Sådan strukturerer du en vidensbase til stemme-AI

Hvordan strukturerer du en vidensbase til stemme-AI, så din agent holder op med at hallucinere?

Strukturér den som rekursive Markdown-chunks på 512 tokens, tagget med metadata for produkt, region og målgruppe, som hentes ved en similaritetstærskel på 0,65+ med en eksplicit afvisningsinstruktion. Dette er det firelags mønster (kuratering, chunking, metadata-afgrænsning og retrieval med afvisning som standard), som stemmeagenter i produktion på platforme som Retell AI bruger til at forhindre fejltilstanden med opdigtede trin.

Resten af denne guide udfolder hvert lag med de præcise konfigurationsværdier, en referencestruktur modelleret på enterprise-supportbiblioteker som Lenovos, og den testprotokol, der fanger hallucinationer, før de når frem til en opkalder.

Hvad skal du bygge?

En retrieval-arkitektur, der forankrer hvert agentsvar i dit verificerede indhold, blokerer modellen fra at opfinde trin, og holder sig inden for latensbudgettet, som naturlige telefonsamtaler kræver.

Når du er færdig med denne vejledning, vil din vidensbase:

• Returnere den rette chunk ved første retrieval mindst 90 % af gangene under testning
• Tilføje under 100 ms latens pr. tur, så den samlede svartid holdes tæt på 600 ms
• Afvise at svare, når svaret ikke findes i kildematerialet, i stedet for at gætte
• Filtrere retrieval efter produkt, region eller workflow, så multi-tenant-indhold ikke krydskontaminerer
• Automatisk holde sig opdateret, efterhånden som din underliggende dokumentation ændrer sig

Hvad har du brug for, før du starter?

• En Retell AI-konto med en fungerende agent (funktionen vidensbase er inkluderet i alle abonnementer)
• Din eksisterende supportdokumentation i et format, du kan eksportere til Markdown
• En liste over de 50 hyppigste opkalderspørgsmål fra de seneste 30 dages telefon- eller chat-tickets
• Redaktøradgang til dit hjælpecenter eller din produktdokumentation (du kommer til at omskrive nogle sider)
• En time til at evaluere retrieval-kvaliteten efter den første opbygning

Hvordan bygger du en vidensbase til stemme-AI, der ikke hallucinerer?

Trin 1: Hvordan gennemgår og kuraterer du kildeindhold, før du indekserer?

Arkivér ethvert dokument, der er forældet, modstridende eller ikke den eneste kilde til sandhed for sit emne, før du indekserer en eneste side. Den største kilde til hallucinationer hos stemmeagenter er ikke modellen. Det er modstridende eller forældet indhold i kildematerialet.

Hvis to sider er uenige om din returfrist, har retrieveren ingen måde at vælge den korrekte på, og LLM'en vil selvsikkert læse op fra den chunk, der vinder similaritetsscoren. Hent hvert dokument, hver FAQ og hver hjælpeartikel, du planlægger at indeksere. Tjek tre ting for hver: er den aktuel i dette kvartal, er den den eneste kilde til sandhed for sit emne, og stemmer den overens med, hvad dine erfarne supportmedarbejdere faktisk siger på opkald. Hvis et dokument ikke bør bruges til at besvare kundespørgsmål, bør det slet ikke være i din vidensbase. ElevenLabs

Du bør nu have et kurateret sæt dokumenter, som du ville være tryg ved at sende ordret til en kunde.

Trin 2: Hvorfor Markdown, og hvordan skal du formatere det?

Konvertér alt til struktureret Markdown med én H1 pr. dokument, en beskrivende H2 pr. brugerspørgsmål, der kan besvares, og korte afsnit med eksplicitte subjekter. Stemmeagenter henter tekst-chunks, ikke renderede websider. Markdown er det format, der overlever chunking-pipelinen med mest semantisk struktur intakt.

Retells egen dokumentation anbefaler Markdown frem for .txt, fordi velstrukturerede overskrifter giver retrieveren rene grænser at splitte på. Erstat hvert "klik her" eller "som beskrevet ovenfor" med den konkrete reference, fordi den chunk, der indeholder "ovenfor", kan blive hentet uden den chunk, den peger på. Hver chunk læses alene, så hver chunk skal give mening alene.

