Offline-evalueringsvs. online-overvågning af AI-agenter

Definering af offline-evaluering

Trajekt-sammensætning

En trajekt er en ordnet liste af trin, som agenten forventes at følge, når den modtager en bestemt input. Hvert trin indeholder:

- brugerudtalelse eller systemhændelse, der udløser agenten - tanke eller resonnering, som agenten skal producere (hvis du logger chain-of-thought) - værktøjskald eller API-anmodning, som agenten skal foretage - forventet værktøjsrespons eller miljøfeedback - den endelige agentoutput, der skal vises til brugeren eller downstream-systemet

Når du indsamler trajekter, starter du normalt med en lille sæt repræsentative brugerhistorier, derefter udvider du dem ved at tilføje edge-cases, som du har set i logs eller som du kan forestille dig fra kravdokumenter.

Bedømmelsesrubrik

Offline-evaluering sammenligner agentens faktiske trajekt med den gyldne trajekt ved hjælp af en rubrik, der kan indeholde flere uafhængige dimensioner:

- Exakt match – producerer agenten den samme sekvens af værktøjskald og responser? - Semantisk lighed – er udtalelserne eller outputterne meningsfuldt ækvivalente, selvom formuleringen afviger? - Trofasthed – forbliver agentens resonnering grundet i de leverede værktøjsoutputter? - Opgave succes – tilfredsstiller den endelige output succeskriterierne defineret for historien?

Hver dimension modtager en score mellem 0 og 1. Den samlede offline-score er ofte en vægtet gennemsnit, men du kan også behandle hver dimension som en separat gate.

Kørning af offline-evalueringsci

Fordi sættet af trajekter er statisk og rubrikken er deterministisk, kan du køre evalueringen som et trin i din kontinuering integration pipeline. Trinet typisk:

- checker ud agentkoden og trajekt-fikseringerne - installerer eventuelle nødvendige afhængigheder - udfører agenten mod hver trajekt, fanget den faktiske spor - anvender rubrikken og skriver en JSON-rapport - fejler bygningen, hvis nogen score falder under en foruddefineret grænseværdi

Dette giver dig hurtig feedback på regressioner, som du kan reproducere.

Definer online-overvågning

Hvad du observerer i produktion

Online-overvågning sammenligner ikke med et forhåndsskrevet script. I stedet strømmer den live-signaler fra den kørende agent og søger efter afvigelser fra etablerede baseline-værdier. Typiske signaler omfatter:

- fordeling af brugerudtalelsernes længde eller tokenantal - hyppighed af hver værktøkskald - fejlrate returneret af eksterne API'er - latency for hvert trin i agent-løkken - rate for fallback- eller gentagelsesadfærd - semantisk drift i den endelige output (målt med indlejring afstand til en seneste reference-sæt)

Fordi produktions-trafik er ubegrænset, indsamler du disse signaler over tidsvinduer (f.eks. fem-minutters glidevinduer) og sammenligner dem med historiske kvartiler.

Instrumenteringspunkter

For at få de data, du har brug for, skal du instrumentere agenten på et par nøglepunkter:

- ved indgangspunktet – fanget det rå brugeranmodning og en tidsstempel - før hvert værktøkskald – log det intentionerede kald og argumenterne - efter hvert værktørsvar – log succesflaget, fejlkode og payload-størrelse - efter agenten producerer sin endelige output – log output-teksten og eventuelle sikkerhedsscores - på regelmæssige interval – udsend et hjerteslag, der inkluderer memory-brug og CPU-belastning

Disse logs sendes til en overvågningsbackend (Prometheus, Loki eller en brugerdefineret tidsserie), hvor du kan oprette dashboards og alarms.

Eksempel på alarmregel

En nyttig regel er at alarmere, når andelen af kald til en bestemt ekstern API, der returnerer en 5xx-fejl, overskrider 99. percentilen for de sidste to uger for tre på hinanden følgende vinduer. Dette fanger en pludselig nedgradering af en afhængighed, som den offline-sæt aldrig dækkede, fordi fejlmodus kun opstår under virkelyst-last.

Almindelige fælder, når man kun afhænger af ét lag

