Eerst evalueren, dan demonstreren
Iedereen bouwt in een middag een indrukwekkende taalmodeldemo. De evaluatiesuite vertelt u of die volgende maand nog werkt.
Het gat tussen een demo en een product is niet modelkwaliteit. Het is dat een demo wordt afgemeten aan of die de zaal imponeerde, en een product aan of het zich correct gedraagt bij de duizendste aanvraag, tegenover iemand die geïrriteerd is.
Het mechanisme dat dat gat dicht is weinig glamoureus: een gecontroleerde dataset uit echt verkeer, inclusief de randgevallen en de mislukkingen, met verwachte uitkomsten erbij. Al het andere — promptwijzigingen, modelupgrades, routering — wordt daartegen een meetbaar besluit.
Zonder zo'n set belanden teams in een lus die wij voortdurend zien. Iemand past een prompt aan om een klacht op te lossen, niemand controleert wat er verder veranderde, en drie weken later is gedrag dat het deed stilletjes achteruitgegaan. Wanneer, kan niemand zeggen, want er was nooit een nulmeting.
Scoren kan deels geautomatiseerd met een model als beoordelaar, maar pas nadat dat is gekalibreerd tegen menselijke beoordelingen van dezelfde voorbeelden. Een ongekalibreerde beoordelaar is een zelfverzekerde toevalsgenerator, en die vertelt u graag dat de kwaliteit is verbeterd.
Zodra de suite bestaat, gaat die als poort in CI. Een promptwijziging die de score verlaagt, wordt niet samengevoegd. Die ene regel maakt van AI-werk dat riskant voelt iets dat zich gedraagt als de rest van uw engineering.
Het is ook het enige eerlijke antwoord op een klant die vraagt of het ding werkt. U kunt een getal laten zien, geproduceerd uit hun eigen data, voordat iemand budget heeft uitgegeven.