11 metrikker til evaluering af LLM-agenter

LLM’er er ikke længere blot kloge papegøjer, der spytter sætninger ud på kommando. Med de nye LLM-agenter har vi fået digitale beslutningstagere, der selvstændigt kan kalde API’er, navigere i ukendt terræn - og begå sig i komplekse miljøer, hvor hvert skridt former det næste

Det er en radikal udvidelse af sprogmodellens rolle, og den udfordrer alle de måder, vi traditionelt har målt “intelligens” på.

Forestil dig en kundesupport-agent, der ikke bare svarer på spørgsmål, men også selv booker en tekniker, genstarter en router via fjern-API - og spørger efter dit samtykke undervejs. Er opgaven løst? er pludselig vigtigere end, om hvert enkelt svar var grammatisk korrekt. Vores gamle metrikker for nøjagtighed og perplexitet falder til jorden, når agenten skal balancere målopfyldelse, sikkerhed og brugeroplevelse samtidigt.

Netop derfor sætter vi i denne artikel fokus på 11 nøje udvalgte metrikker, der kan give dig det fulde billede af en agents præstation - fra robusthed mod støj og uventede miljøændringer til hvor ofte den beder om menneskelig hjælp. Vi viser, hvordan du går fra abstrakte buzzwords til konkrete målbare KPI’er, der kan sættes ind i CI/CD-pipelines og realtidsovervågning.

Hvis du arbejder med fremtidens IT - eller bare vil undgå at din nye AI-kollega saboterer budgettet med unødvendige API-kald - så læs med her på IT Forum Danmark. Vi giver dig værktøjskassen, eksempler fra frontlinjen og de faldgruber, der kan gøre forskellen mellem en hjælpsom agent og en løbske chatbot.

Klar til at tage springet fra statiske benchmarks til dynamisk, outcome-fokuseret evaluering? Lad os dykke ned i ”11 metrikker til evaluering af LLM-agenter” - og sikre, at dine agenter ikke bare taler, men også leverer resultater.

11 metrikker til evaluering af LLM-agenter

Hvorfor LLM-agenter kræver nye evalueringsrammer

I de tidlige år af store sprogmodeller (LLM’er) var evaluering relativt ligetil: giv modellen et prompt, sammenlign dens svar med et facit, og udregn en nøjagtighedsprocent. Men når vi flytter os til agentiske systemer - hvor modellen tager beslutninger over mange trin, kalder eksterne værktøjer og reagerer på et dynamisk miljø - bryder det klassiske regime hurtigt sammen.

Fire måder agent-llm’er adskiller sig fra “bare” llm-chat

  1. Langhorizont-opgaver
    En agent skal måske planlægge, gennemføre og evaluere dusinvis af handlinger (f.eks. “find potentielle leverandører, analyser deres priser, og generér et forslag”). Korrektheden af et enkelt svar siger næsten intet om succes på tværs af hele forløbet.
  2. Værktøjs- og API-kald
    Beslutningen om hvornår og hvordan der skal kaldes kode, SQL, browsere eller andre mikro-services er en væsentlig del af performance. Evalueringen skal derfor omfatte eksterne kalds præcision, fejlrate og latency - noget traditionelle sprogbænkmærker ignorerer.
  3. Ikke-deterministisk adfærd
    Temperatur, sampling og miljøreplikering kan føre til divergerende kørsler. To agent-run kan give samme slutresultat med vidt forskellige mellemtrin - eller helt forskellige resultater. Varians og reproducerbarhed bliver egne metrikker.
  4. Interaktion med et miljø
    I et sandboxed CRM, et spil eller en RPA-workflow får handlingerne side-effekter: databaser ændres, e-mails sendes, scripts fejler. Målet er ikke blot det “korrekte” tekstoutput, men den verdenstilstand som agenten efterlader.

Fra statiske facit-tests til scenarie- og outcome-fokus

Klassisk LLM-evaluering Agent-evaluering
BLEU, ROUGE, MMLU, TruthfulQA Task-succes, plan-kvalitet, værktøjsbrug, recovery-rate
En enkelt prompt ⇒ ét svar Flere trin, beslutninger og side-effekter
Evalueres offline mod “gold standard” Kræver både offline simulation og online overvågning i drift

Det betyder, at vi i stedet for ét facit behøver scenarie-baserede evalueringer, hvor succeskriteriet er et outcome:

  • Fandt agenten de korrekte leverandører og forhandlede den bedste pris?
  • Sendte den e-mailen uden at lække persondata?
  • Kunne den håndtere et API-timeout uden at gå i stå?

Offline vs. Online evaluering - To sider af samme mønt

