Lager 4: Analysera mönster och förbättra agenten kontinuerligt

Efter att du har prioriterat individuella testfallsfel kan du genomföra förbättringar och ändå se liten eller ingen förbättring i agentens övergripande prestanda. Detta resultat tyder ofta på ett systemiskt problem, snarare än en samling orelaterade fel.

Mönsteranalys hjälper dig att titta på flera felaktiga testkörningar för att identifiera återkommande signaler och gemensamma rotorsaker. Använd mönsteranalys för att fokusera på förändringar som åtgärdar grupper av fel på en gång istället för att åtgärda varje fel var för sig.

Viktigt

Följ denna vägledning efter att du har slutfört triagering av fel och tillämpat korrigerande åtgärder. Mönsteranalys är mest användbar efter att du har triagerat minst fem fel.

När mönsteranalys ska användas

Mönsteranalys är mest användbar när du observerar ett eller flera av följande tillstånd:

  • Många fel i samma utvärderingsuppsättning.
  • Upprepade fel med liknande symptom.
  • Förbättringar av enskilda testfall som inte påverkar det totala resultatet.
  • Förbättringar inom ett område som orsakar regressioner i ett annat.

Att åtgärda fel en efter en är ineffektivt i dessa situationer. Mönsteranalys hjälper dig att identifiera gemensamma nämnare hos felen så att du kan åtgärda grundorsaken.

Koncentrationsanalys

Efter att du har klassificerat varje misslyckande, leta efter mönster i hela mängden.

Mönster Vad det tyder på Rekommenderad åtgärd
80 % eller fler fel är problem med utvärderingsinställningen Utvärderingssviten behöver kalibreras, inte agentändringar Pausa agentens iteration. Granska och åtgärda utvärderingskvaliteten först, kör sedan om för att få ren signal.
80 % eller fler fel är agentkonfigurationsproblem inom en kategori (exempelvis alla kunskapsrelaterade) Systemisk brist i agentkonfiguration Fokusera åtgärderna på det området. Detta problem är ofta en arkitektonisk fråga (till exempel kunskapskällsstruktur), inte lösningar för enskilda testfall.
80 % eller fler fel är plattformsbegränsningar Agenten når plattformens gränser Omvärdera agentens omfattning. Skicka vidare till plattformsteamet. Justera tröskelvärden eller behandla påverkade poster som kända begränsningar där det är lämpligt.
Fel fördelas jämnt över grundorsakstyper Inget enskilt systemiskt problem Fortsätt med åtgärder fall för fall med hjälp av åtgärdsmappning.

Så här gör du en koncentrationsanalys

  1. Räkna dina klassificerade fel efter rotorsakstyp:

    • Problem med utvärderingsupplägg
    • Problem med agentkonfigurationen
    • Plattformsbegränsningar
    • Oklassificerade
  2. Beräkna procentandelen för varje typ.

  3. Om någon enskild typ är 80 % eller högre – vilket indikerar ett systemiskt problem – åtgärda kategorin, inte enskilda fall.

  4. Om agentkonfigurationsproblem är koncentrerade kring en kvalitetssignal (till exempel om fem av sex gäller kunskapsgrundning), pekar detta mönster på en arkitektonisk grundorsak.

Korssignalmönster

När fel förekommer i flera utvärderingsuppsättningar tyder det ofta på en gemensam grundorsak. Leta efter följande mönster:

Mönster Vad det sannolikt indikerar Vad ska undersökas
Både faktanoggrannhet och kunskapsförankring misslyckas Problem med kunskapskällan (fel, saknas, otillgänglig eller föråldrad) Kunskapskonfiguration, indexeringsstatus och innehållsfärskhet
Både verktygsanrop och routning av utlösare misslyckas. Problem med orkestreringskonfiguration – ämnen och verktyg är inte korrekt kopplade Gå igenom hur ämnen leder till verktyg. Kontrollera om det finns flöden som är frånkopplade eller felkonfigurerade.
Tonen misslyckas men noggrannheten godkänns Agenten får rätt svar men presenterar det dåligt Fokusera på instruktioner för promptformat, infrastrukturen för noggrannhet är OK.
Säkerheten godkänns men korrektheten underkänns Agenten kan vara överbegränsad – för försiktig, vägrar svara när den ska Gå igenom säkerhetsinstruktionerna för att identifiera alltför breda restriktioner som blockerar legitima svar.
Allt som passerar utom undantagsfall Kärnbeteendet är stabilt Fokusera på att öka robustheten vid marginalerna; Detta mönster är ett gott tecken.
Noggrannheten förbättras men tonen försämras Instruktionskonflikt – nya noggrannhetsinstruktioner kan tränga undan tonvägledning Gå igenom de senaste promptändringarna och ha "instruktionsbudgeten" i åtanke.
Flera utvärderingsuppsättningar försämras samtidigt Troligen en enda grundorsak med bred påverkan Se över om det har gjorts några ändringar i systemprompten, kunskapskällorna eller plattformmodellens uppdateringar.

