Je hebt een berg eigen documenten. Rapporten, contracten, notulen, intake-formulieren, een wiki van 800 pagina’s. En je vraagt je af: kan ik daar niet gewoon een AI op zetten waar mijn team vragen aan kan stellen? Het korte antwoord is ja, en de techniek heet RAG. Het lange antwoord: er zit meer onder de motorkap dan een ChatGPT-achtige UI suggereert, en wie de stappen overslaat krijgt hallucinaties in plaats van bruikbare antwoorden. Dit artikel legt uit hoe een AI agent over eigen data werkt, welke componenten je nodig hebt, wat het kost en welke valkuilen wij de afgelopen 18 maanden in MKB-projecten zijn tegengekomen. Met echte cijfers en een case study van een klant waar we precies dit voor bouwden.
Wat is RAG en waarom heb je het nodig?
RAG staat voor Retrieval Augmented Generation. In gewone taal: een AI-model krijgt bij elke vraag eerst de relevante stukken uit jouw documenten erbij geserveerd, en genereert pas dan een antwoord. Het model “weet” dus niet zelf wat er in jouw rapporten staat, het zoekt het op het moment dat je iets vraagt. Zonder retrieval moet je alles in de prompt proppen, en zonder generation krijg je alleen brokken tekst zonder synthese.
Waarom niet gewoon ChatGPT? Drie redenen. Eén: ChatGPT kent jouw interne data niet. Het model is getraind op publieke tekst en heeft geen idee wat er in jouw klantcontracten of consultancy-rapporten staat. Twee: een context-window van 200.000 tokens klinkt veel, maar als je daar maandelijks 50.000 documenten doorheen gooit zit je binnen drie zoekopdrachten boven de €100 in API-kosten per vraag. Drie: ChatGPT geeft geen bronvermelding. Voor MKB-bedrijven die juridische, financiële of medische informatie verwerken is dat geen optie. Wie het verschil tussen losse chatbots en echte agents helder wil zien, leest AI agents vs chatbots.
RAG lost die drie problemen tegelijk op. Je houdt eigen data lokaal, je betaalt alleen voor de stukken die echt relevant zijn, en je kunt bij elk antwoord laten zien uit welk document de informatie kwam. Voor de bredere context van AI in het MKB raden we ook onze AI automatisering gids aan.
Welke onderdelen heeft een RAG-systeem?
Onder de motorkap van elke werkende RAG-setup zitten vijf componenten. Ze hangen samen en geen enkele kun je weglaten zonder kwaliteit te verliezen.
- Ingestion (document opname). Je RAG-systeem moet weten welke bronnen erbij horen. Dat kunnen PDFs zijn, Google Docs, Notion-pagina’s, SharePoint, intranet of een database. Bij ingestion haal je de ruwe tekst eruit, plus metadata zoals auteur, datum en bron-URL.
- Chunking (stukken knippen). Lange documenten kun je niet in hun geheel aan een AI-model voeren. Je knipt ze in stukken van 300 tot 800 tokens (ongeveer 200 tot 500 woorden). Te grote chunks geven onnauwkeurige retrieval, te kleine chunks verliezen context.
- Embedding (omzetten naar vectoren). Elke chunk gaat door een embedding-model dat de tekst omzet naar een lijst getallen (een vector van bijvoorbeeld 1.536 dimensies). De OpenAI embeddings documentatie geeft een goed startpunt.
- Vector-database (opslag en zoeken). De embeddings sla je op in een vector-database die supersnel “lijkende” vectoren kan vinden. Wij gebruiken meestal pgvector of Qdrant omdat we daar volledige controle hebben over hosting en data-locatie.
- Retrieval en generation (het antwoord bouwen). Bij een binnenkomende vraag haalt het systeem de top 5 tot 10 meest relevante chunks op, plakt die voor een LLM-prompt, en laat het model een antwoord formuleren met expliciete bronverwijzingen.
Sommige teams voegen nog een reranking-stap toe tussen retrieval en generation: een tweede model dat de top 20 chunks herordent op echte relevantie voor de specifieke vraag. Dat verhoogt de kwaliteit van antwoorden flink, vooral als je dataset boven de 10.000 chunks komt.
Welke tools gebruiken wij?
Eerlijke vergelijking van de tools die wij de afgelopen 18 maanden in productie hebben gebruikt voor Nederlandse en internationale MKB-klanten.
| Categorie | Optie | Sterk in | Wij kiezen het bij |
|---|---|---|---|
| Framework | LangChain | Grootste ecosystem, veel integraties | POCs en complexe agents |
| Framework | LlamaIndex | Sterk in data-ingestion en query-engines | Document-zware setups |
| Vector-DB | Pinecone | Managed, schaalbaar, weinig onderhoud | Klanten zonder ops-team, US-data acceptabel |
| Vector-DB | Qdrant | Open-source, snel, EU-hosting mogelijk | AVG-gevoelige projecten, self-hosted |
| Vector-DB | pgvector | Werkt in bestaande Postgres | MKB-klanten die al Postgres draaien |
| LLM | OpenAI (GPT-4o) | Beste kwaliteit voor de meeste tasks | Productie-systemen op antwoord-kwaliteit |
| LLM | Anthropic (Claude Sonnet) | Sterk in lange context en analytisch redeneren | Juridische en consultancy-cases |
| LLM | Mistral (EU) | EU-gehost, open-weight modellen | Klanten met strenge data-locatie-eisen |
Je hoeft niet de duurste tool te kiezen om goede resultaten te krijgen. Een setup met LlamaIndex, pgvector en GPT-4o-mini draait in productie voor minder dan €60 per maand bij modaal MKB-volume. Een setup met LangChain, Pinecone en GPT-4o kost al snel €250 per maand. Het verschil in antwoord-kwaliteit is in 8 van de 10 gevallen niet meetbaar.
Concrete case: Planit Consulting
Bij Planit Consulting, een Britse consultancy, liepen de consultants tegen een probleem aan. Het zoeken in eigen archieven (rapporten, notulen, deliverables) kostte gemiddeld twee uur per consultant per week. Wij bouwden voor hen een AI-assistent op basis van RAG: alle deliverables in een ingestion-pipeline, chunks van 600 tokens in Qdrant op een Frankfurt-server, embeddings via OpenAI, generation via Claude Sonnet. Elke vraag krijgt een antwoord met directe links naar de bron-documenten. Alle data binnen de EU. Resultaat: twee uur per consultant per week bespaard.
Wat kost een RAG-setup?
De scope bepaalt de prijs, en wij zitten bewust aan de onderkant van wat hiervoor in de markt gevraagd wordt. Een POC staat er in twee weken; een volledige productie-opzet voor 30 medewerkers, met de nodige aandacht voor security, performance en monitoring, leveren we in ongeveer vier weken. Dat is grofweg de helft van de doorlooptijd die je elders kwijt bent.
| Onderdeel | POC | Productie-grade RAG |
|---|---|---|
| Ingestion (50-500 documenten) | €1.800 | €4.500 |
| Chunking + embedding pipeline | €1.200 | €2.200 |
| Vector-database setup | €1.000 (pgvector) | €2.800 (Qdrant cluster) |
| Retrieval + reranking | €1.400 | €3.300 |
| UI / chat-interface | €2.200 | €4.500 |
| Eval-suite en monitoring | €400 | €2.700 |
| Eenmalig totaal | €8.000 | €20.000 |
| Tooling per maand | €25-50 | €80-200 |
De maandlasten zijn vaak verrassend laag. Een productie-RAG voor 30 gebruikers op modaal volume (200 vragen per dag) kost circa €120 per maand all-in. Vergelijk dat met een per-zetel SaaS-licentie van €25 per maand per gebruiker bij vergelijkbare tools (€750 voor 30 mensen) en het rekent zich binnen vier maanden terug.
Hoe ziet een simpele RAG-flow eruit in code?
Onder de motorkap is een eerste RAG-flow verrassend compact. Het onderstaande Python-voorbeeld toont de kern in 10 regels met LangChain, een vector-store en een LLM.
from langchain.vectorstores import Qdrant
from langchain.embeddings import OpenAIEmbeddings
from langchain.chat_models import ChatOpenAI
from langchain.chains import RetrievalQA
embeddings = OpenAIEmbeddings(model="text-embedding-3-small")
vectorstore = Qdrant.from_documents(docs, embeddings, location=":memory:")
llm = ChatOpenAI(model="gpt-4o-mini", temperature=0)
qa = RetrievalQA.from_chain_type(llm=llm, retriever=vectorstore.as_retriever(k=5))
antwoord = qa.run("Welke methodologie gebruikten wij bij klant X in 2024?")Wat je niet ziet in dit voorbeeld: de echte complexiteit zit in document-parsing voor de eerste regel, prompt-engineering voor consistente antwoorden, en evaluatie of de retrieval inderdaad de juiste chunks pakt. Voor de bredere afweging zie no-code vs custom automation.
Welke veelvoorkomende valkuilen vermijden?
- Te grove chunking. Test minimaal drie chunk-groottes voor je live gaat. Bij Planit gingen we van 1.000 naar 600 tokens en zagen retrieval-precisie 22 procent omhoog.
- Geen reranking. Een reranker herordent de top 20 chunks op echte relevantie. Kost 50 milliseconden per query en verhoogt antwoord-kwaliteit fors. Cohere Rerank en BGE Rerank zijn populair.
- Hallucinaties accepteren. Bouw in je prompt: “Antwoord alleen op basis van de gegeven bronnen. Als de bronnen geen antwoord geven, zeg dat.” Scheelt 80 procent van de hallucinaties.
- Geen citations. Laat het model na elke claim de bron-chunk noemen, en toon in de UI een klikbare link naar het origineel. Zonder bronvermelding kan je gebruiker een antwoord niet verifieren.
- Geen eval-suite. Bouw een set van 50 tot 200 vragen met bekende correcte antwoorden, en draai die automatisch na elke wijziging. Zonder eval bouw je in het wilde weg.
Hoe meet je of RAG goed werkt?
- Retrieval precision. Van de top-5 chunks die het systeem ophaalt, hoeveel zijn echt relevant? Een goed systeem zit boven 80 procent. Onder 60 procent betekent dat je chunking of embeddings niet goed zitten.
- Answer accuracy. Klopt het antwoord inhoudelijk? Boven 85 procent is goed, onder 70 procent betekent fundamenteel mis.
- Latency. Voor interactief gebruik moet je onder 3 seconden zitten. Boven 5 seconden haken gebruikers af. Splits de latency op in retrieval, reranking en generation.
Daarnaast volg je in productie nog twee dingen: kosten per vraag en gebruiks-patronen. Voor de bredere inrichting van rapportages zie ook onze data en rapportage oplossing.
Wanneer is RAG overkill voor jouw use case?
- Statische FAQ met onder de 50 items. Een gewone chatbot of simpele search-functie is goedkoper en sneller. Lees AI agents vs chatbots.
- Documenten die zelden veranderen en zelden geraadpleegd worden. Een goede mappenstructuur en zoekfunctie volstaat.
- Sterk gestructureerde data. Voor vragen over getallen of relaties tussen entiteiten is een SQL-query of dashboard sneller en betrouwbaarder.
Hoe begin je concreet?
- Week 1: scope en data-audit. Documenteer 20 voorbeeldvragen met bekende correcte antwoorden. Dat is je eerste eval-set.
- Week 2: ingestion + indexering. Bouw de pipeline die documenten ophaalt, opschoont, in chunks knipt en embeddings genereert.
- Week 3: UI en prompt-engineering. Bouw een minimale chat-interface. Test met drie tot vijf eindgebruikers.
- Week 4: eval, monitoring en launch. Groei de eval-suite naar 100+ vragen. Voeg logging toe. Lanceer voor een eerste groep.
Plan een gratis intake-gesprek als je wilt dat we meekijken. Onze werkwijze en garanties staan in onze algemene voorwaarden. Voor de bredere context van wat wij bouwen, zie custom platforms en AI assistent.
