Bygg utvärderingar som faktiskt upptäcker regressioner

Du har byggt en utvärderingssvit. Den går igenom. Du driftsätter. Användarna klagar omedelbart på regressioner som utvärderingen inte upptäckte.

Det här är ett av de vanligaste – och mest nedslående – mönstren i produktionsarbete med LLM:er. Utvärderingssviter som ser imponerande ut men missar regressionerna som är viktiga. De skapar falsk trygghet. Teamet litar på dem, levererar ändringar som försämrar kvaliteten och upptäcker problemet först när användarna påtalar det.

Att bygga utvärderingar som faktiskt upptäcker regressioner är svårare än det verkar. Grunderna (dataset, förväntade utdata och poängsättning) är enkla. Arbetet ligger i att göra dem till en tillförlitlig signal.

Den här artikeln beskriver vad vi har lärt oss om att bygga utvärderingar som håller – för team som tar kvaliteten i produktions-AI på allvar.

Vad bra utvärderingar gör

När en bra utvärderingssvit körs på en föreslagen ändring ger den ett svar med hög säkerhet på frågan: ”Är den här ändringen bättre, sämre eller likvärdig med den nuvarande versionen?”

Skillnaderna:

• Upptäcker regressioner. När kvaliteten försämras för verkliga användningsmönster sjunker utvärderingspoängen.
• Upptäcker förbättringar. När kvaliteten förbättras återspeglas det i poängen (inte bara i handplockade fall).
• Är stabil vid oförändrat läge. När inget väsentligt har ändrats är poängen konsekvent.
• Går att lita på vid beslut. Beslut som fattas utifrån utvärderingspoäng korrelerar med faktiska användarresultat.

Var och en av dessa punkter är svårare än den låter.

Datasetproblemet

Din utvärdering är aldrig bättre än sitt dataset. De flesta bristfälliga utvärderingssviter fallerar här.

Vanliga datasetfel

Fel 1: Handplockade enkla fall. Datasetet skapades när systemet fungerade, ofta av ingenjören som byggde det. Personen valde fall som ”verkade rimliga” – tydliga exempel på varje beteende. Verklig produktionstrafik är stökigare. Svåra, tvetydiga och extrema fall dominerar bland felen men är underrepresenterade i datasetet.

Fel 2: Inaktuellt dataset. Datasetet byggdes för sex månader sedan. Sedan dess har användarnas beteende förändrats, nya funktionsområden tillkommit och nya produktfunktioner lanserats. Datasetet testar en gammal version av verkligheten.

Fel 3: Ingen täckning av regressionskänsliga områden. Utvärderingen täcker det förväntade flödet grundligt men prövar inte gränserna där regressioner faktiskt uppstår.

Fel 4: Kontaminering av datasetet. Exempel som används i utvärderingen förekommer också i prompten eller finjusteringsdatan. Modellen ”minns” dem. Testresultaten blir överdrivet höga och den verkliga prestandan är sämre.

Fel 5: Obalanserad fördelning. 80 % av datasetet består av en typ av indata och 5 % av den långa svansen. En regression i den långa svansen påverkar knappt poängen trots att det är en verklig regression.

Bygg ett starkt dataset

Några principer som ger starka dataset:

Utgå från verklig produktionstrafik. De bästa exemplen är verkliga användarindata (med personuppgifter borttagna). De innehåller precis den oreda som systemet måste kunna hantera.

Ett praktiskt arbetsflöde:

1. Samla in ett urval av produktionsanrop (med lämpliga integritetskontroller).
2. Märk förväntade utdata manuellt (eller låt en LLM märka dem och verifiera sedan manuellt).
3. Lägg till fallet i utvärderingsdatasetet.
4. Uppdatera datasetet regelbundet (en gång i månaden är en bra takt).

Ta med varierade fellägen. Inkludera särskilt fall som tidigare har fallerat i produktion. De blir regressionstester – när du åtgärdar ett fel lägger du till det felande fallet så att felet förblir åtgärdat.

