Orchestration multi-niveaux : comment Scabera coordonne les agents IA
La plupart des IA d'entreprise se résument à un modèle unique répondant à des questions. Une requête arrive, la récupération s'exécute sur l'ensemble de la base de connaissances, les k meilleurs résultats atterrissent dans la fenêtre de contexte, et le modèle génère une réponse. Pour des requêtes simples et monodomaînes, cela fonctionne. Pour les questions complexes et transdomaines qui alimentent réellement les décisions en entreprise, le résultat est systématiquement insuffisant.
L'échec n'est pas un problème de capacité du modèle. C'est un problème architectural. Un seul passage de récupération sur une base de connaissances large et hétérogène est un instrument rudimentaire. Il retourne ce qui est le plus proche dans l'espace d'embedding, et non ce qui est le plus pertinent dans les multiples domaines de connaissance qu'une question complexe requiert réellement.
Le plafond du modèle unique
Prenez une requête d'entreprise réaliste : « Quelle est notre politique en matière de remises pour les clients entreprise en APAC, et diffère-t-elle de nos conditions standard pour les clients mid-market ? »
Répondre correctement à cette question nécessite trois domaines de connaissance distincts : la politique d'autorisation des remises (probablement dans un document de politique commerciale), les critères de classification des comptes APAC (possiblement dans un guide CRM régional ou un document de gestion des territoires) et les définitions des niveaux entreprise et mid-market (possiblement dans un document de tarification ou un manuel de vente). Un seul passage de récupération manquera presque certainement au moins l'un d'eux. La récupération est optimisée pour la similarité sémantique avec la chaîne de requête complète — et les documents les plus sémantiquement proches pourraient être une vue d'ensemble générale de la « gestion des comptes entreprise » qui aborde les trois sujets à haut niveau, plutôt que les documents de politique spécifiques contenant les réponses faisant autorité.
Le modèle reçoit un contexte incomplet. Il génère une réponse au ton confiant qui mélange les informations récupérées avec des interpolations issues de ses données d'entraînement. Certaines parties de la réponse sont correctes. D'autres sont plausibles mais fausses. L'utilisateur n'a aucun moyen fiable de distinguer les deux.
Étendez cela à une base de connaissances comportant des milliers de documents, des dizaines de domaines et des années de contenu accumulé — et le bruit de récupération d'un modèle unique devient un problème de fiabilité, et pas seulement un écart de précision.
Ce que l'orchestration signifie réellement
L'orchestration multi-agents ajoute une couche entre la requête de l'utilisateur et la récupération : un système de routage qui classe les requêtes par domaine et par intention avant toute récupération de document.
Le classifieur analyse la requête entrante et identifie les domaines de connaissance qu'elle touche. Une requête sur les clauses contractuelles est acheminée vers un agent spécialisé en connaissance juridique. Une requête sur l'intégration API est dirigée vers un agent de documentation technique. Une requête touchant plusieurs domaines — comme l'exemple de la politique de remises ci-dessus — est décomposée en sous-questions, chacune acheminée vers l'agent spécialiste approprié.
Chaque agent spécialiste opère sur une base de connaissances délimitée : uniquement les documents de son domaine. Cela réduit considérablement le bruit de récupération. L'agent juridique ne cherche pas dans la documentation produit. L'agent de politique commerciale ne tire pas des runbooks d'ingénierie. La spécialisation est ce qui permet la précision.
Un agent coordinateur se place au-dessus des spécialistes. Lorsqu'une requête nécessite plusieurs agents, le coordinateur lance les agents spécialistes en parallèle, collecte leurs résultats et synthétise une réponse unifiée. L'utilisateur voit une seule réponse. Le système a effectué le travail de plusieurs experts du domaine.
La couche de routage en pratique
L'étape de routage est celle où la plupart des systèmes d'orchestration réussissent ou échouent. Un routage naïf — correspondance de mots-clés ou classification simple — produit des erreurs de routage qui se propagent dans tout le pipeline. Une erreur de routage signifie que le mauvais agent récupère dans le mauvais domaine de connaissance. Le spécialiste produit une réponse confiante mais non pertinente. Le coordinateur la synthétise dans la réponse finale. L'erreur est invisible.
Un routage efficace utilise une combinaison de classification par embedding de requête, de détection d'intention et d'extraction d'entités pour déterminer la couverture des domaines. Le classifieur est entraîné sur des exemples issus des domaines de connaissance réels de l'organisation — pas sur des catégories génériques — afin que les décisions de routage reflètent la structure spécifique de la base de connaissances.
En pratique, le flux pour une requête multidomaine ressemble à ceci : la requête entrante est analysée par le coordinateur, qui identifie trois domaines se chevauchant. Trois agents spécialistes sont lancés en parallèle : l'agent A recherche dans l'index des politiques commerciales, l'agent B dans l'index de classification des comptes, l'agent C dans l'index des définitions de tarification et de niveaux. Les trois terminent la récupération et la génération indépendamment, produisant des sorties avec leurs propres ensembles de citations. Le coordinateur reçoit trois sorties structurées et synthétise une réponse unifiée qui réconcilie les éventuels conflits, couvre les trois dimensions et attribue chaque affirmation factuelle à son agent source et à son document.
Lorsque les agents retournent des informations contradictoires — un document de politique dit une chose, une révision plus récente dit autre chose — le coordinateur fait remonter le conflit explicitement plutôt que de le résoudre silencieusement. L'utilisateur voit : « La Politique commerciale T3 (v2.1) indique X, mais la révision mise à jour T4 (v2.3) indique Y. La version la plus récente s'applique. » C'est une réponse plus utile qu'une synthèse confiante qui aurait choisi silencieusement l'une des deux.
L'intégrité des citations entre les agents
Le difficile problème technique du RAG multi-agents est de maintenir une piste de citations propre et vérifiable lorsque plusieurs agents contribuent à une seule réponse.
Dans un système RAG monolithique, les citations sont simples : chaque affirmation renvoie à un passage du contexte récupéré. Dans un système multi-agents, le coordinateur synthétise les sorties de plusieurs agents, chacun ayant son propre contexte récupéré et son propre ensemble de citations. Si l'étape de synthèse n'est pas soigneusement conçue, les citations des différents agents sont fusionnées, confondues ou tout simplement supprimées. La réponse finale semble citée, mais la piste de citations est rompue.
La solution consiste à traiter chaque sortie d'agent comme un objet structuré et étiqueté plutôt que du texte libre. Avant la synthèse, la sortie de chaque agent porte des métadonnées : quel agent l'a produite, quels documents il a récupérés et quels passages étayent quelles affirmations. L'étape de synthèse du coordinateur opère sur ces objets structurés, et non sur du texte brut. Lorsqu'une affirmation de l'agent A apparaît dans la réponse finale, la citation pointe vers le document source de l'agent A — et non vers un « contexte récupéré » générique.
Cette architecture rend le graphe de citations traçable de bout en bout. Une entrée de journal d'audit pour toute sortie peut reconstituer : la requête d'origine, les agents invoqués, les documents récupérés par chaque agent, et exactement quel passage est attribué à chaque phrase de la réponse finale. Dans les environnements réglementés, ce niveau de traçabilité n'est pas une fonctionnalité. C'est une exigence.
Pourquoi cela passe à l'échelle là où le RAG monolithique ne le fait pas
À mesure qu'une base de connaissances s'agrandit, la récupération monolithique se dégrade. Plus de documents signifie plus de bruit de récupération. Plus de bruit signifie plus de risque d'hallucination. La solution à laquelle la plupart des équipes recourent est d'augmenter le nombre de fragments récupérés — en transmettant plus de contexte au modèle. Mais une fenêtre de contexte plus large ne corrige pas une récupération bruyante ; elle l'amplifie. Le modèle a plus de contenu non pertinent à parcourir et plus d'occasions de synthétiser incorrectement.
L'orchestration multi-agents inverse cette relation. À mesure que la base de connaissances s'agrandit, vous ajoutez des agents spécialistes et affinez les limites des domaines plutôt que d'augmenter la portée de la récupération. Chaque agent continue d'opérer dans un espace plus restreint et bien défini. La précision de la récupération reste élevée parce que chaque agent effectue ses recherches dans un sous-ensemble sélectionné, et non dans l'ensemble du corpus. Le coordinateur reçoit des entrées plus propres et produit une synthèse plus fiable.
C'est pourquoi les systèmes RAG d'entreprise qui doivent rester précis à l'échelle optent presque toujours pour l'orchestration. La contrainte architecturale — spécialisation avant synthèse — est ce qui maintient une haute précision à mesure que la base de connaissances s'étend. Les déploiements RAG privés bénéficient particulièrement de cette approche, car l'ensemble du pipeline de récupération s'exécute sur votre propre infrastructure : vous contrôlez la manière dont les connaissances sont partitionnées, la portée des agents et la journalisation des citations. Le résultat est un système IA qui devient plus performant à mesure que vos connaissances s'enrichissent, et non un système qui devient plus bruyant et moins fiable.