De meeste zakelijke kennisbanken hebben geen RAG nodig

Ik draai mijn interne bedrijfswiki op vijf shell-commando's en een handmatig bijgehouden indexbestand. Geen embeddings, geen vector database, geen herindexeringstaak. Voor een kennisbank van circa 200 documenten is die opzet sneller te bouwen, goedkoper te draaien en nauwkeuriger dan een gemiddelde RAG-pipeline. De afweging wordt pas interessant ergens boven de duizend documenten, niet eerder.

Een korte noot over Karpathy en Obsidian

Twee zaken maakten deze aanpak vanzelfsprekend. De eerste is het consistente standpunt van Andrej Karpathy dat AI-agents tools moeten krijgen in plaats van opgehaalde fragmenten. Zijn AutoResearch-project, uitgebracht in maart 2026, maakt dat argument letterlijk waar: de agent voert code uit in plaats van embeddings te bevragen, en voortgang ontstaat door executie. AutoResearch werd uitgebreid behandeld in een eerder artikel.

De tweede is Obsidian. Een Obsidian vault is gewoon een map met gewone markdown-bestanden. Er is geen proprietary database, geen schema om te migreren, geen SDK om te leren. In combinatie met de lokale REST API-plugin van Obsidian staat de volledige kennisbank achter een normaal HTTP-endpoint dat elk proces kan lezen of schrijven. Die combinatie maakt het patroon "geef de agent tools" triviaal te implementeren: een handvol shell-commando's en u hebt een LLM dat een gestructureerde kennisbank direct kan lezen, schrijven en doorzoeken.

Wat er daadwerkelijk draait

Mijn interne wiki bestaat vandaag uit 22 pagina's gestructureerde kennis: entiteiten (personen, bedrijven, projecten), concepten (frameworks en principes), bronnen (ruwe onderzoeksnotities) en synthesepagina's die alles verbinden. Elke pagina verwijst naar andere pagina's via Obsidian wikilinks, en een handmatig bijgehouden `index.md` in de root somt alles op per categorie met een beschrijving van één regel.

De agent doorzoekt de vault niet met embeddings. Hij voert vijf commando's uit:

• `wiki read <path>`. Haal een enkele markdown-pagina op.
• `wiki write <path> -`. Maak een pagina aan of overschrijf deze vanuit stdin.
• `wiki append <path> <text>`. Voeg een regel toe aan een pagina (gebruikt voor het lopende activiteitenlogboek).
• `wiki search <query>`. Gebruik de ingebouwde full-text search van Obsidian.
• `wiki list <dir>`. Toon bestanden in een map.

De volledige implementatie beslaat ongeveer 80 regels bash en curl. Geen vector database, geen embedding-model, geen chunking-strategie, geen reranker, geen nachtelijke herindexeringstaak. Een nieuwe notitie toevoegen betekent het bestand schrijven. De agent pakt het op bij de volgende query, zonder tussenliggende pipeline-stap.

Het indexbestand is het ophaalsysteem

Het ongemakkelijke deel: de agent begint met `wiki/index.md`. Die samengestelde inhoudsopgave vermeldt elke pagina met een beschrijving van één zin, gegroepeerd per categorie. Na die ene lezing van ongeveer 400 tokens weet de agent al welke een of twee pagina's relevant zijn.

De volgende stap is één of twee gerichte leesacties om de relevante pagina's volledig op te halen. Elke pagina telt tussen de 200 en 800 tokens. De meeste queries eindigen met twee of drie leesacties en circa duizend tokens aan vault-inhoud in het contextvenster. Dat is minder dan wat een standaard RAG-configuratie injecteert, en de inhoud is samenhangend (volledige pagina's) in plaats van opgeknipt (fragmenten losgerukt uit hun context).

Een bijgehouden index doet het werk dat een vector database doet in een RAG-pipeline: het koppelt een query aan de juiste documenten. Het verschil is dat een mens die koppeling eenmalig heeft gecureerd, in plaats van een embedding-model dat de koppeling bij elke query benadert.

De vergelijking in tokens en kosten

Voor een kleine zakelijke kennisbank van circa 200 documenten ziet u hier wat een standaard RAG-opzet kost tegenover het index-gestuurde bestandstoegangspatroon. De tokenaantallen zijn richtinggevende schattingen op basis van typische ophaalpatronen. De infrastructuurcijfers zijn ontleend aan publieke prijslijsten van de meest gebruikte beheerde services.