Stratifiera datasetet. Kategorisera fallen (lätta/medelsvåra/svåra, efter ämne, användartyp och längd). Säkerställ att varje kategori har meningsfull täckning. Följ poäng per kategori, inte bara totalpoängen.

Blanda svårighetsgrader. Ta med några enkla fall (så att du kan upptäcka katastrofala regressioner), några medelsvåra (merparten av verklig trafik) och några svåra (extremfallen). Ett dataset med enbart svåra fall varierar kraftigt vid små ändringar; ett dataset med enbart enkla fall reagerar inte på verkliga regressioner.

Välj lämplig storlek. Om datasetet är för litet blir statistiken brusig. Om det är för stort blir körningarna långsamma och dyra. Typiska storlekar:

• Klassificering: 200–500 fall.
• Generering: 50–200 fall.
• Komplexa agentflöden: 20–50 fall.

Du kan alltid börja mindre och utöka.

Disciplin för uppdatering. Planera in en månatlig granskning av datasetet. Lägg till nya fellägen. Ta bort inaktuella fall. Uppdatera förväntade utdata om det önskade beteendet har ändrats.

Mätetalsproblemet

Det du mäter avgör vad du optimerar för. Dåliga mätetal är det näst vanligaste felet i utvärderingar.

Vanliga mätetalsfel

Fel 1: Sammanfattningar med ett enda tal döljer problem. En total träffsäkerhet på 90 % kan dölja att en viktig kategori har sjunkit från 95 % till 70 % samtidigt som andra har förbättrats. Genomsnittet ser bra ut.

Åtgärd: uppdelning per kategori. Alltid.

Fel 2: Mätetalet mäter fel sak. Ett mätetal för ”korrekthet” i kundtjänstsvar kan missa att svaret är korrekt men otrevligt. Mätetalet fångar inte tonen.

Åtgärd: flerdimensionell poängsättning. Bedöm korrekthet, ton, längd och format separat.

Fel 3: Okänslighet för allvarlighetsgrad. Ett felaktigt svar behandlas likadant oavsett om det är ett trivialt misstag eller en farlig hallucination.

Åtgärd: viktad poängsättning. Allvarliga fel räknas mer. Vissa fel ger 0 (säkerhetsöverträdelser), andra ger −1 (katastrofala fel, värre än inget svar alls).

Fel 4: Bimodal känslighet. Poängen går antingen från 100 % till 99 % (omärkbart) eller från 100 % till 50 % (katastrofalt). Subtila regressioner syns inte.

Åtgärd: graderad poängsättning. Varje utdata bedöms på en kontinuerlig skala (1–5 eller 0–1), inte binärt.

Fel 5: Aggregering över populationer. Genomsnittet för alla användare döljer att prestandan för en undergrupp på 10 % har rasat.

Åtgärd: dimensionell uppdelning efter relevanta segment (användarnivå, frågetyp och språkversion).

Bygg starka mätetal

Flerdimensionella. Varje utdata får flera poäng. Korrekthet. Ton. Format. Säkerhet. Längd. Allt som är viktigt.

Viktade. Vissa dimensioner är viktigare än andra. Vikta dem i eventuella sammansatta mätetal.

Kalibrerade allvarlighetsgrader. Skilj mellan mindre och större fel inom en dimension. Ett svar med sakfel är värre än ett svar med en mindre avvikelse.

Mätetal per kategori. Redovisa poäng uppdelade efter relevanta segment. Lätt/medelsvårt/svårt. Per ämne. Per användartyp.

Trend över tid. En enskild poäng är inte användbar, men en trend är det. Rita upp poängen över tid. Upptäck drift.

Användaranpassade. Mätetalen ska korrelera med det användarna faktiskt bryr sig om. Om användarna klagar på otrevlig ton mäter du otrevlig ton. Om de klagar på längden mäter du längden.

Bedömarproblemet

När en LLM används som bedömare (en LLM poängsätter en annan LLM:s utdata) är bedömaren din poängsättare. Om bedömaren är partisk eller har fel är utvärderingarna oanvändbara.

Vanliga bedömarfel

Fel 1: Längdpartiskhet. LLM-baserade bedömare tenderar att föredra längre svar. De ger ett längre svar högre poäng även när det är svulstigt.

