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
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.
- 6 nov. 2026Replit lance ViBench 2.0 : le meilleur modèle livre un produit fonctionnel dans 65% des builds
- 6 nov. 2026Viggle ouvre deux LoRA pour MiniMax-H3 : le remplacement de personnes dans une vidéo tourne dès 12 Go de VRAM
- 6 nov. 2026Un agent de code remplace le téléopérateur : les robots réussissent 93 essais sur 100, contre 84
- 6 nov. 2026ReplayRCA : corriger à la dernière étape fait perdre 17,1 points de correction causale à un modèle puissant
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é.
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.
L'essentiel de l'IA — une fois par semaine
Sept actus qui ont vraiment compté, choisies à la main. Sans bruit ni communiqués.
C'est fait ! Vérifiez votre boîte mail pour la confirmation.