Авито: как «Виталик» превращает корпоративные проекты в агентов

Почему корпоративному ассистенту мало просто отвечать на вопросы

Внутри крупной компании инструкции, документы и инструменты распределены между подразделениями. Сотруднику недостаточно получить от языковой модели убедительный текст: он должен найти действующий регламент, понять, к кому обратиться, а иногда выполнить действие в другой системе. Ошибка в источнике или маршруте означает лишнее согласование и работу, которую придётся переделывать.

В статье от 18 августа 2026 года старший DS-инженер Авито Никита описывает «Виталика» — корпоративную платформу, которая объединяет знания, специализированных агентов и инструменты. Вопрос авторов не в том, как подключить LLM к чату, а в том, как постепенно превращать повторяемые процессы в управляемые агентские сценарии.

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

Сквозной пример: как разобраться с закупкой ПО

Представим сотрудника корпоративного центра, которому нужно найти замену Microsoft Office и оформить закупку. Ему предстоит выяснить, какие поставщики подходят, сколько стоит решение, есть ли корпоративные скидки, какой порядок согласования действует сейчас. Ответ лежит не в одном документе: понадобятся Confluence, внутренние чаты, поиск в сети, консультации коллег, заявки в хелпдеске и 1С, согласование с руководителем.

Автор оценивает примерно в 30 минут время, нужное только на выяснение маршрута вручную, а не на всю закупку от выбора поставщика до оплаты. «Виталик» должен убрать повторяющийся поиск: подобрать материалы, сопоставить актуальность правил, сформулировать следующий шаг и направить к нужному сервису или человеку. Это не означает, что все обязательные согласования исчезают.

На схеме показан целевой эффект: сократить выяснение маршрута с 30 минут до 1–3 минут; в тексте автор говорит о «паре минут». Это оценка для приведённого сценария, а не измеренный результат A/B-теста или время полного завершения закупки.

Как чат превращается в проект, а проект — в агента

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

Принципиальное различие между артефактом и проектом — срок жизни знаний. Вложение помогает один раз ответить на вопрос; проект собирает устойчивый контекст, над которым могут работать коллеги. Но само наличие документов ещё не делает проект агентом: он должен иметь ответственного владельца, материал для проверки качества и инструменты, если задача требует действий.

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

Первый доменный агент: консультант корпоративного центра

Первым примером проекта, ставшего полноправным агентом, автор называет работу корпоративного центра. Коллеги подключили несколько баз знаний: содержимое синхронизируется из Confluence каждую ночь и используется консультантом для ответов на вопросы. У каждой базы свой агент; для него можно задать параметры генерации — температуру, top-p и top-k — и настройки внутреннего и внешнего поиска.

Температура и параметры выбора токенов управляют тем, насколько разнообразным будет продолжение ответа модели. Они не заменяют проверку фактов. За привязку ответа к регламентам отвечает поиск: консультант возвращает ссылки на материалы, учитывает подразделение и процесс, поддерживает разговор и при необходимости перенаправляет вопрос.

Четыре слоя системы и отдельный оркестратор

Чтобы разделить работу с интерфейсом, подготовку запроса, доступ к инструментам и хранение знаний, Авито построило систему из четырёх слоёв. Их связывает PortalManager: он получает сведения о текущем обращении и готовит конфигурацию агентов к исполнению.

При обращении бэкенд объединяет сведения о пользователе, сессии и проекте в контракт данных. PortalManager на его основе собирает агентскую конфигурацию; поиск, внешние инструменты и хранилища предоставляют ей необходимые сведения и действия. Так у каждой части системы остаётся понятная ответственность.

Почему для исполнения выбрали ADK

Для Авито было недостаточно библиотеки, позволяющей модели вызвать внешний API. При нескольких доменных помощниках нужно сохранять ход разговора, передавать инструменты и полномочия, вмешиваться в исполнение и понимать после ошибки, что произошло. В качестве агентной основы автор называет ADK — набор компонентов для запуска и управления агентами.

