Notitie
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen u aan te melden of de directory te wijzigen.
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen de mappen te wijzigen.
Nadat u individuele testcase-fouten hebt afgehandeld, kunt u oplossingen toepassen en toch weinig tot geen verbetering zien in de algehele prestaties van de agent. Dit resultaat wijst vaak op een systemisch probleem, niet op een verzameling van niet-gerelateerde fouten.
Patroonanalyse helpt om meerdere foutieve testcases te onderzoeken en terugkerende signalen en gemeenschappelijke hoofdoorzaken te identificeren. Gebruik patroonanalyse om u te richten op veranderingen die groepen fouten in één keer aanpakken, in plaats van elke fout afzonderlijk op te lossen.
Belangrijk
Gebruik deze richtlijn nadat u de foutsortering hebt afgerond en herstelmaatregelen heeft toegepast. Patroonanalyse is het nuttigst als u al minstens vijf storingen hebt gesorteerd.
Wanneer patroonanalyse te gebruiken
Patroonanalyse is het nuttigst wanneer u een of meer van de volgende omstandigheden waarneemt:
- Veel fouten in dezelfde evaluatieset.
- Herhaalde fouten met vergelijkbare symptomen.
- Verbeteringen in individuele testcases die de totale scores niet veranderen.
- Verbeteringen op het ene gebied die regressies veroorzaken in een ander gebied.
Het één voor één oplossen van fouten is in deze situaties inefficiënt. Patroonanalyse helpt bij het vaststellen van gemeenschappelijke kenmerken van fouten, zodat u de onderliggende oorzaak kunt aanpakken.
Concentratieanalyse
Nadat u individuele fouten hebt geclassificeerd, zoekt u naar patronen in de hele set.
| Patroon | Wat het aangeeft | Aanbevolen actie |
|---|---|---|
| 80% of meer fouten zijn problemen met in evaluatie-instellingen | De evaluatiesuite moet gekalibreerd worden, er zijn geen aanpassingen aan de agent nodig | Pauzeer de iteratie van de agent. Controleer en corrigeer eerst de evaluatiekwaliteit en voer daarna opnieuw uit om een zuiver signaal te krijgen. |
| 80% of meer fouten zijn problemen met agentconfiguratie binnen één domein (bijvoorbeeld allemaal kennisgerelateerd) | Systemisch hiaat in agentconfiguratie | Richt de herstelacties op dat gebied. Dit probleem is vaak een probleem in de architectuur (bijvoorbeeld de structuur van kennisbronnen), geen individuele testcase-oplossing. |
| 80% of meer fouten zijn platformbeperkingen | De agent bereikt de platformgrenzen | Herzie de scope van de agent. Escaleer naar het platformteam. Pas drempels aan of behandel getroffen items als bekende beperkingen waar dit van toepassing is. |
| Fouten zijn gelijkmatig verdeeld over verschillende typen hoofdoorzaken | Geen enkel systemisch probleem | Ga per geval verder met het herstelproces aan de hand van hersteltoewijzing. |
Een concentratieanalyse uitvoeren
Tel de geclassificeerde fouten per hoofdoorzaaktype:
- Problemen met evaluatie-instellingen
- Problemen bij agentconfiguratie
- Platformbeperkingen
- Ongeclassificeerd
Bereken het percentage voor elk type.
Als een enkel type 80% of hoger is, wat wijst op een systemisch probleem, los dan de categorie op, niet de individuele gevallen.
Als problemen met agentconfiguratie zich in één kwaliteitssignaal concentreren (bijvoorbeeld vijf van de zes zijn kennisonderbouwing), wijst dat patroon op een hoofdoorzaak in de architectuur.
Patronen tussen signalen
Wanneer fouten voorkomen in meerdere evaluatiesets, duidt dat vaak op een gemeenschappelijke oorzaak. Let op de volgende patronen:
| Patroon | Wat het waarschijnlijk aangeeft | Wat te onderzoeken |
|---|---|---|
| Zowel feitelijke nauwkeurigheid als kennisonderbouwing falen | Probleem met kennisbron (fout, ontbrekend, ontoegankelijk of verouderd) | Kennisconfiguratie, indexeringsstatus en actualiteit van de inhoud |
| Tool-aanroep en triggerroutering falen beide | Probleem met de Indelingsconfiguratie: onderwerpen en tools zijn niet goed verbonden | Bekijk hoe onderwerpen naar hulpprogramma's worden gerouteerd. Controleer op losgekoppelde of verkeerd geconfigureerde stromen |
| Toon is niet goed, de nauwkeurigheid is wel goed | De agent geeft het juiste antwoord, maar presenteert het op een slechte manier | Richt u op instructies voor de promptstijl; de nauwkeurigheidsinfrastructuur is in orde. |
| Veiligheid is goed, maar bij de nauwkeurigheid gaat het fout | De agent kan te beperkt zijn, te voorzichtig, weigert te antwoorden wanneer dat zou moeten | Bekijk veiligheidsinstructies voor te brede beperkingen die legitieme antwoorden blokkeren. |
| Alles wordt positief beoordeeld, behalve randgevallen | Het kerngedrag is stabiel | Focus op het vergroten van robuustheid aan de marges; dit patroon is een goed teken. |
| Nauwkeurigheid verbetert maar de toon verslechtert | Instructieconflict: nieuwe nauwkeurigheidsinstructies kunnen toonrichtlijnen verdringen | Bekijk recente wijzigingen in de prompt en houd het "instructiebudget" in gedachten. |
| Meerdere evaluatiesets verslechteren allemaal tegelijkertijd | Waarschijnlijk een enkele hoofdoorzaak met brede impact | Controleer op recente wijzigingen in systeemprompts, updates van kennisbronnen of updates van platformmodellen. |
Wat te doen met patronen tussen signalen?
- Identificeer de gedeelde hoofdoorzaak: als twee signalen allebei falen, delen ze waarschijnlijk een afhankelijkheid zoals een kennisbron, promptsectie of toolconfiguratie.
- Corrigeer de gedeelde afhankelijkheid: los niet elk signaal afzonderlijk op.
- Voer beide evaluatiesets opnieuw uit: controleer na de oplossing of beide sets verbeteren.
- Als er maar één verbetert, delen de signalen eigenlijk geen hoofdoorzaak. Sorteer de resterende fouten los van elkaar.
Trendanalyse voor verschillende iteraties
Volg hoe scores veranderen gedurende de iteratiecycli om te beoordelen of uw herstelstrategie effectief is.
| Trend | Interpretatie | Actie |
|---|---|---|
| Scores verbeteren in meerdere iteraties | Herstelacties werken | Ga door tot de drempelwaarden zijn bereikt. |
| Scores onveranderd ondanks wijzigingen | Herstel richt zich niet op de echte hoofdoorzaak | Sorteer opnieuw, de classificatie van de hoofdoorzaak kan onjuist zijn. |
| Scores gaan omlaag na een verandering | Regressie, de wijziging heeft iets verstoord | Draai de wijziging terug. Onderzoek wat er is achteruitgegaan en waarom. |
| De ene evaluatieset verbetert, de andere verslechtert | Afweging: het verbeteren van de ene dimensie schaadt de andere | Onderzoek koppeling, vaak veroorzaakt door instructieconflicten (zie Beleving 3). |
| Scores fluctueren tussen uitvoeringen (afwijking van meer dan 10%) | Instabiliteit van beoordelaar of non-determinisme van de agent | Valideer eerst de betrouwbaarheid van de beoordelaar (zie Validatie van beoordelaar). Herhaal de evaluatie minimaal drie keer per iteratie. |
Een trendweergave opbouwen
Leg na elke iteratie het volgende vast:
- Datum
- Wijziging aangebracht
- Evaluatieset
- Score voor
- Score na
- Delta
Met deze informatie kunt u:
- Bevestigen dat u naar de drempelwaarden toe beweegt
- Snel regressies identificeren
- Detecteer stabilisaties tijdig (Beleving 2)
Fouten documenteren
Gestructureerde foutregistraties dragen bij aan institutionele kennis van iteratiecycli. Zonder documentatie herhalen teams vaak hetzelfde onderzoekswerk.
Het belang van fouten documenteren
- Versnel toekomstige sortering: u herkent direct bekende foutpatronen.
- Bouw escalatiebewijs op: verzamel records over platformbeperkingen om sterkere argumenten voor het platformteam te hebben.
- Bevorder teamleren: met het logboek kunt u dubbele onderzoeken voorkomen wanneer meerdere mensen aan dezelfde agent werken.
- Registreer bekende tekortkomingen: vergeet niet om fouten te registreren die zijn geclassificeerd als "wordt niet opgelost" of "bekende beperking."
Gebruik het logboeksjabloon voor fouten
Gebruik het logboeksjabloon voor fouten om fouten vast te leggen in een lichtgewicht of gedetailleerd formaat, afhankelijk van teamgrootte en proceslooptijd.
Wat moet u vastleggen
Verzamel minimaal de volgende informatie voor elke gesorteerde fout:
- Welke testcase er fout ging.
- Als welk type hoofdoorzaak u het heeft geclassificeerd.
- Wat er precies misging.
- Wat u hebt aangepast om het op te lossen.
- Of de oplossing heeft gewerkt.
Noteer ook het volgende voor onopgeloste fouten:
- Wat u tot nu toe geprobeerd hebt.
- Waarom het onopgelost blijft.
- Wanneer het opnieuw moet worden geëvalueerd: (bijvoorbeeld "na platformupdate X")
Werkstroom voor continue verbetering
Gebruik deze checklist na elke sorterings- en herstelcyclus om te bevestigen dat u de uitkomsten en volgende stappen hebt vastgelegd.
Checklist na de iteratie
| Gereed? | Task |
|---|---|
| ✓ | Registreer alle gesorteerde fouten in het foutlogboek. |
| ✓ | Identificeer en noteer concentraties van hoofdoorzaken. |
| ✓ | Controleer patronen tussen signalen. |
| ✓ | Noteer scores voor trendbewaking. |
| ✓ | Documenteer bekende beperkingen met workarounds. |
| ✓ | Bepaal de prioriteiten voor de volgende iteratie op basis van de resterende fouten. |
| ✓ | Stel het schema voor opnieuw uitvoeren in (welke evaluatiesets, wanneer). |
Wanneer u kunt stoppen met itereren
Stop met itereren wanneer:
- Alle evaluatiesets liggen boven de drempelwaarden.
- U bekende hiaten hebt gedocumenteerd.
- De scores consistent (< 5% variantie) zijn.
- Er geen open problemen met agentconfiguratie zijn die signalen blokkeren.
Stop niet met itereren als:
- U geen aanhoudende fouten hebt onderzocht.
- U hebt uitdagende testcases verwijderd om aan de drempelwaarden te voldoen.
- U de beperkingen van het platform niet hebt gedocumenteerd.
Lees meer informatie in Bepalen wanneer de iteratie is voltooid is.
Volgende stappen
- Beoordeel praktische voorbeelden die tonen hoe de lagen van het kader samen functioneren in praktijksituaties.
- Gebruik de foutenlogboeksjabloon om uw bevindingen bij te houden.