Du bør nu have en mappe med Markdown-filer, hvor hver fil dækker ét produktområde, og hver H2 dækker ét brugerspørgsmål, der kan besvares.

Trin 3: Hvilken chunk-størrelse fungerer bedst til stemme-AI?

Brug rekursiv chunking på 512 tokens med 10-15 % overlap, hvor der først splittes på Markdown-overskrifter, derefter afsnit, derefter sætninger. Dette er den benchmark-validerede standard for generelt RAG-indhold, og det holder godt for stemmesupportmateriale specifikt.

En veltunet rekursiv splitter på 512 tokens med 15 % overlap og metadata-berigelse overgår en dyr semantisk chunking-tilgang på de fleste virkelige dokumentsæt. Lange chunks fylder LLM'ens kontekstvindue med støj. Korte chunks fragmenterer instruktioner på tværs af flere retrievals og får agenten til at springe trin over midt i en forklaring. Den hårde regel: split aldrig en nummereret procedure på tværs af to chunks. Hvis "Trin 3" ligger i chunk A og "Trin 4" i chunk B, kan retrieveren returnere den ene uden den anden, og din agent vil springe en handling over. Substack

Du bør nu have chunks, hvor hver enhed enten indeholder en komplet procedure eller indeholder kontekstuel prosa, der giver mening uden sine naboer.

Trin 4: Hvilke metadata skal du tagge hver chunk med?

Tag hver chunk med mindst fem felter: product, version, region, audience og last_verified_date. Det er dette, der forhindrer en opkalder fra Texas i at høre returpolitikker fra Californien og forhindrer et ThinkPad-spørgsmål i at hente ThinkCentre-svar.

Hvis en enkelt agent ser KB-indhold for flere delstater eller lokationer, kan retrieval hente chunk'en for den forkerte delstat (f.eks. Californien-politik for en Texas-opkalder), medmindre afgrænsning og metadata er omhyggeligt designet. Det samme problem gælder for produktlinjer, softwareversioner, kundeniveauer og supportkanaler. Ved runtime sender din agent de relevante filtre med forespørgslen, så vektorsøgningen kun overvejer chunks, der matcher opkalderens kontekst. I Retell kan du sende disse som dynamiske variabler, der er indsamlet tidligere i opkaldet. Optimize Smart

Du bør nu have et metadataskema, hvor enhver enkelt chunk kan afgrænses entydigt til én opkalderkontekst.

Trin 5: Hvilken retrieval-tærskel stopper hallucinationer?

Sæt similaritetstærsklen til 0,65 eller højere, og begræns retrieval til 3-5 chunks. Et retrieval-system, der altid returnerer noget, er en hallucinationsmaskine i forklædning.

Når en opkalder spørger om en funktion, du ikke dokumenterer, vil retrieveren stadig fremhæve det nærmeste semantiske match. LLM'en vil modtage den chunk og flydende væve den ind i et forkert svar. I Retells indstillinger for vidensbase styrer to parametre denne adfærd. Parameteren "Chunks to retrieve" angiver, hvor mange resultater der føres ind i LLM'en (standard 3, anbefalet maks. 5 til stemme). "Similarity Threshold" angiver den minimale cosinus-similaritet, for at en chunk anses for relevant (standard 0,6). For softwaresupport-anvendelser, hvor forkert information er værre end ingen information, hæv tærsklen til 0,7.

Du bør nu se dit retrieval-system returnere færre matches af højere kvalitet og afvise de marginale.

Trin 6: Hvordan tvinger du agenten til at afvise i stedet for at gætte?

Tilføj denne præcise instruktion til agentprompten: "Svar kun ved hjælp af informationen i ## Related Knowledge Base Contexts. Hvis den sektion mangler eller ikke indeholder relevant information, sig at der ikke er relateret information tilgængelig, og tilbyd at viderestille opkaldet." Denne enkelte instruktion er den mest effektive anti-hallucinationskontrol i enhver stemmeagent.

Uden den vil LLM'en gribe ned i sine træningsdata, når retrieval kommer tomt tilbage. Dette er fejltilstanden bag næsten enhver offentlig chatbot-katastrofe, herunder Air Canada-sagen om sorgtakst, hvor flyselskabet blev holdt juridisk ansvarligt. Afvisningsmønsteret vender fejltilstanden fra "selvsikkert forkert svar" til "ærligt lad-mig-hente-et-menneske", hvilket er præcis, hvad opkaldere, der bruger din software, faktisk ønsker, når systemet rammer et grænsetilfælde.

