CrowsHaveEyes

Вместо ChatGPT я использовал Open WebUI, который поддерживает MCP из коробки. Логичный выбор — это самый полноценный открытый аналог веб-интерфейса ChatGPT.

Однако, ограничения Open WebUI по части MCP меня сильно разочаровали. Моей целью было сделать как у OpenAI: при желании пользователь может передать URL своего MCP-сервера на инференс-API, и этого должно быть достаточно, чтобы вызывать его tools.

tools=[

{

"type": "mcp",

"server_label": "deepwiki",

"server_url": "https://mcp.deepwiki.com/mcp",

"require_approval": {

"never": {

"tool_names": ["ask_question", "read_wiki_structure"]

}

}

},

]

Но Open WebUI не поддерживает напрямую транспортные протоколы, через которые MCP-клиент и сервер обмениваются сообщениями - streamable HTTP и SSE. Вместо этого у Open WebUI есть собственный прокси (mcpo), с помощью которого можно конвертировать MCP сервер, доступный локально через stdio, в RESTful HTTP. Прямо скажем, неудобно.

У большинства разработчиков задача сводится к деплою готового MCP сервера, реализующего какую-либо внешнюю интеграцию - например, с Jira или PostgreSQL — и его связке с AI-агентом.

Поэтому я подумал: а почему бы не сделать платформу, позволяющую автоматизировать оба шага, или во всяком случае дать разработчику инструменты, позволяющие все сделать максимально просто?

Хорошо бы, чтобы платформа поддерживала понятный удобный пользовательский интерфейс - Open WebUI, но без выявленных выше ограничений. На самом деле одного Open WebUI мало; с учетом запросов рынка, как подсказывает мой опыт, нельзя забывать о популярности телеграм-ботов применительно к AI, а также о необходимости программного доступа по API. Но все же Open WebUI — хорошая стартовая точка.

Решение, которое позволяет обойти ограничения поддержики MCP протокола — это пайплайны Open WebUI. Например, вы можете поднять свой AI агент как отдельный микросервис. Пайплайн — это модуль, который свяжет агента через Open WebUI и позволит вам написать тонкую программную прослойку, чтобы конвертировать ответы агента в формат Open WebUI, добавить какие-то кастомные фичи. В моем случае это передача URL внешнего MCP-сервера.

Здесь тоже все не так просто. Предположим, что код агента написан, например, на LangChain. Мне очень не нравится официальный MCP адаптер для LangChain, мне нужно что-то более простое, желательно синхронное, совместимое с любой python-библиотекой. Клиентской библиотеки, обладающей перечисленными свойствами, в открытом доступе не хватает, и я решил написать свою.

Сам по себе MCP протокол очень прост. Клиент инициализирует сессию, согласно конвенции, определенным JSON-RPC сообщением, может вызывать список tools, prompts, resources сервера, и вызывать тулзы. По замыслу разработчиков протокола, передача JSON-RPC сообщений должна быть возможна поверх нескольких транспортных протоколов - как минимум, HTTP-стрима и stdio. Оба транспорта достаточно легко реализуются стандартными средствами Python.

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

Напротив, я убедился на опыте, что как минимум elicitation — возможность запросить детали у юзера при выполнении определенного шага рабочего процесса агента - в ряде случаев необходима.

Правда, когда мне пришлось реализовать такой механизм в реальном агенте, выбранный мной способ был далек от того elicitation, который мы видим в официальном MCP SDK от Anthropic, и не без причин. Мало того, что elicitation требует двустороннего обмена сообщениями между агентом и пользователем, так еще и агент сам должен иметь возможность задавать вопрос, выступая в некоторых случаях инициатором диалога, а не тем, кто только отвечает на сообщения пользователя. Эти ситуации пока что не проработаны в большинстве диалоговых AI-систем.

Впрочем, свой MCP-клиент я решил не перегружать нестандартным функционалом. По замыслу он должен остаться относительно простым и включать следующие компоненты:

• MCP-сессию, реализующую отправку JSON-RPC сообщений на сервер;

• Транспортный слой, который включает поддержку HTTP-стрима и stdio;

• Адаптер, в настоящий момент - для LangChain/LangGraph, но с возможностью добавлять другие агентские бэкенды.

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

