Выбрать большую языковую модель оказалось проще, чем найти к ней интерфейс. Рассказываем, как мы за полгода прошли через Open WebUI, остановились на Assistant-UI и почему это изменило наш подход к AI-продуктам.
Суть события
Команда, разрабатывающая корпоративный AI-продукт, столкнулась с неожиданной проблемой: модель выбрали за неделю, а интерфейс к ней не могли найти три месяца. Готовые решения либо слишком простые, либо слишком закрытые. История выбора между Open WebUI и Assistant-UI — это по сути история о том, где проходит граница между «показать чат» и «встроить AI в продукт».
Детали
Open WebUI — это open-source веб-интерфейс, который можно развернуть рядом с любой LLM за один вечер. По сути это self-hosted AI-чат в духе ChatGPT, только свой. Для задач, где пользователю нужен привычный диалог с моделью и больше ничего, это разумный выбор: быстрый запуск, минимум кода, знакомый UX. Но если ваш продукт — не чат, а процесс, где AI ведёт пользователя по шагам, обновляет состояние, вызывает инструменты и ждёт подтверждения, Open WebUI упирается в стену.
Assistant-UI — это TypeScript/React библиотека, набор инструментов для сборки интерфейса под свою задачу. Это не готовое решение, а конструктор. Библиотека умеет показывать ответ модели по мере генерации, корректно обрабатывает прерывания и повторные запросы, поддерживает длинные многошаговые диалоги и интегрируется с разными бэкендами, включая собственные API и LangGraph. Из коробки доступно больше 20 UI-компонентов для прямого взаимодействия с пользователем — от таблиц и чек-листов до командной строки и трекера прогресса.
Интеграция с LangGraph стоит отдельного внимания. Это не просто «AI отвечает на вопросы», а фреймворк, где состояние агента может включать граф задач, маршруты, точки ожидания человека. Assistant-UI поддерживает потоковое обновление не только текста, но и состояния агента — а значит, на интерфейсе можно показать, на каком этапе сейчас работает AI, что он делает и когда ждёт решение человека. Для продуктов с human-in-the-loop это архитектурная база, а не костыль.
Обратная сторона: порог входа ощутимо выше. Нужен React, нужно время на сборку MVP, часть функциональности придётся дописывать руками — та же работа с документами, которая в Open WebUI была сразу.
Контекст
Эта история выбора применима не только к «Банку идей» из оригинальной статьи. Логика «готовый чат vs кастомный фреймворк» всплывает в десятках сценариев: внутренние AI-ассистенты для сотрудников, AI-модули в CRM и ERP, сервисы разбора заявок и документов, мультиагентные системы для аналитики и проверки гипотез. Во всех этих случаях «чат» — это верхний уровень. Под ним — корпоративный поток, состояние, управление агентами, проверки, согласования и доменная логика. UI становится частью архитектуры продукта, а не декоративной оболочкой.
Параллель с веб-разработкой 2010-х: когда сайты были статичными, хватило готовых CMS. Когда появились сложные интерактивные приложения, WordPress перестал хватать — нужен был свой фронтенд. С AI-продуктами происходит то же самое. Готовые платформы хороши для быстрого старта и универсальных сценариев. Но для продуктов, где AI — не просто генератор ответов, а участник бизнес-процесса, нужен инструмент, который позволяет проектировать UX вокруг логики системы.
Что дальше
Простая рамка: если цель — быстро показать пользователю чат с AI и этого достаточно, берите Open WebUI. Если цель — встроить AI в конкретный бизнес-сценарий, где модель работает с состоянием, вызывает инструменты, ведёт пользователя по процессу и ждёт обратную связь — нужен фреймворк уровня Assistant-UI. Это не про сложность ради сложности, а про соответствие интерфейса логике продукта. Команды, которые уже работают с LangGraph или похожими оркестраторами, получат от Assistant-UI максимум: нативная поддержка потокового состояния, human-in-the-loop и генеративный UI из коробки. Для остальных — стоит хотя бы попробовать и посмотреть, где упираетесь в возможности готового чата.
