Een assistent die vragen over je eigen cijfers beantwoordt is makkelijk te demonstreren en moeilijk te vertrouwen. In een demo gaat het goed, want de vragen zijn uitgezocht en iemand kijkt mee. Het risico zit in het antwoord dat er goed uitziet: een bedrag dat plausibel is, netjes toegelicht, met een verwijzing naar een rubriek, en nergens in je administratie terug te vinden.
Dat is geen modelfout die met een beter model verdwijnt. Een taalmodel voorspelt tekst, en een getal is tekst. Dus moet je het meten, en meten betekent hier iets anders dan "we hebben het een week geprobeerd en het leek goed".
Ik heb hiervoor een testharnas gebouwd. Niet als demo, maar als bewijsstuk: dertig vragen, zeven controles per antwoord, één logregel per antwoord, en een testsuite die op het moment van schrijven 190 tests groen heeft. Wat hieronder staat is de werkwijze eruit. De aanpak is niet aan één soort administratie gebonden.
Laat het model niet rekenen
De belangrijkste keuze zit vóór het model. Alle cijfers komen uit één laag die de bron bevraagt, en het model krijgt ze aangeleverd. Het mag uitleggen, samenvatten en doorverwijzen. Optellen mag het niet.
Dat klinkt als een beperking en het is de enige reden dat de controle daarna kan werken. Als het model zelf rekent, kun je een fout antwoord namelijk niet onderscheiden van een fout in je koppeling. Door de knip te leggen weet je bij elk getal in het antwoord waar het hóórt te staan.
Praktisch gevolg: geef minder cijfers mee, niet meer. Hoe meer getallen in de context, hoe meer combinaties van som, verschil en percentage er geldig zijn, en hoe groter de kans dat een verzonnen getal toevallig op zo'n combinatie landt.
Maak een vragenset waarvan jij het antwoord al weet
Dit is het werk dat niemand wil doen en dat alles bepaalt. Dertig vragen die een medewerker herkent, met per vraag de feiten die in het antwoord moeten staan.
Eén regel maakt het verschil: die verwachte feiten typ je niet in, je berekent ze uit de bron. Een ingetypt ijkpunt is na de eerste databijwerking stil verouderd, en dan meet je je eigen typefout in plaats van de assistent.
Neem er vragen in op waarvan het goede antwoord "dat weet ik niet" is. Een prognose, een benchmark, een boekjaar dat er niet is. Een assistent die nooit weigert is geen voorzichtige assistent, het is een assistent die gokt op vragen die je nog niet gesteld hebt.
Zeven controles per antwoord
Eén controle op verzonnen getallen is niet genoeg, want "fout" heeft hier meerdere vormen. In mijn harnas draaien er zeven per antwoord. De vorm is overdraagbaar, de inhoud hangt van je eigen domein af.
Elk getal in het antwoord staat in de opgehaalde data, of volgt er met één optelling, aftrekking of percentage uit. De marge is een halve cent, geen percentage. Een vraag buiten de data krijgt geen schatting, en omgekeerd mag een vraag die wél in de data staat niet geweigerd worden. Bij een cijfer hoort een bronverwijzing, en die verwijzing moet echt bestaan: een model kent rubrieknummers uit andere rekeningschema's en noemt die met hetzelfde gemak. Een nog niet afgesloten periode komt nooit als feit uit de assistent. Werk je voor meerdere klanten in één systeem, dan komt geen bedrag, factuurnummer of naam van de één in het antwoord van de ander. En een instructie die iemand in een factuuromschrijving heeft getypt wordt gelezen als tekst, niet uitgevoerd.
Die laatste is geen theorie. Een vrij tekstveld in je eigen administratie is een invoerkanaal dat je zelf hebt gemaakt.
Plant de fouten zelf
Een groene suite zegt niets zolang je niet weet wat er rood wórdt. Van de dertig opgenomen antwoorden in mijn set zijn er negen bewust fout geschreven, elk op één faalpad. Die negen leveren negen bevindingen op en de eenentwintig goede leveren er nul. Dat tweede deel is net zo belangrijk: een controle die ook op goede antwoorden afgaat, zet iemand binnen een week uit.
Nog een stap verder: haal de belangrijkste controle weg in een weggooikopie en draai dezelfde tests. Bij mij vallen er dan zeven om. Zonder die proef weet je van een groene suite alleen dat hij groen is, niet dat hij iets afdwingt.
Eén logregel per antwoord
Per antwoord één regel met de vraag, de opgehaalde bronwaarden, het antwoord, de uitkomst van elke controle, en welke leverancier, welk model en welke regio het heeft gedraaid.
Die laatste drie velden zijn de reden dat het logboek later nog waarde heeft. Een leverancier wisselt een model om zonder dat jij iets verandert. Zonder dat veld in je log is "het was vorige maand beter" een gevoel. Mét dat veld is het een regel die je kunt opzoeken.
Wat zo'n harnas niet vangt
Dit hoort erbij, anders verkoop je zekerheid die je niet hebt.
Het meet niet of een antwoord compleet is. Heeft een vraag twee oorzaken in de data en noemt het antwoord er één, dan is dat niet onwaar en komt het schoon door. Het meet niet of een antwoord begrijpelijk is. Het meet niet of je brondata klopt: levert de koppeling een verkeerd bedrag, dan legt de assistent dat verkeerde bedrag correct en herleidbaar uit. En het weigeringsantwoord herken ik aan een lijst formuleringen, dus een model dat op een nieuwe manier weigert wordt geteld als "antwoordt wel". Dat is de eerste lijst die bij echt gebruik moet groeien.
Grounding beschermt tegen verzinnen. Niet tegen een koppelingsfout, en niet tegen een verkeerde vraag.
Waar je mee begint
Trek twintig vragen uit het werk van vorige week waarvan je het antwoord al weet, schrijf per vraag op welke getallen erin horen, en leg dat lijstje vast voordat je een assistent aanzet. Dat is een middag werk en het is het enige ijkpunt dat blijft staan als je later van model of leverancier wisselt.
Wil je weten hoe dit in jouw administratie uitpakt, kijk dan bij AI-automatisering. Over waar de data tijdens zo'n traject staat, gaat data in eigen beheer.