Bruk rammeverket for evalueringstriage gjennom praktiske scenarier

Disse ende-til-ende-gjennomgangene illustrerer hvordan evaluerings-triage-rammeverklagene fungerer sammen i praksis. Hver reise starter fra et annet evalueringsscenario og følger en distinkt diagnosebane.

Gjennomgangene viser hvordan du bruker rammeverket trinn for trinn. Bruk disse eksemplene til å forstå hvordan du går fra evalueringsresultater til diagnose, utbedring og verifisering i virkelige agentevalueringsscenarioer.

Reise 1: Første evalueringskjøring

Du kjører evalueringspakken for første gang på en kundestøtteagent. Her er resultatene:

Trinn 1: Tolke resultater (lag 1)

Bruk tabellen for poengtolkning til å kalibrere terskler og identifisere hvilke evalueringssett som er under blokkeringsterskler.

Beredskapsvurdering: Iterate. Kunnskapsgrunnlaget er under blokkeringsterskelen. Fokuser på utbedring der.

Trinn 2: Prioritere feil (lag 2, trinn 0)

Situasjonen: Kunnskapsforankring har syv tester. To testtilfeller mislykkes: KG-003 og KG-005. Begge testtilfellene er i et kjernesett for forretningsevaluering, så de er prioritet 2. Siden det bare er to, prioriter begge.

Referanse: Prioritere feil (lag 2, trinn 0)

Trinn 3: Triage KG-003 (lag 2, trinn 1-2)

Testtilfelle KG-003:

• Eksempelinndata: "Hva er returpolicyen?"
• Forventet svar: "Vi tilbyr et 30-dagers returvindu for alle kjøp."
• Agentens svar: "Returpolicyen vår tillater returer innen 15 virkedager etter kjøp."
• Evalueringsmetode: Nøkkelords samsvar
• Resultatet: Mislykkes (forventet «30-dagers», sa agenten «15 virkedager»)

Kontroller evalueringsoppsettet (trinn 1 i lag 2):

Klassifisering: Problem med evalueringsoppsett. Utdatert forventet svar. Agenten har rett. Evalueringen er feil.

Trinn 4: Triage KG-005 (lag 2, trinn 1-2)

Testtilfelle KG-005:

• Eksempelinndata: "Inkluderer Premium-planen en utvidet garanti?"
• Forventet svar: "Premium-planen inneholder en to års standardgaranti. Utvidede garantialternativer er tilgjengelige for kjøp separat.»
• Agentens svar: «Ja, Premium-planen inneholder en treårig utvidet garanti som dekker alle deler og arbeid.»
• Evalueringsmetode: Sammenlign mening
• Resultatet: Fail (agent fabrikkerte garantidetaljer)

Kontroller evalueringsoppsettet (trinn 1 i lag 2):

Diagnostisere agenten (trinn 2 i lag 2):

Klassifisering: Konfigurasjonsproblem for agent. Kunnskapsgrunnlagshull. Agenten produserte garantidetaljer som ikke finnes i de konfigurerte kunnskapskildene.

Trinn 5: Utbedre (lag 3)

KG-003 (evalueringsoppsettutbedring):

• Endre: Oppdater forventet verdi fra «30-dagers returvindu» til «15 virkedager»
• Kjør på nytt: Bare KG-003
• Forventet: Bestått

KG-005 (agentkonfigurasjonsutbedring):

• Endre: Legg til forankringsinstruksjon i systemledeteksten: «Bare svar basert på informasjon som finnes i kunnskapskildene dine. Hvis informasjonen ikke er tilgjengelig, kan du si det.»
• Kjør på nytt: Evalueringssett for full kunnskapsjording (endring av agentkonfigurasjon kan ha bredere effekter)
• Forvente: KG-005 passerer. Andre testtilfeller bør ikke gå tilbake.

Trinn 6: Bekreft

Etter begge endringene kjører du evalueringssettet for kunnskapsjording på nytt:

Vurdering: Kunnskapsjording er nå over 80% blokkeringsterskelen. Én feil (KG-007) forblir og blokkerer ikke beredskapen. Se gjennom det i neste gjentakelse.

Trinn 7: Dokument (lag 4)

Registrer i feilloggen:

Mønsternotat: Bekreft forventede verdier mot kildedokumenter før hver evaluering kjøres. Legg til dette trinnet i sjekklisten for forhåndsevaluering.

Ny klarhetskontroll: Alle evalueringssettene er nå over blokkeringsgrenser.

Klargjøringsvurdering: Distribuer agent med kjente hull (KG-007 dokumentert, overvåkingsplan på plass).

Referanse: Lag 4: Analyser mønstre og forbedre agenten kontinuerlig

Reise 2: Poengplatå

Situasjonen: Du kjører fire gjentakelser på en produktstøtteagent. Faktisk nøyaktighet forblir på 78% på tvers av alle fire løp. Du gjør raske endringer etter hver kjøring, men ser ingen forbedring.

