Grunnmodeller har blitt bedre, men det som virkelig muliggjør trygg produksjonssetting, er systematisk evaluering
Godt utformede evalueringer hjelper produktledere, ansvarlige for KI-styring og teknologidirektører med å ta i bruk KI-agenter trygt og i stor skala, slik at KI går fra å være et isolert leketøy til et konkurransefortrinn.
Denne tryggheten kommer av å evaluere KI-agenters atferd mot reelle brukerforespørsler, grensetilfeller og domenespesifikke scenarioer som gjenspeiler den faktiske virksomheten – ikke av en offentlig referansetest som hevder at «denne modellen er best»
Målet er å underbygge denne tryggheten med målbare resultater. Suksess innebærer å definere "godt" konkret og målbart, i tråd med virksomhetens behov og risikotoleranse – enten det gjelder faktanøyaktighet, passende tone, hastighet eller kostnadseffektivitet.
Ved å integrere evaluering i hele systemet (instrumentering, logging, A/B-testing og sikkerhetsmekanismer) og balansere grundighet mot effektivitet kan team levere raskere og mer robuste løsninger.
De fleste virksomheter er komfortable med at de ansatte utforsker ChatGPT eller Gemini. Det er derimot mindre vanlig å ta i bruk LLM-er i kritiske arbeidsflyter eller miljøer.
Det har ofte vært gode grunner til dette: Kvaliteten har variert, og risikoen for hallusinasjoner eller uønsket atferd har veid tyngre enn teknologiens potensielle gevinster.
Balansen mellom risiko og gevinst har endret seg betydelig det siste året. Noe skyldes bedre ytelse i grunnmodellene, men mye handler om en mer systematisk tilnærming til evaluering. Evalueringer gir oss og kundene våre tryggheten til å produksjonssette store, kundevendte agenter på få uker.
Denne veiledningen forklarer grunnelementene i evalueringer og hvordan de utformes, implementeres og driftes for produksjonsbruk.
Målet med evaluering er ikke å finne en perfekt modell, men å skape velbegrunnet trygghet for at modellen oppfører seg i tråd med virksomhetens behov, brukernes forventninger og organisasjonens risikotoleranse.
Enhver evalueringsstrategi bygger på ett enkelt spørsmål: Hvordan ser «godt» ut? Svaret bør være konkret. For én organisasjon kan «godt» bety faktanøyaktighet innenfor strenge toleranser. En annen kan prioritere hastighet, kostnadseffektivitet eller en særegen tone. Alle rammebetingelser – fra hvilke data som kan brukes, til hvilke myndighetskrav som gjelder – påvirker denne definisjonen.
Det avgjørende er at 'godt' består av elementer som faktisk kan måles. Hvis suksess betyr å gi nyttig økonomisk veiledning, må nytte uttrykkes gjennom egenskaper som faktanøyaktighet, passende forbehold, tilpasset resonnering og trygge grenser. Når «godt» er definert målbart, er neste spørsmål hvordan resultatene skal analyseres og tolkes. Det er oppfølgingen av resultatene som gjør evaluering til en metode, fremfor bare en rekke skjønnsmessige vurderinger.
Enhver evalueringsprosess bygger på tre sammenkoblede søyler:
Inndata/referansetester: Representative eksempler fra virkeligheten for generell ytelse og kuraterte interne datasett for å teste egnethet i domenet.
Modellatferd: Hvordan modellen kalles (hentingsforsterket generering, oppsummering, strukturert informasjonsinnhenting og verktøybruk).
Måleverdier: Hvordan ytelsen måles og tolkes.
Inndataene må representere den virkeligheten systemet vil møte. Den mest verdifulle innsikten kommer fra reelle eksempler: kundeforespørsler, økonomiske scenarioer eller bransjespesifikke tilfeller. Bare ved å teste mot disse kan du forstå om modellen virkelig oppfatter nyansene brukerne trenger, og oppfyller virksomhetens behov.
Modellens atferd – blant annet hvordan den promptes, hvordan innhenting og verktøybruk orkestreres, og hvordan kontekst tilføres – er like viktig som selve modellen. To identiske modeller kan oppføre seg svært forskjellig avhengig av hvordan de tas i bruk. Dette laget må derfor inngå i evalueringsdesignet.
Til slutt har vi måleverdiene. Tall alene forteller sjelden hele historien, men gode måleverdier gjør systematferden forståelig. Svartid, nøyaktighet, sikkerhet, sammenheng, skjevhet, kostnader og brukertilfredshet gir samlet et flerdimensjonalt bilde av et system i produksjon. Kunsten er å velge måleverdier som samsvarer med prosjektets eller virksomhetens KPI-er og belyser egenskapene som betyr mest for brukerne. Enklere måleverdier er ofte mer presise og rimeligere, mens dårlige valg kan villede teamene. Slik kan du tenke når du velger måleverdier:
Eksempler på gode måleverdier:
Kundeservice-chatbot: løsningsgrad ved første kontakt (ble brukerens problem løst uten eskalering?), gjennomsnittlig behandlingstid, brukertilfredshet og andel eskaleringer til menneskelige agenter
Verktøy for finansanalyse: kildehenvisningenes nøyaktighet (andel påstander med korrekt kilde), faktanøyaktighet kontrollert mot fasit, relevans ved innhenting (fant verktøyet de rette dokumentene?) og sammenheng i resonneringen vurdert av fageksperter
Assistent for kodegenerering: korrekt syntaks, andel beståtte tester, antall sikkerhetssårbarheter og tid til en fungerende løsning
Eksempler på dårlige måleverdier:
Å bruke bare svarlengde som mål på kvalitet (lengre ≠ bedre)
Å måle hastighet uten å ta hensyn til avveiningen mot nøyaktighet
Å følge modellens konfidenspoeng uten å kontrollere dem mot faktisk korrekthet
Å basere seg utelukkende på modellens interne perpleksitet uten brukervendt validering
Vanlige fallgruver som bør unngås:
Motstridende måleverdier: å optimalisere for både hastighet og grundighet uten å erkjenne avveiningen
Overtilpasning til referansetester: å oppnå 95 % på testsettet, men mislykkes i produksjon fordi virkelige brukere oppfører seg annerledes
For en kunde innen strengt regulerte finansielle tjenester var nøyaktighet avgjørende i løsningen for dyp forskning. Vi utarbeidet både kvalitetssikringsdatasett laget av eksperter og verktøygenererte datasett. Dermed kunne vi vurdere presisjonen og hvor godt systemet valgte riktige verktøy og hentet riktig informasjon, noe som ga et balansert bilde av nøyaktigheten og kvaliteten på resonneringen. Nøkkelen var å måle flere dimensjoner: faktanøyaktighet (ekspertvalidering), innhentingskvalitet (presisjon/gjenfinning av relevante dokumenter) og sammenheng i resonneringen (strukturert vurdering av den logiske flyten).
Når LLM-som-dommer bør brukes til å vurdere nyansert kvalitet
LLM-som-dommer bruker en annen KI-modell som evaluator og erstatter menneskelig gjennomgang med skalerbar, automatisert kvalitetsvurdering. LLM-som-dommer misbrukes ofte når enklere måleverdier kan gi den nødvendige nøyaktigheten. Metoden kan være nyttig når deterministiske kontroller ikke kan fange opp kvaliteten, for eksempel når måleverdien er semantisk (nytte, kildeforankring, kvalitet på resonnering, tone eller tolkning av retningslinjer) og deterministisk poengsetting ikke er mulig. Du kan ha behov for skalerbar tilbakemelding på tvers av mange prompt-/modellvarianter og for å definere tydelige vurderingskriterier og et skjema for strukturerte utdata. Følg disse trinnene for å få metoden til å fungere:
Definer vurderingsdimensjonene tydelig: korrekthet, kildeforankring, etterlevelse av retningslinjer, handlingsrelevans og tone.
Bruk strukturerte utdata (JSON-skjema) for dommerens svar.
Registrer både binære terskelverdier og diagnostisk tekst for feilanalyse.
Kalibrer dommerens utdata mot menneskemerkede eksempler i hver lanseringssyklus.
Bruk to dommere eller regelmessige konsensuskontroller på kritiske områder.
Følg utviklingen i dommerens avvik og graden av uenighet over tid.
Et datasett for referansetesting er et fast, kuratert sett med testeksempler og kjente svar som brukes til å evaluere modeller konsekvent og sammenligne resultater rettferdig mellom versjoner. Det inneholder vanligvis inndata (for eksempel brukerforespørsler), forventede utdata eller referansevurderinger og evalueringskriterier eller etiketter for poengsetting. Offentlige referansetester brukes til å sammenligne ytelsen til de fremste modellene. De kan være et nyttig utgangspunkt når du skal finne ut hvilken modell som kan egne seg i systemet.
For ditt eget system kan du imidlertid ikke bruke disse referansetestene som et mål på ytelsen i virksomhetens kontekst, fordi testene har kjente svakheter:
Kontaminering: Modeller kan være trent på data fra referansetesten. Å evaluere dem på samme datasett kan sammenlignes med å rette en prøve der kandidaten hadde fasiten.
Metning: Alle toppmodellene oppnår allerede nær maksimal poengsum. Forbedringer eller svekkelser begrenses dermed til noen få prosentpoeng og ligger ofte innenfor testresultatenes naturlige variasjon.
Begrenset omfang: Dataene i referansetesten gjenspeiler ikke de faktiske oppgavene dine, fordi de er sterkt kuratert og renset. Noen er til og med generert av LLM-er og gjenspeiler derfor ikke kompleksiteten og grensetilfellene i dataene dine, som skrivefeil, uvanlige formuleringer og bilder med støy.
En elev ber applikasjonen om hjelp til å løse tekstoppgaver.
Et eksempel på en offentlig referansetest du kan bruke: GSM8K (matematisk resonnering på grunnskolenivå)
Et valgfritt og vanskeligere sett: MATH.
Derfor er denne referansetesten nyttig:
Sammenlign raskt hvilken modell som er best på generell matematisk resonnering,
Et godt første filter før du investerer i fullstendige produktevalueringer.
Derfor trenger du likevel ditt eget datasett:
Applikasjonen din har krav som GSM8K ikke tester:
Ordlyden og rekkefølgen på emnene i læreplanen din,
Forklaringsstilen for aldersgruppen din,
Hvordan tvetydige elevspørsmål eller spørsmål med mange skrivefeil skal håndteres,
Regler og retningslinjer (for eksempel når eleven skal få hint fremfor fullstendige svar).
Effektiv validering avhenger av at du utvikler applikasjonsspesifikke referansetester. Disse datasettene bør bygge på reelle interaksjoner, typiske grensetilfeller og sannsynlige feilscenarioer. Dette kan være krevende ved implementering av et nytt produkt eller en ny prosess. I de fleste tilfeller er det likevel mulig å samle inn data fra et eksisterende produkt eller så tidlig som mulig, også i den første testfasen. Etter at applikasjonen er utviklet, bør referansetestene videreutvikles sammen med produktet og gradvis bli rikere og mer representative.
Eksempelstudie: Utvikling av en skreddersydd referansetest for en bankassistent
En bank-chatbot svarer på spørsmål om budsjetter, forbruk og transaksjoner. Offentlige QA-referansetester og tekst-til-SQL fanget ikke opp sentrale bankrisikoer som SQL-injeksjon, datalekkasje eller videreføring av kontekst mellom flere samtaletrinn. Vi utviklet en skreddersydd referansetest som gjenspeiler produktets agentprosess.
Komponenter i den skreddersydde referansetesten i denne kodebasen:
Red-team-testsett med ondsinnede prompter for SQL-injeksjon, uthenting av personopplysninger, overstyring av prompter og lekkasje mellom økter
Nulltoleranse for sikkerhetsbrudd: Alle forsøk på SQL-injeksjon, uthenting av personopplysninger eller lekkasje mellom økter må avvises.
Nøyaktig videreføring av kontekst: Omskrevne forespørsler må bevare brukerens hensikt og entiteter.
Hovedpoeng: Behandle utviklingen av referansetesten som en produktfunksjon. Det nåværende rammeverket viser at ende-til-ende-evaluering er koblet opp, men dekningen og utvalgsstørrelsene må økes for å gjenspeile reelle bankrisikoer (angrep med flere hensikter, omgåelse av sikkerhetsmekanismer og kontekstavhengige forespørsler). Referansetesten bør utvides i takt med nye agenter og sikkerhetsmekanismer.
Forbindelsen mellom den applikasjonsspesifikke referansetesten og modellvalget er avgjørende. Referansetesten viser ikke bare om en løsning fungerer, men også hvilken kombinasjon av modellstørrelse og ettertreningsteknikker som gir ønsket ytelse mest kostnadseffektivt. De største forbedringene av forhåndstrente modeller («PT» i ChatGPT) kommer ikke fra ny trening, men fra metoder for "ettertrening".
Disse metodene handler om å forme hvilken informasjon modellen har tilgang til, hvordan informasjonen struktureres, og hvordan modellen veiledes og orkestreres under inferens. Teknikker for ettertrening omfatter:
Prompting med tankerekke og dynamisk tildeling av regnekraft (tenk mer på vanskeligere problemer)
Selvkonsistens, der flere utdata genereres og det beste velges
Kontekstbygging og orkestrering, som Retrieval-Augmented Generation (RAG), eksempler med få eksempler og agentbaserte arbeidsflyter
Verktøybruk og tilgang til ekstern kunnskap, slik at modellen kan handle utover sine interne parametere
Strategier for kunnskapsrepresentasjon og -lagring, utformet for effektiv innhenting og resonnering over strukturerte og ustrukturerte data
Selv om disse ettertreningsteknikkene kan forbedre systemets ytelse betydelig, medfører de også avveininger. Hvert ekstra lag med orkestrering, innhenting eller resonnering øker systemets kompleksitet, inferenstid og driftskostnader. Med gjennomtenkt bruk gjør den rette kombinasjonen av ettertreningsteknikker det ofte mulig å benytte mindre, raskere og rimeligere modeller og samtidig oppfylle ytelseskravene. I stedet for å øke modellstørrelsen oppnås ytelsen gjennom bedre systemdesign.
Den rette balansen er spesifikk for hver applikasjon og bør bestemmes med applikasjonsspesifikke evalueringer som finner den optimale kombinasjonen av teknikker. De gjør det mulig å finne punktet der mer orkestrering ikke lenger gir vesentlige gevinster, slik at teamene kan velge det laveste nivået av ettertreningskompleksitet som kreves for ønsket ytelse.
En KI-løsning må ses som et komplett system: databaser, API-er, brukergrensesnitt, orkestreringslag, overvåkingsinfrastruktur med mer. Evalueringen må derfor omfatte hele teknologistakken. Du bør overvåke sentrale deler av systemet for å oppdage mulige problemer og øke tempoet på en ansvarlig måte.
Overvåking av sentrale deler av systemet innebærer:
Å instrumentere prosessene for å få målbare resultater.
Å logge eksperimenter slik at effekten av hver justering blir synlig.
Å bruke enkle A/B-sammenligninger før større endringer produksjonssettes, for å avdekke mulige regresjoner.
Datadrevet iterasjon forkorter veien fra prototype til produksjon uten blindsoner. Logging og overvåking er også viktig for å forstå hvordan applikasjonen faktisk brukes. Her er et eksempel på hvordan observerbarhet kan sikres:
Trinn 1: Brukerforespørselen kommer inn med request_id, user_segment og intent.
Trinn 2: Sporingen logger modellversjon, promptversjon, innhentede dokumenter og verktøykall.
Trinn 3: En LLM-dommer vurderer svaret (korrekthet, kildeforankring og policy_risk).
Trinn 4: Regelmotoren vurderer terskelverdiene.
Trinn 5: Hvis en terskel brytes, utløses et varsel, og saken sendes til reserveløsningen eller menneskelig gjennomgang.
Trinn 6: Feilen legges til i køen for prioritering og deretter i etterslepet for referansetesten.
Virkelige brukere oppfører seg sjelden akkurat slik designerne forventer. Noen vil misforstå instruksjonene. Andre vil bevisst lete etter svakheter. Disse grensetilfellene er ikke avvik, men uvurderlige signaler. En godt implementert evalueringsprosess fanger dem opp, analyserer dem og tar dem med i fremtidige tester. Rask iterasjon uten blindsoner er bare mulig når evalueringen er bygd inn i systemet, ikke lagt til etter at utviklingen er ferdig.
Vi anbefaler å bygge inn sikkerhetsmekanismer og overvåking fra første dag:
Følg regelmessig modellens måleverdier og regresjoner ved hjelp av den applikasjonsspesifikke referansetesten.
Registrer og gjennomgå grensetilfeller eller manipulerende inndata, og legg dem til i datasettet for den applikasjonsspesifikke referansetesten.
Sørg for at måleverdiene i evalueringen samsvarer med de viktigste KPI-ene.
Utfordre datasettet og referansetesten regelmessig for å sikre at nye risikoer ikke overses, og at resultatene ikke påvirkes av skjevheter.
Implementer automatiske varsler ved svekkede måleverdier (utløs for eksempel en gjennomgang hvis nøyaktigheten faller under 85 %).
Oppretthold en prosess for menneskelig gjennomgang av kritiske beslutninger (juridisk rådgivning, medisinsk veiledning og finansielle transaksjoner).
Hver kjøring av en referansetest bruker regnekraft og energi. Hvert overflødig eksperiment øker kostnadene. Ansvarlig evaluering bør balansere grundighet mot effektivitet.
Noen praktiske tiltak kan hindre at energi- og kostnadsbruken løper løpsk:
Bruk mindre modeller når det er mulig. Kjør de første eksperimentene på rimeligere modeller, og skaler opp først når tilnærmingen er validert.
Mellomlagre prompter og API-kall.
Bruk energibevisst planlegging (satsvis behandling, spotforekomster og fleksibel prioritet).
Følg bruken av regnekraft sammen med ytelsen.
Følg samtidig nøye med på nye KI-reguleringer. Selv uten en egen lov gjelder fortsatt eksisterende regelverk og nødvendige tiltak, blant annet:
Personvern:
Sørg for at datasett til referansetester ikke inneholder personopplysninger uten gyldig samtykke
Innfør retningslinjer for oppbevaring av loggførte forespørsler
Tilby mekanismer for å be om sletting av data
Likestilling og skjevhet:
Test ytelsen på tvers av demografiske grupper
Sørg for bred representasjon når referansetesten utarbeides
Menneskerettigheter og åpenhet:
Dokumenter modellens begrensninger tydelig for brukerne
Gi forklaringer på kritiske beslutninger
Muliggjør menneskelig kontroll av kritiske applikasjoner
Evaluering er ikke en engangshendelse, men et system i stadig utvikling. I et felt i rask utvikling ligger konkurransefortrinnet i hvor raskt du kan teste, lære og tilpasse deg, slik at modeller og nye løsninger kan tas i bruk mer effektivt.
Ved å gjøre evaluering til en sentral del av utviklings- og produktarbeidet kan team innovere raskere og tryggere. Begynn med å definere hva som er godt i konteksten til KI-applikasjonen, etabler en evalueringsplattform og videreutvikle den til en applikasjonsspesifikk referansetest som for hver iterasjon gir trygghet for at løsningen er produksjonsklar.