Un agent perd des données à cause de la taille du tableau, pas du nombre d'échanges : 92% de tours corrects contre 46%

Un agent typique est conçu simplement : l'outil renvoie un tableau, le modèle le reçoit dans son contexte et le restitue à l'utilisateur, puis répond « de tête » aux demandes de précision du genre « montre seulement les départs après 21:00 ». Cela paraît anodin, mais c'est précisément là que les données s'abîment. La recherche a tout calculé correctement, le JSON est valide, le schéma est cohérent, et pourtant le tableau final affiche à l'utilisateur un autre prix, une date erronée ou un vol manquant.

Les auteurs d'un travail récent publié sur arXiv ont mesuré le phénomène sur un véritable agent en production. Dans le titre, la « précision » désigne la part des tours de dialogue où tous les champs de toutes les lignes correspondent à la référence. Principal résultat : la chute de précision dépend de la taille du tableau, et non du nombre d'échanges déjà passés.

Si vous construisez des agents, cela pèse directement sur l'architecture et sur la facture de tokens.

Ce qui a été comparé

Les chercheurs ont pris AwardWise, un assistant multi-agents de recherche de billets d'avion en miles, bâti sur Google Agent Development Kit. Les deux versions du système ne diffèrent que par la manière de livrer les données. Le modèle (Gemini 2.5 Flash), la température de 0,1, le top_p de 0,5 et les instructions associées sont identiques.

La première version, SYNTHESIS, reprend le schéma standard des frameworks. La liste complète des vols entre dans le contexte du planificateur, qui construit lui-même le tableau et répond lui-même aux demandes de précision.

La seconde, BYPASS, est celle qui tourne en production. Les enregistrements sont stockés dans l'état de la session et ne passent jamais par la génération du modèle. Le modèle se contente de traduire la demande de l'utilisateur en arguments de filtre ; le filtre est exécuté par du code déterministe ordinaire, et les lignes arrivent dans l'interface par un canal typé distinct.

Le test portait sur 24 dialogues, avec 339 tours évalués pour chaque variante. Les réponses des fournisseurs avaient été figées au préalable : 408 instantanés sur 36 itinéraires, le plus gros résultat comptant 510 lignes. Le critère est strict : un tour n'est jugé correct que si les champs correspondent à la référence.

Résultats

Les tours entièrement corrects représentent 92,3% pour BYPASS et 45,7% pour SYNTHESIS, soit un écart de +46,6 points de pourcentage. Sur trois familles de modèles, l'écart est resté compris entre +46,6 et +55,8 points.

Les auteurs ont ensuite cherché ce qui provoque l'effondrement. La taille du tableau a été modifiée selon les dates des instantanés, selon les préfixes d'un même résultat et selon un schéma en « carré latin » qui dissocie la taille de la position dans le dialogue. Partout, SYNTHESIS s'effondre à mesure que le tableau grossit, tandis que BYPASS reste stable. Le seuil d'effondrement dépend de la puissance du modèle : il est inférieur à 10 lignes pour GPT-4o-mini et plus élevé pour Gemini 2.5 Pro. Mais le contournement maintient son niveau sur les quatre modèles testés : 140 exécutions sur 144. Les auteurs résument ainsi : un modèle plus puissant achète un seuil, l'architecture achète l'immunité.

Remplacer Flash par Gemini 2.5 Pro sur les mêmes dialogues fait passer la précision de la reformulation de 46% à 72%, mais chaque tour coûte environ 5 fois plus cher. C'est une façon coûteuse de louer de la précision au lieu de ne pas la perdre.

Coûts, erreurs et limites

Avec BYPASS, le coût et la latence d'un tour ne dépendent pas de la taille du tableau : environ $0,012. Avec la reformulation, les dépenses croissent avec le contexte. Au-delà de 100 lignes, presque aucune réponse n'est correcte, et chaque réponse correcte coûte environ 200 fois plus cher qu'avec la voie de contournement.

L'hypothèse selon laquelle les erreurs s'accélèrent à chaque tour n'a pas été confirmée par le test préenregistré. Selon les auteurs, la cause tient à la méthode : avec un taux d'échec aussi élevé, il n'y a rien à quoi comparer. On voit en revanche que les erreurs se propagent. Le tableau corrompu devient l'entrée du tour suivant. Avec BYPASS, chaque tour est recalculé à partir de l'état sauvegardé, si bien que cette chaîne n'existe pas ; le résultat nul de 0/25 signifie seulement qu'aucun contre-exemple n'a été trouvé.

Les limites comptent aussi. Il s'agit d'un seul système dans un seul domaine, les principales mesures ont été réalisées sur Gemini 2.5 Flash, et les scénarios de dialogue ont été écrits d'après les sessions d'un praticien expérimenté du voyage en miles (award travel). Le gain n'est pas décomposé par facteur : le stockage de l'état, le filtre déterministe et le canal latéral ont été évalués ensemble.

Enseignement pratique : les canaux latéraux comme LangGraph ou AG-UI étaient généralement adoptés pour obtenir une interface prévisible. Ce travail montre qu'ils protègent aussi les données. Si un outil renvoie des dizaines de lignes, gardez-les dans l'état de la session, confiez le filtrage au code et ne laissez au modèle que la traduction de la demande en arguments.