Så håller du en kunskapsbas för röst-AI uppdaterad när din källa till sanning finns i SharePoint, Azure eller privata dokument
Ja, och arkitekturen är enkel när du slutar försöka få Copilot Studio att göra det. Du speglar auktoritativa dokument från SharePoint, OneDrive eller Azure Blob till ett vektorindex som agenten äger, och låter sedan Microsoft Graph-webhooks och Event Grid-notiser driva inkrementella uppdateringar. Ändringar i källan sprids till agenten på ensiffriga minuter. Inga omuppladdningar.
De flesta team stöter på det här problemet efter att de redan har provat de uppenbara vägarna. Copilot Studios SharePoint-kontakt uppdateras fortfarande inte automatiskt när filer ändras, en begränsning som Microsoft bekräftade i juli 2025 och som inte har åtgärdats när detta skrivs. Azure AI Search kan nå SharePoint via en indexerare, men indexeraren kan inte ligga bakom Conditional Access, har endast grundläggande ACL-stöd i förhandsversion och kräver att du bygger agentlagret själv. Mönstret som den här guiden beskriver använder Retell AI som röstlager eftersom dess kunskapsbas-API accepterar autentiserade pushar från din egen synk-arbetare, vilket kringgår varje begränsning som Microsofts förstahandsväg medför.
En röstagent som svarar utifrån en kurerad spegling av ditt privata korpus, där ändringar sprids från ände till ände på fem till femton minuter och med en daglig avstämningskörning som fångar upp allt som händelseströmmen tappar.
När du är klar kommer din stack att:
Innan du börjar behöver du:
Sites.Selected föredras, Sites.Read.All är det bredare reservalternativet)Eftersom verktygen designades för ett annat jobb. Copilot Studio byggdes för att sammanfatta innehåll åt en människa som läser en skärm, inte för att mata en röstagent som har under en sekund på sig att formulera ett talat svar. Azure AI Searchs SharePoint-indexerare byggdes för företagssök, där ett uppdateringsfönster på fyra till sex timmar är helt okej. Ingen av produkterna designades utifrån antagandet att en faktureringspolicy som ändras kl. 9.00 måste vara svaret som en uppringare hör kl. 9.08.
Tre begränsningar skiljer röst från text. Den första är latensbudgeten. Ett hämtningsanrop måste returnera på under 100 millisekunder under ett pågående samtal, så indexet måste ligga på samma nätverk som agenten, och segmenten måste vara små nog att bäddas in inline utan att spränga LLM:ens kontextfönster. Den andra är feltolerans. När en chatbot returnerar fel länk klickar användaren igen. När en röstagent citerar en avvecklad policy i ett inspelat efterlevnadssamtal har du ett problem med granskningsloggar kopplade till sig. Den tredje är förväntan på aktualitet. Säljteam justerar priser på tisdagar. Supportteam skickar ut policyuppdateringar efter en incidentgenomgång på fredagen. Agenten som citerar förra veckans siffra är värre än ingen agent alls.
Det är därför arkitekturen separerar källan till sanning från hämtningslagret. SharePoint förblir kanoniskt. Vektorindexet är en härledd artefakt som synk-pipelinen håller aktuell. Fellägen blir observerbara i stället för tysta.
Välj utifrån var dokumentet skapas, inte utifrån var det är enklast att koppla in. Varje källa signalerar något olika om hur innehållet underhålls.
SharePoint-dokumentbibliotek är rätt primärkälla när ägarskapet är kollaborativt och innehållet utvecklas genom kommittégranskning. Tjänstekataloger, policyhandböcker, interna wikis och säljmanualer tenderar att bo här, med versionshistorik, kommentarer och godkännandeflöden kopplade. Kostnaden är metadatakaos: en typisk webbplats innehåller fyra versioner av samma policy, två avvecklade utkast och någons skärmdumpsmapp.
OneDrive är sällan rätt primärkälla för en röstagent. Innehåll som är knutet till en enda persons konto följer med ut genom dörren när den personen slutar. Använd OneDrive endast som ett iordningställningsområde där enskilda medarbetare skapar utkast som befordras till ett SharePoint-bibliotek efter granskning.
Azure Blob-containrar är rätt källa när dokument produceras av uppströmssystem. Genererade PDF:er från en faktureringspipeline, avtal som släpps av ett CLM-verktyg, kontoutdrag från ett exportjobb och transkriptioner från ett inspelningssystem hör alla hemma i Blob. Volymen är högre, aktualiteten är svårare att fejka, och filnamngivningen följer den konvention som det producerande systemet upprätthåller, vilket gör spegla-och-synka enklare än SharePoints fritt formade struktur.
De flesta företagsteam synkar båda. SharePoint matar policy- och produktsidan, Blob matar den operativa och maskingenererade sidan, och röstagentens kunskapsbas slår ihop båda bakom ett enda hämtnings-API.
Registrera ett program i Microsoft Entra ID, begär programbehörigheter och låt en klientadministratör bevilja godkännande.
Programbehörigheter körs under en tjänstprincipal. Arbetaren fortsätter köra genom natten utan en inloggad användare, och token är konsekvent mellan anrop. Delegerade behörigheter binder däremot åtkomst till ett verkligt användarkonto och tvingar fram en omautentisering ungefär var 75:e minut enligt de säkerhetsbibliotek Microsoft nu använder. Delegerade behörigheter kan inte heller bevara ACL:er på dokumentnivå, som Microsofts egen dokumentation för SharePoint-indexeraren påpekar, vilket blir ett problem i samma ögonblick som efterlevnad frågar vem som får höra vad.
Omfattning är där de flesta team överdelar. Att bevilja Sites.Read.All låter appen läsa alla webbplatser i klientorganisationen. Det går snabbt vid uppsättning och är oförsvarbart i en granskning. Det snävare alternativet är Sites.Selected, där en klientadministratör förhandsgodkänner appen mot specifika webbplats-ID:n endast. Arbetaren ser de bibliotek som agenten behöver och inget annat. Använd Sites.Selected från dag ett. Att i efterhand fylla på med omfattning på webbplatsnivå kräver nytt godkännande och oftast en säkerhetsgranskning du inte budgeterade för.
För Azure Blob, tilldela samma tjänstprincipal rollen Storage Blob Data Reader på den specifika containern. Omfattning på containernivå slår omfattning på kontonivå av samma skäl.
Kombinera två Microsoft Graph-primitiver. Webhooks talar om för dig när något hände. Delta-frågor talar om exakt vad som ändrades.
En webhook-prenumeration är en POST till /subscriptions med en resurssökväg som pekar på enheten (till exempel /sites/{site-id}/drive/root), en changeType med updated, och en notificationUrl riktad mot din arbetares HTTPS-endpoint. Notiskroppen är avsiktligt tunn. Den bär resurs-ID:t och ändringstypen, inget mer. Detta är avsiktligt. Arbetaren använder notisen som en signal för att anropa delta-endpointen, där den faktiska nyttolasten bor.
Delta-frågan är /sites/{site-id}/drive/root/delta. Vid första körningen, ingen token, får du en fullständig uppräkning plus en ogenomskinlig @odata.deltaLink. Spara den länken ordagrant. Vid varje efterföljande körning spelar du upp den och Graph returnerar endast de objekt som lagts till, ändrats, döpts om eller tagits bort sedan förra anropet. Microsofts skanningsvägledning är tydlig: webhooks plus delta är det rekommenderade mönstret för stora bibliotek, eftersom ren polling ger dig strypning, och rena webhooks förlorar data om endpointen är långsam.
Två bitar folklore värda att känna till. Samma objekt kan förekomma mer än en gång på en delta-sida, avsiktligt, eftersom Graph expanderar mapphierarkier och slår ihop samtidiga ändringar. När dubbletter dyker upp, ta den sista förekomsten. Prenumerationer löper också ut. Förnya vid 75 % av maximal livslängd, inte vid deadline. Ett förnyelsejobb som misslyckas tyst är det enskilt vanligaste skälet till att en tidigare fungerande synk börjar driva mot inaktuellt innehåll, och du upptäcker det när en kund klagar.
Använd Event Grid för realtidsnotiser och change feed för batch-avstämning. De löser olika problem och produktionssvaret är att köra båda.
Event Grid skickar ut händelser i samma ögonblick som en blob skapas, ersätts eller tas bort. Prenumerera på lagringskontonivå, filtrera på eventType för Microsoft.Storage.BlobCreated och Microsoft.Storage.BlobDeleted, och dirigera till din arbetare. För Azure Data Lake Storage Gen2, lägg till ett filter på API-anropet FlushWithClose. Detta säkerställer att händelsen utlöses först efter att blobben är fullständigt committad. Hoppa över detta och du bearbetar partiella uppladdningar, vilket ger inläsningsfel som ser ut som filkorruption men inte är det.
Change feed är den ordnade, hållbara loggen bakom händelserna. Enligt Microsofts dokumentation tillhandahåller den en garanterad transaktionslogg som bevaras som Avro-filer i $blobchangefeed/log/, skriven inom några minuter från varje ändring. Event Grid är best-effort och kan tappa notiser under belastning. Change feed kan inte det. Kör ett dagligt jobb som går igenom change feed och stämmer av mot ditt kunskapsbas-manifest, så har du ett skyddsnät under realtidsvägen.
Kombinationen spelar roll. Event Grid ensamt är snabbt men förlustbenäget. Change feed ensamt är tillförlitligt men långsamt. Tillsammans ger de dig aktualitet i minutskala på den lyckliga vägen och full konsistens till morgonen på den olyckliga vägen.
Arbetaren laddar ner filen, normaliserar den och pushar den till plattformens API. Tre operationer: skapa, uppdatera, ta bort. Omdöpning kollapsar till ta-bort-plus-skapa.
Retell AI:s kunskapsbas accepterar en lång lista dokumentformat inklusive PDF, DOCX, PPTX, XLSX, CSV, TSV, TXT, MD, HTML, RTF, ODT, EPUB, plus meddelandeformat och flera bildtyper. Begränsningarna värda att känna till: 50 MB per fil, 25 filer per bas, och 1 000 rader gånger 50 kolumner för kalkylark. Markdown läses in renast när du styr källformatet, vilket är varför team ofta kör ett normaliseringssteg som konverterar skapade Word-dokument till Markdown innan de pushas.
När ett filantal växer förbi 25, dela upp baser per domän snarare än per avdelning. En faktureringsagent kopplad till "billing-policies-en", "service-catalog-2026" och "exception-cases" hämtar rent över alla tre eftersom hämtningslikhet beräknas per segment, inte per bas. Att dela upp per avdelning, å andra sidan, skapar fel gränser. Samma uppringarfråga spänner ofta över två avdelningar, och agenten hämtar bara från en av dem.
På den operativa sidan är idempotens det som räddar dig när samma notis kommer två gånger. Hasha varje fils innehåll och använd hashen som dokumentidentifierare. En dubblettnotis för en oförändrad fil producerar en no-op i stället för en dubblerad indexpost.
En ren textextraktor förlorar tyst 30 till 40 procent av meningen i en verklig PowerPoint eller ett finansiellt kalkylark. Agenten citerar sedan självsäkert de överlevande 60 procenten, inklusive de delar som inte längre är meningsfulla utan tabellen de kom från.
PowerPoint-filer kodar information i bildlayout, tabellceller, bildbaserade upplysningsrutor och talarnoteringar. Excel kodar mening i kolumnrubriker som spänner över sammanfogade celler, i formler som refererar till andra flikar, och i flikordning. Naiv textextraktion returnerar en platt sträng av ord med strukturen bortskalad. Två vägar överlever i produktion.
Den första är layoutmedveten tolkning. Verktyg som Unstructured, Azure Document Intelligence eller LlamaParse bevarar tabellceller och bildstruktur som Markdown. De är billigare per dokument och förutsägbara i utdata. Nackdelen är att de hanterar tabeller väl men diagram dåligt.
Den andra, som har fått fäste sedan mitten av 2025, är bildbaserad extraktion. Rendera varje bild eller ark till en bild och passera den genom en vision-kapabel LLM som returnerar Markdown. Utdatan återhämtar tabeller, diagram och visuella upplysningsrutor som textextraktorer missar. Kostnaden är högre per dokument och långsammare, vilket gör detta till rätt väg för de dokument som faktiskt spelar roll och fel väg för massinläsning av allt på en SharePoint-webbplats.
Beslutsregeln som håller: dirigera policydokument genom den billiga layoutmedvetna vägen, dirigera en liten uppsättning värdefulla visuella dokument (ensidesdokument, presentationer som chefer refererar till, prislistorna ditt säljteam faktiskt använder) genom den bildbaserade vägen. Försök inte använda ett tillvägagångssätt för allt.
Rekursiv teckenuppdelning vid 512 tokens med 10 till 20 procents överlapp, tre segment hämtade vid standardlikhet. Justera därifrån utifrån dina egna samtalsdata.
Detta är inte det populära svaret. Det populära svaret är semantisk segmentering, som låter smartare och presterar sämre i benchmarks. Den Vecta-benchmark som publicerades i början av 2026 satte rekursiv 512-token-uppdelning på 69 procents hämtningsnoggrannhet och semantisk segmentering på 54 procent på samma korpus av 50 dokument. NVIDIA:s forskning landar på samma ställe: faktabaserade frågor (den typ en röstagent får) presterar bäst vid 256 till 512 tokens, med 10 till 20 procents överlapp för att bevara meningskontext över gränser.
Den praktiska implikationen för synk: att ändra segmentstorlek eller inbäddningsmodell ogiltigförklarar varje befintligt segment i basen. Om hämtning plötsligt presterar sämre efter en justeringsrunda, lappa inte inkrementellt. Släpp basen, läs in källan på nytt, och acceptera ombearbetningskostnaden på några timmar. Klarheten du får på varje framtida svar är värd omtagningen.
Justering av hämtningströskeln sker efter att du har samtalsdata, inte innan. Dra 50 till 100 samtal från analys efter samtal, tagga fel-segment-fallen, och justera antingen segmenteringen av den felande källan eller likhetströskeln. De flesta team överjusterar först. Standardinställningarna är korrekta för 80 procent av användningsfallen.
Bygg ett slutet testflöde som spårar från ändring till talat svar med en unik testbar fras. Detta är den mest användbara femminuterskontrollen i hela pipelinen.
Välj ett dokument och redigera ett unikt numeriskt värde i det. "Rabatt på premiumnivå: 12,5 %" blir "Rabatt på premiumnivå: 14,0 %". Spara i SharePoint. Inom fem till femton minuter (Graph-notis, delta-bearbetning, inbäddning) bör ändringen vara live i indexet. Placera ett testsamtal där du ställer frågan. Om agenten säger 14,0 % fungerar loopen.
När den inte gör det, isoleras felet rent. Fick arbetaren webhooken? Kolla dina endpoint-loggar. Returnerade delta-frågan filen? Kolla arbetarloggarna. Lyckades uppladdningen? Kolla API-svaret. Kom segmentet in i hämtningen? Kolla samtalets hämtningslogg i analys efter samtal. Varje lager svarar på en ja/nej-fråga, och du hittar det trasiga lagret på under tio minuter.
Kör den här loopen efter varje meningsfull pipeline-ändring. Ny segmenteringsstrategi, ny inbäddningsmodell, ny källa, ny synk-arbetarversion. Om loopen sluts är ändringen säker att skicka. Om den inte gör det har du en exakt reproduktion av buggen.
Tre lager, tillämpade i den här ordningen. Rensa vid källan. Begränsa vid prompten. Observera vid samtalet.
Rensning vid källan är det lager som de flesta team hoppar över och betalar för senare. När en policy avvecklas, flytta filen ut ur den synkade mappen. Det renaste mönstret är en uppdelning i katalogerna synced/ och archive/ inuti samma SharePoint-bibliotek, där arbetaren endast bevakar synced/. Två indexerade versioner av samma policy är ett recept på självsäkra motsägelser, och du kan inte felsöka dig ur motstridiga källdokument.
Begränsning vid prompten är lager två. Instruera agenten att svara endast utifrån hämtad kunskapsbaskontext och att eskalera när ingen är tillgänglig. Publika benchmarks visar att grundad RAG minskar hallucinationsgraden med 26 till 43 procent jämfört med ogrundade LLM:er. Lyftet håller bara när hämtningen ytar rätt dokument. Ett svar av typen "inget svar hittat, kopplar dig vidare" är nästan alltid bättre än ett självsäkert felaktigt, och en eskaleringsregel som utlöses vid hämtning med låg likhet är en av de mest slagkraftiga inställningarna i agenten.
Observation vid samtalet är lager tre och där loopen sluts. Tagga varje miss med en kategori: saknad källa, fel segment hämtat, inaktuellt innehåll, modelltolkningsfel. Varje kategori har en annan åtgärd. Saknade källor går in i nästa inläsningsrunda. Fel segment betyder oftast att två dokument diskuterar liknande ämnen med olika vokabulär, vilket åtgärdas med metadatataggar eller genom att dela upp källan. Inaktuellt innehåll spåras tillbaka till ett webhook-glapp som den dagliga avstämningen borde ha fångat, men inte gjorde, vilket är en bugg i ditt avstämningsjobb.
För ett team som hanterar 5 000 samtal per månad på tre minuter styck är kunskapsbasanvändning den minsta posten med en storleksordning.
Retell AI debiterar $0.07 per minut för baskostnaden för samtal, med kunskapsbasanvändning på $0.005 per minut ovanpå. Varje arbetsyta inkluderar 10 kostnadsfria kunskapsbaser. Ytterligare baser kostar $8 per månad. För 15 000 minuters månatlig samtalstid lägger kunskapsbasanvändning till $75. Baskostnaden för samtal är $1 050. Jämför båda med SDR- eller receptionslönen som agenten uppväger och matematiken blir uppenbar. Priser är konsekventa oavsett om du använder en bas eller sju, och det finns ingen plattformsavgift ovanpå.
De dolda kostnaderna är på Microsoft-sidan, och de är oftast små men lätta att felkonfigurera. Microsoft Graph debiterar per anrop. Azure Event Grid debiterar per miljon operationer. Båda är ören vid typisk synkvolym. Sättet du gör detta till en verklig räkning på är genom att polla SharePoint var 30:e sekund i stället för att prenumerera på webhooks. En sådan bugg har spikat Azure-förbrukningsavgifter med en faktor femtio för åtminstone ett team jag har sett. Webhook plus delta håller räkningen platt oavsett hur ofta källan ändras.
Dessa återkommer tillräckligt ofta över driftsättningar för att förtjäna en checklista.
Webhook-prenumerationens utgång. Prenumerationer förnyar inte sig själva. Lägg till utgång i din larmning och förnya vid 75 procent av maximal livslängd. Tyst utgång är den vanligaste orsaken till drift.
Hantering av borttagning. De flesta team skickar synk som hanterar skapade och uppdaterade filer och glömmer bort borttagna. Agenten citerar sedan en policy som avvecklades för tre månader sedan. Koppla in ändringstypen deleted som ett förstklassigt fall, inte ett kantfall.
Läsomfattning för hela klientorganisationen. Att bevilja Sites.Read.All vid uppsättning går snabbt. Sex månader senare, när en revisor frågar vilka webbplatser rösttjänstens tjänstprincipal kan se, är "alla" fel svar. Använd Sites.Selected från början.
Dokument över taket på 50 MB. Långa handböcker misslyckas tyst med uppladdning när de överskrider gränsen per fil. Förbehandla dokument av översstorlek genom att dela på logiska gränser (kapitel, avsnitt, produktlinje) och ladda upp varje del som sitt eget dokument. Behåll förälder-barn-metadata så att hämtning kan sy ihop dem igen vid behov.
Drift mellan iordningställnings- och produktionskunskapsbaser. Team bygger en synk-pipeline mot en iordningställningsbas, kopierar agentkonfigurationen till produktion, och glömmer att produktionsagenten fortfarande pekar på förra kvartalets manuellt uppladdade filer. Gör kunskapsbas-ID:t explicit i din driftsättningskonfiguration och verifiera det efter varje release.
Ja. Arkitekturen är tjänstprincipal-autentisering via Microsoft Entra ID, filer hämtade över en autentiserad Graph-kanal, och uppladdningar pushade till kunskapsbas-API:t över HTTPS. Källdokument stannar i SharePoint med sina befintliga ACL:er. Kunskapsbasen håller en indexerad kopia som endast används för hämtning under samtal, och du kan begränsa tjänstprincipalen till en enda webbplats om efterlevnad kräver det.
Fem till femton minuter från ände till ände på den lyckliga vägen. Fördelningen: Graph-webhook-leverans inom några minuter, delta-fråga och nedladdning på under en minut, tolkning och inbäddning på en till tre minuter beroende på dokumentstorlek. När det väl är indexerat lägger hämtning till under 100 millisekunder under själva samtalet, så uppringare uppfattar ingen paus.
Ett dagligt avstämningsjobb spelar upp delta-frågan och jämför resultaten mot kunskapsbas-manifestet, och fångar upp allt som Event Grid eller Graph missade. Kombinationen av realtidswebhooks och en daglig delta-svep är standardmönstret, rekommenderat i Microsofts egen ingenjörsskrift just eftersom notiser är best-effort.
Ja. Samma arbetarmönster gäller för Google Drive (via Drive Activity API), Amazon S3 (via S3 Event Notifications), Confluence, Notion och alla källor som skickar ut ändringshändelser. Kunskapsbas-API:t är källagnostiskt. Den enda biten som ändras är autentiserings- och händelselyssningskoden.
Copilot Studios SharePoint-kontakt uppdateras inte automatiskt när filer ändras, en begränsning som Microsoft bekräftade i mitten av 2025 och som inte har skickat en fix när detta skrivs. Kringgåenden involverar Power Automate-flöden som utlöser manuella uppdateringar. Utöver synkproblemet är Copilot Studio byggt för chattytor och producerar inte röstlatens under en sekund. För telefonagenter är arkitekturen i den här guiden vägen.
Retell AI levereras med SOC 2 Type II, HIPAA med självbetjänings-BAA, och GDPR, plus konfigurerbar datalagring och PII-redigering. För vård-arbetsbelastningar är standardmönstret att grinda BAA:n innan någon PHI vidrör indexet. Efterlevnadshållning mot ditt specifika regelverk är din att validera. Certifieringarna på infrastrukturnivå täcker plattformen, inte din innehållsklassificeringspolicy.
Ja. En agent kan ha flera kunskapsbaser länkade, och varje bas kan hämta från en annan källpipeline. Ett vanligt mönster är en bas per logisk domän (fakturering, support, produktspecifikationer) med källor rent separerade. Noder i konversationsflöden kan också binda en annan bas till en specifik nod när sälj- och supportvägar behöver distinkt kontext.
En ingenjör som är bekväm med OAuth och webhooks för synklagret, en driftansvarig för agentbygget och promptjusteringen, och en innehållsansvarig som avgör vad som hör hemma i den synkade mappen. Uppdelningen som fungerar i praktiken: IT äger arbetaren och autentiseringen; drift äger agenten; innehållsteamet äger vad som är i omfattning. Arkitekturen stöder en enpersonsuppsättning för proof of concept och skalar utan omarkitektur.
Azure AI Searchs SharePoint-indexerare hanterar inläsning väl men har hårda gränser värda att känna till. Den stöder inte klientorganisationer med Conditional Access aktiverat. ACL-bevarande är i publik förhandsversion, inte GA. Uppdateringslatensen körs i timmar, inte minuter. Och du behöver fortfarande bygga röstagentlagret ovanpå. För ren företagssök är AI Search helt okej. För röst är mönstret synka-in-i-Retell-AI operativt enklare och snabbare att driftsätta.
Rekursiv 512-token-uppdelning med 10 till 20 procents överlapp. Detta är den benchmark-validerade standarden över 2026 års utvärderingar och överträffar semantisk segmentering med ungefär 15 poäng på verkliga dokumentkorpusar. Tre segment hämtade vid standardlikhet. Justera först efter att du har 50 till 100 verkliga samtalstranskriptioner att informera ändringen med.
Synk-pipelinen är den oglamorösa halvan av röst-AI, och det är också halvan som avgör om driftsättningen skickas eller stannar upp. En pilot som "fungerar på demodata" och faller ihop i samma ögonblick som en policy ändras är signaturfelläget i det här utrymmet, och arkitekturen ovan är fixen.
När kunskapsbasen väl är stabil expanderar samma agent till angränsande arbetsflöden på samma data. AI-kundtjänst för inkommande frågor, leadskvalificering för utgående, en receptionist som dirigerar till endera. Korpuset du har kurerat för ett blir källan till sanning för alla.
Börja kostnadsfritt med $10 i kredit på retellai.com.
See how much your business could save by switching to AI-powered voice agents.
Total Human Agent Cost
AI Agent Cost
Estimated Savings
Ett demonummer från Retell Clinic Office
Start building smarter conversations today.
.avif)
.avif)
