Hoe houd je een voice-AI-kennisbank up-to-date wanneer je bron van waarheid in SharePoint, Azure of privΓ©documenten staat

Hoe houd je een voice-AI-kennisbank up-to-date wanneer je bron van waarheid in SharePoint, Azure of privΓ©documenten staat
BACK TO BLOGS
ON THIS PAGE
Back to top

Kan een voice-AI omgaan met een kennisbank die wekelijks verandert, terwijl je bron van waarheid in SharePoint, Azure of privΓ©documenten staat?

Ja, en de architectuur is eenvoudig zodra je stopt met proberen Copilot Studio dit te laten doen. Je spiegelt gezaghebbende documenten uit SharePoint, OneDrive of Azure Blob naar een vector-index die de agent zelf bezit, en laat vervolgens Microsoft Graph webhooks en Event Grid-meldingen incrementele updates aansturen. Bewerkingen in de bron worden binnen enkele minuten doorgevoerd naar de agent. Zonder opnieuw uploaden.

De meeste teams lopen tegen dit probleem aan nadat ze de voor de hand liggende paden al hebben geprobeerd. De SharePoint-connector van Copilot Studio ververst nog steeds niet automatisch wanneer bestanden veranderen, een beperking die Microsoft in juli 2025 bevestigde en die op het moment van schrijven niet is opgelost. Azure AI Search kan SharePoint bereiken via een indexer, maar de indexer kan niet achter Conditional Access staan, heeft in preview slechts basale ACL-ondersteuning, en vereist dat je de agentlaag zelf bouwt. Het patroon dat deze gids beschrijft gebruikt Retell AI als de stemlaag omdat de kennisbank-API geauthenticeerde pushes accepteert van je eigen synchronisatieworker, wat elke beperking omzeilt die de first-party-route van Microsoft oplegt.

Wat ga je bouwen

Een stemagent die antwoordt vanuit een samengestelde spiegel van je privΓ©corpus, waarbij bewerkingen end-to-end binnen vijf tot vijftien minuten worden doorgevoerd, plus een dagelijkse reconciliatiepass die opvangt wat de eventstream mist.

Aan het eind zal je stack:

  • Geauthenticeerde content ophalen uit SharePoint-sites, OneDrive-mappen, Azure Blob-containers en elk ander systeem dat wijzigingsgebeurtenissen uitzendt
  • Aangemaakte, bijgewerkte, hernoemde en verwijderde bestanden verwerken als vier verschillende gebeurtenistypes
  • Alleen de chunks opnieuw embedden die bij gewijzigde documenten horen, en de rest van de index onaangeroerd laten
  • Elk gesproken antwoord terugleiden naar het document en de chunk die het onderbouwden
  • Zichzelf herstellen wanneer webhook-bezorging uitvalt, door delta-queries volgens schema opnieuw af te spelen

Vereisten

Voordat je begint, heb je nodig:

  • Tenant-adminrechten in Microsoft Entra ID om een app te registreren en application permissions te verlenen (Sites.Selected heeft de voorkeur, Sites.Read.All is de bredere terugvaloptie)
  • Een storage-account op Azure van het type StorageV2, BlockBlobStorage of BlobStorage als Blob deel uitmaakt van je bronset, aangezien general-purpose v1-accounts niet naar Event Grid kunnen publiceren
  • Een HTTPS-endpoint dat binnen drie seconden een 2xx-respons teruggeeft, anders laat Microsoft Graph de melding vallen en probeert het tot vier uur lang opnieuw
  • Een werkende kennis van OAuth 2.0 client-credential-flows, of een low-code automatiseringsrunner die auth voor je afhandelt (n8n, Make, Power Automate of Azure Logic Apps werken allemaal)
  • Een Retell AI-workspace (10 gratis kennisbanken inbegrepen, $10 aan startkrediet)

Waarom verslaat dit probleem de meeste first-party-tools?

