💬 NLP

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

Dit artikel introduceert SANA, een diagnostisch ablatiekader dat de prestaties van end-to-end Exploratory Question Answering (EQA) over enorme datameren ontleedt in specifieke componentfouten — zoeken, plannen en data-analyse — om systematisch knelpunten te identificeren en verbeteringen in agentontwerp te sturen.

Oorspronkelijke auteurs: Austin Senna Wijaya, Jiaxiang Liu, Haonan Wang, Eugene Wu

Gepubliceerd 2026-06-15

📖 5 min leestijd🧠 Diepgaand

CC BY 4.0

Oorspronkelijke auteurs: Austin Senna Wijaya, Jiaxiang Liu, Haonan Wang, Eugene Wu

Oorspronkelijk artikel gelicentieerd onder CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dit is een AI-gegenereerde uitleg van het onderstaande artikel. Het is niet geschreven of goedgekeurd door de auteurs. Raadpleeg het oorspronkelijke artikel voor technische nauwkeurigheid. Lees de volledige disclaimer

Stel je voor dat je een zeer slimme, maar soms verwarde detective hebt ingehuurd (een AI Agent) om een mysterie op te lossen. De aanwijzingen staan niet in één net bestand; ze liggen verspreid over een enorme, chaotische loods vol met miljoenen dozen, papieren en digitale bestanden (een Data Lake).

De taak van de detective is om de juiste aanwijzingen te vinden, ze te lezen, wat berekeningen uit te voeren en de zaak op te lossen. Maar soms faalt de detective. Waarom? Keek de detective op de verkeerde plek? Begreep de detective de aanwijzing verkeerd? Klopde de wiskunde niet? Of raakte de detective simpelweg in de war over wat de volgende stap was?

Dit artikel introduceert SANA, een nieuwe manier om precies te diagnosticeren waar de detective de fout in gaat. Denk aan SANA als een "black box"-recorder die het je mogelijk maakt de investigatie te pauzeren en specifieke onderdelen van het brein van de detective te vervangen om te zien welk onderdeel de zwakke schakel is.

De drie belangrijkste manieren waarop een detective kan falen

De auteurs verdelen de taak van de detective in drie hoofdvakken:

Zoeken (De aanwijzingen vinden): Kan de detective de juiste dozen vinden in de enorme loods?
- Het probleem: Als de loods enorm groot is, pakt de detective misschien de verkeerde dozen of mist hij de juiste zelfs volledig.
Plannen (Het strijdplan): Kan de detective de juiste volgorde van stappen bepalen? (bijv. "Eerst de locatie vinden, dan de mensen vinden die daar wonen, dan hen tellen.")
- Het probleem: De detective kan in de war raken, een stap overslaan of het puzzelstukje achterstevoren proberen op te lossen.
Data-analyse (Het werk doen): Zodra de aanwijzingen zijn gevonden, kan de detective ze dan daadwerkelijk lezen en de wiskunde uitvoeren?
- Het probleem: De detective vindt misschien het juiste document, maar leest de cijfers verkeerd of schrijft de verkeerde code om de berekening te maken.

Hoe SANA werkt: De "Superkrachtige" Wissel

Om te achterhalen welke vaardigheid het probleem is, gebruikt SANA een slimme truc. Het neemt een opgeloste mysteries (waarbij we het antwoord al weten kennen) en creëert een "Gold Standard"-versie van de aanwijzingen.

Vervolgens laat het de detective door dezelfde mystery lopen, maar vervangt het de hulpmiddelen één voor één:

De "Perfecte Zoek"-wissel: We geven de detective een toverstaf die alleen de juiste dozen aanreikt, waardoor het zoeken wordt overgeslagen. Als de detective nog steeds faalt, is het probleem niet het zoeken; het is iets anders.
De "Perfecte Plan"-wissel: We geven de detective een vooraf geschreven kaart met de exacte stappen die genomen moeten worden. Als ze nog steeds falen, is het probleem niet het plannen; ze volgen de kaart simpelweg niet.
De "Perfecte Wiskunde"-wissel: We geven de detective een rekenmachine die gegarandeerd het juiste antwoord geeft als ze de juiste vraag stellen. Als ze nog steeds falen, is het probleem dat ze de verkeerde vragen stellen.

Door de normale prestaties van de detective te vergelijken met deze "perfecte" versies, kan SANA precies aanwijzen waar de breuklijn zit.

Wat ze vonden: De zwakke plekken van de detective

