Une pratique est populaire actuellement dans le secteur de l'IA : donner à un modèle de langage l'accès à des outils et le laisser choisir lesquels appeler. Cela fonctionne magnifiquement en démonstration. Cela s'effondre en production.
Chez Atlas Verified, notre agent IA accède à plus de 100 outils spécialisés — bases gouvernementales de conformité, API de suivi des navires, services de contrôle des sanctions, fournisseurs de données commerciales, suivi des conteneurs et autres. Chaque outil existe parce qu'un professionnel a besoin de cette donnée précise pour décider d'une vérification. Le défi technique est de garantir l'appel des bons outils, dans le bon ordre, avec les bonnes entrées, à chaque fois, au-delà de leur construction.
Cet article détaille les problèmes réels d'orchestration à grande échelle et les méthodes techniques que nous avons développées pour les résoudre.
Le problème de la multiplication des outils
Lorsque votre agent dispose de 5 outils, la sélection est simple. Le modèle lit leurs descriptions, choisit le bon et l'appelle. Mais quelque chose se dégrade au-delà de 20, 50, 100 outils.
D'abord, il y a le problème de la fenêtre de contexte. Chaque outil exige une description, un schéma de paramètres et des consignes d'utilisation dans l'instruction système. À 100+ outils, des dizaines de milliers de jetons sont consommés avant même que la question de l'utilisateur entre dans le contexte. Le modèle passe plus de temps à lire les documents des outils qu'à réfléchir au problème.
Ensuite vient l'exactitude de la sélection. Les modèles de langage choisissent bien entre quelques options clairement distinctes. Ils choisissent mal entre des dizaines d'outils aux descriptions similaires. Avec plusieurs outils aux noms proches pour le contrôle des sanctions, le modèle choisit souvent le mauvais — ou appelle plusieurs outils renvoyant des données qui se recoupent.
Enfin viennent le coût et la latence. Chaque description d'outil consomme des jetons. Chaque appel inutile entraîne des appels d'API externes, souvent facturés à la requête. Un agent qui appelle 8 outils quand 3 suffiraient est coûteux et lent.
Pourquoi le routage statique ne fonctionne pas
La solution naïve est le routage statique : reconnaître des schémas dans la question et diriger vers des ensembles d'outils prédéfinis. « Vérifiez cette entreprise » déclenche le contrôle des sanctions. « Suivez ce conteneur » déclenche le suivi des navires. « Vérifiez ce certificat » déclenche la recherche USDA.
Cela échoue immédiatement en pratique. Prenons « Pouvez-vous vérifier ce certificat biologique d'Inde ? ». Un routeur statique peut lancer une recherche dans la base biologique USDA — c'est raisonnable. Mais un professionnel veut aussi savoir : l'organisme certificateur est-il sanctionné ? Existe-t-il des alertes FDA actives pour ce produit et ce pays ? L'exportateur figure-t-il sur des listes de parties interdites ? L'itinéraire déclaré présente-t-il des anomalies commerciales ?
Une question peut légitimement exiger cinq outils ou davantage dans des domaines totalement différents. Le routage statique manque des contrôles critiques ou déclenche tout excessivement, ramenant les problèmes de coût et d'exactitude.
Le contexte compte énormément. « Parlez-moi de cette entreprise » signifie des choses complètement différentes selon que l'utilisateur examine un connaissement, un certificat biologique ou mène une recherche générale. Les mêmes mots exigent des outils différents selon le contexte.
Architecture à deux couches : sélection et exécution
Notre solution sépare la sélection des outils de leur exécution grâce à deux couches de modèles distinctes.
La couche de sélection utilise un modèle rapide et peu coûteux. Son seul rôle est d'examiner la question, le contexte de conversation et un manifeste compact des outils disponibles, puis de choisir ceux à rendre accessibles pour cette interaction précise. Elle ne les appelle pas — elle décide simplement de ceux auxquels le modèle d'exécution devrait accéder.
Le modèle de sélection voit une représentation simplifiée de chaque outil : description d'une ligne, données renvoyées et limites. C'est bien plus compact que les schémas complets de paramètres ; il peut donc évaluer les 100+ outils sans atteindre les limites de contexte. Il sélectionne généralement 8-12 outils pertinents pour la question actuelle.
La couche d'exécution utilise un modèle de raisonnement plus performant. Elle reçoit uniquement les outils choisis par la sélection, avec schémas complets et consignes. En travaillant sur un ensemble ciblé plutôt que sur tout le catalogue, elle décide mieux lesquels appeler, dans quel ordre et avec quels paramètres.
Cette séparation apporte des bénéfices mesurables. La sélection prend une fraction de seconde et coûte très peu. Le modèle d'exécution voit un contexte clair et ciblé et fait moins d'erreurs. Le nombre total d'appels par interaction a considérablement baissé depuis cette architecture.
Filtrage par capacités
Au-delà de la sélection à deux couches, chaque outil déclare ses capacités — les types de tâches qu'il peut accomplir. Un outil peut indiquer son utilité pour les contrôles de conformité, le renseignement commercial, l'analyse documentaire ou le suivi des expéditions.
Lorsque le système détermine l'intention de l'utilisateur, il filtre le catalogue pour ne garder que les outils aux capacités correspondantes. Le modèle de sélection ne voit même pas les outils sans rapport avec le type de tâche.
Cela compte pour une raison subtile : les modèles de langage sont influençables. Si un outil de sanctions est dans le contexte, le modèle peut décider de lancer un contrôle même pour une simple question sur les itinéraires. Retirer les outils non pertinents avant la sélection élimine toute une catégorie d'appels inutiles.
Boucles de retour sur la qualité
Sélectionner les outils ne représente que la moitié du travail. L'autre moitié consiste à garantir des résultats utiles — et à savoir quoi faire sinon.
Après chaque exécution, notre système évalue la qualité du résultat. Les défaillances courantes comprennent :
Résultats vides. L'outil s'est exécuté avec succès mais n'a renvoyé aucune donnée. L'entité peut être absente de la base (constat valide et informatif) ou la requête mal formée (problème à corriger avant une nouvelle tentative).
Correspondances à faible confiance. Une recherche approximative renvoie des résultats dont le score est inférieur au seuil. Le système doit décider de les présenter comme correspondances potentielles ou de les écarter et essayer une autre stratégie.
Échantillon insuffisant. Une requête commerciale renvoie des résultats d'une seule source alors que plusieurs devraient être recoupées pour assurer la fiabilité. Le système reconnaît cette lacune et peut demander des appels supplémentaires pour la combler.
Lorsque les contrôles qualité échouent, le système réinjecte des consignes dans la boucle de raisonnement de l'agent. C'est une nouvelle tentative dirigée qui explique le problème et suggère une reformulation de la requête, au-delà d'une simple répétition.
Livraison progressive des résultats
La vérification de conformité commerciale comporte intrinsèquement plusieurs étapes. Un utilisateur téléverse un connaissement et demande à l'agent de le vérifier. Celui-ci doit contrôler l'expéditeur dans les listes de sanctions, vérifier la certification biologique, rechercher la position du navire, contrôler les alertes FDA pour la matière première et valider la classification tarifaire. Ces contrôles prennent des durées différentes.
Au lieu d'attendre la fin de tous les contrôles avant d'afficher quoi que ce soit, nous diffusons les résultats progressivement. À chaque retour d'outil, les résultats sont immédiatement mis en forme et livrés à l'interface. L'utilisateur voit apparaître les sanctions, puis les données du navire, puis le statut biologique, chacun sous forme de carte structurée dès qu'il est prêt.
La synthèse finale, qui produit un résumé narratif reliant tous les résultats, s'exécute seulement après la fin de tous les outils.
Vérification automatique : boucler le processus
Lors du traitement documentaire par notre chaîne OCR, le système d'extraction identifie les données clés — identifiants NOP, noms d'entreprises, identifiants de navires, numéros de conteneurs, codes portuaires et SH. Chacune correspond à des outils précis de vérification.
Au lieu d'attendre la demande « vérifiez ce document », le système précalcule des indications de vérification. Lorsque l'utilisateur ouvre une conversation sur un document, l'agent connaît déjà les outils et paramètres à utiliser. Cela réduit fortement le délai : il n'a pas à lire le document, identifier les entités, puis déterminer les contrôles. Il dispose déjà d'un plan prêt à exécuter.
Les principes
La construction de ce système a cristallisé plusieurs principes que nous estimons largement applicables à la conception d'agents IA :
Séparer sélection et exécution. Ne faites pas de votre modèle de raisonnement votre modèle de routage. Utilisez des modèles rapides et peu coûteux pour la classification, et des modèles performants et coûteux pour le raisonnement.
Réduire le choix, augmenter l'exactitude. Un modèle choisissant entre 10 outils bien adaptés surpasse toujours celui qui choisit entre 100 outils. Investissez dans le filtrage avant la sélection.
Valider après l'exécution, et pas seulement avant. Les appels échouent de façons imprévisibles. Construisez des boucles qualité qui détectent les mauvais résultats et guident les nouvelles tentatives.
Diffuser progressivement, plutôt que par lots. Les utilisateurs devraient voir les résultats dès leur arrivée. La livraison progressive dépasse l'amélioration d'expérience : elle transforme fondamentalement l'interaction avec les données de vérification.
Rendre l'intention explicite. Ne laissez pas le modèle déduire ce qui est « bon ». Dites-le-lui. La planification des objectifs transforme une exploration ouverte en vérification dirigée.
L'agent IA d'Atlas Verified orchestre 100+ outils spécialisés de vérification pour automatiser les contrôles de conformité commerciale sur la chaîne mondiale.