Utvärderingar: från AI-experiment till trygg produktion

• Även om grundmodellerna har förbättrats är det systematiska utvärderingsmetoder som verkligen har möjliggjort trygg användning i produktion

• Väl utformade utvärderingar hjälper produktchefer, AI-styrningsansvariga och teknikchefer att driftsätta AI-agenter säkert och storskaligt, så att AI går från isolerad leksak till konkurrensfördel.

• Den tryggheten kommer av att AI-agenters beteende utvärderas mot verkliga användarfrågor, gränsfall och domänspecifika scenarier som speglar verksamhetens faktiska sammanhang – inte av ett offentligt prestandatest som säger att ”den här modellen är bäst”

• Målet är att belägga den tryggheten med mätbara resultat. Framgång kräver att "bra" definieras konkret och mätbart utifrån verksamhetens behov och risktolerans – oavsett om det gäller faktamässig korrekthet, lämplig ton, hastighet eller kostnadseffektivitet.

• Genom att integrera utvärdering i hela systemet (instrumentering, loggning, A/B-testning och skyddsräcken) och balansera noggrannhet mot effektivitet kan team driftsätta snabbare och skapa robustare lösningar.

De flesta företag är bekväma med att medarbetarna experimenterar med ChatGPT eller Gemini. Men det är betydligt mindre vanligt att använda LLM:er i arbetsflöden eller miljöer där mycket står på spel.

Skälen har ofta varit välgrundade: kvaliteten har varierat och risken för hallucinationer eller oönskade beteenden har vägt tyngre än teknikens möjliga fördelar.

Balansen mellan risk och nytta har förändrats markant under det senaste året. En del beror på att grundmodellerna har blivit bättre, men mycket beror på den ökade systematiken kring utvärdering (eller ”evals”). Utvärderingar ger oss och våra kunder tryggheten att driftsätta storskaliga och kundinriktade agenter på bara några veckor.

Den här guiden beskriver grunderna i utvärderingar samt hur de utformas, implementeras och används för produktionsfall.

Målet med utvärdering är inte att hitta en perfekt modell, utan att skapa välgrundad trygghet i att modellen beter sig i linje med verksamhetens behov, användarnas förväntningar och organisationens risktolerans.

Varje utvärderingsstrategi utgår från en enkel fråga: Hur ser ”bra” ut? Svaret bör vara konkret. För en organisation kan ”bra” betyda faktamässig korrekthet inom strikta toleranser, medan en annan prioriterar hastighet, kostnadseffektivitet eller ett särskilt tonläge. Alla begränsningar ni arbetar under – från vilka data som får användas till gällande regelkrav – formar definitionen.

Det avgörande är att 'bra' består av komponenter som faktiskt går att mäta. Om framgång innebär att ge användbar finansiell vägledning måste användbarheten uttryckas genom egenskaper som faktamässig korrekthet, lämpliga ansvarsfriskrivningar, personanpassat resonemang och säkra gränser. När ”bra” har definierats mätbart blir nästa fråga hur resultaten ska analyseras och tolkas. Det är genom att agera på resultaten som utvärdering blir en metod i stället för en serie subjektiva bedömningar.

Varje utvärderingspipeline vilar på tre sammankopplade pelare:

1. Indata/prestandatester: Representativa exempel från verkligheten för generell prestanda och handplockade interna datauppsättningar för att testa lämpligheten inom domänen.

2. Modellbeteende: Hur modellen anropas (hämtningsförstärkt generering, sammanfattning, strukturerad informationshämtning och verktygsanvändning).

3. Mätvärden: Hur prestandan mäts och tolkas.

Indatan måste representera den verklighet som systemet kommer att möta. De mest värdefulla insikterna kommer från verkliga exempel: kundfrågor, finansiella scenarier eller branschspecifika fall. Endast genom att testa mot dessa går det att förstå om modellen verkligen uppfattar de nyanser som användarna kräver och uppfyller verksamhetens behov.

Modellens beteende – hur den promptas, hur hämtning och verktygsanvändning orkestreras samt hur kontext tillförs – är lika viktigt som själva modellen. Två identiska modeller kan bete sig mycket olika beroende på hur de driftsätts. Det här lagret måste därför ingå i utvärderingens utformning.