De onderzoekers testten dit op twee verschillende soorten "mysteries" (benchmarks): LakeQA (een enorme, rommelige loods) en KramaBench (een kleinere, meer gefocuste set aanwijzingen).

Dit is wat zij ontdekten:

1. De "Data-analyse" Bottleneck (Het wiskundeprobleem)
In beide soorten mysteries was de grootste fout Data-analyse. Zelfs wanneer de detective de juiste aanwijzingen vond en een goed plan had, maakten ze vaak de fout in de eigenlijke berekening of de code. Het is alsof je de juiste ingrediënten hebt, maar de taart laat aanbranden. Dit was het meest consistente faalpunt.

2. De "Zoek"-Bottleneck (Het loodsprobleem)
In de LakeQA (enorme loods) setting was Zoeken een groot probleem. De detective raakte verdwaald in de enorme hoeveelheid data.

De oplossing: Toen ze de zwakkere detective een "toverstaf" gaven die alleen de juiste dozen liet zien, schoot hun prestatie enorm omhoog. Dit bewijst dat voor enorme data lakes het vermogen om de naald in de hooiberg te vinden het moeilijkste deel is.
Het contrast: In de kleinere KramaBench setting was zoeken geen zo groot probleem, omdat er minder dozen waren om doorheen te zoeken.

3. De "Planning"-Bottleneck (Het kaartprobleem)
Verrassend genoeg was Planning niet het grootste probleem. De detectives waren eigenlijk best goed in het bedenken van een degelijk plan op eigen kracht.

De crux: Het probleem was niet het maken van het plan; het was het volgen ervan. Zelfs wanneer ze een perfecte kaart kregen, raakten de zwakkere detectives vaak afgeleid, sloegen ze een verkeerde afslag in of vergaten ze waar ze waren. Ze hadden moeite om zich aan het pad te houden.

Het "Residuele" Probleem: De menselijke fout

Zelfs toen de onderzoekers de detective de Perfecte Zoek, de Perfecte Plan en de Perfecte Wiskunde tools gaven, kregen ze nog steeds niet 100% van de antwoorden goed.

Waarom? Het "Action Policy" (het besluitvormingsbrein) van de detective had nog steeds gebreken. Ze zouden soms:
- Te vroeg opgeven.
- Het verkeerde antwoord indienen, zelfs met de juiste aanwijzingen.
- Vast komen te zitten in een loop waarbij ze steeds hetzelfde deden.

De Kernconclusie

Dit artikel zegt niet alleen "AI wordt beter." Het fungeert als een diagnostisch instrument voor een monteur. Het vertelt ons dat:

Als je werkt met enorme hoeveelheden data, heeft je AI betere zoekvaardigheden nodig.
Als je complexe data-analyse doet, heeft je AI betere codeer-/rekenvaardigheden nodig.
Ongeacht de taak, heeft je AI meer discipline nodig om zijn plan te volgen en niet op te geven of te hallucineren bij het uiteindelijke antwoord.

SANA helpt ontwikkelaars om te stoppen met gissen en te beginnen met het repareren van het specifieke deel van de AI dat daadwerkelijk kapot is.

Technische Samenvatting: SANA - Search Agent Navigation Ablation Framework

1. Probleemdefinitie

Exploratieve Beantwoording (Exploratory Question Answering, EQA) over data lakes vereist dat een LLM-agent iteratief relevante bronnen ontdekt, geretraineerde data analyseert en zijn acties aanpast op basis van tussenresultaten. In tegenstelling tot standaard QA moet de agent bepalen welke tabellen, metadata, filters of berekeningen noodzakelijk zijn om een hoogwaardige vraag te beantwoorden zonder voorafgaande kennis van de dataschema.

Huidige evaluatiemethoden vertrouwen op end-to-end nauwkeurigheid, wat fouten over verschillende componenten heen vermengt:

Zoeken (Search): Het ophalen van irrelevante, incomplete of ontbrekende bronnen.
Plannen (Planning): Het deconstrueren van de vraag in verkeerde of incomplete subvragen.
Data-analyse (Data Analysis): Het schrijven van incorrecte queries/code, het verkeerd interpreteren van resultaten of schemafouten.
Agentbeleid (Agent Policy): Het besluitvormingsproces op turn-niveau (Action Policy) dat bepaalt wat de volgende stap is, wanneer te stoppen, of hoe bewijs te synthetiseren.

