Jouw evaluaties zijn ook onbetrouwbaar: Stop met het vertrouwen op een slaagpercentage dat je niet kunt reproduceren
De meeste mensen weten dat AI-agents niet-deterministisch zijn. Je stuurt dezelfde prompt, maar krijgt verschillende outputs.
We accepteerden dit. We begonnen LLM's te gebruiken als rechters om deze agents te beoordelen.
Maar we maakten een enorme fout. We gingen ervan uit dat onze rechters deterministisch waren. Dat zijn ze niet.
Je evaluatiesuite is een willekeurig systeem dat een ander willekeurig systeem beoordeelt. Als je niet meet hoeveel je beoordelaar schommelt, heb je geen kwaliteitscontrole. Je hebt een muntworp.
Ik zag dit gebeuren bij een support agent. Het dashboard bleef wekenlang groen. Toen schoten de klantklachten omhoog. Ik voerde dezelfde evaluatie uit op 200 oude reacties. 14 daarvan veranderden van oordeel. De agent was niet veranderd. De rechter veranderde van gedachten.
Een onbetrouwbare controle is erger dan geen controle. Het geeft je een vals gevoel van vertrouwen.
Er zijn drie redenen waarom je evaluaties falen:
- Het rechtermodel: Elke LLM-rechter heeft variantie. Zelfs bij temperatuur 0 garanderen providers niet hetzelfde resultaat. Een stille modelupdate kan je baseline van de ene op de andere dag ruïneren.
- De harness: Als je context of tool-outputs veranderen tussen runs door, ziet de rechter een andere vraag. De input is verschoven.
- De rubric: Vage regels zoals "is dit goed?" zorgen voor variantie. Strakke, specifieke regels verminderen dit.
Je moet onbetrouwbare evaluaties behandelen als onbetrouwbare softwaretests. Ship ze niet. Quarantaineer ze. Meet de flake rate.
Stop met het rapporteren van een enkel slaagpercentage. Begin met het rapporteren van overeenstemming (agreement).
Voer elke rechter-aanroep meerdere keren uit. Als de rechter het niet met zichzelf eens kan zijn, is het oordeel geen signaal. Het is ONSTABIEL.
Een ONSTABIEL resultaat moet een first-class outcome zijn in je CI/CD-pipeline. Het moet luid falen.
Om een onstabiele evaluatie te herstellen, heb je twee dingen nodig:
- Een scoringlaag: Deze berekent de stabiliteit en zet resultaten om in PASS, FAIL of UNSTABLE.
- Een tracinglaag: Je moet de ruwe bytes, de exacte prompt en de tool-outputs voor elke run kunnen zien.
Zonder traces zul je denken dat het model gewoon willekeurig is. Je zult de temperatuur verlagen en denken dat je het hebt opgelost. Dat heb je niet. Je hebt de bug alleen maar stiller gemaakt.
Volg deze regels om echte kwaliteit te bouwen:
- Rapporteer overeenstemming, niet alleen gemiddelden.
- Maak UNSTABLE een falende status in je pipeline.
- Pin de versies van je rechtermodel.
- Lees de traces wanneer een check faalt.
Een groen dashboard dat je niet kunt reproduceren, is geen signaal. Het is een verhaal dat je jezelf vertelt.
Optionele leercommunity: https://t.me/GyaanSetuAi