2026-01-11 · Обновлено 2026-07-15

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

Профессиональный вызов RAG 3 (ECR3): Создание эффективных ИИ-агент архитектур

В рамках задачи Enterprise RAG Challenge 3 (ECR3) от участников требовалось выполнять бизнес-задачи в условиях симулированной компании API. Особую пользу приносит зафиксированный список лидеров, поскольку многие участники публиковали не только свои оценки, но и информацию об архитектуре решений, модель составе компонентов, затратах и причинах возникновения сбоев.

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

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

Что такое вызовы, связанные с корпоративными RAG системами?

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

Что тестирует бенчмарк

Через AGES агенты работают внутри фиктивной компании, которая имеет:

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

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

Читайте значения как снапшот

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

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

Типы задач

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

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

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

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

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

Пять информативных подходов

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

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

Этот метод с наивыским баллом оценки Автоматизация промпт-инжиниринг с использованием цикла самосовершенствования.

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

Трёхагентный пайплайн:

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

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

2. Multi-agent последовательные пайплайн (Команда Lcnxuy / @andrey_aiweapps)

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

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

1. Агент брандмауэра безопасности: модуль предварительной проверки, который определяет наличие разрешений согласно правилам вики ещё до запуска основного цикла обработки.
2. Агент извлечения контекста: отвечает за извлечение ключевых правил из объёмных промпты и заранее загружает данные о пользователе, проекте и клиенте.
3. Агент выполнения: механизм в стиле ReAct с использованием планирование, включающий 5 внутренних этапов — идентификация → обнаружение угроз → сбор информации → верификация доступа → выполнение.
4. LinkGeneratorAgent: компонент, встроенный в инструмент генерации ответов, который анализирует контекст с целью включения необходимых ссылок на сущности.

Агент LinkGenerator является наиболее переносимым компонентом всей системы. Размещение его внутри инструмента генерации ответов превращает требование бенчмарк — обязательная привязка сущностей — из отдельной инструкции, которую процесс выполнения модель может проигнорировать, в неотъемлемое свойство самого интерфейса.

Стек: atomic-agents и instructor фреймворки с использованием моделей gpt-5.1-codex-max, gpt-4.1 и claude-sonnet-4.5.

3. Работа с ризонинг под руководством схемы с пошаговой верификацией (Команда NLN7Dw / Илия Рис)

Эта команда сочетала SGR с высокоскоростным инференс, а также валидатором на каждом этапе разработки. Благодаря такой архитектуре внесение правок происходит легко: недостаточные этапы отклоняются ещё до того, как они превратятся в tool call, после чего основной поток обработки запрашивает их переработку с учётом замечаний валидатора.

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

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

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

4. Система обогащения данных и защиты (Команда J8Gvbi / @mishka)

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

Система обогащения данных:

Более чем 20 модулей обогащения данных были проанализированы ответы API, и в них были внесены контекстуальные подсказки:

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

Система защиты с тремя режимами:

Гибридная вики RAG: три потока поиска — регулярные выражения, семантический анализ и поиск по ключевым словам — обрабатывают различные формы запросов в корпоративной вики.

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

5. Механизм планирования и выполнения REPL (команда key_concept_parallel)

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

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

Настройка с несколькими модель:

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

1. Планировщик формирует высокоуровневый шаг обработки.
2. Процесс генерации кода с помощью модель выполняется в чистом контексте модель и результатом становится соответствующий скрипт на Python.
3. Скрипт запускается в REPL с ограничением по задаче, где переменные сохраняются между шагами.
4. Механизм принятия решений модель анализирует полученный результат и выбирает один из вариантов: продолжить выполнение, прервать процесс или изменить план действий.

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

Шаблоны, повторявшиеся во всех представленных работах

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

Управление контекстом осуществлялось явно

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

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

Гардрейлы были размещены в разных границах сбоев

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

Умные обертки инструментов

Несколько команд создали слои абстракции над необработанным API:

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

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

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

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

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

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

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

Список литературы

• Enterprise RAG Challenge 3 — официальный сайт
• Таблицы лидеров ECR3
• Бенчмарк: erc3-prod
• Заметки к выпуску