- At levere med kun offline-scores – du kan passere gate, men stadig frigøre en agent, der fejler på sjældne brugerformuleringer eller på en værktøjsadfqrd, der kun viser sig under høj koncurrency. - At levere med kun dashboards – du måske lægger mærke til et problem dage efter, at den fejlende ændring er blevet merged, hvilket gør rollback hårdere og øger brugerens påvirkning. - At sammenligne produktionsnumre over en periode, hvor modellen, prompten eller værktøjslisten også er ændret – den observerede drift kunne være på grund af den bevidste opgradering snarere end en regression, hvilket fører til falske alarms. - At bruge samme grænseværdi for offline- og online-signaler – offline-scores er normalt tætte (du forventer næsten-perfekte matches), mens online-metrikker er støjende; at anvende en enkelt grænseværdi kan føre til enten for mange falske positive eller missed detections.

Opbygning af en regressionsport i CI

Nedenfor er et konkrekt eksempel på, hvordan du kunne strukturere porten for en kundesupportagent, der bruger et sprogmodel, et genfindingsværktøj og en billetoprettelses-API.

Trin | Værktøj eller script | Output | Frekvens Kontroller kode og fixtures | git clone + git checkout | rent arbejdsområde | en gang per pipeline-kørsel Installer afhængigheder | pip install -r requirements.txt | isoleret miljø | en gang per pipeline-kørsel Kør agent på hver trajektori | python run_agent.py --trajectories data/trajectories.jsonl | JSONL-fil med faktiske spor | en gang per pipeline-kørsel Anvend rubrik | python score_traces.py --rubrik config/rubrik.yaml | score per dimension og samlet | en gang per pipeline-kørsel Tjek grænseværdier | python gate_check.py --min-overall 0.92 --min-faithfulness 0.88 | bestå/fejl-status | en gang per pipeline-kørsel Udgiv rapport | curl -X POST -d @report.json https://metrics.example.com/ingest | post i tidsserie | en gang per pipeline-kørsel

Hvert trin er bevidst holdt idempotent, så re-kørsel af pipelineen giver det samme resultat. Hvis et trin mislykkes, stopper pipelineen og merge-anmodningen blokeres.

Konfiguration af produktionsalarmer, der har betydning

Effektiv online-overvågning fokuserer på signaler, der ændrer sig hurtigt, når noget går galt, snarere end på målinger, der kun ændrer sig langsomt.

Værktøjsfejlrate

Mål forholdet mellem fejlede værktøjskald og samlede værktøjskald for hver ekstern service. En pludselig stigning indikerer ofte en nedbrud eller en ændring i servicekontrakten, som agenten ikke har tilpasset sig.

Loop-genstartstæller

Nogle agenter genstarter et værktøjskald, når de modtager en tvetydig respons. Spor den gennemsnitlige antal genstart per brugeranmodning. En stigning kan betyde, at modellen producerer mere usikre output eller at værktøjet returnerer vage fejl.

Output-embedding-drift

Beregn en sætningsembedding for hver endelig agentoutput og sammenlign dens afstand til medianembedding af den sidste stabile uge. Hvis 95. percentilafstanden overstiger en forudindstillet grænse, udløs en undersøgelse.

Sikkerhedssignal-overvågning

