Hvad betyder Task success rate?
Task success rate måler, om brugerens samlede opgave bliver løst. Hvis en agent i 36 af 50 testforløb finder den rigtige sag, udfører den tilladte ændring og bekræfter resultatet korrekt, er succesraten 72 procent. Det forudsætter, at alle nødvendige kriterier faktisk er kontrolleret.
Målet flytter opmærksomheden fra pæne svar og vellykkede API-kald til arbejdets resultat. Et værktøj kan svare uden fejl, mens agenten har valgt den forkerte kunde. Et svar kan lyde færdigt, selv om ændringen aldrig blev gemt. Derfor skal succes defineres som observerbar tilstand, ikke som agentens egen påstand.
Beskriv sluttilstanden og de tilladte grænser
En testopgave bør angive startdata, forventet resultat og begrænsninger. For en mødeassistent kan succes kræve korrekt deltager, ledigt tidspunkt, godkendelse og én registreret aftale. Et korrekt møde med en uautoriseret invitation er ikke fuld succes. Aftal også, hvordan manglende oplysninger håndteres: nogle opgaver er løst korrekt ved at spørge brugeren eller eskalere, frem for at gennemføre en handling. Definér disse udfald før testen. Ellers risikerer teamet at ændre succeskriteriet bagefter for at passe til det, systemet tilfældigvis gjorde.
Tæl forsøg på en sammenlignelig måde
Angiv, om resultatet gælder første forsøg, gentagne forsøg eller en løsning med menneskelig hjælp. En agent, der lykkes efter fem genstarter, har andre driftsvilkår end en, der lykkes direkte. Bevar derfor også tid, værktøjsforbrug og mængden af manuel hjælp. Del fejlene op efter årsag, så de kan rettes: manglende data, forkert plan, afvist adgang eller ukorrekt slutkontrol. Brug både almindelige sager og relevante grænsetilfælde, men rapportér grupperne tydeligt. En kunstigt svær stresstest og en repræsentativ driftsprøve svarer på forskellige spørgsmål og bør ikke blandes til ét uigennemsigtigt tal.
Et eksempel fra praksis
En servicevirksomhed afprøver en agent, som klargør opfølgning på afsluttede opgaver. Testmiljøet indeholder kendte kunder og sager. Succes kræver, at agenten vælger den rigtige sag, laver et relevant udkast, gemmer det som udkast og undlader at sende noget. Et forløb, der sender en mail, fejler dermed testen, selv hvis teksten er god. Teamet kontrollerer resultatet i målsystemet og bruger loggen til at finde årsagen til fejlene.
Typiske faldgruber
- At tælle et grønt API-svar eller agentens 'færdig' som opgavesucces.
- At skjule menneskelig hjælp og gentagne forsøg i den samlede procent.
- At ændre succeskriterierne undervejs uden at genmåle tidligere resultater.
Det skal I afklare
- Definér starttilstand, sluttilstand, tilladte handlinger og korrekt eskalering.
- Kontrollér resultatet uafhængigt af agentens afsluttende tekst.
- Vis antal forsøg, fejlårsager, tid og manuel hjælp sammen med succesraten.
Spørgsmål og svar
Kan delvist løste opgaver tælle med?
De kan rapporteres særskilt eller få en tydeligt defineret delscore. En fuld succesrate bør kun tælle de opgaver, der opfylder alle de aftalte nødvendige kriterier.
Findes der én standard for succes?
Nej. Succeskriteriet afhænger af opgaven. Benchmarks som SWE-bench bruger konkrete kodeopgaver og tests, mens virksomhedens egen proces kræver kriterier, der passer til dens systemer og ansvar.
Kilder og videre læsning
De tekniske begreber bygger på nedenstående kilder. Eksemplerne er illustrative og viser, hvordan I kan arbejde med emnet.
- LangSmith: Evaluation concepts ↗Definition af kvalitetskriterier, testdata og evaluering af hele systemer og deltrin.
- SWE-bench: Overview ↗Eksempel på opgavebaseret evaluering med konkrete kodeproblemer og et reproducerbart testmiljø.