RAG-audit: verouderde chunks, verweesde PDF's, foute rerank

Het is dinsdagochtend. Een klant vraagt aan je RAG-support-agent wanneer ze een product mag retourneren dat ze vorige week kocht. De agent haalt een chunk op die er onberispelijk uitziet. Juiste koppen, juiste toon, juiste merkstem. Het stuk citeert een retourtermijn van 30 dagen. Die termijn heb je in januari teruggebracht naar 14 dagen. Het nieuwe beleid staat ook in de kennisbank. De retriever vond beide. De rerank koos de oudere versie omdat die langer was, dichter geschreven, en op meer trefwoorden matchte.

Dit is de storing die we het vaakst zien als we voor een klant een RAG-kennisbank doorlichten. Het model is in orde. Het zit in retrieval, en drie specifieke storingen veroorzaken het grootste deel.

Hieronder de checklist die we afdraaien voordat we een RAG-systeem loslaten op een betalende klant. Het kost ongeveer een dag op een kleine kennisbank en een week op een grote. We zijn er nog nooit doorheen gegaan zonder iets te vinden.

Verouderde chunks die fris ogen

De eerste ronde is de voor de hand liggende. We lijsten elke chunk in de index op en sorteren op datum van inname. Alles ouder dan 18 maanden krijgt een vlag. Net zoals alles waarvan de bron-URL of bestandspad niet meer resolvet.

De moeilijkere ronde is de chunk die technisch actueel is maar feitelijk afgevoerd. Een prijspagina die nog leeft op de oude URL omdat marketing de pagina online liet "voor SEO". Een teamprofiel van iemand die in april vertrok. Een productspec voor een SKU die je hebt uitgefaseerd. Geen van die chunks zakt voor een freshness-check op timestamp. Allemaal worden ze met overtuiging aan je klant geciteerd.

Wat we doen: we vragen de operations lead van de klant om met ons door een lijst te lopen van de top 200 chunks op retrieval-frequentie van de afgelopen 30 dagen. Niet de top 200 op score, de top 200 op feitelijke retrieval-count. Zo'n 10 tot 15 procent krijgt een vlag van "dat citeren we niet meer". Die chunks moeten uit de index, niet alleen gemarkeerd worden als deprecated. De retriever trekt zich niets aan van je metadata-vlaggen als je er niet ook op filtert.

Verweesde PDF's

Elke kennisbank van een jaar of ouder heeft ze. Een PDF die ooit is geüpload, gechunkt, geëmbed, en daarna vergeten. De PDF is verwijderd uit het bronsysteem (Notion, SharePoint, Drive) maar de chunks staan nog in de vector store. We hebben indexen gezien waarin ruwweg 8 procent van de chunks verwijst naar brondocumenten die niet meer bestaan op het systeem dat ze geacht wordt te beheren.

Dit is erger dan een verouderde chunk omdat er voor een mens geen manier is om de bron te controleren. De agent citeert de PDF. De klant vraagt om het document. De link geeft een 404. Het vertrouwen stort ter plekke in.

De auditstap is mechanisch. Voor elke unieke bron-URL of file-ID in de index, stuur je een HEAD-request of het equivalente API-call. Log de mislukkingen. Vergelijk met de gezaghebbende lijst van levende documenten in het bronsysteem. De delta is je weesverzameling. Verwijder die chunks. Niet "markeren voor review". Verwijder ze.

Een verwante klasse wees: de PDF die wel bestaat maar überhaupt niet in de klant-gerichte index thuishoort. Interne salarisschalen. Een conceptpersbericht. Een NDA-only diagnose van een consultant. We hebben alle drie aangetroffen in klant-gerichte indexen. De audit stelt over elk brondocument één vraag: zou je rustig blijven slapen als je slechtst gedragen klant dit woordelijk in een tweet plakt? Zo niet, dan hoort het niet in de index.

De rerank die liegt

Dit is de paragraaf waar klanten het meest van schrikken. De retriever geeft 50 kandidaten terug. Een rerank-model scoort ze. De top 5 gaat naar het taalmodel. Iedereen gaat ervan uit dat de rerank het vangnet is. Het is de meest voorkomende enkele oorzaak van zelfverzekerd verkeerde antwoorden.