Fel 2: Formatpartiskhet. Bedömare föredrar strukturerade utdata (punktlistor och rubriker) framför prosa, oavsett vad som passar uppgiften bäst.

Fel 3: Preferens för den egna modellen. När bedömarmodellen tillhör samma modellfamilj som modellen som bedöms ger den den egna familjens utdata högre poäng.

Fel 4: Inställsamhet. Bedömare håller med om den inramning de får. Om du säger till bedömaren att ”den förra versionen var dålig, poängsätt den nya” blir poängen för den nya versionen överdrivet höga.

Fel 5: Brist på förankring. Bedömare poängsätter efter intryck i stället för specifika kriterier. Samma prompt ger olika poäng vid olika körningar.

Bygg starka bedömare

Kalibrera mot människor. Ta ett urval av bedömarens poäng och låt en människa göra en ny bedömning. När de inte är överens förbättrar du bedömarprompten eller accepterar att människor behövs för den dimensionen.

Använd olika bedömningsmodeller. Använd om möjligt en bedömare från en annan modellfamilj än systemet som utvärderas. Det minskar preferensen för den egna modellen.

Var tydlig med kriterierna. Bedömarprompten ska exakt ange hur bra och dåligt ser ut, med exempel. Vaga kriterier ger vag poängsättning.

Undvik ledande inramningar. Säg inte till bedömaren att ”poängsätta på en skala där de flesta utdata är bra”. Förankra bedömningen i specifika beteenden.

Förankrade bedömningsmatriser. Poängsätt enligt en definierad matris med exempel för varje nivå. ”Poäng 5: korrekt i sak, specifikt, välstrukturerat. Poäng 4: i huvudsak korrekt, kan sakna en detalj. Poäng 3: …” Med hållpunkter är bedömaren konsekvent. Utan dem driver den.

Tvinga fram strukturerade utdata. Bedömaren producerar strukturerade poäng (per dimension, med motivering), inte fritext. Det är enklare att aggregera och granska.

En stark bedömarprompt ser ut så här:

Du utvärderar en AI-assistents svar.

Användarfråga: {query}
Assistentens svar: {response}

Poängsätt följande dimensioner på en skala från 1 till 5:

1. Faktamässig korrekthet: Är alla påståenden korrekta? (5 = alla är korrekta, 4 = i huvudsak korrekt med mindre problem, 3 = en del är felaktigt, 2 = mycket är felaktigt, 1 = det mesta är fel)

2. Relevans: Besvarar svaret användarens faktiska fråga? (5 = besvarar frågan perfekt, 1 = besvarar den inte)

3. Fullständighet: Innehåller svaret tillräcklig information? (5 = fullständigt, 1 = mycket ofullständigt)

4. Ton: Är svaret professionellt på ett lämpligt sätt? (5 = perfekt ton, 1 = olämpligt)

Ange följande för varje poäng:
- Poängen
- En specifik motivering i en mening
- Den specifika text i svaret som stöder poängen

Utdata som JSON: {"accuracy": {"score": N, "reason": "...", "evidence": "..."}, ...}

Kör bedömaren mot en kalibreringsuppsättning (exempel som människor har poängsatt). Justera tills bedömaren är överens med människorna inom en godtagbar marginal.

Utforma utvärderingssviter för produktion

Några mönster som fungerar i produktion:

Svit 1: Regressionssviten

En definierad uppsättning testfall (200–500) som systemet måste klara före varje driftsättning. Den har sammanställts från verkliga fel, extremfall och verifierat bra mönster. Den ändras inte ofta.

Det här är din svit för sådant som ”inte får gå sönder”. CI-integrering: den körs för varje PR. Blockera sammanslagning vid regression.

Svit 2: Röktestet

En liten delmängd (10–30 fall) som körs ofta. Den ger snabb återkoppling under utvecklingen och upptäcker omedelbart katastrofala regressioner.

Integrering: pre-commit-hook eller ett snabbt röktest före den huvudsakliga utvärderingen.

Svit 3: Upptäcktssviten