Slutligen har vi mätvärdena. Siffror berättar sällan hela historien, men väl valda mätvärden gör systemets beteende begripligt. Svarstid, korrekthet, säkerhet, koherens, snedvridning, kostnad och användarnöjdhet bildar tillsammans en flerdimensionell bild av ett system i produktion. Konsten ligger i att välja mätvärden som överensstämmer med projektets eller verksamhetens KPI:er och belyser de egenskaper som är viktigast för användarna. Enklare mätvärden är ofta mer träffsäkra och billigare, medan dåliga val kan leda teamet fel. Så här bör ni tänka när ni väljer mätvärden:

Exempel på bra val av mätvärden:

• Chattbot för kundtjänst: Lösningsgrad vid första kontakten (löstes användarens problem utan eskalering?), genomsnittlig handläggningstid, användarnöjdhet och eskaleringsgrad till mänskliga handläggare

• Verktyg för finansiell analys: Källhänvisningarnas korrekthet (andel påståenden med rätt källa), faktaprecision validerad mot facit, hämtningens relevans (hittades rätt dokument?) och resonemangets koherens bedömd av domänexperter

• Assistent för kodgenerering: Korrekt syntax, andel godkända tester, antal säkerhetsbrister och tid till fungerande lösning

Exempel på dåliga val av mätvärden:

• Att enbart använda svarslängd som mått på kvalitet (längre ≠ bättre)

• Att mäta hastighet utan att beakta avvägningen mot korrekthet

• Att följa modellens konfidenspoäng utan att validera dem mot faktisk korrekthet

• Att enbart förlita sig på modellens interna perplexitet utan användarnära validering

Vanliga fallgropar för mätvärden:

• Motstridiga mätvärden: Att samtidigt optimera för snabbhet och fullständighet utan att erkänna avvägningen

• Överanpassning till prestandatester: Att nå 95 % på testdata men misslyckas i produktion eftersom verkliga användare beter sig annorlunda

För en kund inom starkt reglerade finansiella tjänster var korrektheten i lösningen för djup forskning helt avgörande. Vi tog fram både expertskapade fråge- och svarsdata och verktygsgenererade data. Därmed kunde vi bedöma precisionen samt hur väl systemet valde rätt verktyg och hämtade rätt information, vilket gav en balanserad bild av korrekthet och resonemangskvalitet. Nyckeln var att mäta flera dimensioner: faktamässig korrekthet (expertvalidering), hämtningskvalitet (precision/återkallning för relevanta dokument) och resonemangets koherens (strukturerad bedömning av det logiska flödet).

När LLM-as-a-judge bör användas för nyanserad kvalitetsbedömning

LLM-as-a-judge använder en andra AI-modell som utvärderare och ersätter mänsklig granskning med skalbar, automatiserad kvalitetspoängsättning. LLM-as-a-judge används ofta i onödan när enklare mätvärden ger den träffsäkerhet som behövs. Metoden kan vara användbar när deterministiska kontroller inte kan fånga kvaliteten, exempelvis när mätvärdet är semantiskt (hjälpsamhet, faktastöd, resonemangskvalitet, ton eller tolkning av policyer) och deterministisk poängsättning inte är möjlig. Ni kan behöva skalbar återkoppling för många prompt- och modellvarianter samt definiera tydliga bedömningskriterier och ett schema för strukturerade utdata. Följ dessa steg för att få metoden att fungera:

• Definiera bedömningsdimensionerna uttryckligen: korrekthet, faktastöd, policyefterlevnad, handlingsbarhet och ton.

• Använd strukturerade utdata (JSON-schema) för bedömarens svar.

• Samla in både binära kontrollpoäng och diagnostisk text för felanalys.

• Kalibrera bedömarens utdata mot mänskligt märkta exempel i varje lanseringscykel.

• Använd dubbla bedömare eller återkommande konsensuskontroller inom områden där mycket står på spel.

• Följ förändringar hos bedömaren och graden av oenighet över tid.

En datauppsättning för prestandatestning är en fast, handplockad samling testexempel med kända svar som används för att utvärdera modeller enhetligt och jämföra resultat rättvist mellan versioner. Den innehåller vanligtvis indata (exempelvis användarfrågor), förväntade utdata eller referensbedömningar samt utvärderingskriterier eller etiketter för poängsättning. Offentliga prestandatester används för att jämföra ledande modellers prestanda och kan ge en första vägledning om vilka modeller som kan vara lämpliga när systemet utformas.

För det egna systemet går det däremot inte att använda dessa tester som ställföreträdande mått på prestandan i verksamhetens sammanhang, eftersom de har kända brister:

• Kontaminering: Modeller kan ha tränats på testdata. Att utvärdera dem mot samma datauppsättning blir då som att rätta med facit till hands.

• Mättnad: Alla ledande modeller når redan nära maxpoäng. Förbättringar och försämringar begränsas därför till några få procentenheter och ligger ofta inom testresultatens naturliga variation.

• Snävt omfång: Testdata speglar inte era faktiska uppgifter, utan är noggrant utvalda och rensade. Vissa är till och med LLM-genererade och speglar därför inte komplexiteten och gränsfallen i era data, såsom stavfel, ovanliga formuleringar och brusiga bilder.

En elev ber tillämpningen om hjälp med att lösa textuppgifter.

Ett offentligt prestandatest som kan användas: GSM8K (matematiskt resonemang på grundskolenivå)

• Valfri svårare uppsättning: MATH.

Därför är prestandatestet användbart:

• Jämför snabbt vilken modell som är bättre på allmänt matematiskt resonemang,

• Ett bra första filter innan ni investerar i fullständiga produktutvärderingar.

Därför behövs ändå en egen datauppsättning:

Er tillämpning har krav som GSM8K inte testar:

• Kursplanens formuleringar och ämnesordning,

• Förklaringsstil anpassad till åldersgruppen,

• Hantering av tvetydiga elevfrågor eller frågor med många stavfel,

• Policyregler (exempelvis när ledtrådar respektive fullständiga svar ska ges).

Effektiv validering kräver tillämpningsspecifika prestandatester. Datauppsättningarna bör bygga på verkliga interaktioner, typiska gränsfall och rimliga felscenarier. Det kan vara svårt när en ny produkt eller process implementeras. I de flesta fall går det dock att samla in data från en befintlig produkt eller så tidigt som möjligt, även under den första testfasen. När tillämpningen har utvecklats bör prestandatesterna följa produktens utveckling och med tiden bli rikare och mer representativa.

Kopplingen mellan ert tillämpningsspecifika prestandatest och modellvalet är avgörande. Prestandatestet visar inte bara om en lösning fungerar, utan också vilken kombination av modellstorlek och efterträningsmetoder som ger önskad prestanda mest kostnadseffektivt. De kraftfullaste förbättringarna av förtränade modeller (”PT” i ChatGPT) kommer inte från omträning, utan från metoder för "efterträning".

Metoderna formar vilken information modellen har tillgång till, hur informationen struktureras och hur modellen vägleds och orkestreras vid inferens. Efterträningsmetoder som:

• Promptning med tankekedja och dynamisk fördelning av beräkningskraft (tänk mer vid svårare problem)

• Självkonsistens, där flera utdata genereras och den bästa väljs

• Kontextkonstruktion och orkestrering, såsom Retrieval-Augmented Generation (RAG), few-shot-exempel och agentbaserade arbetsflöden

• Verktygsanvändning och tillgång till extern kunskap, vilket gör att modellen kan agera utöver sina interna parametrar

• Strategier för kunskapsrepresentation och lagring, utformade för effektiv hämtning och resonemang över strukturerade och ostrukturerade data

Även om dessa efterträningsmetoder kan förbättra systemets prestanda avsevärt medför de också avvägningar. Varje extra lager av orkestrering, hämtning eller resonemang ökar systemets komplexitet, inferenstid och driftskostnad. Med en genomtänkt kombination av efterträningsmetoder går det dock ofta att använda mindre, snabbare och billigare modeller och ändå uppfylla prestandakraven. I stället för att öka modellstorleken uppnås prestandan genom bättre systemdesign.

Rätt balans är specifik för varje tillämpning och bör fastställas med hjälp av tillämpningsspecifika utvärderingar för att hitta den optimala kombinationen av metoder. De visar när ytterligare orkestrering inte längre ger meningsfulla förbättringar, så att teamet kan välja den lägsta efterträningskomplexitet som krävs för målprestandan.

En AI-lösning måste betraktas som ett helt system: databaser, API:er, användargränssnitt, orkestreringslager, övervakningsinfrastruktur med mera. Utvärderingen måste därför omfatta hela teknikstacken. Övervaka centrala delar av systemet för att upptäcka möjliga problem och kunna öka takten på ett ansvarsfullt sätt.

Att övervaka centrala delar av systemet innebär att:

• Instrumentera era pipelines för mätbara resultat.