Наконец, модульная архитектура пайплайнов в OpenWebUI позволяет легко поддерживать несколько LLM провайдеров - я тестировал свою платформу с API OpenAI и публичными эндпоинтами в облаке.

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

А пока я решил деплоить контейнеры с MCP в облачную среду, откуда мои агенты смогут без проблем их вызывать. Это звучит относительно просто, но неоднозначен как минимум сетевой вопрос: как сделать, чтобы общение агента с MCP было должным образом защищено?

Возникает потребность в приватной сети, но об этом уже в другой раз.

Создание платформы, которая позволяет автоматизировать интеграцию агентов с внешними инструментами, стоит на повестке дня в AI индустрии.

Однако, как и MCP протокол, эта платформа должна быть открытой для кастомизации, предоставлять разработчикам доступ к своим внутренним модулям и API. Тот уровень контроля, который дает OpenAI в случае со своими MCP коннекторами в режиме разработчика ChatGPT, на мой взгляд, недостаточен.

В этом и состоит рациональное обоснование моего пока еще экспериментального проекта.

Поэтому агентские системы обычно представляют собой микросервисную архитектуру, объединяющую несколько логических блоков. Взять хотя бы ReAct паттерн, в котором reasoning агент выполняет управляющую роль, а action — отвечает за вызов функций и выполнение других действий.
И, как в любой микросервисной архитектуре, мы приходим к необходимости горизонтального масштабирования, что удобнее всего делать в облаке. Во-первых, сами LLM — очень ресурсоемкие элементы системы, инфраструктура для них требует сложной конфигурации. Об этом больше сказано ниже. Во-вторых, обмен данными между ними тоже требует правильного проектирования и развертывания дополнительных сервисов, как например векторная БД, механизмы стриминга данных, кэширования, чанкования, эмбеддингов.

Главные трудности в конфигурации облачной инфраструктуры под AI агенты, согласно моей практике, связаны с рассчетом нагрузки. Особенно это касается GPU-инфраструктуры, ответственной за хостинг LLM. Эта тема заслуживает отдельной статьи — с появлением различных алгоритмов внимания, квантизации моделей и механизмов выделения GPU-памяти, правильный подбор мощностей требует всё более нетривиальных вычислений. Было бы хорошо, если бы эта проблема также была решена на уровне облака и снимала с AI-инженеров заботу о правильно подобранной инфраструктуре. Но мы находимся на ранней ступени адаптации облаков под нужды AI, и многое приходится изобретать самостоятельно.

Зачем вообще мне понадобилось разворачивать свои ИИ модели в облаке, если можно обратиться к API OpenAI, DeepSeek или Qwen? На практике среди преимуществ открытых весов неожиданно в приоритете оказалась скорость генерации ответа. Для ряда агентских систем критическим параметром является именно скорость. На нее оказывают влияние сетевая связность, размер весов и тип квантизации, мощность GPU, параллелизм запросов, размер контекстного окна и масса других параметров, к которым разработчик далеко не всегда имеет доступ, работая с провайдерами закрытых моделей типа OpenAI.

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

Так ли это — покажет время.

Retrieval‑Augmented Generation (RAG) — тандем LLM и векторных баз для поиска релевантных фрагментов, вставляемых в контекст перед генерацией, который обрел популярность в последние год-полтора благодаря нескольким безусловным преимуществам.

Этот подход позволяет использовать модели общего назначения на узкоспециализированных доменах без полного дообучения. Он и сейчас является самым надежным и дешевым способом снизить галлюцинации, даёт ссылки на документы и улучшает точность ответа. RAG используется в цепочке следующих логических шагов, через которые проходят данные в системе: векторизация → recall → prompt → LLM → извлечение структурированных данных.

Теперь о минусах RAG. Описанная методика только дополняет контекст модели релевантными данными, но не повышает способность самой LLM к извлечению нужных признаков. Эта способность зависит от того, каким задачам и на каких данных модель была обучена. К тому же RAG добавляет несколько архитектурных и прикладных сложностей - пайплайн с векторной базой, embedding, поиск по индексу, чанкинг данных, который может быть нетривиальным процессом с применением различных методик (таких как Semantic Chunking).

