Deskhero
Dansk
Prøv gratis

← Back to articles

Indstil chatbotters sikkerhedsgrænser, der faktisk reducerer fejl

Indstil chatbotters sikkerhedsgrænser, der faktisk reducerer fejl

Brug sikkerhedstærskler til at videresende usikre chatbotbeskeder på en sikker måde. Et praktisk design har tre niveauer: svar ved høj sikkerhed, bekræft eller afklar i midten, og videresend til et menneske ved lav sikkerhed. De numeriske grænser skal kalibreres til din model og trafik. Værdier som 0.85 og 0.5 kan illustrere politikken, men de er ikke universelle standardindstillinger.

Oracles dokumentation om hensigtsgenkendelse bruger 0.70 som udgangspunkt for sin egen hensigtsmodel og anbefaler at teste højere værdier, når resultaterne understøtter det. Dette råd er platformspecifikt. En tærskel, der fungerer for én model, ét domæne eller én definition af en score, kan være forkert for en anden.

Før du ændrer en tærskel, skal du opbygge et repræsentativt evalueringssæt fra nylige samtaler. Markér, om hver forudsagte hensigt eller hvert svar var korrekt, og sammenlign derefter disse resultater med de scores og handlinger, som systemet registrerede. Det giver dig et grundlag for at vælge en grænse i stedet for udelukkende at stole på en leverandørs standardindstilling.

  • Højt niveau (illustrativt: 0.85+): botten svarer automatisk uden et bekræftelsestrin.
  • Mellemste niveau (illustrativt: 0.5 til 0.85): botten bekræfter eller afklarer, før den handler.
  • Lavt niveau (illustrativt: under 0.5): botten overdrager samtalen til et menneske eller udløser en fallback-hensigt.

Professionelt tip: Start med tilstrækkeligt mange nylige samtaler til at dække almindelige hensigter, tvetydige formuleringer og kendte fejltilfælde. Et mindre, omhyggeligt mærket sæt er mere nyttigt end en stor stikprøve med upålidelige mærkninger.

Vigtigste pointer

En politik med tre niveauer kan reducere skjulte forkerte svar ved at give tvetydige beskeder en vej til bekræftelse. Dens effekt på automatisering og nøjagtighed skal måles med dine egne mærkede samtaler.

Punkt Detaljer
Start med tre niveauer Definér handlinger for højt, mellemste og lavt niveau. Betragt 0.85 og 0.5 som eksempler, og kalibrér derefter de faktiske grænser.
Kalibrér med virkelige data Mærk et repræsentativt sæt med hensyn til korrekthed, og undersøg derefter resultaterne for hvert scoreniveau, før du stoler på en tærskel.
Vær skeptisk over for LLM’ens egen sikkerhedsvurdering I RAG-systemer skal du evaluere signaler for hentning og forankring i stedet for at stole på modellens angivne sikkerhed.
Overvåg både automatisering og fejl Hold øje med automatiseringsraten og raten af forkerte svar samlet; hvis kun den ene stiger, er det et advarselssignal.
Brug forankret, godkendt viden Deskhero’s AI-chatbot svarer kun ud fra offentligt FAQ-indhold, der er godkendt af Brugeren, og overdrager samtalen, når den ikke kan svare med tilstrækkelig sikkerhed.

Indholdsfortegnelse

Hvad er en sikkerhedstærskel for en chatbot helt præcist?

En sikkerhedsscore er det tal, som din hensigtsklassifikator eller dit hentesystem tildeler sit bedste gæt, som regel et sted mellem 0 og 1. En sikkerhedstærskel er den linje, du trækker i dette interval for at afgøre, hvad botten skal gøre som det næste. Scoren rangerer dine muligheder; tærsklen er den politiske beslutning, du lægger oven på den.

Betydningen af en sikkerhedsscore afhænger af systemet. Nogle klassifikatorer giver scores, der kan kalibreres mod observeret korrekthed. Andre platforme viser kun rangerings- eller lighedssignaler. Antag ikke, at en score på 0.92 betyder 92 % sandsynlighed for et korrekt svar, medmindre leverandøren dokumenterer denne fortolkning, og dine evalueringsdata bekræfter den.