Hvis du kører en prompt-injektionsdetektor eller en profanity-filtreringsfunktion på agentoutput, log den brøkdel af anmodninger, der er markeret. Brug OWASP Prompt Injection Prevention Cheat Sheet (https://cheatsheetseries.owasp.org/cheatsheets/LLM_Prompt_Injection_Prevention_Cheat_Sheet.html) til at afgøre, hvilke mønstre du skal overvåge. En stigning i markerede anmodninger kan indikere, at modellen bliver mere sårbær over for jailbreak-forsøg.

Lukke cirklen: omdannelse af overvågningsresultater til offline-test

Den virkelige kraft i at have begge lag kommer til syne, når du bruger produktionsobservationer til at forbedre din testssuite.

Fanget en ny fejl

Når en alarm udløses, er det første skridt at udtrække den præcise anmodning-svar-sekvens, der forårsagede problemet. De fleste overvågningsystemer låter dig downloade en spor-id, der indeholder:

- den oprindelige brugerudtalelse - hver værktøjopkald og dets argumenter - hver værktøjsrespons - den endelige agentoutput

Gem denne spor som en ny trajektoriefil.

Mærk den forventede adfærd

Arbejd med produkt ejeren eller sikkerhedslederen for at afgøre, hvad den korrekte adfærd skal være. Hvis fejlen skyldtes en fejl i værktøjet, kan du beslutte at simulere værktøjsresponsen for at simulere den rettede version. Hvis fejlen skyldtes modellens resonnering, kan du skrive en tankekedde, der fører til det korrekte svar.

Tilføj til den offline-samling

Placer den nye trajektorie i versionkontrolleret trajektorie-mappe. Opdater dokumentationen for at notere kilde (f.eks. "tilføjet fra produktionsincident INC-2024-09-12-07").

Justér rubrikken hvis nødvendigt

Nogle gange afslører en ny trajektorie en dimension, der tidligere blev ignoreret. For eksempel kan du opdage, at agenten nogle gange producerer et korrekt svar, men inkluderer en unødvendig undskyldningsfrase, der irriterer brugere. Du kan tilføje en "koncisel" dimension til rubrikken og give den en vægt.

Kør gate igen

Kør CI-pipeline igen. Hvis den nye trajektorie får den samlede score til at dykke under threshold, ved du, at den nuværende kode ville have fejlet gate - hvilket er præcis, hvad du ville have fanget, før frigivelse.

At gentage denne cyklus skaber en feedback-løkke, hvor produktionen lærer testssuiten, hvad der skal testes, og testssuiten forhindrer kendte regressionsfejl i at nå brugere.

Hvad dette ikke er

Denne diskussion lover ikke, at offline-evaluering vil fange alle mulige fejl før frigivelse. Den hævder ikke, at online-overvågning aldrig vil overse en fejl eller at de to lag sammen giver en 100 % garanti for korrekthed. Den fastslår ikke, at brug af disse metoder vil gøre din agent fejlfri eller at du kan springe over sikkerhedsrevisioner, rød-hold-øvelser eller formel verificering. Den antyder ikke, at signalerne beskrevet er tilstrækkelige til overholdelse af regler i høj-risiko-domæner. Den påstår ikke, at arbejdsgangen vil eliminere behovet for menneskelig overvågning eller at du kan stole udelukkende på automatiserede scores til frigivelsesbeslutninger. Den garanterer ikke, at en bestemt grænseværdi vil virke for hvert hold eller hver modelarkitektur. Den påstår ikke, at tabellen ovenfor er den eneste måde at konfigurere en CI-port eller at alarmreglerne nævnt er universelt optimale. Den hævder ikke, at OWASP-svindelark vil forhindre alle prompt-injektionsforsøg eller at de erstatter en dedikeret sikkerhedsrevision.

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

Har vi brug for begge?

Ja, hvis agenten berører noget, som en bruger eller et system bekymrer sig om. De detekterer forskellige klasser af fejl.

Kan offline-tester erstatte overvågning?

Nej. Dit testset kan ikke indeholde inputs, du endnu ikke har tænkt på.

Kan overvågning erstatte offline-tester?

Nej. Overvågning fortæller dig, at noget er ændret efter faktum; en gate fortæller dig før frigivelse.

Hvad skal vi alarmerer om i produktion?

Ændringshastighed i fejlsignaler, værktøjsfejlhastigheder og usædvanlige loop- eller gentagelsesmønstre - ikke kun volumen.

Hvordan holder vi scores sammenlignelige over tid?

Fastgør rubrikken og trajektorierne, og optegn ændringer i model, prompt og værktøjer sammen med scores.

Er nogen af lagene en sikkerhedscertificering?

Nej. Begge er ingeniørsignaler. Sikkerhedsreview er en separat øvelse.

Referencer

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

Prøv produktet: AgentGrade

2026-09-20 · kun primærkilder · ingen fabrikerede trafikmålinger · beslutningsstøtte kun

Relaterede artikler

- Agenteval-rubrikker, der bevæger sig over stacks - Udforsk det fulde AI mikro-SaaS emne matrix →