Så strukturerar du en kunskapsbas för röst-AI

Hur strukturerar du en kunskapsbas för röst-AI så att din agent slutar hallucinera?

Strukturera den som rekursiva Markdown-chunks på 512 token, taggade med metadata för produkt, region och målgrupp, hämtade vid ett likhetströskelvärde på 0,65+ med en uttrycklig avvisningsinstruktion. Det här är det fyrlagersmönster (kurering, chunking, metadataavgränsning och hämtning med avvisning som standard) som produktionssatta röstagenter på plattformar som Retell AI använder för att förhindra felläget med påhittade steg.

Resten av den här guiden går igenom varje lager med de exakta konfigurationsvärdena, en referensstruktur modellerad efter supportbibliotek för företag som Lenovos, samt det testprotokoll som fångar hallucinationer innan de når en uppringare.

Vad kommer du att bygga?

En hämtningsarkitektur som grundar varje agentsvar i ditt verifierade innehåll, hindrar modellen från att hitta på steg och håller sig inom den latensbudget som krävs för naturliga telefonsamtal.

När den här handledningen är slut kommer din kunskapsbas att:

• Returnera rätt chunk vid första hämtningen minst 90 % av gångerna under testning
• Lägga till under 100 ms latens per tur och hålla den totala svarstiden nära 600 ms
• Vägra svara när svaret inte finns i källmaterialet i stället för att gissa
• Filtrera hämtning efter produkt, region eller arbetsflöde så att innehåll för flera hyresgäster inte korskontaminerar
• Hålla sig aktuell automatiskt när din underliggande dokumentation ändras

Vad behöver du innan du börjar?

• Ett Retell AI-konto med en fungerande agent (funktionen kunskapsbas ingår i alla abonnemang)
• Din befintliga supportdokumentation i ett format du kan exportera till Markdown
• En lista med de 50 vanligaste uppringarfrågorna från de senaste 30 dagarnas telefon- eller chattärenden
• Redigeringsåtkomst till ditt hjälpcenter eller dina produktdokument (du kommer att skriva om vissa sidor)
• En timme för att utvärdera hämtningskvaliteten efter det första bygget

Hur bygger du en kunskapsbas för röst-AI som inte hallucinerar?

Steg 1: Hur granskar och kurerar du källinnehåll innან indexering?

Arkivera varje dokument som är föråldrat, motsägelsefullt eller inte den enda sanningskällan för sitt ämne innan du indexerar en enda sida. Den största källan till hallucinationer hos röstagenter är inte modellen. Det är motsägelsefullt eller föråldrat innehåll i källmaterialet.

Om två sidor är oense om ditt återbetalningsfönster har hämtaren inget sätt att välja rätt sida, och LLM:en läser självsäkert upp den chunk som vinner likhetspoängen. Ta fram varje dokument, FAQ och hjälpartikel du planerar att indexera. Kontrollera tre saker för var och en: är den aktuell för det här kvartalet, är den den enda sanningskällan för sitt ämne, och stämmer den med vad dina erfarna supportmedarbetare faktiskt säger på samtal. Om ett dokument inte bör användas för att besvara kundfrågor bör det inte finnas i din kunskapsbas över huvud taget. ElevenLabs

Du bör nu ha en kurerad uppsättning dokument som du skulle vara bekväm med att skicka ordagrant till en kund.

Steg 2: Varför Markdown, och hur ska du formatera det?

Konvertera allt till strukturerad Markdown med en H1 per dokument, en beskrivande H2 per lösbar användarfråga och korta stycken med tydliga subjekt. Röstagenter hämtar textchunks, inte renderade webbsidor. Markdown är det format som överlever chunking-pipelinen med mest semantisk struktur intakt.

Retells egen dokumentation rekommenderar Markdown framför .txt eftersom välstrukturerade rubriker ger hämtaren rena gränser att dela på. Ersätt varje "klicka här" eller "som beskrivits ovan" med den konkreta referensen, eftersom den chunk som innehåller "ovan" kan hämtas utan den chunk den pekar på. Varje chunk läses ensam, så varje chunk måste vara begriplig ensam.