Retrieval-augmented generation (RAG) tilføjer endnu et lag. Det genererede svar kan lyde sikkert, selv når det hentede materiale er forældet eller irrelevant. Hentelighed, kildens kvalitet, understøttelse af svaret og modellens adfærd er separate signaler. Test hvert af dem mod mærkede resultater, før du kombinerer dem i en videresendelsespolitik.

Professionelt tip: Brug ikke en LLM’s selvrapporterede sikkerhed som det eneste signal til videresendelse. Kræv relevant kildemateriale, og test, om kontroller af hentning eller forankring faktisk forudsiger korrekthed i dine data.

Hvorfor tre sikkerhedsniveauer er bedre end én enkelt grænse

En enkelt tærskel tvinger dig til at træffe et binært valg: svar eller lad være med at svare. Et mellemste niveau tilføjer en tredje mulighed: stil et kort opklarende spørgsmål. Det kan reducere skjulte fejl uden at sende enhver usikker besked direkte videre til et menneske.

Niveau Typisk interval Bottens adfærd Eksempel på brugeroplevelse
Højt Illustrativt: 0.85 og derover Automatisk svar uden besvær Botten svarer direkte: “Din ordre afsendes torsdag.”
Mellemste Illustrativt: 0.5 til 0.85 Bekræft eller afklar “Mener du at spore din ordre eller at annullere den?”
Lavt Illustrativt: under 0.5 Fallback eller overdragelse “Lad mig sætte dig i forbindelse med en fra vores team.”

Diagram over chatbot-sikkerhedsniveauer og adfærd

Disse intervaller er eksempler, der gør logikken for videresendelse konkret. Erstat dem med værdier, der er afledt af din egen platform, scoredefinition og omkostningen ved et forkert svar.

Begrundelsen er enkel, når du ser den i praksis. En enkelt grænse ved eksempelvis 0.70 betyder, at enhver score lige over denne linje automatisk besvares med fuld sikkerhed, selv om en score på 0.71 kun adskiller sig ganske lidt fra 0.69. Det mellemste niveau giver dig en bufferzone, hvor botten indrømmer en vis usikkerhed i stedet for at lade, som om den ikke har nogen.

  • Hold bekræftelsesforløb korte. Valgbare knapper reducerer ofte tvetydighed bedre end endnu en åben prompt.
  • Fallback-teksten bør anerkende fejlen uden at lyde ødelagt: “Jeg er ikke sikker på, at jeg forstod det, så lad mig sætte dig i forbindelse med en medarbejder.”
  • Mål, om bekræftelser på det mellemste niveau løser tvetydigheden eller blot skaber mere friktion.

Her er den afvejning, som interessenterne skal høre klart: Hvis du sænker din tærskel, stiger automatiseringsraten, men hvert forkert svar, der passerer den lavere grænse, bliver usynligt. Ingen markerer det, fordi botten virkede sikker. Hvis du hæver tærsklen, sker det modsatte: Fejl bliver synlige som fallbacks, hvilket føles værre driftsmæssigt, men faktisk er sikrere, fordi en synlig fejl bliver logget og rettet, mens en usynlig fejl blot langsomt nedbryder tilliden.

Hvordan kalibrerer du sikkerhedstærskler for din bot?