Offline (pre-deployment)
  • Brug simulerede miljøer eller replay-log data.
  • Muligt at køre hundreder af seeds og måle varians.
  • Ideelt til regressionstests før hver release.
Online (post-deployment)
  • Real-time A/B-tests mod tidligere agent-versioner.
  • Driftsmetrikker som latency, tokenforbrug og API-fejlrates.
  • Bruger-feedback, SUS/NPS og incident reviews.

Kun ved at kombinere kontrollerede offline-eksperimenter med kontinuerlig online-monitorering får vi et fuldt billede af agentens værdiskabelse - og af dens risici. Dermed baner vi vejen for de 11 metrikker, der dækker hele spektret fra hård task-succes til blød brugeroplevelse.

De 11 metrikker: Hvad du bør måle – og hvorfor

Før vi dykker ned i kode og dashboards, er det afgørende at forstå hvad vi overhovedet skal måle. Nedenfor finder du elleve metrikker, der tilsammen giver et 360°-blik på en agentisk LLM-løsning - fra rå opgavesucces til menneskelig tillid.

  1. Opgavesuccesrate

    Måler om agenten fuldfører sin primære opgave korrekt. Uden et klart succeskriterium risikerer alle andre metrikker at miste mening.

    Eksempler på målemetoder: binær/gradueret bedømmelse af slut-output, automatisk enhedstest for kode-generering, menneskelig scoring af scenarier.

  2. Mål- og delmålsdækning (plan-kvalitet)

    Evalu­erer hvorvidt agentens interne plan rammer både slutmål og nødvendige delmål - essentiel for langhorizont-opgaver.

    Eksempler: sammenlign plan-strukturer mod et “gold plan”, brug graf-alignering eller LLM-baseret rubric-scoring af delmål.

  3. Pålidelighed og reproducerbarhed

    Lav varians mellem gentagne kørsler → høj forudsigelighed. Kritisk i produktion, hvor nondeterminisme kan skræmme brugere.

    Eksempler: kør hver test 20×, beregn standard­afvigelse på succesrate, brug seed-kontrollerede gensimuleringer.

  4. Sikkerhed og policy-overholdelse

    Tjek for overtrædelse af interne/eksterne retningslinjer (f.eks. GDPR, skadefuldt indhold, jail-break).

    Eksempler: automatiseret policy-classifier, rød-team prompts, score “violation per 1 000 calls”, manuel audit.

  5. Faktualitet og kildeverificerbarhed

    Hvor sandt er output, og kan det verificeres? Vigtigt når agenten genererer rapporter, medicinske råd eller koder love.

    Eksempler: LLM-baseret fact-score (GPTJudge), overlap med ground-truth triples, procent af påstande med link til kilde.

  6. Robusthed mod støj og miljøændringer

    Agenter møder fejl 404, langsomme API’er og ustrukturerede pdf-filer. Robusthed måler om de stadig leverer.

    Eksempler: fault-injection tests, syntetisk støj i input, evaluerings-suite med “skiftende sand” (ablat-test af API-felter).

  7. Autonomi og interventionsrate

    Ideelt skal agenten arbejde selvstændigt - men ikke på bekostning af kvalitet. Denne metrik kvantificerer behovet for menneskelig hjælp.

    Eksempler: procent af sessioner hvor bruger trykker “hjælp”, antal manuelle justeringer pr. 100 opgaver.

  8. Værktøjs-/API-brugseffektivitet

    Hvor præcist og økonomisk kalder agenten eksterne værktøjer? Dårlig værktøjsbrug = latens og udgifter.

    Eksempler: succesrate for API-kald, gennemsnitlig responstid, ratio “unødvendige kald/total”, F1 på værktøjs-valg.

  9. Effektivitet og omkostning

    Tæller tokens, GPU-sekunder og kroner. En genial agent er værdiløs, hvis den kræver 30 kr. per forespørgsel.

    Eksempler: median latency, tokens pr. vellykket opgave, $-forbrug i realtid via billing-API, CO₂-ækvivalent.

  10. Fejltolerance og recovery

    Når noget går galt, kan agenten så rette kursen selv? Kritisk for autonom styring og kundeservicebots.

    Eksempler: tid til recovery efter injected error, procent af afbrudte workflows som genoptages, edit-distance fra “corrected” plan.

  11. Brugeroplevelse og tillid

    Selv de mest imponerende system-scores er meningsløse, hvis brugerne ikke føler sig trygge og produktive.

    Eksempler: SUS (System Usability Scale), CES (Customer Effort Score), NPS (Net Promoter Score), kvalitativ interviewanalyse.

Disse metrikker overlapper naturligt; den ultimative kunst er at orkestrere dem til et balanceret kompas, der både advarer om katastrofer og afslører hurtige gevinster.

