Deskhero
Norsk
Prøv gratis

← Back to articles

Sett konfidensgrenser for chatboter som faktisk reduserer feil

Sett konfidensgrenser for chatboter som faktisk reduserer feil

Bruk terskler for sikkerhet i svarene til å rute usikre chatbothenvendelser på en trygg måte. Et praktisk design har tre nivåer: svar ved høy sikkerhet, bekreft eller presiser i mellomnivået, og send videre til et menneske ved lav sikkerhet. De numeriske grensene må kalibreres for modellen og trafikken din. Verdier som 0.85 og 0.5 kan illustrere retningslinjene, men de er ikke universelle standardverdier.

Oracles dokumentasjon om intensjonsavklaring bruker 0.70 som et utgangspunkt for sin egen intensjonsmodell og anbefaler å teste høyere verdier når resultatene støtter det. Dette rådet gjelder spesifikt for plattformen. En terskel som fungerer for én modell, ett domene eller én definisjon av poengsummen, kan være feil for en annen.

Før du endrer en terskel, bør du bygge et representativt evalueringssett basert på nylige samtaler. Merk om hver forutsagte intensjon eller hvert svar var korrekt, og sammenlign deretter resultatene med poengsummene og handlingene systemet registrerte. På denne måten får du et grunnlag for å velge en grense i stedet for å basere deg utelukkende på en leverandørs standardverdi.

  • Høyt nivå (illustrasjon: 0.85+): boten svarer automatisk, uten et bekreftelsestrinn.
  • Mellomnivå (illustrasjon: 0.5 til 0.85): boten bekrefter eller presiserer før den utfører en handling.
  • Lavt nivå (illustrasjon: under 0.5): boten sender samtalen videre til et menneske eller utløser en reserveintensjon.

Profftips: Start med nok nylige samtaler til å dekke vanlige intensjoner, tvetydige formuleringer og kjente feilsituasjoner. Et mindre, nøye merket sett er mer nyttig enn et stort utvalg med upålitelige merkinger.

Viktigste punkter

En policy med tre nivåer kan redusere ubemerket feilaktige svar ved å gi tvetydige henvendelser en bekreftelsesmulighet. Effekten på automatisering og nøyaktighet må måles med dine egne merkede samtaler.

Punkt Detaljer
Start med tre nivåer Definer handlinger for høyt, middels og lavt nivå. Se på 0.85 og 0.5 som eksempler, og kalibrer deretter de faktiske grensene.
Kalibrer med reelle data Merk et representativt sett for korrekthet, og undersøk deretter ytelsen per poengnivå før du stoler på en terskel.
Vær skeptisk til LLM-ens egen sikkerhet I RAG-systemer bør du evaluere signaler for gjenfinning og forankring i stedet for å stole på modellens oppgitte sikkerhet.
Følg med på både automatisering og feil Følg med på automatiseringsgrad og andel feilaktige svar samtidig. Hvis bare én av dem øker, er det et faresignal.
Bruk forankret, godkjent kunnskap Deskhero’s AI-chatbot svarer bare fra offentlig FAQ-innhold som er godkjent av User, og sender samtalen videre når den ikke kan svare med tilstrekkelig sikkerhet.

Innholdsfortegnelse

Hva er egentlig en terskel for chatbotens sikkerhet i svarene?

En sikkerhetspoengsum er tallet som intensjonsklassifisereren eller gjenfinningssystemet ditt tildeler sitt beste forslag, vanligvis et sted mellom 0 og 1. En terskel for sikkerhet i svarene er grensen du trekker i dette området for å avgjøre hva boten skal gjøre videre. Poengsummen rangerer alternativene dine, mens terskelen er beslutningen om retningslinjer som du legger oppå den.

Betydningen av en sikkerhetspoengsum avhenger av systemet. Noen klassifiserere gir poengsummer som kan kalibreres mot observert korrekthet. Andre plattformer viser bare rangerings- eller likhetssignaler. Ikke anta at en poengsum på 0.92 betyr 92 % sannsynlighet for et korrekt svar, med mindre leverandøren dokumenterer denne tolkningen og evalueringsdataene dine bekrefter den.

