Enterprise RAG Challenge 3 : enseignements tirés des soumissions publiques

Viacheslav Dubrov

2026-01-11 · Mis à jour 2026-07-15 · 12 min · Agents IA

Traduction automatique Cet article a été traduit automatiquement depuis la version originale en anglais.

L’Enterprise RAG Challenge 3 (ERC3) demandait à des agents d’accomplir des tâches métier via l’API d’une entreprise simulée. Le classement figé des prix est particulièrement instructif, car de nombreux participants ont publié davantage qu’un score : architecture, combinaison de modèles, coût et analyse des échecs.

J’ai étudié ces descriptions publiques pour répondre à une question plus précise : quels choix de conception revenaient dans les soumissions performantes, et lesquels sont utiles au-delà de ce benchmark ?

À la fin de cet article, vous devriez pouvoir transformer ces observations en hypothèses de conception pour vos propres traces d’agents, puis les tester en fonction de vos types de tâches et du coût des échecs.

Qu’est-ce que l’Enterprise RAG Challenge ?

L’Enterprise RAG Challenge 3 est un projet de recherche participatif à grande échelle qui évalue la capacité d’agents AI autonomes à gérer des tâches métier complexes. Contrairement aux benchmarks statiques, ERC3 s’exécute sur l’Agentic Enterprise Simulation (AGES), une simulation à événements discrets qui expose une API d’entreprise réaliste.

Ce que teste le benchmark

Dans AGES, les agents travaillent au sein d’une entreprise fictive comprenant :

• Des profils d’employés avec des compétences et des services précis
• Des projets avec des affectations d’équipe et des relations clients
• Un wiki d’entreprise contenant les règles métier et les hiérarchies de permissions
• Le suivi du temps et les opérations financières

Chaque tâche démarre une simulation isolée. Le wiki de l’entreprise est partagé, mais les enregistrements opérationnels varient selon la tâche ; un agent ne peut donc pas résoudre toute la suite en mémorisant l’état d’une seule entreprise.

Lire les scores comme un instantané

ERC3 expose désormais à la fois un classement figé de la compétition et un benchmark public qui a continué à recevoir des runs après l’événement. Ces pages répondent à des questions différentes. Les chiffres ci-dessous décrivent le classement des prix à la clôture de la compétition, et non les meilleures sessions ultérieures :

La page du benchmark live peut afficher des scores plus élevés, car elle inclut des runs ultérieurs. Le classement figé est donc la bonne source pour les affirmations sur les résultats de la compétition.

Types de tâches

Les tâches couvrent plusieurs domaines de compétence :

• Raisonnement multi-hop, par exemple pour faire correspondre les compétences des employés aux affectations de projets.
• Validation des permissions, par exemple pour bloquer des modifications de salaire ou des accès aux données non autorisés.
• Requêtes ambiguës, notamment des demandes multilingues et paraphrasées.
• Conformité stricte au format de sortie, avec notamment des liens obligatoires vers les entités dans les réponses.

Ce que suggèrent réellement les soumissions

Les comptes rendus publics ne permettent pas de conclure simplement que « le multi-agent surpasse le single-agent ». La soumission arrivée quatrième dans le classement des prix reposait explicitement sur une architecture single-agent simple. Ils permettent en revanche de dégager quatre observations plus ciblées :

1. La décomposition était utile lorsqu’elle isolait une frontière d’échec connue. Les équipes séparaient les vérifications de permissions, la validation des étapes, l’exécution du code ou le formatage des réponses, et non des « rôles d’agents » arbitraires.
2. La validation se rapprochait des actions irréversibles. Plusieurs systèmes vérifiaient les permissions avant l’exécution, réexaminaient chaque étape ou protégeaient la réponse finale.
3. L’itération pilotée par les traces comptait. Le vainqueur transformait les runs en échec en révisions de prompt via une boucle automatisée ; d’autres équipes documentaient des corrections tout aussi concrètes au niveau des outils et des prompts.
4. La politique de contexte constituait un choix architectural. Les équipes ont testé la distillation, le préchargement, la retrieval et la compression de l’historique. Leurs propres rapports divergent sur l’utilité de la compression : il n’existe donc pas de recette universelle.

Cinq approches instructives

