Lager 2: Prioritera agentfel

Efter att du tolkat utvärderingspoäng och identifierat fokusområden, avgör varför enskilda testfall misslyckades och vem som behöver agera.

Denna artikel ger strukturerad vägledning för att diagnostisera fel på testfallsnivå. Det hjälper dig att klassificera grundorsaken, skilja mellan agent-, utvärderings- och infrastrukturproblem och välja lämplig nästa åtgärd.

Innan du börjar

Innan du påbörjar prioritering av misslyckanden:

  1. Slutför poängtolkning och beredskapsbedömning och identifiera vilka utvärderingsset som kräver uppmärksamhet.
  2. Fokusera på de högst prioriterade felen baserat på beredskap och risk.

Viktigt

Om du hoppar över detta steg riskerar du att slösa tid på problem med låg påverkan eller problem som inte blockerar.

Kontroll före triage: Verifiera infrastrukturens hälsa:

Innan du diagnostiserar individuella fel, kontrollera att beroendena fungerade under utvärderingskörningen. Infrastrukturproblem kan orsaka fel som liknar agent- eller utvärderingsproblem, men som inte har någon koppling till dessa.

Kontrollera följande villkor:

  • Kunskapskällor är tillgängliga och helt indexerade.
  • API-serverdelar eller anslutningsprogram returnerar inte fel, tidsgränser eller kvotbegränsningssvar.
  • Autentiseringstoken är giltiga under hela utvärderingskörningen.
  • Utvärderingsmiljön matchar den avsedda agentkonfigurationen.

Om ett beroende är felaktigt korrigerar du problemet och kör utvärderingen igen innan du fortsätter. Att prioritera resultat från en misslyckad körning kan leda till felaktiga slutsatser.

Steg 0: Prioritera misslyckanden

Innan du prioriterar enskilda testfall, bestäm var du ska fokusera först.

Prioritera misslyckanden i denna ordning:

Prioritet Prioritera först Logisk grund
1 Säkerhets- och efterlevnadsfel Störst konsekvens. Åtgärda dessa fel innan distribution.
2 Misslyckanden i kärnaffärsscenarier Direkt påverkan på agentens värdeerbjudande.
3 Misslyckanden i utvärderingsuppsättningen med lägst poäng Troligen systemomfattande. Att åtgärda grundorsaken kan lösa flera fel.
4 Återkommande fel i flera körningar Konsekventa fel är lättare att diagnostisera.
5 Funktionsscenariofel Viktigt, men vanligtvis med mindre påverkan.

Om du har många misslyckanden (till exempel fler än 15), prioritera inte varje misslyckande individuellt. Börja med den utvärderingsuppsättning som har lägst poäng och granska manuellt några misslyckanden. Om de delar en rotorsak kan åtgärdandet lösa många fel på en gång.

Identifiera kvalitetssignalen för ett misslyckat test

Om ett utvärderingsresultat visar ett misslyckat testfall men inte tydligt anger kvalitetssignalen använder du utvärderingsuppsättningen och bedömningsmetoden för att avgöra vilken signal det gäller.

Till exempel:

  • Utvärderingsuppsättningen anger förmågeområdet, såsom säkerhet, faktagrund eller verktygsanvändning.
  • Betygsmetoden, såsom nyckelordsmatchning eller bedömningsmatrisbaserad poängsättning, ger mer kontext.

Genom att identifiera den avsedda kvalitetssignalen kan du välja de mest relevanta diagnostiska frågorna.

Steg 1: Verifiera utvärderingsuppsättningen

Viktigt

Börja alltid här. Innan du undersöker agenten, kontrollera att utvärderingsupplägget är korrekt.

För varje fel, granska manuellt agentens faktiska svar tillsammans med det förväntade värdet och betygsmetoden.

