Evaluering af AI-agenter: mål task success og fejl
Agent-evaluering skal måle hele opgaven – valg af værktøjer, resultater, handlinger og sikkerhed – ikke kun hvor pænt slutteksten ser ud.
Byg et realistisk eval-sæt
Dig, der har en agentprototype og vil måle task success, værktøjsvalg, fejl og regressioner før mere autonomi.
- Mål flere lag
Agent-evaluering skal måle hele opgaven – valg af værktøjer, resultater, handlinger og sikkerhed – ikke kun hvor pænt slutteksten ser ud.
Byg et realistisk eval-sæt
Brug normale cases, edge cases, manglende data, modstridende instruktioner, værktøjsfejl og opgaver som agenten skal afvise eller eskalere.
Mål flere lag
Registrér task success, korrekt værktøjsvalg, skema-validitet, antal værktøjskald, latency, pris, human takeover og regel violations.
Frys versioner under sammenligning
Gem model, prompt, værktøj-skema, retrieval-konfiguration og dataset-version, så en forbedring faktisk kan forklares.
Kør regression før release
Nye prompts eller værktøjer må ikke kun forbedre den ene case, der udløste ændringen. Kør det samme eval-sæt før udrulning.
Case: evaluer hele ticket-opgaven, ikke slutteksten
Et eval-sæt på 50 supportsager måler korrekt intent, retrieval-kilde, værktøjsvalg, eskalering og endelig handling. En velformuleret tekst tæller ikke som succes, hvis agenten slog den forkerte kunde op eller burde have eskaleret.
Byg dit første agent-eval-sæt
Byg 20 cases til din egen agent: normale, mangelfulde, modstridende, værktøjsfejl og mindst tre cases der skal afvises. Skriv godkendelseskriterier før første kørsel.
Kontrol: kør regression før release
- Kan du reproducere testen med samme model-, prompt- og værktøjsversioner?
- Måler du både task success og regel violations?
- Kører regressionstesten før en prompt, model eller værktøj-skema går i produktion?
Score task success før du scorer “kvaliteten af svaret”
En agent kan skrive et flot svar efter at have kaldt det forkerte system. Evaluer derfor lagvis: korrekt forståelse af opgaven, korrekt værktøjsvalg, gyldige argumenter, korrekt brug af værktøjsresultat, policy-overholdelse og slutresultat.
Inddel fejl efter alvor. En kosmetisk formulering og en uautoriseret skrive må ikke tælle ens i et gennemsnit. Brug hard-fail kriterier til sikkerhed og compliance, og soft scores til stil eller effektivitet.
Gem regressionscases fra produktion. Hver alvorlig fejl bør blive en test, der køres igen før model-, prompt- eller værktøj-ændringer.
Lav en eval-taksonomi før du laver et gennemsnit
Opdel eksempelvis fejl i task failure, værktøj selection, argument validation, retrieval, regel, factuality og UX. Så kan du se, om en ny model faktisk løser det problem, du har, eller blot forbedrer tekstkvaliteten.
Brug hard fails til sikkerhed og kritiske regler
Hvis agenten skriver til forkert kunde, omgår godkendelse eller bruger et forbudt værktøj, bør casen være fejlet uanset hvor flot slutteksten er. Soft scores kan bruges til formulering, relevans og effektivitet, men de må ikke udligne sikkerhedsbrud.
Online og offline evaluering supplerer hinanden
Offline evals giver reproducerbare tests før release. Produktion viser de uforudsete inputs, som testsættet mangler. Sampling af anonymiserede runs, gennemgang-rate, human takeover og fejlårsager kan derfor bruges til at udvide næste regression suite.
En release bør have et sammenligneligt før/efter
Frys dataset, model/config, promptversion og værktøj-skemaer for den test, der sammenlignes. Notér ikke bare “version B føles bedre”; vis hvilke cases den løser, hvilke den forringer, og om latency eller omkostning ændrer sig.