Agent vurderingsrubrikker, der kan bruges på tværs af teknologistacks

Definerer en rejseklar rubrik

Jeg starter med at skrive rubrikken, før jeg kigger på nogen modeloutput. Rubrikken skal indeholde tre uafhængige akser: opgave succes, værktøj korrekthed og troværdighed. Hver akse får sin egen vurderingsvejledning, der ikke nævner modelnavnet, rammeversionen eller den præcise prompt-formulering. Jeg gemmer vejledningerne i en plain-text-fil, der ligger ved siden af testssuiten, så alle kan se dem.

Kerneejendomme

- Foruddefinerede kriterier – succesbetingelserne skrives ned, før den første kørsel. - Akseisolering – score for en akse bløder aldrig ind i en anden.

Hvorfor opgave succes skal være resultatbaseret

Opgave succes besvarer det simple spørgsmål: fik agenten afsluttet hvad der blev bedt om? Jeg dømmer dette mod en checkliste, der ser på den endelige tilstand af verden, ikke på formuleringen af svaret. For eksempel, hvis opgaven er "opdater brugerens e-mail-adresse til alice@example.com", tjekker jeg database-posten efter kørslen. Jeg bekymrer mig ikke om, hvorvidt agenten sagde "Jeg har opdateret din e-mail" eller "Din e-mail er nu alice@example.com".

Konkret checkliste

- Forudsætning verificeret (f.eks. bruger findes). - Efterudsætning verificeret (f.eks. e-mail-felt er lig med alice@example.com). - Ingen ekstra sideeffekter (f.eks. ingen andre felter ændret). - Valgfrit: forsinkelse under en grænseværdi (f.eks. 2 sekunder).

Jeg optager en binær bestået/ikke-bestået score for hver trajektori. Hvis agenten mislykkes i efterudsætningen, er opgave-succes-scoren nul, uanset hvor flydende prosaen ser ud.

Værktøjets korrekthed som en separat akse

Værktøjets korrekthed ser på de opkald, agenten laver til eksterne API'er, funktioner eller databaser. Jeg behandler hvert opkald som et mini-eksperiment: valgte agenten det rigtige værktøj, overførte det de rigtige argumenter, og ringede det det rigtige antal gange? Jeg følger retningslinjerne fra OWASP-cheatsheets om sikker værktøjsbrug, f.eks. LLM Prompt Injection Prevention Cheat Sheet og SQL Injection Prevention Cheat Sheet for at undgå utilsigtet injektion.

Bedømmelsesskema

- Det rigtige værktøj er valgt – 1 point. - Alle argumenter matcher skemaet – 1 point per argument. - Ingen ekstra opkald – 1 point, hvis opkaldsantal svarede til det forventede. - Ingen forbudte sideeffekter (f.eks. skrivning til en log, der skal forblive læsbar) – 1 point.

Akse-scoren er summen af point divideret med det maksimale mulige. Jeg holder denne akse separat, så en fejl i værktøjsbrug ikke skjuler en succes i opgavegennemførelse.

Sandhed: sporing af hver påstand

Sandhed spørger, om hver udsagn i agentens output kan spores tilbage til værktøjsresultaterne eller den kontekst, der blev givet til modellen. Jeg behandler outputtet som en samling påstande og checker hver enkelt påstand mod beviserne. Hvis en påstand ikke kan understøttes, markerer jeg den som en hallucination. Denne akse er vigtigst, når agenten sammenfatter dokumenter, citerer kilder eller besvarer spørgsmål, der kræver eksterne data.

Trin-for-trin-verificering

- Split outputtet op i atomare sætninger.- For hver sætning, liste de faktiske påstande, den indeholder.- Match hver faktisk påstand med en linje i værktøjsoutputtet eller en snippet fra den leverede kontekst.- Hvis en faktisk påstand ikke har nogen match, tæl den som en fejl.- Sandheds-score = (antal understøttede faktiske påstande) / (samlet antal faktiske påstande).

Jeg optager de rene tal, så jeg kan se, om et fald i sandhed kommer fra få store hallucinationer eller mange små fejl.

Hvad dette ikke er

