Автоматический перевод
Эта статья была автоматически переведена с оригинальной английской версии.
Enterprise RAG Challenge 3 (ECR3): Побеждающие архитектуры AI-агентов
Enterprise RAG Challenge 3 (ECR3) только что завершился. 524 команды, более 341,000 запусков агентов, и лишь 0.4% команд получили идеальный балл. Теперь, когда лидерборд и разборы решений стали публичными, я изучил победившие подходы, чтобы понять, что топ-команды делали иначе.
В этом посте разберем, что такое ECR3, как выглядели задачи и какие паттерны снова и снова встречались в рабочих архитектурах.
Кратко: мультиагентные пайплайны обошли монолитные. Команда-победитель использовала эволюционную prompt engineering через 80+ автоматизированных итераций. Победители вложили много усилий в guardrails (предварительные проверки безопасности, валидаторы внутри цикла, пост-исполнительные защиты) и в стратегию работы с контекстом. Важнее было не количество контекста, а его состав.
Что такое Enterprise RAG Challenge?
Enterprise RAG Challenge 3 — это крупномасштабный краудсорсинговый исследовательский проект, который проверяет, как автономные AI-агенты справляются со сложными бизнес-задачами. В отличие от статических бенчмарков, ECR3 работает поверх Agentic Enterprise Simulation (AGES) — дискретно-событийной симуляции, которая предоставляет реалистичный enterprise API.
Почему ECR3 важен
Через AGES агенты работают внутри фиктивной компании, в которой есть:
- Профили сотрудников с конкретными навыками и отделами
- Проекты с назначениями команд и отношениями с клиентами
- Корпоративная wiki с бизнес-правилами и иерархиями разрешений
- Учет времени и финансовые операции
Для каждой задачи поднимается отдельная симуляция с новыми данными, поэтому агент не может ничего запоминать между запусками.
Порог сложности
Лидерборд очень жесткий:
| Метрика | Значение |
|---|---|
| Зарегистрированные команды | 524 |
| Всего запусков агентов | 341,000+ |
| Доступные задачи | 103 уникальные бизнес-задачи |
| Идеальный балл (100.0) | Только 0.4% команд |
| Балл ≥ 0.9 | Только 1.1% команд |
Типы задач
Задачи охватывают несколько областей навыков:
- Multi-hop reasoning: кросс-сопоставление навыков сотрудников с назначениями на проекты
- Проверка разрешений: предотвращение несанкционированных изменений зарплаты или доступа к данным
- Неоднозначные запросы: обработка многоязычных и перефразированных пользовательских запросов
- Строгое соблюдение формата вывода: обязательное включение ссылок на сущности в ответ
Что на самом деле побеждало
В верхней части лидерборда постоянно повторялись четыре паттерна:
- Мультиагентные пайплайны обошли монолитных агентов. Разделение задачи работало лучше, чем один большой агент, пытающийся делать все сразу.
- Чем автономнее агент, тем жестче должны быть ограничения. Guardrails не были второстепенной деталью.
- Автоматизированная эволюция промптов обошла ручную настройку. Лучшие промпты проходили через 80+ поколений.
- Стратегия контекста делала основную часть работы. Не больше контекста, а правильный контекст.
Лучшие победившие подходы
Пять архитектур ниже идут в очень разных направлениях — от полностью автоматизированной эволюции промптов до гибридного retrieval. У каждой есть идеи, которые стоит заимствовать.
1. Эволюционная prompt engineering (команда VZS9FL / @aostrikov)
Подход с самым высоким баллом автоматизировал prompt engineering через цикл самоулучшения.
Вместо ручной настройки промптов команда собрала цикл из трех агентов, который позволяет агенту учиться на собственных ошибках.
Пайплайн из трех агентов:
| Агент | Роль |
|---|---|
| Main Agent | Запускает бенчмарк, логирует все действия и сбои |
| Analyzer Agent | Анализирует проваленные задачи, формулирует гипотезы о корневых причинах |
| Versioner Agent | Генерирует новую версию промпта с учетом полученных выводов |
Результат: production-промпт был 80-й автоматически сгенерированной версией. Каждая версия исправляла конкретный паттерн ошибок, проявившийся в логах предыдущего прогона. Большинство из них — это те edge cases, которые замечаешь только после часа просмотра неудачного trace.
Стек: claude-opus-4.5 с Anthropic Python SDK и нативным Tool Use.
2. Последовательный мультиагентный пайплайн (команда Lcnxuy / @andrey_aiweapps)
Здесь отказались от монолитного агента и собрали последовательный пайплайн из специалистов, каждый из которых достаточно мал, чтобы действительно хорошо делать свою работу.
4-этапный пайплайн:
- Security Gate Agent: предварительная проверка перед исполнением, которая валидирует разрешения по правилам wiki до запуска основного цикла.
- Context Extraction Agent: извлекает критически важные правила из больших промптов и заранее загружает данные о пользователе, проекте и клиенте.
- Execution Agent: ReAct-подобное планирование с 5 внутренними фазами (Identity → Threat Detection → Info Gathering → Access Validation → Execution).
- LinkGeneratorAgent: встроен в response tool, парсит контекст и добавляет обязательные ссылки на сущности.
Интереснее всего здесь LinkGenerator agent. Он исправлял один из самых частых режимов отказа: агент дает правильный ответ, но забывает обязательные reference links.
Стек: фреймворки atomic-agents и instructor с gpt-5.1-codex-max, gpt-4.1 и claude-sonnet-4.5.
3. Schema-guided reasoning с валидацией шагов (команда NLN7Dw / Ilia Ris)
Эта команда объединила SGR, очень быструю инференс-обработку и валидатор в реальном времени. Ставка была такой: много быстрых, валидированных решений лучше одного медленного, долго обдуманного ответа.
Ключевые компоненты:
| Компонент | Функция |
|---|---|
| StepValidator | Проверяет каждый предложенный шаг. Если что-то не так, отправляет его на доработку с комментариями. |
| Context Management | Полный план с предыдущего хода плюс сжатая история для более старых ходов |
| Dynamic Enrichment | Автоматически подтягивает профиль пользователя, проекты, клиентов; LLM фильтрует и добавляет только данные, релевантные задаче |
| Auto-pagination Wrappers | Все list endpoints автоматически возвращают полные результаты |
Преимущество по скорости идет от запуска на Cerebras со скоростью примерно 3,000 токенов/секунду. При таком темпе агент может позволить себе переосмыслить шаг, а не фиксироваться на медленном первом ответе более тяжелой модели.
Стек: gpt-oss-120b на Cerebras с кастомизированной реализацией SGR NextStep.
4. Система enrichers и guard (команда J8Gvbi / @mishka)
Здесь к базовой SGR-архитектуре добавили неблокирующие «умные подсказки» и многоуровневую guard-систему. Когда приходят ответы API, enrichers анализируют их и тихо подсказывают агенту, на что обратить внимание.
Система enrichers:
Более 20 enrichers анализировали ответы API и внедряли контекстные подсказки:
RoleEnricher: "You are LEAD of this project, proceed with update."
PaginationHintEnricher: "next_offset=5 means MORE results! MUST paginate."
Система guard в трех режимах:
| Режим | Поведение |
|---|---|
| Hard block | Невозможные действия блокируются навсегда |
| Soft block | Рискованные действия блокируются при первой попытке, но разрешаются при повторе |
| Soft hint | Подсказка без блокировки |
Гибридный RAG по wiki: три поисковых потока (regex, semantic, keyword), работающие параллельно, где для каждого типа запроса побеждает лучший.
Стек: qwen/qwen3-235b-a22b-2507 на SGR-фреймворке LangChain.
5. Plan-execute REPL (команда key_concept_parallel)
Эта архитектура жестко разделяет планирование и исполнение и использует цикл с генерацией кода. По сути это REPL: агент планирует шаг, генерирует код, выполняет его и решает, что делать дальше.
Разные модели для разных задач: planner строит план, code-gen model пишет Python, а меньшая decision model решает, что делать после каждого шага.
Мультимодельная конфигурация:
| Этап | Модель |
|---|---|
| Планирование | openai/gpt-5.1 |
| Генерация кода | deepseek/deepseek-v3.2 |
| Решение после шага | openai/gpt-4.1 |
| Финальный ответ | openai/gpt-4.1 |
REPL завершения шага:
- Planner создает шаг верхнего уровня.
- Code-gen model пишет для него Python-скрипт.
- Скрипт выполняется в изолированном контексте.
- Decision model смотрит на результат и выбирает: продолжать, остановиться или перепланировать.
Ветка перепланирования — именно то место, где эта архитектура особенно полезна. Когда шаг частично проваливается, decision model может переписать остаток плана, а не продолжать сломанный сценарий.
Паттерны, которые встречались везде
Помимо отдельных архитектур, почти через все топовые решения проходили несколько общих практик.
Управление контекстом делало основную часть работы
Топ-команды поняли, что качество контекста — это потолок качества работы агента.
| Стратегия | Подход | Лучше всего подходит для |
|---|---|---|
| Rule Distillation | Предобработка wiki через LLM в ~320-токенный summary | Компактных промптов, быстрого старта |
| Aggressive Preloading | Загрузка данных о пользователе/проекте/клиенте до начала исполнения | Минимизации вызовов инструментов |
| Hybrid RAG | Потоки поиска regex + semantic + keyword | Сложных retrieval-задач |
| History Compression | Последние ходы хранятся полностью, более старая история сжимается | Длинных диалогов |
Компромисс: команды Kc7F2N и f1Uixf обнаружили, что качество контекста важнее объема. Команда f1Uixf даже увидела, что compression истории ухудшает результат, поэтому оставила полную историю и вместо этого опиралась на long-context models.
Guardrails: чем автономнее агент, тем сильнее они нужны
Агенты с самыми высокими баллами также были окружены самыми строгими ограничениями. Это звучит парадоксально, но так не кажется, если посмотреть на механизм. У автономного агента больше способов ошибиться, значит, ему нужно больше точек, где его можно остановить.
| Тип guardrail | Когда | Пример |
|---|---|---|
| Pre-Execution Gates | До запуска основного цикла | Security Gate Agent валидирует разрешения по правилам wiki |
| In-Loop Validators | Во время рассуждения | StepValidator проверяет каждое предложенное действие и отправляет на доработку при ошибке |
| Post-Execution Guards | Перед финальной отправкой | Three-Mode Guard System валидирует полноту ответа |
Умные обертки над инструментами
Топ-команды строили слои абстракции поверх сырого API:
- Auto-pagination: обертки проходят по всем страницам и возвращают полный датасет.
- Fuzzy normalization: «Willingness to travel» преобразуется в поле API
will_travel. - Specialized reasoning tools: инструменты
think,planиcriticдля контролируемого рассуждения.
Общие режимы отказа и как победители их исправляли
Даже у лучших агентов были одинаковые слепые зоны. Исправления были архитектурными, а не промптовыми:
| Режим отказа | Описание | Архитектурное исправление |
|---|---|---|
| Permission Bypass | Выполнение ограниченных действий без проверки разрешений пользователя | Pre-execution Security Gate Agent; обязательная последовательность Identity → Permissions → Execution |
| Missing Entity Links | Текст ответа корректный, но отсутствуют обязательные reference links | Встроенный LinkGeneratorAgent в response tool |
| Pagination Exhaustion | Обработка только первой страницы результатов list-запроса | Auto-pagination wrappers для всех list endpoints |
| Tool-Calling Loops | Зацикливание на повторных вызовах одного и того же инструмента с небольшими вариациями | Ограничения на число ходов; reasoning-focused models (Qwen3) |
| Context Overloading | Заполнение контекста нерелевантными разделами wiki | Rule distillation; динамическая фильтрация контекста |
Что из этого стоит вынести
Если вы строите агентов и хотите применить это на практике:
- Используйте мультиагентные пайплайны. Монолитные агенты проиграли. Топ-команды использовали 3–5 специалистов для безопасности, извлечения контекста, планирования и исполнения.
- Автоматизируйте итерацию промптов. Победивший промпт был версией 80. Цикл найдет паттерны отказов, которые вы бы сами не заметили.
- Вкладывайтесь в guardrails всерьез. Предварительные проверки безопасности, критики внутри цикла и защиты после исполнения. Самые автономные на вид агенты были сильнее всего ограничены.
- Делайте обертки над инструментами. Pagination, обогащение данных и fuzzy matching должны жить в wrappers. Одна команда построила 20+ enrichers, которые в реальном времени отслеживали ответы API.
- Серьезно относитесь к стратегии контекста. Rule distillation (~320-токенные summary), preloading и динамическая фильтрация. Скорость тоже помогает. Одна команда работала на ~3,000 токенов/секунду и могла часто перепланировать.