Leverandørernes standardindstillinger og branchens intervaller er udgangspunkter. Dine faktiske grænser bør komme fra dine egne samtaletransskripter, fordi chatbotters nøjagtighed varierer voldsomt efter domæne, hensigtens kompleksitet og hvor rodet dine brugeres formuleringer er.

  1. Opbyg et repræsentativt testsæt. Brug virkelige spørgsmål, der spænder over almindelige hensigter, tvetydige formuleringer og kostbare fejltilfælde. Den nødvendige stikprøvestørrelse afhænger af trafikken og den præcision, du har brug for.
  2. Mærk den faktiske sandhed. Markér for hvert samtaletranskript, om det givne svar faktisk var korrekt, ikke blot om botten lød sikker.
  3. Knyt resultater til scores. Plot sikkerhedsscoren over for korrektheden for hver mærket besked. Du leder efter det punkt, hvor forkerte svar begynder at samle sig.
  4. Beregn præcision og recall for hvert niveau. For hvert foreslået niveau skal du beregne, hvor stor en procentdel af svarene der faktisk var korrekte (præcision), og hvor stor en procentdel af de korrekte svar der kom igennem uden unødvendig fallback (recall).
  5. Opbyg et reliabilitetsdiagram. Gruppér forudsigelser efter sikkerhedsscore, og plot den forudsagte sikkerhed over for den observerede nøjagtighed. En velkalibreret bot giver en næsten diagonal linje; en dårligt kalibreret bot buer væk fra den.
  6. Beregn Expected Calibration Error (ECE), når det er muligt. Dette ene tal kvantificerer forskellen mellem den angivne sikkerhed og den faktiske nøjagtighed på tværs af alle dine grupper.
  7. Kør en A/B-test, før ændringer rulles bredt ud. Opdel trafikken efter segment eller tidsinterval, og sammenlign derefter automatiseringsrate, rate af forkerte svar og fallback-rate mellem de gamle og nye tærskler.

Tænk på det som en pipeline: Scorefordelingen flyder ind i niveaugrænserne, niveaugrænserne bestemmer handlingsresultaterne, og handlingsresultaterne måles mod den faktiske sandhed for at kontrollere, om grænserne overhovedet var korrekte.

Metrik Hvad den fortæller dig Værktøj/metode
Præcision pr. niveau Andelen af automatisk besvarede beskeder, der faktisk var korrekte Manuel mærkning af samtaletransskripter
Recall pr. niveau Andelen af korrekte svar, der undgik unødvendig fallback Manuel mærkning af samtaletransskripter
Reliabilitetsdiagram Om den angivne sikkerhed stemmer overens med den observerede nøjagtighed Plot over grupperet nøjagtighed
Expected Calibration Error En enkelt score, der opsummerer kalibreringsforskellen Kalibreringsanalyse

Et studie fra 2025 af en RAG-baseret chatbot til teknisk support rapporterede, at strategien med prompten “Combo” reducerede Expected Calibration Error fra 23.33 til 8.4, mens nøjagtigheden steg fra 69.33 % til 81.33 %, inden for studiets eksperimentelle opsætning. Resultatet er ikke et universelt benchmark, men det viser, at prompt- og systemdesign kan påvirke kalibreringen såvel som selve tærsklen.

Hvordan kalibrerer du sikkerhedstærskler for din bot? Oversigtsdiagram

Hvad går galt, når tærskler fastsættes forkert?

To fejltilstande befinder sig i hver sin ende af den samme skala, og begge forekommer ofte nok til, at du bør kunne genkende deres symptomer udenad.

  • For lav tærskel: botten svarer automatisk på svage match. Nogle forkerte svar bliver muligvis ikke rapporteret, fordi forløbet aldrig signalerer usikkerhed.
  • For høj tærskel: botten eskalerer spørgsmål, som den kunne have besvaret korrekt, hvilket skaber forsinkelser og reducerer den nyttige automatiseringsrate.
  • Flere korrigerende hændelser: Hvis brugerne i stigende grad omformulerer, korrigerer eller udtrykkeligt siger “det var ikke det, jeg spurgte om”, er det et stærkt tegn på, at dit mellemste niveau er for snævert, eller at grænsen for det høje niveau er for aggressiv.
  • Uoverensstemmelse mellem fallback-rate og antallet af supportsager: Hvis antallet af fallbacks falder, men din supportkø alligevel vokser, kan botten være i gang med at give forkerte automatiske svar i stedet for at eskalere.
  • Feedbackmarkeringer samlet omkring din grænse: Hvis tommelfinger-ned eller “ikke nyttigt”-signaler samler sig lige omkring din tærskelgrænse, er grænsen sandsynligvis placeret forkert.

Løsningen kan være en anden grænse, et bredere mellemste niveau, bedre træningsdata eller stærkere kontroller af hentning og forankring. For RAG-baserede bots skal du kontrollere, at det hentede materiale understøtter svaret, i stedet for at betragte et flydende svar som dokumentation. Evaluer først en foreslået tærskel offline på mærkede samtaler. Hvis du derefter kører en online-test, skal du fastsætte sikkerheds- og tilbagerulningskriterier, før du eksponerer mere trafik.

