Evals er kravspesifikasjonen for en AI-funksjon

En funksjon bygget på en språkmodell svarer ulikt hver gang den blir spurt. Det knekker setningen ethvert kravdokument hviler på: «det virker». Denne artikkelen handler om hva som erstatter den, hvem som skriver erstatningen, og hva studioet lærte av å spesifisere åtte AI-miljøer i ett og samme produkt.

Hvorfor holder ikke «det virker» for en AI-funksjon?

Fordi det mangler én enkelt utdata å kontrollere. En deterministisk funksjon godkjennes én gang; en modellbasert må godkjennes statistisk, over tilfellene som betyr noe, og godkjennes på nytt hver gang prompten eller modellen endres. Hamel Husain, AI-konsulent som har levert slike systemer siden 2023, skrev 29. mars 2024 at mislykkede AI-produkter «almost always share a common root cause: a failure to create robust evaluation systems». Teamene som mislykkes, spiller whack-a-mole: retter ett svar, ødelegger et annet, og vet aldri hvor de står.

Hva er en eval, i produkttermer?

En spesifikasjon i tre deler, skrevet på leserens språk og eid av produktrollen.

• Tilfellene den må klare: reelle inndata, helst fra reelle brukere eller logger, hvert med hva et godt svar inneholder.
• Tilfellene den må avstå fra: spørsmålene utenfor avgrensningen, dataene den aldri får røpe, handlingene den aldri får påstå å ha utført.
• Toleransen: hvor ofte den kan bomme på hvert sett før funksjonen trekkes tilbake, angitt som et tall en person har signert.

Husain beskriver tre nivåer av testing som svarer til de delene: billige kontroller som kjøres ved hver endring, gjennomgang av loggede kjøringer av menneske og modell, og A/B-tester med reelle brukere. De to første er evalen. Spesifikasjonen er en liste tilfeller og et tall, og tallet er en produktbeslutning fordi det bytter kvalitet mot leveranse.

Hvem skriver den?

Den som ellers ville skrevet akseptkriteriene. En utvikler kan skrive riggen; bare produktrollen kan si hvilke tjue tilfeller som betyr noe, hvilke avslag som er ufravikelige, og hvilken bomrate virksomheten tåler. Anthropics veiledning om agentdesign, publisert 19. desember 2024, gjør samme poeng fra arkitektursiden: finn «the simplest solution possible, and only increasing complexity when needed», og velg en forhåndsdefinert arbeidsflyt fremfor en selvstendig agent overalt der stegene kan kjennes på forhånd. Det valget er en spesifikasjonsbeslutning, og den tas av den som eier tilfellene.

Hva lærte studioet av å gjøre det?

Torn Studio hadde produktrollen i Changemkr, en AI-plattform for endringsledelse som studioet eier en del av, frem til juni 2026. Ved junigrensen kjørte åtte AI-miljøer på én tjeneste, hvert med egen modell, egne verktøy og egen promptversjonering med tilbakestilling i ett klikk, tellbare i promptregisteret. Hver promptendring var en release, og hver release ble godkjent mot sine tilfeller.

I juni 2026 testet et eksternt konsulentbyrå planleggerens AI-assistent og rapporterte den som upålitelig. Studioet gjorde rapporten om til 27 nummererte funn, grupperte dem etter rotårsak før noen kode ble rørt, og fant at 4 av de 27 var produktbeslutninger som ikke krevde noen koderetting i det hele tatt: funksjonen gjorde det den var bedt om, og det den var bedt om, var feil. Det skillet, feil eller beslutning, er det en eval gjør synlig før en tester gjør det.

Verifiseringen er der den ærlige grensen sitter. Rettingene ble kjørt mot hele stakken i containere med nettlesertester: 11 passerte, 1 ble hoppet over, og de tre store generative flytene ble aldri verifisert fra start til slutt, fordi utdataene deres varierer mellom kjøringer og en test som forventer samme utdata hver gang ikke kan bære dem. Rapporten sier det per funn, og det er poenget: en verifisering som rapporterer seg som helt grønn, er en ingen kan stole på neste gang.

Hvor kommer tilliten inn?

En eval dekker korrekthet; tilfellene om å avstå og å opplyse dekker tillit, og de hører hjemme i samme dokument. Google PAIRs People + AI Guidebook ber team om å kalibrere tillit — «tell the user when a lack of data might mean they’ll need to use their own judgment» — og om å vise sikkerhet som kategorier. EU-kommisjonens side om AI-forordningen sier at chatboter skal gjøre folk oppmerksomme på at de snakker med en maskin, med transparensregler som gjelder fra august 2026, og lenker til teksten. Hvordan en funksjon fortjener den tilliten er en egen artikkel; evalen er der tilfellene skrives ned først.

Hvor modellen sitter i et eksisterende system — den avgrensede jobben med en kontroll rundt seg — er beskrevet i AI i systemene dere allerede har. Tilfellene i en eval velges på samme måte som en backlog prioriteres, og den metoden finnes i å bestemme hva som skal bygges neste.

Slik spesifiserer studioet en AI-funksjon

Product Management hos Torn Studio prises per oppdrag med prisen fast før arbeidet starter, og en AI-funksjon innenfor oppdraget får evalen sin skrevet før prompten sin: tilfellene, avslagene, toleransen, signert av den som skal lese tallet. Studioet bygger deretter mot den, slik at funksjonen leveres med dokumentet som sier hva den får gjøre og hvor den skal avstå.