Ett större och mer varierat dataset (tusentals fall) från ett urval av verklig produktionstrafik. Körs mer sällan (varje vecka?). Letar efter mönster som de mindre sviterna kan missa.

Integrering: schemalagt jobb. Resultaten granskas under veckovisa kvalitetsmöten.

Svit 4: Onlinesviten

Ett urval av verklig produktionstrafik som poängsätts automatiskt (av en LLM-baserad bedömare) eller via användarsignaler. Upptäcker drift som offlineutvärderingar missar.

Integrering: kontinuerligt, via en instrumentpanel.

Svit 5: Användarflödessviten

Heltäckande tester som kör fullständiga användarflöden, inte bara enskilda LLM-anrop. För agentsystem och flerstegsflöden.

Integrering: före driftsättning av större ändringar.

Ett moget produktionssystem har alla fem. Börja med regressionssviten och lägg till de andra när kapaciteten växer.

Disciplin kring kostnad och tid

Utvärderingar kostar pengar (LLM-anrop) och tid (för att köra och granska dem).

En utvärdering med 500 fall och en ledande bedömningsmodell kan kosta 5–20 euro per körning. Kör den för varje PR (10 per dag) och du hamnar på 50–200 euro per dag. Hanterbart, men ändå en verklig kostnad.

Strategier:

Kör röktester i PR:er och fullständiga sviter vid sammanslagning. Det sparar kostnader för PR:er som inte kommer att slås samman.

Cachelagra resultat. Om varken prompten eller modellen har ändrats behöver du inte köra igen. Cachelagra efter (prompt_version, model, dataset_version).

Använd billigare bedömare där det går. En billigare bedömningsmodell med god kalibrering är ofta tillräcklig.

Parallellisera. Utvärderingskörningar lämpar sig utmärkt för parallellisering. Använd samtidighet.

Gör ett urval i stället för en fullständig körning. Vid rutinmässiga kontroller kan du välja 50 fall från ett dataset med 500 fall. Kör allt vid viktiga ändringar.

Tidsbudgeten handlar oftast om ”hur länge kan en PR vänta?”. Sikta på att köra en fullständig utvärdering på under 15 minuter. Tar det längre tid byter utvecklarna sammanhang och tappar produktivitet.

Operativa mönster

Några arbetssätt som utmärker mogna utvärderingsprogram:

Mönster 1: Utvärderingsstyrda driftsättningar

Driftsättning i produktion av ändringar som påverkar en LLM styrs av utvärderingsresultaten. Har poängen sjunkit under tröskelvärdet? Driftsättningen blockeras. En ingenjör undersöker.

Tröskelvärdet är vanligtvis relativt: ”poängen måste ligga inom 2 % från baslinjen”. Det tillåter brus men upptäcker väsentliga regressioner.

Mönster 2: Undersök när poängen rör sig

Alla betydande poängförändringar (uppåt eller nedåt) ska undersökas. Gick poängen upp? Varför? Har vi förbättrat något eller har testet blivit enklare? Gick poängen ned? Var exakt? Är regressionen begränsad till ett segment?

Fira inte och få inte panik på grund av aggregerade rörelser – undersök dem.

Mönster 3: Kontinuerlig kurering av dataset

Datasetet är inte ett engångsbygge. Det kureras kontinuerligt. Process:

• En användare klagar på ett svar → lägg till det i datasetet som regressionstest.
• En ny funktion lanseras → lägg till fall som täcker den.
• Ett modellbeteende överraskar någon → om det är ett verkligt fel, lägg till det.
• Inaktuella fall (inte längre relevanta) → ta bort dem.

Ett månatligt granskningsmöte fungerar bra. Datasetet behandlas som en levande tillgång.

Mönster 4: Differensbaserad granskning

När du granskar ett utvärderingsresultat fokuserar du på skillnaderna mot baslinjen:

• Fall där den nya versionen fick högre poäng än baslinjen (förbättringar).
• Fall där den nya versionen fick lägre poäng (regressioner).
• Fall där poängen förblev densamma (ingen signal).

