Both Ends Count! Just How Good are LLM Agents at "Text-to-Big SQL"?

Dit paper introduceert nieuwe, schaalafhankelijke evaluatiemetrics voor "Text-to-Big SQL" om aan te tonen dat bestaande benchmarks ontoereikend zijn voor het beoordelen van de kosten, latentie en prestaties van LLM-agents in productieomgevingen met grote datasets.

De kern

Titel: De "Grote SQL" Test: Waarom slimme AI-agenten soms te duur of te traag zijn

Stel je voor dat je een superhandige kok (een AI-agent) hebt die voor je kookt. Je geeft hem een opdracht in gewone taal: "Maak een soep van alle groenten die donker zijn en snijd ze in blokjes."

In de wereld van kleine databases (zoals een simpele lijst met 100 recepten) is het makkelijk om te zien of de kok het goed heeft gedaan. Als hij een wortel vergeet of een ui te groot snijdt, proef je het direct. De "proef" (de test) is simpel: smaakt het? Ja of Nee?

Maar wat als je diezelfde kok vraagt om een soep te maken voor een heel dorp met miljoenen groenten? Dan verandert de spelletjesregels volledig.

Dit is precies wat dit paper onderzoekt. De auteurs zeggen: "We kijken alleen naar de smaak, maar vergeten de rekening en de tijd."

Hier is de uitleg in simpele taal:

1. Het Probleem: De "Grote SQL" Valstrik

Tot nu toe hebben onderzoekers gekeken of AI goed kan vertalen van "gewone taal" naar "database taal" (SQL). Ze keken alleen of het antwoord juist was.

Maar in de echte wereld (Big Data) werkt het anders:

• De Kosten: Als de AI een foutje maakt (bijvoorbeeld: "Haal alle 10 miljoen rijen op in plaats van 10"), kost dat enorm veel geld in de cloud. Het is alsof je per ongeluk een hele vrachtwagen vol groenten laat bezorgen in plaats van één zak.
• De Snelheid: Als de AI eerst 5 minuten nadenkt over welke groenten hij moet snijden, terwijl het koken zelf maar 1 seconde duurt, ben je te laat met je soep.
• De "Extra" Groenten: Als de AI de soep maakt maar er ook nog een onnodige komkommer in doet (een extra kolom), is de soep nog steeds eetbaar. Bij een kleine database is dat een klein foutje. Bij een grote database kost het extra tijd en geld om die komkommer er weer uit te halen.

De huidige tests zien dit niet. Ze zeggen: "Fout! Je had geen komkommer nodig." Maar in de praktijk is dat een kleinigheidje dat we kunnen oplossen, zolang de soep maar goed smaakt.

2. De Oplossing: Twee Kanten Tellen

De auteurs van dit paper zeggen: "We moeten naar beide kanten kijken!"

1. De Vertaling: Is de opdracht goed begrepen?
2. De Uitvoering: Hoeveel kost het en hoe lang duurt het?

Ze hebben nieuwe meetlatjes (metrieken) bedacht, zoals een "Efficiëntie-Score".

• Voorbeeld: Stel AI A maakt de soep perfect, maar duurt 10 minuten en kost €100. AI B maakt de soep 99% perfect, maar duurt 1 minuut en kost €1.
• Oude test: AI A wint (want 100% perfect).
• Nieuwe test ("Big SQL"): AI B wint (want het is sneller en goedkoper, en dat 1% foutje is te verwaarlozen).

3. De Experimenten: De "Kookwedstrijd"

De auteurs hebben de slimste AI's ter wereld (zoals GPT-4o, Claude, Gemini) op de proef gesteld. Ze lieten ze werken met een enorm groot dataset (TPC-H, een standaard voor grote data) en keken naar:

• Hoe snel reageerden ze?
• Hoeveel kostte het?
• Wat gebeurde er als de dataset 10x, 100x of 1000x groter werd?

De verrassende bevindingen:

• Snelheid is niet alles: De nieuwste, "slimste" AI's (zoals Claude Opus) waren soms extreem langzaam. Ze dachten te lang na voordat ze de pan op het vuur zetten.
• Schaal maakt het erger: Bij kleine datasets was het verschil tussen de AI's klein. Maar bij enorme datasets (miljoenen rijen) werden de fouten van de langzamere AI's duizenden keren duurder. Een klein foutje bij een grote dataset is als een lek in een olietanker: het kost een fortuin om het te repareren.
• De "Goedkoopste" winnaar: Soms was een iets minder "slimme" AI (zoals Gemini Flash) beter, omdat hij sneller was en minder kostte, zelfs als hij af en toe een onnodige komkommer in de soep deed.