Fra metrikker til praksis: Evalueringspipeline, værktøjer og governance

  1. Scenarie- og datasætkonstruktion
    Formål: Sikre realistiske og repræsentative opgaver.
    • Brug syntetiske prompts til kanttilfælde og kuraterede brugerlogs til “happy paths”.
    • Tag højde for værktøjsadgang (API-nøgler, databaser) og tidsbegrænsninger i hvert scenarie.
    • Versionér datasættet (fx via DVC eller Git-LFS) så regressioner kan spores.
  2. Automatiserede harnesses (offline-test)
    Formål: Hurtig feedback ved model- eller prompt-ændringer.
    • Implementér et pytest-lignende setup hvor hver testcase kalder agenten i “dry-run” mode og måler de 11 metrikker.
    • Udnyt rammer som OpenAI Evals, LangChain Benchmarks eller AutoEval.
    • Gem rå resultater (JSON) og metadatér med modelhash, prompt-version og dependency-digests.
  3. Sandboxede integrationstests
    Formål: Verificere at agenten kan kalde eksterne værktøjer sikkert.
    • Kør agenten i en docker-container uden internet og giv kun mock-services.
    • Fang latens, fejlkoder og retry-strategier for hvert API-kald.
    • Tjek, at der ikke skrives persondata eller tokens til logs.
  4. A/B- og online-målinger
    Formål: Se om forbedringer holder vand i produktion.
    • Routér en procentdel af trafikken til “eksperiment” via feature-flags.
    • Mål opgavesucces, tokenforbrug, CES/NPS og interventionsrate i realtid.
    • Brug sequential testing eller Bayesiansk analyse for hurtigere signifikans.
  5. Rød-teamning & sikkerhedstests
    Formål: Afsløre jailbreaks, datasabotage og politiske brud.
    • Kør automatiserede prompt-injektion suites én gang i døgnet.
    • Lad interne og eksterne “red-teams” indsende nye exploits via et bounty-program.
    • Log alle resultater i et separat security_evals-repository.

Fra rå tal til styringsværktøj

Metrik Vægt Datakilde
Opgavesuccesrate 30 % Offline & Online
Sikkerhed / policy 15 % Red-team & Logs
Faktualitet 10 % Auto-grader + Human
Autonomi / intervention 10 % Online
Værktøjs­effektivitet 10 % Sandbox & Prod
Omkostning 10 % Billing API
Fejltolerance 5 % Simulation
Robusthed 5 % Noise-tests
Brugeroplevelse 5 % Surveys

Den samlede komposit-score beregnes som vægtet gennemsnit og publiceres i et Grafana eller Power BI dashboard. Threshold alerts (PagerDuty/Slack) udløses ved fald > X % i kritiske metrikker.

Ci/cd, drift og monitorering

  • Regressionstests i pipeline: Stop automatiske deploys hvis komposit-score < sidste release eller hvis sikkerheds-score < 95 %.
  • Prompt- og modeldrift: Hash alle prompts; sammenlign output-distributioner over tid (Population Stability Index). Rul tilbage via feature-flags.
  • Auditlogning: Gem fuld interaktionshistorik (anonymiseret) + model-parametre for compliance (GDPR, ISO 27001).

Governance & etik

  • Etabler et Model Oversight Board som godkender større prompt- eller arkitekturændringer.
  • Dokumentér beslutninger i Model Cards, Data Statements og System Fact Sheets.
  • Kør årlig bias-revison og offentliggør resultaterne.

Best practices

  1. Start småt: Automatiser 2-3 nøglemetrikker før du forsøger den fulde palet.
  2. Hold test- og produktions-credentials adskilt for at undgå datalæk.
  3. Lad menneskelige reviewere fokusere på fuzzy aspekter (tillid, tonalitet), og lad maskiner klare det binære.
  4. Opsæt canary-releases med “kill-switch” knap.
  5. Budgettér til vedligehold: nye modeller = nye failure-modes.

Kendte faldgruber

  • Proxy-gaming: Agenten optimerer mod metrikker frem for brugerintention.
  • Eval-træthed: Overforbrug af store LLM-graderinger giver høje API-regninger.
  • Sampling-bias: Datasæt der ikke afspejler reelle brugere → falsk sikkerhed.
  • For sen feedback: Uden realtidsovervågning fanges katastrofer først i support-tickets.
  • Silo-organisering: Hvis ownership er uklart, drukner resultaterne i dashboards ingen ser på.

Nøglen er at gøre evaluering lige så iterativ, versionsstyret og synligt som selve koden - ellers bliver din LLM-agent hurtigt en sort boks med ukendt risiko.

Indholdsfortegnelse