Важным аргументом стали три абстракции. Session хранит историю конкретного диалога; state — рабочее состояние агента и проекта; persistent memory — долговременные сведения о пользователе, которые могут пригодиться в следующих обращениях. Такое разделение помогает не смешивать текущий шаг с контекстом всего проекта и накопленными знаниями.

Также автор выделяет явный граф исполнения, поддержку MCP, callback-функции, согласование с человеком (human-in-the-loop approvals) и трассировку. Callback — возможность выполнить заданную проверку или действие в момент события рантайма, например перед обращением к модели. Approval — точка, в которой продолжение потенциально значимого действия может зависеть от решения человека. Трассировка сохраняет последовательность этапов для разбора поведения агента.

PortalManager собирает дерево агентов для каждого запроса

После получения подготовленного бэкендом контракта PortalManager не обращается к одной неизменной модели. Он собирает дерево доступных для запроса агентов, связывает их с нужным контекстом и выбирает модель отдельно для каждого узла. В статье различаются планировщик, которому важно понимать внутренние процессы Авито, и узкие доменные агенты, где подходят предварительно проверенные дистиллированные модели.

Дистилляция — обучение более компактной модели на примерах поведения другой модели. Для узких доменных задач автор предлагает использовать такие модели после проверки на соответствующих данных; планировщику же требуется понимание внутренних процессов Авито.

Подготовка на схеме исполнения включает загрузку агента, построение дерева, инициализацию сессии, подготовку трассировки и запуск Runner. Это работа PortalManager. Отдельный этап исполнения отвечает уже за решения языковой модели и вызовы инструментов. Благодаря этому доступный набор действий и состояние задаются системой, а не возникают из свободного текста ответа.

От вопроса до ответа: цикл ReAct внутри ADK Runner

ReAct — способ вести задачу по шагам: языковая модель учитывает доступные сведения, выбирает следующее действие, получает результат и решает, достаточно ли его для ответа. В отличие от заранее записанного маршрута из неизменных шагов, порядок обращения к инструментам выбирается моделью в пределах разрешённого набора.

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

PortalManager задаёт рамки работы: контекст, разрешённые инструменты, правила, состояние и трассировку. ADK Runner исполняет цикл, в котором LLM выбирает порядок шагов. Колбэки позволяют вмешиваться в отдельные этапы исполнения, а механизм approvals предусматривает согласование с человеком.

Почему workflow, агентный рантайм и coding-агент — разные вещи

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

Команде нужен был слой, объединяющий эти возможности. Workflow удобен, когда последовательность заранее известна; агентный SDK помогает управлять решениями LLM и её состоянием; корпоративная платформа связывает проекты, знания, владельцев, инструменты и проверку качества. Эту последнюю роль и выполняет «Виталик».

Почему RAG — не просто поиск по одному справочнику

Языковая модель сама по себе не знает, какая версия внутреннего регламента действует сегодня. Поэтому перед составлением ответа ей дают найденные фрагменты доступных корпоративных материалов. Этот подход называется RAG — генерация с опорой на предварительно найденные документы. Для «Виталика» он особенно важен: ответ должен учитывать не только общие знания о закупке, но и правила конкретного подразделения.

Разным документам нужна разная подготовка. PDF может содержать сложную вёрстку, Excel — таблицы с важными значениями, Confluence — инструкции, которые регулярно обновляются. Поэтому команда предусматривает несколько способов обработки документов и задаёт агентам инструкции по использованию этих материалов.

В работе RAG есть два потока. Сначала документы загружают, очищают и индексируют; когда приходит вопрос, система ищет подходящие фрагменты, собирает контекст и передаёт его модели. Подготовленный корпус знаний затем используется многократно.

Подготовка знаний: загрузка, обработка и индексирование

Сначала платформа получает доступные документы из PDF, Excel, Confluence и проектных файлов. Следом извлекает содержание, обрабатывает таблицы, использует запасной способ обработки при проблемах с основным парсером (fallback) и удаляет дубли. От корректности этого шага зависит, попадёт ли в поиск существенная часть регламента, а не отдельные обрывки текста.

