Evals är kravspecen för en AI-funktion

En funktion byggd på en språkmodell svarar olika varje gång den tillfrågas. Därmed faller påståendet som varje kravdokument vilar på: ”det fungerar”. Den här artikeln beskriver vad som ersätter det, vem som skriver ersättningen och vad studion lärde sig när den specade åtta AI-miljöer i en och samma produkt.

Varför räcker ”det fungerar” inte för en AI-funktion?

Därför att det inte finns en enda utdata att kontrollera. En deterministisk funktion godkänns en gång; en modellbaserad måste godkännas statistiskt, över de fall som spelar roll, och godkännas igen varje gång prompten eller modellen ändras. Hamel Husain, AI-konsult som levererat sådana system sedan 2023, skrev den 29 mars 2024 att misslyckade AI-produkter ”almost always share a common root cause: a failure to create robust evaluation systems”. Teamen som misslyckas spelar whack-a-mole: rättar ett svar, förstör ett annat, och vet aldrig var de står.

Vad är en eval, sett från produktsidan?

En specifikation i tre delar, skriven på läsarens språk och ägd av produktrollen.

• Fallen den måste klara: riktiga indata, helst från riktiga användare eller loggar, och för varje fall en beskrivning av vad ett bra svar innehåller.
• Fallen där den måste avstå: frågorna utanför avgränsningen, uppgifterna den aldrig får röja, handlingarna den aldrig får påstå sig ha utfört.
• Toleransen: hur ofta den får missa i varje grupp av fall innan funktionen dras tillbaka, angiven som ett tal som en person har skrivit under.

Husain beskriver tre testnivåer som svarar mot de delarna: billiga kontroller som körs vid varje ändring, granskning av loggade körningar där både människa och modell läser, och A/B-test med riktiga användare. De två första är evalen. Specen är en lista med fall och ett tal, och talet är ett produktbeslut, eftersom det väger kvalitet mot leveranstakt.

Vem skriver den?

Den som annars skulle skriva acceptanskriterierna. En utvecklare kan skriva riggen, men bara produktrollen kan säga vilka tjugo fall som spelar roll, när funktionen ovillkorligen ska avstå och vilken felfrekvens verksamheten tål. Anthropics vägledning om agentdesign, publicerad den 19 december 2024, säger samma sak från arkitektursidan. Den råder team att hitta ”the simplest solution possible, and only increasing complexity when needed” och att välja ett fördefinierat arbetsflöde framför en självständig agent överallt där stegen är kända i förväg. Det valet är ett specbeslut, och det tas av den som äger fallen.

Vad lärde sig studion av att göra det?

Fram till juni 2026 hade Torn Studio produktrollen i Changemkr, en AI-plattform för förändringsledning som studion är delägare i. I slutet av juni körde åtta AI-miljöer på en och samma tjänst, var och en med egen modell, egna verktyg och egen promptversionering med återställning i ett klick. Alla åtta går att räkna i promptregistret. Varje promptändring var en release, och varje release godkändes mot sina fall.

I juni 2026 testade en extern konsultbyrå planerarens AI-assistent och bedömde den som opålitlig. Studion delade upp rapporten i 27 numrerade fynd och grupperade dem efter rotorsak innan någon kod rördes. Då visade det sig att 4 av de 27 var produktbeslut som inte krävde någon kodrättning alls: funktionen gjorde det den var tillsagd att göra, och det den var tillsagd att göra var fel. En eval gör den uppdelningen, bugg eller beslut, synlig innan en testare hittar den.

Den ärliga gränsen går vid verifieringen. Rättningarna verifierades med webbläsartester mot hela stacken i containrar: 11 tester gick igenom och 1 hoppades över. De tre stora generativa flödena testades aldrig hela vägen igenom, eftersom deras utdata varierar mellan körningar och ett test som förväntar sig samma utdata varje gång inte fungerar för dem. Rapporten säger det för varje fynd, och det är hela poängen: en verifiering som redovisar allt som grönt går inte att lita på nästa gång.

Hur hänger evalen ihop med förtroende?

En eval täcker korrekthet. Fallen där funktionen ska avstå eller upplysa användaren täcker förtroende, och de hör hemma i samma dokument. Google PAIR:s People + AI Guidebook ber team att kalibrera förtroendet och att visa hur säker funktionen är i form av kategorier. Ett av råden där är ”tell the user when a lack of data might mean they’ll need to use their own judgment”. EU-kommissionens sida om AI-förordningen säger att chattbotar ska göra människor medvetna om att de talar med en maskin och att transparensreglerna gäller från augusti 2026. Sidan länkar också till förordningstexten. Hur en funktion förtjänar det förtroendet får bli en egen artikel. Fallen skrivs först ner i evalen.

Var modellen hör hemma i ett befintligt system, som ett avgränsat jobb med en kontroll runt sig, beskrivs i AI i era befintliga system. Fallen i en eval väljs på samma sätt som en backlogg prioriteras, och den metoden finns i att bestämma vad som ska byggas härnäst.

Så specar studion en AI-funktion

Product Management hos Torn Studio prissätts per uppdrag, och priset är fast innan arbetet börjar. En AI-funktion inom uppdraget får sin eval skriven före sin prompt: fallen den ska klara, fallen där den ska avstå och toleransen, underskrivna av den som ska läsa talet. Studion bygger sedan mot evalen, så att funktionen levereras med dokumentet som säger vad den får göra och var den ska avstå.