Du bör nu ha en mapp med Markdown-filer där varje fil täcker ett produktområde och varje H2 täcker en lösbar användarfråga.

Steg 3: Vilken chunkstorlek fungerar bäst för röst-AI?

Använd rekursiv chunking vid 512 token med 10–15 % överlappning, och dela på Markdown-rubriker först, sedan stycken och sedan meningar. Det här är den benchmarkvaliderade standarden för allmänt RAG-innehåll, och den håller väl även för röstsupportmaterial specifikt.

En välinställd rekursiv splitter på 512 token med 15 % överlappning och metadataberikning presterar bättre än en dyr semantisk chunking-metod på de flesta verkliga dokumentuppsättningar. Långa chunks fyller LLM:ens kontextfönster med brus. Korta chunks fragmenterar instruktioner över flera hämtningar och får agenten att hoppa över steg mitt i en förklaring. Den hårda regeln: dela aldrig en numrerad procedur över två chunks. Om "Steg 3" finns i chunk A och "Steg 4" i chunk B kan hämtaren returnera den ena utan den andra och din agent hoppar över en åtgärd. Substack

Du bör nu ha chunks där varje enhet antingen innehåller en fullständig procedur eller innehåller kontextuell prosa som är begriplig utan sina grannar.

Steg 4: Vilken metadata ska du tagga varje chunk med?

Tagga varje chunk med minst fem fält: product, version, region, audience och last_verified_date. Det här är vad som hindrar en uppringare i Texas från att höra returpolicyer för Kalifornien och hindrar en ThinkPad-fråga från att dra fram ThinkCentre-svar.

Om en enda agent ser KB-innehåll för flera delstater eller platser kan hämtningen dra fram fel delstats chunk (t.ex. Kaliforniens policy för en uppringare i Texas) om inte avgränsning och metadata är noggrant utformade. Samma problem gäller produktlinjer, mjukvaruversioner, kundnivåer och supportkanaler. Vid körning skickar din agent de relevanta filtren tillsammans med förfrågan så att vektorsökningen bara beaktar chunks som matchar uppringarens kontext. I Retell kan du skicka dessa som dynamiska variabler som samlats in tidigare i samtalet. Optimize Smart

Du bör nu ha ett metadataschema där varje enskild chunk kan avgränsas unikt till en uppringarkontext.

Steg 5: Vilket tröskelvärde för hämtning stoppar hallucinationer?

Ställ in likhetströskelvärdet till 0,65 eller högre och begränsa hämtningen till 3–5 chunks. Ett hämtningssystem som alltid returnerar något är en förklädd hallucinationsmaskin.

När en uppringare frågar om en funktion du inte dokumenterar kommer hämtaren ändå att ta fram närmaste semantiska matchning. LLM:en får den chunken och väver flytande in den i ett felaktigt svar. I Retells inställningar för kunskapsbasen styr två parametrar detta beteende. Parametern "Chunks to retrieve" anger hur många resultat som matas in i LLM:en (standard 3, rekommenderat max 5 för röst). "Similarity Threshold" anger den minsta cosinuslikheten för att en chunk ska anses relevant (standard 0,6). För mjukvarusupportfall där felaktig information är värre än ingen information, höj tröskelvärdet till 0,7.

Du bör nu se att ditt hämtningssystem returnerar färre matchningar av högre kvalitet och avvisar marginella sådana.

Steg 6: Hur tvingar du agenten att avvisa i stället för att gissa?

Lägg till den här exakta instruktionen i agentprompten: "Svara endast med informationen i ## Related Knowledge Base Contexts. Om den sektionen saknas eller inte innehåller relevant information, säg att det inte finns någon relaterad information tillgänglig och erbjud att överföra samtalet." Den här enda instruktionen är den mest effektiva antihallucinationskontrollen i någon röstagent.

Utan den kommer LLM:en att gripa efter sin träningsdata när hämtningen kommer tillbaka tom. Det här är felläget bakom nästan varje offentlig chatbotkatastrof, inklusive Air Canadas fall med sorgebiljetter där flygbolaget hölls juridiskt ansvarigt. Avvisningsmönstret vänder felläget från "självsäkert felaktigt svar" till "ärligt låt-mig-hämta-en-människa", vilket är precis vad uppringare som använder din mjukvara faktiskt vill ha när systemet stöter på ett gränsfall.

