Strategie als document — Het zevende hoofdstuk

Hoofdstuk 6 — Strategie als document, niet als code

We komen bij de inzichten die, in het verhaal van degenen die RAG vanaf 2023 hebben gebouwd, het vaakst voorkomen als "het ding dat ik vanaf dag één had willen begrijpen".

Traditionele frameworks behandelen de zoekstrategie als Python-code. Wil je, voor technische catalogi, eerst zoeken op productcode, dan op trefwoorden, dan op semantische vectoren, en pas als laatste de reactie genereren? Schrijf een functie. Wil je, voor fotoalbums, de traditionele semantische zoekopdracht helemaal overslaan en vertrouwen op een gespecialiseerde reranker voor afbeeldingen? Schrijf een andere functie. Wil je, voor bedrijfsvideo's, het geluid van het visuele spoor scheiden, ze afzonderlijk transcriberen, ze als afzonderlijke bronnen behandelen en ze vervolgens in de uiteindelijke reactie samenstellen? Nog een functie. Elk type inhoud, elke branche, elke klant leidt uiteindelijk tot een codebranch die afwijkt van de andere, totdat het wijzigen van een strategie een software release, een code review, een testcyclus, een implementatie vereist. De tijd tussen "ik heb een idee om de zoekopdracht in technische handleidingen te verbeteren" en "het idee is in productie" wordt gemeten in weken. Voor elk idee.

De alternatieve kijk is simpel te zeggen en diepgaand in de gevolgen: de zoekstrategie is geen code. Het is een document. Een JSON – een gestructureerd tekstformaat dat elke redacteur, met een half uur training, kan lezen – die zegt: "probeer eerst dit, dan dat, als het eerste faalt ga dan naar het derde, herordeneer zo, antwoord met dit model." Dit document leeft in een database, niet in een repository. Het wordt bewerkt via een interface, niet via een pull request. Het wordt versiebeheerd, gekopieerd en gespecialiseerd per domein. Een strategie voor technische catalogi, een voor fotoalbums, een voor installatiehandleidingen, een voor video's, een voor audio, een voor juridische contracten, een voor balansoverzichten. Ze co-existeren allemaal in hetzelfde systeem. Ze zijn allemaal in realtime te bewerken.

Wie met deze aanpak heeft gewerkt – laten we het, zonder al te veel verbeelding, Meta-RAG noemen – vertelt over een snelheidsverandering die verder gaat dan engineering. Een typische klantvraag "voeg een specifieke zoekopdracht toe voor productcodes die afkortingen bevatten zoals CMP40M of RH1M" is niet langer een ontwikkelticket van twee weken. Het is een nieuwe stap die aan een JSON-procedure wordt toegevoegd, snel getest in een staging-omgeving, en in een middag naar productie gepromoveerd. De vraag "wat verandert er als we een andere reranker voor foto's gebruiken, terwijl we de huidige voor tekst behouden?" wordt beantwoord door één regel configuratie te wijzigen. Het experiment kost niets, het terugdraaien kost niets (gewoon de vorige versie van het document herstellen), en de opgedane kennis – wat goed werkt voor een bepaald type inhoud – wordt een versiebeheerde en overdraagbare aanwinst, niet de impliciete kennis van degene die die specifieke codebranch heeft geschreven en nu op vakantie is.

Er is ook een interessant sociaal effect dat naar voren komt in organisaties die deze aanpak hanteren. Met strategieën als document verschuift de grens tussen "ontwikkelaar" en "expertgebruiker". Een digitale bibliothecaris, een bedrijfsarchivaris, een domeinexpert – de hoofd van de technische afdeling, de documentatieverantwoordelijke, de productmanager die als geen ander de echte vragen van de klanten kent – kan een strategie lezen, begrijpen wat het doet, wijzigingen voorstellen en soms zelfs direct schrijven. Ze hoeven niet door de trechter van het ontwikkel ticket te gaan, ze hoeven geen dingen uit te leggen die de ontwikkelaar niet weet (omdat het niet tot zijn werkgebied behoort om die te weten). De RAG stopt met het zijn van een product dat je consumeert en wordt een tool die je vormgeeft op basis van je organisatorische kennis. Dit, volgens de ervaring van degenen die het hebben geprobeerd, verandert het moreel van het project nog voordat de cijfers van de metrics veranderen.