Rerank-modellen zijn getraind op algemene relevantiesignalen. Ze belonen documenten die op antwoorden lijken: gestructureerd, dicht, on-topic vocabulaire. Een lange, goed opgemaakte pagina uit 2023 verslaat een korte, ongepolijste aankondiging van vorige maand, zelfs wanneer de aankondiging de gezaghebbende update is. De rerank-documentatie van Cohere is daar expliciet over. Rerank optimaliseert voor semantische relevantie, niet voor actualiteit, niet voor gezag, niet voor beleidsstatus. Die laag moet jij erbovenop leggen.

Er is ook de goed gedocumenteerde position bias in lange contexten. De paper Lost in the Middle liet zien dat zelfs wanneer het juiste document opgehaald wordt, modellen het vaak negeren als het in het midden van de prompt belandt. De rerank bepaalt wat de top haalt. Zet de rerank het juiste document op rank 3 en het verkeerde op rank 1, dan volgt het model meestal rank 1.

De auditstap hier is de nuttigste van de hele checklist. Trek een steekproef van 200 echte klantvragen uit de afgelopen 60 dagen. Log voor elk de top 5 reranked chunks en de top 5 op ruwe vector-similariteit. Laat een mens (de domein-expert van de klant, niet wij) markeren welke chunks echt klopten. Wij zien doorgaans dat de rerank het oneens is met de domein-expert op 15 tot 25 procent van de queries.

Kijk vervolgens naar de meningsverschillen. Het patroon is bijna altijd hetzelfde: de rerank verkiest de langere, oudere, beter opgepoetste chunk. De oplossing is niet "train een betere rerank". De oplossing is hard filters leggen vóór rerank draait. Geldigheidsdata. Document-type whitelists voor specifieke intents. Een "current policy"-vlag die afgedwongen wordt bij retrieval, niet alleen in metadata.

Een uitgewerkt voorbeeld

Dit is het type filter dat we uiteindelijk toevoegen. De retriever geeft kandidaten. Voor rerank draait, gooien we alles eruit dat zakt voor een hard policy check.

from datetime import date

def pre_rerank_filter(candidates, query_intent):
    today = date.today()
    out = []
    for c in candidates:
        if c.meta.get("deprecated"):
            continue
        eff_from = c.meta.get("effective_from")
        eff_to = c.meta.get("effective_to")
        if eff_from and eff_from > today:
            continue
        if eff_to and eff_to < today:
            continue
        if query_intent == "policy" and c.meta.get("doc_type") != "policy":
            continue
        out.append(c)
    return out

Dat zijn veertien regels. Het is ook het verschil tussen een systeem dat in juni nog januari-beleid citeert, en een systeem dat dat niet doet. We hebben nooit een productiewaardige RAG-opzet uitgerold die geen variant van dit nodig had.

Wat je vandaag echt kunt draaien

De volledige audit kost een week. De versie van vijf minuten gaat zo. Open je vector store. Draai een query die chunks telt, gegroepeerd per innamemaand. Als de oudste staart meer dan 18 maanden terug ligt en niemand in je team kan opnoemen wat erin zit, heb je een verouderde-chunks-probleem. Pak vervolgens drie willekeurige URL's uit het bronveld. Open ze in een browser. Geeft eentje een 404, dan heb je een wezenprobleem. Draai dan één echte klantvraag twee keer door je retriever: eenmaal met de rerank, eenmaal zonder. Verschillen de antwoorden, dan neemt de rerank een beslissing die iemand in je team zou moeten nemen.

Toen we de support-agent bouwden voor een van onze grotere e-commerce klanten, lag het rerank-meningsverschilcijfer op 22 procent voordat we het pre-rerank policy filter erbij zetten. Daarna bleef het hangen op 3 procent, en die drie waren randgevallen die de domein-expert sowieso wilde nakijken. Hetzelfde draaiboek bepaalt hoe we AI-agents uitrollen: retrieval eerst, model tweede, audit voor lancering.

Draai vandaag de versie van vijf minuten. Zakt er iets, dan weet je waar je daarna moet kijken.