Du bör nu se din agent säga "Jag har inte det dokumenterat; låt mig överföra dig" på frågor utanför omfånget i stället för att hitta på steg.

Steg 7: Hur håller du kunskapsbasen från att bli föråldrad?

Aktivera automatisk uppdatering på URL-källor så att Retell hämtar om var 24:e timme, versionshantera dina Markdown-filer i Git och kör en kvartalsvis granskning av alla filer med ett last_verified_date äldre än 90 dagar. Föråldrad kunskap är hallucinationens tysta partner.

Om kunskapsbasen är föråldrad hämtar RAG bara fel svar snabbare. Lösningen är att automatisera aktualitet i stället för att förlita sig på att någon minns att ladda upp filer på nytt när produktdokumenten ändras. Kombinera automatisk uppdatering med automatisk crawling av hjälpcentrets underväg så att nya artiklar indexeras automatiskt utan manuell åtgärd. CX Today

Du bör nu ha en kunskapsbas som uppdaterar sig själv när ditt underliggande innehåll uppdateras, utan någon människa i loopen.

Steg 8: Hur testar du hämtning innan du går live?

Kör dina 50 verkliga uppringarfrågor genom hämtningssystemet och inspektera vad som kommer tillbaka innan någon LLM-generering sker. Tre saker är viktiga för varje förfrågan: finns rätt chunk bland de tre översta, är likhetspoängen över ditt tröskelvärde, och skulle en människa som läser bara de hämtade chunksen kunna besvara frågan.

För varje fråga där hämtningen misslyckas ligger lösningen nästan alltid vid källan. Antingen saknas det relevanta innehållet helt, delade chunkingen en procedur över gränser, eller filtrerar metadatan bort det. Motstå frestelsen att åtgärda hämtningsfel genom att lägga till instruktioner i agentprompten. Promptlappningar är hur kunskapsbaser driver in i ett ohanterligt kaos. Sikta på 90 %+ hämtningsträffsäkerhet på testuppsättningen innan du driftsätter till live-samtal.

Du bör nu ha ett uppmätt hämtningsträffsäkerhetsvärde för dina vanligaste uppringarfrågor och en lista med källdokumentfixar för frågorna som misslyckades.

Steg 9: När ska du använda konversationsflöde i stället för en enda prompt?

Använd konversationsflöde med kunskapsbaser på nodnivå för alla röstagenter där uppringarens intention delar upp sig i distinkta arbetsflöden, särskilt mjukvarusupport, vårdbokning och miljöer med flera produkter. En platt kunskapsbas som ligger under en enda prompt är den lösaste möjliga arkitekturen.

För mjukvarusupport specifikt är mönstret av högsta kvalitet konversationsflöde där varje nod bara hämtar från den del av dokumentationen som är relevant för den delen av samtalet. Ett typiskt mjukvarusupportflöde har noder för triage, kontosökning, felsökning, eskalering och bekräftelse efter lösning. Felsökningsnoden laddar felsöknings-KB:n. Kontosökningsnoden laddar ingen KB alls eftersom den bör anropa ett API. Den här strukturen är mer tillförlitlig att underhålla än en enda gigantisk prompt med en enda gigantisk KB. Kombinera den med inbyggd analys efter samtal så att du kan se vilka noder som utlöser hämtning och vilka förfrågningar som kommer tillbaka under tröskelvärdet.

Du bör nu ha en driftsättning där hämtningsomfånget snävas in när samtalet smalnar av, i stället för att varje tur söker igenom varje dokument.

Hur ska du strukturera själva kunskapsbasen? En referens i Lenovo-stil

Nivåindela kunskapsbasen efter målgrupp och avgränsa hämtningen till uppringarens nivå. Det här är det strukturella mönster som Lenovos supportbibliotek för företag använder för att hålla lärarinriktat klassrumshanteringsinnehåll från att krocka med tekniskt ingenjörsinnehåll.