Hvordan bør RAG- og LLM-chatbots håndtere sikkerhed forskelligt?

Generative modeller gør videresendelse baseret på sikkerhed mere kompliceret, fordi flydende og selvsikker tekst ikke beviser, at et svar er forankret. En nyttig politik adskiller derfor signaler som kvaliteten af hentningen, understøttelse fra kilder, svarenes konsistens og eventuelle klassificatorscores. Hvert signal skal stadig valideres mod den faktiske korrekthed.

I en medicinsk evaluering på tværs af flere specialer vurderede 33 læger fra 17 specialer svar på 284 spørgsmål. Det mediane svar blev vurderet højt, men 36 indledende svar fik en af de to laveste nøjagtighedsscorer på en sekspunkts skala. Denne kombination af stærke gennemsnitlige resultater og vigtige fejl understøtter omhyggelig validering i domæner med høje omkostninger. I en separat forbrugersag fastslog en domstol, at et flyselskab var ansvarligt for unøjagtige oplysninger om refundering, som dets chatbot havde givet.

Praktiske mønstre, der holder i produktion:

  • Kræv et relevant kildeafsnit for faktuelle svar i arbejdsgange, hvor vidensbasen er autoritativ.
  • Betragt et tomt eller svagt henteresultat som automatisk lav sikkerhed, uanset hvad sprogmodellen selv hævder.
  • Indbyg en tydelig vej til “Det ved jeg ikke” eller eskalering, som modellen kan vælge uden straf, eftersom modeller, der er trænet til altid at producere et svar, vil producere et, selv når de ikke burde.
  • Gem oprindelsesoplysninger sammen med svaret, så en kontrollant kan undersøge, om kilden understøtter påstanden.

Professionelt tip: Hvis et svar skal komme fra en godkendt vidensbase, og hentningen ikke returnerer noget relevant, skal du videresende til afklaring eller fallback i stedet for at bede modellen improvisere.

Hvad bør du overvåge efter at have ændret en tærskel?

En ændring af en tærskel er ikke en engangsredigering, som du foretager og derefter glemmer. Det er begyndelsen på et overvågningsvindue, hvor du holder øje med de specifikke signaler, der fortæller dig, om ændringen hjalp eller stille gjorde tingene værre.

  • Automatiseringsrate: procentdelen af samtaler, der blev løst uden menneskelig indblanding.
  • Rate af forkerte svar: manuelt mærket ud fra en stikprøve af samtaletransskripter, ikke selvrapporteret af botten.
  • Fallback-rate: hvor ofte botten eskalerer eller overdrager samtalen, fulgt over tid og pr. hensigt.
  • Korrigeringer pr. 100 samtaler: hvor ofte brugerne omformulerer, korrigerer eller udtrykkeligt afviser et svar.
  • Eskaleringsforsinkelse: hvor lang tid det tager, før en overdraget samtale når frem til et menneskeligt svar.
  • Brugertilfredshed eller CSAT: helst opdelt efter niveau, så du kan se, om bekræftelser på det mellemste niveau faktisk fungerer godt.

Opbyg et dashboard, der viser fordelingen af sikkerhedsscores over tid sammen med resultaterne for hvert niveau, og behold et fast stikprøvepanel med markerede forkerte svar til manuel gennemgang hver uge. Den vigtigste sammenhæng at holde øje med er denne: Hvis automatiseringsraten stiger, samtidig med at raten af forkerte svar også stiger, har din tærskel bevæget sig i den forkerte retning, selv om det overordnede automatiseringstal ser ud som en sejr. Evaluering af chatbotresultater fungerer kun, når du følger begge tal side om side, aldrig ét alene.

Politikskabeloner til tærskelbaseret videresendelse

Her er en politisk struktur, du kan tilpasse direkte, sammen med de telemetrikontroller, der bør køre automatisk efter enhver udrulning.

En minimal pseudokodestruktur for logikken bag videresendelsen:

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