Vad man ska göra med korssignalmönster

  1. Identifiera den gemensamma rotorsaken: Om två signaler misslyckas tillsammans delar de sannolikt ett beroende, till exempel en kunskapskälla, ett promptavsnitt eller en verktygskonfiguration.
  2. Åtgärda det gemensamma beroendet: åtgärda inte varje signal var för sig.
  3. Kör om båda utvärderingsuppsättningar: Efter åtgärden, bekräfta att båda har förbättrats.
  4. Om bara en förbättras, har signalerna egentligen ingen gemensam grundorsak. Prioritera de återstående felen oberoende.

Trendanalys över iterationscykler

Följ hur poängen förändras under dina iterationscykler för att förstå om din åtgärdsstrategi fungerar.

Trend Tolkning Åtgärd
Poängen förbättras över iterationscykler Reparationen fungerar Fortsätt tills tröskelvärden har nåtts.
Poängen är oförändrad trots förändringar Reparationen riktar sig inte mot den verkliga rotorsaken Prioritera på nytt. Rotorsaksklassificeringen kan vara felaktig.
Poängen försämras efter en förändring Regression – ändringen bröt något Rulla tillbaka ändringen. Undersök vad som försämrades och varför.
En utvärderingsuppsättning förbättras, en annan försämras Avvägning – att förbättra en dimension försämrade en annan Undersök koppling, ofta orsakad av instruktionskonflikt (se Journey 3).
Poäng fluktuerar mellan körningar (mer än +/-10 % varians) Bedömarens instabilitet eller icke-determinism hos agent Validera bedömarens tillförlitlighet först (se Gradervalidering). Kör minst tre gånger per iteration.

Skapa en trendvy

Efter varje iteration, anteckna:

  • Datum
  • Utförd ändring
  • Utvärderingsuppsättning
  • Poäng före
  • Poäng efter
  • Delta

Den här informationen hjälper dig att:

  • Bekräfta att du närmar dig trösklar
  • Identifiera regressioner snabbt
  • Upptäck platåer tidigt (Resa 2)

Dokumentera fel

Strukturerade felregister bygger institutionell kunskap över iterationscykler. Utan dokumentation upprepar team ofta samma utredningsarbete.

Varför dokumentera fel

  • Snabba upp framtida prioritering: Du känner omedelbart igen kända felmönster.
  • Skapa eskaleringsbevis: Samla in poster över plattformens begränsningar för att skapa starkare argument till plattformsteamet.
  • Möjliggör teamlärande: Loggen hjälper till att undvika dubbla utredningar när flera personer arbetar på samma agent.
  • Spåra kända luckor: Glöm inte att spåra fel klassificerade som "kommer inte att åtgärdas" eller "känd begränsning."

Använd felloggs­mallen

Använd felloggsmallen för att registrera fel i ett enkelt eller detaljerat format, beroende på teamstorlek och processmognad.

Vad ska registreras

Samla minst in följande information för varje prioriterat fel:

  1. Vilket testfall misslyckades.
  2. Vilken typ av rotorsak du klassificerade det som.
  3. Vad gick fel specifikt.
  4. Vad du ändrat för att åtgärda det.
  5. Om lösningen fungerade.

För olösta fel, dokumentera även:

  • Det du har försökt hittills.
  • Varför det fortfarande är olöst.
  • Tidpunkt för omvärdering (till exempel "efter plattformsuppdatering X")

Arbetsflöde för kontinuerlig förbättring

Använd denna checklista efter varje prioriterings- och åtgärdscykel för att bekräfta att du har dokumenterat resultaten och nästa steg.

Checklista efter iteration

Klar? Uppgift
Registrera alla prioriterade fel i felloggen.
Identifiera och notera rotorsakskoncentrationer.
Granska mönster mellan signaler.
Registrera poäng för trenduppföljning.
Dokumentera kända begränsningar med tillfälliga lösningar.
Identifiera prioriteringar för nästa iteration baserat på kvarvarande misslyckanden.
Ange schema för ny körning (vilka utvärderingsuppsättningar, när).

När man ska sluta iterera

Sluta iterera när:

  • Alla utvärderingsuppsättningar är över tröskelvärdena.
  • Du har dokumenterat kända luckor.
  • Poängen är konsekventa (< 5 % varians).
  • Inga öppna konfigurationsproblem för agenten gällande blockerande signaler.

Sluta inte iterera när:

  • Du undersökte inte kvarstående fel.
  • Du tog bort svåra testfall för att nå gränsvärden.
  • Du dokumenterade inte plattformsbegränsningar.

Läs mer i Bestäm när iterationen är klar.

Nästa steg

  • Granska praktiska exempel som visar hur ramverkslagren samverkar i verkliga scenarier.
  • Använd mallen för fellogg för att följa dina resultat.