Lenovo etablerade tre nivåer av artiklar — allmänna ämnen och produktinformation, lärarspecifika ämnen samt tekniska ämnen och problem, med fokuserade artiklar, eliminerade redundanser och standardiserade namnkonventioner över alla tre nivåer. Tillämpa samma mönster på en kunskapsbas för röst-AI: Contiem

Nivå 1: Allmän produkt och prissättning. Publika fakta som varje uppringare kan tänkas fråga om. Taggade audience: all. Indexera allt.

Nivå 2: Steg-för-steg för slutanvändare. Steg-för-steg-procedurer för standarduppringaren. Taggade audience: end_user, avgränsade efter product och region. Den här nivån bär huvuddelen av hämtningstrafiken.

Nivå 3: Teknisk och admin. Konfiguration, integrationer och gränsfall. Taggade audience: admin. Hämtas bara när uppringaren har identifierats som administratör tidigare i samtalet.

Interna runbooks, eskaleringsmatriser och ingenjörsanteckningar läggs i en helt separat kunskapsbas, aldrig åtkomlig för den kundvända agenten. Nivåindelningen är vad som förhindrar att ett felsökningssamtal med en slutanvändare av misstag tar fram en intern eskaleringsprocedur.

Vilka är de bästa metoderna när kunskapsbasen är live?

Ska kunskapsbasen innehålla agentinstruktioner?

Nej. Kunskapsbasen är till för att förse med stödjande information, inte agentbeteende. Om du märker att du laddar upp en Markdown-fil med titeln "Hur agenten ska bete sig när X inträffar" hör det innehållet hemma i prompten eller i en konversationsflödesnod. Att blanda dem urvattnar båda: hämtaren rangordnar beteendeinstruktioner mot faktafrågor och drar fram dem vid fel tillfällen.

Hur ska du skriva rubriker för rösthämtning?

Led med användarens mål, inte funktionsnamnet. "Konfigurera tvåfaktorsautentisering" blir "Slå på tvåfaktorsinloggning". Hämtaren matchar mot uppringarens talade formuleringar, och naturliga språkfrågor matchar naturliga språkrubriker långt bättre än de matchar produktterminologi.

Varför ska varje chunk vara fristående?

Varje chunk hämtas ensam. Använd fullständiga namn i stället för pronomen, fullständiga produktnamn i stället för "plattformen", och upprepa varje villkorlig kontext i varje steg i stället för att säga "om du använder administratörskonsolen, då..." tre stycken senare. Den här enda regeln eliminerar en förvånande andel hallucinationer eftersom den tar bort den tvetydighet som LLM:en annars försöker lösa genom att gissa.

Hur felsöker du en hallucination i efterhand?

Fånga de hämtade chunksen, likhetspoängen och metadatafiltren på varje samtal tillsammans med transkriptet. Att bara logga det slutliga agentsvaret gör hallucinationsfelsökning nästan omöjlig: du ser det felaktiga svaret men inte om hämtaren returnerade fel chunk eller om rätt chunk genererades felaktigt. De flesta "hallucinations"-ärenden visar sig vara rangordningsproblem vid hämtning, vilka åtgärdas vid källan.

Varför hämtas tabelldata dåligt?

Chunking-pipelinen kan inte bevara de rumsliga relationer som gör tabeller läsbara, så en tabellcell hämtas ofta utan sin kolumnrubrik. Skriv om kritiska tabeller som prosa med tydliga meningar. "Pro-abonnemanget stöder 50 användare och inkluderar API-åtkomst" slår en tabellcell som hämtaren delar bort från sin kolumnrubrik.

Vilka är de vanliga fallgroparna och hur undviker du dem?

Varför är det ett misstag att dumpa hela hjälpcentret i en enda KB?

En kunskapsbas med 4 000 chunks där 50 är relevanta för en given uppringare är sämre än en med 400 chunks där 50 är relevanta, eftersom hämtaren har 10 gånger fler konkurrerande matchningar som förvirrar den. Bygg smala kunskapsbaser per arbetsflöde och länka dem på nodnivå i stället.

Varför ska du inte lappa hallucinationer i prompten?

