RAG-actualiteit: de pdf van vorige maand is geen zoekprobleem

De trace van de retrieval ziet er voorbeeldig uit. Clausule 12.3 stond bovenaan, kwam in de context en draagt het antwoord. Het antwoord is toch fout.

De getekende wijziging heeft de index nooit bereikt.

RAG-actualiteit is de bewaakte afspraak tussen een geldende bron en de index waaruit je antwoordt. De afspraak zegt hoe oud de geïndexeerde toestand mag worden, hoe wijzigingen erin terechtkomen en wat het product doet als de afspraak wordt geschonden. In De RAG-engineer heet dit versheid. Retrievalkwaliteit redt geen document dat de index nooit heeft gezien. Wat is RAG? definieert de architectuur. Deze pagina definieert de klok die eronder loopt.

Verouderde index en verouderde embeddings

Een verouderde index vertegenwoordigt niet langer de brontoestand die je had afgesproken te serveren. De bron is bewerkt, vervangen, verwijderd of achter nieuwe rechten gezet, en de index draagt nog de oude toestand.

De fout kan buiten de vectorstore zitten. Keywordindexen, metadatatabellen, rerankingkenmerken, documentcaches en gegenereerde samenvattingen houden allemaal vervangen content vast. “We hebben de embeddings opnieuw gebouwd” is onvolledig zolang een oude lexicale vermelding of een gecachet antwoord nog geserveerd kan worden.

Een verouderde embedding betekent meestal een van drie dingen:

1. De vector is berekend uit tekst die sindsdien is gewijzigd of ingetrokken.
2. Het embeddingmodel is veranderd en de opgeslagen documentvectoren zijn nooit gemigreerd, zodat de index vectoren van twee modelgeneraties mengt en queryvectoren bij geen van beide betrouwbaar aansluiten.
3. De preprocessing is veranderd, met nieuwe chunkgrenzen, een nieuwe analyzer of een nieuwe opschoonstap, terwijl de oude vectoren bleven staan.

Tijd alleen bederft geen vector. Als brontekst, rechten, preprocessing en embeddingmodel ongewijzigd zijn, koopt elke nacht opnieuw embedden kosten, geen actualiteit. Wat veroudert, is de relatie tussen de opgeslagen representatie en de bron die ze zegt te vertegenwoordigen.

TTL is de grens, niet de update

Een time-to-live (TTL) beantwoordt één vraag: hoe lang mag dit corpus geserveerd worden zonder geslaagde actualiteitscontrole?

Hij ontdekt geen gewijzigde alinea, haalt geen vervanging op, verwijdert geen ingetrokken document en bouwt geen index. Daarvoor is een keten nodig waarlangs een wijziging doorreist:

geldende wijziging
→ wijzigingssignaal
→ ingest- of verwijderingsevent
→ getransformeerd document en metadata
→ kandidaat-indexversie
→ evaluatie
→ atomaire omschakeling in productie

Elke pijl kan breken terwijl het zoekendpoint gezond blijft.

Gebruik het beste wijzigingssignaal dat de bron biedt: een versie-ID, een wijzigingstijdstip, een ETag, een event of een contenthash. Geen enkel signaal volstaat alleen. Een stabiele URL kan onder je handen van inhoud veranderen. Een nieuw tijdstip kan een metadatawijziging zijn in plaats van een inhoudelijke. Een verwijderd record heeft een tombstone of een vergelijkbaar verwijderingsevent nodig, anders hoort de index nooit dat het weg is. Een verlopen TTL moet verificatie in gang zetten, geen blind opnieuw embedden.

Voor indexbrede wijzigingen geldt een strengere regel. Een nieuw embeddingmodel, nieuwe chunking of een nieuwe indexarchitectuur wijzigt de live index nooit ter plekke. Bouw een kandidaat-index, valideer de aantallen en de retrievalkwaliteit op je eigen gouden queries, en promoveer die daarna in één atomaire stap. Terugdraaien is dan triviaal: niet promoveren, of de alias terugzetten.

Bepaal de TTL per corpus en per gevolg. Een productcatalogus, een set getekende contracten en een statische technische handleiding delen geen wijzigingstempo en geen foutkosten. Een corpus dat continu verandert, zoals een ticketarchief of een kennisbank waar drie teams de hele dag in werken, heeft event-driven synchronisatie en een lag-budget nodig in plaats van een TTL. Deze pagina levert die getallen niet. De broneigenaar en de producteigenaar moeten ze opschrijven.

