RAG-implementatie laten maken: retrieval-augmented generation voor enterprise-AI

Wanneer RAG, wanneer fine-tuning, wanneer alleen prompt engineering

De drie methoden om een LLM domein-kennis te geven hebben verschillende kostenstructuren, latency-profielen en accountability-eigenschappen. De juiste keuze hangt af van datavers-frequentie, het volume aan grond-waarheid en de eisen rond bronvermelding. RAG is in negen van de tien enterprise-cases het juiste startpunt.

Prompt engineering werkt zolang uw kennis in een paar duizend tokens past en zelden verandert. Zodra uw kennisbron groter is dan het context-window of dagelijks muteert (productcatalogus, ticket-historie, juridische updates), valt prompt engineering om. Fine-tuning is bedoeld om gedrag of stijl te leren — niet om feiten in te bakken. Een fine-tuned model dat een verzonnen feit produceert is even moeilijk te corrigeren als een fout in een gewicht-matrix; u kunt het niet selectief vergeten.

RAG ontkoppelt kennis van model. De LLM blijft een algemeen redeneer-apparaat, en de waarheid leeft in een extern document-store met versie-historie, audit-trail en autorisatie. Een document bijwerken is een upsert op de vector-DB, geen retraining-run van twaalf uur. Een document intrekken (GDPR, geheimhoudingsplicht, verlopen contract) is een delete; bij fine-tuning is dat in feite onmogelijk. Voor enterprise-toepassingen waar accountability, retracteerbaarheid en bronvermelding ertoe doen, is RAG de structureel juiste architectuur.

Chunking-strategie, embeddings en vector-database: drie keuzes die alles bepalen

De drie technische beslissingen die het meest direct invloed hebben op retrieval-kwaliteit zijn: hoe u documenten in stukken hakt, welk embedding-model u kiest, en op welke vector-store u indexeert. Standaardadvies bestaat niet — de juiste keuze hangt af van documentlengte, query-stijl, taal en latency-budget.

Chunking. Fixed-size chunking (bijvoorbeeld 512 tokens met 64 overlap) is robuust en goedkoop, maar breekt vaak midden in een argument af. Semantic chunking gebruikt een sentence-encoder om logische breekpunten te vinden — de chunk-grens valt waar het onderwerp daadwerkelijk verandert. Voor lange juridische of technische documenten werkt hiërarchische chunking goed: kleine chunks voor retrieval-precisie, gekoppeld aan grotere parent-chunks die als context bij synthesis worden meegegeven. De recall-score op uw eigen golden set is de enige betrouwbare manier om te bepalen welke strategie wint.

Embeddings. OpenAI text-embedding-3-large is een sterke default voor Engels en redelijk Nederlands. Voyage-3 en voyage-multilingual presteren consistent hoog op multilingual benchmarks. Cohere embed-v3 ondersteunt input-type-conditioning (search_document vs. search_query) wat asymmetric retrieval ten goede komt. Voor self-hosted scenario's werken BGE-large, e5-mistral en gte-large goed; ze zijn fine-tunebaar op uw eigen domein als out-of-the-box accuracy tekortschiet. Belangrijk: een embedding-model wisselen betekent uw hele index herbouwen, dus benchmark vooraf op uw eigen data.

Vector-database. Pinecone is managed, schaalt eenvoudig en heeft sterke hybrid-search; geen self-hosting mogelijk. Weaviate biedt rijke filtering, GraphQL-API en self-host of cloud. Qdrant is hoge-prestatie, Rust-based, met sterke filtering en goede self-host story. pgvector koppelt vector-search aan een bestaande PostgreSQL — handig als uw metadata toch al relationeel is en u één database wilt beheren. Milvus is enterprise-scale (miljarden vectoren), maar zwaarder in operationele complexiteit. De keuze hangt af van schaal, hosting-vereisten (EU-only?), filter-complexiteit en of u losse infrastructuur of een geïntegreerde stack wilt.

Evaluatie: RAGAS, golden sets en wat het écht betekent dat uw RAG werkt

Een RAG-systeem dat bij de demo werkt zegt niets over een RAG-systeem dat in productie werkt. U heeft kwantitatieve evaluatie nodig — anders is iedere wijziging een gok en weet u niet of een nieuwe embedding-versie een verbetering of regressie is.

Wij leveren elke RAG-implementatie met een eval-harness die u zelf kunt draaien. Een nieuwe LLM-versie, een ander embedding-model, een aangepaste chunking-strategie — u vergelijkt voor en na, en u beslist op cijfers in plaats van onderbuik. Frameworks die we standaard inzetten: RAGAS, LlamaIndex Eval, custom pytest-harnesses voor specifieke claim-types, en Langfuse voor productie-tracing.

Concrete RAG-toepassingen die wij bouwen

RAG is niet één product — het is een patroon dat in vrijwel elk kennis-intensief proces past. Een paar terugkerende toepassingen waar de ROI direct meetbaar is.