2026-01-11 · Mis à jour 2026-07-15

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

Défi d’entreprise RAG 3 (ECR3) : Concevoir des architectures d’agents AI performantes

L’Épreuve 3 des Enterprise RAG Challenges (ECR3) demandait aux agents d’accomplir des tâches métier au sein d’une entreprise simulée API. Le classement des prix figé s’avère particulièrement utile, car de nombreux participants ont publié non seulement leur score, mais aussi l’architecture qu’ils utilisaient, la composition de leurs modèles, les coûts associés ainsi que des notes relatives aux échecs rencontrés.

J’ai examiné ces descriptions publiques afin de répondre à une question plus ciblée : quels choix de conception apparaissent fréquemment dans les soumissions de haute qualité, et lesquels sont utiles en dehors de ce benchmark ?

TL;DR : Il n’existait pas de topologie unique gagnante. Les solutions les plus performantes allaient d’un agent simple chargé d’appeler des outils à des systèmes spécialisés pipelines ainsi que des systèmes de planification et d’exécution. Les idées récurrentes étaient plus spécifiques : apprendre à partir des traces d’échec, valider les étapes à risque juste avant leur exécution, rendre explicite la politique de contexte, et cacher les dangers API tels que la pagination derrière des enveloppes fiables. La version en production prompt du gagnant était sa 80e version générée automatiquement.

Quel est le défi lié à l’RAG au niveau enterprise ?

La Épreuve 3 de l’Enterprise RAG est une projet de recherche à grande échelle et collaboratif qui teste la manière dont les agents autonomes AI gèrent des tâches métier complexes. Contrairement aux modèles benchmarks statiques, ECR3 s’exécute sur le Agentic Enterprise Simulation (AGES), une simulation d’événements discrets qui expose un entreprise réaliste API.

Ce que testent les benchmark

Grâce à AGES, les agents opèrent au sein d’une entreprise fictive qui dispose de :

• Profils d’employés présentant des compétences et des départements spécifiques
• Projets incluant des affectations d’équipe et des relations avec les clients
• Wiki corporate contenant des règles métier et des hiérarchies de permissions
• Suivi du temps et opérations financières

Chaque tâche lance une simulation isolée. La wiki de l’entreprise est partagée, mais les enregistrements opérationnels diffèrent d’une tâche à l’autre ; par conséquent, un agent ne peut pas résoudre l’ensemble des tâches en mémorisant un seul état de l’entreprise.

Interpréter les scores comme une capture instantanée

ECR3 expose désormais à la fois un classement figé des compétitions et un benchmark public qui continue de recevoir des exécutions même après la fin de l’événement. Ces pages répondent à des questions différentes. Les graphiques ci-dessous présentent le classement des prix au moment de la clôture de la compétition, et non celui des sessions les plus performantes postérieures :

La page en temps réel benchmark peut afficher des scores plus élevés, car elle prend en compte les exécutions effectuées ultérieurement. C’est pourquoi le classement figé constitue la source appropriée pour déterminer qui a remporté la compétition.

Types de tâches

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

• Raisonnement multi-nœuds, tel que l’association des compétences des employés aux affectations de projets.
• Validation des permissions, comme le blocage des modifications de salaire ou des accès aux données non autorisés.
• Consultes ambiguës, y compris les requêtes multilingues et les demandes reformulées.
• Conformité stricte des sorties, incluant des liens d’entités obligatoires dans les réponses.

Ce que les soumissions suggèrent réellement

Les documents publiés ne permettent pas de conclure de manière claire que « multi-agent surpasse le modèle à un seul agent ». La solution classée quatrième était explicitement une architecture basée sur un seul agent simple. Cependant, ils permettent d’affirmer quatre observations plus précises :

1. La décomposition s’avérait utile lorsqu’elle permettait d’isoler une frontière de défaillance 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’agent » arbitraires.
2. La validation était placée plus près des actions irréversibles. Plusieurs systèmes vérifiaient les permissions avant exécution, examinaient chaque étape individuellement ou protégeaient la réponse finale.
3. L’itération pilotée par les traces était cruciale. Le gagnant transformait les exécutions échouées en versions prompt grâce à un boucle automatisée ; d’autres équipes documentaient des correctifs concrets liés aux outils et aux prompt similaires.
4. La politique de contexte relevait d’un choix architectural. Les équipes expérimentaient la distillation, le préchargement, la récupération ainsi que la compression de l’historique. Leurs propres rapports divergent quant à l’efficacité de cette compression, ce qui explique l’absence de solution universelle.

Cinq approches informatives

