Un agent avec filtre et canal latéral atteint 92,3% de tours entièrement corrects, contre 45,7% pour la réécriture par le modèle

Les auteurs ont comparé deux architectures d'un agent de production dédié à la recherche de billets d'avion en miles, sur Gemini 2.5 Flash et 24 dialogues. Quand le modèle réimprime lui-même les lignes de la table à chaque réponse, 45,7% des tours sont entièrement corrects. Quand les enregistrements restent dans l'état de session et que le modèle se contente de transmettre des arguments à un filtre déterministe, 92,3% des tours sont corrects. L'écart de 46,6 points de pourcentage vient uniquement du mode de livraison des données, et non du nombre de tours.

Traité par IA depuis arXiv cs.CL ; édité par Hamidun News
Un agent avec filtre et canal latéral atteint 92,3% de tours entièrement corrects, contre 45,7% pour la réécriture par le modèle
Source : arXiv cs.CL. Collage: Hamidun News.
Écouter l'article
Fiche synthèse et chiffres clés
ParamètreDonnées
Source primairearXiv cs.CL ↗
Rédacteur en chef
Chiffre clé #1Chez GPT-4o-mini, la précision de la réécriture s'effondre dès que la table compte moins de 10 lignes
Chiffre clé #2Au-delà de 100 lignes, une réponse correcte obtenue par réécriture coûte environ 200 fois plus cher qu'avec le schéma à filtre
Chiffre clé #3Gemini 2.5 Pro fait passer la précision de la réécriture de 46% à 72%, pour un coût par tour multiplié par 5

Quand un agent reçoit d'un outil une table toute prête et la recopie dans sa réponse à chaque tour de dialogue, le modèle altère des données que l'outil avait pourtant calculées correctement. Les auteurs d'une nouvelle étude ont mesuré ce phénomène dans un agent de production dédié à la recherche de billets d'avion en miles. Ils ont comparé deux architectures sur les mêmes données figées.

Dans le schéma SYNTHESIS, la liste complète des lignes entre dans le contexte du modèle, qui régénère la table lui-même à chaque fois. Dans le schéma BYPASS, celui qui tourne en production, les enregistrements sont stockés dans l'état de session et les lignes partent vers l'interface sans passer par le modèle. La métrique principale est la part des tours où tous les champs de toutes les lignes sont corrects : 92,3% pour BYPASS contre 45,7% pour SYNTHESIS.

L'écart apparié entre les deux atteint 46,6 points de pourcentage. C'est la taille de la table dans le contexte, et non le nombre de tours, qui détermine les erreurs.

Ce qui a été comparé, et comment

Le système s'appelle AwardWise. C'est un assistant multi-agents bâti sur Google Agent Development Kit (ADK). Un planificateur aiguille les requêtes, et des sous-agents interrogent la recherche de places en prime (Seats.aero) et les tarifs en argent (SerpAPI). Les deux architectures tournaient sur Gemini 2.5 Flash, avec une température de 0,1 et un top_p de 0,5. Les données provenaient des mêmes réponses figées des fournisseurs. Seule la livraison différait.

Dans SYNTHESIS, le schéma classique d'ADK, le modèle traite « de tête » les précisions du type « uniquement les départs après 21:00 » et réimprime la table. Dans BYPASS, il se limite à traduire la demande de l'utilisateur en arguments pour un filtre déterministe. Le filtre s'applique à l'ensemble d'enregistrements sauvegardé, et les lignes parviennent au client sous forme d'événements typés, en parallèle du flux de tokens du modèle et non à travers lui. Une erreur de traduction de la demande en arguments produit une seule tranche de données erronée, mais bien réelle. La réécriture, elle, met en jeu chaque champ de chaque ligne à chaque tour.

L'évaluation porte sur 24 dialogues, avec 339 tours évalués par condition. Les dialogues reprennent des sessions d'un praticien expérimenté de l'award-travel. La référence a été calculée par l'évaluateur de filtres de production, et la vérification s'est faite ligne par ligne et champ par champ, un tour étant remis à zéro dès qu'un résultat est faux. Le corpus compte 408 instantanés de résultats sur 36 itinéraires ; le plus gros résultat contient 510 lignes. Sur trois familles de modèles, ces mêmes 46,6 points de pourcentage deviennent un écart de 46,6 à 55,8 points de pourcentage.

Un décrochage de la précision selon la taille de la table

Pour isoler la taille du nombre de tours, les auteurs ont mené plusieurs expériences. Vingt dialogues sur quatre itinéraires faisaient varier la taille des résultats. Une échelle de six itinéraires donnait au modèle les K premières lignes d'un même résultat, de sorte que le contenu restait constant. Un carré latin séparait la taille de la position de la ligne. Dans chaque plan d'expérience, SYNTHESIS s'effondre quand la table grossit, tandis que BYPASS reste stable. Une table de contrôle identique octet pour octet à la table problématique conserve son niveau, même là où le schéma à réécriture a obtenu zéro.

