Business Truth, not SQL Accuracy: A Rule-Gated 7B Analytics Agent Outperforms a Direct-Prompted 32B Baseline

De Detective versus de Rekenmachine: Waarom het juist hebben belangrijker is dan het snel hebben

Stel je voor dat je in een enorme, chaotische bibliotheek bent waar miljoenen boeken constant worden herschreven, verplaatst of weggegooid. Je vraagt een bibliothecaris: "Hoeveel rode boeken zijn er afgelopen dinsdag verkocht?" Een traditioneel computerprogramma werkt als een supersnelle rekenmachine: het begint onmiddellijk te zoeken, haalt een getal naar voren en roept het naar je terug. Als de wiskunde perfect is, voelt de computer zich trots. Maar wat als "rood" voor jou "crimson" betekende maar voor de bibliothecaris "scarlet"? Of wat als de rode boeken vorige week naar een ander gebouw zijn verplaatst, waardoor de vraag onmogelijk te beantwoorden is? De rekenmachine zou je nog steeds een getal geven, maar het zou het verkeerde zijn, en niemand zou het weten totdat het te laat was.

Dit is de wereld van LLM analytics agents. Dit zijn AI-systemen die ontworpt zijn om met databases (de bibliotheken) te praten en zakelijke vragen te beantwoorden. Lange tijd maten wetenschappers hun succes door te controleren of de AI de juiste "code" (SQL) schreef om de bibliotheek een vraag te stellen. Het is alsoam met een leerling beoordelen enkel op het gebruik van de juiste grammatica, terwijl je negeert of ze het verhaal daadwerkelijk begrepen. Maar in de echte wereld is een "perfecte" zin die tot een foutief getal leidt een ramp. Het is als een GPS die je perfecte aanwijzingen geeft naar een huis dat vorig jaar is afgebrand. De echte uitdaging is niet alleen het schrijven van de code; het is weten wanneer je niet moet antwoorden, wanneer je om verduidelijking moet vragen, en wanneer je moet zeggen: "Ik kan je hier niet bij helpen." Dit artikel duikt in dat rommelige, echte probleem en stelt de vraag: Is het beter om een gigantisch, duur brein te hebben dat zelfverzekerd gokt, of een kleiner, regelvolgend detective die alles dubbelcheckt?

Het Verhaal van QueryProof: De Regelvolgende Detective

In dit onderzoek heeft een onderzoeker genaamd Morris Lee een nieuw soort AI-agent gebouwd genaamd QueryProof. Het doel was om een gedurfde stelling te testen: misschien hebben we geen massief brein van 32 miljard parameters nodig om slim te zijn. Misschien hebben we alleen een kleiner brein van 7 miljard parameters nodig dat wordt gedwongen om strikte regels te volgen en het eigen werk te controleren.

Om dit te testen, creëerde de onderzoeker een speciale speeltuin genaamd WarehouseReliabilityBench. Stel je twee nep-bibliotheken voor (één voor een webshop, één voor een softwarebedrijf) vol met verraderlijke vallen. Van de 400 vragen waren er ongeveer de helft ontworpen om onmogelijk correct te beantwoorden met een simpel getal. Sommige vragen waren ambigu (zoals vragen naar "omzet" zonder te zeggen of je "bruto" of "netto" bedoelt), sommige vroegen naar data die niet bestond, en sommige probeerden de AI te misleiden om de regels te breken. In deze gevallen was het juiste antwoord geen getal; het was een beleefde weigering, een verzoek om meer details, of een "Ik kan dat niet doen"-bericht.

Het experiment vergeleek drie hoofdpersonages:

1. Het Gigantische Brein (32B): Een enorm model dat direct wordt geprompt om alles te beantwoorden. Het had geen vangnet, geen regels, en niemand die het werk controleerde.
2. De Regelvolgende Detective (QueryProof): Een kleiner 7B-model, maar dit model was ingepakt in een "deterministische state machine". Denk aan een strenge supervisor die de AI dwingt om een regelboek te raadplegen voordat hij spreekt. Als de vraag ambigu is, zegt de supervisor: "Stop! Vraag om verduidelijking." Als de data ontbreekt, zegt de supervisor: "Stop! Weiger te antwoorden." De AI mag pas spreken als hij deze controles heeft doorstaan.
3. De Kosten-Gelijke Baseline: Een kleiner model met enkele extra voorbeelden (few-shot) om te zien of het simpelweg geven van meer hints helpt.

De Grote Onthulling: Regels Verslaan Ruwe Kracht

De resultaten waren verrassend en zeer duidelijk. Het Gigantische Brein was zelfverzekerd maar vaak fout. Het probeerde elke vraag te beantwoorden, zelfs de onmogelijke, en gaf daardoor bij de meeste van hen verkeerde zakelijke cijfers. De "False Success Rate" (de ratio van foutieve antwoorden op alle door het model gegeven antwoorden) was een verbluffende 0,754. Het was als een student die op elke vraag van een toets gokt en een hoge score haalt op "inspanning", maar de eigenlijke toets faalt.