Retrieval-augmented generation (RAG) legger til et nytt lag. Det genererte svaret kan høres sikkert ut selv når det gjenfunne materialet er utdatert eller irrelevant. Likhet ved gjenfinning, kildekvalitet, støtte for svaret og modellens atferd er separate signaler. Test hvert av dem mot merkede resultater før du kombinerer dem i en rutingspolicy.

Profftips: Ikke bruk en LLMs egenrapporterte sikkerhet som det eneste rutesignalet. Krev relevant kildemateriale, og test om kontroller av gjenfinning eller forankring faktisk forutsier korrekthet i dataene dine.

Hvorfor tre sikkerhetsnivåer er bedre enn én enkelt grense

Én enkelt terskel tvinger frem et binært valg: svar eller ikke svar. Et mellomnivå legger til et tredje alternativ: still et kort oppklarende spørsmål. Dette kan redusere ubemerkede feil uten å sende alle usikre henvendelser direkte til et menneske.

Nivå Typisk område Botens atferd UX-eksempel
Høyt Illustrasjon: 0.85 og høyere Svar automatisk, uten friksjon Boten svarer direkte: «Bestillingen din sendes torsdag.»
Middels Illustrasjon: 0.5 til 0.85 Bekreft eller presiser «Mener du å spore bestillingen din eller å kansellere den?»
Lavt Illustrasjon: under 0.5 Reserveflyt eller overføring «La meg sette deg i kontakt med noen på teamet vårt.»

Diagram over chatbotens sikkerhetsnivåer og atferd

Disse områdene er eksempler som gjør rutingslogikken konkret. Bytt dem ut med verdier som er utledet fra din egen plattform, definisjon av poengsummen og kostnaden ved et feilaktig svar.

Begrunnelsen er enkel når du ser den i praksis. En enkelt grense på for eksempel 0.70 betyr at alle poengsummer like over denne linjen besvares automatisk med full sikkerhet, selv om en poengsum på 0.71 knapt skiller seg fra 0.69. Mellomnivået gir deg en buffersone der boten innrømmer en viss usikkerhet i stedet for å late som om den ikke er usikker.

  • Hold bekreftelsesflytene korte. Valg som kan trykkes på, reduserer ofte tvetydighet bedre enn enda en åpen forespørsel.
  • Reserveflytens tekst bør erkjenne bommen uten å høres ødelagt ut: «Jeg er ikke sikker på at jeg forsto det riktig. La meg sette deg i kontakt med en person.»
  • Mål om bekreftelser på mellomnivå faktisk løser tvetydigheten eller bare skaper mer friksjon.

Her er avveiningen interessenter trenger å høre tydelig: Hvis du senker terskelen, øker automatiseringsgraden, men hvert feilaktige svar som kommer over den senkede grensen, blir usynlig. Ingen flagger det fordi boten virket sikker. Hvis du hever terskelen, skjer det motsatte: Feilene blir synlige som reserveflyter. Det føles verre driftsmessig, men er faktisk tryggere, fordi en synlig feil blir logget og rettet, mens en usynlig feil bare svekker tilliten i det stille.

Hvordan kalibrerer du terskler for sikkerhet i svarene til boten din?

Leverandørstandarder og bransjenivåer er utgangspunkter. De faktiske grensene dine bør komme fra dine egne samtalelogger, fordi chatbotens nøyaktighet varierer kraftig etter domene, kompleksiteten i intensjonene og hvor rotete formuleringene fra brukerne dine er.

  1. Bygg et representativt testsett. Bruk reelle spørsmål som dekker vanlige intensjoner, tvetydige formuleringer og kostbare feilsituasjoner. Den nødvendige utvalgsstørrelsen avhenger av trafikken og presisjonen du trenger.
  2. Merk fasiten. For hver samtalelogg markerer du om svaret som ble gitt, faktisk var korrekt, ikke bare om boten hørtes sikker ut.
  3. Knytt resultater til poengsummer. Plott sikkerhetspoengsummen mot korrekthet for hver merkede henvendelse. Du ser etter hvor feilaktige svar begynner å samle seg.
  4. Beregn presisjon og tilbakekalling per nivå. For hvert foreslåtte nivå beregner du hvilken prosentandel av svarene som faktisk var korrekte (presisjon), og hvilken prosentandel av de korrekte svarene som kom gjennom uten unødvendig reserveflyt (tilbakekalling).
  5. Bygg et pålitelighetsdiagram. Gruppér prediksjoner etter sikkerhetspoengsum og plott forventet sikkerhet mot observert nøyaktighet. En godt kalibrert bot gir en linje nær diagonalen, mens en dårlig kalibrert bot avviker fra den.
  6. Beregn Expected Calibration Error (ECE) der det er mulig. Dette enkelttallet kvantifiserer avstanden mellom oppgitt sikkerhet og faktisk nøyaktighet på tvers av alle gruppene dine.
  7. Kjør en A/B-test før du ruller ut endringer bredt. Del trafikken etter segment eller tidsintervall, og sammenlign deretter automatiseringsgrad, andel feilaktige svar og reserveflyt mellom de gamle og de nye tersklene.

