2026-01-11 · Atualizado 2026-07-15

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

Desafio Enterprise RAG 3 (ECR3): Criar Arquiteturas de Agente AI Vitoriosas

O Desafio 3 da Enterprise RAG (ECR3) solicitou que os agentes realizassem tarefas empresariais num ambiente de empresa simulada API. A tabela de classificação com prémios congelados é excepcionalmente útil, uma vez que muitos participantes publicaram não apenas a sua pontuação, mas também a arquitetura utilizada, a combinação de modelos, os custos envolvidos e as observações relativas a falhas.

Analisei essas descrições públicas para responder a uma pergunta mais específica: quais escolhas de design surgiram com frequência nas submissões de alta qualidade e quais delas são úteis fora deste benchmark?

TL;DR: Não existiu uma topologia vencedora única. As soluções mais robustas variaram desde um agente simples que efetua chamadas a ferramentas até sistemas especializados pipelines e de planeamento e execução. As ideias recorrentes eram mais específicas: aprender com rastreios de falhas, validar passos arriscados perto do momento da execução, tornar explícita a política de contexto e ocultar perigos API, como a paginação, por trás de wrappers fiáveis. A versão de produção prompt do vencedor foi a sua 80.ª versão gerada automaticamente.

O que é o desafio Enterprise RAG?

O Desafio Enterprise RAG 3 é um projeto de investigação em larga escala, baseado em colaboração com a comunidade que testa a forma como agentes autónomos AI lidam com tarefas empresariais complexas. Ao contrário de modelos benchmarks estáticos, o ECR3 é executado na Agentic Enterprise Simulation (AGES), uma simulação de eventos discretos que disponibiliza um empresa realista API.

O que os benchmark testam

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

• Perfis de funcionários com competências e departamentos específicos
• Projetos com atribuições de equipa e relações com clientes
• Wiki corporativo com regras de negócio e hierarquias de permissões
• Acompanhamento de tempo e operações financeiras

Cada tarefa inicia uma simulação isolada. A wiki da empresa é partilhada, mas os registos operacionais variam consoante a tarefa; por isso, um agente não consegue resolver todo o conjunto de tarefas apenas memorizando o estado da empresa em determinado momento.

Leia as pontuações como um instantâneo

O ECR3 disponibiliza agora tanto uma tabela de classificação congelada da competição como um benchmark público que continuou a receber novas execuções após o término do evento. Essas páginas respondem a perguntas distintas. Os valores apresentados abaixo referem-se à tabela de prémios no momento do encerramento da competição, e não às sessões com melhores resultados registadas posteriormente:

A página em tempo real da benchmark pode apresentar pontuações mais elevadas, uma vez que inclui execuções realizadas posteriormente. Por isso, o quadro de classificação congelado é a fonte adequada para determinar quem venceu a competição.

Tipos de tarefas

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

• Raciocínio multi-hop, como a correspondência entre as competências dos colaboradores e as atribuições de projetos.
• Validação de permissões, como o bloqueio de alterações salariais ou de acesso a dados não autorizados.
• Consultas ambíguas, incluindo pedidos em múltiplos idiomas e reformulados.
• Conformidade estrita da saída, incluindo a inclusão obrigatória de ligações a entidades nas respostas.

O que as submissões realmente sugerem

Os relatórios públicos não permitem chegar a uma conclusão clara do tipo “multi-agent supera o agente único.” A proposta que ficou em quarto lugar era explicitamente um design baseado num único agente. No entanto, eles permitem quatro observações mais específicas:

1. A decomposição era útil quando isolava um limite de falha conhecido. As equipas separavam as verificações de permissões, a validação de etapas, a execução de código ou a formatação de respostas — e não “papéis de agente” arbitrários.
2. A validação passou a ser realizada mais perto das ações irreversíveis. Vários sistemas verificavam as permissões antes da execução, analisavam cada etapa individualmente ou protegiam a resposta final.
3. A iteração orientada por rastreios era crucial. O vencedor transformou as execuções falhadas em revisões prompt através de um ciclo automatizado; outras equipas documentaram correções de ferramentas e prompt igualmente concretas.
4. A política de contexto era uma escolha arquitetónica. As equipas experimentaram técnicas como destilação, pré-carregamento, recuperação de informações e compressão de histórico. Os seus próprios relatórios divergem quanto à eficácia da compressão, pelo que não existe uma solução universal.