Tokenbesparing hangt af van corpusstructuur en querypatronen. Het grotere punt is alles in de tweede kolom dat verdwijnt: geen vector database-regel op de maandelijkse factuur, geen embedding-model om te onderhouden, en geen debugsessie over verschuivende antwoorden wanneer de chunking-strategie is gewijzigd. Voor een kennisbank die comfortabel in het hoofd van één persoon past, is elk van die bewegende onderdelen overhead zonder bijbehorend voordeel.

Wat u niet meer hoeft na te denken

De scherpste manier om voor dit patroon te pleiten is het opsommen van de beslissingen die wegvallen:

• Chunking-strategie. Geen discussie over "moeten we opsplitsen per alinea, per zin of per aantal tokens?". De pagina is de eenheid.
• Keuze van het embedding-model. Geen onderzoeksproject waarbij text-embedding-3-small wordt vergeleken met fijngestemde alternatieven.
• Beheer van de vector database. Geen beheerde service om te monitoren, te upgraden of voor te begroten.
• Herindexeringspipelines. Geen nachtelijke batchtaak, geen Slack-berichten over een verouderde index.
• Evaluatiesuite voor ophalen. Geen precision-and-recall-testsuite die naast de kennisbank draait.
• Afstemming van hybrid search. Geen BM25-plus-vector-plus-rerank-pipeline om in balans te houden.

Dat is grofweg het volledige RAG-operationshandboek, verwijderd. Wat ervoor in de plaats komt, is één shellscript en de discipline om een indexbestand accuraat te houden. Die discipline is reëel, maar het is dezelfde discipline die een wiki in de eerste plaats waardevol maakt voor mensen.

Wanneer RAG toch de juiste keuze is

Dit patroon heeft duidelijke grenzen. Een bijgehouden index werkt niet meer ergens rond de 1.000 documenten, wanneer een mens de structuur niet langer in zijn hoofd kan houden en het indexbestand te lang wordt voor de agent om bij elke query efficiënt te scannen. Boven die schaal verdienen embeddings en een echte ophaallaag hun plaats.

Andere gevallen waarin RAG het juiste instrument blijft:

• Multimodale corpora. PDF's met tabellen, gescande documenten, audiotranscripties, beeldrijke rapporten. Een markdown-vault veronderstelt dat alles teruggebracht kan worden tot tekst.
• Hoogfrequente updates op schaal. Als u duizenden publieke documenten indexeert die elke minuut wijzigen en direct doorzoekbaar moeten zijn.
• Strikte metadatafiltering bij ophalen. Wanneer queries gestructureerde filters vereisen (datumbereiken, auteur, documenttype) die ingebakken zijn in de ophaalstap, is een vector database met metadata de schonere oplossing.
• Onbetrouwbare of adversariale inhoud. Wanneer het corpus afkomstig is van veel schrijvers met conflicterende agenda's en geen enkele mens vertrouwd kan worden om een gecureerde index bij te houden.

Voor de meeste interne zakelijke kennisbanken (bedrijfswiki's, productdocumentatie, verkoophandboeken, onboardinggidsen, interne standaardprocedures) gelden geen van die voorwaarden. Het corpus is klein, het aantal schrijvers is beperkt, de structuur is stabiel, en de mensen die de documentatie onderhouden zijn degenen die het meest belang hebben bij correctheid. Voor de use cases die ik zie is RAG vaak de verkeerde standaard.

Wat dit betekent voor de meeste bedrijven

Als u een klein of middelgroot bedrijf bent dat naar uw bestaande documentatie kijkt en zich afvraagt hoe u die doorzoekbaar kunt maken voor AI, is het eerlijke antwoord meestal dat u geen vector database nodig hebt. U hebt een indexbestand nodig, een kort script dat uw documenten leest en schrijft, en een LLM met toegang tot tools. De onderdelen zijn allemaal beschikbaar. Het werk zit in het accuraat houden van de index.

De bedrijven die RAG-as-a-service aanbieden hebben het niet mis over de technologie; het meningsverschil gaat over wanneer het de standaardarchitectuur moet zijn. RAG is het juiste instrument voor problemen op een schaal die de meeste bedrijven niet hebben, bij inhoudstypen die de meeste bedrijven niet opslaan. Als eerste naar RAG grijpen leidt soms tot lange roadmaps en terugkerende infrastructuurkosten voordat de oorspronkelijke use case is ingelost.

webvise bouwt interne AI-tools op dit soort pragmatische basis: gestructureerde kennis, eenvoudige tools, agents die direct lezen en schrijven. Als u naar een RAG-project kijkt voor de documentatie van uw team en een tweede mening wilt over of de complexiteit gerechtvaardigd is, neem dan contact op om uw concrete corpus te bespreken voordat u zich vastlegt op de infrastructuur.