Omdat de tools voor een andere taak zijn ontworpen. Copilot Studio is gebouwd om content samen te vatten voor een mens die een scherm leest, niet om een stemagent te voeden die minder dan een seconde heeft om een gesproken antwoord samen te stellen. De SharePoint-indexer van Azure AI Search is gebouwd voor enterprise search, waar een verversvenster van vier tot zes uur prima is. Geen van beide producten is ontworpen rond de aanname dat een facturatiebeleid dat om 9.00 uur wordt bewerkt, het antwoord moet zijn dat een beller om 9.08 uur hoort.

Drie beperkingen scheiden stem van tekst. De eerste is het latency-budget. Een ophaalcall moet in minder dan 100 milliseconden terugkomen tijdens een live gesprek, dus de index moet op hetzelfde netwerk als de agent staan, en de chunks moeten klein genoeg zijn om inline te embedden zonder het contextvenster van de LLM te overschrijden. De tweede is fouttolerantie. Wanneer een chatbot de verkeerde link teruggeeft, klikt de gebruiker opnieuw. Wanneer een stemagent een ingetrokken beleid citeert tijdens een opgenomen compliancegesprek, heb je een probleem met auditlogs eraan vast. De derde is de versheidsverwachting. Salesteams passen prijzen aan op dinsdag. Supportteams brengen beleidsupdates uit na een incidentreview op vrijdag. De agent die het cijfer van vorige week citeert, is erger dan helemaal geen agent.

Daarom scheidt de architectuur de bron van waarheid van de ophaallaag. SharePoint blijft canoniek. De vector-index is een afgeleid artefact dat de synchronisatiepipeline actueel houdt. Foutmodi worden observeerbaar in plaats van stil.

Hoe kies je tussen SharePoint, OneDrive en Azure Blob als bron?

Kies op basis van waar het document wordt geschreven, niet op basis van waar het het makkelijkst aan te sluiten is. Elke bron signaleert iets anders over hoe de content wordt onderhouden.

SharePoint-documentbibliotheken zijn de juiste primaire bron wanneer eigenaarschap collaboratief is en content evolueert via commissiereview. Servicecatalogi, beleidshandboeken, interne wiki's en salesplaybooks staan hier vaak, met versiegeschiedenis, opmerkingen en goedkeuringsflows eraan vast. De prijs is metadata-wildgroei: een typische site bevat vier versies van hetzelfde beleid, twee ingetrokken concepten en iemands screenshotmap.

OneDrive is zelden de juiste primaire bron voor een stemagent. Content die aan het account van één persoon is gekoppeld, loopt de deur uit wanneer die persoon vertrekt. Gebruik OneDrive alleen als staging-gebied waar individuele medewerkers concepten schrijven die na review naar een SharePoint-bibliotheek worden gepromoveerd.

Azure Blob-containers zijn de juiste bron wanneer documenten door upstream-systemen worden geproduceerd. Gegenereerde PDF's uit een facturatiepipeline, contracten neergezet door een CLM-tool, overzichten uit een exportjob en transcripties uit een opnamesysteem horen allemaal thuis in Blob. Het volume is hoger, de versheid is moeilijker te faken, en de bestandsnaamgeving volgt welke conventie het producerende systeem ook afdwingt, wat spiegelen-en-synchroniseren eenvoudiger maakt dan de vrije structuur van SharePoint.

De meeste enterprise-teams synchroniseren beide. SharePoint voedt de beleids- en productkant, Blob voedt de operationele en machine-gegenereerde kant, en de kennisbank van de stemagent voegt beide samen achter één enkele ophaal-API.

Hoe authenticeer je zonder de bron bloot te stellen?

Registreer een application in Microsoft Entra ID, vraag application permissions aan, en laat een tenant-admin toestemming verlenen.

Application permissions draaien onder een service principal. De worker blijft de hele nacht doordraaien zonder een ingelogde gebruiker, en de token is consistent over alle calls. Delegated permissions daarentegen koppelen toegang aan een echt gebruikersaccount en forceren ongeveer elke 75 minuten een re-auth, volgens de beveiligingsbibliotheken die Microsoft nu gebruikt. Delegated permissions kunnen ook geen ACL's op documentniveau behouden, zoals de eigen SharePoint-indexer-documentatie van Microsoft opmerkt, wat een probleem wordt op het moment dat compliance vraagt wie wat kan horen.