Cinco abordagens informativas

Estes não correspondem aos cinco primeiros classificados por ordem de ranking. Selecionei-os porque as suas descrições públicas revelam cinco abordagens distintas para construir o sistema: revisão automatizada de prompt, fases especializadas, validação passo a passo, mecanismos de proteção de respostas e isolamento entre a fase de planeamento e a execução. Sempre que interpreto os motivos pelos quais uma determinada arquitetura se revelou eficaz, indico essa interpretação em vez de a considerar como um resultado obtido através de uma tabela de classificação.

1. Evolução prompt engineering (Equipa VZS9FL / @aostrikov)

O abordagem com maior pontuação Execução automatizada de prompt engineering através de um ciclo de autoaperfeiçoamento.

Em vez de ajustar manualmente o prompt em produção, a equipa desenvolveu um três-agent loop que converte os rastreios com falhas em versões candidatas.

Três agentes pipeline:

O resultado: A produção prompt foi o 80.ª versão gerada automaticamente. A equipa descreve o ciclo como um processo que analisa tarefas falhadas, propõe causas potenciais e decide quais sugestões devem ser integradas. A tabela de classificação determina a pontuação final e o número de iterações; ela não isola a proporção de ganhos que se deve à automação, em oposição aos modelos, ferramentas ou ao feedback acumulado de benchmark.

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

2. Multi-agent sequencial pipeline (Equipa Lcnxuy / @andrey_aiweapps)

Esta submissão implementou um fluxo de trabalho sequencial no qual componentes especializados eram responsáveis pelas verificações de segurança, extração de contexto, execução e formatação de ligação de entidades.

Os componentes documentados:

1. Agente de Portão de Segurança: Verificação pré-execução que valida as permissões em relação às regras do wiki antes de o ciclo principal ser iniciado.
2. Agente de Extração de Contexto: Extrai as regras críticas de documentos extensos prompts e carrega antecipadamente os dados do utilizador, do projeto e do cliente.
3. Agente de Execução: Planeamento no estilo ReAct, composto por 5 fases internas (Identidade → Deteção de Ameaças → Recolha de Informações → Validação de Acesso → Execução).
4. LinkGeneratorAgent: Integrado na ferramenta de resposta, analisa o contexto para incluir os links das entidades necessárias.

O agente LinkGenerator é a parte mais transferível. Ao integrá‑lo na ferramenta de resposta, torna‑se obrigatória a presença de benchmark — ligações a entidades obrigatórias —, o que faz com que essa característica faça parte da própria interface em vez de ser apenas mais uma instrução que o modelo de execução pode esquecer.

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

3. Raciocínio orientado por esquema com validação passo a passo (Equipa NLN7Dw / Ilia Ris)

Esta equipa combinou SGR com inferência rápida e um validador em cada passo proposto. Este design torna as revisões económicas: basta rejeitar um passo defeituoso antes que ele se transforme num tool call, para depois solicitar ao fluxo principal que o refaça com base nos comentários do validador.

Componentes principais:

A equipa relatou ter executado gpt-oss-120b na Cerebras com uma taxa de até aproximadamente 3.000 tokens por segundo. A inferência rápida reduziu o impacto negativo da latência na fase de validação, embora a tabela de classificação não ofereça uma análise de ablação que distinga a velocidade do resto dos fatores de projeto.

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

4. Sistema de enriquecimento e proteção (Equipa J8Gvbi / @mishka)

Esta submissão adicionou sugestões não bloqueantes e um sistema de proteção em camadas a uma base SGR. À medida que as respostas API eram recebidas, os mecanismos de enriquecimento analisavam-nas e inseriam orientações operacionais no contexto posterior.

O sistema de enriquecimento:

Mais do que 20 enriquecedores Inspecionou as respostas API e injetou pistas contextuais:

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

Sistema de proteção em três modos:

Wiki híbrido RAG: Três fluxos de busca — regex, semântico e por palavras-chave — que lidam com diferentes formatos de consultas no wiki da empresa.

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

5. REPL de planeamento e execução (Equipa key_concept_parallel)