4. De Conclusie: De "Rekening" is net zo belangrijk als het "Antwoord"

De boodschap van dit paper is helder:
In de wereld van Big Data (grote data) mag je niet alleen kijken of het antwoord juist is. Je moet ook kijken of het betaalbaar en snel genoeg is.

Als je een AI gebruikt voor een groot bedrijf, wil je niet de duurste, langzaamste kok die 100% perfect is. Je wilt de kok die snel, goedkoop en "voldoende goed" is.

Kort samengevat in een metafoor:
Vroeger keken we alleen of de auto op het juiste adres kwam. Nu, met Big Data, moeten we ook kijken of de auto niet 100 liter benzine heeft verbruikt voor een ritje van 1 kilometer, of dat de chauffeur 2 uur heeft zitten nadenken over welke route hij moet nemen terwijl de passagier al doodongeduldig is.

De auteurs zeggen: "Twee kanten tellen!" (Both Ends Count!). De vertaling én de uitvoering moeten samen goed zijn.

Technische samenvatting

Hier is een gedetailleerde technische samenvatting van het paper "Both Ends Count! Just How Good are LLM Agents at Text-to-'Big SQL'?" in het Nederlands.

Probleemstelling

Hoewel Text-to-SQL (het vertalen van natuurlijke taal naar SQL) en Big Data beide uitgebreid worden onderzocht, ontbreekt er tot nu toe onderzoek dat deze twee domeinen gezamenlijk evalueert. In de praktijk worden Text-to-SQL-systemen vaak geïntegreerd in Big Data-workflows (zoals interactieve data-analyse op grote schaal). De auteurs noemen dit "Text-to-Big SQL".

Bestaande benchmarks en evaluatiemetrics voor Text-to-SQL zijn te beperkt voor Big Data-omgevingen om de volgende redenen:

1. Gevolgen van fouten: Op kleine datasets zijn vertaalfouten vaak onschuldig. In Big Data-systemen (zoals Amazon Athena of Spark) kunnen foutieve queries echter enorme rekenkracht verbruiken, grote hoeveelheden data scannen en aanzienlijke kosten veroorzaken.
2. Onvolledige metrics: Traditionele metrics (zoals Exact Matching of Execution Accuracy) gebruiken een "alles-of-niets"-benadering. Een query die een extra, onnodige kolom teruggeeft, wordt als volledig fout beschouwd. In Big Data is dit echter vaak "gedeeltelijk correct" en kan de gebruiker de extra kolom eenvoudig verwijderen, maar de kosten voor het scannen van die data zijn al gemaakt.
3. Tijd en Kosten: De huidige metrics negeren de kosten en latentie die ontstaan door de interactie tussen de LLM, de agent en de tools, evenals de uitvoeringstijd van de query zelf. Als het genereren van SQL trager is dan de fysieke uitvoering, wordt interactieve analyse onpraktisch.

Methodologie

De auteurs introduceren een nieuw evaluatiekader dat zowel de generatie (SQL maken) als de uitvoering (Big Data engine) als eerste-class burgers behandelt.

1. Agent Architectuur:

• Ze gebruiken een ReAct-agent (Reasoning + Acting) gebaseerd op LangGraph.
• De agent gebruikt een controller (LLM) die denkt, acties kiest en observaties interpreteert.
• De agent heeft toegang tot vier tools: list_tables, get_schema, check_query (syntactische validatie) en run_query.
• Om kosten en resources te beperken, stopt de agent na de eerste run_query-uitvoering (geen eindeloze correctielussen).
• De downstream engine is Spark SQL, gekozen vanwege zijn wijdverspreide gebruik voor grote datasets.

2. Gebruikte Benchmarks:

• BIRD: Een Text-to-SQL benchmark voor realistische databases (gebruikt voor nauwkeurigheidsmetingen).
• TPC-H: Een klassieke data-analyse benchmark die schaalbaarheid toelaat (gebruikt om de impact van dataschaal te testen).

3. Nieuwe Metrics:
De auteurs stellen drie nieuwe metrics voor die de "Big SQL"-context vangen:

• VES* (Valid Efficiency Score*): Een uitgebreide versie van de bestaande VES. Deze houdt rekening met:
  • De uitvoeringstijd van de gegenereerde query versus de "golden" query.
  • Kolom-precisie: Een straf voor overbodige kolommen (superfluous columns). Als een query extra kolommen teruggeeft, wordt de score verlaagd, maar niet tot nul (in tegenstelling tot traditionele metrics).
  • Formule: VES* = (Correctheid * KolomPrecisie * (T_gold / T_e2e)).
