💬 NLP

SANA: What Matters for QA Agents over Massive Data Lakes?

Cet article introduit SANA, un cadre d'ablation diagnostique qui décompose la performance de l'Exploratory Question Answering (EQA) de bout en bout sur des lacs de données massifs en échecs de composants spécifiques — recherche, planification et analyse de données — afin d'identifier systématiquement les goulots d'étranglement et de guider les améliorations dans la conception d'agents.

Auteurs originaux : Austin Senna Wijaya, Jiaxiang Liu, Haonan Wang, Eugene Wu

Publié 2026-06-15

📖 6 min de lecture🧠 Analyse approfondie

CC BY 4.0

Auteurs originaux : Austin Senna Wijaya, Jiaxiang Liu, Haonan Wang, Eugene Wu

Article original sous licence CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Ceci est une explication générée par l'IA de l'article ci-dessous. Elle n'a pas été rédigée ni approuvée par les auteurs. Pour une précision technique, consultez l'article original. Lire la clause de non-responsabilité complète

Imaginez que vous ayez engagé un détective très intelligent, mais parfois confus (un Agent IA) pour résoudre un mystère. Les indices ne sont pas rangés dans un dossier bien propre ; ils sont éparpillés dans un entrepôt massif et chaotique rempli de millions de boîtes, de papiers et de fichiers numériques (un Lac de Données ou Data Lake).

Le travail du détective est de trouver les bons indices, de les lire, de faire des calculs et de résoudre l'affaire. Mais parfois, le détective échoue. Pourquoi ? A-t-il cherché au mauvais endroit ? A-t-il mal compris l'indice ? A-t-il fait une erreur de calcul ? Ou s'est-il simplement embrouillé sur la marche à suivre ?

Ce document présente SANA, une nouvelle façon de diagnostiquer précisément là où le détective fait fausse route. Considérez SANA comme un enregistreur de "boîte noire" qui vous permet de mettre l'enquête en pause et de remplacer spécifiquement certaines parties du cerveau du détective pour voir quel est le maillon faible.

Les trois principales façons dont un détective peut échouer

Les auteurs décomposent le travail du détective en trois compétences principales :

La Recherche (Trouver les indices) : Le détective peut-il trouver les bonnes boîtes dans l'entrepôt massif ?
- Le Problème : Si l'entrepôt est immense, le détective peut prendre les mauvaises boîtes ou passer totalement à côté des bonnes.
La Planification (Le plan de bataille) : Le détective peut-il déterminer l'ordre correct des étapes ? (ex : « D'abord trouver l'emplacement, puis trouver les personnes qui y vivent, ensuite les compter. »)
- Le Problème : Le détective peut s'embrouiller, sauter une étape ou essayer de résoudre l'énigme à l'envers.
L'Analyse de Données (Faire le travail) : Une fois les indices trouvés, le détective est-il capable de les lire et de faire les calculs ?
- Le Problème : Le détective peut trouver le bon document mais mal lire les chiffres ou écrire le mauvais code pour calculer le résultat.

Comment fonctionne SANA : Le remplacement "super-puissant"

Pour déterminer quelle compétence pose problème, SANA utilise une astuce ingénieuse. Il prend un mystère résolu (où nous connaissons déjà la réponse) et crée une version "Standard d'Or" des indices.

Ensuite, il fait passer le détective à travers le même mystère, mais en remplaçant ses outils un par un :

Le remplacement "Recherche Parfaite" : Nous donnons au détective une baguette magique qui lui tend uniquement les bonnes boîtes, supprimant ainsi le besoin de chercher. Si le détective échoue toujours, le problème n'est pas la recherche ; c'est autre chose.
Le remplacement "Plan Parfait" : Nous donnons au détective une carte pré-écrite des étapes exactes à suivre. S'il échoue toujours, le problème n'est pas la planification ; il ne fait simplement pas suivre la carte.
Le remplacement "Mathématiques Parfaites" : Nous donnons au détective une calculatrice qui garantit la bonne réponse s'il pose la bonne question. S'il échoue toujours, le problème est qu'il pose les mauvaises questions.

En comparant les performances normales du détective à ces versions "parfaites", SANA peut localiser précisément l'endroit où se produit la rupture.

Ce qu'ils ont découvert : Les points faibles du détective

