Как мы строим AI-агента над сервисами Яндекс 360: RAG, MCP и скиллы

Алиса Про помогает работать с корпоративными данными в сервисах Яндекс 360. Пользователь может попросить найти переписку, собрать информацию из писем и документов, подготовить ответ или выполнить действие в рабочем сервисе. За таким запросом стоит цепочка из классификации, поиска, чанкинга, rerank, генерации, MCP-инструментов и проверки прав доступа.

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

В докладе отвечу на пять вопросов.

1. Как устроить полный путь запроса от текста пользователя до ответа или действия? Покажу production-пайплайн Алисы Про. Классификатор определяет сценарий, агент выбирает источники, получает документы с учётом прав пользователя, режет их на чанки, запускает поиск и rerank, собирает контекст и вызывает генератор. Для многошаговых задач агент получает через MCP инструменты Почты, Диска, Календаря и других сервисов. Скиллы задают последовательность шагов, ограничения и точки подтверждения человеком.

2. Как запустить такой пайплайн на миллионы пользователей и не потратить лишние GPU? Общая ресурсная модель Алисы Про рассчитана на 4,38 млн MAU, 2,76 млн DAU и 100 RPS. Standalone создаёт до 1050 RPS на backend, но маршрутизация пропускает в модельный контур только 7,5 RPS. Виджет рассчитан на 2,98 млн MAU, 2,16 млн DAU и 80 RPS. Около 78 RPS приходится на сценарии с поиском по письмам и файлам. Текущий контур использует 15 H100 и 15 V100. Мы ограничиваем число кандидатов, запускаем дорогие модели только для подходящих сценариев и объединяем слабо загруженные пулы. Покажу, как из профиля трафика получить ресурсную модель и найти в ней лишние карты.

3. Как искать по корпоративной почте с приемлемым качеством и стоимостью? Запрос превращается в фильтры по датам, отправителям и типам писем. После этого работают лексическая и векторная ветки, fallback и BGE-rerank. На один запрос приходится до 192 кандидатов, при плановой нагрузке это около 15 тыс. кандидатов в секунду. Rerank обрабатывает их тремя параллельными батчами по 64. На валидационном срезе за 15 августа 2026 года поиск нашёл хотя бы один релевантный документ в 91,9% запросов. Совместный контур поиска и ретрива сохранил релевантный источник в 89,1% запросов.

4. Как дать агенту доступ к рабочим сервисам и сохранить контроль над его действиями? Каждый MCP-инструмент имеет ограниченный контракт, передаёт авторизацию исходной системы и повторно проверяет права пользователя. Доступные действия ограничиваются allow-list, на число шагов и tool calls ставятся бюджеты, изменения журналируются, опасные операции требуют подтверждения. MCP-шлюз рассчитан на 50 RPS при запуске и рост до 100 RPS, лимит одного пользователя составляет 5 RPS. Покажу, как считать fan-out, когда один пользовательский запрос вызывает несколько инструментов.

5. Как понять, где агент ошибся? Мы отдельно оцениваем классификацию, поиск, сборку контекста, выбор MCP-инструмента, параметры tool call и финальный ответ. Средняя нормированная self-assessment-оценка ответа на том же срезе составила 78,8%, доля ненулевых оценок 84,1%. Такое разложение показывает конкретную причину ошибки и помогает выбрать исправление для нужной стадии.

Слушатели получат схему production-архитектуры корпоративного агента, способ расчёта нагрузки на поиск, MCP и модельный контур, подход к оценке GPU-потребности и набор метрик для раздельной проверки поиска, инструментов и ответа. Эти решения можно использовать при проектировании собственного RAG или MCP-агента над корпоративными данными.