Gå igenom följande frågor i ordning. Avbryt när du når ett resultat.

  1. Är agentens svar acceptabelt? Skulle en verklig användare vara nöjd med detta svar, även om det inte klarade utvärderingen?

    • Om Ja har utvärderingskonfigurationen ett problem: Antingen är bedömaren eller det förväntade värdet fel.
    • Om nej, fortsätt till nästa fråga.
  2. Är det förväntade svaret aktuellt och korrekt jämfört med källan?

    • Om ja, fortsätt till nästa fråga.
    • Om Nej finns det ett problem med utvärderingskonfigurationen: Det förväntade svaret är inaktuellt eller felaktigt.
  3. Återspeglar testfallet realistisk användarinmatning?

    • Om ja, fortsätt till nästa fråga.
    • Om nej, har utvärderingsupplägget ett problem: Testfallet är orealistiskt.
  4. Kan ett rimligt alternativt svar också vara korrekt, men bedömaren tillåter det inte?

    • Om ja, har utvärderingsupplägget ett problem: Bedömaren är för stel och tar inte hänsyn till giltiga variationer.
    • Om nej, fortsätt till nästa fråga.
  5. Är utvärderingsmetoden lämplig för det du testar?

    • Om ja, är utvärderingen giltig. Gå vidare till steg 2: Diagnostisera agenten.
    • Om nej, finns det ett problem med utvärderingsuppsättningen: Utvärderingsmetoden är inte lämplig för denna kvalitetssignal.

Bedömning av acceptans av agentens svar

Använd följande signaler för att avgöra om agentens svar är acceptabelt:

  • Samma viktiga fakta, olika formuleringar → Ofta acceptabelt (bedömaren kan vara för strikt).
  • Kritisk information som finns i källan men saknas i svaret → Ofta inte acceptabelt.
  • Otydlig "tillräckligt bra"-tröskel → acceptanskriterier kan vara otydliga (flagga för steg 4).

Om du är osäker, jämför innehållet med den ursprungliga källan, inte bara det förväntade svaret.

Dessa signaler vägleder ditt omdöme, men ersätter det inte.

Vanliga feltyper vid utvärderingsuppställningar

Feltyp beskrivning Exempel
Föråldrat förväntat svar Källinnehållet har ändrats men det förväntade värdet har inte uppdaterats Policyn har uppdaterats till 15 dagar, men utvärderingen förväntar sig fortfarande "30-dagars returfönster."
Alltför strikt bedömare Nyckelordsmatchning misslyckas för en giltig synonym eller omformulering Förväntat svar: "kallt vatten." agentens svar: "svalt vatten, 30 °C," vilket är semantiskt korrekt.
Orealistiskt testfall Testscenariot återspeglar inte det faktiska användarbeteendet Testar en fyrstyckesfråga när riktiga användare skriver 5–10 ord.
Felaktig utvärderingsmetod Utvärderingsmetoden stämmer inte överens med det du faktiskt testar. Använder Nyckelordsmatchning (Alla) för en syntesfråga där Jämför betydelse är lämpligt.
Faktiskt fel för bedömare Språkmodell-som-domare uppfinner en felorsak som inte är verklig (isolerat fel) Språkmodellbedömare säger "svaret nämner inte returpolicyn" när det tydligt gör det.
Systematisk snedvridning för bedömare Språkmodell-som-domare tillämpar en inkonsekvent standard över testkörningar (kalibreringsproblem) Bedömaren accepterar korta svar men misslyckas med längre för samma kvalitetssignal, oavsett innehåll.
Tvetydiga acceptanskriterier Förväntat värde kan tolkas på flera sätt Bör inkludera prisinformation. Månadsvis? Årlig? Per användare?

Validering av bedömare

Bedömarens tillförlitlighet är en förutsättning för tillförlitlig prioritering. Om själva bedömningsverktyget är opålitligt, feldiagnostiserar du varje fel som det är involverat i.

För att validera graders tillförlitlighet:

  1. Välj 5–10 testfall där du vet det korrekta utfallet (godkänt eller underkänt) från manuell granskning.
  2. Kör utvärderingen och jämför bedömarens utdata med det manuella utfallet.
  3. Om bedömaren inte håller med i mer än 20 % av fallen, ska du omkalibrera bedömaren innan du felsöker agenten.

