Lag 2: Triagering af agentfejl

Efter du har fortolket evalueringsresultater og identificeret fokusområder, skal du afgøre, hvorfor de enkelte testtilfælde fejlede, og hvem der skal handle.

Denne artikel giver struktureret vejledning til diagnosticering af fejl på testcase-niveau. Det hjælper dig med at klassificere den grundlæggende årsag, skelne mellem agent-, evaluerings- og infrastrukturproblemer og vælge den passende næste handling.

Inden du starter

Inden du påbegynder fejltriage:

1. Gennemfør scorefortolkning og parathedsvurdering, og identificer, hvilke evalueringssæt der kræver opmærksomhed.
2. Fokuser på de højest prioriterede fejl baseret på parathed og risiko.

Forhånds-triage-tjek: Verificér infrastrukturens sundhed

Før du diagnosticerer individuelle fejl, skal du bekræfte, at afhængighederne fungerede korrekt under evalueringen. Infrastrukturproblemer kan forårsage fejl, der ligner agent- eller evalueringsproblemer, men som ikke er relateret til nogen af delene.

Kontrollér følgende:

• Videnskilder er tilgængelige og fuldt indekserede.
• API-backends eller connectors returnerer ikke fejl, timeouts eller begrænsningssvar.
• Autentiseringstokens er gyldige under hele evalueringen.
• Evalueringsmiljøet matcher den tiltænkte agentkonfiguration.

Hvis en afhængighed ikke fungerer korrekt, skal du rette problemet og gentage evalueringen, før du fortsætter. Udvælgelse af resultater fra en ustabil evaluering kan føre til forkerte konklusioner.

Trin 0: Prioriter fejl

Inden du gennemgår de enkelte testcases, skal du beslutte, hvor du vil fokusere først.

Prioriter fejl i denne rækkefølge:

Hvis du har mange fejl (for eksempel mere end 15), så gennemgå ikke hver fejl individuelt. Start med evalueringssættet med lavest score og gennemgå manuelt et par fejl. Hvis fejlene har samme årsag, kan udbedring af denne løse mange fejl på én gang.

Identificer kvalitetssignalet for en fejlet test

Hvis et evalueringsresultat viser et fejlet testtilfælde, men ikke tydeligt identificerer kvalitetssignalet, skal du bruge evalueringssættet og bedømmelsesmetoden til at udlede signalet.

Eksempel:

• Evalueringssættet angiver kompetenceområdet, såsom sikkerhed, forankring eller værktøjsbrug.
• Bedømmelsesmetoden, såsom nøgleordsmatch eller rubrikbaseret scoring, giver mere kontekst.

At identificere det tilsigtede kvalitetssignal hjælper dig med at vælge de mest relevante diagnostiske spørgsmål.

Trin 1: Verificér evalueringsopsætningen

For hver fejl gennemgår du manuelt agentens faktiske svar sammen med forventet værdi og bedømmelsesmetoden.

Gennemgå de følgende spørgsmål i den angivne rækkefølge. Stop, når du når et resultat.

1. Er agentens svar acceptabelt? Ville en rigtig bruger være tilfreds med dette svar, selvom det ikke bestod evalueringen?

   • Hvis ja, er der en fejl i evalueringsopsætningen: graderen eller den forventede værdi er forkert.
   • Hvis nej, fortsæt til næste spørgsmål.

2. Er det forventede svar aktuelt og nøjagtigt i forhold til kilden?

   • Hvis ja, fortsæt til næste spørgsmål.
   • Hvis nej, er der et problem med evalueringsopsætningen: Det forventede svar er forældet eller forkert.

3. Afspejler testtilfældet realistisk brugerinput?

   • Hvis ja, fortsæt til næste spørgsmål.
   • Hvis Nej, er der et problem med evalueringsopsætningen: Testcasen er urealistisk.

4. Kan et rimeligt alternativt svar også være korrekt, men at bedømmeren ikke tillader det?

   • Hvis Ja, har evalueringsopsætningen et problem: Graderen er for stiv og tager ikke højde for gyldige variationer.
   • Hvis nej, fortsæt til næste spørgsmål.