• VCES (Valid Cost-Efficiency Score): Een kosten-georiënteerde variant van VES*. Deze normaliseert de totale kosten (tokenkosten van de LLM + uitvoeringskosten van de query) ten opzichte van de kosten van de ideale query.
• CVQ (Expected Cost per Valid Query): De verwachte kosten om een geldig resultaat te krijgen onder een "retry-until-success" strategie. Dit kwantificeert het risico van fouten bij grote dataschalen.

4. Experimentele Opstelling:

• Uitgevoerd op AWS EC2 en Amazon EMR.
• Vergelijking van diverse state-of-the-art LLMs (o.a. GPT-4o, GPT-5, Claude Opus 4.5/4.6, Gemini 3 Pro/Flash).
• Testen op verschillende dataschalen (Scale Factors van 10 tot 1000).

Belangrijkste Resultaten

1. Traditionele metrics zijn ontoereikend: Bij hoge nauwkeurigheid (waar veel modellen vergelijkbare scores halen) kunnen traditionele metrics geen onderscheid maken tussen modellen. Ze zien geen verschil tussen een snelle, goedkope agent en een trage, dure agent die even goed werkt.
2. VES en VCES bieden scherper onderscheid:*
   • VES* identificeert modellen die niet alleen correct zijn, maar ook efficiënt in agent-interactie en kolom-selectie. GPT-4o scoorde hier het hoogst vanwege een goede balans tussen snelheid en nauwkeurigheid.
   • VCES toont aan dat goedkopere modellen (zoals Gemini 3 Flash) vaak kostenefficiënter zijn, zelfs als ze iets trager zijn of minder nauwkeurig, omdat de tokenkosten lager zijn.
3. De impact van dataschaal:
   • Bij kleine datasets domineert de agent-interactie (LLM-reasoning) de totale tijd.
   • Bij grote datasets (SF 1000) wordt de uitvoeringstijd van de query zelf de bottleneck.
   • CVQ toont aan dat fouten bij grote schalen exponentieel duurder worden. Een model met een kleine nauwkeurigheidsdaling (bijv. 10% minder dan een concurrent) kan bij SF 1000 aanzienlijk hogere kosten veroorzaken dan bij SF 10.
4. Foutanalyse:
   • De meest voorkomende fouten zijn gerelateerd aan "Output Format" (vooral extra kolommen) en "Unaligned Aggregation Structure".
   • Veel fouten die traditioneel als "fout" worden gezien (zoals een extra kolom), zijn in de praktijk vaak "gedeeltelijk correct" en kunnen door de gebruiker eenvoudig worden opgelost, maar kosten wel extra resources.

Bijdragen

1. Nieuw Evaluatiekader: Het introduceren van Text-to-Big SQL als een distinct domein met specifieke metrics (VES*, VCES, CVQ) die kosten, latentie en gedeeltelijke correctheid integreren.
2. Systematische Evaluatie: Een uitgebreide vergelijking van frontier LLMs in een ReAct-agent setting, waarbij inzicht wordt gegeven in de trade-offs tussen snelheid, kosten en nauwkeurigheid.
3. Inzicht in Schaalbaarheid: Het aantonen dat de impact van query-ongenaukigheden toeneemt met de dataschaal, wat nieuwe eisen stelt aan de selectie van modellen voor productieomgevingen.
4. Toekomstgericht Onderzoek: Het identificeren van open vragen, zoals het optimaliseren van agent-stages (het gebruik van verschillende modellen voor verschillende taken), het integreren van fysieke query-planning en het ondersteunen van benaderende queries (approximate queries) voor betere performance.

Betekenis

Dit paper is cruciaal omdat het de kloof overbrugt tussen theoretische Text-to-SQL benchmarks en de realiteit van Big Data-productiesystemen. Het laat zien dat het alleen kijken naar "werkt de SQL?" niet genoeg is; men moet ook kijken naar "hoeveel kost het om de SQL te draaien en hoe snel is het?".

Voor organisaties die AI-agents willen inzetten voor data-analyse op grote schaal, biedt dit werk een praktische leidraad voor het selecteren van modellen:

• Kies voor snelheid (VES*) als interactie cruciaal is.
• Kies voor kosten (VCES) als budget beperkend is.
• Houd rekening met dataschaal: bij zeer grote datasets is een model met iets lagere nauwkeurigheid veel riskanter en duurder dan een nauwkeuriger model.

De studie benadrukt dat de toekomst van Text-to-SQL ligt in het gezamenlijk optimaliseren van de agent, de taalmodel-intelligentie en de database-engine, in plaats van ze als gescheiden componenten te behandelen.