Du bør nu se din agent sige "Jeg har ikke det dokumenteret; lad mig viderestille dig" på spørgsmål uden for scope i stedet for at opfinde trin.

Trin 7: Hvordan holder du vidensbasen fra at blive forældet?

Aktivér auto-refresh på URL-kilder, så Retell henter på ny hver 24. time, versionér dine Markdown-filer i Git, og kør en kvartalsvis gennemgang af enhver fil med en last_verified_date ældre end 90 dage. Forældet viden er hallucinationens stille partner.

Hvis vidensbasen er forældet, henter RAG bare det forkerte svar hurtigere. Løsningen er at automatisere aktualitet i stedet for at stole på, at nogen husker at uploade filer igen, når produktdokumentationen ændrer sig. Kombinér auto-refresh med auto-crawling af undersider i hjælpecentret, så nye artikler indekseres automatisk uden manuel indgriben. CX Today

Du bør nu have en vidensbase, der opdaterer sig selv, når dit underliggende indhold opdateres, uden et menneske i loopet.

Trin 8: Hvordan tester du retrieval, før du går live?

Kør dine 50 rigtige opkalderspørgsmål gennem retrieval-systemet, og inspicér, hvad der kommer tilbage, før nogen LLM-generering finder sted. Tre ting betyder noget for hver forespørgsel: er den rette chunk blandt de øverste 3, er similaritetsscoren over din tærskel, og ville et menneske, der kun læste de hentede chunks, kunne besvare spørgsmålet.

For ethvert spørgsmål, hvor retrieval fejler, er løsningen næsten altid ved kilden. Enten mangler det relevante indhold helt, chunkingen splittede en procedure på tværs af grænser, eller metadataen filtrerer det fra. Modstå trangen til at rette retrieval-fejl ved at tilføje instruktioner til agentprompten. Prompt-lapper er, hvordan vidensbaser driver hen mod et uvedligeholdeligt rod. Sigt efter 90 %+ retrieval-nøjagtighed på testsættet, før du implementerer til live-opkald.

Du bør nu have et målt retrieval-nøjagtighedstal for dine hyppigste opkalderspørgsmål og en liste over rettelser i kildedokumenter for de spørgsmål, der fejlede.

Trin 9: Hvornår skal du bruge conversation flow i stedet for en enkelt prompt?

Brug conversation flow med vidensbaser på node-niveau til enhver stemmeagent, hvor opkalderintentionen deler sig i distinkte workflows, især softwaresupport, sundhedsbooking og miljøer med flere produkter. En flad vidensbase, der ligger under en enkelt prompt, er den løseste mulige arkitektur.

For softwaresupport specifikt er mønsteret af højeste kvalitet conversation flow, hvor hver node kun henter fra den del af dokumentationen, der er relevant for den del af opkaldet. Et typisk softwaresupport-flow har noder til triage, kontoopslag, fejlfinding, eskalering og bekræftelse efter løsning. Fejlfindingsnoden indlæser fejlfindings-KB'en. Kontoopslagsnoden indlæser slet ingen KB, fordi den bør kalde et API. Denne struktur er mere pålidelig at vedligeholde end én kæmpe prompt med én kæmpe KB. Kombinér den med indbygget analyse efter opkald, så du kan se, hvilke noder der udløser retrieval, og hvilke forespørgsler der kommer tilbage under tærsklen.

Du bør nu have en implementering, hvor retrieval-scopet strammer, efterhånden som samtalen indsnævres, i stedet for at hver tur søger i alle dokumenter.

Hvordan skal du strukturere selve vidensbasen? En reference i Lenovo-stil

Inddel vidensbasen i niveauer efter målgruppe, og afgræns retrieval til opkalderens niveau. Dette er det strukturelle mønster, som Lenovos enterprise-supportbibliotek bruger til at holde lærervendt indhold om klasseledelse fra at kollidere med teknisk ingeniørindhold.

Lenovo etablerede tre niveauer af artikler — generelle emner og produktinformation, lærerspecifikke emner samt tekniske emner og problemer, med fokuserede artikler, elimineret redundans og standardiserede navngivningskonventioner på tværs af alle tre niveauer. Anvend det samme mønster på en stemme-AI-vidensbase: Contiem