Scope is waar de meeste teams te veel delen. Het verlenen van Sites.Read.All laat de app elke site in de tenant lezen. Het is snel bij de setup en onverdedigbaar in een audit. Het strakkere alternatief is Sites.Selected, waarbij een tenant-admin de app vooraf autoriseert tegen alleen specifieke site-ID's. De worker ziet de bibliotheken die de agent nodig heeft en niets meer. Gebruik Sites.Selected vanaf dag één. Het achteraf toevoegen van scoping op siteniveau vereist opnieuw toestemming en meestal een securityreview die je niet had begroot.

Wijs voor Azure Blob dezelfde service principal de rol Storage Blob Data Reader toe op de specifieke container. Scope op containerniveau verslaat scope op accountniveau om dezelfde reden.

Hoe stream je bestandswijzigingen vanuit SharePoint naar een synchronisatieworker?

Combineer twee Microsoft Graph-primitieven. Webhooks vertellen je wanneer er iets is gebeurd. Delta-queries vertellen je precies wat er is veranderd.

Een webhook-abonnement is een POST naar /subscriptions met een resourcepad dat naar de drive wijst (bijvoorbeeld /sites/{site-id}/drive/root), een changeType van updated, en een notificationUrl gericht op het HTTPS-endpoint van je worker. De meldingsbody is opzettelijk dun. Deze bevat de resource-ID en het wijzigingstype, meer niet. Dit is bewust zo. De worker gebruikt de melding als signaal om het delta-endpoint aan te roepen, waar de eigenlijke payload staat.

De delta-query is /sites/{site-id}/drive/root/delta. Bij de eerste run, geen token, krijg je een volledige enumeratie plus een opake @odata.deltaLink. Bewaar die link letterlijk. Bij elke volgende run speel je deze opnieuw af en geeft Graph alleen de items terug die sinds de laatste call zijn toegevoegd, gewijzigd, hernoemd of verwijderd. De scan-richtlijn van Microsoft is expliciet: webhooks plus delta is het aanbevolen patroon voor grote bibliotheken, omdat pure polling je throttling oplevert en pure webhooks data verliezen als het endpoint traag is.

Twee stukjes folklore die het weten waard zijn. Hetzelfde item kan meer dan eens verschijnen in een delta-pagina, bewust, omdat Graph mappenhiΓ«rarchieΓ«n uitvouwt en gelijktijdige wijzigingen samenvoegt. Neem bij duplicaten het laatste voorkomen. Abonnementen verlopen ook. Vernieuw op 75% van de maximale levensduur, niet op de deadline. Een vernieuwingsjob die stil faalt is de allervaakst voorkomende reden dat een eerder werkende synchronisatie begint af te drijven naar verouderde content, en je komt erachter wanneer een klant klaagt.

Hoe stream je bestandswijzigingen vanuit Azure Blob Storage?

Gebruik Event Grid voor realtime-meldingen en de change feed voor batch-reconciliatie. Ze lossen verschillende problemen op en het productieantwoord is om beide te draaien.

Event Grid pusht gebeurtenissen op het moment dat een blob wordt aangemaakt, vervangen of verwijderd. Abonneer op het storage-account, filter op eventType voor Microsoft.Storage.BlobCreated en Microsoft.Storage.BlobDeleted, en route naar je worker. Voeg voor Azure Data Lake Storage Gen2 een filter toe op de FlushWithClose-API-call. Dit zorgt ervoor dat de gebeurtenis pas afgaat nadat de blob volledig is gecommit. Sla dit over en je verwerkt gedeeltelijke uploads, wat ingestiefouten produceert die eruitzien als bestandscorruptie maar dat niet zijn.