Til bekræftelsestrinnet skal teksten være kort: “Det ser ud til, at du spørger om [X] eller [Y]. Hvilken af dem?” To valgbare knapper kan gøre et tvetydigt match til en afklaring med ét tryk. Sørg for en tekstbaseret mulighed, når valgene ikke passer.

Før du ruller en ændring af tærsklen ud til al trafik, skal du validere den offline og derefter bruge en kontrolleret test, hvis platformen understøtter det. Fastlæg på forhånd kriterier for tilbagerulning baseret på raten af forkerte svar, fallback-rate og brugerfeedback. Et forløb til overdragelse til et menneske for det lave niveau bør bevare samtalen og gøre det næste trin tydeligt.

Hvad bør du kontrollere med din chatbotplatform?

Før du aktiverer en tærskel i produktion på en leverandørplatform, skal du bekræfte, at platformen faktisk giver dig de kontroller, som hele denne tilgang afhænger af.

  • Kan du læse rå sikkerhedsscores for hver besked og ikke kun et binært resultat om, hvorvidt noget “matchede/matchede ikke”?
  • Kan du indstille tærskler pr. hensigt eller pr. færdighed i stedet for ét globalt tal for hele botten?
  • Kan du i RAG-konfigurationer få adgang til hentningens lighedsscore separat fra outputtet fra genereringstrinnet?
  • Understøtter platformen en indstilling for “sikkerhedsfordel”, så hensigter med næsten samme score vises som valgmuligheder i stedet for, at én af dem vælges i stilhed?
  • Kan du eksportere komplette samtaletransskripter til offline-mærkning og analyse uden at fjerne sikkerhedsmetadataene?
  • Findes der en testtilstand, hvor du kan køre en mulig tærskel mod historisk trafik, før den påvirker aktive brugere?

Oracles egen dokumentation om justering af hensigtsgenkendelse er en nyttig reference til, hvordan disse indstillinger ser ud på en moden platform. Både sikkerhedstærskel og sikkerhedsfordel vises udtrykkeligt som navngivne, justerbare kontroller. Hvis en leverandør ikke kan besvare disse spørgsmål klart under indkøbet, skal du betragte det som et advarselssignal og ikke som et mindre hul. Du kan ikke kalibrere det, du ikke kan se, og en platform, der skjuler sine scores, beder dig stole blindt på den.

Sådan håndterer Deskhero usikre chatbot-svar

Deskhero viser ikke rå sikkerhedsscores for chatbotten eller kundetilpasselige sikkerhedsniveauer. I stedet svarer AI-chatbotten ud fra arbejdsområdets godkendte offentlige FAQ og viser kontaktformularen, når den ikke kan svare med tilstrækkelig sikkerhed. FAQ-forslag kan oprettes ud fra løste sager og indhold hentet fra websites, men en Bruger skal godkende dem, før chatbotten kan bruge dem.

  • Chatbot-svar til kunder bruger kun offentligt FAQ-indhold, der er godkendt af Brugeren.
  • Når chatbotten ikke kan svare med tilstrækkelig sikkerhed, viser den en formular, så den besøgende kan kontakte teamet.
  • Hver chatsession bliver til en sag med sit samtaletranskript, og automatiske handlinger mærkes og logges.
  • Chatbotten aktiveres pr. widget og kræver mindst 100 godkendte offentlige FAQ-elementer.

Professionelt tip: Før du aktiverer en supportchatbot bredt, skal du teste almindelige spørgsmål og kendte særtilfælde mod den godkendte FAQ. Gennemgå både besvarede og overdragede chatsager for at finde manglende, tvetydige eller forældede FAQ-elementer.

Det, denne vejledning har ret i, som de fleste råd ikke har

De fleste råd om sikkerhedstærskler på nettet behandler selve tallet som produktet: Find den magiske grænse, indstil den, og gå videre. Den måde at se det på vender tingene på hovedet. Tærsklen kommer efter to ting, der faktisk betyder mere: kvaliteten af din forankring og din disciplin omkring mærkning. Ingen grænse kan rette op på en ødelagt version af nogen af delene.

Forskellen er vigtigst for generative RAG-chatbots. En klassificatorscore, en hentnings-lighedsscore og en LLM’s angivne sikkerhed kan ikke bruges som det samme. De stammer fra forskellige mekanismer og kan have meget forskellige sammenhænge med korrekthed.

