Enterprise RAG Challenge 3: уроки из публичных решений

Viacheslav Dubrov

2026-01-11 · Обновлено 2026-07-15 · 9 мин · ИИ-агенты

Автоматический перевод Эта статья была автоматически переведена с оригинальной английской версии.

Enterprise RAG Challenge 3 (ERC3) предложил ИИ-агентам выполнять бизнес-задачи через API симулированной компании. Зафиксированный призовой лидерборд особенно полезен: многие участники опубликовали не только результат, но и архитектуру, набор моделей, стоимость и разбор ошибок.

Я изучил эти публичные описания, чтобы ответить на более узкий вопрос: какие проектные решения повторялись в сильных работах и какие из них применимы за пределами этого бенчмарка?

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

Коротко: единой выигрышной топологии не было. Сильные решения варьировались от простого агента с tool calls до пайплайнов со специалистами и систем plan-execute. Но несколько идей повторялись: учиться на ошибочных трейсах, валидировать рискованные шаги как можно ближе к моменту исполнения, явно задавать политику работы с контекстом и скрывать особенности API — например, пагинацию — за надёжными обёртками. Production-промпт победителя конкурса был его 80-й автоматически сгенерированной версией.

Что такое Enterprise RAG Challenge?

Enterprise RAG Challenge 3 — это крупный краудсорсинговый исследовательский проект, проверяющий, как автономные ИИ-агенты справляются со сложными бизнес-задачами. В отличие от статических бенчмарков, ERC3 работает на базе Agentic Enterprise Simulation (AGES) — дискретно-событийной симуляции, которая предоставляет реалистичный enterprise API.

Что проверяет бенчмарк

В AGES агенты работают внутри вымышленной компании, в которой есть:

• Профили сотрудников с конкретными навыками и подразделениями
• Проекты с назначенными командами и отношениями с заказчиками
• Корпоративная wiki с бизнес-правилами и иерархией разрешений
• Учёт времени и финансовые операции

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

Считайте результаты снимком состояния

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

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

Типы задач

Задачи охватывают несколько областей:

• Мультихоповый ризонинг, например сопоставление навыков сотрудников с назначениями в проектах.
• Проверка разрешений, например блокировка неавторизованных изменений зарплат или доступа к данным.
• Неоднозначные запросы, включая многоязычные и перефразированные формулировки.
• Строгое соблюдение формата ответа, включая обязательные ссылки на сущности.

Что на самом деле показывают решения

Публичные описания не позволяют сделать простой вывод вроде «multi-agent лучше single-agent». Решение, занявшее четвёртое место в призовом зачёте, представляло собой явно простую архитектуру с одним агентом. Однако из материалов следуют четыре более узких наблюдения:

1. Декомпозиция помогала, когда изолировала известную границу отказа. Команды разделяли проверки разрешений, валидацию шагов, исполнение кода или форматирование ответа, а не создавали произвольные «роли агентов».
2. Валидация смещалась ближе к необратимым действиям. Несколько систем проверяли разрешения перед исполнением, проверяли отдельные шаги или защищали финальный ответ.
3. Итерации на основе трейсов имели значение. Победитель превращал неудачные запуски в ревизии промпта через автоматизированный цикл; другие команды также описывали конкретные исправления инструментов и промптов.
4. Политика работы с контекстом была архитектурным решением. Команды пробовали дистилляцию, предварительную загрузку, retrieval и сжатие истории. Их собственные отчёты расходятся в вопросе, помогало ли сжатие, поэтому универсального рецепта нет.

Пять показательных подходов

Это не пять лучших решений в порядке мест. Я выбрал их потому, что публичные описания демонстрируют пять разных способов построения системы: автоматическую ревизию промптов, специализированные стадии, валидацию каждого шага, защиту ответа и изоляцию plan-execute. Там, где я объясняю, почему решение могло помочь, я обозначаю это как интерпретацию, а не как вывод из лидерборда.

1. Эволюционный промпт-инжиниринг (команда VZS9FL / @aostrikov)

Подход с самым высоким результатом автоматизировал промпт-инжиниринг через цикл самоулучшения.

Вместо ручной настройки production-промпта команда построила цикл из трёх агентов, который превращал неудачные трейсы в кандидаты на ревизию.

Пайплайн из трёх агентов:

Production-промпт был 80-й автоматически сгенерированной версией. Команда описывает цикл так: анализировать неудачные задачи, предлагать причины и решать, какие рекомендации включить. Лидерборд подтверждает финальный результат и количество итераций, но не позволяет отделить вклад автоматизации от вклада моделей, инструментов и накопленной обратной связи по бенчмарку.

Стек: claude-opus-4.5 with Anthropic Python SDK и нативный Tool Use.

2. Последовательный мультиагентный пайплайн (команда Lcnxuy / @andrey_aiweapps)

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

Задокументированные компоненты:

1. Security Gate Agent: проверка перед исполнением, которая сверяет разрешения с правилами wiki до запуска основного цикла.
2. Context Extraction Agent: извлекает критически важные правила из объёмных промптов и предварительно загружает данные о пользователе, проекте и заказчике.
3. Execution Agent: планирование в стиле ReAct с пятью внутренними фазами (Identity → Threat Detection → Info Gathering → Access Validation → Execution).
4. LinkGeneratorAgent: встроен в response tool, разбирает контекст и добавляет обязательные ссылки на сущности.