• Logga experiment så att effekten av varje justering blir synlig.

• Använd enkla A/B-jämförelser före större driftsättningar för att testa möjliga försämringar.

Datadriven iteration förkortar vägen från prototyp till produktion utan att skapa blinda fläckar. Loggning och övervakning är också viktiga för att förstå hur tillämpningen används i verkligheten. Här är ett exempel på hur observerbarhet kan säkerställas:

• Steg 1: En användarbegäran kommer in med request_id, user_segment och intent.

• Steg 2: Spårningen loggar modellversion, promptversion, hämtade dokument och verktygsanrop.

• Steg 3: En LLM-bedömare poängsätter svaret (correctness, groundedness, policy_risk).

• Steg 4: Regelmotorn utvärderar tröskelvärdena.

• Steg 5: Om ett tröskelvärde överträds utlöses ett larm och ärendet skickas till en reservlösning eller mänsklig granskning.

• Steg 6: Felet läggs i prioriteringskön och därefter i kön för kommande prestandatester.

Verkliga användare beter sig sällan exakt som konstruktörerna förväntar sig. Vissa kommer att missförstå instruktionerna. Andra kommer avsiktligt att söka efter svaga punkter. Dessa gränsfall är inte avvikelser, utan ovärderliga signaler. En väl implementerad utvärderingspipeline fångar och analyserar dem samt för in dem i framtida tester. Snabba iterationer utan blinda fläckar är bara möjliga när utvärderingen byggs in i systemet från början, inte läggs till efter utvecklingen.

Vi rekommenderar att skyddsräcken och övervakning införs från dag ett:

• Följ regelbundet modellens mätvärden och försämringar med hjälp av ert tillämpningsspecifika prestandatest.

• Samla in och granska gränsfall eller fientliga indata (och lägg till dem i datauppsättningen för ert tillämpningsspecifika prestandatest).

• Säkerställ att utvärderingsmåtten överensstämmer med era viktigaste KPI:er.

• Utmana regelbundet datauppsättningen och prestandatestet för att säkerställa att ni inte förbiser nya risker eller påverkas av snedvridningar.

• Inför automatiska larm vid försämrade mätvärden (utlös exempelvis en granskning om korrektheten sjunker under 85 %).

• Behåll en process för mänsklig granskning av beslut där mycket står på spel (juridisk rådgivning, medicinsk vägledning och finansiella transaktioner).

Varje körning av ett prestandatest förbrukar beräkningskraft och energi. Varje överflödigt experiment ökar kostnaden. Ansvarsfull utvärdering bör balansera noggrannhet mot effektivitet.

Några praktiska åtgärder kan hindra energiåtgång och kostnader från att skena:

• Använd mindre modeller när det är möjligt. Kör de första experimenten på billigare modeller och skala bara upp när tillvägagångssättet har validerats.

• Cachelagra prompter och API-anrop.

• Använd energimedveten schemaläggning (batchbearbetning, spotinstanser och flexibel prioritet).

• Följ beräkningsanvändningen parallellt med prestandan.

Var samtidigt uppmärksam på nya AI-regleringar. Även när särskild lagstiftning saknas gäller fortfarande befintliga regelverk och nödvändiga åtgärder, exempelvis:

Dataskydd:

• Säkerställ att datauppsättningar för prestandatester inte innehåller personuppgifter utan korrekt samtycke

• Inför policyer för lagring av loggade frågor

• Tillhandahåll rutiner för begäran om radering av data

Likabehandling och snedvridning:

• Testa prestandan för olika demografiska grupper

• Säkerställ bred representation när prestandatestet skapas

Mänskliga rättigheter och transparens:

• Dokumentera tydligt modellens begränsningar för användarna

• Förklara beslut där mycket står på spel

• Möjliggör mänsklig tillsyn av kritiska tillämpningar

Utvärdering är inte en engångshändelse, utan ett system som ständigt utvecklas. I ett snabbrörligt område ligger fördelen i hur snabbt ni kan testa, lära och anpassa er, så att modeller och nya lösningar kan driftsättas med större effekt.

Genom att göra utvärdering till en central del av utveckling och produktledning kan team förnya snabbare och säkrare. Börja med att definiera vad som är bra i AI-tillämpningens sammanhang, bygg en utvärderingsplattform och utveckla den till ett tillämpningsspecifikt prestandatest som vid varje iteration ger trygghet i att lösningen är produktionsklar.