5. Er evalueringsmetoden passende til det, du tester?

   • Hvis Ja, er evalueringen gyldig. Gå videre til trin 2: Diagnosticér agenten.
   • Hvis nej, er der et problem med evalueringsopsætningen: Evalueringsmetoden er ikke egnet til dette kvalitetssignal.

Vurdering af svaracceptabilitet

Brug følgende signaler til at vurdere, om agentens svar er acceptabelt:

• Samme nøglefakta, forskellig formulering → Ofte acceptabelt (vurderingspersonen kan være for streng).
• Manglende kritisk information fundet i kilden → ofte ikke acceptabelt.
• Uklar "god nok"-grænse → Acceptkriterier kan være uklare (markér til trin 4).

Er du i tvivl, så sammenlign indholdet med den oprindelige kilde frem for kun det forventede svar.

Disse signaler vejleder din dømmekraft, men kan ikke erstatte den.

Almindelige fejltyper i evalueringsopsætninger

Validering af bedømmer

Bedømmerens pålidelighed er en forudsætning for pålidelig fejltriage. Hvis selve bedømmeren er upålidelig, fejldiagnosticerer du hver fejl, den behandler.

For at validere graderens pålidelighed:

1. Vælg 5-10 testeksempler, hvor du kender det korrekte bestået/ikke bestået udfald fra manuel gennemgang.
2. Kør evalueringen og sammenlign graderens output med den manuelle vurdering.
3. Hvis graderen er uenig i mere end 20% af tilfældene, skal graderen rekalibreres, før agenten fejlfindes.

Tegn en grader kræver opmærksomhed:

• Den samme testsag giver forskellige afgørelser på tværs af kørsler.
• Fejl samler sig i evalueringssæt, der bruger modelbaseret bedømmelse, mens deterministiske metoder består.
• Graderen markerer problemer, som du ikke kan genskabe ved at gennemgå agentens svar.

Kalibreringsmuligheder for grader:

• Brug deterministiske metoder, hvor det er muligt.
• Tilføj eksplicitte "acceptable" og "ikke acceptable" eksempler til bedømmelsesvejledningen.
• Udvid nøgleordsættene til at inkludere synonymer og gyldige omformuleringer.
• Brug Sammenlign betydning i stedet for Nøgleord-match (Alle) til kontrol af semantisk ækvivalens.

Trin 2: Diagnosticér agenten

På dette tidspunkt er evalueringen gyldig, og agenten har givet et forkert svar. Diagnosticer hvad der gik galt i agentkonfigurationen.

Tjek for faktuel nøjagtighed og problemer med videnforankring

Tjek for fejl i værktøjsinvokation

Tjek for fejl i trigger-rutning

Kontrollér for fejl i tone- og svarkvalitet

Tjek for sikkerheds- og grænsefejl

Kontrollér, om der er eskalering og yndefuld fejl

Efter diagnosticering, kortlæg fejlmønstre til afhjælpningsstrategier efter rodårsag.

Trin 3: Identificer platformens begrænsninger

Hvis evalueringen er korrekt, og rimelige konfigurationsændringer ikke forbedrer resultaterne, kan problemet være en platformbegrænsning.

Platformbegrænsningsindikatorer

Handlingssti for platformbegrænsninger

1. Dokumentér begrænsningen klart (hvad der fejler, hvad du har forsøgt, og dokumentation for at det ikke skyldes konfiguration).
2. Anvend en workaround, når det er muligt (for eksempel omstrukturér kildedokumentet for at forbedre hentningen).
3. Markér testcasen som en kendt begrænsning, eller juster tærskelværdierne, så den ikke hindrer øvrig fremgang.
4. Eskaler med beviser til platformteamet.
5. Registrér elementet i fejlloggen til genvurdering, når platformens funktioner opdateres.

Efter klassificering, gennemgå vejledningen til workaround og eskalering for håndtering af platformbegrænsninger.

Når en fejl ikke passer ind i rammen

Nogle fejl kan ikke klart tilskrives én enkelt rodårsagstype. Som almindelige eksempler kan nævnes:

• Kvalitetsproblemer med backend-data: Videnskildeindholdet er teknisk korrekt, men formuleret tvetydigt, så hverken agenten eller evalueringen kan klandres.
• Intermitterende infrastrukturproblemer: Netværkstimeouts, API-hastighedsbegrænsning og connectorproblemer, der ikke reproduceres konsekvent.
• Ændringer i modelversion: agentens adfærd ændrede sig efter en opdatering af platformens model, som ikke var initieret af dig.
• Tvetydige testcases: Scenariet er tvetydigt, og fornuftige mennesker er uenige om det korrekte svar.

Anbefalet fremgangsmåde: Dokumentér det, du observerede (fejlen, agentens svar, hvad du undersøgte). Registrer elementet som "uklassificeret" i fejlloggen. Hvis fejlen gentager sig, bliver den ofte klassificeret med yderligere beviser.

Håndtering af sammensatte årsager

En enkelt fejl kan have flere medvirkende rodårsager. Eksempel:

• En nøjagtighedsfejl, hvor det forventede svar er en smule forældet (evalueringsopsætning), og videnskilden også er ufuldstændig (agentkonfiguration).
• En fejl i værktøjsaktivering, hvor værktøjsbeskrivelsen er tvetydig (agentkonfiguration), og orkestreringen ikke understøtter betingede værktøjskald (platformbegrænsning).

Anbefalet tilgang: Udfør den fulde triage for hver fejl. Hvis flere rodårsagstyper gælder, håndteres de i prioriteret rækkefølge:

1. Ret evalueringen først: for at få et klart signal om, hvorvidt ændringen af agenten faktisk hjælper.
2. Ret agentkonfigurationen for at afgøre, om den tilbageværende fejl faktisk er et platformproblem.
3. Dokumentér først platformbegrænsningen , når 1 og 2 er adresseret.

Genkør de berørte testtilfælde efter hver ændring, inden du fortsætter.

Håndtering af samtalefejl med flere sving

For scenarier med flere ture opstår fejl kun over sving.

Hvornår skal man mistænke et problem med flere ture

• Agenten svarer korrekt i de tidlige runder, men modsiger sig selv senere.
• Agenten mister kontekst fra et tidligere værktøjskald eller videnshentning i en senere runde.
• Timingen for eskalering giver kun mening, når den fulde samtalehistorik tages i betragtning.
• Agentens tone forringes gradvist, efterhånden som samtalen skrider frem.
• Agenten beder om information, som brugeren allerede har givet.

Yderligere diagnostiske spørgsmål

Afhjælpningsvejledning for multi-turn problemer

• Konteksttab: Kontroller samtalestatus-konfigurationen. Sørg for, at værktøjsoutput og nøglefakta vedvarer i samtalens omgange
• Modsigelser: Tilføj en instruktion om konsistens, for eksempel: "Vær konsekvent i forhold til dine tidligere svar i denne samtale."
• Gentager spørgsmål: Verificér platformens konfiguration af samtalehukommelsen.
• Forringelse ved lange samtaler: Overvej strategier for samtaleopsummering eller kontekstbeskæring.

Validering af beståelse af testcases (falsk positiv kontrol)

Denne ramme fokuserer på testcases, der fejler. Dog kan en testcase, der fejlagtigt består, skabe skjulte kvalitetsgab.

Anbefalet praksis: Gennemgå manuelt 5-10% af beståede testcases pr. evalueringskørsel, især for:

• Modelbaseret bedømmelse (højere risiko for falske positiver)
• Subjektive signaler (tone, hjælpsomhed)
• Testcases, der tidligere fejlede, men nu består efter en ændring

Hvis du finder falske positiver, kalibrer graderen.

Næste trin

Efter gennemførelse af fejltriage:

• Brug lag 3: Kortlæg fejlmønstre til afhjælpningsstrategier.
• Brug Lag 4: Analyser mønstre for at identificere systemiske problemer.
• Gennemgå praktiske eksempler , der demonstrerer, hvordan rammelagene arbejder sammen i virkelige scenarier.