Esta arquitetura estabelece uma barreira clara entre o planeamento e a execução, recorrendo a um ciclo de geração de código. Embora tenha aparecido na classificação geral do Ultimate em vez dos cinco primeiros lugares fixos, a sua descrição pública é útil, pois demonstra uma forma diferente de decomposição: isolamento por fase de execução em vez de por função empresarial.

Diferentes modelos tratavam tarefas distintas: um era responsável pelo planeamento, outro escrevia código em Python, e um modelo de decisão separado escolhia o que fazer após cada passo.

Configuração multi-modelo:

O REPL de conclusão de passos:

1. O planeador cria uma etapa de alto nível.
2. O modelo de geração de código funciona num contexto de modelo novo e escreve um script em Python para esse modelo.
3. O script é executado numa REPL com escopo de tarefa, na qual as variáveis permanecem entre as etapas.
4. O modelo de decisão analisa o resultado e escolhe: continuar, interromper ou replanear.

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

Padrões que se repetiram nas submissões

As implementações diferiam entre si, mas vários aspetos de engenharia surgiram repetidamente nas descrições públicas.

A gestão de contexto era explícita

Nenhuma equipa consegue transmitir ao modelo todas as regras, registos e passos anteriores sem ter de tomar uma decisão relativa à política a ser aplicada. A diferença relevante reside no modo como cada sistema filtra as informações.

Compromisso: O NLN7Dw comprime turnos mais antigos, enquanto f1Uixf Foi relatado que a compressão de histórico prejudicou os experimentos e que, por isso, optou‑se por manter a conversa na sua totalidade. Trate a compressão como uma escolha deliberada, e não como uma opção padrão.

Foram definidas restrições em diferentes limites de falha

Várias equipas inseriram verificações antes, durante ou depois do laço principal. Estes mecanismos abordam riscos distintos e não devem ser agrupados num único “agente crítico” genérico.

Envoltórios de ferramentas inteligentes

Várias equipas criaram camadas de abstração em torno dos dados brutos API:

• Autopaginação: Os wrappers percorrem cada página e devolvem o dataset completo.
• Normalização difusa: A “disposição para viajar” é traduzida para a will_travel Campo API.
• Ferramentas de raciocínio especializadas: think, plan, e critic Ferramentas para deliberação controlada.

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

Os relatórios mencionam repetidamente falhas em API e nos limites definidos pelas políticas. As soluções mais reutilizáveis transferiram esse requisito para o código ou para uma etapa de validação dedicada:

Uma ordem de adoção prática

O ECR3 é uma empresa simulada, e não um estudo de ablação de agentes gerais. Utilize-o como fonte de hipóteses de projeto e, em seguida, teste essas hipóteses com os seus próprios registos. Uma ordem de adoção sensata é:

1. Torne primeiro a correção de API determinística. Pagine automaticamente os endpoints de lista, normalize campos difusos, valide esquemas e gere os links necessários dentro da ferramenta de resposta.
2. Adicione verificações nas fronteiras de risco real. Verifique a identidade e as permissões antes da mutação; valide uma etapa antes da execução apenas quando a chamada adicional ao modelo deteta falhas que justifiquem o custo.
3. Elabore uma política de contexto. Decida o que deve ser pré-carregado, recuperado, comprimido ou mantido literalmente. Avalie a política com base em fatias de tarefa e não apenas no número de tokens.
4. Transforme rastreios falhados em casos de regressão. Classifique a falha, altere um mecanismo e execute novamente a fatia afetada. Automatize a revisão de prompt somente após esse ciclo se mostrar confiável.
5. Descomponha quando a responsabilidade ficar mais clara. Um componente separado é justificado quando puder gerir uma restrição específica, utilizar um modelo ou ferramenta diferente ou ser testado de forma independente — e não simplesmente porque “multi-agent” parece mais capaz.

A lição mais importante não é que uma arquitetura venceu. É que as submissões fiáveis tornaram visíveis os requisitos operacionais ocultos, através de ferramentas, validadores e ciclos de avaliação.

Referências

• Desafio 3 da Enterprise RAG - Site Oficial
• Classificações ECR3
• Benchmark: erc3-prod
• Notas de Lançamento