Overvåk evalueringsfeilene med strukturerte loggingsmaler

Dokumentering av evalueringsfeil bygger institusjonell kunnskap som akselererer fremtidige triage-økter. Når du støter på samme type feil på nytt, vet du allerede hva du skal sjekke først i stedet for å gjenoppdage de samme grunnårsakene.

Bruk disse strukturerte malene til å registrere feilanalyse fra triage-øktene. Velg versjonen som passer teamets behov og arbeidsflyt.

Viktig!

Fullfør feiltriage først. Dokumentfeil når du diagnostiserer dem.

Velg malversjonen som passer til teamet:

  • Lett versjon for små team som iterer på én enkelt agent
  • Detaljert versjon for større team eller når du bygger institusjonell kunnskap på tvers av agenter

Logg for lett feil

Den enkle feilloggen er ment for små team eller raske prioriteringsøkter.

Kopier denne tabellen, og fyll den ut under triage-økter. Legg til én rad per feil.

Testtilfelle Grunnårsakstype Problem observert Endring brukt Løst
___ Evalueringsoppsett, agentkonfigurasjon eller plattformbegrensning ___ ___ Ja / Nei / Delvis
___ ___ ___ ___ ___
___ ___ ___ ___ ___

Eksempel (fylt ut)

Testtilfelle Grunnårsakstype Problem observert Endring brukt Løst
KG-003 Evalueringsoppsett Forventet svar utdatert (gammel returpolicy – 30 dager, gjeldende policy er 15 virkedager) Oppdatert forventet verdi til 15 virkedager Ja
KG-005 Agentkonfigurasjon Agenten har gitt garantidetaljer som ikke finnes i noen kunnskapskilde Lagt til forankringsinstruksjon: «Bare svar fra kunnskapskilder» Ja
TI-002 Plattformbegrensning Hentingsrangering ignorerer nøyaktig dokumenttittel. Vanlige spørsmål som alltid hentes i stedet for produkthåndbok Omstrukturerte dokumentoverskrifter som midlertidig løsning. eskalert til plattformteam Partial
FA-019 Plattformbegrensning Tvetydig spørring kan ikke hente riktig kilde på en pålitelig måte Dokumentert som kjent begrensning. overvåking i produksjon Ingen (kjent mellomrom)

Detaljert feillogg

Den detaljerte feilloggen er for team som må dele funn, spore status på tvers av sprinter eller bygge institusjonell kunnskap på tvers av flere agenter.

Bemerkning

Last ned en CSV-versjon av denne malen.

Registrering per feil

Felt Verdi
Testtilfelle-ID (fra evalueringssettet, for eksempel KG-003)
Evalueringssett (hvilket evalueringssett denne posten tilhører)
Kvalitetssignal (faktisk nøyaktighet, kunnskapsjording, verktøyaktivering osv.)
Grunnårsakstype (Evalueringsoppsett, agentkonfigurasjon, plattformbegrensning, verktøyintegrering, uklassifisert)
Rotårsaksdetalj (spesifikk undertype, for eksempel «utdatert forventet svar», «tvetydighet for verktøybeskrivelse»)
Problem observert (hva agenten gjorde kontra hva det burde ha gjort)
Diagnosebane (hvilke triage-spørsmål som førte til denne klassifiseringen, for eksempel «Trinn 1, 2. kvartal – forventet svar utdatert»)
Utbedringshandling (hva som ble endret, spesifikke nok detaljer til å reprodusere)
Status (Åpne, Pågår, Løst, Vil ikke løse)
Vil ikke fikse begrunnelse (hvis vil ikke løse: hvorfor, og hvilken overvåking som er på plass)
Verifikasjon (rerun result: pass or fail, date, iteration number)
Dato triagert ___
Kategorisert av ___

Eksempel (fylt ut)

Felt Verdi
Testtilfelle-ID KG-005
Evalueringssett Kunnskapsjording
Kvalitetssignal Kunnskapsjording
Grunnårsakstype Agentkonfigurasjon
Rotårsaksdetalj Feil informasjon, agentgenerert innhold som ikke finnes i noen kunnskapskilde
Problem observert Agent hevdet "3-års utvidet garanti som dekker alle deler og arbeidskraft" når kilden sier "2-års standard garanti"
Diagnosebane Trinn 1 passert (gyldig evaluering) → trinn 2, 2.4 (besvart uten kilde) + 2.5 (motsagt kilde)
Utbedringshandling Lagt til i systemledeteksten: «Bare svar basert på informasjon som finnes i kunnskapskildene dine. Hvis informasjonen ikke er tilgjengelig, kan du si det.»
Status Løst
Vil ikke fikse begrunnelse I/T
Verifikasjon Pass (gjentakelse 2, 15. februar)
Dato triagert 14. februar
Kategorisert av [navn]

Sammendragslogg for iterasjon

Spor resultater og endringer på tvers av gjentakelser for trendanalyse.

Gjentakelse Dato Endring gjort Evalueringssett berørt Poengsum før Poengsum etter Delta Merknader
1 ___ Opprinnelig plan (ingen endringer) Alle — ___% — Første kjøring
2 ___ ___ ___ ___% ___% ___ ___
3 ___ ___ ___ ___% ___% ___ ___

Konsentrasjonssammendrag

Etter hver triage-økt, tell opp grunnårsakstyper for å finne konsentrasjonsmønstre.

Grunnårsakstype Antall % av total Systemisk?
Evalueringsoppsett ___ ___% (80%+ = pause agentarbeid, rette opp evalueringer først)
Agentkonfigurasjon ___ ___% (80%+ i ett område = arkitektonisk problem)
Plattformbegrensning ___ ___% (80%+ = revurdere omfanget, eskalere)
Verktøy eller integrering ___ ___% (fix backend, ikke agent)
Uklassifisert ___ ___% (skjerm, kan bli klassifiserbar med mer data)
I alt ___ 100 %

Anbefalte fremgangsmåter for vedlikehold av loggen

  • Oppdater i sanntid under triage. Ikke samle opp oppdateringer etter økten.
  • Registrere negative resultater også, for eksempel "prøvd X, hjalp ikke." Denne praksisen bidrar til å forhindre mislykkede fremgangsmåter på nytt.
  • Se gjennom før hver gjentakelse. Se etter mønstre før du adresserer individuelle feil.
  • Del på tvers av teamet. Del loggen med teamet slik at alle ser tidligere funn.
  • Arkiver, ikke slett. Behold løste oppføringer for mønsteranalyse. Flytt oppføringer til en arkivinndeling hvis den aktive loggen blir lang.

Neste trinn

Når du har dokumentert feilene dine:

  • Last updated on