Desafio Enterprise RAG 3: lições das submissões públicas

Viacheslav Dubrov

2026-01-11 · Atualizado 2026-07-15 · 11 min · Agentes de IA

Tradução automática Este artigo foi traduzido automaticamente a partir da versão original em inglês.

O Enterprise RAG Challenge 3 (ERC3) pediu a agentes que concluíssem tarefas empresariais através da API de uma empresa simulada. A tabela de classificação congelada é particularmente útil porque muitos participantes publicaram mais do que uma pontuação: arquitetura, combinação de modelos, custo e notas sobre falhas.

Analisei essas descrições públicas para responder a uma pergunta mais específica: que escolhas de design se repetiram nas submissões fortes e quais são úteis fora deste benchmark?

No final, deverá conseguir transformar estas observações em hipóteses de design para os seus próprios traces de agentes e testá-las com base na sua combinação de tarefas e nos custos das falhas.

Em resumo: não houve uma topologia vencedora única. As submissões fortes variaram entre um agente simples com tool-calling e pipelines especializados e sistemas plan-execute. As ideias recorrentes foram mais específicas: aprender com traces falhados, validar passos de risco perto do ponto de execução, tornar explícita a política de contexto e ocultar perigos da API, como a paginação, através de wrappers fiáveis. O prompt de produção do vencedor foi a sua 80.ª versão gerada automaticamente.

O que é o Enterprise RAG Challenge?

O Enterprise RAG Challenge 3 é um projeto de investigação de grande escala e crowdsourced que testa a forma como agentes AI autónomos lidam com tarefas empresariais complexas. Ao contrário dos benchmarks estáticos, o ERC3 funciona sobre o Agentic Enterprise Simulation (AGES), uma simulação de eventos discretos que disponibiliza uma API empresarial realista.

O que o benchmark testa

Através do AGES, os agentes trabalham dentro de uma empresa fictícia que inclui:

• Perfis de colaboradores com competências e departamentos específicos
• Projetos com atribuições de equipas e relações com clientes
• Wiki empresarial com regras de negócio e hierarquias de permissões
• Registo de horas e operações financeiras

Cada tarefa inicia uma simulação isolada. A wiki da empresa é partilhada, mas os registos operacionais variam consoante a tarefa, pelo que um agente não consegue resolver o conjunto memorizando o estado de uma única empresa.

Leia as pontuações como um instantâneo

O ERC3 disponibiliza agora tanto uma tabela de classificação congelada da competição como um benchmark público que continuou a receber execuções após o evento. Estas páginas respondem a perguntas diferentes. Os valores abaixo descrevem a tabela de classificação dos prémios no momento de encerramento da competição, e não as sessões posteriores com melhor desempenho:

A página do benchmark em direto pode apresentar pontuações superiores porque inclui execuções posteriores. Por isso, a tabela congelada é a fonte adequada para afirmações sobre o que venceu a competição.

Tipos de tarefas

As tarefas abrangem várias áreas de competência:

• Raciocínio multi-hop, como associar competências de colaboradores a atribuições em projetos.
• Validação de permissões, como bloquear alterações não autorizadas a salários ou acessos a dados.
• Consultas ambíguas, incluindo pedidos multilingues e paráfrases.
• Conformidade rigorosa do output, incluindo links obrigatórios para entidades nas respostas.

O que as submissões sugerem realmente

As descrições públicas não sustentam uma conclusão simples como “multi-agent supera single-agent”. A submissão que ficou em quarto lugar nos prémios era explicitamente um design simples de single-agent. No entanto, sustentam quatro observações mais específicas:

1. A decomposição foi útil quando isolou uma fronteira de falha conhecida. As equipas separaram verificações de permissões, validação de passos, execução de código ou formatação de respostas — e não “papéis de agentes” arbitrários.
2. A validação aproximou-se das ações irreversíveis. Vários sistemas verificavam permissões antes da execução, analisavam passos individuais ou protegiam a resposta final.
3. A iteração orientada por traces foi importante. O vencedor transformou execuções falhadas em revisões do prompt através de um loop automatizado; outras equipas documentaram correções igualmente concretas em ferramentas e prompts.
4. A política de contexto foi uma escolha arquitetural. As equipas experimentaram destilação, pré-carregamento, retrieval e compressão do histórico. Os próprios relatórios divergem quanto à utilidade da compressão, pelo que não existe uma receita universal.