LinkGeneratorAgent — наиболее переносимая часть решения. Его размещение внутри response tool превращает требование бенчмарка — обязательные ссылки на сущности — в свойство интерфейса, а не в ещё одну инструкцию, которую execution-модель может забыть.

Стек: фреймворки atomic-agents и instructor с gpt-5.1-codex-max, gpt-4.1 и claude-sonnet-4.5.

3. Ризонинг под управлением схемы с валидацией шагов (команда NLN7Dw / Ilia Ris)

Эта команда объединила SGR с быстрым инференсом и валидатором каждого предложенного шага. Такое решение удешевляет исправления: ошибочный шаг отклоняется до того, как становится tool call, после чего основной поток получает комментарии валидатора и перерабатывает его.

Ключевые компоненты:

Команда сообщила о запуске gpt-oss-120b на Cerebras со скоростью до примерно 3 000 токенов в секунду. Валидация сочеталась с высокопроизводительным инференсом, что могло снизить её стоимость по латентности. Публичный результат не позволяет изолировать этот эффект.

Стек: gpt-oss-120b on Cerebras с кастомизированной реализацией SGR NextStep.

4. Система enrichers и гардрейлов (команда J8Gvbi / @mishka)

В этом решении к базе на SGR добавили неблокирующие подсказки и многоуровневую систему гардрейлов. По мере поступления ответов API enrichers анализировали их и добавляли операционные рекомендации в последующий контекст.

Более 20 enrichers анализировали ответы API и добавляли контекстные подсказки:

RoleEnricher: "You are LEAD of this project, proceed with update."
PaginationHintEnricher: "next_offset=5 means MORE results! MUST paginate."

Трёхрежимная система гардрейлов:

Гибридный RAG для wiki: три потока поиска — regex, semantic и keyword — покрывали разные типы запросов к wiki компании.

Стек: qwen/qwen3-235b-a22b-2507 на SGR-фреймворке LangChain.

5. Plan-execute REPL (команда key_concept_parallel)

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

Разные модели выполняли разные задачи: одна планировала, другая писала Python, а отдельная decision-модель выбирала дальнейшее действие после каждого шага.

Мультимодельная конфигурация:

REPL завершения шага:

1. Planner создаёт высокоуровневый шаг.
2. Code-gen-модель работает в новом модельном контексте и пишет для него Python-скрипт.
3. Скрипт выполняется в REPL, привязанном к задаче; переменные сохраняются между шагами.
4. Decision-модель анализирует результат и выбирает действие: продолжить, прервать или перепланировать.

Именно ветка replanning представляет наибольший практический интерес. Если шаг частично завершился ошибкой, decision-модель может сохранить выполненную работу и переписать только оставшуюся часть плана.

Повторяющиеся паттерны в решениях

Реализации различались, но в публичных описаниях снова и снова встречались одни и те же инженерные проблемы.

Управление контекстом было явной политикой

Ни одна команда не могла передавать модели все правила, записи и предыдущие шаги, не сделав выбор политики. Интересно было то, где именно каждая система фильтровала информацию.

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

Гардрейлы размещались на разных границах отказа

Несколько команд размещали проверки до, во время или после основного цикла. Эти механизмы решали разные задачи и не должны сводиться к одному абстрактному «critic agent».

Обёртки над инструментами

Несколько команд построили абстракции поверх исходного API:

• Автоматическая пагинация: обёртки проходят по всем страницам и возвращают полный датасет.
• Нечёткая нормализация: «готовность к командировкам» преобразуется в поле API will_travel.
• Специализированные инструменты для ризонинга: инструменты think, plan и critic для контролируемого рассуждения.

Режимы отказа и структурные исправления, о которых сообщили команды

В описаниях решений неоднократно упоминаются ошибки на границах API и политик. Наиболее переносимые исправления перемещали требование в код или в отдельный шаг валидации:

Практический порядок внедрения

ERC3 — это одна симулированная компания, а не общее исследование абляций агентных систем. Используйте его как источник дизайн-гипотез, а затем проверяйте эти гипотезы на собственных трейсах. Разумный порядок внедрения:

1. Сначала сделайте корректность API детерминированной. Добавьте автоматическую пагинацию для list endpoints, нормализацию нечётких полей, валидацию схем и генерацию обязательных ссылок внутри response tool.
2. Добавьте проверки на реальных границах риска. Проверяйте identity и permission перед мутацией; валидируйте шаг до исполнения только в том случае, если дополнительный вызов модели выявляет ошибки, стоимость которых оправдывает затраты.
3. Зафиксируйте политику работы с контекстом. Определите, что предварительно загружается, извлекается через retrieval, сжимается или сохраняется без изменений. Оценивайте эту политику по срезам задач, а не только по числу токенов.
4. Превращайте неудачные трейсы в регрессионные кейсы. Классифицируйте ошибку, меняйте один механизм и повторно запускайте затронутый срез. Автоматизируйте ревизию промптов только после того, как этот цикл станет надёжным.
5. Декомпозируйте систему, когда границы ответственности становятся яснее. Отдельный компонент оправдан, если он может владеть ограничением, использовать другую модель или инструмент либо тестироваться независимо, а не просто потому, что «multi-agent» звучит мощнее.

Судя по этим описаниям, надёжные решения делали скрытые операционные требования явными — в инструментах, валидаторах и циклах эвалуации.

Источники

• Enterprise RAG Challenge 3 — официальный сайт
• Лидерборды ERC3
• Бенчмарк: erc3-prod
• Примечания к релизу