Eerdere benchmarks (bijv. LakeQA, KramaBench) en agentische evaluaties (bijv. DCI, Metadata Reasoner) isoleren deze foutmodi niet. Hierdoor blijft het onduidelijk of een agent faalt door een zwakke retrieval-infrastructuur, zwakke redeneerketens of gebrekkige executiebeleid.

2. Methodologie: Het SANA-framework

De auteurs stellen SANA (Search Agent Navigation Ablation framework) voor, een diagnostisch ablatie-framework ontworpen om de end-to-end EQA-taaknauwkeurigheden te deconstrueren naar specifieke componentfouten.

2.1 Taakprofilering

SANA transformeert opgeloste EQA-taken naar runtime profielen die grondwaarheidsinformatie bevatten:

Bronsequentie (Source Sequence): De geordende sequentie van gouden datasets ( $D_{gold}$ ) die nodig is voor elke subvraag.
Gesaneerdeerde Subvragen (Sanitized Subquestions): Een sequentie van subvragen ( $\tilde{Q}$ ) waarbij directe vermeldingen van datasetnamen zijn verwijderd om het lekken van zoekdoelen te voorkomen (bijv. het vervangen van "nypd_crimes" door "vind politierapporten die door de NYPD zijn gerapporteerd").
Executierecord (Execution Records): Specificaties van de dataset, de analyse-intentie, de correcte code/query en het tussenantwoord voor elke stap die data-analyse vereist.

2.2 Intentie-gebaseerde Ablatie

SANA isoleert de bijdrage van systeemcomponenten door ze te vervangen door geïdealiseerde versies, terwijl het Action Policy van de agent (beslissingen over wat de volgende stap is) behouden blijft. Het framework definieert drie assen voor ablatie:

Planning Ablatie: De agent ontvangt de gesaneerde subvraagsequentie ( $\tilde{Q}$ ) en het doel van elke stap, maar moet nog steeds zoekopdrachten formuleren en analyse uitvoeren. Dit test of de agent een correcte decompositie kan volgen.
Search Ablatie: De standaard zoektool wordt vervangen door een oracle-achtige operator ( $f_{ideal}$ ) die de zoekruimte strikt beperkt tot $D_{gold}$ . De agent beslist nog steeds wat er gezocht moet worden en wanneer, maar de retrieval-precisie is perfect.
Data-analyse Ablatie: De standaard executietool wordt vervangen door $g_{ideal}$ , die controleert of de intentie van de agent overeenkomt met het geannoteerde executierecord. Indien overeenkomstig, wordt het geverifieerde tussenantwoord geretourneerd; zo niet, dan wordt een sterker model gebruikt om de correcte code voor de gestelde intentie te generen.

2.3 Evaluatieopstelling

Het framework werd toegepast op twee benchmarks:

LakeQA: Een grootschalige data lake-omgeving (~40 miljoen documenten, 135 taken).
KramaBench (Geconverteerd): Een kleinschaligere data-naar-inzicht setting (1.764 bronnen, 83 taken) aangepast om data-ontdekking te vereisen.

Experimenten werden uitgevoerd met twee modelgroottes (gpt-5.4-nano en gpt-5-mini) onder vaste budgetten ( $B=30$ tool calls) en looptijden. De studie vergelijkt Naive (baseline), Standard (huidige best practices) en Ideal (ablatie) configuraties.

3. Belangrijkste Resultaten

3.1 LakeQA Bevindingen (Grootschalige Ontdekking)

Zoeken is een Belangrijke Bottleneck: Ideale zoekopdrachten (oracle retrieval) verbeterden de semantische match (SM) met +14,1% voor gpt-5.4-nano en +13,3% voor gpt-5-mini ten opzichte van BM25. Het voorladen van gouden bronnen leverde nog hogere winsten op (+28,9% voor nano), wat aangeeft dat zwakkere agenten aanzienlijk moeite hebben met navigatie door zoekprocessen (het formuleren van queries en het vastleggen van bronnen).
Data-analyse is een Constante Bottleneck: Ideale data-analyse verbeterde de SM met +18,5% voor gpt-5-mini, wat suggereert dat sterkere modellen vaak de juiste intentie identificeren maar falen in de implementatie (SQL/Python generatie).
Planning is Minder Beperkend: Ideale planning leverde bescheiden winsten op (+3,0% voor nano, +9,6% voor mini). Analyse toonde aan dat agenten vaak plannen kunnen genereren die vergelijkbaar zijn met de gouden decompositie, maar dat ze falen om deze tijdens de uitvoering te volgen (traject-drift).
Residuele Beleidsfouten: Zelfs wanneer alle componenten geïdealiseerd zijn, blijft er een gat bestaan (bijv. 76,3% SM voor gpt-5-mini versus 100% potentieel). Falen omvatten het hallucineren van eindantwoorden, het verspillen van budget aan loops, of het niet valideren van tussenbewijs.

