Forts de plus de 20 ans d'expérience, nous transformons votre présence numérique. Nous sommes spécialisés dans la création de sites web et de boutiques en ligne, le référencement naturel (SEO) et le marketing numérique, les logiciels ERP et les automatisations intelligentes qui permettent à votre entreprise de prendre son envol.
SchemaRouter : comment les agents IA trouvent les bonnes données sans contexte superflu
SchemaRouter montre comment les agents IA choisissent correctement les outils et les champs, réduisent le contexte et conservent la provenance, les unités et les licences d'utilisation.
Un agent fiable ne demande que les champs dont il a besoin et conserve, en plus de ceux-ci, l'origine, l'unité et l'autorisation.
Réponse d'abord : SchemaRouter montre qu'un agent IA n'a pas besoin de consulter l'intégralité du répertoire des API ni de récupérer tous les champs disponibles pour répondre correctement. Il lui suffit d'un petit plan d'exécution qui sélectionne les bons outils, conserve les champs essentiels et transfère avec eux les unités, la provenance et la licence d'utilisation.
Dans le benchmark de ce travail, l'approche a atteint une précision de réponse de 0,71 avec 227 tokens de contexte récupérés, contre 2 066 tokens pour la méthode « fetch-all », avec une précision de 0,70. Ce résultat porte sur 110 questions relatives à la science des matériaux et ne démontre pas une supériorité universelle. Il offre toutefois un enseignement architectural spécifique pour les agents connectés à des systèmes de gestion de la relation client (CRM), à des outils d'analyse, à des catalogues de commerce électronique, à des bases de données et à des API externes.
Plus un agent IA dispose d’outils, plus une décision apparemment simple devient difficile : quel outil doit-il appeler, avec quels paramètres, et quels champs précis doit-il renvoyer ? Dans un simple chatbot, le modèle répond à partir du contexte qui lui est fourni. Dans un système RAG agentique, il doit d’abord décider où chercher, puis transformer ce choix en un appel valide.
Une requête peut nécessiter une combinaison d'une base de données interne, d'un magasin de vecteurs, d'un magasin de graphes et d'une API externe. Le choix ne se limite pas au nom de l'outil : chaque point de terminaison présente des paramètres obligatoires, des champs de réponse, des unités, des sources et des restrictions d'utilisation différents. Si l'un de ces éléments vient à manquer, le plan peut être pertinent d'un point de vue sémantique, mais techniquement irréalisable.
Le travail de recherche SchemaRouter : routage par outil tenant compte des champs pour un RAG hétérogène et agentique efficace, publié sur arXiv le 3 juillet 2026, propose une couche intermédiaire de routage. Un petit LLM extrait l’intention et les concepts clés ; ensuite, des règles déterministes basées sur un schéma de graphe sélectionnent les outils et les domaines. Cette distinction est cruciale, car la diagnostic d'une défaillance d'un agent IA Il faut savoir si le problème vient de la compréhension, du plan, de l'appel d'outil ou du lecteur en aval.
Pourquoi le « prompt-all », l'« over-fetch » et l'« under-fetch » posent des problèmes différents
La stratégie prompt-all place toutes les descriptions d'outils et de champs dans l'invite de routage. Cette approche peut s'avérer efficace avec un modèle puissant, mais le schéma se répète à chaque appel et s'allonge à mesure que l'inventaire s'étoffe. Dans l'étude, le catalogue comptait 19 outils et 166 champs de réponse. À lui seul, le segment de schéma comptait 5 042 caractères, soit environ 1 260 tokens en partant de l'hypothèse simplifiée de quatre caractères par token.
Les auteurs estiment de manière détaillée une augmentation d'environ 66 tokens de routage par outil supplémentaire : environ 6 600 tokens pour 100 outils et 33 000 pour 500. Il s'agit d'une estimation basée sur l'inventaire des 19 outils, et non d'une mesure issue de déploiements de cette ampleur. La mise en cache des invites peut réduire le coût d’entrée d’un schéma fixe, mais elle ne supprime pas la nécessité de prêter attention au préfixe complet et ne résout pas non plus les problèmes liés aux changements d’outils, de versions ou d’autorisations.
Les surchargement C'est un autre problème : l'agent appelle davantage d'outils ou renvoie plus de champs que nécessaire. Cela augmente la charge utile, le contexte et le risque que des données sensibles ou contradictoires parviennent au lecteur. Le sous-extraction elle laisse de côté un aspect essentiel et peut conduire à une réponse convaincante mais incomplète. La protection contre injection indirecte de prompt dans des sources externes un contrôle distinct est nécessaire ; un taux de récupération plus faible limite la portée, mais ne prouve pas que le contenu soit fiable.
Prompt-all
Il fournit au modèle l'intégralité du schéma d'outils à chaque appel de routage. Cela offre une grande visibilité, mais la taille de l'invite augmente à mesure que l'inventaire s'étoffe.
Schéma completCoût de routage élevé
Uniquement vectoriel
Il trouve des outils proches sur le plan sémantique, mais peut présenter des lacunes en matière de paramètres obligatoires, de champs de réponse et d'exécutabilité.
SimilitudeRisque d'« under-fetch »
SchemaRouter
Il utilise un petit modèle de langage (LLM) pour la compréhension et une projection de champ déterministe pour générer des plans d'outils valides et tenant compte des métadonnées.
Sensible au champPlan d'exécution
Le « schema graph » transforme les API en une carte fonctionnelle
SchemaRouter représente sous forme de nœuds les éléments suivants : Tool, Endpoint, Parameter, ResponseField, DomainConcept, Unit, SourceType, LicensePolicy, FieldGroup et Intent. Les arêtes relient les endpoints aux paramètres et aux champs, les champs aux unités, aux sources et aux concepts, ainsi que les expressions naturelles aux noms de champs canoniques. Le système ne se contente pas de stocker des descriptions textuelles ; il enregistre les relations qui déterminent quelle requête est valide et ce que signifie chaque réponse.
Ce concept s'apparente au « schema linking » de text-to-SQL, mais s'applique à un environnement comportant de nombreux outils hétérogènes. Elle ne se contente pas d'aligner des mots sur les colonnes d'une base de données. Elle relie des requêtes à des champs de nombreuses API et conserve des métadonnées que le lecteur en aval ne peut pas reconstituer en toute sécurité à partir de connaissances paramétriques.
Le « production graph » qui a inspiré cette étude est propriétaire. L'article mentionne une exportation JSON figée, un cadre d'évaluation et un référentiel permettant de reproduire les résultats. Lors d'une vérification effectuée le 14 septembre 2026, cependant, le lien GitHub indiqué renvoyait une erreur HTTP 404. Par conséquent, l’article fonde ses mesures sur l’article complet et ne présente pas le référentiel comme un document public accessible.
Comment est généré un plan d'outillage exécutable ?
Dans un premier temps, un petit LLM extrait l'intention, les concepts du domaine, les valeurs des paramètres, les contraintes de source et les outils explicitement mentionnés. Si l'utilisateur nomme un outil, celui-ci prévaut. Sinon, les candidats sont filtrés en fonction du domaine de l'intention et des groupes de champs requis. Une contrainte de source peut, par exemple, distinguer les données expérimentales, calculées ou issues de la littérature.
La sélection des champs s'effectue ensuite de manière déterministe. Elle inclut les identifiants, les correspondances concept-champ et les groupes de champs qui font office de filet de sécurité pour le rappel. La couche d'alias fait le lien entre la langue de l'utilisateur et les noms de champs canoniques : un terme de domaine peut être associé au nom exact compris par l’API. Enfin, le schéma associe une unité, un type source et une licence à chaque champ concerné.
Le fait qu'un système soit « valide dès sa conception » ne signifie pas que la politique d'entreprise soit automatiquement mise en œuvre. Cela signifie que les champs proviennent du schéma déclaré et que les paramètres proviennent de l'ensemble accepté par le point de terminaison. L'authentification, l'autorisation, le consentement, les limites de débit, la minimisation des données et les contrôles d'approbation doivent être imposés par les couches de politique et d'exécution correspondantes. La protection des données dans le CRM sans entraver les activités marketing exige précisément cette distinction entre le domaine d'utilisation et l'accès autorisé.
Que mesure réellement le benchmark des 110 questions ?
L'évaluation comprend 110 questions relatives à la science des matériaux réparties en neuf catégories : 36 recherches de propriétés à l'aide d'un seul outil, 12 recherches chimiques, 12 requêtes sensibles à la provenance, 10 requêtes multi-domaines, 10 recherches bibliographiques, 8 comparaisons entre sources, 8 requêtes sensibles aux unités, 8 requêtes négatives sans outil approprié et 6 requêtes ambiguës portant sur une seule entité.
Le « frozen inventory » couvre 19 outils hétérogènes et 166 champs de réponse : bases de données sur les propriétés des matériaux, PubChem, API bibliographiques, une source d’annonces commerciales et des solutions de repli sur le Web ou sous forme de questions-réponses. Les données en aval sont des fixtures structurées et déterministes. Ce choix facilite la comparaison contrôlée, mais sous-estime le bruit, le désordre et les éventuelles injections de prompt que l'on rencontre dans un corpus réel.
L'étude ne se limite pas à la précision de l'outil ou au champ F1. Elle évalue la validité des paramètres, le taux de plans exécutables, les tokens de contexte récupérés, la latence de bout en bout, la précision finale de la réponse et vérifie si la réponse transmet la provenance et la licence. C’est là le niveau approprié pour un agent de production : le routeur n’est pas performant parce qu’il génère un plan « élégant », mais parce qu’il contribue à ce que la réponse finale soit correcte, rapide et vérifiable.
Les résultats : une précision comparable à celle de la concurrence avec beaucoup moins de contexte
SchemaRouter a atteint une précision de réponse de 0,71 avec un intervalle de confiance à 95 % compris entre 0,63 et 0,79, un rappel de champ de 0,86, 227 tokens de contexte récupérés et une latence de bout en bout de 5,5 secondes. La méthode « fetch-all » a affiché une précision de 0,70, mais a utilisé 2 066 tokens et pris 4,9 secondes. La méthode « prompt-all » a affiché une précision de 0,66, 207 tokens de contexte récupérés et une latence de 15,1 secondes.
Le point de fonctionnement du SchemaRouter
Ces chiffres concernent exclusivement le benchmark de 110 questions et ne constituent en aucun cas une garantie pour chaque déploiement d'AGENTIC RAG.
0,71précision des réponses avec des intervalles de confiance qui se chevauchent
227tokens de contexte récupérés
0,93taux « tool-exact » dans le tableau de base
62%réponses accompagnées d'une mention de licence « schema-only »
La différence la plus marquée réside dans l'efficacité et la validité du plan. SchemaRouter a affiché un taux de précision « tool-exact » de 0,93 et une validité des paramètres de 1,00 dans le tableau de référence des métriques de planification. Il a utilisé environ neuf fois moins de tokens de contexte récupérés que la méthode « fetch-all », sans perte mesurable de précision dans cette configuration particulière. Par rapport à la méthode « prompt-all », le temps de traitement de bout en bout était environ 2,7 fois plus court.
Pourquoi le nombre minimum de champs est un mauvais indicateur de performance clé (KPI)
L'une des conclusions les plus utiles est que la minimisation extrême des champs nuit au résultat en aval. Au point de fonctionnement à champ minimal, la précision est tombée à 0,56 avec 188 tokens de contexte récupérés. Lorsque des groupes de champs pertinents pour l'intention ont été ajoutés comme filet de sécurité pour le rappel, la précision est remontée à 0,71, tandis que le nombre de tokens n'a augmenté qu'à 227.
Le cours ne consiste pas à « fournir davantage de données ». Il s’agit plutôt de trouver que le bon objectif d’optimisation allie la qualité de la réponse et le coût réel du contexte. Une métrique basée sur le nombre de champs considère tous les champs comme équivalents, alors qu’un identifiant court et un champ textuel volumineux ont une empreinte de tokens très différente. Le plan le plus court peut sembler efficace tout en omettant l’élément qui permet au lecteur de répondre.
Pour les équipes produit et données, les tableaux de bord doivent établir un lien entre les indicateurs de routage et le taux de réussite des réponses, la latence, l'utilisation des jetons, les appels non valides et les échecs liés à des champs manquants. De même, les Les agents IA multimodaux doivent faire l'objet d'une vérification après la perception: un plus grand nombre d'entrées ne garantit pas un fonctionnement correct, mais une suppression trop radicale du contexte ne garantit pas non plus que les informations essentielles seront conservées.
Provenance, licences et sécurité des données
La différence la plus marquée au niveau des réponses concerne la traçabilité. SchemaRouter a inclus des citations de licence « schema-only » dans 62 % des réponses non négatives. La mention de la licence et la déclaration du type de source ont toutes deux atteint 94 %. Les références de base présentaient un taux de citations « schema-only » quasi nul, car ces chaînes de licence spécifiques n'existaient pas dans le document reçu par le lecteur.
En matière de marketing, de commerce électronique et de gestion de contenu, ce principe va au-delà de la science des matériaux. Lorsqu’un agent utilise des flux de produits, des ressources DAM, des données clients ou des études de marché sous licence, la provenance et les conditions d’utilisation ne doivent pas être ajoutées a posteriori sous forme de note de bas de page. Elles doivent accompagner le contenu tout au long de son parcours, depuis le registre jusqu’à la sortie finale. Il s’agit d’une interprétation architecturale, et non d’un résultat inter-domaines démontré par le benchmark.
Une réponse API plus concise peut également réduire le risque d'exposition excessive des données, mais uniquement si la sélection des champs est imposée côté serveur et associée à une autorisation par propriété d'objet. Un routeur qui « demande » moins de champs ne remplace pas les contrôles d’accès. La spécification MCP précise également que les annotations des outils ne sont que des indications et ne doivent pas être considérées en elles-mêmes comme une description fiable du comportement.
Porte de production pour les agents sensibles au contexte
Le schéma sélectionne les données ; la politique détermine si elles sont autorisées
Associez chaque point de terminaison et chaque champ de réponse aux champs « propriétaire », « sensibilité », « finalité autorisée », « rôle », « source », « unité », « licence » et « durée de conservation ». N'exécutez le plan qu'après avoir passé les contrôles d'autorisation et de minimisation des données, et conservez une trace de la requête, de la version du schéma sélectionnée, des champs renvoyés et de la réponse finale.
En quoi SchemaRouter présente-t-il encore des lacunes ?
Les autres erreurs se répartissent principalement entre un mauvais choix d’outil pour les entités ambiguës et des erreurs du lecteur. Dans les requêtes ambiguës portant sur une seule entité, le « concept matcher » a du mal à déterminer la source appropriée en l'absence de nom explicite. La couche d'alias nécessite une maintenance humaine à mesure qu'un domaine s'étend ; par conséquent, cette approche ne supprime pas la gouvernance du schéma.
Il existe des limites importantes en termes de validité. Le benchmark comporte 110 requêtes, est axé sur la science des matériaux, a été créé par un seul annotateur et utilise des « fixtures » structurées et figées à la place de véritables documents. L'évaluation a été réalisée en une seule exécution avec Qwen-3.5 122B auto-hébergé, à une température de zéro et avec le raisonnement désactivé. C’est la même famille de modèles qui a généré et évalué les réponses, tandis qu’un examen ponctuel inter-familles n’a été effectué que sur 40 échantillons.
Les mesures de latence proviennent d'un serveur partagé et surchargé ; elles sont données à titre indicatif. Les résultats nécessitent une réplication multi-seed, multi-modèle et inter-domaines. De plus, l'article défend un routage indépendant de la taille du schéma, mais la maintenance du graphe, des alias, des groupes de champs et des politiques reste un véritable coût organisationnel.
Qu'est-ce que cela signifie pour le CRM, le commerce électronique et les agents marketing ?
Un agent commercial peut être connecté à un catalogue, un entrepôt, une tarification, des commandes, des avis et des plateformes publicitaires. La question « quel produit présente un potentiel de promotion ? » nécessite des champs spécifiques et peut-être des autorisations d’accès différentes de celles requises pour « quelle campagne a généré le meilleur ROAS ? ». Si toutes les descriptions et toutes les données sont systématiquement chargées, le contexte s’élargit. Si l’on ne sélectionne que l’outil le plus proche sur le plan sémantique, le coût du produit ou la fenêtre d’attribution peuvent faire défaut.
Un registre « field-aware » peut indiquer quels champs sont requis pour chaque intention, leurs unités, leur source, leur actualité et leurs contraintes d'accès. Pour une requête CRM, par exemple, le plan peut nécessiter le stade du cycle de vie et le dernier contact autorisé, mais pas l'historique complet des notes ni les informations non pertinentes par rapport à l'objectif. Pour la disponibilité d'un produit, il faut le SKU, l'état des stocks et l'horodatage, et non l'intégralité de l'objet de la commande.
La mise en œuvre en production nécessite la mise en œuvre de mesures de confidentialité et d'autorisation, qui ne font pas l'objet de cet article. Il faut également prévoir un plan de secours lorsqu'un point de terminaison change de schéma, lorsque la source est obsolète ou lorsque le plan n'atteint pas un seuil de confiance. Les Les agents IA en entreprise doivent être considérés comme des logiciels ayant leurs limites, et non pas en tant que « collègues » qui comblent arbitrairement les lacunes.
Un projet pilote en sept étapes pour le routage tenant compte du contexte
Le projet pilote doit partir d'une décision ciblée, dont le coût d'échec est mesurable, et non de l'ensemble de l'inventaire des API de l'entreprise. Un premier cas d'utilisation approprié est une requête en lecture seule dans un catalogue, un outil d'analyse ou une base de connaissances d'assistance, où les réponses correctes sont connues et où il existe une solution de secours sûre.
Sept étapes pour passer de l'inventaire à un shadow run sécurisé
Étape 1Définissez un objectif commercial
Précisez quelle question l'agent doit répondre, quelles données il n'a pas le droit de consulter, qui en est le propriétaire et quel est le coût d'une erreur ou d'un retard.
Étape 2Cartographier les outils et les terminaux
Enregistrez la méthode, les paramètres requis, les champs de réponse, les limites de débit, les versions et les modes de défaillance uniquement pour les systèmes concernés par cet intent.
Étape 3Joindre des métadonnées par champ
Indiquez le nom canonique, les alias, l'unité, le type de source, la date de mise à jour, la licence, le niveau de confidentialité et le rôle requis. Ne saisissez pas les autorisations sous forme de texte libre dans l'invite.
Étape 4Voici les groupes de champs critiques pour le rappel
Identifiez les identifiants et les petits groupes de champs nécessaires comme « filet de sécurité », afin que la minimisation ne se transforme pas en sous-extraction.
Étape 5Créez une suite de requêtes Gold
Ajoutez simplement des requêtes simples, polyvalentes, sensibles à la provenance, ambiguës et négatives, pour lesquelles la bonne décision consiste à ne pas effectuer d'appel inapproprié.
Étape 6Comparer les références en aval
Évaluez les méthodes « prompt-all », « similarity routing » et « fetch-all » contrôlé en fonction de la précision des réponses, de la validité de l'exécution, des jetons de contexte, de la latence, de l'exhaustivité des métadonnées et de l'exposition des données.
Étape 7Exécutez le mode « shadow » et la surveillance versionnée
Enregistrez la requête, la version du schéma, le plan d'exécution, les champs renvoyés, la réponse et la correction humaine avant d'autoriser toute action d'écriture ou tout impact autonome sur les clients et le budget.
Les Automatisation des processus métier et IA chez TWO DOTS commencent par la cartographie des processus, des données, des responsables et des points de contrôle. Pour un projet pilote de type SchemaRouter, l’intérêt ne réside pas dans l’ajout d’une couche d’abstraction supplémentaire, mais dans la démonstration que le plan réduit le contexte superflu sans omettre de champs essentiels ni contourner les politiques.
L'essentiel : le plus petit ensemble suffisant et contrôlable
SchemaRouter ne démontre pas qu’un graphe de schémas soit la meilleure solution pour tous les systèmes RAG agentiques. Il montre toutefois que le choix des champs de réponse mérite d’être considéré comme un problème architectural à part entière. Dans ce benchmark particulier, le routage préservant le recall a maintenu une précision compétitive avec beaucoup moins de contexte récupéré que la méthode « fetch-all » et avec des informations plus riches sur l'origine et les autorisations.
Pour les entreprises, l'objectif idéal n'est ni « toutes les données », ni « le moins possible ». C’est le plus petit ensemble suffisant, exploitable, autorisé et contrôlable qui permette d’obtenir une réponse correcte. Cela nécessite des indicateurs qui couvrent l'ensemble du parcours : intention, choix de l'outil, validation des paramètres, projection sur le terrain, autorisation, extraction, réponse et vérification humaine.
Si le schéma graphique reste versionné, que les alias sont gérés par les propriétaires de domaine et que les autorisations sont appliquées en dehors du modèle, cette approche peut constituer un point de contrôle utile. Si elle est considérée uniquement comme une technique de réduction du nombre de tokens, elle risque d'optimiser le mauvais indicateur et de transférer la complexité vers un registre dont personne ne se charge de la maintenance.
De l'API « inventory » à un projet pilote contrôlé
Concevez des agents IA qui demandent les bonnes données
TWO DOTS cartographie les intentions, les outils, les champs de réponse, les autorisations, la validation et la surveillance, afin qu'un workflow d'IA puisse réduire le contexte superflu sans perdre d'informations essentielles ni le contrôle.
Il s'agit d'une couche de routage de recherche qui organise les outils, les points de terminaison, les paramètres, les champs de réponse et les métadonnées dans un graphe de schéma et génère des plans d'outils exécutables.
Quel problème cherche-t-il à résoudre ?
Il s'efforce de limiter à la fois l'« over-fetching », qui fait apparaître des outils ou des champs superflus, et l'« under-fetching », qui omet des informations indispensables à une réponse correcte.
En quoi cela diffère-t-il du routage par similarité vectorielle ?
La fonction « similarity » peut trouver un outil adapté, mais ne garantit pas la validité des paramètres ni la suffisance des champs de réponse. SchemaRouter applique une sélection déterministe des champs sur le graphe.
Quels résultats a-t-il obtenus lors du test de performance ?
Sur 110 questions, il a atteint une précision de réponse de 0,71 avec 227 tokens de contexte extraits, un taux d'exactitude de l'outil de 0,93 et une validité des paramètres de 1,00 dans le tableau principal de l'étude.
S'avère-t-il être le routeur le plus précis ?
Non. Les intervalles de confiance des meilleurs routeurs se chevauchent. Ce travail met principalement l'accent sur l'efficacité contextuelle, les plans exécutables et les métadonnées de provenance ou de licence.
Pourquoi le nombre minimum de champs est-il un mauvais indicateur de performance clé (KPI) ?
En effet, au point de fonctionnement « minimal-field », la précision est tombée à 0,56. L'ajout de groupes de champs « recall-critical » l'a ramenée à 0,71, avec une légère augmentation du nombre de tokens, qui est passé de 188 à 227.
SchemaRouter impose-t-il des autorisations et des règles de confidentialité ?
Pas en soi. Le schéma peut véhiculer des métadonnées pertinentes, mais l'autorisation, le consentement, la minimisation des données et les contrôles d'approbation doivent être imposés par les couches de politique et d'exécution.
Quelle est la première étape à suivre pour mettre en place un projet pilote ?
Sélectionnez un intent en lecture seule restreint, répertoriez les endpoints et les champs nécessaires, puis créez des requêtes de référence comprenant des réponses correctes, des cas ambigus et des exemples négatifs fiables.