Сейчас контекстное окно модели позволяет вместить намного больше данных, чем раньше - взять хотя бы 1 млн токенов у Llama 4, так что необходимость в чанкинге и самом RAG уже не настолько острая. Есть, конечно, проблема понимания длинного контекста. Важно понимать, что при решении практических задач точность LLM может падать пропорционально длине контекста - на эту тему есть интересный бенчмарк:

Разные модели имеют разные показатели long context understanding, как видно из таблицы выше. Их точность для определенных задач можно увеличить двумя способами - SFT-файнтюнингом на размеченных данных и дистилляцией - передачей знаний от более сильной модели.

Fine‑tuning: точечное улучшение LLM

Файнтюнинг изначально был менее доступен, чем RAG - во-первых, он требует понимания того, как работает оптимизация весов большой языковой модели-трансформера (если мы не говорим про файнтюнинг каких-то других архитектур нейросетей). Во-вторых, он требует набора данных (как правило, размеченных, если мы говорим про Supervised Fine-Tuning), и в третьих, он требует вычислительных мощностей, таких как GPU-кластер.

В результате файнтюнинг позволяет настроить веса модели под конкретные инструкции, задачи, формат данных, что значительно повышает точность модели в определенном специализированном домене.

На своем опыте я сделал следующий вывод: файнтюнинг необходим для разработки агентов, особенно в области feature-extraction задач, это очень эффективная практика, которая должна быть взята на вооружение разработчиками, так как она закрывает недостатки RAG и служит необходимым компонентом прикладных ИИ систем. Перечисленные выше трудности файнтюнинга тоже постепенно решаются - во-первых, облачные провайдеры делают доступными вычислительные мощности. В моих статьях и видео достаточно гайдов по использованию облака для файнтюнинга. Чтобы экономить на GPU, по-прежнему остается актуальной методика Low-Rank Adaptation (LoRA), хотя во многих случаях и полный файнтюнинг, который модифицирует веса модели полностью, тоже возможен и оправдан. Ведь для узко специализированной задачи может быть достаточно обучить модель на совсем небольшом наборе данных - 100-500 примеров.

Динамическая квантизация в сочетании с LoRA (QLoRA) позволяет еще сильнее сократить расход видеопамяти и время обучения модели.

В целом SFT-файнтюнинг можно разделить на следующие шаги: подготовка датасета → формирование train и validation наборов → обучение → оценка. В моем последнем видео я "начал с конца" и разобрал прикладные аспекты оценки (evaluation) при разработке агентских систем. Лишь недавно я обратил внимание на библиотеки для evaluation, такие как openevals в экосистеме Langchain/Langsmith, о которых в знал и раньше, но обходился простым скриптингом. Для тех, кто только начинает знакомство с evals, будет полезен мой ноутбук с экспериментами на Langchain/Langsmith и openevals.

При подготовке данных для feature extraction важно выбрать итоговый формат данных, который будет понятен и человеку, и LLM. При небольшом объеме данных самое важное - качественные примеры ответов (output), которые готовятся обычно человеком, вручную. Это особенно актуально для специализированных случаев feature-extraction - например, если вы разрабатываете систему, которая будет читать технические спецификации изделий, товарные коды и тому подобные типы данных. Для составления такого датасета придется привлекать человека с профессиональными знаниями в соответствующем домене. А для LLM чем проще выходной формат данных, тем меньше вероятность галлюцинаций. Поэтому я руководствуюсь тремя принципами -

1. Не усложнять выходной формат данных применением, например, JSON или XML - простого текста в большинстве случаев достаточно;

2. Выполнять feature-extraction из минимальной единицы входных данных за одну генерацию. Это может быть одна PDF-страница, изображение, параграф текста;

3. Использовать Chain-of-Thoughts для валидации процесса извлечения.

Само обучение, как ни странно, вызывает меньше всего проблем - используйте готовые средства обучения библиотеки transformers или API OpenAI, контролируйте качество чекпоинтов, своевременно используя evaluation, и следите за оверфиттингом.

Distillation: перенос знания

Distillation — это обучение компактных или более слабых моделей на основе поведения более сильной LLM‑«учителя». Это еще один способ повысить качество модели, часто менее затратный, чем SFT-файнтюнинг - достаточно просто сгенерировать датасет с помощью модели-учителя, без участия человека.