Les chercheurs ont testé cela sur deux types de "mystères" (benchmarks) : LakeQA (un entrepôt immense et désordonné) et KramaBench (un ensemble d'indices plus petit et plus ciblé).

Voici ce qu'ils ont découvert :

1. Le goulot d'étranglement de l'Analyse de Données (Le problème de mathématiques)
Dans les deux types de mystères, le plus gros problème était l'Analyse de Données. Même lorsqu'ils trouvaient les bons indices et avaient un bon plan, ils se trompaient souvent dans le calcul ou le code proprement dit. C'est comme avoir les bons ingrédients mais brûler le gâteau. C'était le point de défaillance le plus constant.

2. Le goulot d'étranglement de la Recherche (Le problème de l'entrepôt)
Dans le cadre de LakeQA (l'entrepôt immense), la Recherche était un problème majeur. Le détective se perdait dans la masse de données.

La Solution : Lorsqu'ils ont donné au détective plus faible une "baguette magique" qui ne montrait que les bonnes boîtes, ses performances ont bondi massivement. Cela prouve que pour les lacs de données géants, la capacité à trouver l'aiguille dans la botte de foin est la partie la plus difficile.
Le Contraste : Dans le cadre plus restreint de KramaBench, la recherche n'était pas un problème majeur car il y avait moins de boîtes à examiner.

3. Le goulot d'étranglement de la Planification (Le problème de la carte)
Étonnamment, la Planification n'était pas le problème principal. Les détectives étaient en fait plutôt doués pour élaborer un plan décent par eux-mêmes.

Le Piège : Le problème n'était pas de créer le plan, mais de le suivre. Même lorsqu'on leur donnait une carte parfaite, les détectives les plus faibles se laissaient distraire, prenaient un mauvais tournant ou oubliaient où ils allaient. Ils avaient du mal à rester sur le chemin.

Le problème "Résiduel" : L'erreur humaine

Même lorsque les chercheurs ont donné au détective les outils de Recherche Parfaite, de Plan Parfait et de Mathématiques Parfaites, ils n'ont toujours pas obtenu 100 % de bonnes réponses.

Pourquoi ? La "Politique d'Action" du détective (son cerveau de prise de décision) présentait encore des failles. Ils allaient parfois :
- Abandonner trop tôt.
- Soumettre la mauvaise réponse alors qu'ils avaient les bons indices.
- Rester bloqués dans une boucle en faisant la même chose de façon répétée.

L'essentiel

Ce document ne se contente pas de dire "L'IA s'améliore". Il agit comme un outil de diagnostic de mécanicien. Il nous dit que :

Si vous travaillez avec des données massives, votre IA a besoin de meilleures compétences de recherche.
Si vous faites de l'analyse de données complexe, votre IA a besoin de meilleures compétences en codage/mathématiques.
Quel que soit la tâche, votre IA a besoin d'une meilleure discipline pour suivre son plan et ne pas abandonner ou halluciner la réponse finale.

SANA aide les développeurs à arrêter de deviner et à commencer à réparer la partie spécifique de l'IA qui est réellement défectueuse.

Résumé Technique : SANA - Cadre d'Ablation pour la Navigation d'Agents de Recherche

1. Définition du Problème

Le Questionnement Exploratoire (EQA - Exploratory Question Answering) sur des lacs de données nécessite qu'un agent LLM découvre de manière itérative des sources pertinentes, analyse les données récupérées et adapte ses actions en fonction des résultats intermédiaires. Contrairement au QA standard, l'agent doit déterminer quels tableaux, métadonnées, filtres ou calculs sont nécessaires pour répondre à une question de haut niveau sans connaissance préalable du schéma des données.

Les méthodes d'évaluation actuelles reposent sur la précision de bout en bout, ce qui confond les échecs de composants distincts :

Recherche : Récupération de sources non pertinentes, incomplètes ou manquantes.
Planification : Décomposition de la question en sous-questions erronées ou incomplètes.
Analyse de Données : Écriture de requêtes/codes incorrects, mauvaise interprétation des résultats ou erreurs de schéma.
Politique de l'Agent : Le processus de décision au niveau du tour (Action Policy) déterminant la marche à suivre, le moment de s'arrêter ou comment synthétiser les preuves.

Les benchmarks précédents (ex. : LakeQA, KramaBench) et les évaluations d'agents (ex. : DCI, Metadata Reasoner) n'isolent pas ces modes d'échec. Par conséquent, il reste difficile de savoir si un agent échoue à cause d'une infrastructure de recherche médiocre, de chaînes de raisonnement faibles ou de politiques d'exécution défectueuses.

2. Méthodologie : Le Cadre SANA

Les auteurs proposent SANA (Search Agent Navigation Ablation framework), un cadre d'ablation diagnostique conçu pour déconstruire les précisions des tâches EQA de bout en bout en échecs de composants spécifiques.

2.1 Profilage de Tâche

SANA transforme les tâches EQA résolues en profils d'exécution contenant des informations de vérité terrain :

Séquence de Sources : La séquence ordonnée des jeux de données de référence ( $D_{gold}$ ) requis pour chaque sous-question.
Sous-questions Sanitisées : Une séquence de sous-questions ( $\tilde{Q}$ ) où les mentions directes de noms de jeux de données sont supprimées pour éviter de divulguer les cibles de recherche (ex. : remplacer "nypd_crimes" par "trouver les rapports de crimes signalés par la NYPD").
Registres d'Exécution : Spécifications du jeu de données, de l'intention d'analyse, du code/requête correct et de la réponse intermédiaire pour chaque étape nécessitant une analyse de données.

2.2 Ablation par Intention

SANA isole la contribution des composants du système en les remplaçant par des versions idéalisées tout en préservant la Politique d'Action de l'agent. Le cadre définit trois axes d'ablation :

Ablation de Planification : L'agent reçoit la séquence de sous-questions sanitisées ( $\tilde{Q}$ ) et l'objectif de chaque étape, mais doit toujours formuler des requêtes de recherche et exécuter l'analyse. Cela teste si l'agent peut suivre une décomposition correcte.
Ablation de Recherche : L'outil de recherche standard est remplacé par un opérateur de type oracle ( $f_{ideal}$ ) qui restreint l'espace de recherche strictement à $D_{gold}$ . L'agent décide toujours de ce qu'il cherche et de quand, mais la précision de la récupération est parfaite.
Ablation d'Analyse de Données : L'outil d'exécution standard est remplacé par $g_{ideal}$ , qui vérifie si l'intention de l'agent correspond au registre d'exécution annoté. Si elle correspond, il renvoie la réponse intermédiaire vérifiée ; sinon, il utilise un modèle plus puissant pour générer le code correct pour l'intention énoncée.

2.3 Configuration d'Évaluation

Le cadre a été appliqué à deux benchmarks :

LakeQA : Un environnement de lac de données à grande échelle (~40 millions de documents, 135 tâches).
KramaBench (Converti) : Un environnement à plus petite échelle (données vers insights) (1 764 sources, 83 tâches) adapté pour exiger la découverte de données.

Les expériences ont été menées avec deux tailles de modèles (gpt-5.4-nano et gpt-5-mini) sous des budgets fixes ( $B=30$ appels d'outils) et des temps d'exécution. L'étude compare les configurations Naive (base), Standard (meilleures pratiques actuelles) et Ideal (ablation).

3. Résultats Clés

3.1 Conclusions de LakeQA (Découverte à Grande Échelle)

La Recherche est un Goulot d'Étranglement Majeur : La recherche idéale (récupération oracle) a amélioré la correspondance sémantique (SM) de +14,1 % pour gpt-5.4-nano et de +13,3 % pour gpt-5-mini par rapport à BM25. Le préchargement des sources de référence a produit des gains encore plus élevés (+28,9 % pour nano), indiquant que les agents plus faibles luttent considérablement avec la navigation de recherche (formulation de requêtes et engagement envers les sources).
L'Analyse de Données est un Goulot d'Étranglement Constant : L'analyse de données idéale a amélioré la SM de +18,5 % pour gpt-5-mini, suggérant que les modèles plus forts identifient souvent l'intention correcte mais échouent dans l'implémentation (génération SQL/Python).
La Planification est Moins Limitante : La planification idéale a fourni des gains modestes (+3,0 % pour nano, +9,6 % pour mini). L'analyse a révélé que les agents peuvent souvent générer des plans similaires à la décomposition de référence, mais qu'ils échouent à les suivre lors de l'exécution (dérive de trajectoire).
Échecs de Politique Résiduels : Même avec tous les composants idéalisés, un écart subsiste (ex. : 76,3 % de SM pour gpt-5-mini contre 100 % de potentiel). Les échecs incluent l'hallucination de réponses finales, le gaspillage de budget dans des boucles, ou l'incapacité à valider les preuves intermédiaires.

3.2 Conclusions de KramaBench (Analyse à Petite Échelle)

L'Analyse de Données Domine : Dans ce contexte, l'analyse de données était le principal goulot d'étranglement, améliorant la SM de +24,1 % (nano) et de +14,5 % (mini) lorsqu'elle était idéalisée.
La Recherche est Moins Critique : Les améliorations de la recherche étaient marginales (+2,4 % à +6,0 %), reflétant la petite échelle et la nature des tâches qui sont plus proches des pipelines de données vers insights que de la découverte large.
Impact de la Planification : L'ablation de la planification a montré des gains relatifs plus importants pour le modèle le plus faible (nano) que pour le plus fort, suggérant qu'une décomposition explicite aide davantage les agents plus faibles dans les tâches d'analyse structurée.

3.3 Analyse des Échecs

L'audit des traces d'échec a révélé des profils d'échec distincts :

gpt-5.4-nano : Les échecs étaient répartis entre le ciblage des sources, la divergence de plan, le gaspillage de tours (boucles répétées) et l'arrêt prématuré.
gpt-5-mini : Les échecs étaient concentrés dans l'exécution/calcul (57,2 % des échecs) et la finalisation (35,7 %). Ce modèle atteint généralement la preuve correcte mais échoue à implémenter l'opération correctement ou à synthétiser la réponse finale.

4. Contributions

Cadre SANA : Un cadre d'ablation diagnostique qui convertit les tâches EQA résolues en profils d'exécution pour construire des interfaces idéalisées pour la planification, la recherche et l'analyse de données tout en préservant la politique de l'agent.
Évaluation Contrôlée : Une évaluation systématique sur LakeQA et le KramaBench converti qui isole les contributions de bout en bout de la recherche, de la planification et de l'exécution sous des conditions fixes.
Diagnostic Empirique : La preuve que l'analyse de données est une limitation constante à travers les benchmarks, que la recherche est une limitation majeure dans la découverte à grande échelle, et que les échecs de politique résiduels (contrôle de trajectoire, validation, critères d'arrêt) persistent même lorsque les composants sont idéalisés.

5. Signification et Revendications

L'article affirme que SANA apporte un passage nécessaire de l'évaluation de la précision de bout en bout "boîte noire" vers une approche diagnostique qui identifie les modes d'échec spécifiques des agents EQA.

Déconstruction de la Précision : Les auteurs soutiennent que la précision de bout en bout seule ne peut distinguer un échec de recherche, de planification ou de la politique de l'agent. SANA permet des comparaisons systématiques des progrès dans ces domaines spécifiques.
Politique vs Qualité des Composants : Les résultats suggèrent que les améliorations futures des agents EQA nécessitent plus que de meilleurs récupérateurs ou une meilleure génération de code. L' "écart résiduel" indique un besoin de politiques d'exécution plus fortes capables de suivre la progression des sous-objectifs, de s'engager sur des sources validées, de se remettre des dérives de trajectoire et de vérifier les preuves intermédiaires avant de soumettre une réponse finale.
Goulots d'Étranglement Contextuels : Le papier souligne que les goulots d'étranglement ne sont pas universels ; ils changent selon la structure du benchmark (ex. : la recherche domine dans les grands lacs, tandis que l'analyse domine dans les tâches plus petites axées sur les insights).

Limitations reconnues par les auteurs :

Approximation Diagnostique : Les outils idéaux sont des approximations d'oracles ; ils peuvent ne pas créditer des sources valides alternatives en dehors du profil.
Portée des Tâches : Les conclusions sont spécifiques aux suites de tâches évaluées (LakeQA et KramaBench converti) et peuvent ne pas se généraliser à tous les benchmarks d'agents.
Dépendance au Juge : Plusieurs métriques (correspondance sémantique, trajectoire de plan, étiquetage d'échec) reposent sur des juges LLM, ce qui peut introduire des faux positifs/négatifs.