Выбор UI-инструмента для быстрого прототипирования в AI-продуктах: Open WebUI

При разработке AI-продукта мы столкнулись с неожиданной задачей. Выбрать LLM оказалось проще, чем выбрать интерфейс для работы с ней. Готовые AI-чаты хорошо подходят для диалога с одной моделью, но начинают ограничивать продукт, если в нем появляются несколько агентов, сложные сценарии и промежуточные этапы работы. В этой статье опишем суть задачи, требования и разберем Open WebUI.

Основная цель MVP заключается в демонстрации замысла продукта и проверке его жизнеспособности. На этом этапе важно сконцентрироваться на реализации основных функций, внешний вид порой не так важен. Но в AI-продуктах есть нюанс: даже для MVP интерфейс нередко становится частью логики продукта и будущей архитектуры.

Если раньше AI-решения были, по сути, одним чатом, в рамках которого пользователь общался с одной нейросетью, то современные решения включают цепочку или граф AI-агентов, каждый из которых выполняет свою работу отдельно от остальных, иногда взаимодействуя с пользователем. В этом случае UI становится полноценным командным центром: состояние системы, динамика размышлений и работы, вызов внутренних функций (tool calling), точки взаимодействия с пользователем (human-in-the-loop) и многое другое.

Поэтому выбор UI-инструмента влияет и на скорость прототипирования, и на конечный результат, получится ли у пользователя органично работать в системе. В этой статье мы расскажем, как выбирали инструмент для фронтенда в проекте «Банк идей».

Что такое «Банк идей»?

«Банк идей» — это мультиагентная система, отвечающая за анализ и подготовку идей сотрудников компании. Сотрудник в чат-боте описывает проблему, которую хочет решить, подает на вход свою идею, и затем она проходит множество ИИ-агентов, каждый из которых выполняет отведенную ему роль:

• Критик подсвечивает слабые места.

• Безопасник удаляет конфиденциальную информацию, прежде чем идея перейдет во внешнюю LLM.

• И другие агенты.

Под ИИ-агентом принято понимать систему на базе искусственного интеллекта с набором инструментов для решения задачи пользователя.

Работая над «Банком идей», мы столкнулись с необходимостью быстро реализовать фронтенд для демонстрации работы сервиса.

Техническая реализация

Для реализации «Банка идей» мы использовали LangGraph, который позволяет представить логику агентов в виде графа: инструменты агента = узлы, соединенные ребрами, выстраивающими пайплайн агента, а каждый агент = узел в общем графе-оркестраторе.

«Банк идей» подразумевает плотное взаимодействие с пользователем по ходу изменения идеи. У нас было конкретное видение: нам нужен привычный и интуитивно понятный интерфейс: чат-бот с внедрением кастомных компонентов.

Какие нестандартные компоненты требовались:

• Доски. На моменте анализа идеи доменными агентами-экспертами каждый из них должен был передавать свое мнение на доску, где пользователь мог их все прочитать, сравнить и даже внести свои правки. После прохождения этапа оценки доски оставались висеть в чате для контекста.

• Отображение графа. Полный пайплайн графа-оркестратора отрабатывает от 15 до 20 минут. Чтобы пользователь не думал, что сервис завис, мы хотели отображать процесс прохождения всех этапов работы агентов.

Обычный чат-интерфейс хорошо работает, когда весь результат можно представить одним потоком сообщений. Но если система должна показывать состояние процесса, прерываться для подтверждения действий, выводить tool results в виде интерактивных компонентов и сохранять контекст работы, архитектура UI-слоя тоже важна.

Требования к инструменту

Исходя из специфики задачи, мы сформулировали требования:

• Open-source решение.

• Простота внедрения в уже созданную систему.

• Возможность быстрой и удобной кастомизации.

• Продовый и понятный интерфейс.

• Поддержка многошагового взаимодействия.

• Возможность отображать не только ответы модели, но и промежуточные состояния.

• Пригодность не только для демо, но и для дальнейшего развития.

Для внутренних MVP можно позволить себе временный интерфейс. Но если MVP показывает хорошие результаты, бизнес почти всегда хочет быстро перейти к пилоту с реальными пользователями, а затем и к промышленному внедрению. Слишком жесткий UI-каркас может сэкономить время на старте, но создать дорогой рефакторинг уже через несколько недель.

Что попробовали

Исходя из требований, список сократился до двух вариантов:

• Open WebUI — самодостаточная open-source платформа с готовым веб-интерфейсом для работы с моделями, документами, инструментами и knowledge base.

• Assistant-UI — открытая TypeScript/React-библиотека, которая дает production-ready компоненты и инструменты для построения чата, но предполагает, что продуктовый интерфейс вы собираете внутри собственного приложения.

Это два инструмента для разных сценариев. Мы сравнивали их не напрямую, а по удобству для разработки и пользователя и полученному бизнес-результату.

Open WebUI

Именно Open WebUI мы использовали для первого варианта «Банка идей» с минимальной архитектурой, и поначалу казалось, что это лучший выбор.

Плюсы Open WebUI:

• Понятный и привычный интерфейс чат-бота, который не нужно писать с нуля. Присутствуют привычные функции: прикрепление файлов, выдача подсказок для запросов, создание рабочих пространств и так далее.

• Поддерживает любые модели: от локальных до API. Можно обращаться к своим собственным агентам и в любой момент переключать чаты, модели и агентов без потери контекста.

• Интеграция RAG.

• Добавление пользовательских инструментов (Tools) — Python-скриптов в самом веб-интерфейсе, которые выполняются на вашем сервере и действуют по запросу LLM.

• Наличие механизма событий (events), который обеспечивает связь между backend-логикой и пользовательским интерфейсом в реальном времени.

Open WebUI дает богатую функциональность «из коробки». Для команд, которым нужно быстро поднять внутренний AI-чат или демостенд без отдельной фронтенд-разработки, это действительно удобный вариант.

Где Open WebUI начал ограничивать нас

1. Безопасность. Tools и Functions выполняют на вашем сервере произвольный Python-код, поэтому нужно следить, кому передаются права создавать и импортировать инструменты.

2. Невозможность редактировать базовый интерфейс. Большинство функций (левая панель, прикрепление вложений) полезны для обычного чат-бота, но избыточны для «Банка идей». Чтобы их убрать, пришлось бы вносить изменения в код самого Open WebUI, что привязывало бы нас к определенной версии.

3. Детальная кастомизация не предполагается. Мы так и не нашли способа реализовать доски и другие компоненты так, как мы задумали.

4. Ограниченная поддержка многошагового взаимодействия. Несмотря на event-систему, Open WebUI не предоставляет полноценной модели многошагового взаимодействия «из коробки». Поддерживался один эндпоинт, и мы не могли разделить случаи, когда нужно начать пайплайн заново и когда нужно просто его продолжить после прерывания для взаимодействия с пользователем.

Именно здесь стало понятно, что Open WebUI хорош, когда не хочется писать код и нужен готовый привычный AI-чат. Но если проект требует собственного UX со сложным состоянием, human-in-the-loop и доменными компонентами, платформа начинает ощущаться не ускорителем, а рамкой, которую приходится постоянно обходить.

В следующей части так же разберем Assistant-UI и подведем итог по тому, в каких ситуациях какой инструмент выбрать.