När agenten säger något fel är instinkten att lägga till "säg inte X" i prompten. Tre av dessa och prompten blir motsägelsefull; tio och den blir ohanterlig. Ta reda på varför LLM:en sa X. Nästan alltid föreslog en chunk i KB:n det, eller så tvingade avsaknaden av en chunk modellen att falla tillbaka på träningsdata. Lappa källan.

Vad är kostnaden för överhämtning?

Varje extra chunk lägger till token i prompten och millisekunder till svaret. Att ställa in "chunks to retrieve" till 10 för att mer kontext känns säkrare är ett vanligt misstag. Håll dig till 3 chunks för typiskt supportinnehåll, öka till 5 bara när uppringarfrågor spänner över flera ämnen, och gå aldrig högre om du inte har mätt att det förbättrar träffsäkerheten.

Varför fortsätter offentliga chatbotmisslyckanden att inträffa?

För att agenten tillåts tala utan en uttrycklig avvisningsinstruktion. Air Canadas chatbot hölls ansvarig efter att ha genererat en obefintlig sorgepolicy som motsade flygbolagets faktiska regler, och liknande misslyckanden fortsätter återkomma hos leverantörer som hoppar över avvisningslagret. Gör avvisningen uttrycklig, testa att den utlöses och behandla varje fall där agenten hittar på information som en P0-bugg. CanLII

Varför ska du testa på nytt efter varje källuppdatering?

Att lägga till ett nytt dokument ändrar hämtningslandskapet för varje befintlig förfrågan. En chunk som rangordnades först i går kan rangordnas trea i dag. Håll 50-frågors-testuppsättningen automatiserad och kör den på nytt närhelst det underliggande innehållet ändras väsentligt.

Vilka resultat har verkliga team sett?

Hur använde SWTCH det här mönstret för support av EV-laddare?

SWTCH driftsatte en Retell-driven röstagent vid namn Lucas för att hantera supportsamtal om EV-laddare, där uppringare vanligtvis står vid en död laddare med lågt batteri och ingen tålamod för en felaktig instruktion. Implementeringen minskade supportkostnaderna med mer än 50 % och förbättrade SaaS-marginalerna avsevärt, med agenten som svarar på sekunder i stället för minuter. Tillförlitlighetsribban sattes av användningsfallet: ett felaktigt felsökningssteg är skillnaden mellan en fungerande laddare och en strandsatt förare.

Hur skalade Anker detta över global support?

Anker rullade ut Retell över global support för konsumentelektronik, där uppringare ställer produktspecifika frågor över dussintals SKU:er och flera språk. Fallstudien illustrerar varför metadataavgränsning är viktig i stor skala. Utan produktnivåfiltrering på hämtningen kan en soundbar-fråga dra in en dammsugarmanual, och agenten kombinerar dem självsäkert. Med rätt KB-struktur håller sig agenten inom produktkontexten under hela samtalet.

Vilken produktionsvolym har den här arkitekturen hanterat?

Retell AI driver nu 50 miljoner+ AI-telefonsamtal i realtid varje månad för kunder över tusentals företag, utan att någon agent rapporterats spåra ur över den volymen. Arkitekturen i den här guiden är samma som körs under de samtalen. Yahoo Finance

Vanliga frågor

Vilken är den bästa chunkstorleken för en kunskapsbas för röst-AI?

Rekursiv chunking vid 512 token med 10–15 % överlappning är den benchmarkvaliderade standarden. Mindre chunks (200–300 token) fungerar för FAQ-liknande innehåll; större chunks (1024 token) fungerar för berättande prosa. Dela alltid på Markdown-rubriker först, sedan stycken och sedan meningar.

Hur förhindrar jag LLM:en från att generera information som inte finns i kunskapsbasen?

Lägg till en uttrycklig avvisningsinstruktion i agentprompten: "Svara endast med informationen i ## Related Knowledge Base Contexts. Om den sektionen saknas eller inte innehåller relevant information, svara att det inte finns någon relaterad information tillgänglig." Kombinerat med ett likhetströskelvärde på 0,65 eller högre är detta den mest effektiva enskilda antihallucinationskontrollen.

Hur mycket latens lägger kunskapsbasen till per tur?

