При разработке AI-продукта мы столкнулись с неожиданной задачей. Выбрать LLM оказалось проще, чем выбрать интерфейс для работы с ней. Готовые AI-чаты хорошо подходят для диалога с одной моделью, но начинают ограничивать продукт, если в нем появляются несколько агентов, сложные сценарии и промежуточные этапы работы. Разбираем, почему мы остановились на assistant-ui вместо Open WebUI и какие выводы сделали в процессе.
Когда обычного чат-интерфейса уже недостаточно
Еще несколько лет назад большинство AI-сервисов представляли собой обычный чат с одной языковой моделью. Пользователь задавал вопрос, получал ответ, и на этом взаимодействие заканчивалось. Сегодня корпоративные AI-продукты устроены иначе. За одним запросом пользователя может стоять целая цепочка AI-агентов, каждый из которых выполняет свою задачу: анализирует данные, обращается к внешним сервисам, вызывает инструменты, проверяет результат или передает его следующему агенту. В некоторых сценариях к процессу снова подключается пользователь, чтобы подтвердить действие, уточнить информацию или скорректировать ход выполнения. В такой архитектуре интерфейс должен показывать состояние процесса, отображать промежуточные результаты работы агентов, поддерживать многошаговое взаимодействие и помогать пользователю ориентироваться в том, что происходит внутри системы.
Какие требования к интерфейсу появились в «Банке идей»
С задачей выбора UI-инструмента мы столкнулись при разработке «Банка идей» — мультиагентной системы для анализа и доработки предложений сотрудников. Подробнее об устройстве продукта мы уже рассказывали в отдельной статье, поэтому здесь остановимся только на особенностях, которые повлияли на интерфейс. Обработка одной идеи состоит из нескольких этапов и занимает от 15 до 20 минут. В процессе с ней последовательно работают разные AI-агенты, а на отдельных шагах требуется участие пользователя. Поэтому интерфейс должен был поддерживать не обычную переписку с моделью, а полноценный многоэтапный сценарий. Мы сформулировали несколько основных требований:
- отображать текущий этап обработки и общий прогресс показывать результаты работы отдельных агентов
- поддерживать паузы, во время которых система ожидает действий пользователя
- позволять подтверждать, уточнять или корректировать результат на промежуточных этапах
- отображать структуру процесса в виде графа
- поддерживать отдельные экраны и нестандартные компоненты, включая доски с идеями
- сохранять состояние длительных операций, чтобы пользователь мог вернуться к процессу позже
Мы понимали, что выбор интерфейсного решения повлияет не только на скорость сборки MVP, но и на возможность развивать продукт без постоянной борьбы с ограничениями готового чата.
Почему начали с Open WebUI, а затем отказались от него
Из коробки он предоставляет многие возможности, которые нужны AI-продуктам:
- чат с языковой моделью
- загрузку и обработку файлов
- поддержку нескольких моделей
- работу с инструментами и артефактами
- пользовательские настройки
- открытую кодовую базу, которую можно дорабатывать под свои задачи.
Благодаря этому мы быстро получили рабочий интерфейс и смогли сосредоточиться на развитии мультиагентной системы, а не на разработке базового UI.
Однако по мере развития продукта наши требования вышли далеко за рамки классического AI-чата. Интерфейс должен был не только отображать диалог, но и поддерживать сложные пользовательские сценарии. Например:
- показывать граф выполнения и текущее состояние процесса
- отображать результаты работы отдельных агентов в разных представлениях
- выводить собственные экраны и виджеты
- поддерживать доски с идеями и другие нестандартные компоненты
Нам приходилось все глубже вмешиваться в архитектуру Open WebUI. Чем больше появлялось новых сценариев, тем больше времени уходило на адаптацию существующего решения. Интерфейс продукта уже не укладывался в модель чат-приложения, а значит нужна была библиотека, которая позволит строить UI вокруг собственной логики.
Почему выбрали assistant-ui
В отличие от Open WebUI, это не готовое приложение, а React-библиотека для создания AI-интерфейсов. Она берет на себя базовую функциональность работы с языковыми моделями, а внешний вид, навигацию и пользовательские сценарии полностью определяет разработчик.
В частности, assistant-ui позволяет:
- свободно комбинировать чат с любыми другими элементами интерфейса
- добавлять собственные экраны и маршруты без обходных решений
- использовать существующую дизайн-систему
- интегрировать компоненты React без ограничений
- постепенно развивать интерфейс по мере появления новых сценариев
Еще одним преимуществом стала архитектура библиотеки. Большая часть логики взаимодействия с LLM вынесена в отдельные примитивы и хуки. Благодаря этому можно менять внешний вид приложения или добавлять новые сценарии, не затрагивая механизм работы с моделью.
В результате интерфейс больше не был привязан к архитектуре готового AI-чата. Мы смогли строить его как обычное React-приложение, добавляя AI-функции туда, где они нужны.
Что стоит учитывать при выборе AI-интерфейс
Наш опыт показал, что универсального решения не существует. Для проверки гипотезы готовые AI-интерфейсы помогают быстро собрать MVP. Но если продукт развивается и вокруг чата появляется собственная логика, их возможностей может оказаться недостаточно.
Для Банка идей оптимальным решением стал assistant-ui. Он позволил встроить AI в существующее React-приложение, сохранить единый интерфейс и при этом не ограничивать развитие продукта. На текущем этапе его возможностей полностью хватает для наших задач.
Главный вывод: выбирать стоит не самый функциональный инструмент, а тот, который соответствует архитектуре и этапу развития продукта.