Il ne s’agit pas des cinq meilleurs systèmes classés par score. Je les ai sélectionnés parce que leurs descriptions publiques exposent cinq manières distinctes de construire le système : révision automatisée des prompts, étapes spécialisées, validation à chaque étape, protections de la réponse et isolation plan-execute. Lorsque j’interprète la raison pour laquelle une conception a pu être utile, je le précise au lieu de présenter cette interprétation comme un résultat du classement.

1. Prompt engineering évolutionnaire (équipe VZS9FL / @aostrikov)

L’approche ayant obtenu le meilleur score automatisait le prompt engineering via une boucle d’auto-amélioration.

Au lieu d’ajuster manuellement le prompt de production, l’équipe a construit une boucle à trois agents qui transformait les traces en échec en propositions de révision.

Pipeline à trois agents :

Le prompt de production était la 80e version générée automatiquement. L’équipe décrit une boucle qui analyse les tâches en échec, propose des causes et décide quelles suggestions intégrer. Le classement établit le score final et le nombre d’itérations. Il ne permet pas d’isoler la part du gain attribuable à l’automatisation par rapport aux modèles, aux outils ou aux retours accumulés du benchmark.

Stack : claude-opus-4.5 avec l’Anthropic Python SDK et Tool Use natif.

2. Pipeline séquentiel multi-agent (équipe Lcnxuy / @andrey_aiweapps)

Cette soumission construisait un workflow séquentiel dans lequel des composants spécialisés prenaient en charge les contrôles de sécurité, l’extraction du contexte, l’exécution et le formatage des liens vers les entités.

Composants documentés :

1. Security Gate Agent : contrôle pré-exécution qui valide les permissions par rapport aux règles du wiki avant le lancement de l’agent loop principal.
2. Context Extraction Agent : extrait les règles critiques de prompts volumineux et précharge les données utilisateur, projet et client.
3. Execution Agent : planification de type ReAct en 5 phases internes (Identity → Threat Detection → Info Gathering → Access Validation → Execution).
4. LinkGeneratorAgent : intégré à l’outil de réponse, il analyse le contexte pour inclure les liens obligatoires vers les entités.

Le LinkGeneratorAgent est l’élément le plus facilement transférable. Le placer dans l’outil de réponse fait d’une exigence du benchmark — les liens obligatoires vers les entités — une propriété de l’interface plutôt qu’une instruction supplémentaire que le modèle d’exécution pourrait oublier.

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

3. Raisonnement guidé par schéma avec validation des étapes (équipe NLN7Dw / Ilia Ris)

Cette équipe associait SGR à une inférence rapide et à un validator sur chaque étape proposée. La conception rendait la révision peu coûteuse : une étape défectueuse était rejetée avant de devenir un tool call, puis le flux principal était invité à la retravailler à partir des commentaires du validator.

Composants clés :

L’équipe indiquait exécuter gpt-oss-120b sur Cerebras à environ 3 000 tokens par seconde au maximum. Elle associait la validation à une inférence à haut débit, ce qui a pu réduire le coût en latence. Le résultat public ne permet pas d’isoler cet effet.

Stack : gpt-oss-120b sur Cerebras, avec une implémentation personnalisée de SGR NextStep.

4. Système d’enrichissement et de guards (équipe J8Gvbi / @mishka)

Cette soumission ajoutait des indications non bloquantes et un système de guards à plusieurs niveaux à une base SGR. À mesure que les réponses de l’API arrivaient, des enrichers les inspectaient et ajoutaient des conseils opérationnels au contexte ultérieur.

Plus de 20 enrichers inspectaient les réponses de l’API et injectaient des indications contextuelles :

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

Système de guards à trois modes :

RAG hybride pour le wiki : trois flux de recherche — regex, sémantique et mots-clés — couvraient différentes formes de requêtes sur le wiki de l’entreprise.

Stack : qwen/qwen3-235b-a22b-2507 sur le framework SGR de LangChain.

5. REPL plan-execute (équipe key_concept_parallel)

Cette architecture séparait strictement la planification et l’exécution et utilisait une boucle de génération de code. Elle apparaissait dans le classement Ultimate plus large, et non dans le top cinq figé des prix. Sa description publique reste utile, car elle montre une autre forme de décomposition : l’isolation par phase d’exécution plutôt que par rôle métier.

