Are We Asking the Right Questions? On Ambiguity in Natural Language Queries for Tabular Data Analysis

Dit paper presenteert een raamwerk dat ambiguïteit in natuurlijke taalqueries voor tabulair data-analyse herdefinieert als een kenmerk van samenwerking tussen gebruiker en systeem, waarmee het huidige evaluatiemethoden bekritiseert en richtlijnen voor toekomstig onderzoek biedt.

De kern

Titel: Waarom we stoppen met klagen over "onduidelijke" vragen aan computers

Stel je voor dat je een chef-kok (de computer) vraagt om een maaltijd te bereiden.

In de wereld van data-analyse hebben we tot nu toe altijd gedacht dat als een klant (de gebruiker) een onduidelijk bestelling geeft, de chef het probleem is. We dachten: "De klant moet precies zeggen wat hij wil, anders is het mijn fout dat ik de verkeerde maaltijd maak."

Deze paper zegt: "Nee, wacht even. Dat is niet hoe samenwerking werkt."

Hier is de kern van het verhaal, vertaald naar alledaags Nederlands:

1. Het probleem: De "Perfecte" klant bestaat niet

Stel je voor dat je naar een supermarkt gaat en zegt: "Ik wil een salade."
De chef-kok (het systeem) denkt: "Oké, maar welke? Met kip of zonder? Met dressing of zonder? Van deze week of van vorige week?"

In de oude manier van denken (zoals veel huidige AI-systemen doen), proberen ze de chef te dwingen om één perfecte maaltijd te raden, alsof de klant een fout heeft gemaakt. Ze proberen de "verborgen intentie" van de klant te achterhalen.

Maar de auteurs van dit artikel zeggen: Onduidelijkheid is geen fout, het is een teken van samenwerking.
Wanneer jij zegt "een salade", geef je een deel van het werk aan de chef. Jij vertrouwt erop dat de chef weet dat "salade" meestal groenten betekent, en dat hij de rest zelf mag invullen op basis van wat er in de koelkast ligt.

2. De nieuwe kijk: Samenwerking in plaats van perfectie

De paper introduceert een nieuw concept: Coöperatieve vragen.

• De "Samenwerkende" vraag: Jij zegt: "Maak een salade met wat seizoensgroenten."

  • Jij geeft de basis (groenten).
  • De chef vult de rest in (welke groenten, welke dressing) op basis van gezond verstand.
  • Dit is een goede vraag. Het systeem mag hier keuzes maken.

• De "Niet-samenwerkende" vraag: Jij zegt: "Maak iets."

  • Dit is te vaag. De chef weet niet of je een soep, een taart of een salade wilt. Er is geen enkele logische keuze die de chef kan maken. Dit is een vraag die niet opgelost kan worden.

• De "Onmiskenbare" vraag: Jij zegt: "Maak een Caesar-salade met kip, zonder Parmezaanse kaas, met dressing op basis van citroen."

  • Hier is geen ruimte voor interpretatie. De chef moet precies doen wat er staat. Dit is goed om te testen of de chef de instructies kan volgen, maar niet om te testen of de chef creatief kan zijn.

3. De grote ontdekking: We testen de verkeerde dingen!

De auteurs hebben 15 grote lijsten met vragen (benchmarks) onderzocht die gebruikt worden om AI-systemen te testen. Ze ontdekten twee grote problemen:

1. De "Cheats" (Data-Privilege): Veel testvragen bevatten geheimen die een echte klant niet zou weten.

   • Voorbeeld: Een vraag zegt: "Hoeveel mensen hebben de bestelling met ID #A729 gedaan?"
   • Een echte klant in de open wereld weet die ID niet. Die weet alleen: "Hoeveel mensen hebben pizza besteld?"
   • De huidige tests laten AI-systemen slagen door te raden op basis van deze "cheats", terwijl ze in de echte wereld zouden falen.

2. De "Mix" van vragen: De tests mengen alle soorten vragen door elkaar.

   • Ze testen of de AI een simpele som kan maken (wat een simpele vraag is) en of de AI een creatieve keuze kan maken (wat een samenwerkende vraag is) in dezelfde test.
   • Analogie: Het is alsof je een kok test door hem te vragen of hij een ei kan bakken (simpele taak) en of hij een compleet diner kan bedenken voor een bruidspaar (creatieve taak), en dan zegt: "Hij heeft 50% goed gedaan." Dat zegt je niets over of hij een goede kok is.