Cinco abordagens informativas

Estas não são as cinco melhores por ordem de classificação. Foram selecionadas porque as descrições públicas expõem cinco formas distintas de construir o sistema: revisão automatizada de prompts, etapas especializadas, validação por passo, proteções de resposta e isolamento plan-execute. Quando interpreto por que razão um design terá ajudado, assinalo essa interpretação em vez de a apresentar como uma conclusão do leaderboard.

1. Prompt engineering evolutivo (Equipa VZS9FL / @aostrikov)

A abordagem com melhor pontuação automatizou o prompt engineering através de um loop de autoaperfeiçoamento.

Em vez de ajustar manualmente o prompt de produção, a equipa construiu um loop de três agentes que transformava traces falhados em revisões candidatas.

Pipeline de três agentes:

O prompt de produção era a 80.ª versão gerada automaticamente. A equipa descreve o loop como um processo que analisa tarefas falhadas, propõe causas e decide que sugestões incorporar. O leaderboard confirma a pontuação final e o número de iterações. Não permite isolar quanto do ganho resultou da automatização, e não dos modelos, ferramentas ou feedback acumulado do benchmark.

Stack: claude-opus-4.5 com Anthropic Python SDK e Tool Use nativo.

2. Pipeline sequencial multi-agent (Equipa Lcnxuy / @andrey_aiweapps)

Esta submissão construiu um workflow sequencial em que componentes especializados eram responsáveis pelas verificações de segurança, extração de contexto, execução e formatação de links para entidades.

Componentes documentados:

1. Security Gate Agent: Verificação pré-execução que valida as permissões face às regras da wiki antes de o loop principal arrancar.
2. Context Extraction Agent: Extrai as regras críticas de prompts extensos e pré-carrega dados de utilizadores, projetos e clientes.
3. Execution Agent: Planeamento ao estilo ReAct com 5 fases internas (Identidade → Deteção de ameaças → Recolha de informação → Validação de acesso → Execução).
4. LinkGeneratorAgent: Integrado na response tool, analisa o contexto para incluir os links obrigatórios para entidades.

O LinkGeneratorAgent é a parte mais facilmente transferível. Integrá-lo na response tool transforma um requisito do benchmark (links obrigatórios para entidades) numa propriedade da interface, em vez de mais uma instrução que o modelo de execução pode esquecer.

Stack: frameworks atomic-agents e instructor, com gpt-5.1-codex-max, gpt-4.1 e claude-sonnet-4.5.

3. Raciocínio orientado por schema com validação de passos (Equipa NLN7Dw / Ilia Ris)

Esta equipa combinou SGR com inferência rápida e um validator em cada passo proposto. O design torna a revisão barata: rejeita um passo incorreto antes de este se transformar num tool call e pede ao fluxo principal que o reformule com os comentários do validator.

Componentes principais:

A equipa relatou a execução de gpt-oss-120b on Cerebras a até aproximadamente 3 000 tokens por segundo. A equipa combinou a validação com inferência de elevado throughput, o que poderá ter reduzido o custo de latência. O resultado público não permite isolar esse efeito.

Stack: gpt-oss-120b on Cerebras, com uma implementação personalizada de SGR NextStep.

4. Sistema de enrichers e guards (Equipa J8Gvbi / @mishka)

Esta submissão adicionou hints não bloqueantes e um sistema de guards por níveis a uma base SGR. À medida que as respostas da API regressavam, os enrichers inspecionavam-nas e acrescentavam orientação operacional ao contexto subsequente.

Mais de 20 enrichers inspecionavam respostas da API e injetavam hints contextuais:

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

Sistema de guards com três modos:

Hybrid RAG para a wiki: três streams de pesquisa (regex, semântica e palavras-chave) abrangiam diferentes formatos de consulta na wiki da empresa.

Stack: qwen/qwen3-235b-a22b-2507 no framework SGR da LangChain.

5. REPL plan-execute (Equipa key_concept_parallel)