Trinn 1: Kontroller mønstre (lag 4)

Se gjennom feilloggen på tvers av alle fire gjentakelser:

Trend - Stabil. Utbedring er ikke rettet mot den faktiske grunnårsaken.

Referanse: Lag 4: Analyser mønstre og forbedre agenten kontinuerlig

Trinn 2: Analysere mislykkede testtilfeller

Se gjennom de seks vedvarende feilene på tvers av alle gjentakelser.

Konsentrasjonsanalyse: Fem av seks feil (83%) involverer samme grunnårsak: Agenten henter informasjon fra vanlige spørsmål-siden i stedet for produkthåndboken.

Trinn 3: Retriage (lag 2)

I utgangspunktet klassifiserer du feilene som agentkonfigurasjonsproblem: Feil kilde hentet.

Bruk flere agentkonfigurasjonsendringer, inkludert rask omording, omorganisering og tillegg av eksempler. Disse endringene resulterer ikke i målbar forbedring. På dette tidspunktet validerer du feilen mot plattformbegrensningsindikatorer.

Reklassifisering: Dette problemet er en plattformbegrensning knyttet til hentingsrangering. Plattformen prioriterer konsekvent vanlige spørsmål over produkthåndboken for disse spørringene, og ytterligere ledetekst- eller instruksjonsendringer påvirker ikke hentingsvirkemåten.

Referanse: Lag 2: Triage-agent feil

Trinn 4: Utbedre (lag 3 – plattformbegrensning)

Når du klassifiserer en feil som en plattformbegrensning, fokuserer du på løsninger og dokumentasjon i stedet for å gjøre endringer i agentkonfigurasjonen.

Referanse: Svar på plattformbegrensning

Løsningsstrategi: Bruk én eller flere av følgende løsningsmetoder for å redusere innvirkningen:

• Omstrukturer produkthåndboken med klarere inndelingsoverskrifter som samsvarer med vokabularet som brukes i brukerspørringer.
• Dupliser kritiske produktspesifikasjoner fra håndboken til vanlige spørsmål for å opprette overflødige hentingsbaner.
• Refaktorer manuelt innhold slik at hver inndeling adresserer et enkelt, veldefinert spørsmål for å forbedre henting av delsamsvar.

Disse tilnærmingene tar sikte på å påvirke hentingsatferd uten å stole på lede- eller instruksjonsendringer.

Eskalering og sporing: Hvis begrensningen vedvarer, dokumenterer og eskalerer du problemet til plattformteamet.

• Dokumenter begrensningen som følger: «Spørringer for produktspesifikasjoner henter< konsekvent vanlige spørsmål-siden (sist oppdatert: >dato<, >n< sider) i stedet for >produkthåndboken (sist oppdatert: <dato>, <N-sider>), til tross for håndboken som inneholder autoritativ informasjon.»
• Gi støttebevis: Inkluder flere testtilfeller som viser spørringen, den forventede kilden og den faktiske kilden som hentes.
• Send inn for etterforskning.
• Del den dokumenterte begrensningen og bevisene med plattformteamet for sporing og oppfølging.

Trinn 5: Bekreft

Når du har restrukturert produkthåndboken og lagt til overflødige vanlige spørsmål, kjører du det relevante evalueringssettet på nytt for å bekrefte innvirkningen.

Vurdering: Den midlertidige løsningen forbedrer den generelle ytelsen. Én feil gjenstår (FA-019). Spørringen er for tvetydig til å hente riktig kilde på en pålitelig måte, selv med omstrukturert innhold. Denne feilen registreres som en kjent begrensning.

Trinn 6: Dokument

Oppdater feilloggen for å gjenspeile den endelige klassifiseringen og resultatene.

Viktig takeaway: Hvis evalueringsresultatene forblir flate på tvers av flere ledetekster eller instruksjonsendringer, er det lite sannsynlig at årsaken er ledeteksten. Valider infrastruktur og plattformatferd før du investerer mer i ledeteknikk.

Reise 3: Regresjon etter oppdatering

Situasjonen: Du oppdaterte systemledeteksten for å forbedre tone og empati. Toneresultatene økte, men faktisk nøyaktighet falt under blokkeringsterskelen, noe som introduserte en regresjon.

Før endringen:

Du la til følgende instruksjon i systemledeteksten: «Bekreft alltid kundens bekymring og vis empati før du gir svaret ditt. Start hvert svar ved å validere kundens opplevelse.»

Etter endringen:

Trinn 1: Tolke (lag 1)

Faktisk nøyaktighet er nå under 80% blokkeringsterskelen. Denne endringen introduserer en regresjon og blokkerer beredskap.

Referanse: Lag 1: Tolke resultater og identifisere feil

Trinn 2: Kontroller mønstre (lag 4)

