Evals er kravspecifikationen for en AI-funktion

En funktion bygget på en sprogmodel svarer forskelligt, hver gang den bliver spurgt. Det knækker den sætning, ethvert kravdokument hviler på: »det virker«. Denne artikel handler om, hvad der erstatter den, hvem der skriver erstatningen, og hvad studiet lærte af at specificere otte AI-miljøer i ét og samme produkt.

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

Fordi der mangler ét enkelt output at kontrollere. En deterministisk funktion godkendes én gang; en modelbaseret skal godkendes statistisk, på tværs af de tilfælde, der betyder noget, og godkendes igen, hver gang prompten eller modellen ændres. Hamel Husain, AI-konsulent, der har leveret den slags systemer siden 2023, skrev den 29. marts 2024, at mislykkede AI-produkter »almost always share a common root cause: a failure to create robust evaluation systems«. De teams, der fejler, spiller whack-a-mole: retter ét svar, ødelægger et andet og ved aldrig, hvor de står.

Hvad er en eval, i produkttermer?

En specifikation i tre dele, skrevet på læserens sprog og ejet af produktrollen.

• De tilfælde, den skal klare: rigtige input, helst fra rigtige brugere eller logfiler, hvert med hvad et godt svar indeholder.
• De tilfælde, den skal afstå fra: spørgsmålene uden for afgrænsningen, de data, den aldrig må afsløre, de handlinger, den aldrig må påstå at have udført.
• Tolerancen: hvor ofte den må ramme forbi på hvert sæt, før funktionen trækkes tilbage, angivet som et tal, en person har skrevet under på.

Husain beskriver tre niveauer af test, der svarer til de dele: billige kontroller, der kører ved hver ændring, gennemgang af loggede kørsler ved menneske og model, og A/B-tests med rigtige brugere. De to første er evalen. Specifikationen er en liste af tilfælde og et tal, og tallet er en produktbeslutning, fordi det bytter kvalitet mod levering.

Hvem skriver den?

Den, der ellers ville skrive acceptkriterierne. En udvikler kan skrive riggen; kun produktrollen kan sige, hvilke tyve tilfælde der betyder noget, hvilke afslag der er ufravigelige, og hvilken fejlrate forretningen tåler. Anthropics vejledning om agentdesign, udgivet den 19. december 2024, gør samme pointe fra arkitektursiden: find »the simplest solution possible, and only increasing complexity when needed«, og vælg et foruddefineret workflow frem for en selvstændig agent, overalt hvor trinnene kan kendes på forhånd. Det valg er en specifikationsbeslutning, og den træffes af den, der ejer tilfældene.

Hvad lærte studiet af at gøre det?

Torn Studio havde produktrollen i Changemkr, en AI-platform til forandringsledelse, som studiet ejer en del af, frem til juni 2026. Ved junigrænsen kørte otte AI-miljøer på én tjeneste, hvert med egen model, egne værktøjer og egen promptversionering med tilbagerulning i ét klik, tællelige i promptregistret. Hver promptændring var en release, og hver release blev godkendt mod sine tilfælde.

I juni 2026 testede et eksternt konsulentbureau planlæggerens AI-assistent og rapporterede den som upålidelig. Studiet gjorde rapporten til 27 nummererede fund, grupperede dem efter rodårsag, før nogen kode blev rørt, og fandt, at 4 af de 27 var produktbeslutninger, der slet ikke krævede nogen koderettelse: funktionen gjorde, hvad den var blevet bedt om, og det, den var blevet bedt om, var forkert. Den skelnen, fejl eller beslutning, er det, en eval gør synligt, før en tester gør det.

Verificeringen er der, hvor den ærlige grænse sidder. Rettelserne blev kørt mod hele stakken i containere med browsertests: 11 bestod, 1 blev sprunget over, og de tre store generative flows blev aldrig verificeret fra start til slut, fordi deres output varierer mellem kørsler, og en test, der forventer samme output hver gang, ikke kan bære dem. Rapporten siger det pr. fund, og det er pointen: en verificering, der rapporterer sig selv som helt grøn, er en, ingen kan stole på næste gang.

Hvor kommer tilliden ind?

En eval dækker korrekthed; tilfældene om at afstå og at oplyse dækker tillid, og de hører hjemme i samme dokument. Google PAIRs People + AI Guidebook beder teams om at kalibrere tillid — »tell the user when a lack of data might mean they’ll need to use their own judgment« — og om at vise sikkerhed som kategorier. EU-Kommissionens side om AI-forordningen siger, at chatbots skal gøre folk opmærksomme på, at de taler med en maskine, med gennemsigtighedsregler, der gælder fra august 2026, og linker til teksten. Hvordan en funktion fortjener den tillid, er en artikel for sig; evalen er der, hvor tilfældene skrives ned først.

Hvor modellen sidder i et eksisterende system — det afgrænsede job med en kontrol omkring sig — er beskrevet i AI i jeres eksisterende systemer. Tilfældene i en eval vælges på samme måde, som en backlog prioriteres, og den metode findes i at beslutte, hvad der skal bygges næst.

Sådan specificerer studiet en AI-funktion

Product Management hos Torn Studio prissættes pr. opgave med prisen fast, før arbejdet begynder, og en AI-funktion inden for forløbet får sin eval skrevet før sin prompt: tilfældene, afslagene, tolerancen, underskrevet af den, der skal læse tallet. Studiet bygger derefter mod den, så funktionen leveres med det dokument, der siger, hvad den må gøre, og hvor den skal afstå.