Niveau 1: Generelt produkt og priser. Offentligt tilgængelige fakta, som enhver opkalder kan spørge om. Tagget audience: all. Indeksér alt.

Niveau 2: Slutbruger-vejledninger. Trin-for-trin-procedurer for standardopkalderen. Tagget audience: end_user, afgrænset efter product og region. Dette niveau bærer hovedparten af retrieval-trafikken.

Niveau 3: Teknisk og admin. Konfiguration, integrationer og grænsetilfælde. Tagget audience: admin. Hentes kun, når opkalderen er blevet identificeret som administrator tidligere i opkaldet.

Interne runbooks, eskaleringsmatricer og ingeniørnoter hører til i en helt separat vidensbase, aldrig tilgængelig for den kundevendte agent. Niveauinddelingen er det, der forhindrer et slutbruger-fejlfindingsopkald i utilsigtet at fremhæve en intern eskaleringsprocedure.

Hvad er best practices, når vidensbasen er live?

Bør vidensbasen indeholde agentinstruktioner?

Nej. Vidensbasen er til at levere understøttende information, ikke agentadfærd. Hvis du opdager, at du uploader en Markdown-fil med titlen "Hvordan agenten skal opføre sig, når X sker", hører det indhold til i prompten eller i en conversation flow-node. At blande dem udvander begge: retrieveren rangerer adfærdsinstruktioner imod faktuelle forespørgsler og henter dem på de forkerte tidspunkter.

Hvordan skal du skrive overskrifter til stemme-retrieval?

Start med brugerens mål, ikke funktionsnavnet. "Konfigurér tofaktorgodkendelse" bliver til "Slå tofaktorlogin til." Retrieveren matcher mod opkalderens talte ordvalg, og naturligt formulerede spørgsmål matcher naturligt formulerede overskrifter langt bedre, end de matcher produktterminologi.

Hvorfor skal hver chunk være selvstændig?

Hver chunk hentes alene. Brug fulde navne i stedet for stedord, fulde produktnavne i stedet for "platformen", og gentag enhver betinget kontekst i hvert trin i stedet for at sige "hvis du bruger admin-konsollen, så..." tre afsnit senere. Denne ene regel eliminerer en overraskende del af hallucinationerne, fordi den fjerner den tvetydighed, som LLM'en ellers forsøger at løse ved at gætte.

Hvordan fejlfinder du en hallucination efterfølgende?

Registrér de hentede chunks, similaritetsscorer og metadata-filtre på hvert opkald sammen med transskriptionen. At logge kun det endelige agentsvar gør hallucinationsfejlfinding næsten umulig: du ser det forkerte svar, men ikke hvorvidt retrieveren returnerede den forkerte chunk, eller den rette chunk blev genereret forkert. De fleste "hallucinations"-tickets viser sig at være retrieval-rangeringsproblemer, som løses ved kilden.

Hvorfor hentes tabeldata dårligt?

Chunking-pipelinen kan ikke bevare de rumlige relationer, der gør tabeller læsbare, så en tabelcelle hentes ofte uden sin kolonneoverskrift. Omskriv kritiske tabeller som prosa med eksplicitte sætninger. "Pro-abonnementet understøtter 50 brugere og inkluderer API-adgang" slår en tabelcelle, som retrieveren splitter væk fra sin kolonneoverskrift.

Hvad er de almindelige faldgruber, og hvordan undgår du dem?

Hvorfor er det en fejl at dumpe hele hjælpecentret i én KB?

En vidensbase med 4.000 chunks, hvor 50 er relevante for en given opkalder, er værre end en med 400 chunks, hvor 50 er relevante, fordi retrieveren har 10 gange flere konkurrerende matches til at forvirre den. Byg smalle vidensbaser pr. workflow, og link dem på node-niveau i stedet.

Hvorfor bør du ikke lappe hallucinationer i prompten?

Når agenten siger noget forkert, er instinktet at tilføje "sig ikke X" til prompten. Tre af disse, og prompten bliver modstridende; ti, og den bliver uhåndterlig. Find ud af, hvorfor LLM'en sagde X. Næsten altid antydede en chunk i KB'en det, eller fraværet af en chunk tvang modellen til at falde tilbage på træningsdata. Lap kilden.