De change feed is de geordende, duurzame log achter de gebeurtenissen. Volgens de documentatie van Microsoft biedt deze een gegarandeerde transactielog die wordt bewaard als Avro-bestanden in $blobchangefeed/log/, geschreven binnen enkele minuten na elke wijziging. Event Grid is best-effort en kan meldingen laten vallen onder belasting. De change feed kan dat niet. Draai een dagelijkse job die de change feed doorloopt en reconcilieert tegen je kennisbank-manifest, en je hebt een vangnet onder het realtime-pad.

De combinatie doet ertoe. Event Grid alleen is snel maar verliesgevoelig. De change feed alleen is betrouwbaar maar traag. Samen geven ze je versheid op minuutschaal op het gelukkige pad en volledige consistentie tegen de ochtend op het ongelukkige pad.

Hoe push je gewijzigde bestanden naar de kennisbank van de stemagent?

De worker downloadt het bestand, normaliseert het, en pusht het naar de platform-API. Drie operaties: create, update, delete. Hernoemen valt samen tot delete-plus-create.

De Retell AI- kennisbank accepteert een lange lijst documentformaten waaronder PDF, DOCX, PPTX, XLSX, CSV, TSV, TXT, MD, HTML, RTF, ODT, EPUB, plus berichtformaten en verschillende beeldtypes. De beperkingen die het weten waard zijn: 50 MB per bestand, 25 bestanden per kennisbank, en 1.000 rijen bij 50 kolommen voor spreadsheets. Markdown wordt het schoonst geΓ―ngest wanneer je het bronformaat beheerst, wat de reden is dat teams vaak een normalisatiestap draaien die geschreven Word-documenten omzet naar Markdown voordat ze pushen.

Wanneer een bestandsaantal boven de 25 groeit, splits je kennisbanken op domein in plaats van op afdeling. Een facturatieagent die is gekoppeld aan "billing-policies-en", "service-catalog-2026" en "exception-cases" haalt schoon op over alle drie, omdat de ophaalsimilariteit per chunk wordt berekend, niet per kennisbank. Splitsen op afdeling daarentegen creëert de verkeerde grenzen. Dezelfde bellervraag overspant vaak twee afdelingen, en de agent zal maar uit één ervan ophalen.

Voor de operationele kant is idempotentie wat je redt wanneer dezelfde melding twee keer aankomt. Hash de content van elk bestand en gebruik de hash als de documentidentificatie. Een dubbele melding voor een ongewijzigd bestand levert een no-op op in plaats van een dubbele index-entry.

Wat is de juiste manier om PowerPoints, tabellen en layout-zware documenten af te handelen?

Een pure tekstextractor verliest stilletjes 30 tot 40 procent van de betekenis in een echte PowerPoint of financiΓ«le werkmap. De agent citeert vervolgens vol vertrouwen de overgebleven 60 procent, inclusief de delen die geen zin meer hebben zonder de tabel waar ze uit komen.

PowerPoints coderen informatie in slide-layout, tabelcellen, beeldgebaseerde callouts en sprekernotities. Excel codeert betekenis in kolomkoppen die samengevoegde cellen overspannen, in formules die naar andere tabbladen verwijzen, en in tabbladvolgorde. NaΓ―eve tekstextractie geeft een platte reeks woorden terug met de structuur eraf gestript. Twee paden overleven in productie.

Het eerste is layout-bewust parsen. Tools zoals Unstructured, Azure Document Intelligence of LlamaParse behouden tabelcellen en slide-structuur als Markdown. Ze zijn goedkoper per document en voorspelbaar in output. Het nadeel is dat ze tabellen goed afhandelen maar grafieken slecht.

Het tweede, dat sinds midden 2025 aan populariteit heeft gewonnen, is beeldgebaseerde extractie. Render elke slide of blad naar een afbeelding en stuur die door een vision-capable LLM die Markdown teruggeeft. De output herstelt tabellen, grafieken en visuele callouts die tekstextractors missen. De kosten zijn hoger per document en trager, wat dit het juiste pad maakt voor de documenten die er echt toe doen en het verkeerde pad voor bulk-ingestie van alles in een SharePoint-site.