3.2 KramaBench Bevindingen (Kleinschalige Analyse)

Data-analyse Domineert: In deze setting was data-analyse de primaire bottleneck, wat de SM verbeterde met +24,1% (nano) en +14,5% (mini) wanneer geïdealiseerd.
Zoeken is Minder Kritisch: Verbeteringen in zoeken waren marginaal (+2,4% tot +6,0%), wat de kleinere schaal reflecteert en de aard van de taken die dichter bij data-naar-inzicht pipelines liggen dan bij brede ontdekking.
Impact van Planning: Planning-ablatie toonde meer significante relatieve winsten voor het zwakkere model (nano) dan voor het sterkere model, wat suggereet dat expliciete decompositie zwakkere agenten meer helpt bij gestructureerde analyse-taken.

3.3 Foutanalyse

Audit van gefaalde traces onthulde duidelijke foutprofielen:

gpt-5.4-nano: Fouten waren verdeeld over bron-targeting, plan-divergentie, turn-waste (herhaalde loops) en voortijdige stopzetting.
gpt-5-mini: Fouten waren geconcentreerd in executie/computatie (57,2% van de fouten) en finalisatie (35,7%). Dit model bereikte doorgaans het juiste bewijs, maar faalde in het correct implementeren van de operatie of het synthetiseren van het eindantwoord.

4. Bijdragen

SANA-framework: Een diagnostisch ablatie-framework dat opgeloste EQA-taken omzet in runtime-profielen om geïdealiseerde interfaces voor planning, zoeken en data-analyse te construeren terwijl het agentbeleid behouden blijft.
Gecontroleerde Evaluatie: Een systematische evaluatie op LakeQA en geconverteerde KramaBench die de end-to-end bijdragen van zoeken, planning en executie isoleert onder vaste condities.
Empirische Diagnose: Bewijs dat data-analyse een consistente beperking is over benchmarks, zoeken een belangrijke beperking is in grootschalige ontdekking, en dat residuele beleidsfouten (trajectcontrole, validatie, stopcriteria) aanhouden zelfs wanneer componenten geïdealiseerd zijn.

5. Betekenis en Claims

Het artikel claimt dat SANA een noodzakelijke verschuiving biedt van het evalueren van "black-box" end-to-end nauwkeurigheid naar een diagnostische aanpak die specifieke foutmodi in EQA-agenten identificeert.

Deconstructie van Nauwkeurigheid: De auteurs stellen dat end-to-end nauwkeurigheid alleen niet kan onderscheiden of een fout ligt in zoeken, planning of het beleid van de agent. SANA maakt systematische vergelijkingen van vooruitgang in deze specifieke gebieden mogelijk.
Beleid versus Componentkwaliteit: De resultaten suggereren dat toekomstige verbeteringen in EQA-agenten meer vereisen dan alleen betere retrievers of sterkere codegeneratie. De "residuele kloof" wijst op de behoefte aan sterkere runtime-beleid die subdoel-progressie kunnen volgen, gevalideerde bronnen kunnen vastleggen, kunnen herstellen van traject-driften en tussenbewijs kunnen verifiëren voordat een eindantwoord wordt ingediend.
Context-afhankelijke Bottlenecks: Het paper benadrukt dat bottlenecks niet universeel zijn; ze verschuiven op basis van de benchmarkstructuur (bijv. zoeken domineert in grote lakes, terwijl analyse domineert in kleinere, inzichts-gedreven taken).

Beperkingen erkend door de auteurs:

Diagnostische Approximatie: Ideale tools zijn benaderingen van oracles; ze kunnen alternatieve geldige bronnen buiten het profiel mogelijk niet crediteren.
Taakbereik: Conclusies zijn specifiek voor de geëvalueerde taaksuites (LakeQA en KramaBench) en generaliseren mogelijk niet naar alle agent-benchmarks.
Afhankelijkheid van Judges: Verschillende metrieken (semantische match, plan-traject, fout-labeling) vertrouwen op LLM-judges, wat fout-positieven/negatieven kan introduceren.