Это вторая часть нашей реализации MCP на Open WebUI, которая строится для целей портфельной аналитики. В прошлой части мы разобрали интеграционную часть нашего решения: как мы пришли к Open WebUI, как использовали статусы в запросах пользователя, как отображаем результаты (чтобы не словить ошибки о слишком больших чанках), как строим графики в интерфейсе и как работаем с запросами пользователей.

Данная часть будет посвящена реализации самого агента: его общению с инструментами, вызову этих самых инструментов и планированию шагов по их вызовам. В этой статье будет рассмотрен наш путь по реализации данного агента: от наивного агента, которому просто дали пул инструментов и отправили в релиз до разделения агента на планировщик и исполнителя (спойлер: вторая версия стала куда лучше справляться с различными задачами). Отдельно будет затронута возможность различных моделей использовать chain-of-thoughts.

В момент выхода протокола MCP нас очень заинтересовали его возможности. Нам хотелось использовать этот протокол для того, чтобы внутренние пользователи могли обращаться к базе данных в свободной форме и получать данные в течение нескольких минут. MCP для этого выглядел очень хорошо: пользователь может сформировать запрос на удобном для него языке, а LLM поймет, что нужно сделать и сделает это.

На первый взгляд MCP в связке с LLM полностью закрывал данные проблемы, однако с ростом объема данных стало заметно, что LLM не удается обрабатывать их быстро и качественно, а написание SQL запросов для нее не всегда легкая задача (даже если примеры этих запросов у нее есть в промпте). В итоге мы получили потерю контроля над контекстом модели и непредсказуемый результат.

В этой части я расскажу про интеграцию с Open WebUI и какая архитектура модели позволила победить вышеуказанные проблемы. Следующие статьи расскажут о реализации MCP таким, каким он позволяет выполнять наши задачи (но не финальной версии). Эта статья может быть полезна всем, кто строит свои модели на основе Open WebUI или еще только выбирает фреймворк, на котором предстоит строить будущую модель

Это вторая (и заключительная) часть цикла статей о нашей миграции с Zeppelin. О причинах и первом опыте перехода с Zeppelin я рассказал здесь. В данной статье я хочу большее внимание уделить второму виду Zeppelin notebook, которые срочно нуждались в переносе.
Конечно, отчеты для клиентов не были настолько "забагованы" как рассылки: большая часть проблем с Zeppelin крылась именно в cron-е, который временами работал как хотел (или в интерпретаторах, мы так и не смогли разобраться, но ошибка интерпретатора возникала только когда запускали через cron). В отчетах этого звена не было, поэтому их перенос был плавным и основан скорее на особенностях UI/UX дизайна.
Данная статья может быть полезна аналитикам, которые не знают, какой инструмент использовать для своих задач и думают, что писать графический интерфейс крайне сложно (спойлер, нет), а также для команд, которые устали от Zeppelin как UI-инструмента (и от Zeppelin в целом)

Для задач аналитики Zeppelin - это чуть ли не находка. Он может в одной книжке исполнять код на любом языке (был бы интерпретатор), выводить его в виде красивых табличек, графиков и в любом другом виде, который удобен. И на Хабре есть много статей, посвященных плюсом данного решения для задач аналитики.

В результате в аналитический отдел ТКБ Инвестмент Партнерс данный инструмент проник достаточно глубоко: на нем писались аналитические отчеты для разных отделов, расчетные таблицы, которые затем отсылались в дашборды, также данными книжками могли пользоваться все, кто знал какие-либо языки программирования.

И мы попали в зависимость от него. Панацея, которая должна была стать легким решением для (почти) любой задачи превратилась в наше проклятие. Из-за проблем с данной системой на нас приходило по 5-7 тикеров в неделю, а также потерей доверия к нашим сервисам.