Отличным практическим примером перечисленных методик может послужить исследование технологического института Джорджии, опубликованное в январе 2025.

Авторами была реализована следующая архитектура:

DistilBERT + fine‑tuning на 10 000 документов → компактная модель с эффективным временем обучения (4–9 ч на ПК) с 97% качества модели-родителя. Пайплайн извлечения признаков включал следующие шаги:

• Сэмплинг 10k примеров из тестового корпуса (объявления вакансий) с целью извлечения признаков.

• Разбивка на чанки с применением Semantic Chunking

• Генерация ground‑truth с помощью LLM (Gemini).

• Файнтюнинг DistilBERT - небольшой модели с архитектурой раннего трансформера, которая получена путем дистилляции знаний модели BERT. Дистилляция позволяет сохранить 97% процентов качества, при размере на 40% меньше, чем у исходной модели BERT

• Prediction - извлечение признаков.

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

RAG — поиск релевантных фрагментов, Fine‑tuning для улучшения и стабилизации ответов модели, и Distillation в эффективной агентской системе дополняется промпт-инжинирингом и CoT, Chain‑of‑thoughts, для самовалидации системой извлеченной информации и ее автоматического итеративного приближения к ожидаемому результату.

Датасет содержит данные на более чем 30 языках, включая русский. Данные получены следующим образом:

Выполнена выборка промптов из открытых англоязычных датасетов с последующим переводом на различные языки. Для перевода использовалась GPT-4o, которая, кстати, хорошо показала себя при создании моего собственного датасета и русскоязычного файнтюна Llama 3 на нем. Далее авторы мультиязычного CoT-датасета сгенерировали ответы на полученные промпты с помощью deepseek-ai/DeepSeek-R1-Distill-Llama-70B восемь раз, и отфильтровали блоки <think> не на том языке, либо с нарушениями правил языка или логическими ошибками. Это достаточно интересный момент, так как разработчики полностью опубликовали код для генерации своего датасета, включая фильтрацию сгенерированных цепочек рассуждений. Если с автоматическим определением языка цепочки все достаточно просто, то для проверки ее соответствия нормам языка и, самое главное, логической корректности, пришлось опять-таки задействовать LLM. Принцип такой же, как и при использовании модели-судьи для выполнения автоматизированных evaluation-тестов.

Пример оценочного промпта из кода проекта:

fluency_system_message = f"""You are a {language} fluency evaluation AI. Given a piece of text, give the fluency and naturalness of the {language} in the text a score from 1-5. Only include your final number in your output."""

То есть модель-судья выставляет оценку от 1 до 5 правильности и естественности сгенерированного текста. Почему-то разработчики использовали GPT-4o-mini, хотя у нее самой, на мой взгляд, есть проблемы с мультиязычностью. Возможно, более правильной оценки можно добиться, используя тот же DeepSeek V3. В итоговый датасет попали только те ответы, у которых наилучшая оценка по пятибалльной шкале.

После этого датасет готов к файнтюнингу моделей рассуждений — дистиллированных на R1 версий Qwen. Для файнтюнинга моделей от 1.5 до 14B авторы использовали llamafactory (код доступен в репозитории на HF по ссылке выше) и достаточно скромные GPU-мощности: всего лишь около 10 минут на восьми NVIDIA L20. Т.е. Вы вполне можете взять GPU поменьше — например, из доступных моделей в облаке подошли бы две RTX 4090 или A10, или одна V100 - и за несколько часов достичь того же результата.

В остальном это обычный SFT-файнтюнинг в одну эпоху, без квантизации. Отдельно стоит отметить процесс evaluation — код можно найти здесь. Ниже — таблица оценок полученных моделей рассуждений для промптов на разных языках. Из нее можно сделать вывод, что модели генерируют более корректные цепочки на таких языках, как английский, немецкий, испанский и другие, наличие которых в корпусе базовой модели, можно предположить, было относительно высоким. Их оценка около 0.8, тогда как у менее распространенных в цифровом пространстве языков она ниже, например, 0.2 у тамильского.

Хорошая новость, что на русском модели научились генерировать цепочки мыслей достаточно неплохо, судя по результату evaluation — даже при том, что в датасете всего 54 примера на русском.