RAG retrieval vergeleken: aktezoek bij een notariskantoor

Het is 19:30 in Leuven. Een notaris-vennoot legt de laatste hand aan de hervorming van de dossierboom op de kantoor-NAS. Wat eerst gesorteerd was op jaar en aktetype, staat nu gegroepeerd per cliëntfamilie. Twintigduizend mappen verplaatst. De RAG-aktezoek-agent die het team elke ochtend gebruikt, heeft geen idee dat dit gebeurd is. Morgen om 09:00 levert hij citaten op die wijzen naar bestandsnamen die niet meer bestaan.

Dit is de saaie helft van elk RAG-project. De retrieval-laag die je kiest, bepaalt hoe die avond eindigt.

We hebben drie RAG-retrieval-stacks doorgemeten voor dezelfde klus: een notariskantoor van 19 mensen in Leuven, ruwweg 80.000 historische pagina's (akten, statuten, hypotheekakten, fiscale aktes), één Nederlands-en-Frans aktezoek-agent eroverheen. De criteria: kosten per tenant bij dat aantal pagina's, AVG-dataresidentie, en wie 's nachts opgepiept wordt als een vennoot de mappenstructuur omgooit.

Wat een notariskantoor echt nodig heeft van retrieval

De agent moet vragen kunnen beantwoorden als welke akte regelt het vruchtgebruik op de gezinswoning van familie X. Dat betekent: de juiste clausule uit een akte van 60 pagina's halen, de exacte pagina citeren, en verdedigbaar zijn als iemand vraagt waarom déze clausule en niet een andere.

Drie randvoorwaarden bepalen elke beslissing hieronder.

Dataresidentie is lastig. Notariële akten bevatten bankgegevens, familieverhoudingen, fiscale posities, soms medische context bij een testament. De Belgische Nationale Kamer van Notarissen behandelt dit met dezelfde ernst als een ziekenhuis patiëntdossiers. "EU-regio" is niet hetzelfde als "datasoevereiniteit". We wilden dat zowel de opslag als de embedding-stap op EU-bodem gebeurt.

De reindex-cadans is niet nul. Notariskantoren reorganiseren. Vennoten gaan met pensioen, nieuwe klerken leggen hun eigen structuur op, een digitale archivaris besluit dat cliëntfamilie wint van jaar-en-type. De retrieval-laag moet dat kunnen volgen zonder dat er telkens een engineer aan te pas komt.

Er is geen DevOps-team. Negentien mensen, één office manager die ook IT-support doet. Alles wat een nachtelijke piepdienst vereist, valt af.

Optie 1: Anthropic hosted file-search

Het simpelste pad. PDF's uploaden via de Files API, koppelen aan een search tool, het model laten ophalen. Eén factuur, één leverancier, geen embedding-pipeline om te onderhouden.

Wat het kost bij 80k pagina's: gedomineerd door prijs per search en per opgeslagen token, niet door infrastructuur. Bij ons queryvolume (een paar honderd searches per dag, verspreid over negentien mensen) komt onze schatting uit op een paar honderd euro per maand inclusief opslag. Niet goedkoop, niet pijnlijk.

Waar het voor deze klant wringt: de verwerking gebeurt primair op door Anthropic beheerde infrastructuur onder hun commerciële DPA. Goede operators, serieuze controls, maar de vraag die de orde van notarissen stelt is: "waar fysiek worden deze akten verwerkt op het moment dat een klerk een query intikt." Voor een klantenservice-agent is dat gesprek te voeren. Voor een notariskantoor waarvan het hele businessmodel de verzegelde envelop is, was het een gevecht dat we niet wilden aangaan.

Reindex is bovendien handmatig. Als de vennoot mappen herschikt, upload je opnieuw met nieuwe metadata en verwijder je de oude objecten. Er is geen bucket-watcher. Voor een kantoor zonder eigen developer wordt dat een terugkerende factureerbare opdracht voor iemand zoals wij, en dat vond de klant terecht een onwenselijke langetermijnvorm.

Optie 2: Cloudflare AutoRAG met R2 en Workers AI

Cloudflare AutoRAG koppelt drie stukken aan elkaar: R2 als document-bucket, Workers AI voor embeddings, Vectorize als index. Je wijst hem op een bucket, hij herindexeert als objecten veranderen, je queryt via één endpoint.

Voor een klein EU-kantoor is dit het saai-goede antwoord. R2-opslag bij 80.000 PDF's is afrondingsfout op de maandfactuur. Embeddings zijn een eenmalige kost bij inname plus goedkope re-embeds bij wijzigingen. Queries zijn flat-rate goedkoop. Onze schatting komt all-in uit op een paar tientjes per maand op deze schaal, ruwweg een orde van grootte onder optie 1.

Dataresidentie is instelbaar. R2 heeft location hints, Workers AI draait aan de rand met EU-pinning beschikbaar, en de DPA van Cloudflare dekt EU SCC's netjes af. Voor een Belgische notaris is dat een verdedigbare houding, en de marktpositie van Cloudflare maakt het inkoopgesprek korter dan bij een kleinere leverancier.