Hvad er omkostningen ved over-retrieval?

Hver ekstra chunk tilføjer tokens til prompten og millisekunder til svaret. At sætte "chunks to retrieve" til 10, fordi mere kontekst føles mere sikkert, er en almindelig fejl. Bliv ved 3 chunks for typisk supportindhold, øg til 5 kun når opkalderspørgsmål spænder over flere emner, og gå aldrig højere, medmindre du har målt, at det forbedrer nøjagtigheden.

Hvorfor bliver offentlige chatbot-fejl ved med at ske?

Fordi agenten får lov at tale uden en eksplicit afvisningsinstruktion. Air Canada-chatbotten blev holdt ansvarlig, efter at den genererede en ikke-eksisterende sorgpolitik, der modsagde flyselskabets faktiske regler, og lignende fejl bliver ved med at gentage sig på tværs af leverandører, der springer afvisningslaget over. Gør afvisningen eksplicit, test at den udløses, og behandl ethvert tilfælde, hvor agenten opfinder information, som en P0-fejl. CanLII

Hvorfor skal du teste igen efter hver kildeopdatering?

At tilføje et nyt dokument ændrer retrieval-landskabet for hver eksisterende forespørgsel. En chunk, der rangerede først i går, kan rangere som nummer tre i dag. Hold testsættet med 50 spørgsmål automatiseret, og kør det på ny, når det underliggende indhold ændrer sig betydeligt.

Hvilke resultater har rigtige teams set?

Hvordan brugte SWTCH dette mønster til support af EV-ladere?

SWTCH implementerede en Retell-drevet stemmeagent ved navn Lucas til at håndtere supportopkald om EV-ladere, hvor opkaldere typisk står ved en død lader med lavt batteri og ingen tålmodighed til en forkert instruktion. Implementeringen reducerede supportomkostningerne med mere end 50 % og forbedrede SaaS-marginerne betydeligt, idet agenten svarer på sekunder i stedet for minutter. Pålidelighedskravet blev sat af anvendelsen: et forkert fejlfindingstrin er forskellen mellem en fungerende lader og en strandet bilist.

Hvordan skalerede Anker dette på tværs af global support?

Anker rullede Retell ud på tværs af global support for forbrugerelektronik, hvor opkaldere stiller produktspecifikke spørgsmål på tværs af snesevis af SKU'er og flere sprog. Casestudiet illustrerer, hvorfor metadata-afgrænsning betyder noget i stor skala. Uden produktniveau-filtrering på retrieval kan et spørgsmål om en soundbar hente en manual til en støvsuger, og agenten vil selvsikkert kombinere dem. Med korrekt KB-struktur bliver agenten inden for produktkonteksten under hele opkaldet.

Hvilket produktionsvolumen har denne arkitektur håndteret?

Retell AI driver nu 50M+ AI-telefonopkald i realtid hver måned for kunder på tværs af tusindvis af virksomheder, uden at nogen agent er rapporteret at være løbet af sporet på tværs af det volumen. Arkitekturen i denne guide er den samme, der kører under de opkald. Yahoo Finance

Ofte stillede spørgsmål

Hvad er den bedste chunk-størrelse til en vidensbase til stemme-AI?

Rekursiv chunking på 512 tokens med 10-15 % overlap er den benchmark-validerede standard. Mindre chunks (200-300 tokens) fungerer til FAQ-lignende indhold; større chunks (1024 tokens) fungerer til narrativ prosa. Split altid først på Markdown-overskrifter, derefter afsnit, derefter sætninger.

Hvordan forhindrer jeg LLM'en i at generere information, der ikke findes i vidensbasen?

Tilføj en eksplicit afvisningsinstruktion til agentprompten: "Svar kun ved hjælp af informationen i ## Related Knowledge Base Contexts. Hvis den sektion mangler eller ikke indeholder relevant information, svar at der ikke er relateret information tilgængelig." Kombineret med en similaritetstærskel på 0,65 eller højere er dette den mest effektive enkelte anti-hallucinationskontrol.

Hvor meget latens tilføjer vidensbasen pr. tur?

