Je wilt een chatbot die jouw handleidingen, contracten of kennisbank kent. De korte versie: je traint daar geen model voor bij, je haalt bij elke vraag de juiste passage uit je eigen documenten op en stuurt die mee. Dat heet ophalen bij de bron, in het Engels retrieval augmented generation of RAG. Hieronder lees je wat er precies gebeurt, waarom antwoorden alsnog misgaan en wat je vooraf moet regelen.
Het wezenlijke onderscheid: pas je het model aan, of laat je het model ongemoeid en voer je het per vraag de juiste tekst?
Er zijn twee routes naar een chatbot die jouw stukken kent. Bij de eerste pas je het model zelf aan, bijtrainen of finetunen. Bij de tweede blijft het model zoals het is en zoek je bij elke vraag de relevante passages uit je eigen documenten op, om die als context met de vraag mee te sturen. Die tweede route is wat wij ophalen bij de bron noemen, in het Engels retrieval augmented generation, afgekort RAG.
Bijtrainen is bijna nooit het antwoord, en dat komt niet doordat het duur is maar doordat het het verkeerde probleem oplost. Bijtrainen verschuift vooral stijl, toon en vaardigheden. Het is geen betrouwbare manier om feiten in een model te krijgen. Een bijgetraind model kan bovendien niet aanwijzen waar iets staat, kan niet vergeten wat jij uit je archief hebt gehaald, en moet opnieuw de trainingsmolen door zodra er een contract wijzigt. Ophalen bij de bron doet precies het omgekeerde: je documenten blijven een aparte, beheersbare verzameling, je kunt bij elk antwoord de bron tonen, en een nieuwe versie is een kwestie van opnieuw indexeren.
Volledige openheid: wij bouwen dit soort chatbots en we verkopen prototype-dagen. Dit stuk is geschreven vanuit dat werk, niet als onafhankelijke testbank. We hebben geen commerciële band met Google, OpenAI, Qdrant, Weaviate of een van de andere partijen die hieronder ter sprake komen.
De grens loopt bijna precies langs een vraag: staat het antwoord letterlijk in een document, of moet het worden uitgerekend?
Drie stappen. Geen ervan is magisch, en dat is precies waarom je ze moet kennen.
Je documenten worden in stukken geknipt van een paar alinea’s. Elk stuk gaat door een model dat er een lange reeks getallen van maakt. Teksten die inhoudelijk op elkaar lijken, krijgen reeksen die dicht bij elkaar liggen. Waar je knipt, bepaalt of een clausule heel blijft of halveert.
Die getallenreeksen gaan in een vectordatabase: opslag die niet op woorden zoekt maar op nabijheid. Gangbaar zijn Pinecone, Qdrant, Weaviate, Milvus en Chroma, plus pgvector als uitbreiding op een gewone PostgreSQL-database.
Bij een vraag wordt ook die vraag omgezet naar getallen. De database geeft de dichtstbijzijnde stukken terug en die gaan als context mee naar het model, dat het antwoord formuleert uit wat het meekrijgt. Meer krijgt het niet te zien.
Vrijwel elk verkeerd antwoord komt uit de ophaalstap, niet uit het model. Dit zijn de vier oorzaken die wij het vaakst zien.
Alles meesturen, een ingebouwde documentzoekfunctie gebruiken, of het ophalen zelf bouwen.
Het eenvoudigste alternatief is helemaal geen ophaalmechanisme. Past je hele verzameling in één keer bij het model, dan stuur je hem gewoon integraal mee. Contextvensters zijn de laatste jaren flink gegroeid, dus voor een handvol handleidingen is dat een reëel vertrekpunt en verdwijnt de hele knipvraag. Het wordt traag en verbruikt veel zodra je bij elke vraag alles opnieuw meestuurt, en wat de AI-functies in je app kosten hangt vooral aan die hoeveelheid tekst per vraag.
Bij de grote aanbieders hoef je het ophalen vaak niet meer zelf te bouwen. Google heeft in de Gemini API een ingebouwde documentzoekfunctie die File Search heet: die regelt opslag, knippen, getallenreeksen en het meesturen van de gevonden stukken, verwerkt sinds 2026 ook beeld naast tekst, en kan filteren op metadata en naar paginanummers verwijzen (bron: ai.google.dev en blog.google). OpenAI heeft een vergelijkbare file search-tool met vector stores, eerst alleen in de Assistants API en nu ingebouwd in de Responses API; die oudere Assistants API wordt uitgefaseerd (bron: developers.openai.com). Bij Anthropic bestaat zo’n beheerde variant niet: de ingebouwde tools zijn daar zoeken op het web, pagina’s ophalen en code uitvoeren, dus stuur je bestanden mee of bouw je het ophalen zelf (bron: platform.claude.com).
Wil je de opslag in Europa houden, dan is er echte keuze. Qdrant is een Berlijns bedrijf en Weaviate een Amsterdams, beide open source, dus zelf hosten of hun beheerde variant. Wil je geen extra systeem, dan zet je pgvector op een Europese beheerde PostgreSQL; OVHcloud noemt pgvector expliciet als ondersteunde uitbreiding. Wat het wordt hangt vooral af van waar de rest van je gegevens al staat: zie database kiezen voor je MVP. Zelf bouwen loont als je de knipstrategie, de rechten of de opslaglocatie in eigen hand wilt houden. Moet het model niet bij een kopie kijken maar bij het systeem waar de documenten in staan, dan komt MCP in beeld. En of je een chatbot wilt of iets dat zelf handelt, staat in het verschil tussen een chatbot en een AI-agent.
Geen cijfer. Wel twee dingen die op papier moeten staan voordat er iemand begint te bouwen.
Vraag één: welke documenten zijn de waarheid. Niet alles uit de gedeelde map, maar per onderwerp één aangewezen bron met een eigenaar die hem bijhoudt. Zolang die keuze niet is gemaakt, bouw je een chatbot die de tegenspraak in je archief netjes verwoordt, en dat valt pas op als iemand ernaar handelt. Ruim dus eerst op en indexeer daarna. Dit is bijna altijd het echte werk, en het is bewust geen technische taak.
Vraag twee: wie mag wat zien. Rechten horen in de ophaalstap, niet in de instructie aan het model. Filter de stukken op de rechten van de vragensteller voordat ze naar het model gaan, want een regel in de systeemprompt om bepaalde gegevens niet te tonen is geen toegangscontrole. Wat er met persoonsgegevens in zo’n keten gebeurt en wanneer je leverancier verwerker wordt, staat in klantdata in AI-tools en de AVG.
Wat je hiervan in één werkdag kunt vaststellen: neem twintig tot dertig echte vragen van je eigen mensen of klanten, indexeer een afgebakende set documenten en kijk per vraag of het juiste stuk boven komt. Dat is de test die telt, want levert de ophaalstap het verkeerde stuk, dan maakt geen enkel model dat goed. Hoe je zo’n reeks vragen herhaalbaar opzet, staat in AI-functies testen. Voor het bredere beeld is je eigen AI maken het startpunt, en twijfel je of jouw geval in één dag past, loop dan de kan-dit-in-1-dag-check na.
Ophalen bij de bron is de Nederlandse term voor retrieval augmented generation, afgekort RAG. Je laat het taalmodel ongemoeid en zoekt bij elke vraag de relevante stukken uit je eigen documenten op. Die stukken gaan als context met de vraag naar het model, dat zijn antwoord formuleert uit wat het meekrijgt.
Een vectordatabase slaat de getallenreeksen op die van je tekststukken zijn gemaakt, en zoekt niet op woorden maar op nabijheid: welke stukken liggen inhoudelijk het dichtst bij de vraag. Gangbare namen zijn Pinecone, Qdrant, Weaviate, Milvus en Chroma, en pgvector als uitbreiding op een gewone PostgreSQL-database.
Bijna nooit. Bijtrainen verandert vooral stijl en vaardigheden, niet de feitenkennis, en een bijgetraind model kan niet aanwijzen waar iets staat en niet vergeten wat je hebt verwijderd. Verandert een document, dan moet je opnieuw trainen. Ophalen bij de bron houdt je documenten los van het model, dus een nieuwe versie indexeer je simpelweg opnieuw.
Omdat de zoekstap niet begrijpt dat een document is vervangen. Een oude handleiding die nog in de index staat, is voor die stap net zo geldig als de nieuwe. Dit los je op in het beheer: wijs per onderwerp één geldende bron aan, haal verouderde versies uit de index en indexeer opnieuw bij elke wijziging.
Niet betrouwbaar. Ophalen levert citaten, geen berekeningen. Een vraag naar een totaal, zoals hoeveel contracten er dit kwartaal aflopen, heeft een antwoord dat in geen enkel stuk tekst staat. Daarvoor heb je een zoekopdracht op gestructureerde gegevens nodig, dus een database of een rekenstap naast de chatbot.
In de ophaalstap, niet in de instructie aan het model. Filter de stukken op de rechten van de vragensteller voordat ze naar het model gaan. Een instructie in de systeemprompt om bepaalde gegevens niet te tonen is geen toegangscontrole: zodra een stuk in de context zit, kan het in het antwoord belanden.
Stuur ons je twintig meestgestelde vragen en een paar documenten. Wij kijken in een intake mee welke bron de waarheid is en leveren in één werkdag een klikbaar prototype dat antwoordt uit jouw eigen stukken.
Een korte intake volgt na je inschrijving. Daarna stemmen we scope en datum af.
We nemen contact op om de intake in te plannen.
We gebruiken cookies om je ervaring te verbeteren en het gebruik van de site te meten.