Waarom een taalmodel niet mag rekenen, en hoe je dat oplost

Een taalmodel voorspelt tekst, het rekent niet. Daarom haal je getallen via een vaste route uit je eigen systeem en laat je het model alleen de zin eromheen schrijven.

Een taalmodel rekent niet. Het voorspelt telkens het volgende stukje tekst dat gezien de voorgaande tekst het waarschijnlijkst is, en getallen zijn daarbij gewoon tekst. Daarom laat je in een zakelijk proces de bedragen nooit door het model bedenken: je haalt ze via een vaste route uit je eigen systeem, en het model schrijft alleen de zin eromheen.

Dat klinkt als een beperking, maar het is de reden dat lokale AI in de administratie te vertrouwen is. Hieronder staat hoe zo’n model werkt, waarom juist cijfers misgaan, en hoe een werkgang eruitziet waarin dat niet meer kan gebeuren.

Hoe werkt een taalmodel eigenlijk?

Een taalmodel is een statistisch model dat tekst opdeelt in stukjes, tokens genoemd, en bij elke stap berekent welk volgend stukje het waarschijnlijkst is. Meer is het niet. Daarom werkt het zo goed voor taal.

Zo’n stukje is soms een heel woord, vaker een deel ervan. “Meerwerk” kan als “meer” en “werk” de machine in gaan. Het model heeft geen opgeslagen feiten die het opzoekt en geen rekenkern die sommen maakt. Het heeft patronen: in miljarden zinnen is het woord dat na “de factuur is verzonden naar” komt vaak een bedrijfsnaam, dus voorspelt het een bedrijfsnaam.

Voor schrijven is dat prima gereedschap. Een ruwe notitie van de bouwplaats omzetten in een nette factuuromschrijving is precies waar taalpatronen voor deugen. Het gaat mis zodra je iets vraagt wat geen taalpatroon is maar een feit.

Waarom gaan juist getallen mis?

Omdat een getal voor het model geen waarde heeft, alleen een vorm. Drie dingen komen daar samen.

Getallen worden in stukjes geknipt. Een bedrag als 14.375 kan als meerdere losse stukjes verwerkt worden. Het model ziet dus niet één waarde, maar een reeks tekens die er plausibel uit moet zien. Dat het vaak toch goed gaat bij eenvoudige sommen, komt doordat die sommen ontelbaar vaak in de trainingstekst stonden, niet doordat er gerekend wordt.

Plausibel is niet hetzelfde als correct. Het model kiest wat waarschijnlijk is. Een factuurtotaal van 12.480 euro is een waarschijnlijk uitziend getal, ook als het echte totaal 12.840 is. Er is in de uitvoer niets dat het verschil verraadt.

Fout en goed zien er hetzelfde uit. Een mens die twijfelt, aarzelt. Een model schrijft een verzonnen bedrag met dezelfde vlotte pen als een gecontroleerd bedrag. Dat is de kern van wat “hallucineren” wordt genoemd: niet dat er fouten in zitten, maar dat je ze er niet aan af kunt zien.

Waar het in de praktijk misgaat, is voorspelbaar: optellen van regels, btw-percentages toepassen, staffels en kortingen, omrekenen van eenheden, uren optellen over weken heen, en datumrekenwerk zoals een vervaldatum van dertig dagen. Stuk voor stuk dingen die elk boekhoudpakket al foutloos doet.

Er is wel een taak waar het model bij getallen juist sterk in is: overnemen. Uit een pdf halen dat er 14.375,00 op de factuur staat, is herkennen en kopiëren, geen rekenen. Ook daar hoort een controle bij, maar het is een wezenlijk ander soort taak dan uitrekenen.

Wat is een vaste dataroute?

Een vaste dataroute is een vooraf vastgelegde opzoekactie of berekening in je eigen systeem, uitgevoerd door software en niet door het taalmodel. Het model mag bepalen welke vraag er gesteld wordt en het antwoord in gewone taal verwoorden. Het getal zelf komt uit de database of uit de rekenregel.

In technische termen heet dat functieaanroepen: het model krijgt een lijst met functies die het mag aanroepen, zoals “haal het openstaande saldo van deze klant op” of “bereken de offerteprijs voor dit aantal panelen”. Stelt iemand de vraag “wat staat er nog open bij Van Dijk Installaties?”, dan schrijft het model niet het bedrag, maar roept het de functie aan. De software zoekt het op, en het model maakt er een zin van.