Il ne s’agit pas des cinq meilleures solutions classées par ordre de performance. Je les ai sélectionnées parce que leurs descriptions publiques mettent en évidence cinq approches distinctes pour concevoir le système : la révision automatique prompt, des étapes spécialisées, une validation à chaque étape, des mécanismes de protection des réponses, ainsi qu’une isolation entre la planification et l’exécution. Lorsque j’analyse pourquoi une certaine conception s’avère efficace, je formule cette interprétation explicitement, plutôt que de la présenter comme un résultat issu d’un classement.

1. Évolution prompt engineering (Équipe VZS9FL / @aostrikov)

Le l’approche présentant le score le plus élevé l’automatisation prompt engineering au moyen d’un cycle d’autosuramélioration.

Au lieu de régler manuellement le prompt en environnement de production, l’équipe a conçu un trois-agent loop qui transforme les traces défaillantes en versions candidates.

Trois agents pipeline :

Le résultat : La version en production prompt était la 80e version générée automatiquement. L’équipe décrit ce cycle comme une analyse des tâches échouées, une proposition de causes possibles, ainsi qu’une décision quant aux suggestions à intégrer. Le classement définit la note finale et le nombre d’itérations ; il ne permet pas de distinguer dans quelle mesure les améliorations proviennent de l’automatisation plutôt que des modèles, des outils ou des retours accumulés via benchmark.

Stack : pile d’objets ou d’éléments hiérarchisés. claude-opus-4.5 avec Anthropic Python SDK ainsi que le natif Tool Use.

2. Multi-agent séquentiel pipeline (Équipe Lcnxuy / @andrey_aiweapps)

Cette contribution a mis en place un flux de travail séquentiel dans lequel des composants spécialisés étaient chargés des vérifications de sécurité, de l’extraction du contexte, de l’exécution ainsi que du formatage des liens entité.

Les composants documentés :

1. Agent de porte de sécurité : Vérification préalable qui valide les permissions par rapport aux règles du wiki avant le démarrage du boucle principale.
2. Agent d’extraction de contexte : Il extrait les règles essentielles à partir des documents volumineux prompts et charge à l’avance les données relatives à l’utilisateur, au projet et au client.
3. Agent d’exécution : Planification de type ReAct comprenant 5 phases internes (Identité → Détection de menaces → Collecte d’informations → Validation d’accès → Exécution).
4. LinkGeneratorAgent : Intégré à l’outil de réponse, il analyse le contexte afin d’inclure les liens vers les entités requises.

L’agent LinkGenerator constitue la partie la plus transférable. En l’intégrant à l’outil de réponse, on crée une exigence benchmark — des liens d’entité obligatoires — qui devient une propriété de l’interface plutôt que simplement une instruction supplémentaire que le modèle d’exécution pourrait oublier.

Stack : pile d’objets ou d’éléments hiérarchisés. atomic-agents et instructor frameworks avec gpt-5.1-codex-max, gpt-4.1 et claude-sonnet-4.5.

3. Raisonnement guidé par un schéma avec validation étape par étape (Équipe NLN7Dw / Ilia Ris)

Cette équipe a associé SGR à une inférence rapide ainsi qu’à un validateur pour chaque étape proposée. Cette architecture rend les révisions peu coûteuses : il suffit de rejeter une étape défectueuse avant qu’elle ne se transforme en tool call, puis de demander au flux principal de la retravailler en tenant compte des commentaires du validateur.

Composants clés :

L’équipe a indiqué avoir exécuté gpt-oss-120b sur Cerebras à environ 3 000 tokens par seconde. Une inférence rapide a permis de réduire le retard lié à la validation, bien que le classement ne propose pas d’analyse d’ablation permettant de distinguer l’impact de la vitesse de celui des autres aspects du design.

Stack : pile d’objets ou d’éléments hiérarchisés. gpt-oss-120b sur Cerebras, grâce à une implémentation personnalisée de SGR NextStep.

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

Cette contribution a ajouté des indications non bloquantes ainsi qu’un système de protection hiérarchisé à une base SGR. Lorsque les réponses API arrivaient, les modules d’enrichissement les analysaient et y intégraient des directives opérationnelles destinées au contexte ultérieur.

Le système d’enrichissement :

Plus que 20 enrichisseurs J’ai examiné les réponses générées par API et y ai injecté des indices contextuels :

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

Système de protection à trois modes :

Wiki hybride RAG : Trois flux de recherche — basés sur les expressions régulières, la sémantique et les mots-clés — permettent de gérer différents types de requêtes dans le wiki de l’entreprise.

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

5. REPL plan-exécution (Équipe key_concept_parallel)