Tenk på det som en prosess: Fordelingen av poengsummer går inn i grensene for nivåene, grensene bestemmer resultatet av handlingene, og resultatene måles mot fasiten for å kontrollere om grensene faktisk var riktige i utgangspunktet.

Måling Hva den forteller deg Verktøy/metode
Presisjon per nivå Andelen automatisk besvarte henvendelser som faktisk var korrekte Manuell merking av samtalelogger
Tilbakekalling per nivå Andelen korrekte svar som unngikk unødvendig reserveflyt Manuell merking av samtalelogger
Pålitelighetsdiagram Om oppgitt sikkerhet samsvarer med observert nøyaktighet Plott over gruppert nøyaktighet
Expected Calibration Error En enkelt poengsum som oppsummerer kalibreringsavstanden Kalibreringsanalyse

En studie fra 2025 av en RAG-basert chatbot for teknisk støtte rapporterte at strategien med «Combo»-instruks reduserte Expected Calibration Error fra 23.33 til 8.4, samtidig som nøyaktigheten økte fra 69.33 % til 81.33 %, innenfor studiens eksperimentelle oppsett. Resultatet er ikke en universell referanseverdi, men viser at instruks- og systemdesign kan påvirke kalibreringen, i tillegg til selve terskelen.

Hvordan kalibrerer du terskler for sikkerhet i svarene til boten din? Oversiktsdiagram

Hva går galt når tersklene settes feil?

To feilmønstre befinner seg i hver sin ende av den samme skalaen, og begge er så vanlige at du bør kjenne symptomene deres ut og inn.

  • For lav terskel: boten svarer automatisk på svake treff. Noen feilaktige svar kan forbli urapporterte fordi flyten aldri signaliserer usikkerhet.
  • For høy terskel: boten eskalerer spørsmål den kunne ha svart korrekt på, noe som skaper forsinkelser og reduserer den nyttige automatiseringsgraden.
  • Flere korrigeringshendelser: Hvis brukerne i økende grad omformulerer, korrigerer eller uttrykkelig sier «det var ikke det jeg spurte om», er det et tydelig tegn på at mellomnivået ditt er for smalt, eller at grensen for høyt nivå er satt for strengt.
  • Uoverensstemmelse mellom reserveflytgrad og mengden kundestøttesaker: Hvis antallet reserveflyter synker, men kundestøttekøen likevel vokser, kan det hende boten svarer feil automatisk i stedet for å eskalere.
  • Tilbakemeldingsmarkeringer samlet rundt grensen: Hvis tommel ned- eller «ikke nyttig»-signalene samler seg rett rundt terskelgrensen, er grensen sannsynligvis plassert feil.

Løsningen kan være en annen grense, et bredere mellomnivå, bedre treningsdata eller sterkere kontroller av gjenfinning og forankring. For RAG-baserte boter bør du kontrollere at det gjenfunne materialet støtter svaret, i stedet for å behandle et velformulert svar som bevis. Evaluer en foreslått terskel offline på merkede samtaler først. Hvis du deretter kjører en nettbasert test, må du definere sikkerhets- og tilbakeføringskriterier før du slipper til mer trafikk.

Hvordan bør RAG- og LLM-chatboter håndtere sikkerhet i svarene på ulike måter?