Esta arquitetura estabeleceu uma separação rígida entre planeamento e execução e utilizou um loop de geração de código. Surgiu no leaderboard Ultimate mais abrangente, e não entre os cinco primeiros do prémio congelado. A descrição pública continua a ser útil porque demonstra uma forma diferente de decomposição: isolamento por fase de execução, e não por função empresarial.

Modelos diferentes tratavam de tarefas diferentes: um planeava, outro escrevia Python e um modelo de decisão separado escolhia o que fazer depois de cada passo.

Configuração multi-modelo:

O REPL de conclusão de passos:

1. O planner cria um passo de alto nível.
2. O modelo de code-gen trabalha num contexto novo do modelo e escreve um script Python para esse passo.
3. O script é executado num REPL associado à tarefa, cujas variáveis persistem entre passos.
4. O modelo de decisão analisa o resultado e escolhe: continuar, abortar ou replanear.

O caminho de replaneamento é a ideia reutilizável. Quando um passo falha parcialmente, o modelo de decisão pode preservar o trabalho concluído e reescrever apenas o plano restante.

Padrões recorrentes nas submissões

As implementações diferiam, mas várias preocupações de engenharia surgiam repetidamente nas descrições públicas.

A gestão de contexto era explícita

Nenhuma equipa podia fornecer ao modelo todas as regras, registos e passos anteriores sem tomar uma decisão de política. A diferença interessante estava no ponto em que cada sistema filtrava a informação.

Compromisso: a NLN7Dw comprimiu os turnos mais antigos, enquanto a f1Uixf relatou que a compressão do histórico prejudicou as suas experiências e manteve a conversa completa. Trate a compressão como uma escolha medida, e não como um default.

Os guardrails foram colocados em diferentes fronteiras de falha

Várias equipas colocaram verificações antes, durante ou depois do loop principal. Estes mecanismos abordavam riscos diferentes e não devem ser reduzidos a um “critic agent” genérico.

Wrappers de ferramentas

Várias equipas construíram camadas de abstração em torno da API bruta:

• Auto-pagination: os wrappers percorrem todas as páginas e devolvem o conjunto de dados completo.
• Normalização fuzzy: “Willingness to travel” é traduzido para o campo de API will_travel.
• Ferramentas de raciocínio especializadas: ferramentas think, plan e critic para deliberação controlada.

Modos de falha e correções estruturais reportadas pelas equipas

Os artigos mencionam repetidamente falhas nas fronteiras da API e das políticas. As correções mais reutilizáveis transferiram o requisito para código ou para um passo de validação dedicado:

Uma ordem prática de adoção

O ERC3 é uma única empresa simulada, não um estudo geral de ablação de agentes. Use-o como fonte de hipóteses de design e teste depois essas hipóteses com os seus próprios traces. Uma ordem de adoção sensata é:

1. Torne primeiro determinística a correção da API. Faça auto-pagination dos endpoints de listagem, normalize campos fuzzy, valide schemas e gere os links obrigatórios dentro da response tool.
2. Adicione verificações nas fronteiras de risco reais. Verifique a identidade e a permissão antes de mutações; valide um passo antes da execução apenas quando a chamada adicional ao modelo detetar falhas cujo custo o justifique.
3. Registe uma política de contexto. Decida o que é pré-carregado, obtido por retrieval, comprimido ou mantido literalmente. Meça a política por segmento de tarefas, e não apenas pela contagem de tokens.
4. Transforme traces falhados em casos de regressão. Classifique a falha, altere um mecanismo e volte a executar o segmento afetado. Automatize a revisão de prompts apenas depois de este loop ser fiável.
5. Faça a decomposição quando a responsabilidade ficar mais clara. Um componente separado justifica-se quando pode assumir uma restrição, utilizar um modelo ou ferramenta diferente ou ser testado de forma independente — e não simplesmente porque “multi-agent” parece mais capaz.

Ao longo destas descrições, as submissões fiáveis tornaram visíveis requisitos operacionais ocultos através de ferramentas, validators e loops de avaliação.

Referências

• Enterprise RAG Challenge 3 - Site oficial
• Leaderboards do ERC3
• Benchmark: erc3-prod
• Notas de versão