Under 100 ms per tur på Retells optimerade hämtnings-pipeline, vilket håller agenten inom det totala svarsfönstret på ~600 ms som uppringare förväntar sig. Om du ser väsentligt högre latens, kontrollera om du hämtar fler chunks än du behöver eller om metadatafiltrering tillämpas vid förfrågningstillfället i stället för efter hämtning.

Ska jag använda en enda prompt eller konversationsflöde med kunskapsbaser på nodnivå?

Konversationsflöde vinner för mjukvarusupport och alla scenarier där uppringarens intention delar upp sig i distinkta arbetsflöden. Kunskapsbaser på nodnivå låter varje konversationstillstånd hämta från en fokuserad del av innehållet, vilket förbättrar träffsäkerheten och gör underhållet enkelt. Enskilda prompter fungerar för smala användningsfall som en FAQ för en enda produkt. Retells guide om att driftsätta konversations-AI täcker det arkitektoniska valet mer i detalj.

Hur ofta ska jag uppdatera kunskapsbasen?

Aktivera automatisk uppdatering på URL-källor så att Retell hämtar om var 24:e timme. För uppladdade dokument, kör en manuell granskning närhelst den underliggande produkten eller policyn ändras och behandla allt äldre än 90 dagar som i behov av verifiering.

Kan jag träna röstagenten på mina samtalsinspelningar i stället för att skriva dokumentation?

Ja, delvis. Du kan använda lyckade samtalstranskript och inspelningar av erfarna medarbetare som källmaterial för kunskapsbasen. Extrahera fråga-och-svar-paren, konvertera dem till Markdown och indexera dem tillsammans med din formella dokumentation. Det är särskilt användbart för att fånga den specifika formulering dina bästa medarbetare använder, som ofta löser problem snabbare än den officiella hjälpcentertexten. Det ersätter inte strukturerad dokumentation; det kompletterar den.

Vilka metadatafält är viktigast för hämtning hos röstagenter?

Minst: product, version, region, audience och last_verified_date. Lägg till topic för granulär routning i ett konversationsflöde, och compliance_scope om du har reglerat innehåll (HIPAA, finansiell rådgivning) som aldrig ska hämtas utanför specifika samtalskontexter.

Hur testar jag om min kunskapsbas fungerar innan jag går live?

Bygg en testuppsättning med 50–100 verkliga uppringarfrågor från de senaste 30 dagarnas supportärenden. För var och en, inspektera de hämtade chunksen innan någon LLM-generering: finns rätt chunk bland de tre översta, är likhetspoängen över tröskelvärdet, och skulle en människa kunna besvara frågan från bara de chunksen. Sikta på 90 %+ hämtningsträffsäkerhet på testuppsättningen innan du driftsätter.

Vad händer när en uppringare frågar om något som inte finns i kunskapsbasen?

Med en avvisningsinstruktion på plats och ett likhetströskelvärde på 0,65 eller högre säger agenten att den inte har den informationen dokumenterad och erbjuder antingen att ta ett meddelande eller gör en förberedd överföring via samtalsöverföring till en mänsklig agent med full konversationskontext. Utan dessa kontroller faller agenten tillbaka på den underliggande LLM:ens träningsdata, vilket är precis det felläge som den här guiden är utformad för att förhindra.

Vad ska du göra härnäst?

Du har nu en kunskapsbasarkitektur som grundar varje agentsvar i verifierat innehåll, avgränsar hämtning efter uppringarkontext, vägrar svara när svaret inte är dokumenterat och uppdaterar sig själv när ditt källmaterial ändras. Det här är grunden som låter en röstagent hantera mjukvarusupport, reglerade branscher eller alla samtal med höga insatser där ett felaktigt steg spelar större roll än ett snabbt.

För att bygga vidare på detta stöder samma hämtningsarkitektur användningsfall som automatisering av AI-kundtjänst, leadskvalificering med produktspecifik routning, och AI-drivna receptionister för vårdmottagningar där compliance-avgränsning inte är förhandlingsbar. Samma mönster kartläggs även mot driftsättningar inom vård och försäkring där kostnaden för en hallucination är en regulatorisk fråga, inte bara en kundupplevelse.

Börja bygga gratis med 10 USD i användningskrediter på retellai.com.