Generative modeller gjør sikkerhetsruting mer komplisert fordi flytende og selvsikker tekst ikke beviser at et svar er forankret. En nyttig policy skiller derfor mellom signaler som kvalitet på gjenfinning, støtte fra sitater, samsvar i svaret og eventuell klassifiseringspoengsum. Hvert signal må fortsatt valideres mot faktisk korrekthet.

I en medisinsk evaluering på tvers av flere spesialiteter vurderte 33 leger fra 17 spesialiteter svar på 284 spørsmål. Medianen for svarene ble vurdert som høy, men 36 av de innledende svarene fikk en av de to laveste nøyaktighetspoengsummene på en skala fra ett til seks. Denne kombinasjonen av sterke gjennomsnittsresultater og viktige feil støtter behovet for grundig validering i domener der feil har høy kostnad. I et separat forbrukertilfelle kom en domstol frem til at et flyselskap var ansvarlig for unøyaktig refusjonsinformasjon som chatboten hadde gitt.

Praktiske mønstre som fungerer i produksjon:

  • Krev et relevant kildeavsnitt for faktabaserte svar i arbeidsflyter der kunnskapsbasen er autoritativ.
  • Behandle et tomt eller svakt gjenfinningsresultat som automatisk lav sikkerhet, uavhengig av hva språkmodellen selv hevder.
  • Bygg inn en tydelig «Jeg vet ikke»- eller eskaleringsbane som modellen kan velge uten å bli straffet, siden modeller som er trent til alltid å produsere et svar, vil gjøre det også når de ikke burde.
  • Lagre opphavsinformasjon sammen med svaret, slik at en kontrollør kan sjekke om kilden støtter påstanden.

Profftips: Hvis et svar skal komme fra en godkjent kunnskapsbase, og gjenfinningen ikke returnerer noe relevant, bør du rute samtalen til presisering eller reserveflyt i stedet for å be modellen improvisere.

Hva bør du følge med på etter at du har endret en terskel?

En terskelendring er ikke en engangsredigering du gjør og deretter glemmer. Den markerer starten på en overvåkingsperiode der du følger med på de spesifikke signalene som viser om endringen hjalp eller i det stille gjorde ting verre.

  • Automatiseringsgrad: prosentandelen samtaler som ble løst uten menneskelig involvering.
  • Andel feilaktige svar: manuelt merket fra et utvalg samtalelogger, ikke egenrapportert av boten.
  • Reserveflytgrad: hvor ofte boten eskalerer eller sender samtalen videre, fulgt over tid og per intensjon.
  • Korrigeringer per 100 samtaler: hvor ofte brukerne omformulerer, korrigerer eller uttrykkelig avviser et svar.
  • Forsinkelse ved eskalering: hvor lang tid det tar før en samtale som er sendt videre, når frem til et menneskelig svar.
  • Brukertilfredshet eller CSAT: helst segmentert etter nivå, slik at du kan se om bekreftelser på mellomnivå faktisk fungerer godt.

Bygg et dashbord som viser fordelingen av sikkerhetspoengsummer over tid sammen med resultatgrad per nivå, og behold et fast utvalg av flaggede feilaktige svar for manuell gjennomgang hver uke. Den viktigste korrelasjonen å følge med på er denne: Hvis automatiseringsgraden øker samtidig som andelen feilaktige svar øker, har terskelen nettopp beveget seg i feil retning, selv om det overordnede automatiseringstallet ser ut som en seier. Evaluering av chatbotytelse fungerer bare når du følger begge tallene side om side, aldri ett av dem isolert.

Kopierbare retningslinjer for terskelbasert ruting

Her er en struktur for retningslinjer du kan tilpasse direkte, sammen med telemetrikontrollene som bør kjøres automatisk etter enhver utrulling.

En minimal pseudokode for rutingslogikken:

if confidence >= HIGH_CUTOFF:
    auto_answer(intent)
elif confidence >= MEDIUM_CUTOFF:
    present_confirmation(top_2_intents)
else:
    escalate_to_human()

