Een model kan in een notitieboekje goed presteren, terwijl het product nog steeds slechte antwoorden geeft. De productieapplicatie kan de vraag herschrijven, een andere bron kiezen, andere tekstfragmenten ophalen of het antwoord na het genereren afwijzen.
Ik wil dat de hoofdevaluatie via hetzelfde applicatiepad verloopt als een echt verzoek. Anders kan het een component certificeren die de klant in zijn eentje nooit tegenkomt.
Zorg voor twee evaluatielagen
End-to-end-testcases laten me zien of het product zich correct gedraagt. Diagnostische testcases helpen vaststellen waarom dat niet het geval is. Ik heb beide nodig.
Voor een ondersteuningsmedewerker kan het volledige traject bestaan uit het beleid van de tenant, modelroutering, het ophalen van gegevens, het genereren van reacties, het valideren van bewijsmateriaal en de overdracht. Een regressie op een van die grenzen moet zichtbaar zijn in het eindresultaat.
Diagnostische controles onderzoeken afzonderlijk de opgehaalde bronnen, herschreven zoekopdrachten, geëxtraheerde beweringen en het gedrag van de provideradapter. Ze zijn nuttig voor onderzoek, maar ik zou het resultaat op productniveau niet vervangen door een verzameling slagingspercentages van afzonderlijke componenten.
Schrijf je verwachtingen op voordat je de uitvoer leest
In elk evaluatiegeval moeten de intentie van de klant, het beschikbare bewijsmateriaal, toegestane beweringen, verboden beweringen en de verwachte actie worden vastgesteld. Sommige gevallen moeten worden afgesloten met een verduidelijkende vraag of een doorverwijzing naar een medewerker.
Ik neem in documenten gewone vragen, ongefundeerde vragen, dubbelzinnige verwijzingen, verouderd materiaal, taalwijzigingen en confronterende instructies op. De verdeling moet de risico’s van het product weerspiegelen, zonder te doen alsof het een perfecte kopie is van het daadwerkelijke verkeer.
Een casusbeschrijving als “goed antwoord over retourzendingen” nodigt uit tot subjectieve beoordeling. “Moet vragen welk product is besteld; mag geen garantie geven dat het in aanmerking komt” biedt een beoordelaar een criterium dat hij of zij consequent kan toepassen.
Gebruik geautomatiseerde juryleden waar dat nuttig is
Deterministische controles zijn nuttig voor exacte identificatiegegevens, toegestane koppelingen, verboden beweringen en verplichte gestructureerde velden. Menselijke controle blijft belangrijk om de semantische juistheid te waarborgen en om te beoordelen of het antwoord de klant helpt.
Een modelgebaseerde beoordelaar kan de inspanning die met beoordelen gepaard gaat verminderen, maar ik beschouw de score ervan als een extra maatstaf die gekalibreerd moet worden. Ik vergelijk deze score met door mensen toegekende labels voor relevante soorten gevallen en onderzoek de verschillen, in plaats van alleen de gemiddelde overeenstemming te meten.
De beoordelingsrubriek moet een zelfverzekerd antwoord zonder onderbouwing afstraffen, zelfs als de formulering uitstekend is. Ook moet onnodige terughoudendheid als een tekortkoming van het systeem worden beschouwd. Een jurylid dat voorzichtigheid beloont zonder dat dit iets oplevert, kan een systeem kiezen dat nooit een antwoord geeft.
Bescherm de testset tegen herhaaldelijk afstemmen
Ik maak een onderscheid tussen voorbeelden die worden gebruikt om de pijplijn te verbeteren en voorbeelden die zijn gereserveerd voor een latere controle. Als elke fout onmiddellijk deel gaat uitmaken van de optimalisatielus, levert de prestatie op diezelfde voorbeelden minder informatie op.
Kleine evaluatiesets kunnen nog steeds waardevol zijn, maar de resultaten ervan moeten worden gerapporteerd met vermelding van de noemers en beperkingen. Een perfect resultaat op basis van een handvol negatieve gevallen is geen bewijs dat ongefundeerde antwoorden zijn uitgesloten.
Door herhaalde simulaties kan variabiliteit aan het licht komen op de punten waar dat van belang is. Ik hoef niet elke deterministische randvoorwaarde vele malen opnieuw te simuleren, maar onstabiel generatiegedrag verdient meer dan één gunstige steekproef.
Vergelijk wijzigingen in hetzelfde bewijsmateriaal
Om een wijziging in de opvraagprocedure te beoordelen, vergelijk ik de oude en de voorgestelde pijplijnen op basis van dezelfde cases en dezelfde bronsnapshot. Ik noteer de codeversie, de promptversie, de modelconfiguratie en de relevante corpusversie.
In mijn evaluatietabel worden ondersteunde antwoorden, niet-ondersteunde antwoorden, onnodige onthoudingen, mislukte overdrachten, vertraging en kosten apart weergegeven. Eén samengestelde score kan een nadelige afweging tussen die aspecten verhullen.
In het releasebesluit moet worden vermeld welke fouten de implementatie blokkeren. Een openbaarmaking die meerdere tenants betreft of een ongeoorloofde handeling verdient een andere beoordelingsstap dan een onhandige maar accurate zin.
Na de implementatie zet ik gecontroleerde productiefouten om in nieuwe cases en houd ik een aparte lijst bij voor toekomstige wijzigingen. De evaluatie vormt dan een bijgewerkte beschrijving van de verplichtingen van het product, gebaseerd op het daadwerkelijke verloop van de applicatie.
Bijgewerkt op 25 september 2026.