Jeg vil gerne gøre det klart, hvilke begrænsninger en rejseklar rubrik har. Den garanterer ikke, at agenten er sikker, billig eller hurtig. Den lover ikke 100 % nøjagtighed på hver mulig input. Den er ikke en erstatning for en dedikeret sikkerhedsreview, en omkostningsanalyse eller en forsinkelsesbenchmark. Rubrikken måler kun de tre akser, jeg definerede ovenfor. Hvis du skal vide, om agenten lækker private nøgler, skal du køre en separat hemmelighedsstyringscheck, f.eks. ved hjælp af Secrets Management Cheat Sheet. Hvis du skal vide, om agenten holder sig inden for en budget, skal du spore tokenbrug eller API-opkaldskost uden for denne rubrik.

Kort sagt er rubrikken et værktøj til at sammenligne agentkvalitet på tværs af stacks, ikke en mirakelkur for alle produktionsproblemer.

Opbygning af sammenlignelige trajektorier

En trajektori er den fulde log over, hvad der sker under én kørsel: den initielle prompt, hver værktøkskald med dets argumenter og resultater, og den endelige modeloutput. Jeg gemmer hver trajektori som et JSON-objekt med et fast skema, så jeg kan differe kørsler automatisk. Herunder er et eksempel på skemaet, jeg bruger.

Felt | Type | Beskrivelse prompt | string | Den nøjagtige bruger- eller systemprompt, der sendes til modellen. værktøkskald | array | Ordenet liste over værktøgskald. værktøkskald[].værktøj | string | Navn på værktøjet eller API'et. værktøkskald[].argumenter | object | Argumenter, der sendes til værktøjet. værktøkskald[].resultat | any | Råt output fra værktøjet. output | string | Den endelige tekst, der returneres af modellen. metadata | object | Valgfrie tags som modelnavn, frameworkversion, tidsstempel.

Fordi skemaet aldrig ændrer sig, kan jeg beregne de tre akse-scores for hver trajektori ved hjælp af samme scripts. Jeg har et master-sæt af trajektorier, der dækker de kerneopgaver, jeg leverer, og de almindelige fejlmoder, jeg har set. Når jeg ændrer modellen, kører jeg de samme trajektorier igen og sammenligner de nye scores med baseline.

Kører evalueringer på hver ændring

Jeg integrerer evalueringstrinet i min kontinuerlige-integrationspipeline. Pipelinen gør følgende for hver commit, der kan påvirke adfærd:

- Checker ud den seneste kode. - Installerer agentafhængighederne. - Kører agenten mod den faste trajektorisæt. - Parser logfilerne og beregner opgave-succes-, værktøj-korrekt- og trofasthedsscores. - Poster resultaterne til en dashboard og markerer enhver akse, der falder mere end fem procent i forhold til den foregående grønne build.

Denne praksis fanger regressionsfejl tidligt. For eksempel, da jeg skiftede den underliggende opbevaringsbibliotek, faldt værktøj-korrekt-aksen fra 0,96 til 0,82, fordi den nye bibliotek returnerede resultater i en anden rækkefølge, hvilket fik agenten til at foretage ekstra opkald. Faldet blev vist i CI-rapporten, før nogen bruger lagde mærke til et problem.

Jeg har også en menneskeskørt hold-ud-sæt af tyve trajektorier. Hver måned scorer jeg dem med en person og sammenligner gennemsnittet med de automatiske scores. Hvis den automatiske dommer glider, justerer jeg rubrikken eller genetræner dommermodellen.

Operatør checkliste for Agent eval-rubrikker, der rejser over stacks

Jeg holder en skrevet checkliste ved siden af hver udgivelse, der berører dette emne. Listen er bevidst kedelig: navngiv ejeren, navngiv bevisartefakten og navngiv rollback. Hvis et trin ikke kan producere en fil, en billet eller en loglinje, er det ikke et trin - det er en ønsketænkning.

Før du ændrer produktion