Затем документы делятся на фрагменты — чанки; для них вычисляются числовые представления смысла, или эмбеддинги, и данные помещаются в Elasticsearch. Эмбеддинг помогает находить близкие по содержанию части текста, даже если запрос сформулирован другими словами. Благодаря разбиению поиск работает с отдельными положениями регламента, а не только с документом целиком.

Во время вопроса: найти, переранжировать и собрать контекст

Когда сотрудник спрашивает об оформлении закупки, поисковый компонент должен найти подходящие фрагменты из уже подготовленных источников. В статье перечислены векторный поиск, гибридный поиск и внутренний поиск. Гибридный подход сочетает смысловое сопоставление с поиском по словам; на схеме конвейера RAG прямо упомянуты плотные векторы и BM25, метод оценки текстового совпадения.

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

Далее система собирает для модели ограниченный набор выдержек. Токен — единица текста, которой оперирует LLM; объём входа ограничен числом таких единиц. Поэтому контекст собирают с учётом токен-бюджета, защиты от переполнения и ссылок на исходные материалы. Для закупки это могут быть регламент, сведения о поставщиках, прайс-листы и внутренние политики по ПО.

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

Проверка качества RAG, кэширование и границы результата

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

Кэширование фрагментов и эмбеддингов позволяет повторно использовать уже подготовленные данные и не выполнять одни и те же вычисления заново. Это одна из мер масштабирования RAG, на которые обращает внимание автор.

MCP Hub: как дать агентам инструменты, не перегружая PortalManager

Ответ с правильной ссылкой ещё не равен выполненному процессу. Чтобы перейти от консультации к действию, агенту нужны программные инструменты: прочитать запись из системы, получить сведения о поставщике, обратиться к согласованию. Авито выносит эти подключения в отдельный MCP Hub, чтобы PortalManager оставался оркестратором, а не набором прямых интеграций со всеми сервисами.

MCP — протокол, позволяющий представить функции внешнего сервиса как доступные агенту инструменты с описанными входами и выходами. «Единый контракт» здесь означает, что вызывающий агент знает, какие аргументы передать и какой результат ожидать, но не обязан знать устройство 1С или другого сервиса. Автор отдельно указывает владельцев функциональных возможностей, права доступа и трассировку вызовов.

Схема показывает несколько уровней: основной «Виталик» и доменные помощники корпоративного центра, HR и аналитики обращаются к общим функциональным возможностям. Среди них — шлюзы LLM и реранкера, слой навыков и агентов, MCP Hub и прямые MCP-серверы (на схеме — Exchange / EWS). Рядом показаны jira-mcp, локальные инструменты и колбэки.

В закупочном сценарии через такой слой агент может обратиться к интеграции 1С или внутреннему сервису согласования. Он знает контракт вызова, а не устройство подключённой системы. За подключением инструмента закрепляются владелец, права доступа и трассировка, поэтому новые возможности можно добавлять, не превращая PortalManager в набор отдельных интеграций.

Четыре направления оценки: от вызова функции до готового маршрута

Для перевода проекта в доменного агента недостаточно того, что он несколько раз красиво ответил в чате. Модель может верно сформулировать действие, но выбрать неподходящий инструмент; поисковик может найти похожий документ, но пропустить нужное правило; правильный аргумент вызова может обернуться ошибкой сервиса. Поэтому Авито разделяет проверки качества на четыре направления.

BFCL и tau2 — наборы задач для проверки того, как модель выбирает инструменты и формирует аргументы вызовов. Команда также использует ruBFCL — собственный перевод BFCL — и задачи на внутренних документах. Для доменных ответов применяется LLM-as-a-judge: языковая модель оценивает результат по заданным критериям вместе с эталонами и отзывами.

На схеме проверка организована через компоненты Data, Runner, Provider, Agent, Metrics и Opik. Эта цепочка связывает тестовые примеры с исполнением агента и сбором оценок, а четыре направления бенчмарков помогают увидеть, на каком этапе возникают ошибки.

Как это применяют к агенту корпоративного центра