De beslisregel die standhoudt: route beleidsdocumenten via het goedkope layout-bewuste pad, route een kleine set waardevolle visuele documenten (one-pagers, slidedecks waar leidinggevenden naar verwijzen, de tariefkaarten die je salesteam daadwerkelijk gebruikt) via het beeldgebaseerde pad. Probeer niet één aanpak voor alles te gebruiken.

Welke chunking- en ophaalinstellingen werken echt?

Recursieve karaktersplitsing op 512 tokens met 10 tot 20 procent overlap, drie chunks opgehaald op standaardsimilariteit. Stem vanaf daar af op basis van je eigen gespreksdata.

Dit is niet het populaire antwoord. Het populaire antwoord is semantische chunking, wat slimmer klinkt en slechter benchmarkt. De Vecta-benchmark, gepubliceerd begin 2026, zette recursieve 512-token-splitsing op 69 procent ophaalnauwkeurigheid en semantische chunking op 54 procent op hetzelfde corpus van 50 documenten. NVIDIA's onderzoek komt op dezelfde plek uit: feitelijke queries (het soort dat een stemagent krijgt) presteren het best op 256 tot 512 tokens, met 10 tot 20 procent overlap om zinscontext over grenzen heen te behouden.

De praktische implicatie voor synchronisatie: het veranderen van chunkgrootte of embeddingmodel maakt elke bestaande chunk in de kennisbank ongeldig. Als het ophalen na een afstempas plotseling slechter presteert, patch dan niet incrementeel. Verwijder de kennisbank, ingest de bron opnieuw, en accepteer de herverwerkingskost van enkele uren. De helderheid die je krijgt bij elk toekomstig antwoord is de herdoening waard.

Het afstemmen van de ophaaldrempel gebeurt nadat je gespreksdata hebt, niet ervoor. Haal 50 tot 100 gesprekken op uit analyse na het gesprek, tag de verkeerde-chunk-fouten, en pas ofwel de chunking van de betreffende bron aan ofwel de similariteitsdrempel. De meeste teams overtunen in het begin. De standaardinstellingen zijn correct voor 80 procent van de use cases.

Hoe verifieer je dat de synchronisatielus echt end-to-end werkt?

Bouw een gesloten-luscheck die traceert van bewerking tot gesproken antwoord met een unieke testbare zin. Dit is de nuttigste controle van vijf minuten in de hele pipeline.

Kies een document en bewerk er een unieke numerieke waarde in. "Premium tier-korting: 12,5%" wordt "Premium tier-korting: 14,0%". Sla op in SharePoint. Binnen vijf tot vijftien minuten (Graph-melding, delta-verwerking, embedding) moet de wijziging live zijn in de index. Plaats een testgesprek waarin je de vraag stelt. Als de agent 14,0% zegt, werkt de lus.

Wanneer dat niet zo is, isoleert de fout zich schoon. Heeft de worker de webhook ontvangen? Controleer je endpoint-logs. Gaf de delta-query het bestand terug? Controleer de worker-logs. Slaagde de upload? Controleer de API-respons. Kwam de chunk in het ophalen terecht? Controleer de ophaallog van het gesprek in analyse na het gesprek. Elke laag beantwoordt een ja/nee-vraag, en je vindt de kapotte laag binnen tien minuten.

Draai deze lus na elke betekenisvolle pipeline-wijziging. Nieuwe chunking-strategie, nieuw embeddingmodel, nieuwe bron, nieuwe synchronisatieworker-versie. Als de lus sluit, is de wijziging veilig om uit te rollen. Als dat niet zo is, heb je een precieze reproductie van de bug.

Hoe voorkom je dat de agent hallucineert wanneer bronnen conflicteren?

Drie lagen, toegepast in deze volgorde. Snoei bij de bron. Beperk bij de prompt. Observeer bij het gesprek.