Tecken på att en bedömare behöver uppmärksamhet:

  • Samma testfall ger olika bedömningar över flera körningar.
  • Fel samlas i utvärderingsuppsättningar som använder modellbaserad klassificering medan deterministiska metoder godkänns.
  • Bedömare flaggar problem som du inte kan återskapa genom att granska agentens svar.

Omkalibreringsalternativ för bedömare:

  • Använd deterministiska metoder där det är möjligt.
  • Lägg till explicita exempel som "acceptabelt" och "inte acceptabelt" i bedömningsmatrisen.
  • Bredda nyckelordsuppsättningarna till att inkludera synonymer och giltiga omformuleringar.
  • Använd Jämför betydelse istället för Nyckelordsmatchning (Alla) för semantiska ekvivalenskontroller.

Steg 2: Diagnostisera agenten

Vid denna punkt är utvärderingen giltig och agenten gav ett felaktigt svar. Diagnostisera vad som gick fel i agentkonfigurationen.

Dricks

Vissa diagnostiska frågor kräver översikt över agentens interna processer (till exempel vilken kunskapskälla som hämtats, vilket verktyg som använts eller vilket ämne som triggats). Använd spårloggar, transkriptioner av konversationer eller testanalyser om de är tillgängliga. Om din plattform inte visar dessa detaljer, dra slutsatser från svaret (till exempel, innehåll som endast förekommer i Källa A kommer sannolikt från Källa A).

Kontrollera om det finns brister i den faktamässiga korrektheten och kunskapsgrundningen

Question Om ja → grundorsak
Hämtade agenten från fel kunskapskälla? Konfiguration av kunskapskällan. Fel källa, indexerad eller prioriterad.
Hämtade agenten rätt källa men extraherade fel information? Prompt- eller instruktionslucka. Modellen behöver vägledning för extraktion.
Är själva källinnehållet felaktigt eller föråldrat? Kunskapskällans innehåll. Uppdatera källdokumentet.
Svarade agenten utan att använda någon kunskapskälla (hittade på ett svar)? Källans tillgänglighet. Källan är inte indexerad, eller så stämmer frågeformuleringen inte överens med källvokabulären.
Motsade agenten informationen som finns i källan? Felaktig information. Lägg till explicit förankringsinstruktion.

Kontrollera verktygsanropsfel

Question Om ja → grundorsak
Utlöstes fel verktyg? Tvetydighet i verktygsbeskrivning. Verktygens beskrivningar överlappar.
Utlöstes rätt verktyg med fel parametrar? Parameterdefinition. Schemat eller beskrivningen är oklar.
Utlöstes verktyget inte alls? Utlösande villkor. Indata uppfyller inte anropskriterierna.
Utlöstes verktyget när det inte borde ha gjort det? Negativ skyddsmekanism saknas. Ingen instruktion för när verktyget inte ska anropas.
Utfördes verktyget korrekt men hanterades utdata felaktigt i svaret? Svarsinstruktioner. Agenten behöver vägledning om formateringsverktygets utdata.
Aktiverades verktyget korrekt men inträffade ett fel i verktyget självt (fel, timeout, felaktig data)? Verktygs- eller integrationsproblem; felet ligger i backend-systemet, inte i agenten. Åtgärda verktyget, inte agenten.

Sök efter dirigeringsfel för utlösare

Question Om ja → grundorsak
Utlöstes fel ämne? Överlappning av ämnesutlösare. Utlösare är otydliga mellan ämnena.
Utlöstes inget ämne (träffade reserven)? Ämnestäckningslucka. Inget ämne hanterar denna inmatningstyp.
Matchade flera ämnen med fel förvrängning? Logik för att lösa tvetydighet. Prioritets- eller förtydligandeflödet felkonfigurerat.

Kontrollera om ton- och svarskvaliteten brister