Het is geen magie, en het heeft zijn kosten. Er is een motor nodig die deze strategieën-als-documenten efficiënt en veilig uitvoert. Er is een beschrijvingstaal nodig die rijk genoeg is om reële scenario's te omvatten, maar ook arm genoeg om niet een andere Turing-complete vermomming te worden. Er zijn tools voor versiebeheer, testen en terugdraaien nodig. Maar dit alles is het probleem van degene die de motor bouwt – eenmalig, en voor alle gebruikers. De individuele eindklant ziet slechts één ding: de mogelijkheid om zijn zoekstrategie te laten evolueren met de snelheid van de gedachte, in plaats van met de snelheid van de software releasecyclus. En voor degenen die erin zitten, is dit een stille revolutie die nog geen naam heeft gevonden in de vakbladen.

Afsluiting — Hoofdstuk zeven, over een paar maanden

Begin 2026, na het optellen van de lessen uit de voorgaande hoofdstukken – de verloren tabellen, de leugenachtige rerankers, de overgeërfde hallucinaties, de cloudfacturen die sneller stegen dan de waarde, de veelbelovende maar starre frameworks – begon iemand in Italië met de bouw van een andere RAG-server. Geschreven in Python, ontworpen om te draaien op toegankelijke hardware, in staat om met cloudmodellen te communiceren wanneer dat handig is en met lokale modellen wanneer privacy dat vereist of de kosten niet kloppen. Een server waarin zoekstrategieën bewerkbare documenten zijn, de reranker een lokaal proces op GPU is, tabellen niet verloren gaan omdat ze als volwaardige burgers worden behandeld, foto's geen objecten erven van stoffige archieven uit andere tijdperken, en de kosten per query – zowel in geld als in gegevens die naar derden worden gelekt – bekend en controleerbaar tot op de cent zijn.

We zullen de naam van het project niet noemen. Dit is niet het moment om dat te doen, en we willen geen onderzoek veranderen in een reclame. Maar als de voorgaande hoofdstukken je een situatie hebben laten herkennen die je meemaakt – een bedrijfschatbot die met vertrouwen verkeerde antwoorden geeft, een RAG-project dat al maanden niet van de grond komt, een cloudfactuur die sneller stijgt dan de waarde die het oplevert, een groeiend vermoeden dat je vertrouwelijke documenten naar plaatsen reizen die je niet kent – dan is het de moeite waard om te weten dat er een andere weg is, die door iemand in Italië is bewandeld, en die in 2026 de eerste antwoorden begon te geven die in 2023 werden verwacht.

Het goede nieuws is dat bedrijfs-AI eindelijk de demofase verlaat. Het minder goede nieuws is dat het die fase verlaat met alle littekens van de reis: opgeblazen frameworks, afhankelijkheid van providers, monolithische architecturen, vuile data, stille bugs en een bepaalde neiging van de industrie om oplossingen te verkopen nog voordat het probleem is begrepen. We hebben er in zes hoofdstukken over verteld. Het zevende – het verhaal van wat er gebeurt als eindelijk iemand de dingen goed doet, met geduld, in het Italiaans en in open source – zullen we binnenkort schrijven, met minder voorzichtigheid over de namen en meer cijfers op tafel.

Ondertussen, als je hier bent gekomen, heb je al meer zelfonderzoek gedaan dan 90% van de besluitvormers die momenteel een contract tekenen voor een bedrijfschatbot zonder de vragen te stellen die jij hebt gesteld tijdens het lezen van deze hoofdstukken. Het is een betere startpositie dan waar zij mee zijn begonnen. En in de komende maanden zal het verschil tussen degenen die deze vragen hebben gesteld en degenen die dat niet hebben gedaan, zeer zichtbaar worden op de facturen – en op de antwoorden die jouw AI zal geven aan jouw klanten.

Dit onderzoek is opgesteld in april 2026, gebaseerd op achttien maanden ervaring met het ontwerpen, bouwen en optimaliseren van bedrijfs-RAG-systemen tussen eind 2024 en begin 2026.