Wat is validatie van AI-output? Elk resultaat toetsen aan regels (formaat, bereik, verplichte velden) vóór het je systeem in gaat. Waarom onmisbaar.
Validatie is het toetsen van een AI-resultaat aan harde regels voordat het verder reist: klopt het formaat, ligt de waarde in een plausibel bereik, zijn alle verplichte velden gevuld, is de som in orde? Een taalmodel produceert taal, geen waarheid. Validatie is de poort die telt wat aanvaardbaar is, en die anders markeert of weigert.
Een taalmodel antwoordt in vloeiende zinnen, en precies daarin schuilt het gevaar: een fout antwoord leest even overtuigend als een juist antwoord. Validatie doorbreekt die indruk door het antwoord niet te lezen maar te meten. De uitvoer van een model wordt eerst in een vaste vorm gegoten (een lijst velden met typen) en daarna aan regels getoetst: is dit een echte datum, ligt dit bedrag boven nul, is dit nummer de juiste lengte, is de som van de regels gelijk aan het totaal?
De regels komen uit twee bronnen. De ene is gezond verstand over het domein: een factuurdatum ligt niet in de toekomst, een postcode heeft een bekend formaat, een percentage ligt tussen nul en honderd. De andere is jouw eigen administratie: welke waarden komen er werkelijk in voor, welke combinaties zijn onmogelijk, welke velden mogen nooit leeg zijn. Die tweede bron maakt validatie sterk: een model mag vlot geloven dat een klant vierhonderd jaar oud is; jouw database weet beter.
Wat te doen met een resultaat dat faalt? Twee eerlijke wegen: weigeren en opnieuw proberen met een scherpere instructie, of doorzetten naar een mens met de foutscore ernaast. Wat nooit mag: het falende resultaat stilletjes behandelen als goed. Een validatiestap die alles doorlaat is geen poort maar een formulier. Hij schrijft alleen maar op dat hij er is. Bij elk werkstroom dat we bouwen hoort daarom bij elke modelstap een expliciet antwoord op de vraag: wat gebeurt er als deze stap mist?
De moeite waard is validatie bij elke AI-stap waarvan de uitvoer verder reist dan het scherm: naar een administratie, een klant, een planning of een bestand. Hoe onherstelbaarder de gevolgen (een boeking, een verzonden brief, een gekoppeld dossier) hoe strenger de poort. Ook in werkstromen die zonder menselijke tussenstap draaien loont hij dubbel, omdat er daar geen lezer is die een rare waarde opvangt.
Het loont niet als de uitvoer alleen wordt gelezen en de lezer zelf oordeelt. Een concept-samenvatting heeft geen harde poort nodig, wel een mens. En validatie is geen vervanging van kwaliteit: als de invoer rommelig is of de instructie vaag, weigeren de regels alles of laten ze alles door, en in beide gevallen zegt de poort niets meer. Validatie is een vangnet, geen paranormafabriek; de kwaliteit wordt vooraf bepaald door goede invoer en scherpe instructies.
In onze werkstromen volgt op elke modelstap een schemastap: velden met typen en regels, ontleend aan het domein en aan jouw eigen gegevens. Wat faalt, gaat niet door. Het wordt herprobeerd, gemarkeerd of naar een mens gezet, en dat gedrag staat vooraf vast. Guardrails en de menselijke controle zijn de buren van deze stap; hoe die samenhangen lees je daar. Trajecten worden op nacalculatie afgerekend, met de aannames van elke stap op papier.
Begin met vier soorten. Formaat: is het een echte datum, een echt nummer, een echt e-mailadres. Bereik: ligt de waarde tussen grenzen die in jouw vak logisch zijn. Verplichting: zijn alle velden die je nodig hebt gevuld. Verhouding: kloppen onderdelen met elkaar. Het totaal met de regels, de einddatum met de begindatum. Vul die vier aan met de bijzonderheden van jouw administratie: combinaties die niet kunnen, waarden die er niet in voorkomen. Hoe concreter de regels uit jouw eigen gegevens komen, hoe scherper de poort.
Dat moet vooraf vaststaan, want het is de kern van de stap. Twee gangbare routes: opnieuw proberen met een aangescherpte instructie en de foutmelding meegegeven, of doorzetten naar een mens die het document of bericht beoordeelt. Welke route per foutsoort geldt, leggen we in het ontwerp vast. Een ontbrekend veld is iets anders dan een onmogelijk bedrag. Wat nooit mag: het antwoord alsnog doorgelaten worden met een aantekening voor later. Dan heeft de poort alleen kosten gegeven en geen bescherming.
Grotendeels bij gestructureerde uitvoer, niet bij alles. Zolang het model velden uit een bron moet vullen, vangt de regelpoort de meeste verzinningen af: een datum die niet bestaat, een bedrag dat niet optelt, een klantnaam die niet in de lijst staat. Wat validatie niet kan zien is een waarde die plausibel is maar verkeerd. Een bedrag dat optelt maar van de verkeerde regel komt. Daarom hoort validatie samen met een bronverplichting voor het model en steekproeven erop; geen enkele stap alleen vangt alles.
Nee, en dat is bewust. De regels worden in gewone taal opgesteld (wat mag niet, wat moet erin, wanneer is een waarde onmogelijk) en worden in het ontwerp van de werkstroom vastgelegd, niet in een script dat niemand leest. Jouw kennis van het vak bepaalt de regels; het bouwen van de poort is ons werk. Wat we van jou vragen is de lijst van velden die tellen en de uitzonderingen die jij kent. En die kennis heb jij al, anders zat je niet te lezen over validatie.
EIGHTY8