Snoeien bij de bron is de laag die de meeste teams overslaan en er later voor betalen. Wanneer een beleid wordt ingetrokken, verplaats het bestand dan uit de gesynchroniseerde map. Het schoonste patroon is een synced/- en archive/-directorysplitsing binnen dezelfde SharePoint-bibliotheek, waarbij de worker alleen naar synced/ kijkt. Twee geΓ―ndexeerde versies van hetzelfde beleid is een recept voor zelfverzekerde tegenstrijdigheden, en je kunt je niet uit conflicterende brondocumenten heen debuggen.

Beperken bij de prompt is laag twee. Instrueer de agent om alleen te antwoorden vanuit opgehaalde kennisbank-context en te escaleren wanneer er geen beschikbaar is. Publieke benchmarks tonen dat gegronde RAG hallucinatiepercentages met 26 tot 43 procent verlaagt ten opzichte van ongegronde LLM's. De verbetering houdt alleen stand wanneer het ophalen het juiste document naar boven haalt. Een antwoord "geen antwoord gevonden, ik verbind je door" is bijna altijd beter dan een zelfverzekerd verkeerd antwoord, en een escalatieregel die afgaat bij ophalen met lage similariteit is een van de instellingen met de hoogste hefboomwerking in de agent.

Observeren bij het gesprek is laag drie en waar de lus sluit. Tag elke misser met een categorie: ontbrekende bron, verkeerde chunk opgehaald, verouderde content, modelinterpretatiefout. Elke categorie heeft een andere fix. Ontbrekende bronnen gaan naar de volgende ingestiepas. Verkeerde chunks betekenen meestal dat twee documenten vergelijkbare onderwerpen bespreken met verschillend vocabulaire, wat je oplost met metadata-tags of door de bron te splitsen. Verouderde content leidt terug naar een webhook-gat dat de dagelijkse reconciliatie had moeten opvangen, maar niet deed, wat een bug is in je reconciliatiejob.

Wat zijn de werkelijke kosten om dit te draaien?

Voor een team dat 5.000 gesprekken per maand afhandelt van elk drie minuten, is kennisbankgebruik met een orde van grootte de kleinste kostenpost.

Retell AI factureert $0,07 per minuut voor de basisgesprekskost, met kennisbankgebruik daarbovenop van $0,005 per minuut. Elke workspace bevat 10 gratis kennisbanken. Extra kennisbanken kosten $8 per maand. Voor 15.000 minuten maandelijkse gesprekstijd voegt kennisbankgebruik $75 toe. De basisgesprekskost is $1.050. Vergelijk beide met het SDR- of frontdesksalaris dat de agent compenseert en de rekensom wordt duidelijk. De prijzen zijn consistent of je nu één kennisbank of zeven gebruikt, en er komt geen platformkost bovenop.

De verborgen kosten zitten aan de Microsoft-kant, en ze zijn meestal klein maar makkelijk verkeerd te configureren. Microsoft Graph rekent per call. Azure Event Grid rekent per miljoen operaties. Beide zijn centen bij typisch synchronisatievolume. De manier waarop je dit in een echte rekening verandert is door SharePoint elke 30 seconden te pollen in plaats van je op webhooks te abonneren. Een dergelijke bug heeft de Azure-verbruikskosten met een factor vijftig doen pieken bij minstens één team dat ik heb gezien. Webhook plus delta houdt de rekening vlak, ongeacht hoe vaak de bron verandert.

De vijf foutmodi die het opletten waard zijn

Deze komen vaak genoeg terug in verschillende implementaties dat ze een checklist verdienen.

Verlopen webhook-abonnement. Abonnementen vernieuwen zichzelf niet. Voeg verloop toe aan je alerting en vernieuw op 75 procent van de maximale levensduur. Stil verlopen is de vaakst voorkomende oorzaak van afdrijven.

Afhandeling van verwijderingen. De meeste teams leveren synchronisatie die aangemaakte en bijgewerkte bestanden afhandelt en verwijderde vergeet. De agent citeert dan een beleid dat drie maanden geleden werd ingetrokken. Bedraad het deleted-wijzigingstype als een eersteklas geval, niet als een randgeval.