Skillnaden är signalen. Det är opraktiskt att granska 500 fall i följd; det går att granska 30 skillnader.

Mönster 5: Mänsklig granskning av oenighet med bedömaren

Gör regelbundet (varje vecka?) ett urval av fall där bedömaren gav låg respektive hög poäng. Den mänskliga granskningen ställer frågan: håller du med bedömaren?

Oenighet blottlägger:

• Partiskhet hos bedömaren (kalibrera bedömarprompten).
• Verkliga kvalitetsproblem (åtgärda systemet).
• Datasetproblem (fallets förväntade utdata är fel).

Det är så du upprätthåller bedömarkvaliteten över tid.

Mönster 6: Kvartalsvis granskning av utvärderingen

Gör en kvartalsvis tillbakablick på själva utvärderingsprogrammet:

• Vilka verkliga regressioner upptäckte utvärderingssviten under kvartalet?
• Vilka verkliga regressioner missade den?
• Vilka falsklarm gav den?
• Vilka kända luckor finns i täckningen?
• Hur väl täcker datasetet de aktuella produktionsbeteendena?

Det här är en metautvärdering: att utvärdera utvärderingen. Utan den försämras utvärderingsprogrammet.

Ett genomarbetat exempel: utvärdering av kundtjänst

För att göra det konkret följer här en utvärderingsuppsättning av produktionsklass för ett AI-system som genererar kundtjänstsvar.

Mål: säkerställa att AI:ns svar på kundfrågor är korrekta, hjälpsamma, varumärkesanpassade och säkra.

Dataset:

1. Regressionssvit (300 fall):

   • 50 enkla fall (tydliga policyer, enkla svar).
   • 100 medelsvåra fall (typisk komplexitet).
   • 100 svåra fall (tvetydiga, känsliga, flerdelade).
   • 50 kända felfall (scenarier som tidigare har regredierat).

2. Upptäcktssvit (1 000 fall): Ett månatligt urval från verklig produktionstrafik, rensat från personuppgifter.

3. Angreppssvit (50 fall): Särskilt utformade prompter som försöker extrahera information, få återbetalning i fall som inte berättigar till det eller manipulera AI:n.

Mätetal:

För varje fall poängsätter bedömaren:

• Faktamässig korrekthet (1–5)
• Policyefterlevnad (1–5)
• Lämplig ton (1–5)
• Fullständighet (1–5)
• Lämplig längd (1–5)
• Säkerhet (binärt: godkänd/underkänd)

Bedömare:

• Primär bedömare: Claude (en annan leverantör än systemet som testas, vilket använder GPT – genom att välja en annan leverantör undviker man partiskhet till förmån för den egna modellen).
• Kalibrerad mot en mänsklig granskare med 100 referensfall.
• Omkalibreras kvartalsvis.

Aggregering:

• Genomsnittlig poäng per dimension och segment (segment: ärendetyp, kundnivå, språk).
• Godkännandegrad för säkerhet (måste vara 100 %).
• Viktad poäng per fall (används för differenser).

Drift:

• Röktest (30 fall) för varje PR.
• Fullständig regressionssvit (300 fall) vid sammanslagning av en PR.
• Upptäcktssvit (1 000 fall) varje vecka.
• Angreppssvit (50 fall) före varje prompt- eller modelländring.
• Onlineurval av 1 % av produktionstrafiken, bedömt i realtid.

Granskning:

• Månatligt möte: granska utvärderingstrender, nya fellägen och datasetuppdateringar.
• Kvartalsmöte: metautvärdering, bedömarkalibrering och datasetgranskning.

Resultat (från verkliga driftsättningar av liknande system):

• Cirka 3 upptäckta regressioner per månad som annars skulle ha driftsatts.
• Cirka 1 falsklarm per månad (utvärderingen flaggar en regression som i själva verket är acceptabel).
• Drift upptäcks inom dagar i stället för veckor eller månader.
• Ökad trygghet vid leverans av prompt- och modelländringar.

Så här ser utvärderingar av produktionsklass ut. Inte ett snabbt helgprojekt, utan en fortlöpande investering med verklig avkastning.