Question Om ja → grundorsak
Är agentens ton inkonsekvent med systempromptens vägledning? Brist på toninstruktion. Lös saknade eller motsägelsefulla riktlinjer.
Är svaret för utförligt eller för kortfattat i förhållande till frågan? Formatanvisningar. Lägg till vägledning om längd eller struktur.
Saknar agenten empati i känsliga sammanhang? Saknad vägledning om empati. Lägg till explicit vägledning för emotionella inmatningar.
Är svaret strukturellt dåligt (textvägg, inga steg)? Formatanvisningar. Lägg till formateringskrav.

Kontrollera för säkerhets- och gränsfel

Question Om ja → grundorsak
Avslöjade agenten systeminformation? Systempromptskydd. Lägg till instruktioner om "avslöja ej".
Gick agenten utanför sin definierade ram? Brist i definitionen av omfattningen. Tydliggör gränsdragningen.
Gick agenten med på promptinjektion? Säkerhetsanvisningar. Lägg till vägledning för motstånd mot motstånd.
Hanterade agenten personuppgifter felaktigt? Regler för hantering av personuppgifter. Lägg till instruktioner för dataskydd.

Sök efter eskalering och smidig felhantering

Question Om ja → grundorsak
Misslyckades agenten med att eskalera när den borde ha gjort det? Eskaleringsutlösare. Kriterier är inte definierade eller för snäva.
Eskalerade agenten för tidigt? Eskaleringströskel. Kriterierna är för känsliga.
Förlorade eskaleringen samtalets kontext? Överlämningskonfiguration. Bevarande av kontext är inte konfigurerat.
Hamnade agenten i en loop i stället för att erkänna ett misslyckande? Reservlogik. Försöksgräns eller reservbeteende är inte konfigurerat.

När du har diagnostiserat ska du mappa felmönster till åtgärdsstrategier utifrån rotorsak.

Steg 3: Identifiera plattformens begränsningar

Om utvärderingen är korrekt och rimliga konfigurationsändringar inte förbättrar resultaten, kan problemet vara en plattformsbegränsning.

Indikatorer för plattformsbegränsningar

Indikator Vad det antyder
Samma fel kvarstår trots flera olika varianter av prompt och konfiguration Inte ett konfigurationsproblem
Hämtning hämtar konsekvent fel dokument trots korrekt konfigurerad källa. Begränsning i hämtningens rankning
agent kan inte genomföra det nödvändiga resonemanget trots tydliga instruktioner Modellens förmågegräns
Det krävda orkestreringsmönstret stöds inte av någon konfigurationsinställning. Orkestreringslogikens begränsning
Modellbaserad graderare felklassificerar konsekvent trots bedömningsmatrisjustering Gradermodellens begränsning

Åtgärdsplan för plattformsbegränsningar

  1. Dokumentera begränsningen tydligt (vad som misslyckas, vad du har försökt och ge underlag för att det inte är konfigurationsrelaterat).
  2. Tillämpa en tillfällig lösning när det är möjligt (till exempel omstrukturera källdokumentet för att förbättra hämtningen).
  3. Markera testfallet som en känd begränsning eller justera tröskelvärden så att det inte hindrar framsteg på andra områden.
  4. Eskalera med bevis till plattformsteamet.
  5. Spåra objektet i felloggen för omvärdering när plattformens kapabiliteter uppdateras.

När du har klassificerat, läs igenom vägledningen för lösningar och eskalering för att reagera på plattformsbegränsningar.

När ett fel inte passar in i ramverket

Vissa fel mappas inte tydligt till en enda rotorsakstyp. Vanliga exempel:

  • Problem med kvaliteten på backenddata: Kunskapskällans innehåll är tekniskt korrekt men tvetydigt skrivet, så varken agenten eller utvärderingen är fel.
  • Intermittenta infrastrukturproblem: Nätverkstidsgränser, API-hastighetsbegränsningar och anslutningsprogramsproblem som inte reproduceras konsekvent.
  • Modellversionsändringar: Agentens beteende förändrades efter en plattformsmodelluppdatering som du inte initierade.
  • Tvetydiga testfall: Scenariot är tvetydigt, och rimliga personer är oense om det rätta svaret.

