Een antwoord kan duidelijk en beleefd zijn, maar juist op het cruciale punt onjuist zijn. Een klantenservicemedewerker kan de juiste productbeschrijving citeren en vervolgens een leveringsbelofte toevoegen die in de bron helemaal niet staat.
Ik beschouw het genereren en het valideren als afzonderlijke verantwoordelijkheden. Het model stelt een reactie voor. De applicatie beslist of die reactie voldoet aan de bewijs- en productregels die nodig zijn voor de levering.
Breng de claims in kaart die een risico vormen
Niet elke zin hoeft op dezelfde manier te worden behandeld. Een begroeting bevat weinig feitelijke informatie. Een prijs, productcode, garantievoorwaarde of link kan de beslissing van een klant direct beïnvloeden.
Ik begin met het identificeren van die concrete beweringen. De validator vergelijkt deze vervolgens met de opgehaalde bronnen of met gezaghebbende gestructureerde gegevens. Daarbij moeten de onderlinge relaties behouden blijven: het feit dat het getal 49 in een bron wordt aangetroffen, is op zich niet voldoende om een prijs van € 49 voor het geselecteerde product te onderbouwen.
Valuta, variant, hoeveelheid, datum en markt kunnen allemaal de betekenis van een waarde beïnvloeden. Een nuttige controle is om na te gaan of de volledige bewering in de betreffende context wordt ondersteund.
Zorg ervoor dat links gekoppeld blijven aan betrouwbare bronrecords
Een model kan een aannemelijke URL genereren die niet bestaat. Het kan ook een echte URL genereren die naar het verkeerde product verwijst. Ik geef de voorkeur aan links die zijn geselecteerd uit geverifieerde bronrecords boven paden die zijn samengesteld uit gegenereerde tekst.
Voor de linkcontrole is een expliciet normalisatiebeleid nodig. Als alleen domeinen worden vergeleken, zouden veel onjuiste bestemmingen worden geaccepteerd. Als ruwe tekenreeksen worden vergeleken zonder rekening te houden met legitieme opmaakverschillen, kunnen geldige links worden afgewezen.
Als de applicatie een gegenereerde URL ophaalt om deze te valideren, creëert dat ophalen een eigen beveiligingsgrens. In veel gevallen is het eenvoudiger om de URL te vergelijken met een gecontroleerde broncatalogus dan om willekeurige netwerkverzoeken van de validator toe te staan.
Gebruik deterministische controles waar het domein dit toelaat
Identificatiecodes van gestructureerde producten en bekende prijzen lenen zich goed voor deterministische validatie. Vrij geformuleerde omschrijvingen van polissen zijn lastiger: het matchen van trefwoorden kan niet aantonen dat een zin de oorspronkelijke voorwaarden behoudt.
Een modelgebaseerde verificator kan helpen bij het controleren van semantische beweringen, maar voegt daarmee wel een extra, feilbare component toe. Ik zou het systeem afstemmen op door mensen beoordeelde voorbeelden en regels met grote impact expliciet houden. Het is op zichzelf onvoldoende bewijs om hetzelfde generatiemodel te vragen of het correct was.
Een mogelijke resultatstructuur is:
{
"decision": "needs_revision",
"unsupported_claims": ["delivery_by_requested_date"],
"allowed_source_ids": ["shipping-policy-v3"],
"next_action": "ask_for_postcode"
}Dit is een voorbeeldcontract. Het belangrijkste is dat een fout een status oplevert waarop actie kan worden ondernomen, in plaats van een algemene booleaanse waarde die door de daaropvolgende code kan worden genegeerd.
Plan wat er gebeurt als de validatie mislukt
De applicatie kan het proces eenmaal herhalen op basis van beperktere gegevens, een ongefundeerde bewering verwijderen, om ontbrekende informatie vragen of het gesprek doorgeven aan een medewerker. Die keuze moet afhangen van de reden voor de mislukking.
Er moet een limiet worden gesteld aan het aantal herhalingspogingen. Herhaaldelijk verzoeken genereren totdat er een geslaagde reactie komt, kan de kosten opdrijven en tegelijkertijd zwakke plekken in de validator blootleggen. Elke poging moet binnen de tijdslimiet en het budget van het verzoek blijven.
Streaming heeft ook gevolgen voor het ontwerp. Tekst die al aan de klant is getoond, kan niet meer worden verborgen. Als het product validatie vóór levering belooft, moeten opvallende beweringen worden gebufferd of gegenereerd op basis van goedgekeurde gestructureerde velden voordat ze worden vrijgegeven.
Houd de validatie van bewijsmateriaal gescheiden van het vertrouwen in instructies
Een opgehaald document kan zowel nuttige informatie als kwaadaardige instructies bevatten. Het doorstaan van een validatiecontrole geeft dat document nog geen bevoegdheid om de machtigingen van tools of het gedrag van het systeem te wijzigen. De richtlijnen van OWASP inzake promptinjectie vormen een nuttig naslagwerk voor deze afzonderlijke vertrouwensgrens.
Ik wil dat validatiefouten evaluatiegevallen worden. Elke niet-ondersteunde belofte of onjuiste koppeling beschrijft een concreet gedrag dat het systeem de volgende keer zou moeten herkennen, en een regressiecontrole die het team kan uitvoeren voordat de pijplijn wordt aangepast.
Bijgewerkt op 25 september 2026.