De motor met zes polen — De mythe van de tien regels code

Onderzoek in zes delen naar de redenen waarom de documentchatbot die je hebt gekocht blijft verzinnen — en naar de andere richting die begin 2026 door iemand is ingeslagen.

Onderzoek in zes delen naar de redenen waarom de documentchatbot die je hebt gekocht blijft verzinnen — en naar de andere richting die begin 2026 door iemand is ingeslagen.

Intro — De motor met acht polen (maar er waren er zes)

Milaan, maart 2026. Een manager opent de interne bedrijfschatbot, van het type dat in "twee weken" door de IT-afdeling is geïnstalleerd met groot enthousiasme en weinig wantrouwen. Een simpele vraag: "Hoeveel polen heeft de CMP40M motor?" De chatbot antwoordt met alle zekerheid die grote taalmodellen kunnen tonen: "De CMP40M motor heeft acht polen."

Fout. Hij heeft er zes. Het juiste antwoord stond niet in de catalogus van 422 pagina's die iemand, maanden eerder, met het grootste vertrouwen in een vector database had gepompt, ervan overtuigd dat het systeem daarna "alles zou weten". Die data was simpelweg niet in de catalogus aanwezig. Het stond in een PDF bijgevoegd bij een e-mail van de SEW-technici, opgeslagen in een map die niemand de moeite had genomen te indexeren.

Deze scène, met variaties in sector en dialect, herhaalt zich in honderden Italiaanse kantoren. De belofte was simpel en verleidelijk: geef al je bedrijfsdocumenten aan je AI-assistent, en hij kan elke vraag erover beantwoorden. De realiteit is veel prozaïscher: de chatbot leest wel, maar begrijpt niet, zoekt wel, maar vindt niet, en als hij niets vindt – zegt hij het niet – dan verzin hij iets. Hij verzin het vloeiend, met perfecte grammatica, met plausibele cijfers. En dat is veel erger dan niet antwoorden.

Tussen eind 2024 en begin 2026 hebben we maanden besteed aan het uitvoeren van een autopsie op deze mislukkingen. Niet om controverses aan te wakkeren, maar om te begrijpen waarom een zo lineair idee – "geef hem de documenten en stel hem dan vragen" – zo moeilijk wordt wanneer het van het demonstratiepodium afstapt en de ruimte van de echte servers binnenkomt.

Dit onderzoek in zes hoofdstukken vertelt wat we hebben ontdekt: stille bugs die hele catalogi verwijderden, cloud rerankers met verkeerde scores, hallucinaties die niet door het model, maar door vervuilde data ontstonden die jaren eerder al besmet was, uitgaande facturen die elke query duurder maakten dan de waarde ervan, en "populaire" frameworks die alles beloven in tien regels code, zolang je er niet te veel van vraagt. En in het laatste hoofdstuk, de andere richting die iemand, in stilte, begin 2026 is gaan inslaan – een architectuur waarin de zoekstrategie stopt met het zijn van code en een document wordt dat iedereen in het bedrijf kan lezen en bewerken.

Elk hoofdstuk staat op zichzelf. Als je wilt beginnen met het verhaal van de 342 verdwenen tabellen, of dat van de leugenachtige reranker, ben je vrij om dat te doen. Maar het verhaal als geheel heeft een moraal die pas aan het einde naar voren komt: de bedrijfs-RAG – dat technische acroniem dat staat voor Retrieval-Augmented Generation, oftewel "genereer antwoorden op basis van documenten die je eerst ophaalt" – is nog geen afgewerkt product. Het is een grensgebied. En zoals alle grensgebieden is het tot nu toe vooral door verkopers verteld. Het is tijd om ook te luisteren naar degenen die erin hebben geleefd.

Hoofdstuk 1 — De mythe van de tien regels code