Le seuil de décrochage dépend du modèle. Sur les quatre modèles testés, il va de moins de 10 lignes pour GPT-4o-mini à des valeurs nettement plus élevées pour Gemini 2.5 Pro. BYPASS reste stable sur les quatre (140 exécutions sur 144). Les auteurs résument ainsi : la puissance du modèle permet d'acheter un seuil, mais seule l'architecture confère l'immunité.

Le coût du décrochage et les limites

Le coût d'un tour dans BYPASS ne dépend pas de la taille de la table et s'élève à environ $0,012. Avec SYNTHESIS, pour des tables de plus de 100 lignes, il n'y a presque aucune réponse correcte, et chacune coûte environ 200 fois plus que ce tarif fixe. Remplacer Flash par Gemini 2.5 Pro fait passer la précision de la réécriture de 46% à 72%, mais le coût par tour est environ cinq fois plus élevé. Selon les auteurs, acheter de la précision auprès d'un modèle plus gros est un substitut coûteux au renoncement à la réécriture.

L'hypothèse préenregistrée d'une accumulation superlinéaire des erreurs au fil des tours n'a pas été confirmée. Le modèle nul sature lorsque la probabilité d'échec par tour est déjà élevée. En revanche, le traçage des valeurs a montré que les défaillances ne sont pas indépendantes : un résultat altéré devient l'entrée du tour suivant. BYPASS recalcule la réponse à partir de l'état sauvegardé à chaque fois, si bien qu'une telle propagation d'erreur n'a aucune prise.

Les limites sont elles aussi énoncées sans détour. L'écart reflète l'effet conjoint de trois différences entre les architectures, et les auteurs n'ont pas séparé la contribution de chacune. Cela exigerait des conditions distinctes, laissées à un futur travail. Les conditions principales ont tourné sur Gemini 2.5 Flash, hérité de l'histoire du produit et non choisi spécialement. Au fil du travail, les mesures ont mis au jour huit défauts de mise en place, dont trois dans la référence elle-même, ainsi que deux corrections de la sémantique de la référence et trois bugs de production. Tout a été corrigé, et tous les chiffres principaux ont été obtenus après ces correctifs.

La leçon pour les développeurs : le canal latéral typé est apparu dans LangGraph, AG-UI, Vercel Data Parts et Google A2UI pour rendre l'affichage prévisible. Ce travail montre qu'il règle aussi, du même coup, la question de l'exactitude. Si le contexte contient des dizaines ou des centaines de lignes, l'utilisateur doit les voir sans altération. Il vaut donc mieux conserver les enregistrements dans l'état et les filtrer avec du code déterministe, plutôt que de demander au modèle de les réécrire.

Dossier

Questions clés sur cet article

Que sait-on sur Ce qui a été comparé, et comment ?

Le système s'appelle AwardWise. C'est un assistant multi-agents bâti sur Google Agent Development Kit (ADK). Un planificateur aiguille les requêtes, et des sous-agents interrogent la recherche de places en prime (Seats.aero) et les tarifs en argent (SerpAPI). Les deux architectures tournaient sur Gemini 2.5 Flash, avec une température de 0,1 et un top_p de 0,5. Les données provenaient des mêmes réponses figées des fournisseurs. Seule la livraison différait.

Que sait-on sur Un décrochage de la précision selon la taille de la table ?

Pour isoler la taille du nombre de tours, les auteurs ont mené plusieurs expériences. Vingt dialogues sur quatre itinéraires faisaient varier la taille des résultats. Une échelle de six itinéraires donnait au modèle les K premières lignes d'un même résultat, de sorte que le contenu restait constant. Un carré latin séparait la taille de la position de la ligne. Dans chaque plan d'expérience, SYNTHESIS s'effondre quand la table grossit, tandis que BYPASS reste stable.

Que sait-on sur Le coût du décrochage et les limites ?

Le coût d'un tour dans BYPASS ne dépend pas de la taille de la table et s'élève à environ $0,012. Avec SYNTHESIS, pour des tables de plus de 100 lignes, il n'y a presque aucune réponse correcte, et chacune coûte environ 200 fois plus que ce tarif fixe. Remplacer Flash par Gemini 2.5 Pro fait passer la précision de la réécriture de 46% à 72%, mais le coût par tour est environ cinq fois plus élevé.

ZK
Zhemal Khamidun — CPO d'Alpina Digital, product manager d'AlpinaGPT. Conçoit des produits IA depuis 2019. Hamidun News est un projet personnel devenu un agrégateur en production avec plus de 6 000 lecteurs.
✦ Unified AI Workspace · Nomad

Test Frontier LLMs & Autonomous Agents in One Workspace

Run Claude Opus 5.5, GPT-6, Gemini 3.1, and DeepSeek side-by-side in Nomad AI (nomadnet.ai) — unified model routing, deep research, and multimodal workflows under one subscription.

Try Nomad AI →Launch Nomad Agent
Qu'en pensez-vous ?
Chargement des commentaires…