Vanliga fallgropar

Några mönster vi ser om och om igen:

Fallgrop 1: Utvärderingarna byggs efter produktlanseringen. ”Vi lägger till utvärderingar senare.” Senare kommer aldrig. Bygg dem från första dagen.

Fallgrop 2: En enda ingenjör äger allt. En person bygger utvärderingen och ingen annan underhåller den. När personen slutar förfaller utvärderingen. Fördela ägarskapet.

Fallgrop 3: Utvärderingarna behandlas som statiska. De byggs en gång och uppdateras aldrig. De blir oanvändbara när produkten utvecklas. Behandla utvärderingen som en levande tillgång.

Fallgrop 4: Blind tillit till utvärderingspoäng. Utvärderingen säger att det är bättre, så vi levererar. Utan mänskliga stickprovskontroller levererar du sådant som utvärderingen gav höga poäng men som användarna avskyr. Kombinera utvärderingar med mänsklig granskning vid viktiga ändringar.

Fallgrop 5: Optimering mot utvärderingen. Prompter finjusteras specifikt för att få bra resultat i utvärderingen. Utvärderingen förbättras, verkligheten gör det inte. Se upp med det – om förbättringar i utvärderingen inte motsvaras av förbättringar i produktion optimerar du mot testet.

Fallgrop 6: Infrastrukturkostnaden ignoreras. Utvärderingar i stor skala är dyra (LLM-anropen blir många). Utan kostnadsuppföljning upptäcker du det först i slutet av månaden.

Fallgrop 7: Inga tydliga kriterier för godkänt/underkänt. ”Poängen gick från 4,2 till 4,0 – är det en regression?” Definiera tröskelvärden i förväg. Håll fast vid dem.

Fallgrop 8: Utvärderingssviten slukar all testenergi. Omfattande utvärderingar byggs samtidigt som grundläggande korrekthetstester saknas. Utvärderingar är till för kvalitetsdrift; all testning är inte utvärdering.

Den kulturella delen

Den svåraste delen av produktionsutvärderingar är kulturell. Ingenjörer och produktmedarbetare måste:

• Lita tillräckligt mycket på utvärderingarna för att låta dem styra driftsättningar. Annars är utvärderingarna teater.
• Misstro utvärderingarna tillräckligt mycket för att undersöka förändringar. Blind tillit leder till optimering mot testet.
• Investera i datasetkurering som ett fortlöpande arbete. Inte som ett engångsprojekt.
• Acceptera att utvärderingar inte ersätter mänskliga bedömningar. De minskar den yta som människor behöver granska.
• Känna igen när en utvärderingssvit inte fungerar. När verkliga regressioner slinker igenom ligger problemet i utvärderingssviten, inte hos användaren som klagar.

Team med den här kulturen levererar snabbare och mer tillförlitligt. Team utan den hamnar så småningom antingen i ett överdrivet beroende av trasiga utvärderingar eller i handlingsförlamning för att utvärderingar saknas.

Slutsatsen

Att bygga utvärderingar som faktiskt upptäcker regressioner är svårare än det verkar, men fullt genomförbart.

Nycklarna:

• Verkliga, varierade dataset hämtade från produktionsverkligheten.
• Flerdimensionella och segmentmedvetna mätetal som stämmer överens med användarupplevelsen.
• Kalibrerade bedömare som du faktiskt har kontrollerat mot mänskliga bedömningar.
• Flera utvärderingssviter för olika behov (regression, rök, upptäckt, online och heltäckande).
• Operativ disciplin: utvärderingsstyrda driftsättningar, kontinuerlig datasetkurering och undersökning av förändringar.
• Ett kulturellt åtagande att använda och förbättra utvärderingarna över tid.

När det görs väl blir utvärderingar den mest värdefulla infrastrukturen i din AI-stack. Det är så du levererar snabbt och samtidigt upprätthåller kvaliteten. Utan dem flyger du i blindo.

Bygg utvärderingarna. Lita på utvärderingarna. Förbättra utvärderingarna. Det är så kvaliteten i produktions-AI upprätthålls.