QueryProof, de kleinere detective met het regelboek, presteerde volledig beter dan de gigant.

• Nauwkeurigheid: QueryProof behaalde een Business Truth Rate van 0,537 (wat betekent dat het het juiste antwoord of het juiste gedrag vertoonde in 53,7% van de gevallen), terwijl het Gigantische Brein slechts 0,300 haalde.
• Veiligheid: Wanneer QueryProof wel een antwoord gaf, was het minder vaak fout dan het Gigantische Brein. Specifiek waren 35,1% van de antwoorden die QueryProof leverde onjuist, vergeleken met 75,4% van de antwoorden van het Gigantische Brein. Cruciaal was dat op de specifieke vragen die beantwoord konden worden, het Gigantische Brein nul onopgemerkte foutieve getallen gaf, terwijl QueryProof 13 antwoorden gaf op vragen die eigenlijk om verduidelijking of weigering vroegen. De grote overwinning was dat QueryProof de "stille fouten" stopte waarbij een fout getal wordt gerapporteerd zonder enige waarschuwing, waardoor gegarandeerd werd dat er nooit een foutief zakelijk getal werd gerapporteerd bij een uitvoerbare taak.
• Kosten: Hier komt de klapper. QueryProof was 71,0% goedkoper per correct antwoord dan het Gigantische Brein. Het had geen massaal model nodig om betrouwbaar te zijn; het had een goed systeem van controles nodig.

Het onderzoek vond dat de "magie" niet zat in de grootte van het AI-brein. Het zat in de deterministische laag—de rigide regels die de vraag controleerden tegen de werkelijke structuur van de database voordat de AI überhaupt sprak. Deze laag fungeerde als een uitsmijter bij een club, die slechte vragen tegenhield voordat ze problemen konden veroorzaken.

Wat Niet Werkte (En Waarom Dat Belangrijk Is)

De onderzoekers probeerden ook enkele "slimme" functies aan QueryProof toe te voegen, in de hoop het nog beter te maken, maar deze faalden.

• Het Confidence Model: Ze probeerden de AI te leren hoe "zelfverzekerd" hij was, zodat hij vragen kon overslaan waar hij niet zeker van was. Dit werkte niet. Tijdens de test was de geleerde zelfverzekerdheid van de AI feitelijk slechter dan een simpele, handgeschreven regel. Het was als een student die denkt het antwoord te weten maar eigenlijk aan het gokken is, terwijl de simpele regel gewoon eerlijk was.
• Het Routing Systeem: Ze probeerden een systeem dat moeilijke vragen naar een groter model zou sturen. Dit werkte averechts op de testset, waardoor de AI te veel vragen weigerde die hij wel had kunnen beantwoorden.

Het paper is zeer zorgvuldig in het benoemen van deze mislukkingen; ze zijn echt. De "slimme" onderdelen generaliseerden niet van de praktijk naar de uiteindelijke test. Het enige dat werkte, was de saaie, rigide, op regels gebaseerde controle.

De Kanttekening: Hoe Zeker Zijn We?

De onderzoekers zijn eerlijk over de beperkingen van hun verhaal.

• De Speeltuin: De bibliotheken waren synthetisch (nep), gebouwd vanuit een enkele 'seed'. Hoewel dit de test eerlijk en reproduceerbaar maakt, weten we niet zeker of dit ook werkt in een rommelige, echte wereld van een bedrijf met decennia aan slechte data.
• De "Leak": De onderzoekers gaven toe dat ze tijdens de opstelling per ongeluk enkele specifieke zinnen vonden die overeenkwamen met de testvragen. Ze hebben deze verwijderd voor de definitieve test, maar erkennen dat de test niet perfect "schoon" is omdat ze de vragen kenden tijdens het bouwen van de regels. Ze beschouwen de resultaten als een "frozen evaluation" met een bekende fout, niet als een perfect bewijs.
• De Statistiek: Wanneer ze de berekeningen opnieuw uitvoerden met behulp van "families" van vragen in plaats van individuele vragen, werden de betrouwbaarheidsintervallen breder. Dit betekent dat de richting van het resultaat (Regels > Ruwe Kracht) waarschijnlijk waar is, maar de exacte omvang van de overwinning misschien wat onzeker is.

De Kernboodschap

De belangrijkste les hier is dat voor zakelijke analyses betrouwbaarheid voortkomt uit structuur, niet alleen uit omvang. Een kleinere AI, wanneer ingepakt in een strikt systeem van regels dat de data en de vraag controleert voordat er een antwoord wordt gegeven, kan nauwkeuriger, veiliger en goedkoper zijn dan een enorme AI die simpelweg gokt.

Het paper suggereert dat als je een AI wilt die niet tegen je baas liegt, je niet alleen een groter model moet kopen. Je moet een beter "regelboek" en een "uitsmijter" bouwen om het werk te controleren. De "slimme" leerprocessen (zoals confidence scores) zijn misschien leuk om te hebben, maar in dit specifieke geval hielpen ze niet. De echte held was de saaie, deterministische controle die zei: "Wacht even, laten we eerst controleren of deze vraag wel zin heeft voordat we antwoorden."