Het reindex-verhaal is waar deze optie wint. Als het DMS van het kantoor kan syncen met R2 (de meeste moderne kunnen dat, en op de NAS waarop dat niet kan wedgen we een rclone-job), dan propageert een mappenreorganisatie automatisch. De vennoot verschuift de mappen om 19:30, de sync draait om 20:00, AutoRAG detecteert de gewijzigde objecten en herindexeert de delta 's nachts. Om 09:00 levert de agent correcte citaten tegen de nieuwe boom.

De tradeoffs zijn reëel. Je zit voorlopig vast aan de embedding-modellen die Cloudflare aanbiedt (hun line-up is prima, maar als er volgend jaar een sterkere Nederlands-getunede encoder verschijnt en je wilt die, dan wacht je). En het debuggen van een verkeerd geranglijste retrieval tegen een managed pipeline is lastiger dan tegen je eigen pipeline.

Optie 3: Self-hosted LlamaIndex met Postgres pgvector

Volledige soevereiniteit, volledige controle, volledige ops-last. Een Hetzner-bak in Falkenstein, Postgres met pgvector, LlamaIndex die chunking en retrieval orkestreert, een embedding-model naar keuze (voor dit soort klant grijpen we vaak naar een kleine EU-gehoste variant).

De ruwe kosten zijn met afstand de laagste van de drie. Een dedicated EX44-klasse-machine met NVMe bij Hetzner kost ongeveer €40 per maand en draagt deze index met capaciteit over. Geen kosten per query. Bij tien keer zoveel pagina's beweegt de prijs nauwelijks.

De AVG-positie is hier het sterkst. Opslag, embedding, retrieval en query-logs blijven allemaal op hardware waar de klant op een kaart naar kan wijzen. Voor een notariskantoor met een interne compliance officer die één alinea uitleg wil, is "rack 17 in Falkenstein, door ons beheerd, geen derde partij" de makkelijkste alinea om te schrijven.

Wat de klant echt betaalt, is in mensentijd. Iemand moet Postgres gepatcht houden, back-ups roteren, op index-bloat letten, embeddings opnieuw draaien als het model update, en een sync-job leveren die het DMS bewaakt op taxonomie-wijzigingen. Niets daarvan is moeilijk. Alles daarvan is terugkerend. Voor een kantoor van negentien mensen zonder eigen engineer is die "iemand" of wij op retainer of niemand. "Niemand" is de faalmodus waarin retrievalkwaliteit twaalf maanden lang stilletjes wegrot tot mensen de agent niet meer vertrouwen.

Soevereiniteit is een houding, geen feature. Een self-hosted stack waar niemand naar omkijkt is slechter dan een managed stack met een echte SRE erachter. Bepaal wie de pieper draagt voordat je bepaalt welke bak de index draait.

De scorekaart

Wat we gekozen hebben, en waarom

AutoRAG. Niet omdat hij op elke as het hoogst scoorde (pgvector wint op soevereiniteit en kosten-op-schaal, hosted search wint op simpelheid-van-geest), maar omdat de faalmodes het makkelijkst te dragen waren voor dit specifieke kantoor.

De doorslaggevende vraag was die vennoot om 19:30. Welke stack je ook kiest, de dag waarop een senior vennoot de dossierboom hervormt, moet eindigen met een werkende agent. Bij Anthropic moeten wij langskomen om opnieuw te uploaden. Bij self-hosted moeten wij langskomen om de sync te draaien. Bij AutoRAG moeten wij ongeveer nooit langskomen, omdat de bucket-watcher de hele reindex-pipeline is.

Kosten telden minder dan gewoonlijk. De agent vervangt gemiddeld veertig minuten klerktijd per dag aan het doorbladeren van gescande PDF's. Zelfs bij de duurste optie wordt de payback in dagen gemeten. De variabele die de beslissing echt verschuift, is wie de volgende mappenherschikking voor zijn rekening neemt.

Eén waarschuwing over kostenexplosies

Je hebt vast het terugkerende genre verhalen gezien over een AI-agent die een ongebreidelde rekening laat oplopen, recent een die zonder bovengrens DN42 probeerde te scannen. RAG-retrieval-pipelines zijn tammer dan autonome netwerkagents, maar het principe is gelijk: elke laag met kosten per query moet aan agent-zijde worden ingekapseld in een harde rate-limit, per gebruiker en per session. We zetten de notaris-agent op maximaal 200 retrievals per klerk per dag, alarm op 80%, harde stop op 100%. Goedkope verzekering tegen de dag dat een verkeerd geconfigureerde loop een maand van €40 verandert in een maand van €4.000.

Wat je morgen kunt doen

Als je een retrieval-laag opzet voor een klein Europees kantoor: draai dezelfde drie-vragenfilter voordat je code schrijft. Waar staat de data fysiek, wat gebeurt er als de documentboom volgend kwartaal verbouwd wordt, en wie neemt om 22:00 de telefoon op als retrieval verkeerde citaten begint terug te geven. Kosten zijn de laatste vraag, niet de eerste.

Toen we de aktezoek-agent voor het notariskantoor in Leuven bouwden, was het ding waar we steeds tegenaan liepen precies dat mappenherschikkingsprobleem. We hebben het opgelost door een kleine rclone-job van hun DMS naar R2 te wedgen, zodat het reindex-verhaal van Cloudflare werd en niet van ons. Dat soort pipeline-lijm is grotendeels hoe een eerlijke AI-agent bouw eruitziet zodra de demo voorbij is.