For bekreftelsestrinnet bør teksten være kort: «Det ser ut som du spør om [X] eller [Y]. Hvilket av dem gjelder det?» To valg som kan trykkes på, kan gjøre et tvetydig treff om til en avklaring med ett trykk. Sørg for at det også finnes en fritekstmulighet når ingen av valgene passer.

Før du ruller ut en terskelendring til all trafikk, bør du validere den offline og deretter bruke en kontrollert test hvis plattformen støtter det. Fastsett på forhånd kriterier for tilbakeføring basert på andel feilaktige svar, reserveflytgrad og brukertilbakemeldinger. En flyt for overføring til et menneske på lavt nivå bør bevare samtalen og gjøre neste steg tydelig.

Hva bør du kontrollere med chatbotplattformen din?

Før du slår på en terskelendring i produksjon på en leverandørplattform, må du bekrefte at plattformen faktisk gir deg kontrollene som hele denne tilnærmingen er avhengig av.

  • Kan du lese rå sikkerhetspoengsummer for hver henvendelse, ikke bare et binært resultat som «treff/ikke treff»?
  • Kan du angi terskler per intensjon eller ferdighet, i stedet for ett globalt tall for hele boten?
  • For RAG-konfigurasjoner: Kan du få tilgang til likhetspoengsummen for gjenfinning separat fra resultatet fra genereringstrinnet?
  • Støtter plattformen en innstilling for «margin ved sikkerhetsseier», slik at intensjoner med nesten samme poengsum presenteres som alternativer i stedet for at én av dem velges i stillhet?
  • Kan du eksportere komplette samtalelogger for offline-merking og analyse uten at sikkerhetsmetadataene fjernes?
  • Finnes det en testmodus som lar deg kjøre en aktuell terskel mot historisk trafikk før den påvirker aktive brukere?

Oracles egen dokumentasjon om justering av intensjonsavklaring er en nyttig referanse for hvordan disse innstillingene ser ut på en moden plattform. Både terskel for sikkerhet i svarene og margin ved sikkerhetsseier vises uttrykkelig som navngitte, justerbare kontroller. Hvis en leverandør ikke kan svare tydelig på disse spørsmålene under innkjøpsprosessen, bør du se det som et varselsignal, ikke som et mindre hull. Du kan ikke kalibrere det du ikke kan se, og en plattform som skjuler poengsummene sine, ber deg stole blindt på den.

Slik håndterer Deskhero usikre chatbot-svar

Deskhero viser ikke rå sikkerhetspoengsummer fra chatboten eller kundetilpassbare sikkerhetsnivåer. I stedet svarer AI-chatboten fra arbeidsområdets godkjente offentlige FAQ og viser kontaktskjemaet når den ikke kan svare med tilstrekkelig sikkerhet. FAQ-forslag kan opprettes fra løste saker og innhold hentet fra nettsteder, men en User må godkjenne dem før chatboten kan bruke dem.

  • Chatbotens svar til kunder bruker bare offentlig FAQ-innhold som er godkjent av User.
  • Når chatboten ikke kan svare med tilstrekkelig sikkerhet, viser den et skjema slik at den besøkende kan kontakte teamet.
  • Hver chatøkt blir en sak med samtaleloggen, og automatiske handlinger merkes og logges.
  • Chatboten aktiveres per widget og krever minst 100 godkjente offentlige FAQ-elementer.

Profftips: Før du aktiverer en chatbot for kundestøtte i stor skala, bør du teste vanlige spørsmål og kjente spesialtilfeller mot den godkjente FAQ-en. Gå gjennom både besvarte og videresendte chatsaker for å finne manglende, tvetydige eller utdaterte FAQ-oppføringer.

Dette har veiledningen rett i, i motsetning til de fleste råd

De fleste råd om sikkerhetsterskler på nettet behandler selve tallet som produktet: finn den magiske grensen, angi den og gå videre. Denne fremstillingen er bakvendt. Terskelen kommer etter to ting som faktisk betyr mer: kvaliteten på forankringen og hvor systematisk du merker dataene dine. Ingen terskel kan reparere en ødelagt versjon av noen av dem.

Dette skillet er viktigst for generative RAG-chatboter. En klassifiseringspoengsum, en likhetspoengsum for gjenfinning og en LLMs oppgitte sikkerhet er ikke det samme. De kommer fra ulike mekanismer og kan ha svært ulike sammenhenger med korrekthet.