Для консультанта корпоративного центра команда собрала эталонные пары «вопрос — ответ», в том числе о закупке ПО. Их можно использовать, чтобы проверить, не перепутал ли агент нужный регламент, верно ли определил адресата согласования и опирается ли на подходящие источники. Дополнительный сигнал — лайки и дизлайки сотрудников после ответов.

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

На схеме рядом с якорным кейсом указан target 85% — целевой ориентир проверки, а не достигнутая метрика Авито. Способ расчёта этого показателя на схеме не приведён.

Что ещё только планируется: длительные процессы и LLM-вики

Одна из следующих целей команды — научить агентов выполнять продолжительные процессы: писать код, создавать собственные инструменты, запускать цепочки действий и доводить их до результата. При этом обычные ответы на вопросы должны оставаться доступной частью работы «Виталика».

Ещё одно планируемое направление — внутренняя LLM-вики по идее Андрея Карпаты. Вместо повторного поиска по сырым документам модель сможет подготавливать страницы сущностей и понятий, краткие изложения, индекс и список противоречий. На новые вопросы агент будет собирать контекст из этой подготовленной базы знаний. На схеме вариант показан рядом с текущим RAG-конвейером.

Команда уже обучает собственные модели под русский язык и специфику задач Авито. По словам автора, это помогает улучшать качество и безопасность, а также скорость работы на внутренних задачах. Такая работа над моделями идёт параллельно с планами по долгим процессам и LLM-вики.

Команда также ищет новые проекты и инструменты, которые можно подключать как функциональные возможности платформы. Это продолжает путь от полезного сценария внутри команды к специализированному агенту в общей экосистеме.

Дерево процессов — целевая архитектура, не список завершённых запусков

Автор описывает общее устройство как дерево: в корне «Виталик», ниже крупные подразделения, а на концах отдельные процессы. Каждому процессу нужны свои знания, доступные инструменты, инструкция агенту и набор проверок. Общая точка входа должна понимать, к какой ветке направить вопрос, чтобы сотрудник не выбирал десятки внутренних чатов вручную.

На схеме целевого дерева агентов с пометкой «Grand Vision» видны направления Legal, Finance, PMO, Procurement, Analytics и Operations. Ветви иллюстрируют задачи от проверки договора или подготовки материалов до финансового согласования, маршрута закупки и аналитической сводки. Подпись схемы подчёркивает цель: дерево проверенных агентов по функциям и процессам, а не один универсальный чат.

Что нельзя заключить из опубликованной архитектуры

Статья посвящена устройству корпоративной платформы и инженерным причинам её выбора. Автор показывает, как вместе работают проекты, поиск, оркестрация, инструменты и бенчмарки; сравнительных экспериментов ADK с другими агентными SDK или RAG-подходов между собой в материале нет.

Количественных результатов внедрения автор не приводит: не опубликованы баллы четырёх групп бенчмарков, задержки, нагрузка, доля завершённых процессов и измеренная экономия времени. Числа из закупочного сценария остаются оценкой и целевым ориентиром, target 85% — целью на схеме, а проценты McKinsey и MIT во введении относятся к внешней статистике, а не к результатам Авито.

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

Итог: как «Виталик» связывает вопрос с корпоративным процессом

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

Подготовка документов и поискового индекса выполняется отдельно от этого пути. Отдельно живёт и оценка качества: Авито различает вызовы функций, поиск, исполнение инструментов и проверку доменного процесса по эталонам и отзывам сотрудников. Автор описывает консультанта корпоративного центра и такую архитектуру, но нет опубликованных численных результатов бенчмарков.

Поэтому «30 минут → пара минут» следует читать как иллюстрацию ожидаемой пользы, а 85% на схеме — как цель, не достигнутую метрику. Долгие процессы и самостоятельно поддерживаемая LLM-вики обозначены планами; собственные модели уже обучают, но без измерений в публикации. Главная инженерная идея кейса — соединить управляемый жизненный цикл проектов, поиск по корпоративным знаниям, ограниченный набор действий и проверку всей траектории агента.