De slide is identiek op elke conferentie over AI sinds 2023: "Uw bedrijfsdocument assistent in 10 regels code." Onder de titel een blok Python in pastelkleuren dat een open source bibliotheek laat zien - typisch een van die bekende Amerikaanse, waarvan de naam ketens van bomen of Tibetaanse lama's oproept - die PDF's laadt, ze in stukken breekt, ze in een vector database plakt en ze beantwoordt met een taalmodel. In vijf minuten heb je een chatbot. In vijf minuten, het applaus. In vijf minuten is een Italiaans bedrijf van gemiddelde grootte ervan overtuigd dat het probleem is opgelost en dat zijn IT-afdeling het in twee weken kan doen.

Het probleem - wat de slide niet zegt - is dat de demo is gebouwd met drie goed opgemaakte PDF's, een vraag die op maat is gemaakt om overeen te komen met de inhoud, een podium zonder echte latentie, en een presentator die het allemaal zevenentwintig keer heeft geprobeerd voordat hij het podium opging. In de werkelijkheid zijn bedrijfsdocumenten een geologische ramp: scans van scans, tabellen die over de tekst heen vallen, voetnoten die in de paragrafen glippen, alfanumerieke codes zoals "RH1M" die de chunker halverwege doorsnijdt omdat hij ze voor woorden aanziet, afbeeldingen die zeventig procent van de nuttige informatie bevatten maar die niemand echt extraheert, en lay-outs die zo creatief zijn dat ze een archeoloog vereisen in plaats van een parser.

RAG – dit is het idee achter de schermen – is een geweldig idee. Neem de vraag van de gebruiker, zoek in uw archief naar de meest relevante documenten, geef deze aan het taalmodel en laat het een antwoord genereren op basis van die documenten. In theorie lost dit elegant het probleem van hallucinaties op: het model hoeft het antwoord niet meer "te weten", het hoeft het alleen maar "te lezen" in de stukken die u het hebt gegeven. In de praktijk heeft elke schakel in de keten – het chunking, de embedding, de retrieval, de reranking, de uiteindelijke generatie – zijn eigen manier om te breken, en de breuk manifesteert zich zelden als een zichtbare fout. Het manifesteert zich als een licht verkeerd antwoord. Dan als een volledig verkeerd antwoord. Dan als een manager die zich afvraagt waarom hij betaalt voor een systeem dat minder weet dan de stagiair.

De open source frameworks die RAG populair hebben gemaakt, zijn bedoeld om te demonstreren, niet om te produceren. Het zijn uiterst elegante ketens van abstracties waarin elke laag een onuitgesproken aanname verbergt: dat je PDF's een fatsoenlijke OCR hebben, dat je foto's al beschreven zijn, dat je tabellen een conventie volgen, dat het embeddingmodel daadwerkelijk jouw taal spreekt (spoiler: velen spreken alleen goed Engels), dat je archief al van duplicaten is ontdaan. Wanneer een van deze aannames niet klopt – en minstens één klopt er altijd niet, bijna altijd drie – stopt het systeem niet met werken. Sterker nog: het stopt met goed werken, maar blijft antwoorden geven. Vloeiende, zelfverzekerde antwoorden, en vaak los van de waarheid.

Er is een uitspraak die de ronde doet onder de mensen die deze systemen professioneel bouwen, en die je nooit in tutorials zult lezen: "RAG is gemakkelijk te maken, en moeilijk goed te maken." Tussen de eerste demo en de productieservice zit een kloof die je niet kunt overbruggen door GPU's toe te voegen of van model te wisselen. Je overbrugt het door iets ongemakkelijks te begrijpen: wanneer je een bedrijfs-RAG bouwt, schrijf je geen code. Je ontwerpt een kleine, hardnekkige zoekmachine op maat gemaakt voor jouw documenten, met alle redactionele keuzes die dit met zich meebrengt — wat is ruis, wat is signaal, wat moet er dubbel worden geïndexeerd, wat moet er worden weggegooid. Alleen in tutorials van tien regels worden deze keuzes één keer voor je gemaakt, door iemand die jouw documenten nog nooit heeft gezien. En het zijn bijna altijd de verkeerde keuzes voor jouw situatie.