Under 100 ms pr. tur på Retells optimerede retrieval-pipeline, hvilket holder agenten inden for det samlede svarvindue på ~600 ms, som opkaldere forventer. Hvis du ser væsentligt højere latens, så tjek, om du henter flere chunks, end du har brug for, eller om metadata-filtrering anvendes ved forespørgselstid frem for efter retrieval.

Skal jeg bruge en enkelt prompt eller conversation flow med vidensbaser på node-niveau?

Conversation flow vinder til softwaresupport og ethvert scenarie, hvor opkalderintentionen deler sig i distinkte workflows. Vidensbaser på node-niveau lader hver samtaletilstand hente fra en fokuseret del af indholdet, hvilket forbedrer nøjagtigheden og gør vedligeholdelse ligetil. Enkelte prompter fungerer til smalle anvendelser som en FAQ for ét produkt. Retells guide til implementering af konversationel AI dækker det arkitektoniske valg i flere detaljer.

Hvor ofte skal jeg opdatere vidensbasen?

Aktivér auto-refresh på URL-kilder, så Retell henter på ny hver 24. time. For uploadede dokumenter, kør en manuel gennemgang, når det underliggende produkt eller den underliggende politik ændrer sig, og behandl alt ældre end 90 dage som noget, der kræver verifikation.

Kan jeg træne stemmeagenten på mine opkaldsoptagelser i stedet for at skrive dokumentation?

Ja, delvist. Du kan bruge vellykkede opkaldstransskriptioner og optagelser af erfarne medarbejdere som kildemateriale til vidensbasen. Uddrag spørgsmål-og-svar-parrene, konvertér dem til Markdown, og indeksér dem sammen med din formelle dokumentation. Dette er især nyttigt til at fange den specifikke formulering, dine bedste medarbejdere bruger, som ofte løser problemer hurtigere end den officielle hjælpecenter-tekst. Det erstatter ikke struktureret dokumentation; det supplerer den.

Hvilke metadatafelter er vigtigst for retrieval hos stemmeagenter?

Som minimum: product, version, region, audience og last_verified_date. Tilføj topic til granulær routing i et conversation flow, og compliance_scope, hvis du har reguleret indhold (HIPAA, finansiel rådgivning), der aldrig bør hentes uden for specifikke opkaldskontekster.

Hvordan tester jeg, om min vidensbase fungerer, før jeg går live?

Byg et testsæt af 50-100 rigtige opkalderspørgsmål fra de seneste 30 dages support-tickets. Inspicér for hver de hentede chunks, før nogen LLM-generering: er den rette chunk blandt de øverste 3, er similaritetsscoren over tærsklen, og kunne et menneske besvare spørgsmålet ud fra kun de chunks. Sigt efter 90 %+ retrieval-nøjagtighed på testsættet, før du implementerer.

Hvad sker der, når en opkalder spørger om noget, der ikke er i vidensbasen?

Med en afvisningsinstruktion på plads og en similaritetstærskel på 0,65 eller højere siger agenten, at den ikke har den information dokumenteret, og tilbyder enten at tage imod en besked eller foretager en assisteret viderestilling via viderestilling af opkald til en menneskelig agent med fuld samtalekontekst. Uden disse kontroller falder agenten tilbage på den underliggende LLM's træningsdata, hvilket er præcis den fejltilstand, denne guide er designet til at forhindre.

Hvad skal du gøre nu?

Du har nu en vidensbasearkitektur, der forankrer hvert agentsvar i verificeret indhold, afgrænser retrieval efter opkalderkontekst, afviser at svare, når svaret ikke er dokumenteret, og opdaterer sig selv, efterhånden som dit kildemateriale ændrer sig. Dette er fundamentet, der lader en stemmeagent håndtere softwaresupport, regulerede brancher eller ethvert opkald med høj indsats, hvor et forkert trin betyder mere end et hurtigt et.

For at udvide dette yderligere understøtter den samme retrieval-arkitektur anvendelser som automatisering af AI-kundesupport, leadkvalificering med produktspecifik routing og AI-drevne receptionister til lægepraksisser, hvor compliance-afgrænsning er ikke til forhandling. De samme mønstre passer også til implementeringer i sundhedssektoren og forsikring, hvor omkostningen ved en hallucination er et regulatorisk problem, ikke bare et kundeoplevelsesmæssigt et.

Kom godt i gang gratis med $10 i forbrugskreditter på retellai.com.