4. Wat moeten we nu doen? (De oplossing)

De paper stelt drie dingen voor om de toekomst beter te maken:

1. Testen met de juiste vragen:

   • Wil je weten of de AI goed kan rekenen? Gebruik dan onmiskenbare vragen (alles staat er precies op).
   • Wil je weten of de AI slim kan meedenken? Gebruik dan samenwerkende vragen (waar de AI keuzes moet maken).
   • Stop met het testen van creatieve keuzes met vragen die al een vast antwoord hebben.

2. AI's die durven te kiezen:

   • Ontwerp systemen die zeggen: "U vroeg om een salade. Ik heb verse spinazie en tomaat, dus ik maak een Caesar-salade. Vindt u dat goed?"
   • In plaats van te raden of te falen, moet de AI zijn keuze uitleggen. Als de klant het niet leuk vindt, kan hij zeggen: "Nee, ik wilde geen kaas."

3. Van "één keer vragen" naar "gesprek":

   • Als de vraag te vaag is (zoals "Maak iets"), moet de AI niet raden. Het moet vragen: "Bedoelt u een soep of een hoofdgerecht?"
   • Dit is een gesprek, geen commando.

Conclusie

De boodschap is simpel: Stop met proberen de mens perfect te maken.

Mensen zijn nu eenmaal niet perfect in het specificeren van wat ze willen. Ze vertrouwen erop dat de ander (de computer) een beetje meedenkt. Als we AI-systemen ontwerpen die dit vertrouwen waarderen en slimme keuzes maken in plaats van alleen maar exacte instructies te volgen, krijgen we veel betere en menselijkere tools voor het analyseren van data.

Kortom: Laat de chef-kok soms zelf de dressing kiezen, zolang hij maar weet dat het een salade moet zijn.

Technische samenvatting

Probleemstelling

Interacties met tabulaire data via natuurlijke taal (NL) worden gekenmerkt door inherent onduidelijkheden (ambiguïteit). In bestaande systemen, zoals Text-to-SQL en open-domein data-analyse, wordt deze ambiguïteit traditioneel behandeld als een technisch gebrek dat moet worden opgelost door het achterhalen van één enkele, "ware" gebruikersintentie.

De auteurs stellen echter dat deze benadering fundamenteel verkeerd is, vooral in open-domein scenario's waar gebruikers geen perfecte kennis van de onderliggende datastructuur hebben.

• Huidige aanpak: Ambiguïteit wordt gezien als een fout die moet worden gecorrigeerd (post-hoc detectie en classificatie).
• Het probleem: Benchmarks en evaluaties mengen verschillende soorten queries zonder onderscheid te maken. Dit leidt tot evaluaties die systemen niet eerlijk testen op hun vermogen om intenties te interpreteren versus hun vermogen om uitvoeringen nauwkeurig uit te voeren. Veel bestaande datasets bevatten "data-privileged" queries (waarbij de gebruiker kennelijk de schema-structuur kent), wat de open-domein aanname ondermijnt.

Methodologie