Tenant-brede leesscope. Het verlenen van Sites.Read.All bij de setup is snel. Zes maanden later, wanneer een auditor vraagt welke sites de service principal van de stemservice kan zien, is "allemaal" het verkeerde antwoord. Gebruik Sites.Selected vanaf het begin.

Documenten boven het plafond van 50 MB. Lange handboeken falen stilletjes bij het uploaden wanneer ze de limiet per bestand overschrijden. Preprocess documenten die te groot zijn door ze op logische grenzen te splitsen (hoofdstuk, sectie, productlijn) en elk stuk als eigen document te uploaden. Behoud parent-child-metadata zodat ophalen ze indien nodig weer aan elkaar kan naaien.

Afdrijving tussen staging- en productie-kennisbanken. Teams bouwen een synchronisatiepipeline tegen een staging-kennisbank, kopiΓ«ren de agentconfig naar productie, en vergeten dat de productieagent nog steeds naar de handmatig geΓΌploade bestanden van vorig kwartaal wijst. Maak de kennisbank-ID expliciet in je deploymentconfig en verifieer die na elke release.

Veelgestelde vragen

Kan een voice-AI-kennisbank documenten van een privΓ©-SharePoint-site ingesten zonder ze openbaar te maken?

Ja. De architectuur is service-principal-authenticatie via Microsoft Entra ID, bestanden opgehaald over een geauthenticeerd Graph-kanaal, en uploads gepusht naar de kennisbank-API over HTTPS. Brondocumenten blijven in SharePoint met hun bestaande ACL's. De kennisbank houdt een geïndexeerde kopie die alleen wordt gebruikt voor ophalen tijdens gesprekken, en je kunt de service principal scopen tot één enkele site als compliance dat vereist.

Hoe lang duurt het voordat een SharePoint-bewerking een live telefoongesprek bereikt?

Vijf tot vijftien minuten end-to-end op het gelukkige pad. De opsplitsing: Graph-webhook-bezorging binnen enkele minuten, delta-query en download in minder dan een minuut, parsen en embedden in één tot drie minuten afhankelijk van de documentgrootte. Eenmaal geïndexeerd voegt ophalen minder dan 100 milliseconden toe tijdens het gesprek zelf, dus bellers merken geen pauze.

Wat gebeurt er wanneer een webhook-melding wordt gedropt?

Een dagelijkse reconciliatiejob speelt de delta-query opnieuw af en vergelijkt resultaten tegen het kennisbank-manifest, en vangt op wat Event Grid of Graph miste. De combinatie van realtime-webhooks en een dagelijkse delta-veegbeurt is het standaardpatroon, aanbevolen in Microsofts eigen engineering-schrijfsels juist omdat meldingen best-effort zijn.

Werkt deze aanpak voor niet-Microsoft-bronnen?

Ja. Hetzelfde workerpatroon is van toepassing op Google Drive (via de Drive Activity API), Amazon S3 (via S3 Event Notifications), Confluence, Notion, en elke bron die wijzigingsgebeurtenissen uitzendt. De kennisbank-API is bronneutraal. Het enige stuk dat verandert is de auth- en event-listening-code.

Waarom niet gewoon Microsoft Copilot Studio gebruiken?

De SharePoint-connector van Copilot Studio ververst niet automatisch wanneer bestanden veranderen, een beperking die Microsoft midden 2025 bevestigde en waarvoor op het moment van schrijven geen fix is uitgebracht. Workarounds omvatten Power Automate-flows die handmatige verversingen triggeren. Behalve het synchronisatieprobleem is Copilot Studio gebouwd voor chat-oppervlakken en produceert het geen sub-seconde stem-latency. Voor telefoonagenten is de architectuur in deze gids de weg.

Is de data veilig als het corpus gereguleerde content bevat?