Krysssignalmønster samsvarer: Tonen forbedres mens nøyaktigheten forringes.

Angitt grunnårsak: Instruksjonskonflikt.

Den nylig tilføyde toneveiledningen konkurrerer med nøyaktighetsinstruksjoner for modelloppmerksomhet.

Referanse: Lag 4: Analyser mønstre og forbedre agenten kontinuerlig

Trinn 3: Triage de nye feilene (lag 2)

Se gjennom faktiske nøyaktighetstesttilfeller som gikk før endringen og nå mislykkes.

Testtilfelle FA-007:

• Input: "Hva er maksimal filopplastingsstørrelse?"
• Forventet: "Maksimal filopplastingsstørrelse er 25 MB for standardkontoer og 100 MB for bedriftskontoer."
• Agent før: "Maksimal filopplastingsstørrelse er 25 MB for standardkontoer og 100 MB for bedriftskontoer."
• Agent etter: "Jeg forstår fullstendig din bekymring for filopplastingsstørrelser – det kan være frustrerende når du prøver å laste opp viktige dokumenter! Jeg vil forsikre meg om at du har all informasjonen du trenger. Den maksimale opplastingsstørrelsen er 25 MB for standardplaner.»

Trinn 1. Bekreft evalueringen: Det forventede svaret er riktig, og evalueringen er gyldig. Svaret etter oppdateringen utelater virksomhetskontodetaljene.

Trinn 2. Diagnostisere: Den nye toneinstruksjonen krever en empatiinnledning i hvert svar. Dette kravet bruker responsbudsjett og modelloppmerksomhet, og det fører til ufullstendige faktiske svar.

Klassifisering: Konfigurasjonsproblem for agent. Instruksjonskonflikt mellom tone- og nøyaktighetsveiledning.

Referanse: Lag 2: Triage-agent feil

Trinn 4: Utbedre (lag 3)

Problemet er ikke toneveiledning i seg selv, men konkurrerende prioriteringer i systemledeteksten. Utbedring fokuserer på å skille og prioritere instruksjoner.

Gammel instruksjon (enkel, konkurrerende): "Bekreft alltid kundens bekymring og vis empati før du gir svaret ditt. Start hvert svar ved å validere kundens opplevelse.»

Ny instruksjon (atskilt, prioritert): "Inkluder alltid det fullstendige faktiske svaret på kundens spørsmål. Ikke utelat detaljer for kortfattethet. I tillegg, når kunden uttrykker frustrasjon eller bekymring, kort erkjenner det."

Viktige endringer:

• Nøyaktighet prioriteres eksplisitt.
• Fullstendighet av faktiske svar er angitt direkte.
• Empati er betinget snarere enn universell.
• «Kort» begrenser empati for å hindre avkorting av innhold.

Referanse: Lag 3: Kartlegg feilmønstre til utbedringsstrategier

Trinn 5: Bekreft

Kjør hele evalueringspakken på nytt, ettersom endringer i systemledeteksten kan ha stor innvirkning.

Vurdering: Begge signalene oppfyller nå blokkeringsterskler. Tone går ikke helt tilbake til toppen, men den er fortsatt godt over 75% blokkeringsterskelen og forbedrer den opprinnelige grunnlinjen.

Trinn 6: Dokument

Viktig takeaway: Valider alltid systemledetekstendringer mot den fullstendige evalueringsserien, ikke bare målsignalet. Instruksjoner konkurrerer om modelloppmerksomhet, og forbedringer i ett område kan introdusere regresjoner i andre.

Mønster å se etter: Dette scenarioet er en forekomst av instruksjonsbudsjettproblemet. Etter hvert som ledetekstene vokser, blir instruksjonskonflikter mer sannsynlige. Periodisk konsolidering og forenkling bidrar til å opprettholde stabiliteten.

Vanlige mønstre på tvers av reiser

Hver reise starter fra et annet scenario for å illustrere en distinkt diagnosebane. Hvis du vil se hvordan én enkelt agent utvikler seg gjennom hele evalueringens livssyklus – poengtolkning, feiltriage, utbedring og verifisering – kan du se gjennom Reise 1, som gir den mest komplette gjennomgangen av ende-til-ende.

Denne tabellen fremhever regelmessige mønstre som er observert på tvers av reisene og de praktiske leksjonene de forsterker.

Neste trinn

Når du har gjennomgått disse eksemplene, velger du den neste handlingen som best samsvarer med gjeldende situasjon:

• Start med poengtolkning hvis du har evalueringsresultater klare til å vurdere.
• Start feiltriage hvis du trenger å diagnostisere spesifikke testtilfellefeil.
• Bruk mønsteranalyse hvis du arbeider med flere feil og vil identifisere systemiske problemer.
• Konfigurer feillogging for å spore beslutninger, resultater og regelmessige problemer.
• Gå tilbake til rammemålene for å se gjennom den fullstendige evalueringstriagetilnærmingen.