Föreslaget tillvägagångssätt: Dokumentera vad du observerade (felet, agentens svar, vad du kontrollerade). Registrera posten som "oklassificerad" i felloggen. Om felet återkommer kan det ofta klassificeras med ytterligare bevis.

Orsaker till hantering av föreningar

Ett enda fel kan ha flera bidragande orsaker. Till exempel:

  • Ett fel i faktanoggrannheten där det förväntade svaret är något föråldrat (utvärderingsinställning) och kunskapskällan också är ofullständig (agentkonfiguration).
  • Ett verktygsanropsfel där verktygsbeskrivningen är tvetydig (agentkonfiguration) och orkestreringen inte stöder villkorliga verktygsanrop (plattformbegränsning).

Föreslagen metod: Genomför en fullständig felsökning för varje fel. Om flera rotorsakstyper gäller kan du åtgärda dem i prioritetsordning:

  1. Åtgärda utvärderingen först för att få en tydlig signal om agentändringen faktiskt hjälper.
  2. Åtgärda agentkonfigurationen för att avgöra om det kvarvarande felet verkligen är ett plattformsproblem.
  3. Dokumentera plattformsbegränsningen först efter att 1 och 2 har åtgärdats.

Kör om påverkade testfall efter varje ändring innan du fortsätter.

Hantera fel i konversationer i flera vändor

I flerstegs-scenarier visar sig fel endast mellan olika turer.

När du ska misstänka ett problem med flera vändor

  • Agenten svarar rätt i de tidiga omgångarna men motsäger sig själv senare.
  • Agenten förlorar kontext från ett tidigare verktygsanrop eller kunskapsinhämtning i en senare tur.
  • Eskaleringstidpunkten är bara meningsfull när hela konversationshistoriken tas i beaktande.
  • Agentens ton försämras successivt ju längre samtalet går.
  • Agenten ber om information som användaren redan lämnat.

Dricks

Ett fel kan uppstå i en senare vända, medan rotorsaken uppträder tidigare. Spåra tillbaka för att identifiera den första omgången där samtalet började avvika.

Ytterligare diagnostiska frågor

Question Om ja → grundorsak
Berodde misslyckandet på information från en tidigare samtalsvändning som förlorats? Problem med kontexthantering; samtalstillståndet bevaras inte mellan samtalsvändningarna.
Motsade agenten något som den sa i en tidigare vända? Konsistens och vägledningsgap; ingen instruktion för att upprätthålla sammanhang över turer.
Bad agenten igen om information som användaren redan lämnat? Problem med kontexthämtning; agenten refererar inte till tidigare samtalsvändningar.
Visade sig problemet först efter många konversationsturer (5+)? Effektiv kontextlängd överskriden.

Reparationsvägledning för problem med flera vändor

  • Kontextförlust: Kontrollera konversationens tillståndskonfiguration. Säkerställ att verktygsresultat och nyckelfakta förblir tillgängliga under hela konversationen.
  • Motsägelser: Lägg till konsekvensinstruktion, till exempel: "Var konsekvent med dina tidigare svar i denna konversation."
  • Omfråga: Verifiera plattformens konfiguration av konversationsminne.
  • Försämring vid långvarig konversation: Överväg konversationssammanfattning eller strategier för kontextrensning.

Validering av godkända testkörningar (kontroll av falsklarm)

Denna ram fokuserar på att misslyckas med testfall. Men ett testfall som godkänns felaktigt kan skapa dolda kvalitetsbrister.

Rekommenderad praxis: Granska manuellt 5–10 % av godkända testfall per utvärderingsrunda, särskilt för:

  • Modellbaserad gradering (högre risk för falska positiva resultat)
  • Subjektiva signaler (ton, hjälpsamhet)
  • Tidigare underkända testfall som nu godkänns efter en förändring

Om du hittar falsklarm ska du kalibrera bedömningssystemet.

Nästa steg

När du har prioriterat felet: