Traduction automatique
Cet article a été traduit automatiquement depuis la version originale en anglais.
Enterprise RAG Challenge 3 (ECR3) : les architectures d’agents IA gagnantes
L’Enterprise RAG Challenge 3 (ECR3) vient de se terminer. 524 équipes, plus de 341 000 exécutions d’agents, et seulement 0,4 % des équipes ont atteint un score parfait. Maintenant que le classement et les retours d’expérience sont publics, j’ai passé en revue les solutions gagnantes pour comprendre ce que les meilleures équipes faisaient différemment.
Ce billet explique ce qu’est ECR3, à quoi ressemblaient les tâches, et les patterns que j’ai retrouvés dans les architectures qui fonctionnaient.
TL;DR : les pipelines multi-agents ont battu les approches monolithiques. L’équipe arrivée en tête a utilisé une ingénierie de prompts évolutionnaire sur plus de 80 itérations automatisées. Les gagnants ont consacré un effort important aux garde-fous (contrôles de sécurité préalables, validateurs dans la boucle, gardes post-exécution) et à la stratégie de contexte. Ce qui entrait dans le contexte comptait plus que sa taille.
Qu’est-ce que l’Enterprise RAG Challenge ?
L’Enterprise RAG Challenge 3 est un projet de recherche participatif à grande échelle qui teste la manière dont des agents IA autonomes gèrent des tâches métier complexes. Contrairement aux benchmarks statiques, ECR3 s’exécute sur Agentic Enterprise Simulation (AGES), une simulation à événements discrets qui expose une API d’entreprise réaliste.
Pourquoi ECR3 compte
Via AGES, les agents opèrent dans une fausse entreprise qui dispose de :
- Profils employés avec compétences et départements spécifiques
- Projets avec affectations d’équipe et relations clients
- Wiki d’entreprise avec règles métier et hiérarchies d’autorisations
- Suivi du temps et opérations financières
Chaque tâche lance sa propre simulation avec de nouvelles données, donc les agents ne peuvent rien mémoriser d’une exécution à l’autre.
Le niveau de difficulté
Le classement est sévère :
| Métrique | Valeur |
|---|---|
| Équipes inscrites | 524 |
| Exécutions totales d’agents | 341,000+ |
| Tâches disponibles | 103 tâches métier uniques |
| Score parfait (100.0) | Seulement 0,4 % des équipes |
| Score ≥ 0.9 | Seulement 1,1 % des équipes |
Types de tâches
Les tâches couvrent plusieurs domaines de compétence :
- Raisonnement multi-sauts : croiser les compétences des employés avec les affectations projet
- Validation des autorisations : empêcher les changements de salaire ou accès aux données non autorisés
- Requêtes ambiguës : gérer des demandes utilisateur multilingues et paraphrasées
- Conformité stricte de sortie : inclure les liens d’entité obligatoires dans les réponses
Ce qui a réellement gagné
Quatre patterns revenaient constamment en haut du classement :
- Les pipelines multi-agents battent les agents monolithiques. Découper le travail donnait de meilleurs résultats qu’un gros agent qui essaie de tout faire.
- Les agents les plus autonomes étaient les plus contraints. Les garde-fous n’étaient pas un ajout tardif.
- L’évolution automatisée des prompts a battu l’ingénierie manuelle. Les meilleurs prompts ont traversé plus de 80 générations.
- La stratégie de contexte faisait l’essentiel du travail. Pas plus de contexte, le bon contexte.
Principales approches gagnantes
Les cinq architectures ci-dessous prennent des directions très différentes, de l’évolution de prompts entièrement automatisée à la récupération hybride. Chacune contient des éléments à réutiliser.
1. Ingénierie de prompts évolutionnaire (équipe VZS9FL / @aostrikov)
L’approche la mieux classée a automatisé l’ingénierie de prompts via une boucle d’auto-amélioration.
Au lieu d’ajuster les prompts à la main, l’équipe a construit une boucle à trois agents qui permet à l’agent d’apprendre de ses propres échecs.
Pipeline à trois agents :
| Agent | Rôle |
|---|---|
| Agent principal | Exécute le benchmark, journalise toutes les actions et échecs |
| Agent analyste | Passe en revue les tâches échouées, formule des hypothèses sur les causes racines |
| Agent versionneur | Génère une nouvelle version du prompt en intégrant les enseignements |
Le résultat : le prompt de production était la 80e version auto-générée. Chaque version corrigeait un pattern d’échec spécifique observé dans les logs de l’exécution précédente. La plupart relevaient du type de cas limite qu’on ne remarque qu’après avoir fixé une trace d’échec pendant une heure.
Stack : claude-opus-4.5 avec Anthropic Python SDK et Tool Use natif.
2. Pipeline séquentiel multi-agents (équipe Lcnxuy / @andrey_aiweapps)
Ici, l’agent monolithique a été abandonné au profit d’un pipeline séquentiel de spécialistes, chacun suffisamment petit pour être réellement bon dans sa tâche.
Le pipeline en 4 étapes :
- Security Gate Agent : contrôle préalable à l’exécution qui valide les autorisations par rapport aux règles du wiki avant le démarrage de la boucle principale.
- Context Extraction Agent : extrait les règles critiques de prompts massifs et précharge les données utilisateur, projet et client.
- Execution Agent : planification de type ReAct avec 5 phases internes (Identity → Threat Detection → Info Gathering → Access Validation → Execution).
- LinkGeneratorAgent : intégré dans l’outil de réponse, il parse le contexte pour inclure les liens d’entité requis.
L’agent LinkGenerator est la partie intéressante. Il corrigeait l’un des modes d’échec les plus fréquents : un agent qui donne la bonne réponse mais oublie les liens de référence obligatoires.
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 d’étapes (équipe NLN7Dw / Ilia Ris)
Cette équipe a combiné SGR avec une inférence très rapide et un validateur en temps réel. Le pari : de nombreuses décisions rapides et validées battent une seule réponse lente et longuement délibérée.
Composants clés :
| Composant | Fonction |
|---|---|
| StepValidator | Inspecte chaque étape proposée. Si quelque chose ne va pas, la renvoie pour reprise avec des commentaires. |
| Gestion du contexte | Plan complet du tour précédent, plus historique compressé pour les tours plus anciens |
| Enrichissement dynamique | Récupère automatiquement profil utilisateur, projets, clients ; le LLM filtre pour n’injecter que les données pertinentes pour la tâche |
| Wrappers d’auto-pagination | Tous les endpoints de liste renvoient automatiquement les résultats complets |
L’avantage en vitesse vient de l’exécution sur Cerebras à environ 3 000 tokens/seconde. À ce rythme, l’agent peut se permettre de reconsidérer une étape au lieu de s’engager sur une première réponse lente issue d’un modèle plus lourd.
Stack : gpt-oss-120b sur Cerebras, avec une implémentation NextStep SGR personnalisée.
4. Système d’enrichisseurs et de garde (équipe J8Gvbi / @mishka)
Cette approche a ajouté à une base SGR des « indices intelligents » non bloquants et un système de garde à plusieurs niveaux. Au retour des réponses API, les enrichisseurs les inspectent et indiquent discrètement à l’agent ce à quoi il faut prêter attention.
Le système d’enrichisseurs :
Plus de 20 enrichisseurs inspectaient les réponses API et injectaient 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 garde à trois modes :
| Mode | Comportement |
|---|---|
| Blocage dur | Actions impossibles bloquées de manière permanente |
| Blocage souple | Actions risquées bloquées à la première tentative, autorisées en cas de nouvelle tentative |
| Indice souple | Guidage sans blocage |
Wiki RAG hybride : trois flux de recherche (regex, sémantique, mot-clé) exécutés en parallèle, avec le meilleur qui l’emporte pour chaque type de requête.
Stack : qwen/qwen3-235b-a22b-2507 sur le framework SGR LangChain.
5. REPL plan-execute (équipe key_concept_parallel)
Cette architecture a imposé une séparation stricte entre planification et exécution, et utilisé une boucle de génération de code. En pratique, un REPL : l’agent planifie une étape, génère du code, l’exécute, puis décide de la suite.
Des modèles différents pour des tâches différentes : un planner planifie, un modèle de génération de code écrit du Python, et un modèle de décision plus petit décide quoi faire après chaque étape.
Configuration multi-modèles :
| Étape | Modèle |
|---|---|
| Planification | openai/gpt-5.1 |
| Génération de code | deepseek/deepseek-v3.2 |
| Décision post-étape | openai/gpt-4.1 |
| Réponse finale | openai/gpt-4.1 |
Le REPL de complétion d’étape :
- Le planner crée une étape de haut niveau.
- Le modèle de génération de code écrit un script Python correspondant.
- Le script s’exécute dans un contexte isolé.
- Le modèle de décision examine le résultat et choisit : continuer, abandonner ou replanifier.
La voie de replanification est là où ce design prend tout son sens. Lorsqu’une étape échoue partiellement, le modèle de décision peut réécrire le reste du plan au lieu de poursuivre aveuglément sur un plan déjà cassé.
Les patterns observés partout
Au-delà des architectures individuelles, quelques habitudes traversaient presque toutes les meilleures soumissions.
La gestion du contexte faisait l’essentiel du travail
Les meilleures équipes ont compris que la qualité du contexte fixe le plafond de performance d’un agent.
| Stratégie | Approche | Idéal pour |
|---|---|---|
| Distillation des règles | Prétraiter le wiki via LLM en résumé d’environ 320 tokens | Prompts légers, démarrage rapide |
| Préchargement agressif | Charger les données utilisateur/projet/client avant l’exécution | Réduire les appels outils |
| RAG hybride | Flux de recherche regex + sémantique + mot-clé | Besoins de récupération complexes |
| Compression de l’historique | Garder les tours récents en entier, compresser l’historique plus ancien | Conversations longues |
Compromis : les équipes Kc7F2N et f1Uixf ont constaté que la qualité du contexte battait la quantité. f1Uixf a même observé que la compression de l’historique dégradait les performances ; l’équipe a donc conservé l’historique complet et s’est appuyée sur des modèles à long contexte.
Garde-fous : plus l’agent est autonome, plus il en a besoin
Les agents les mieux classés étaient aussi ceux qui avaient les contraintes les plus strictes autour d’eux. Cela semble contre-intuitif, mais ce n’est pas le cas. Un agent autonome a davantage de façons d’échouer, donc il a besoin de plus de points de contrôle où quelque chose peut l’arrêter.
| Type de garde-fou | Moment | Exemple |
|---|---|---|
| Portes pré-exécution | Avant le démarrage de la boucle principale | Security Gate Agent valide les autorisations par rapport aux règles du wiki |
| Validateurs dans la boucle | Pendant le raisonnement | StepValidator vérifie chaque action proposée et déclenche une reprise si elle est défaillante |
| Gardes post-exécution | Avant la soumission finale | Le système de garde à trois modes valide la complétude de la réponse |
Wrappers d’outils intelligents
Les meilleures équipes ont construit des couches d’abstraction autour de l’API brute :
- Auto-pagination : les wrappers parcourent toutes les pages et renvoient le dataset complet.
- Normalisation floue : « Willingness to travel » est traduit vers le champ API
will_travel. - Outils de raisonnement spécialisés : outils
think,planetcriticpour une délibération contrôlée.
Modes d’échec fréquents et comment les gagnants les ont corrigés
Même les meilleurs agents partageaient les mêmes angles morts. Les correctifs étaient structurels, pas de simples ajustements de prompt :
| Mode d’échec | Description | Correctif architectural |
|---|---|---|
| Contournement des autorisations | Exécuter des actions restreintes sans vérifier les autorisations utilisateur | Security Gate Agent pré-exécution ; séquence obligatoire Identity → Permissions → Execution |
| Liens d’entité manquants | Réponse textuelle correcte mais sans les liens de référence requis | LinkGeneratorAgent intégré dans l’outil de réponse |
| Épuisement de pagination | Traitement de la seule première page de résultats de liste | Wrappers d’auto-pagination pour tous les endpoints de liste |
| Boucles d’appels d’outils | Blocage dans des appels répétés au même outil avec de légères variations | Limites de tours ; modèles centrés raisonnement (Qwen3) |
| Surcharge de contexte | Remplir le contexte avec des sections de wiki non pertinentes | Distillation des règles ; filtrage dynamique du contexte |
Ce qu’il faut retenir
Si vous construisez des agents et voulez appliquer cela :
- Utilisez des pipelines multi-agents. Les agents monolithiques ont perdu. Les meilleures équipes utilisaient 3 à 5 spécialistes pour la sécurité, l’extraction de contexte, la planification et l’exécution.
- Automatisez l’itération sur les prompts. Le prompt gagnant était en version 80. Une boucle trouvera des patterns d’échec que vous n’auriez jamais vus.
- Investissez réellement dans les garde-fous. Contrôles de sécurité préalables, critiques dans la boucle et gardes post-exécution. Les agents qui semblaient les plus autonomes étaient les plus encadrés.
- Encapsulez vos outils. Pagination, enrichissement de données et fuzzy matching doivent être dans des wrappers. Une équipe a construit plus de 20 enrichisseurs qui surveillaient les réponses API en direct.
- Prenez la stratégie de contexte au sérieux. Distillation des règles (résumés d’environ 320 tokens), préchargement et filtrage dynamique. La vitesse aide aussi. Une équipe tournait à ~3 000 tokens/seconde, ce qui lui permettait de replanifier souvent.