Des modèles différents prenaient en charge des tâches différentes : l’un planifiait, l’autre écrivait du Python et un modèle de décision distinct choisissait la suite après chaque étape.

Configuration multi-modèle :

La REPL de complétion des étapes :

1. Le planner crée une étape de haut niveau.
2. Le modèle de génération de code travaille dans un contexte de modèle vierge et écrit un script Python pour cette étape.
3. Le script s’exécute dans une REPL limitée à la tâche, dont les variables persistent d’une étape à l’autre.
4. Le modèle de décision examine le résultat et choisit entre continuer, abandonner ou replanifier.

Le chemin de replanification est l’idée la plus réutilisable. Lorsqu’une étape échoue partiellement, le modèle de décision peut conserver le travail déjà effectué et réécrire uniquement le reste du plan.

Les motifs récurrents dans les soumissions

Les implémentations différaient, mais plusieurs préoccupations d’ingénierie revenaient dans les descriptions publiques.

La gestion du contexte était explicite

Aucune équipe ne pouvait fournir au modèle toutes les règles, tous les enregistrements et toutes les étapes précédentes sans faire un choix de politique. La différence intéressante résidait dans l’endroit où chaque système filtrait l’information.

Compromis : NLN7Dw compressait les tours anciens, tandis que f1Uixf rapportait que la compression de l’historique nuisait à ses expérimentations et conservait donc la conversation complète. Considérez la compression comme un choix à mesurer, et non comme une valeur par défaut.

Les guardrails étaient placés à différentes frontières d’échec

Plusieurs équipes plaçaient des contrôles avant, pendant ou après l’agent loop principal. Ces mécanismes répondaient à des risques différents et ne devraient pas être regroupés sous l’étiquette générique de « critic agent ».

Wrappers d’outils

Plusieurs équipes ont construit des couches d’abstraction autour de l’API brute :

• Auto-pagination : les wrappers parcourent toutes les pages et renvoient l’ensemble des données.
• Normalisation floue : « willingness to travel » est traduit vers le champ d’API will_travel.
• Outils de raisonnement spécialisés : outils think, plan et critic pour une délibération contrôlée.

Modes d’échec et corrections structurelles rapportées par les équipes

Les comptes rendus mentionnent régulièrement des échecs aux frontières de l’API et des politiques. Les corrections les plus réutilisables déplaçaient l’exigence dans le code ou dans une étape de validation dédiée :

Un ordre d’adoption pratique

ERC3 ne porte que sur une entreprise simulée et ne constitue pas une étude générale d’ablation d’agents. Utilisez-le comme source d’hypothèses de conception, puis testez ces hypothèses sur vos propres traces. Un ordre d’adoption raisonnable serait le suivant :

1. Rendez d’abord la correction de l’API déterministe. Ajoutez l’auto-pagination aux endpoints de liste, normalisez les champs flous, validez les schémas et générez les liens requis dans l’outil de réponse.
2. Ajoutez des contrôles aux véritables frontières de risque. Vérifiez l’identité et les permissions avant toute mutation ; validez une étape avant son exécution uniquement si l’appel de modèle supplémentaire détecte des échecs dont le coût le justifie.
3. Formalisez une politique de contexte. Décidez ce qui est préchargé, récupéré, compressé ou conservé verbatim. Évaluez cette politique par segment de tâches, et pas uniquement en fonction du nombre de tokens.
4. Transformez les traces en échec en cas de régression. Classez l’échec, modifiez un seul mécanisme, puis relancez le segment concerné. N’automatisez la révision des prompts qu’une fois cette boucle fiable.
5. Décomposez lorsque la responsabilité devient plus claire. Un composant distinct est justifié lorsqu’il peut prendre en charge une contrainte, utiliser un modèle ou un outil différent, ou être testé indépendamment — pas simplement parce que « multi-agent » semble plus puissant.

À travers ces comptes rendus, les soumissions fiables rendaient visibles les exigences opérationnelles implicites dans les outils, les validators et les boucles d’évaluation.

Références

• Site officiel de l’Enterprise RAG Challenge 3
• Classements ERC3
• Benchmark : erc3-prod
• Notes de version