RAG vs file search: twee knowledge-agent stacks scoren

Dinsdagochtend, Utrecht. Een belastingadvieskantoor van 60 man. De managing partner stuurt me een screenshot door. Hun interne knowledge agent vertelde een junior medewerker dat de BTW-behandeling van een specifiek grensoverschrijdend factuurscenario X was. De Confluence-pagina die de agent citeerde, was in 2024 gearchiveerd, en de regel is sindsdien tweemaal gewijzigd.

De partner wil weten of de agent te redden valt, of dat ze hem eruit moeten trekken.

Dit is geen zeldzame mail. Hij valt ongeveer eens per maand in onze inbox, vrijwel altijd van een Nederlands professional-services kantoor onder de €12M dat in 2025 een interne RAG-achtige assistent heeft gebouwd (of betaald) en nu met de gevolgen leeft. De vraag die ze eigenlijk beantwoord willen zien, is binair: vector store, of geen vector store. Closed-corpus RAG, of een file-search tool waarbij het model de routing doet.

Dit is de methode die wij gebruiken om die keuze te scoren.

De twee architecturen op tafel

Optie A is wat de meeste teams al hebben. Een geplande job trekt pagina's uit Confluence en SharePoint, chunkt ze, embedt ze in een vector store (pgvector, Pinecone, Qdrant, kies maar), en de agent haalt de top-k chunks op voordat hij antwoordt. Chunking-regels, reranker, query rewriter, de hele pipeline.

Optie B is nieuwer en lijkt bedrieglijk simpel. Je biedt het model Confluence en SharePoint aan als file-search tool (of als MCP servers), en je laat het model direct search queries afvuren op de bronsystemen en de gevonden documenten lezen. Geen vector store. Geen nachtelijke index-job. Geen chunking-beslissingen in je repo.

Beide kunnen dezelfde vraag beantwoorden. Ze falen op verschillende manieren. Dat is precies het hele punt van de scoresheet.

Hallucinatiepercentage, eerlijk gemeten

De vendor-demo kun je hier niet vertrouwen. Het hallucinatiepercentage van een knowledge agent wordt door twee dingen bepaald: of de opgehaalde context het antwoord daadwerkelijk bevat (recall), en of het model details verzint als dat niet zo is (faithfulness).

Closed-corpus RAG: recall wordt begrensd door je chunking en je reranker. Is een Confluence-pagina gisteren bewerkt en draait je indexer 's nachts, dan haalt de agent een chunk op die de live pagina tegenspreekt. Faithfulness is meestal in orde, mits je het model instrueert om chunks te citeren en te weigeren bij gebrek aan bewijs.

File-search routing: recall hangt af van de zoekkwaliteit van Confluence en SharePoint, en die is eerlijk gezegd middelmatig. Het model vuurt twee of drie queries af, leest wat terugkomt, en stopt. Staat het antwoord op pagina zeven van de SharePoint-resultaten, dan komt hij daar niet. De officiële Confluence search API van Atlassian is prima voor directe titel-matches, en verrassend zwak op semantische formulering.

In onze scoresheet draaien we een vaste evalset van vijftig vragen uit de echte ticketgeschiedenis van de klant, tegen beide architecturen, en we tellen drie categorieën: juist met bron, geweigerd met reden, fout (gehallucineerd of verouderd). Alles boven 5% fout valt door de mand.

import csv, json
from pathlib import Path
from agent_clients import rag_agent, file_search_agent

EVAL_SET = Path("eval/questions.csv")  # cols: question, ground_truth_url

def score(agent, name):
    rows = []
    for row in csv.DictReader(open(EVAL_SET)):
        out = agent.ask(row["question"])
        # out = { "answer": str, "citations": [url], "refused": bool }
        verdict = (
            "refused" if out["refused"]
            else "correct" if row["ground_truth_url"] in out["citations"]
            else "wrong"
        )
        rows.append({**row, "agent": name, **out, "verdict": verdict})
    return rows

results = score(rag_agent, "rag") + score(file_search_agent, "file_search")
Path("eval/out.json").write_text(json.dumps(results, indent=2))

Het is niet glamoureus. Het is het enige getal dat telt.

Refresh-latency in de praktijk

Hoe snel verschijnt een wijziging op een Confluence-pagina in het antwoord van de agent?

Closed-corpus RAG: gelijk aan je herindexeer-cadans. De meeste teams draaien 's nachts, omdat het uurlijks herindexeren van een Confluence-space met 40k pagina's verspilling is. Sommige bouwen een webhook-gedreven incrementele indexer. In de praktijk breekt die binnen negentig dagen, omdat iemand een space verplaatst en de webhook-payloads van vorm veranderen. Het eerlijke veldcijfer is vierentwintig tot tweeënzeventig uur, afhankelijk van of de nachtelijke job groen blijft.

File-search routing: real-time. Het model bevraagt het live systeem. De trade-off is dat elk antwoord de latency van de Confluence search-API betaalt, plus het model dat meerdere volledige pagina's leest. We zien end-to-end responstijden van negen tot veertien seconden voor een niet-triviaal antwoord, tegenover twee tot vier seconden voor de RAG-pipeline.

Voor een belastingadvieskantoor waar de regel deze week tweemaal is gewijzigd, wint real-time. Voor een marketingbureau dat brand-guideline vragen beantwoordt die per kwartaal eens veranderen, wint de snelheid van RAG. Stem de architectuur af op hoe snel jouw waarheid beweegt.