Het verschil in praktijk: de vraag twee keer stellen levert twee keer hetzelfde bedrag op, want het komt uit dezelfde regel in dezelfde database. En als het bedrag niet klopt, zit de fout in je administratie, waar je hem kunt nakijken.

Hoe ziet dat er in een offerte uit?

Neem een installateur die zonnepanelen verkoopt. Er komt een aanvraag per mail binnen en er moet een offerte uit. De werkgang die wij daarvoor inrichten, en die in de demo bij ZonKracht Solar te zien is, verloopt zo:

1. De mail komt binnen en het model doet de intake. Het haalt eruit wat er staat: adres, soort dak, gewenst aantal panelen, of er een laadpaal bij moet. Dit is taalwerk. Daar is een model goed in.
2. De gegevens gaan in een vast schema. Geen lopende tekst, maar velden. Ontbreekt er iets, dan blijft het veld leeg in plaats van dat het wordt ingevuld met iets aannemelijks.
3. De prijs wordt berekend met vaste rekenregels. Paneelprijs, montagekosten, staffel, btw: allemaal regels in software, dezelfde die je calculator ook zou gebruiken. Het model komt hier niet aan te pas.
4. Het model schrijft de begeleidende tekst. De toelichting, de aanhef, de uitleg bij de keuzes. Met de berekende bedragen erin als gegeven, niet als iets dat het zelf invult.
5. Jij of een collega keurt goed. Pas daarna gaat de offerte de deur uit.

Dezelfde scheiding zie je bij inkoopfacturen. Het model leest de pdf uit en stelt voor: deze leverancier, dit bedrag, dit project. De pdf blijft de bron die je erbij kunt openen, en de controle of het bedrag klopt tegen de inkooporder is een vaste regel, geen inschatting. Hoe zo’n werkgang in de bouw loopt staat in inkoopfacturen automatisch verwerken met AI.

Hoe weet je of een antwoord klopt?

Met drie dingen die in elk systeem dat wij neerzetten standaard aanstaan.

Elk antwoord toont zijn bron. Bij een conceptantwoord aan een klant staat uit welk stuk van de goedgekeurde kennisbank het komt, met een gelijkenisscore: hoe dicht lag de gevonden tekst bij de vraag? Een lage score betekent niet dat het antwoord fout is, maar wel dat je beter kijkt voordat je op verzenden drukt.

Jij of je collega beslist. Niets gaat naar buiten zonder goedkeuring. Dat is geen tijdelijke maatregel voor de opstartfase, het is hoe het blijft bij alles wat het pand verlaat of in je boekhouding terechtkomt.

Elke stap is zichtbaar. Je kunt terugkijken welke vraag er is gesteld, welke functie is aangeroepen, welk document is gevonden en hoe lang elke stap duurde. Als iemand over drie maanden vraagt waar dat bedrag vandaan kwam, is dat na te lopen.

Daar hoort een vierde bij die je zelf kunt doen: controlevragen. Stel het systeem vragen waarvan je het antwoord al weet, en vragen waarop het antwoord niet in je data staat. Bij die laatste soort hoort een systeem te zeggen dat het het niet weet. Doet het dat niet, dan mag het niet los op je klanten. In de demo zit daarom een zelftoets met zulke controlevragen, zodat je het gedrag zelf kunt uitproberen in plaats van dat wij het beloven.

En modellen die kunnen redeneren?

Er zijn modellen die hun stappen uitschrijven voordat ze antwoorden, en die halen een deel van de rekenfouten eruit. Ze mogen ook gerust een rekenfunctie aanroepen; dat is precies het idee van een vaste dataroute. Wat er niet verandert, is waar een bindend getal vandaan komt. Op een factuur, een offerte of een urenstaat is dat het bronsysteem, ook als het model het er zelf ook uit had kunnen krijgen. Zodat je bij een controle kunt aanwijzen welke regel welk bedrag opleverde.

Wat je nu kunt doen

Pak de laatste tien teksten die bij jou met AI zijn opgesteld en streep elk getal aan. Vraag per getal: waar kwam dit vandaan, en kan ik dat aanwijzen? Elk getal waarop het antwoord “uit het model” is, is een getal dat via een vaste route uit je eigen systeem zou moeten komen. Dat lijstje is meteen de opdracht voor de inrichting. Wil je het werkend zien, dan laat de demo vijf fictieve bedrijven zien op één lokaal AI-systeem, waarin je per stap ziet waar een getal vandaan komt. Welke werkgangen zich hiervoor lenen staat op automatiseringen, en hoe wij het beheren op hoe wij het beheren.