- Frys branchen eller konfigurationsrevisionen, du vil måle imod. - Optæl den nuværende fejltilstand med en konkretpunktet indtastning og en konkretpunktet udgang. - Bekræft, hvilken identitet jobbet kører som, og om denne identitet kan nå data, den ikke skal kunne nå. - Åbn de primære referencer, du vil citerer: https://cheatsheetseries.owasp.org/cheatsheets/LLM_Prompt_Injection_Prevention_Cheat_Sheet.html, https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html.

Mens du kører checken

- Foretræk en reproducerbar vej over ti anekdotiske skærmbilleder. - Skriv den forventede sikre udfald, før du udløser værktøjet eller forespørgslen. - Fanget det præcise kommando, prompt, skema eller regex under test - ikke en paraphrase. - Hvis systemet kan handle (sende, skrive, slette, overføre), kræv en bekræftelsesgrænse i samme pass.

Efter du er færdig

- Fil residual risiko med en ejer og en dato, selv når scan er ren. - Konverter ikke en grøn check til salgssprog, der hævder fuldstændighed. - Kør den samme checkliste, når modellen, værktøjsskemaet eller valideringsreglerne ændres.

Signal | Hvad at optage | Stop-ship? Uventet skriv eller send | Værktøjsnavn, args, identitet | Ja, indtil gated Manglende bekræftelse på destruktiv handling | Call-sti og omgåelse | Ja Ubetroet tekst behandlet som instruktion | Kildeoverflade og resulterende handling | Ja for agent-rækkevidde Scanner ren, dommer åben | Udsatte punkter + ejer | Kun hvis kernevej er sikker

agenteval hjælper med den målbare første passering. Arkitekturvalg, juridisk godkendelse og kundeorienterede krav har stadig brug for en menneskelig ejer. Behandle hver checkliste-række som beslutningsstøtte, ikke et certifikat.

Hvordan jeg forklarer begrænsninger for købere

Når en potentiel kunde spørger, om produktet "dækker alt", besvarer jeg med grænsen: automatiserede kontroller fanger kendte mønstre, men nye kæder og politikdom stiller krav om gennemgang. Den ærlighed holder supportbelastningen nede og holder bloggen aligneret med, hvad produktet faktisk kan.

Hvis du har brug for en anden mening, par denne artikel med referencerne nedenfor og med din egen reproduktion af staging. Spring ikke reproductionstrinet over, bare fordi en model har skrevet en selvbevidst sammenfattelse.

Referencer

- https://cheatsheetseries.owasp.org/cheatsheets/LLM_Prompt_Injection_Prevention_Cheat_Sheet.html - https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html - https://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.html - https://docs.agents-squads.com/guides/config-files

Ofte stillede spørgsmål

Hvor mange testcases har vi brug for?

Tilstrækkeligt til at dække de opgaver, du faktisk sender, og de måder, de fejler på. En håndfuld godt valgte trajektorier slår en stor samling af lette.

Kan vi bedømme outputs med en anden model?

Du kan, men optegn, at dommeren er en model, og hold en fast stikprøve vurderet af mennesker, så du kan se, om dommeren selv er drifteret.

Hvad er troværdighed, konkrekt?

Om hver påstand i outputtet er understøttet af værktøjsresultaterne eller konteksten, agenten fik, snarere end produceret fra modellens egne prioriteringer.

Skal vi kun vurderе det endelige svar?

Nej. Vurder også trajektorien - værktøjskald er, hvor de fleste agentfejl opstår.

Hvor ofte skal evalueringer køre?

På hver ændring, der kan påvirke adfærd: prompt, model, værktøjsliste eller indhentningskonfiguration.

Betyder et godt score, at agenten er sikker?

Nej. Det betyder, at den har fungeret godt på de opgaver, du testede. Sikkerhed, omkostninger og fejlhåndtering er separate evalueringer.

Referencer

- NIST — Ramme for risikostyring af AI - Stanford CRFM — HELM (Holistic Evaluation of Language Models)

Prøv produktet: AgentGrade

2026-09-20 · kun primære kilder · ingen fabrikerede trafikmetrikker · beslutningsstøtte kun

Relaterede artikler

- Offline-evalueringsmetoder vs online-overvågning af AI-agenter - Se det fulde AI mikro-SaaS emne matrix →