Eigenaarschap van onderhoud na maand veertien

Dit is de vraag die in de architectuurmeeting wordt onderschat en daarna jaar twee domineert.

Closed-corpus RAG heeft een eigenaar nodig. Chunk-grootte, overlap, de keuze van embedder, de reranker-drempel, de prompt die de retriever naar de LLM stuurt: dat alles drift. Zes maanden later moet iemand aan klantzijde kunnen zeggen: "de agent mist tabellen in de technische SOP's omdat we per tokenaantal hebben gechunkt en de tabellen over chunks heen lopen; laten we voor de engineering-space overschakelen op header-aware chunking". Staat die persoon niet op de loonlijst, dan rot de agent stilletjes weg.

File-search routing heeft bijna geen chunking-knoppen. Je schrijft een system prompt, je scopet welke spaces of sites de tool mag doorzoeken, je stelt het weigergedrag in. Daar komt het zo'n beetje op neer. Het model doet het chunk-equivalente werk tijdens het lezen. De onderhoudskosten verschuiven van "data engineer die embeddings begrijpt" naar "policy-persoon die begrijpt welke folders de agent wel en niet mag zien".

Die tweede vorm is meestal wel te bemensen binnen een kantoor onder de €12M. De eerste niet. We hebben precies twee klanten van die omvang gezien die met succes iemand in dienst hielden om een custom RAG-pipeline na maand veertien gezond te houden. Het waren beide softwarebedrijven.

Dat scoping-punt is ook waar de recente verhalen over op hol geslagen agents ertoe doen. Als een autonome agent in het wild bestanden begint aan te raken die hij niet mag aanraken, ligt de oorzaak vrijwel altijd in de breedte van de permissies, niet in modelgedrag. Een file-search agent met een strakke allow-list op folderniveau is makkelijker af te bakenen dan een vector store die zes maanden geleden al alles heeft ingenomen.

De scoresheet die op één pagina past

We scoren de twee architecturen op zeven rijen, elk op een schaal van vijf, naar smaak gewogen:

                                  RAG    File-search
Hallucinatiepercentage (eval)      3         4
Refresh-latency                    2         5
Onderhoudslast jaar 2              2         4
Kosten per 1k antwoorden           5         3
Zoekkwaliteit bronsysteem          5         2
Auditbaarheid (welke pagina)       5         4
Vendor data-retention risico       4         2

De vendor-retention rij is waar het huidige beleid van model-providers ertoe doet. Standaard retention-windows verschillen per vendor en modelklasse; sommige bewaren prompts en responses een aantal dagen aan hun kant voordat ze worden verwijderd. Lees het beleid van je provider voordat je tekent: zie bijvoorbeeld anthropic.com/legal. Voor Nederlandse kantoren waarvan de eigen verwerkersovereenkomst een verwijdertermijn van zeven dagen aan hun klanten belooft, is dit geen breekpunt, maar wel een papierwerkpunt om je FG over in te lichten. Dezelfde rij, gescoord tegen een on-prem embedding-model achter je eigen RAG-pipeline, ziet er beter uit.

Ligt de gewogen score binnen twee punten van elkaar, dan is het juiste antwoord vrijwel altijd file-search routing, omdat onderhoud in jaar twee de stille moordenaar is. Wint RAG met vier of meer punten verschil, dan heb je een echte custom-pipeline use case: hoog volume, smal corpus, strak kostenplafond.

Wanneer file-search routing echt verliest

Tegenwoordig hoor je vaak dat vector stores achterhaald zijn. Wij geloven dat niet. File-search routing verliest helder in drie gevallen.

Het corpus is niet doorzoekbaar via een native API. Leeft jouw kennis in een custom PHP-intranet, een Joomla-site, of een map met 11.000 PDF's op een NAS, dan is er geen search tool om naar te routen. Dan bouw je er sowieso één, en op dat punt zit je halverwege een vector store.

Het volume is hoog genoeg dat de tokenkost per query domineert. File-search routing leest meer tokens per antwoord. Bij duizend antwoorden per dag tikt dat aan. RAG met een kleine reranker wint op unit economics.

Je hebt deterministische citaties nodig voor compliance. RAG met strikte citatie-afdwinging maakt "welke chunk heb je gebruikt" triviaal auditbaar. File-search agents parafraseren soms over drie documenten heen en raken daarbij de precieze paragraaf kwijt.

Wat we voor een Utrechts belastingadvieskantoor deden

Toen we vorig kwartaal de knowledge agent voor dat belastingadvieskantoor bouwden, vroeg de partner ons om RAG. We draaiden de eval. File-search routing scoorde 4/5 op hallucinatiepercentage tegen hun eigen ticketarchief; de geplande RAG-pipeline scoorde 3/5 en zou een halve data engineer nodig hebben om in leven te houden. We leverden file-search routing met een strakke space allow-list, factureerden minder, en ze kregen 's ochtends om 8 uur geen doorgestuurde screenshots meer. Wil je de scoresheet op echte cijfers zien, dan staat dit werk onder onze praktijk AI-agents.

Het kleinste wat je vandaag kunt doen: trek vijftig echte vragen uit je eigen ticketgeschiedenis, plak ze in een spreadsheet, en zet per vraag of het antwoord in de afgelopen week is veranderd. Zijn dat er meer dan tien, dan is je refresh-latency budget uren, geen dagen. Dat ene getal sloopt de helft van de architectuurmeeting voordat hij begint.