Het actualiteitscontract

Leg per corpus minstens deze velden vast:

Veld	Het besluit dat het afdwingt
Geldende bron	Welk systeem wint als kopieën van elkaar afwijken?
Bronidentiteit en versie	Hoe weet je dat dit hetzelfde object in dezelfde toestand is?
Wijzigingssignaal	Wat zegt de ingest dat hij moet ophalen, vervangen of verwijderen?
Laatste geslaagde ingest	Wanneer is de complete keten voor het laatst afgerond, niet alleen gestart?
Maximale leeftijd, TTL of lag-budget	Wanneer stopt het stilzwijgend serveren?
Reactie na overschrijding	Waarschuwen, weglaten, live ophalen, weigeren of naar een mens sturen?
Eigenaar	Wie grijpt in als de versheidstaak zijn venster mist?

Het verversingsschema plus de langste doorlooptijd moet binnen het venster passen. Een dagelijkse taak met een foutwachtrij van twee dagen houdt geen belofte van één dag. En voor beleid, prijzen en deadlines mag een overschreden venster geen antwoord met disclaimer opleveren. Dan hoort het systeem te weigeren of een mens in te schakelen.

Verwijderingen en gewijzigde rechten reizen dezelfde keten af als bewerkingen, met één extra eis: volledigheid. Verdwijnt een bron, dan moeten zijn chunks, keywordvermeldingen, gecachete voorbeelden, citaties en afgeleide samenvattingen verdwijnen of ontoegankelijk worden op elke plek waarheen ze zijn gekopieerd. Een retrievalsysteem dat ingetrokken content onthoudt, is niet alleen verouderd. Het is een lek in het toegangsbeheer met een vriendelijke interface.

Waar GRAIN versheid plaatst

De RAG-engineer definieert GRAIN als Gather corpora, Rank and rerank, Assemble context, Inspect failures, Navigate freshness. Het is het eigen werkmodel van het boek, geen industriestandaard.

Navigate freshness, in de Nederlandse editie versheid navigeren, is eigenaar van de cyclus: TTL-beleid, heringest-taken, wijzigingsdetectie, het opsporen van veroudering, het versheidssignaal aan de gebruiker en het logboek van wat wanneer veranderde. In deze grammatica betekent Navigate versheid. Het is geen synoniem voor het kiezen van de volgende lookup.

De andere letters dragen hun deel. Gather legt bronidentiteit, rechten en update-eigenaarschap vast in het corpus-contract. Rank kiest tussen oude en nieuwe versies als beide in de index zijn geglipt. Assemble neemt de bronversie en het indexeertijdstip mee de context in. Inspect maakt de misser zichtbaar in een trace. Navigate sluit de cyclus door de actuele brontoestand in productie te brengen.

Diagnose van het verouderde antwoord

Neem één fout antwoord en vergelijk vier toestanden:

1. Wat zei de geldende bron op het moment van de query?
2. Welke bronversie heeft de ingest als laatste gezien?
3. Welke versie stond in de productie-index en was ophaalbaar?
4. Welke versie en passage kwamen in de context voor het genereren?

De eerste afwijking wijst de reparatie aan. Bereikte toestand 1 nooit toestand 2, repareer dan de wijzigingsdetectie. Bereikte toestand 2 wel de opslag maar niet toestand 3, repareer dan de indexering of de omschakeling. Stond de huidige versie in toestand 3 maar verloor ze van een ouder duplicaat, repareer dan de ranking en de versiefilters. Bereikte ze toestand 4 en sprak het antwoord haar toch tegen, dan is de fout grounding, geen actualiteit.

Dat onderscheid voorkomt dure schijnreparaties. Opnieuw embedden herstelt geen ontbrekend verwijderingsevent. Een groter contextvenster ontdekt geen wijziging die nooit is ingelezen. Een modelupgrade maakt een verlopen index niet actueel.

Actualiteit is pas op orde als het systeem de bronversie achter een antwoord kan noemen, kan tonen wanneer die in productie kwam, en bewust reageert zodra de toegestane leeftijd verstrijkt. Tot die tijd is “actuele index” een wens met een tijdstempel.

Citeer deze pagina:RAG-actualiteit: de pdf van vorige maand is geen zoekprobleem.Len P. van der Hof. https://lenvanderhof.com/nl/blog/rag-actualiteit/ · Gepubliceerd 22 september 2026.