Привет! Меня зовут Никита, я старший DS-инженер в Авито. В этой статье расскажу, как мы строили «Виталика» — нашу корпоративную экосистему ИИ-агентов. Отвечу на три главных вопроса: как процесс становится агентом, как сделать систему production-ready и куда развивать её дальше.
Статья будет полезна ML-инженерам, AI-архитекторам и техническим лидам, которые строят агентные системы на базе LLM в корпоративной среде.
По данным McKinsey, к концу 2025 года 71% компаний пробовали интегрировать искусственный интеллект как минимум в один из бизнес-процессов. Звучит мощно, но по отчётам MIT из всех пилотов в реальный продакшн переезжают около 5%.
Разрыв между демо и реальностью заключается в том, что продакшн-готовое решение должно отвечать на сложные вопросы:
– как из множества разносторонних источников выбрать ту информацию, которая приведёт к успешному выполнению процесса?
– как обогатить языковую модель инструментами, при помощи которых она может довести процесс до конца?
– как оценить качество траектории, по которой движется модель, пока решает задачу?
Мы нашли ответы на эти вопросы с помощью системы, которая постепенно превращает внутренние знания и процессы Авито в корпоративных агентов. Расскажу про неё подробнее.
Якорный кейс про закупку программного обеспечения
Представим коллегу из корпоративного центра, которому поставили задачу — найти альтернативу Microsoft Office и закупить программное обеспечение.
Чтобы выполнить это задание, нужно найти потенциальных контрагентов, узнать цены и выяснить, есть ли корпоративные скидки. Скорее всего, для этого придётся сходить в разные базы знаний: сделать запрос в сети, посмотреть документацию в Confluence, спросить во внутренних чатах. Также понадобится созвониться с коллегами и выяснить, нужно ли заводить заявку в хелпдеске, какую заявку делать в 1С, и затем согласовать всё с руководителем. Получается, чтобы просто разобраться, что делать, уже нужно около 30 минут.
Таким образом мы видим, чтобы решить задачу, нужно пройти целый процесс. Возможно, похожим путём идёт не только наш сотрудник из Корпцентра, но и другие специалисты. Получается, если автоматизировать этот процесс, он может подойти и им тоже. Значит, можно собрать коллекцию агентов, которые помогут множеству работников. Мы это сделали и собрали платформу для агентов, которую назвали «Виталик».
Агентами становятся успешные процессы
У сотрудников Авито очень разноплановый набор задач, и «Виталик» устроен так, чтобы закрывать их постепенно, по нарастающей сложности. Пользователь видит только чат, а платформа в это время разными способами собирает контекст. Вот что ей доступно:
Обычный чат. Нужен, чтобы узнать базовую информацию, например, «что такое закупка?» или «какое ПО бывает?». Для этого достаточно самой языковой модели, а внешние базы не нужны.
Подгрузка артефактов. Если нужно решить более сложную задачу, например, написать договор на основе предыдущих, в диалог подгружаются артефакты: документы, картинки, ссылки. Это разовый контекст.
Проекты. Это самый сложный уровень. Контейнер знаний со способностью коллаборации с коллегами, возможностью подключения внутренних и внешних баз знаний, обогащения инструментами и правами доступа.
Агенты. Когда пользователь создаёт проект, он фактически делает кандидата в агенты для «Виталика». У самых успешных проектов есть владелец, валидационные данные и инструменты, закрывающие процесс. Они становятся частью агентской системы «Виталик» с единой маршрутизацией на специализированных ассистентов.
Смысл эволюции в том, что проект перестаёт быть просто местом хранения знаний и может стать агентом. Идеальное состояние, когда «Виталик» получает задачу от сотрудника и сам становится единой точкой входа для автоматизации любого процесса.
Четыре слоя production-ready системы
Вернёмся к якорному кейсу и разберём первый проект, ставший полноправным корпоративным агентом в экосистеме «Виталик». Коллеги из корпоративного центра подключили к проекту множество баз знаний, которые обновляются из Confluence каждую ночь и превращаются в Q&A-консультанта. У каждой базы свой агент, с которым можно общаться, настройка общения с LLM (температура, top-p, top-k) и настройки для внутреннего и внешнего поиска.
Инструмент понимает контекст подразделений и процессов, отвечает со ссылками на актуальные материалы, поддерживает диалог и умеет маршрутизировать вопрос дальше. Он закрывает три типа вопросов:
Процессные, например, «Мне нужно выйти на инвесткомитет с инициативой — что надо сделать?»
Операционные, например, «Как оформить закупку в 1С: что указать?»
Маршрутизация, например, «Нужно ли получить оценку рисков от отдела финансов, или достаточно юридической оценки?»
Чтобы агенты работали без сбоев и галлюцинаций, требовалась устойчивая архитектура. Мы выбрали подход из четырёх слоёв и оркестратора:
Пользовательский слой — вход через веб (React/TS) либо через корпоративный мессенджер. Пользователь задаёт вопрос, уже находясь в каком-то проекте.
Слой бэкенда собирает сессию пользователя и настройки проекта, упаковывает всё в контракт данных и передаёт оркестратору.
Оркестратор — PortalManager. Это мозги системы: здесь происходит сборка сцены для агента.
Слой AI-инструментов — RAG, internal search, gateway, MCP Hub. Это руки агента: доступы к базам данных, внутренним базам знаний, MCP-серверам.
Слой с данными — MongoDB, Elasticsearch, PostgreSQL, S3. Здесь хранятся конфигурации агентов, исходные файлы и векторы для поиска.
Рассмотрим каждую часть подробнее.
PortalManager — мозги системы
Перед тем как сделать PortalManager, нужно было понять, на чём его строить. На рынке множество агентских SDK, но нам не хотелось выбирать вариант, которые умеют только вызывать внешние инструменты. Нужно было обеспечить устойчивость системы к сбоям инфраструктуры и к галлюцинациям модели.
Мы выбрали ADK, потому что у него удобное разделение на абстракции session, state и persistent memory, которые хранят знания о диалоге, текущем проекте, контекст для инструмента и агента, а также персистентные знания о пользователе. Также было важно контролировать поток данных, отсюда ценность колбэков ADK. Главное, что это зрелый продукт с продуманной архитектурой: явный workflow-граф, поддержка MCP, встроенные approvals для человека и полная наблюдаемость с трейсингом.
На каждый запрос из бэкенда PortalManager сначала строит агентское дерево. Для каждого агента выбирается модель: планировщику нужна LLM, которая знает внутренние процессы Авито, а для узких доменов подходят дистиллированные модели, прошедшие валидацию. Дальше это передаётся раннеру.
ADK Runner исполняет ReAct-цикл: перед каждым вызовом модели происходит RAG-инъекция контекста → модель решает, ответить сразу или вызвать инструмент → вызывается tool, MCP или рекурсивно другой агент → результат инструмента возвращается модели, и она решает, что делать дальше → PortalManager ловит финальное событие и отдаёт пользователю ответ. Это может быть маршрут, ссылки, следующий шаг.
Применительно к нашему кейсу это значит, что модель на шаге RAG-инъекции подтягивает регламент закупки ПО, на шаге tool-вызова может обратиться к 1С-интеграции или базе поставщиков, а в финальном событии отдаёт сотруднику готовый маршрут из того, что заполнить, куда отправить заявку и кого поставить в копию.
Порядок исполнения выбирает сама LLM, а PortalManager задаёт доступные инструменты, контекст, правила, состояние и наблюдаемость.
Workflow, agent runtime и coding-агенты не взаимозаменяемые вещи
Отмечу разницу между хайповыми инструментами автоматизации — вроде n8n, ADK и Claude Code. У них разный фокус.
Workflow-инструменты (n8n, Make и Zapier) построены вокруг жёсткой, детерминированной логики. Например, при поступлении письма от руководителя система последовательно проверяет заголовок, обращается к LLM как к рядовому модулю обработки и выполняет действие. Эти платформы незаменимы для заранее известных сценариев: cron-задачи, вебхуки, согласования и интеграции. Однако вне этой парадигмы они бессильны: управление доступом, контекстная память, RAG, гибкая настройка агентов и система бенчмарков им не доступны.
Agent runtime (ADK, LangGraph, AutoGen) строятся вокруг LLM как центрального элемента. Они предоставляют управление состоянием, систему колбэков и механизмы работы с памятью. Однако это скорее конструктор, чем готовый продукт: такой рантайм даёт инфраструктуру, но не решает задачи тонкой настройки поведения и не избавляет от низкоуровневой доводки под конкретную задачу.
Coding-агенты (Claude Code и аналоги) узко специализированы на работе с кодом, но у них отсутствует инфраструктурная прослойка для интеграции в бизнес-процессы предприятия.
Ценность «Виталика» в том, что это слой над перечисленными решениями: workflow-инструменты запускают процессы, ADK даёт runtime, а «Виталик» — корпоративный продуктовый слой, объединяющий их для конкретной задачи.
RAG или сердце «Виталика»
PortalManager формирует решение и ответ, поэтому его можно назвать мозгом системы, а RAG — это сердце «Виталика». Он чувствует, какая информация нужна для успешного завершения процесса.
Каждый процесс и доменная область обладает своей спецификой: одному нужен тяжёлый препроцессинг PDF, а другой фокусируется на работе с таблицами. Команда предоставляет разные абстракции для работы с препроцессором документов и даёт инструкцию для каждого агента, как с этими документами работать.
Конвейер строится как цепочка этапов:
1. Загрузка исходных данных из PDF, Excel, Confluence и проектных документов.
2. Препроцессинг: парсинг, обработка таблиц, fallback и дедупликация.
3. Индексация: нарезка чанкером, расчёт эмбеддингов, запись в Elasticsearch.
4. Поиск: векторный и гибридный поиск с реранкером и внутренним поиском.
5. Сборка контекста: контроль токен-бюджета, вставка цитат, защита от переполнения.
6. Формирование ответа модели на подготовленном контексте.
❗Важно: модель вызывается только на финальной стадии, а не участвует на всём протяжении процесса.
Для нашего сотрудника из корпоративного центра это означает, что основой для ответа станут регламенты закупок, прайс-листы поставщиков и внутренние политики по ПО. Именно они проходят этот конвейер, прежде чем модель сформулирует финальный маршрут действий.
Логичное продолжение этой идеи — не делать детерминированный поиск в RAG, при котором для каждого запроса поиск по сырым документам начинается с нуля. Это продолжение идеи Андрея Карпаты про внутреннюю LLM-вики. Вместо этого модель готовит собственную базу знаний из сырых документов: строит индекс, страницы сущностей и концептов, саммари и список противоречий.
На повторные вопросы система использует результат постпроцессинга, который сама определила как релевантный. RAG выступает местом, где корпоративные знания становятся машинно-используемыми. Критически важно качество, включая реранкер, валидационный датасет, масштаб, который обеспечивается кэшированием чанков и эмбеддингов, и работа с контекстом, а именно бюджетирование и защита от переполнения.
MCP Hub и инструменты
Мы сознательно вынесли инструменты в отдельный MCP‑хаб, чтобы не перегружать Portal Manager. Агент не знает, что именно находится под капотом каждого сервиса. Он вызывает нужный инструмент через единый слой. Это даёт чистое разделение ответственности и упрощает масштабирование.
В кейсе с закупкой ПО именно через MCP Hub PortalManager обращается, например, к интеграции с 1С или к внутреннему сервису согласований. Сам агент не знает деталей этих систем, только контракт вызова.
Сами инструменты подключаются как функциональные возможности с единым контрактом, владельцами, правами доступа и трассировкой. При этом неважно, это прямые MCP-серверы, jira-mcp, локальные тулы и колбэки или LLM- и реранкер-шлюзы.
Бенчмарки для измерения качества агентов
Чтобы проект стал агентом, нужно постоянно измерять его качество.
Оценка разбита на четыре направления:
Function calling — агентское поведение и способность моделей. Используются BFCL, ruBFCL — проприетарно переведённый бенчмарк, tau2 и датасеты, сгенерированные на собственных документах.
RAG и поиск — насколько хорошо система находит релевантный контекст и даёт качественный ответ по документам.
Tools / MCP — насколько корректно вызываются инструменты, правильные ли аргументы, нет ошибок и задержек.
Domain agent — доменный бенчмарк, который приносит владелец проекта. Это LLM-as-a-judge, эталонные ответы и обратная связь.
Именно так измеряется и агент из нашего якорного кейса — умный поиск по процессам корпоративного центра. Для него собран набор эталонных вопросов и ответов, в том числе про закупку ПО, также учитывается обратная связь от сотрудников по лайкам и дизлайкам.
Важно, что измеряется не только текст ответа, а поведение агента целиком: маршрут, вызовы инструментов, контекст и то, насколько обоснованным получился ответ.
Система продолжает развиваться
«Виталик» выглядит как дерево с единым входом в корне. Вертикали обозначены большими ветками, а мелкими — отдельные процессы. У каждого процесса свой бенчмарк, набор инструментов, промпт и функциональные возможности, но всё живёт в единой экосистеме.
Считаем, что у «Виталика» ещё много точек роста:
📍 Научить агентов выполнять продолжительные процессы: писать код, создавать собственные инструменты, запускать цепочки действий и доводить их до результата. При этом они продолжают отвечать на запросы: это базовая функция.
📍 Развить идею Карпаты и создать внутреннюю LLM-вики, чтобы модель сама вела базу знаний, обновляла её и использовала для последующих запросов. Такой подход сделает агентов устойчивее и быстрее.
📍 Строить собственные модели. Мы уже обучаем их под русский язык и специфику Авито, что даёт прирост по качеству и безопасности. Такие LLM лучше понимают внутренние документы и работают быстрее на наших задачах.
📍 Ищем проекты и инструменты, чтобы сделать их частью экосистемы как подключаемые функциональные возможности.
«Виталик» — это платформа, на которой полезный сценарий проходит весь жизненный цикл от идеи до полноценного агента.
Вся статья кратко
👉 «Виталик» — корпоративная платформа Авито, в которой собраны ИИ-агенты, автоматизирующие внутренние процессы компании.
👉 Агентами становятся популярные проекты с владельцем, бенчмарками и инструментами.
👉 Архитектура платформы — это PortalManager, который управляет сессией и контекстом, ADK исполняет ReAct-цикл, RAG собирает релевантную информацию, а MCP Hub подключает инструменты.
👉 Бенчмарки оценивают качество по function calling, поиску, вызовам инструментов и доменным эталонам.
👉 Платформа развивается: долгие процессы, LLM-вики, собственные модели и новые возможности агентов.
Автор: nikita_ny