De auteurs introduceren een nieuw raamwerk gebaseerd op cooperatieve interactie (geïnspireerd door Grice's coöperatieprincipe en het principe van minimale inspanning). In plaats van de gebruiker te dwingen tot perfecte specificatie, wordt ambiguïteit gezien als een bewuste verdeling van arbeid tussen gebruiker en systeem.

1. Het Cooperatieve Query Raamwerk:
De auteurs definiëren queries op basis van wat de gebruiker expliciet maakt versus wat het systeem moet afleiden (grounding):

• Coöperatieve Queries: Queries die voldoende specificatie bieden (expliciet of via redelijke inferentie) om tot minstens één geldige, uitvoerbare interpretatie te komen.
  • Unambiguous Queries: Mapen naar één unieke interpretatie via gebruiker-informatie en conventionele kennis (geen systeemkeuzes nodig).
  • Coöperatieve (maar ambigu) Queries: Vereisen selectieve grounding. Het systeem moet een keuze maken uit een reeks redelijke opties (bijv. "relatie tussen X en Y" -> kies Pearson of Spearman correlatie).
• Niet-coöperatieve Queries: Queries die te vaag zijn om tot een geldige interpretatie te komen (bijv. "Wat is de gemiddelde temperatuur?" zonder locatie). Deze zijn onoplosbaar en testen de robuustheid van het systeem.

2. Grounding Mechanismen:

• Gebruiker-geleverde grounding: Expliciete informatie in de query.
• Systeem-geinferreerde grounding:
  • Conventioneel: Oplossing via universele conventies (bijv. "hoogste berg" -> "ter wereld").
  • Selectief: Het systeem krijgt de bevoegdheid om uit redelijke opties te kiezen.

3. Empirische Analyse:
De auteurs hebben dit raamwerk toegepast op 15 bestaande datasets voor tabulaire vraag- en antwoordtaken, Text-to-SQL en data-analyse (o.a. Spider, BIRD, DA-Eval, FeTaQA).

• Ze gebruikten LLM-gebaseerde classifiers (gevalideerd door menselijke experts) om elke query te analyseren op twee dimensies:
  1. Data-Afhankelijkheid: Is de query "data-privileged" (gebruikt het schema of interne waarden)?
  2. Coöperatieve Interpretatie: Is de query unambiguus, coöperatief (vereist selectieve grounding) of niet-coöperatief?

Belangrijkste Resultaten

De analyse van de 15 datasets (zie Figuur 2 in het paper) onthult systematische tekortkomingen in huidige evaluaties:

1. Overvloed aan Data-Privileged Queries: Veel datasets, vooral voor complexe analyses, bevatten queries die verwijzen naar kolomnamen, interne IDs of specifieke dataset-containers. Dit geeft systemen "shortcuts" die in een echt open-domein scenario niet beschikbaar zouden zijn.
2. Gebrek aan Unambiguïteit: Unambiguie queries (die één waar antwoord hebben) vormen slechts een klein percentage van de datasets.
   • Dit betekent dat de meeste datasets niet geschikt zijn om de uitvoeringsnauwkeurigheid (execution accuracy) te testen, omdat er geen "gold standard" antwoord is.
   • Tegelijkertijd zijn ze ook niet geschikt om interpretatie-vaardigheden te testen, omdat de datasets vaak slechts één bedoeld antwoord toelaten, terwijl er in werkelijkheid meerdere redelijke interpretaties mogelijk zijn.
3. Vermenging van Doelen: Huidige evaluaties verwarren de nauwkeurigheid van de uitvoering met het vermogen van het systeem om menselijke keuzes te maken bij ambiguïteit.

Kernbijdragen

1. Conceptueel Raamwerk: Een verschuiving van "ambiguïteit als fout" naar "ambiguïteit als kenmerk van samenwerking". Dit definieert duidelijk de grenzen tussen wat de gebruiker moet specificeren en wat het systeem mag infereren.
2. Evaluatie-richtlijnen: Een bewezen methode om benchmarks te categoriseren. De auteurs stellen dat evaluaties moeten worden gescheiden:
   • Gebruik unambiguie queries voor het testen van uitvoeringsnauwkeurigheid.
   • Gebruik coöperatieve queries (met selectieve grounding) voor het testen van interpretatie- en afstemmingsvaardigheden.
   • Gebruik niet-coöperatieve queries voor het testen van robuustheid.
3. Empirisch Bewijs: Een gedetailleerde analyse van 15 populaire datasets die aantoont dat ze momenteel onvoldoende zijn voor open-domein evaluatie vanwege de aanwezigheid van data-privileged queries en het gebrek aan variatie in query-specifisatie.

Betekenis en Toekomstperspectief

De paper biedt een fundamentele heroriëntatie voor het ontwerpen en evalueren van systemen voor tabulaire data-analyse:

• Ontwerp van Systemen: Systemen moeten proactief worden ontworpen om "grounding" uit te voeren en hun keuzes transparant te maken aan de gebruiker. In plaats van te falen bij ambiguïteit, moeten systemen een mixed-initiative dialoog aangaan om de gebruiker te helpen de query te specificeren.
• Verbetering van Benchmarks: Bestaande datasets moeten worden aangevuld met annotaties over het niveau van specificatie en de aard van de grounding. Nieuwe datasets moeten iteratieve query-verfijning ondersteunen, waarbij meerdere geldige interpretaties mogelijk zijn.
• Open-Domein Realiteit: Voor echte open-domein systemen is het cruciaal om systemen te bouwen die kunnen omgaan met onvolledige mentale modellen van gebruikers, waarbij het systeem de verantwoordelijkheid deelt voor het interpreteren van intenties.

Kortom, de auteurs pleiten voor een stopzetting van de "single-answer" evaluatiemethode en een overstap naar een meer nuancierte, cooperatieve benadering die de complexiteit van mens-systeem interactie in data-analyse eerlijk weergeeft.