Forankring og tærskelkalibrering løser forskellige problemer. Relevant kildemateriale kan reducere svar uden tilstrækkelig understøttelse, men det garanterer ikke, at modellen fortolker kilden korrekt. En kalibreret videresendelsespolitik kan reducere risikabel automatisering, men den kan ikke reparere forældet eller ufuldstændig viden. Validér både videnspipelinen og handlingstærsklerne, og fokuser derefter gennemgangen på de scoreintervaller, hvor fejl og overdragelser samler sig.

Få Deskhero’s forankrede AI-chatbot til at fungere for dit supportteam

En tilpasset pipeline til videresendelse baseret på sikkerhed kræver model- eller hentescores, logning af samtaletransskripter, evalueringsdata og et forløb til overdragelse til et menneske. Deskhero har en administreret tilgang til sin AI-chatbot: Den svarer ud fra den godkendte offentlige FAQ og viser kontaktformularen, når den ikke kan svare med tilstrækkelig sikkerhed.

Deskhero

Deskhero forbinder Gmail-, Google Workspace- og Microsoft 365-postkasser med en fælles helpdesk, mens svarene fortsat bruger din virksomhedsadresse. Spørgsmål, der kommer via e-mail, en integreret formular eller AI-chatbotten, bliver til sager. Deskhero kan foreslå offentlige FAQ-elementer ud fra løste sager og sider hentet fra websites. Når en Bruger godkender et element, kan både chatbotten og AI-automatiske svar bruge det. For e-handelsteams viser Shopify-kundepanelet kunde- og ordrekontekst ved siden af sagen.

Start den 30-dages gratis prøveperiode uden krav om kreditkort, og kør dit eget testsæt med 30 til 100 spørgsmål mod løsningen, før du beslutter, hvor meget af din supportvolumen der skal automatiseres.

Kilder

FAQ

Hvad er en god sikkerhedsscore for en chatbot?

Der findes ikke ét universelt tal. En politik med tre niveauer kan bruge 0.85 og 0.5 som illustrative grænser, men disse værdier er ikke generelle anbefalinger. Oracle dokumenterer 0.7 som udgangspunkt for sin egen hensigtsmodel. Kalibrér enhver grænse mod mærkede samtaler fra den model og platform, du rent faktisk bruger.

Hvordan beregnes en sikkerhedsscore?

For en hensigtsklassifikator er scoren modelspecifik og angiver som regel, hvor stærkt modellen hælder til en hensigt. Den bør kun behandles som en sandsynlighed, hvis platformen definerer den sådan, og kalibreringsdata understøtter fortolkningen. RAG-systemer kan også vise signaler for hentningslighed, forankring eller validering af svar, som hver især kræver separat evaluering.

Hvad er sikkerhedsscoren i en LLM-baseret chatbot?

Det bør ikke antages, at en LLM’s selvrapporterede sikkerhed forudsiger korrekthed. For en RAG-chatbot skal du evaluere kvaliteten af hentningen og kontrollere, om svaret understøttes af det hentede materiale. Brug disse testede signaler, ikke flydende formuleringer eller angivet sikkerhed alene, når du afgør, om botten skal svare eller falde tilbage.

Hvad bør du aldrig fortælle en chatbot?

Undgå at dele følsomme personoplysninger, adgangskoder, økonomiske kontonumre eller fortrolige virksomhedsoplysninger med en chatbot, medmindre du har kontrolleret den specifikke platforms politikker for datahåndtering og opbevaring. Det er endnu vigtigere for supportbots, der logger samtaler til træning eller kvalitetsgennemgang.

Hvordan kontrollerer du, om en chatbots svar er korrekt?

Brug en repræsentativ stikprøve af virkelige samtaler, markér, om hvert svar er understøttet og korrekt, og sammenlign disse resultater med systemets tilgængelige scores og videresendelseshandlinger. Deskhero begrænser chatbotens kildemateriale til offentligt FAQ-indhold, der er godkendt af Brugeren, men teams bør stadig gennemgå svar og overdragelser for manglende eller forældet viden.