Forankring og terskelkalibrering løser ulike problemer. Relevant kildemateriale kan redusere svar uten støtte, men garanterer ikke at modellen tolker kilden riktig. En kalibrert rutingspolicy kan redusere risikofylt automatisering, men kan ikke reparere utdatert eller ufullstendig kunnskap. Valider både kunnskapsprosessen og handlingstersklene, og konsentrer deretter gjennomgangen om poengområdene der feil og overføringer samler seg.

Ta i bruk Deskhero’s forankrede AI-chatbot for kundestøtteteamet ditt

En tilpasset sikkerhetsrutingsprosess trenger modell- eller gjenfinningspoengsummer, logging av samtalelogger, evalueringsdata og en flyt for overføring til et menneske. Deskhero har en administrert tilnærming til AI-chatboten sin: Den svarer fra den godkjente offentlige FAQ-en og viser kontaktskjemaet når den ikke kan svare med tilstrekkelig sikkerhet.

Deskhero

Deskhero kobler Gmail-, Google Workspace- og Microsoft 365-postkasser til en felles kundestøtteplattform, samtidig som svarene fortsatt bruker firmaadressen din. Spørsmål som kommer inn via e-post, et innebygd skjema eller AI-chatboten, blir til saker. Deskhero kan foreslå offentlige FAQ-oppføringer fra løste saker og sider hentet fra nettsteder. Når en User godkjenner en oppføring, kan både chatboten og AI-automatiske svar bruke den. For e-handelsteam viser Shopify-kundepanelet kunde- og bestillingskontekst ved siden av saken.

Start den 30-dagers gratis prøveperioden, uten krav om kredittkort, og kjør ditt eget testsett med 30 til 100 spørsmål mot løsningen før du bestemmer hvor stor del av kundestøttevolumet du vil automatisere.

Kilder

Vanlige spørsmål

Hva er en god sikkerhetspoengsum for en chatbot?

Det finnes ikke noe universelt tall. En policy med tre nivåer kan bruke 0.85 og 0.5 som illustrerende grenser, men disse verdiene er ikke generelle anbefalinger. Oracle dokumenterer 0.7 som et utgangspunkt for sin egen intensjonsmodell. Kalibrer enhver grense mot merkede samtaler fra modellen og plattformen du faktisk bruker.

Hvordan beregnes en sikkerhetspoengsum?

For en intensjonsklassifiserer er poengsummen modellspesifikk og angir vanligvis hvor sterkt modellen foretrekker en intensjon. Den bør bare behandles som en sannsynlighet hvis plattformen definerer den slik og kalibreringsdata støtter tolkningen. RAG-systemer kan også vise likhet ved gjenfinning, forankring eller signaler for validering av svar, og hvert av disse må evalueres separat.

Hva er sikkerhetspoengsummen i en LLM-basert chatbot?

Det bør ikke antas at en LLMs egenrapporterte sikkerhet forutsier korrekthet. For en RAG-chatbot bør du evaluere kvaliteten på gjenfinningen og om svaret støttes av det gjenfunne materialet. Bruk disse testede signalene, i stedet for flytende formuleringer eller oppgitt sikkerhet alene, når du avgjør om boten skal svare eller bruke reserveflyt.

Hva bør du aldri fortelle en chatbot?

Unngå å dele sensitive personopplysninger, passord, økonomiske kontonumre eller konfidensiell forretningsinformasjon med en chatbot, med mindre du har kontrollert retningslinjene for databehandling og lagring hos den aktuelle plattformen. Dette er enda viktigere for kundestøtteboter som logger samtaler for opplæring eller kvalitetskontroll.

Hvordan kontrollerer du at chatbotens svar er korrekt?

Bruk et representativt utvalg av reelle samtaler, merk om hvert svar er støttet og korrekt, og sammenlign resultatene med systemets tilgjengelige poengsummer og rutinghandlinger. Deskhero begrenser chatbotens kildemateriale til offentlig FAQ-innhold som er godkjent av User, men teamene bør likevel gjennomgå svar og overføringer for å finne manglende eller utdatert kunnskap.