Een RAG-index veroudert op twee manieren, en vrijwel al het advies uit 2026 lost er maar één van op. Wijzigingsvertraging is het gat tussen het moment waarop een document wordt aangepast en het moment waarop de vectoren bijwerken. Daar helpt event-gestuurd herindexeren tegen. Versiebotsing is het vervangen document dat er nog gewoon staat, nog steeds klopt op het oog en nog steeds hoog scoort. Geen enkel indexeerschema raakt dat probleem aan.
Hoe ziet een verouderde RAG-index er in de praktijk uit?
De melding komt elke keer op dezelfde manier binnen. De assistent noemt een tarief dat in maart is ingetrokken. Hij citeert een werkinstructie die na een incident is vervangen. Hij beantwoordt een vraag over verlof uit een cao die vorig jaar is verlopen.
De engineer controleert de pijplijn, ziet dat de nachtelijke run is geslaagd en concludeert dat de index gezond is. De index is ook gezond. Het ophalen ging net zo goed. Het fragment dat terugkwam is een echt fragment uit een echt document dat werkelijk in het corpus zit. Er is niets misgegaan. Het systeem heeft alleen geen enkel begrip van welk van zijn documenten nog geldig is.
Dat zijn twee verschillende problemen, met verschillende oplossingen, en maar één ervan krijgt aandacht:
- Wijzigingsvertraging. Een document verandert om 10:00, de nachtelijke job draait om 02:00, en zestien uur lang beschrijft de index een werkelijkheid die niet meer bestaat. Op te lossen met incrementeel of wijzigingsgestuurd herindexeren: signaleer de wijziging, embed alleen de geraakte fragmenten opnieuw, gooi de caches weg die eraan zaten.
- Versiebotsing. Versie 1, versie 2 en versie 3 van dezelfde procedure zitten alle drie in het corpus, alle drie terecht bewaard, alle drie inhoudelijk vrijwel identiek. Daar helpt geen enkele pijplijn tegen, want de pijplijn doet precies wat hij moet doen.
Het meeste dat in 2026 over actualiteit is geschreven gaat over het eerste. Streaming-architecturen, change-data-capture-koppelingen, hashes per fragment, versiebeheer van het embeddingmodel: allemaal terecht, allemaal de moeite waard, en geen daarvan bepaalt welke van twee bewaarde versies de geldende is. De leveranciersdocumentatie begint dat gat te dichten. Oracle schreef in juli 2026 over index drift dat u de levensloopstatus per fragment expliciet moet vastleggen als actueel, vervangen, verwijderd, mislukt of in quarantaine, en dat vervangen fragmenten standaard buiten het zoeken horen te blijven. Dat is het juiste advies. Wat er niet in staat is de vraag die een Nederlands bedrijf meteen daarna krijgt: wat doet u als de wet eist dat de vervangen versie blijft staan?
Waarom lost sneller herindexeren een versiebotsing niet op?
Omdat een embedding betekenis vastlegt, en geldigheid is geen betekenis. De prijslijst van 2024 en die van 2026 zeggen bijna hetzelfde in bijna dezelfde woorden. Juist die gelijkenis zet ze naast elkaar in de vectorruimte, en een gelijkenisvergelijking heeft geen enkele reden om de één boven de ander te kiezen.
Hoe beter uw huis op orde is, hoe erger het wordt. Een bedrijf dat al tien jaar één offertesjabloon gebruikt, één procedureformat over alle afdelingen en één huisstijl voor klantbrieven, heeft een corpus opgebouwd waarin elke versie van elk document een naaste buur is van elke andere versie. Documentdiscipline, overal elders een deugd, maakt dit probleem juist ernstig.
Het onderzoek heeft het inmiddels gemeten. VersionRAG bouwde VersionQA, een benchmark van 100 handmatig samengestelde vragen over 34 documenten met versiegeschiedenis, en rapporteerde 58% nauwkeurigheid voor gewone RAG en 64% voor GraphRAG, tegenover 90% voor een versiebewuste pijplijn. Bij het herkennen van niet-gedocumenteerde wijzigingen scoorden de baselines tussen 0% en 10%, en het versiebewuste systeem 60%.
Lees die cijfers als een richting, niet als een percentage. Honderd vragen over vierendertig documenten is een kleine benchmark en de absolute getallen komen op uw eigen corpus niet terug. Over de richting bestaat geen twijfel, en die sluit aan op wat teams in productie melden: het gat zit niet in het ophalen, maar in het ontbreken van elke geldigheidstoets daarna.
Wat meten de enterprise-benchmarks van 2026 eigenlijk?
Twee publicaties van dit jaar zijn interessanter om wat ze veronderstellen dan om wat ze voorstellen.
EnterpriseRAG-Bench, verschenen in mei 2026, is een synthetisch corpus van ongeveer 500.000 documenten uit negen bronsoorten, waaronder Slack, Gmail, Google Drive, HubSpot, GitHub, Jira en Confluence, met 500 vragen over tien categorieën. De ontwerpkeuze die telt: het corpus is bewust aangevuld met verkeerd opgeborgen documenten, bijna-duplicaten en tegenstrijdige informatie, en de vragenset bevat het oplossen van tegenstrijdigheden en het herkennen dat informatie simpelweg ontbreekt. De dataset en de testomgeving zijn openbaar, en het generatieraamwerk laat een team een variant maken die bij de eigen bronnen past. Dat is een benchmark die is gebouwd op de aanname dat een echt bedrijfsarchief zichzelf tegenspreekt.
ConflictRAG, uit mei 2026 en herzien in juni, benoemt die aanname expliciet: RAG-systemen gaan ervan uit dat opgehaalde documenten onderling consistent zijn, en die aanname klopt in de praktijk regelmatig niet. De detectiestap is het kopiëren waard, ook als u de rest nooit overneemt: eerst een lichte classifier op embeddings, daarna een taalmodel dat alleen de twijfelgevallen nakijkt. De auteurs meten daarvoor 90,8% detectienauwkeurigheid bij 62% lagere API-kosten, met 88,7% F1 op het vinden van tegenstrijdigheden.
Zet de drie naast elkaar en de onderzoeksvraag is verschoven. Het gaat niet langer om beter ophalen. Het gaat om beslissen welk van de opgehaalde stukken nog waar is.
Wat kost opnieuw embedden een Nederlandse mkb'er werkelijk?
Het gebruikelijke argument voor streaming herindexeren zijn de kosten. Het loont om die som helemaal uit te rekenen, want op mkb-schaal draait de conclusie om.
Neem een corpus van 40.000 documenten: offertes, werkbonnen, procedures, contracten en een mailarchief, een geloofwaardige omvang voor een bedrijf van 20 tot 50 medewerkers. Reken met gemiddeld 1.200 woorden per document en ongeveer 1,35 token per woord voor gemengd Nederlands en Engels zakelijk proza. Dat komt neer op ongeveer 65 miljoen tokens.
De gepubliceerde tarieven van OpenAI op 18 september 2026 zijn $0,02 per miljoen tokens voor text-embedding-3-small en $0,13 voor text-embedding-3-large. Dus:
- Een volledige herbouw met het kleine model kost ongeveer $1,30. Elke nacht, een jaar lang: ongeveer $470.
- Alleen 1% van de documenten per dag opnieuw embedden kost ongeveer $0,013 per dag, oftewel ruwweg $4,70 per jaar.
- Met het grote model zijn diezelfde twee bedragen ongeveer $3.075 en ongeveer $31.
De besparing is echt, hij is inderdaad ongeveer honderdvoudig zoals het streaming-verhaal belooft, en op het kleine model bedraagt hij vierhonderdvijfenzestig dollar. Voor een bedrijf dat 80 euro per uur voor een ontwikkelaar betaalt, kost een heel jaar nachtelijke herbouw ongeveer zes uur van diezelfde ontwikkelaar.
Twee eerlijke kanttekeningen. Dit gaat alleen over de embedding-API: inlezen, opknippen, opslag en de vectordatabase zitten er niet in, en bij miljoenen documenten is het absolute bedrag geen afrondingsverschil meer. En een nachtelijke herbouw laat nog steeds een wijzigingsvertraging van maximaal een dag staan, wat voor sommige documentsoorten echt niet acceptabel is.
Maar als incrementeel indexeren is gekozen om geld te besparen, is de goedkoopste post in het systeem geoptimaliseerd. De dure post is de offerte die een verkoper heeft verstuurd op basis van een ingetrokken tarievenlijst.
Waarom kunnen Nederlandse bedrijven de oude versie niet gewoon weggooien?
De voor de hand liggende oplossing voor versiebotsing is opschonen: één versie houden, de rest weg. In veel corpora werkt dat. In een Nederlands bedrijf loopt het stuk op de bewaarplicht.
De Belastingdienst eist dat de administratie zeven jaar wordt bewaard, en gegevens over onroerende zaken tien jaar, vanwege de herzieningstermijn voor de btw. De bewaartermijn begint te lopen op het moment dat een document zijn actuele waarde verliest, niet op het moment dat het is gemaakt. Dat is precies het moment waarop uw index het kwijt wil.
De vervangen offerte, de ingetrokken tarievenlijst en de vorige algemene voorwaarden moeten dus ergens bereikbaar blijven. Daaruit volgt een architectuurscheiding die de meeste mkb-implementaties nooit maken: het bewaararchief en de zoekindex zijn niet dezelfde opslag en horen niet dezelfde inhoud te hebben. Alles bewaren is een wettelijke plicht. Alles ophaalbaar maken is een ontwerpkeuze, en een slechte.
Wat is een verouderingsbudget en hoe stelt u het vast?
Bepaal per documentsoort twee dingen voordat er ook maar iets wordt geëmbed: hoe lang een verouderd antwoord acceptabel is, en wat er gebeurt met de versie die is vervangen. Het resultaat is een korte tabel, en bij een Nederlands bedrijf worden de meeste regels ervan bepaald door een contract of een wet en niet door smaak. Die tabel bepaalt het metadataschema waar al het andere aan hangt.
- Tarievenlijsten en prijslijsten. Marge: minuten. Precies één versie in de index, de rest er volledig uit.
- Offertes en contracten. Marge: uren. Alle versies geïndexeerd, elk met geldigheidsdatums en een status, en standaard gefilterd op de actuele.
- Werkinstructies en procedures. Marge: een dag. Eén actuele versie, met een verwijzing naar wat is vervangen, zodat de assistent kan vertellen wat er is veranderd en wanneer.
- Algemene voorwaarden. Marge: direct, maar geversioneerd op ingangsdatum, want voor een klant die in 2024 tekende is de versie van 2024 het juiste antwoord.
- Cao's en personeelsregelingen. Marge: dagen, met filteren op ingangsdatum als eis en niet als optie.
- Projectmappen en mailarchief. Geen enkele garantie op actualiteit. Wel indexeren, maar onder de bestuurde bronnen ranken, en de assistent laten benoemen uit welke laag een antwoord komt.
Hoe bouwt u versiebewustzijn zonder onderzoeksraamwerk?
Vier stappen, en geen daarvan vraagt om een graafdatabase of om de databasefuncties die de leverancierschecklists veronderstellen.
Leg geldigheid vast bij het inlezen, niet bij de vraag. Elk fragment draagt bronsysteem, document-id, versie, geldig-vanaf, geldig-tot en status. Kan het bronsysteem die velden niet leveren, dan is dat een bevinding over uw documentbeheer en geen reden om de kolom over te slaan.
Maak het vervangen expliciet. Een verwijzing van de oude naar de nieuwe versie kost niets aan opslag en verandert "welke is de actuele" van een semantisch oordeel in een opzoekactie.
Filter voordat u rankt. Zet de retriever standaard op status is actueel, tenzij de vraag een datum bevat of over het verleden gaat. De meeste systemen doen het andersom: alles ophalen en dan hopen dat de reranker een mening heeft over tijd. Die heeft hij niet.
Zet verouderde tweelingen in de evaluatieset. Neem twintig echte vragen en zorg dat het corpus bij elke vraag minstens één geloofwaardig verouderd antwoord bevat. Kan het systeem ze in uw eigen test niet uit elkaar houden, dan lukt het in productie zeker niet. Dit is de goedkoopste stap van de vier en wordt het vaakst overgeslagen.
Wat dit betekent als u een assistent op uw eigen documenten draait
Voor een Nederlands bedrijf van 20 tot 50 medewerkers is de vraag niet hoe vaak er wordt geherindexeerd. De vraag is of het systeem weet welk van zijn documenten nog geldig is, en of het dat in het antwoord kan zeggen.
Er is vaak een kortere weg. De actueelste versie van een prijs, een klantgegeven of een orderstatus staat meestal helemaal niet in een document, maar in Exact, AFAS of uw boekhoudpakket. Een document ophalen dat een getal beschrijft is een slechter antwoord dan het systeem bevragen dat dat getal beheert. Elk veld dat u uit het corpus haalt en in een live API-koppeling zet, is een veld dat niet kan verouderen.
Voor alles wat echt in documenten thuishoort is de oplossing meestal een metadataslag over het corpus dat u al heeft, en niet een nieuwe pijplijn. En het heeft een eigenaar nodig na livegang. Dat is hetzelfde argument als bij de structurele keuze tussen RAG en GraphRAG en dezelfde reden waarom een privé AI-assistent een bestuurd systeem is en geen eenmalig project. Iemand moet het verouderingsbudget bewaken zodra het bouwteam weg is, en daar is doorlopend AI-beheer voor.
Laatst bijgewerkt: 18 september 2026.
Wij bouwen maatwerk-AI en LLM-systemen die in productie draaien: een klikbare MVP bij het tweede gesprek, vaste stappen, en de code is van u.
AI-ontwikkelbureau in Nederland →