Cette architecture érige une barrière stricte entre la planification et l’exécution en recourant à un cycle de génération de code. Elle figurait sur le classement général d’Ultimate plutôt que parmi les cinq premiers classés définitifs, mais sa description publique est utile, car elle illustre une forme différente de décomposition : l’isolement selon la phase d’exécution plutôt que selon le rôle métier.

Différents modèles s’occupaient de tâches distinctes : l’un était chargé de la planification, un autre de l’écriture de code en Python, tandis qu’un modèle de décision séparé déterminait ce qu’il fallait faire à chaque étape.

Configuration multi-modèles :

Le REPL de finalisation d’étape :

1. Le planificateur crée une étape de haut niveau.
2. Le modèle de génération de code fonctionne dans un contexte de modèle vierge et écrit un script Python correspondant.
3. Le script s’exécute dans une REPL dédiée à la tâche, dont les variables restent accessibles entre les différentes étapes.
4. Le modèle de décision analyse le résultat et choisit : continuer, interrompre ou réplanifier.

Le chemin de réplanification correspond à l’idée reutilisable. Lorsqu’une étape échoue partiellement, le modèle de décision peut conserver le travail déjà accompli et ne réécrire que le plan restant.

Modèles récurrents observés dans les soumissions

Les implémentations variaient, mais plusieurs problématiques d’ingénierie ressortaient de manière récurrente dans les descriptions publiques.

La gestion du contexte était explicite

Aucune équipe ne peut fournir au modèle toutes les règles, tous les enregistrements et toutes les étapes précédentes sans avoir à prendre une décision relative aux politiques à appliquer. La différence notable réside dans le fait que chaque système filtre les informations de manière distincte.

Équilibre à trouver : NLN7Dw comprime les tours plus anciens, tandis que f1Uixf Il a indiqué que la compression de l’historique nuisait à ses expériences et qu’il préférait conserver l’intégralité de la conversation. Il convient donc de considérer la compression comme une décision délibérée, et non comme une option par défaut.

Des garde-fous ont été déployés aux différents points de défaillance

Plusieurs équipes ont inséré des vérifications avant, pendant ou après la boucle principale. Ces mécanismes ciblaient des risques distincts et ne devraient pas être regroupés en un seul « agent critique » générique.

Enveloppes d’outils intelligents

Plusieurs équipes ont développé des couches d’abstraction autour du API brut :

• Auto-paginage : Les wrappers parcourent chaque page et renvoient l’ensemble du dataset.
• Normalisation floue : La « volonté de voyager » est traduite en will_travel API champ.
• Outils de raisonnement spécialisés : think, plan, et critic Outils de délibération contrôlée.

Modes de défaillance et correctifs structurels signalés par les équipes

Les rapports évoquent à plusieurs reprises des échecs liés à API ainsi qu’aux limites définies par les politiques en vigueur. Les corrections les plus réutilisables ont consisté à intégrer cette exigence directement dans le code ou à la placer dans une étape de validation dédiée :

Une séquence d’adoption pratique

ECR3 constitue une entreprise simulée et non une étude d’ablation de type agent général. Utilisez-la comme source d’hypothèses de conception, puis validez ces hypothèses à l’aide de vos propres traces d’exécution. Une séquence d’adoption judicieuse est la suivante :

1. Assurer d’abord que la correction de API soit déterministe. Paginer automatiquement les points de terminaison des listes, normaliser les champs flous, valider les schémas, et générer les liens requis au sein de l’outil de réponse.
2. Ajouter des vérifications aux frontières à haut risque. Vérifier l’identité et les permissions avant toute mutation ; valider une étape avant son exécution uniquement lorsque l’appel supplémentaire au modèle détecte des échecs dont le coût en vaut la peine.
3. Élaborer une politique de contexte. Déterminer ce qui doit être chargé à l’avance, récupéré, compressé ou conservé tel quel. Évaluer cette politique en fonction des tranches de tâche plutôt que uniquement en comptant les tokens.
4. Transformer les traces d’échec en cas de régression. Classifier l’échec, modifier un mécanisme, puis relancer la tranche concernée. Automatiser la révision de prompt uniquement après que ce cycle se soit avéré fiable.
5. Décomposer lorsqu la responsabilité devient plus claire. Un composant distinct est justifié s’il peut gérer une contrainte spécifique, utiliser un modèle ou un outil différent, ou être testé de manière indépendante — et non simplement parce que « multi-agent » semble plus performant.

La leçon principale n’est pas qu’une seule architecture ait triomphé. Elle réside plutôt dans le fait que des soumissions fiables rendent visibles, au sein d’outils, de validateurs et de boucles d’évaluation, les exigences opérationnelles jusqu’alors cachées.

Références

• Défi Enterprise RAG 3 – Site officiel
• Classements ECR3
• Benchmark : erc3-prod
• Notes de version