Retell AI wordt geleverd met SOC 2 Type II, HIPAA met self-service-BAA, en GDPR, plus configureerbare dataretentie en PII-redactie. Voor zorg-workloads is het standaardpatroon om de BAA te poorten voordat er PHI de index raakt. De compliancehouding tegen jouw specifieke regelgevingsregime is aan jou om te valideren. De certificeringen op infrastructuurniveau dekken het platform, niet je contentclassificatiebeleid.

Kan één agent tegelijkertijd putten uit SharePoint en Azure?

Ja. Een agent kan meerdere kennisbanken gekoppeld hebben, en elke kennisbank kan putten uit een andere bronpipeline. Een veelvoorkomend patroon is één kennisbank per logisch domein (facturatie, support, productspecificaties) met bronnen netjes gescheiden. Conversation-flow-nodes kunnen ook een andere kennisbank binden aan een specifieke node wanneer sales- en supportpaden aparte context nodig hebben.

Wat is de minimale teamgrootte om dit in productie te draaien?

Eén engineer die comfortabel is met OAuth en webhooks voor de synchronisatielaag, één ops-eigenaar voor de agentbouw en het afstemmen van de prompt, en een contenteigenaar die bepaalt wat in de gesynchroniseerde map thuishoort. De verdeling die in de praktijk werkt: IT bezit de worker en de auth; ops bezit de agent; het contentteam bezit wat binnen scope valt. De architectuur ondersteunt een setup van één persoon voor een proof of concept en schaalt zonder herarchitectuur.

Hoe verhoudt dit zich tot rechtstreeks bouwen op Azure AI Search?

De SharePoint-indexer van Azure AI Search handelt ingestie goed af maar heeft harde limieten die het weten waard zijn. Hij ondersteunt geen tenants met Conditional Access ingeschakeld. ACL-behoud is in public preview, niet GA. Verversingslatency loopt in uren, niet minuten. En je moet nog steeds de stemagentlaag erbovenop bouwen. Voor pure enterprise search is AI Search prima. Voor stem is het synchroniseren-naar-Retell-AI-patroon operationeel eenvoudiger en sneller uit te rollen.

Met welke chunking-strategie moet ik beginnen?

Recursieve 512-token-splitsing met 10 tot 20 procent overlap. Dit is de benchmark-gevalideerde standaard over de evaluaties van 2026 en presteert ongeveer 15 punten beter dan semantische chunking op echte documentcorpora. Drie chunks opgehaald op standaardsimilariteit. Stem pas af nadat je 50 tot 100 echte gesprekstranscripties hebt om de wijziging te informeren.

Waar ga je vanaf hier naartoe

De synchronisatiepipeline is de onglamoureuze helft van voice-AI, en het is ook de helft die bepaalt of de implementatie doorgaat of vastloopt. Een pilot die "werkt op demodata" en omvalt zodra een beleid verandert, is de kenmerkende foutmodus in deze ruimte, en de architectuur hierboven is de fix.

Zodra de kennisbank solide is, breidt dezelfde agent uit naar aangrenzende workflows op dezelfde data. AI-klantenservice voor inkomende vragen, leadkwalificatie voor uitgaand, een receptionist die naar beide routeert. Het corpus dat je voor één hebt samengesteld, wordt de bron van waarheid voor allemaal.

Begin gratis met $10 aan krediet op retellai.com.

ROI Calculator
Estimate Your ROI from Automating Calls

See how much your business could save by switching to AI-powered voice agents.

All done!Β 
Your submission has been sent to your email
Oops! Something went wrong while submitting the form.
Β Β Β 1
Β Β Β 8
20
Oops! Something went wrong while submitting the form.

ROI Result

2,000

Total Human Agent Cost

$5,000
/month

AI Agent Cost

$3,000
/month

Estimated Savings

$2,000
/month
Live Demo
Probeer onze live demo

Een demodemonummer van Retell Clinic Office

Bedankt! Je inzending is ontvangen!
Oeps! Er is iets misgegaan bij het verzenden van het formulier.

Read Other Blogs

Revolutionize your call operation with Retell