Automatisk fejltriage for AI-agenter lyder som en luksus, indtil man har siddet en nat og bladret gennem 400 spans for at finde det første knæk, der fik resten til at vælte. AWS beskriver nu, hvordan Strands Evals’ detectors går fra simple scores til reel årsagsanalyse af agenters traces. Det rammer et ømt punkt i produktion. Hvis værktøjet leverer som beskrevet, kan timer blive til minutter. Det er AWS’ egen påstand, ikke en uafhængig måling endnu (kilde).
Kernen i nyheden: Detectors i Strands Evals SDK identificerer fejl i agenters eksekveringsspor automatisk og udfører root-cause-analyse. Outputtet er struktureret med kategoriserede fejl, vurderingssikkerhed, kausale kæder og forslag til, hvor fixet typisk hører hjemme. Ikke bare hvad der gik galt, men hvorfor og hvor man starter (AWS, Strands Evals GitHub).
Scores forklarer ikke årsagen
Mange teams måler allerede goal success rate, værktøjsvalg-nøjagtighed og måske en hjælpsomhedsscore. De tal er gode til at fange regressioner. Men de siger ikke, hvorfor fejlene opstår. Strands Evals organiserer i Cases, Experiments og Evaluators. Det giver kvalitetssignaler. Detectors lægger så et diagnosespor pr. span og knytter årsagskæder på tværs af en hel session. Mindre gætteri, mere konkret fejlfinding (repo).
I praksis fortsætter man sine eksperimenter og kobler automatisk triage på hver kørsel. Det strukturerede output kan flyde direkte ind i dashboards, issue-trackere eller incident-systemer.
Sådan fungerer detectors teknisk
Pipeline er todelt. Først scanning af alle spans i en session mod en fejl-taksonomi. Ni overordnede kategorier fremgår: hallucination, forkerte handlinger, orkestreringsfejl, manglende efterlevelse af instruktioner, eksekveringsfejl, konteksthåndtering, repetitiv adfærd, LLM-outputproblemer og konfigurationsmismatch. Hvert fund får span-lokation, en eller flere kategorier, confidence-score og evidens udtrukket af tracen.
Dernæst årsagsanalysen. De fundne fejl kædes sammen kausalt. Et tidligt logisk knæk kan forklare flere senere symptomer; det markeres som primær, sekundær eller tertiær. Outputtet prioriterer mod første årsagsled frem for bare højeste alarm. AWS beskriver en tieret strategi til forskellige sessionsstørrelser (blog).
Hvad outputtet ligner
Diagnosen kommer struktureret: fejltyper pr. span, confidence, en kæde af hvad der forårsagede hvad, samt anbefalinger. En nyttig detalje er markering af, hvor fixet foreslås: systemprompt, værktøjsbeskrivelse eller andet. Det gør hånd-offs kortere mellem roller i triage.
Pointen for drift: færre runder på Slack, fordi ejergruppen kan udpeges hurtigere.
Krav og forudsætninger
For at komme i gang kræves Python 3.10 eller nyere, installation af strands-agents-evals via pip, Amazon Bedrock-adgang (LLM-baseret analyse) og, for CloudWatch-eksempler, credentials med logs:StartQuery og logs:GetQueryResults. Ikke eksotisk, men det kræver DevOps-arbejde og rettighedsstyring (kilde).
I praksis: tjek runtime-versioner i CI, kør evals i et isoleret miljø, giv Bedrock-policy med mindst mulige rettigheder, og scope CloudWatch-adgang til relevante log groups.
Sparer det reelt tid
AWS skriver, at diagnosticering kan gå fra timer til minutter. Det er plausibelt, fordi manuel span-for-span-inspektion undgås, og fordi årsagskæder prioriterer første fejl. Men der er ingen uafhængig dokumentation af præcision på tværs af fejlkategorier. Ingen publiceret precision eller recall pr. kategori i materialet. Test derfor på egne traces, før I justerer processer efter resultaterne.
Lav en kort pilot med klare målepunkter. Lad tallene afgøre, om det holder i jeres miljø.
Konsekvenser for implementering
I CI og CD giver det mening at køre detectors på både syntetiske cases og udvalgte repriser af reale sessioner. Faldgruben er støj: hvis traces er uens eller mangler felter, bliver diagnoserne usikre. Start med en tynd golden-path-suite med kendte fejltyper og sporbar inputkontekst.
I build-gates kan exit-koder fra CLI’en bruges til at blokere releases, når nye kritiske kategorier optræder, eller når årsagskæder peger på ændringer i systemprompten, der kræver review. For on-call bør output lande i incident management med vedhæftet kæde og confidence, så der kan eskaleres til den rigtige ejergruppe uden gætværk.
Performance og throughput i praksis
Mål, før I forpligter jer til synkron kørsel i CI. Tre tal er centrale: median og 95p latenstid pr. fuld analyse, samt tokens pr. trace. Sæt en simpel regel: hvis 95p-latenstid pr. analyse holder jer under jeres build-budget, kan det køre synkront; ellers kør asynkrone batches på en kø.
Log også andelen af store sessioner, der kræver flertrinsanalyse, og hvordan det påvirker både latenstid og tokenforbrug. Det er drift, ikke teori.
Sikkerhed, compliance og logpolitik
CloudWatch-integration kræver query-rettigheder. Logs kan indeholde persondata eller forretningshemmeligheder, især når agenten har kundekontekst. Filtrering eller anonymisering af felter bør ske, inden traces sendes til LLM-analyse. Nedenfor et minimumssæt af felter, der typisk fjernes eller maskeres: PII, tokens, interne id’er, rå dokumentindhold og alt, der kan identificere en kunde direkte.
Et simpelt, sikkert trace-format kan se sådan ud:
{
"session_id": "anon-uuid",
"timestamp": "2024-05-10T12:34:56Z",
"spans": [
{
"span_id": "s1",
"parent_id": null,
"name": "tool.call",
"inputs": {"query_hash": "e3b0c442..."},
"outputs": {"status": "ok"},
"metadata": {"latency_ms": 123, "model": "bedrock:model-alias"}
}
],
"attrs": {"env": "ci", "build": "1234"}
}
Note: ingen rå prompts, ingen kundetekster, ingen adgangstokens. Hash eller truncate, hvis feltet er nødvendigt til fejlfinding.
Anbefalet anonymiserings-workflow
Byg en lille pipeline, der kører før evaluering: serialisér trace, kør anonymiseringsfunktion, valider mod enhedstests, og gem derefter som artefakt. Tjeklisten er kort:
- Fjern eller maskér PII og hemmeligheder deterministisk.
- Valider med tests, der fejler, hvis PII-lignende mønstre findes (e-mail, telefon, CPR-agtige sekvenser).
- Skil eval-logs og produktionslogs ad i hver sin log group med forskellig retention og IAM.
- Dokumentér serialiseringsskemaet, så udviklere ved, hvad der er lovligt at logge.
Typiske fejl og verifikation
Falske positiver: en hård promptregel kan forveksle legitim afvigelse med non-compliance. Falske negativer: subtil konteksttab ved meget lange samtaler kan skjule den oprindelige fejl. Håndtering i praksis:
- Marker lave confidence-fund til manuel review.
- Brug spotchecks: træk 5–10 diagnoser pr. uge til manuelt tjek.
- Lav letvægts-labeling: når on-call korrigerer en diagnose, gem facit og genbrug til regressionstests.
Sådan får man værdi hurtigt
Start smalt. Et minimum-setup er 10–20 veldefinerede cases, der dækker de vigtigste flows, plus 3–5 kendte fejlscenarier. Kør detectors i CI på hver commit til agentlogik, promptændringer og tool-skemaer. Fil de første uger output ned i et simpelt dashboard med tre felter: fejltype, confidence, foreslået fix-sted.
Når det virker på det smalle sæt, kan man udvide med reale traces i batches. Kast ikke alt ind fra dag ét. Ellers drukner teamet i signaler, der ikke kan handles på.
Pilotprotokol med målbare succeskriterier
Periode: 2–4 uger. Datagrundlag: 10–20 golden-path cases, 3–5 fejlscenarier, plus 50–100 repriser af reale sessioner. Mål pr. uge:
- Time-to-diagnosis: median og 95p fra alarm til første plausible årsag.
- Match-rate: andel hvor foreslået fix-type matcher endelig rettelse.
- Precision og recall pr. fejlkategori på egne data.
- Andel af incidents, der kan lukkes uden manuel fuldlæsning af trace.
Huller i dokumentation og eksempler
Der er ingen publicerede tal for præcision pr. kategori. Ingen mål for throughput under produktionsbelastning. Det gør kapacitetsplanlægning vanskelig. Uden latenstal pr. fuld analyse er det uklart, om triage kan køre synkront i CI, eller bør skubbes til en asynkron kø. Se afsnittene om prerequisites og detectors i AWS-blogindlægget for den dokumentation, der findes i dag (link), og SDK/CLI-detaljer i repoet (link).
Der mangler også klare retningslinjer for anonymisering før LLM-analyse. Teams må definere det selv som en del af piloten.
Omkostninger og ressourcestyring
Hver detektion og analyse udløser LLM-kald via Bedrock. Styr økonomien ved at måle: tokenforbrug per trace, gennemsnitligt antal spans og andel af store sessioner. Sæt budgetalarmer, og stram inputkonteksten, så irrelevante felter ikke sluger tokens.
Et simpelt regneark rækker: cases pr. dag, spans pr. case, tokens pr. span-analyse og pris pr. 1.000 tokens for valgt model. Brug tallene til at sætte batchstørrelse og hvad der køres offline.
Målepunkter for succes
Hold det skarpt. Time-to-diagnosis fra alarm til første plausible årsag. Andel af fejl hvor foreslået fix-type matcher den endelige rettelse. Precision og recall per fejlkategori på egne data. Reduktion i manuelle trace-gennemlæsninger pr. incident. Hvis tallene ikke bevæger sig efter en måned, er der noget galt i logging-strukturen eller i, hvordan output anvendes i triage.
Ret først datahygiejnen. Justér derefter detektionsregler og workflows.
Konkurrence og videreudvikling
Det her placerer sig i observability for AI-systemer, hvor eval-rammer, tracing og klassisk driftsovervågning mødes. Det komplementerer eksisterende metrics og logs, fordi det går ind i selve agentens beslutningsforløb. Alternativer i dag er hjemmerullede regler, manuelt review eller eval-værktøjer uden årsagskæder.
Næste skridt for økosystemet bør være åbne benchmarks for detektionspræcision og faste mønstre for datahygiejne. Også bedre tooling til at lære lokale domænemønstre uden at miste generalitet.
Vurdering og anbefaling
Detektorlaget adresserer hullet mellem score og handling. Hvis I i dag bruger tid på manuel triage af agentfejl, er der god grund til at eksperimentere. Start snævert og mål alt. AWS’ tidsgevinst er en leverandørpåstand; verificér den i jeres pipeline, før I bygger faste gates på den.
Rækkefølgen er klar: først sporbarhed og ren logging, så automatiseret analyse. Forskellen mærkes først, når I sidder med diagnoserne i hænderne.
Handlingsliste for tekniske teams
- Miljø og rettigheder: Sikr Python 3.10+, pip install af strands-agents-evals, Bedrock-adgang og minimum CloudWatch-permissions til udvalgte log groups.
- Datahygiejne: Definér en trace-serialisering uden PII og hemmeligheder. Enhedstest anonymisering før pilot.
- Testsuite v1: 10–20 golden-path cases og 3–5 kendte fejlscenarier. Fastfrys inputkontekst for reproducerbarhed.
- CI-integration: Kør detectors på hver PR, brug exit-koder til build-gates. Gem struktureret output som artefakt.
- On-call flow: Post diagnoser til incident-system med kausalkæde og confidence. Definér ejergrupper for prompt vs. tool-fixes.
- Målinger: Track time-to-diagnosis, match-rate mellem forslag og faktisk fix, og egen precision og recall pr. kategori.
- Økonomi: Mål tokens per trace og sæt budgetalarmer. Batch store analyser asynkront.
- Review efter 4 uger: Behold det, der skærer tid og fejl. Skær resten fra eller justér logningen.
