Så bygger jag golden datasets för mina egna AI-evals

Ett golden dataset är inte en hög med snygga exempel. Det är en liten, kuraterad uppsättning uppgifter där input, önskat beteende och bedömningsgrund är tillräckligt tydliga för att samma system kan testas igen efter en förändring. Jag bygger hellre 30 genomarbetade cases som täcker verkliga felmoder än 500 syntetiska prompts som alla mäter samma lättaste väg.

Börja med produktens viktigaste jobb

Varje case ska kopplas till ett verkligt användarjobb eller ett dyrt fel. Om jag inte kan förklara varför fallet finns i evalsetet är det sannolikt inte golden. Det gör kontrollen granskningsbar: jag vill kunna peka på vilken artefakt som bar beslutet och vad som skulle behöva ändras för att samma case ska få ett annat utfall.

Blanda normalfall och negativa fall

Jag vill ha typiska uppgifter, svåra edge cases, saknad evidens, konflikter, adversarial inputs och tidigare incidents. Ett dataset med bara happy paths mäter demo-kvalitet. Jag testar alltid minst ett fall där principen borde stoppa flödet — om modellen ändå producerar ett självsäkert resultat har jag byggt en rekommendation, inte en gate.

Skriv expected behavior, inte bara expected answer

För agentflöden kan rätt resultat vara BLOCKED, ett tool call eller en eskalering. Golden truth behöver därför beskriva beteendet och kriterierna, inte alltid en exakt textsträng. I skala blir det här också ett datahanteringsproblem: när IDs, status och ägarskap är explicita går det att återöppna just de delar som påverkas av en ny källa eller en regression.

Frys en kärna men låt datasetet växa

En stabil kärna behövs för jämförbarhet över tid. Nya incidents läggs till som nya cases utan att gamla svåra fall rensas bort för att scoren ska se bättre ut. Det är viktigt att scope följer med: en regel som fungerar i ett visst innehåll eller en viss riskklass ska inte automatiskt bli global standard för alla agentuppgifter.

Undvik contamination där det spelar roll

Ett evalfall som modellen kan hitta ordagrant via browsing kanske inte mäter förmågan du tror. OpenAI lyfter contamination och broken problems som hot mot eval-validitet. Jag försöker därför hålla nästa steg enkelt: handoffen ska innehålla evidens, beslut, osäkerhet och nästa ägare i stället för att nästa agent behöver tolka hela historiken.

Grader måste matcha claimen

Om syftet är faktakorrekthet ska grader inte främst belöna stil. Om syftet är tool safety ska ett vackert svar inte få kompensera för en otillåten action. Det här är en av de punkter där bättre struktur ofta slår en dyrare modell — om systemet inte vet vad som ska mätas kommer mer reasoning bara ge ett mer övertygande oklart svar.

Spara metadata för reproducerbarhet

Case-version, grader-version, modell, harness, tool config och datum gör att scoreförändringar kan tolkas. Annars jämför man lätt två olika experiment som om de vore samma. En bra regression här är medvetet tråkig: samma case ska kunna köras efter en promptändring, modelluppgradering eller refaktorering och visa exakt vilken dimension som flyttade sig.

Använd experter där "rätt" kräver smak

Vissa uppgifter har inget exakt facit. Då behöver golden setet exempel och rubrics från personer som faktiskt kan jobbet, inte bara majoritetsröst från en generisk modell. Jag behandlar därför misslyckanden som framtida testdata: ett dyrt fel som bara dokumenteras i en post-mortem är en missad möjlighet, och nästa release bör möta samma situation i evalsviten.

Ett kontrakt som går att testa

Jag skriver varje case som ett litet kontrakt med fälten case_id, input, evidence, expected_behavior, grader och result, av samma slag som jag beskriver i hur jag tänker kring evals innan lansering — så att systemet kan byta modell eller implementation utan att samtidigt byta definitionen av vad som är bra.

Slutsats

Ett golden dataset är en komprimerad version av produktens kvalitetsdefinition. Det ska bära expertbedömning, verkliga incidents och stabila rubrics så att förbättring kan mätas utan att målstolpen flyttas varje release.