Hoe je een LLM-functie evalueert voordat deze live gaat

"Ik heb het op een paar voorbeelden geprobeerd en het werkte" is het meest gehoorde antwoord wanneer een team beschrijft hoe ze een AI-functie hebben getest, en het is geen evaluatie, het is een demo. Het gat tussen "werkte op de voorbeelden die ik toevallig probeerde" en "betrouwbaar genoeg om voor klanten te zetten" is precies waar AI-functies na lancering misgaan, en het is te dichten vóór lancering als je een echt evaluatieproces bouwt in plaats van een informeel.

Een echte evaluatieset begint met daadwerkelijke zoekopdrachten, geen verzonnen. Haal echte voorbeelden uit supporttickets, zoeklogs, of hoe gebruikers daadwerkelijk met de functie zouden omgaan, niet de nette, goed geformuleerde vragen die een developer schrijft tijdens het bouwen. Echte gebruikers stellen dubbelzinnige vragen, maken typefouten, en formuleren dingen op manieren die je eigen testgevallen nooit hebben voorzien als je die zelf hebt geschreven.

Elk voorbeeld heeft een gelabeld correct antwoord nodig, bepaald door iemand die het domein daadwerkelijk kent, voordat je iets tegen het model laat draaien. Zonder een gelabeld antwoord om tegen te vergelijken, wordt "hoe deed het het" een momentopname-oordeel, wat precies het soort inconsistente evaluatie is dat een functie op gevoel laat uitkomen.

Bepaal de omvang van de set op basis van de daadwerkelijke variatie in je input, niet op een rond getal dat grondig aanvoelt. Vijftig goed gekozen voorbeelden die je echte zoekpatronen dekken, inclusief de lastige, vangen meer regressies dan vijfhonderd voorbeelden die allemaal lichte variaties van het makkelijke geval zijn. We bouwen deze sets iteratief op, beginnend klein en voorbeelden toevoegend zodra nieuwe faalpatronen in productie opduiken.

De set verdient zijn plek alleen als hij bij elke wijziging opnieuw wordt uitgevoerd, niet alleen vóór de eerste lancering. Een prompt-aanpassing, een modelupgrade, een wijziging in wat wordt opgehaald vóór generatie, elk van deze kan sommige gevallen verbeteren en stilzwijgend andere breken. Dezelfde gelabelde set na elke wijziging opnieuw uitvoeren is wat "we hebben het ding opgelost dat we opmerkten en drie dingen gebroken die we niet opmerkten" opvangt.

Volg fouten per categorie, niet alleen als slaagpercentage. Eén enkel percentage vertelt je dat er iets mis is; het vertelt je niet wat je moet oplossen. Fouten opsplitsen in categorieën, verkeerde retrieval, correcte retrieval maar verkeerde redenering, correct antwoord maar verkeerde toon of formaat, vertelt je of de volgende oplossing in je data, je prompt, of je retrieval-pipeline hoort.

Bepaal wat "goed genoeg om uit te brengen" betekent voordat je de resultaten ziet, niet erna. Het is makkelijk om een middelmatige score te rationaliseren zodra je ernaar staart te kijken en wilt lanceren. Vooraf een drempel instellen, en wat er gebeurt met fouten eronder (menselijke terugval, een UI-behandeling met lagere betrouwbaarheid, de functie volledig blokkeren), houdt de evaluatie eerlijk in plaats van een formaliteit die je jezelf voorbij praat.

Niets hiervan is een eenmalige poort vóór lancering. De evaluatieset is een levend bezit: elke echte productiefout die wordt gerapporteerd, wordt een nieuw gelabeld voorbeeld dat eraan wordt toegevoegd, zodat de set beter wordt in het opvangen van de exacte fouten die je gebruikers daadwerkelijk tegenkomen, niet alleen de fouten die je voorzag toen je het bouwde. Een functie die één keer vóór lancering is geëvalueerd en daarna nooit meer, is een functie waar je binnen een maand na uitbrengen blind op vliegt.