RAG en LLMs in 2026: Retrieval-Augmented Generation voor Data Science Sollicitaties

Retrieval-Augmented Generation (RAG) heeft zich in 2026 gevestigd als een van de meest gevraagde vaardigheden in data science sollicitaties. Waar kandidaten vroeger vooral werden getest op klassieke machine learning-algoritmen en statistische concepten, verwachten recruiters tegenwoordig diepgaande kennis van hoe Large Language Models (LLM's) worden gecombineerd met externe kennisbronnen. Deze verschuiving weerspiegelt de realiteit van productieomgevingen, waar bedrijven RAG-systemen inzetten voor klantenservice, documentanalyse en interne kennisbeheer. Dit artikel behandelt de kernconcepten, implementatiepatronen en veelgestelde sollicitatievragen rondom RAG-architecturen.

De RAG-pipeline: van query tot antwoord

Een standaard RAG-pipeline bestaat uit twee fasen: een offline indexeringsfase en een online query-fase. Tijdens de indexering worden documenten opgesplitst in chunks, omgezet naar vectorrepresentaties (embeddings) en opgeslagen in een vectordatabase. Bij een gebruikersvraag worden de meest relevante chunks opgehaald en als context meegegeven aan het taalmodel.

De offline fase is cruciaal voor de prestaties van het systeem. Documenten worden eerst gesplitst met behulp van een text splitter die rekening houdt met natuurlijke grenzen zoals alinea's en zinnen. Vervolgens worden deze chunks geëmbedded met een model zoals OpenAI's text-embedding-3-large of open-source alternatieven zoals BGE of E5. De resulterende vectoren worden geïndexeerd voor snelle similarity search.

Tijdens de online fase wordt de gebruikersvraag eveneens geëmbedded. Via een approximate nearest neighbor (ANN) zoekopdracht worden de top-k meest gelijkaardige chunks opgehaald. Deze context wordt samengevoegd met de oorspronkelijke vraag in een prompt template, waarna het LLM een antwoord genereert.

# rag_pipeline.py
from langchain_openai import OpenAIEmbeddings, ChatOpenAI
from langchain_community.vectorstores import Chroma
from langchain.text_splitter import RecursiveCharacterTextSplitter
from langchain_core.prompts import ChatPromptTemplate
from langchain_core.runnables import RunnablePassthrough

# Offline: ingest documents into the vector store
def build_index(documents: list[str]) -> Chroma:
    splitter = RecursiveCharacterTextSplitter(
        chunk_size=512,       # tokens per chunk
        chunk_overlap=64,     # overlap preserves context at boundaries
        separators=["\n\n", "\n", ". ", " "]
    )
    chunks = splitter.create_documents(documents)
    embeddings = OpenAIEmbeddings(model="text-embedding-3-large")
    return Chroma.from_documents(chunks, embeddings)

# Online: retrieve + generate
def query(vectorstore: Chroma, question: str) -> str:
    retriever = vectorstore.as_retriever(
        search_type="mmr",    # Maximal Marginal Relevance for diversity
        search_kwargs={"k": 5, "fetch_k": 20}
    )
    prompt = ChatPromptTemplate.from_template(
        "Answer based on this context only:\n{context}\n\nQuestion: {question}"
    )
    chain = (
        {"context": retriever, "question": RunnablePassthrough()}
        | prompt
        | ChatOpenAI(model="gpt-4o", temperature=0)
    )
    return chain.invoke(question).content

Het gebruik van search_type="mmr" zorgt ervoor dat opgehaalde chunks zowel relevant als divers zijn, waardoor redundantie in het contextvenster wordt verminderd.

Chunkingstrategieën voor optimale retrieval

De manier waarop documenten worden opgesplitst heeft directe invloed op de kwaliteit van retrieval. Drie chunkingbenaderingen domineren productiesystemen in 2026:

Fixed-size chunking splitst tekst bij een vast aantal tokens (typisch 256-512 tokens) met overlap. Eenvoudig te implementeren, maar kan semantische eenheden doorsnijden.

Semantische chunking detecteert themawisselingen door de embedding-similariteit tussen opeenvolgende zinnen te meten. Wanneer de similariteit onder een drempelwaarde zakt, begint een nieuwe chunk. Elke chunk draagt een samenhangend idee in plaats van een willekeurig stuk tekst.

Late chunking past het transformer-model eerst toe op het volledige document, produceert contextuele token-embeddings en splitst vervolgens in chunks. Dit behoudt langafstandsafhankelijkheden die traditionele chunking vernietigt.

# semantic_chunking.py
import numpy as np
from sentence_transformers import SentenceTransformer

def semantic_chunk(text: str, threshold: float = 0.3) -> list[str]:
    """Split text where semantic similarity drops below threshold."""
    model = SentenceTransformer("all-MiniLM-L6-v2")
    sentences = text.split(". ")
    embeddings = model.encode(sentences)

    chunks, current_chunk = [], [sentences[0]]

    for i in range(1, len(sentences)):
        # Cosine similarity between consecutive sentences
        sim = np.dot(embeddings[i-1], embeddings[i]) / (
            np.linalg.norm(embeddings[i-1]) * np.linalg.norm(embeddings[i])
        )
        if sim < threshold:       # topic shift detected
            chunks.append(". ".join(current_chunk))
            current_chunk = [sentences[i]]
        else:
            current_chunk.append(sentences[i])

    chunks.append(". ".join(current_chunk))  # final chunk
    return chunks

Het kernpunt voor sollicitaties: chunkgrootte is een precision-recall trade-off. Kleine chunks (100 tokens) verbeteren de retrieval-precisie maar fragmenteren context. Grote chunks (1000 tokens) behouden context maar verdunnen de embedding-specificiteit. De meeste productiesystemen zitten op 256-512 tokens met 10-20% overlap.

Vectordatabases en embedding-modellen

De vectordatabase slaat embeddings op en ondersteunt snelle approximate nearest-neighbor (ANN) zoekopdrachten. De keuze van het juiste embedding-model en de vectordatabase beïnvloedt direct de retrieval-latency en nauwkeurigheid.

Embedding-modellen in 2026 zijn geconvergeerd rond enkele hoogpresterende opties. OpenAI's text-embedding-3-large (3072 dimensies) en open-source alternatieven zoals bge-m3 van BAAI of Cohere's embed-v4 bieden sterke meertalige retrieval.

| Database | Indexering | Beheerd | Sterk punt | |----------|------------|---------|------------| | Pinecone | Proprietair | Ja | Eenvoud, serverless schaling | | Weaviate | HNSW | Ja/Self | Hybride zoeken (vector + BM25) | | Milvus | IVF, HNSW | Ja/Self | Datasets op miljardenschaal | | Qdrant | HNSW | Ja/Self | Filtering + payload opslag | | pgvector | IVF, HNSW | Self | PostgreSQL-integratie |

Voor sollicitatiegesprekken is begrip van het HNSW-algoritme (Hierarchical Navigable Small World) essentieel: het bouwt een meerlagige graaf waarbij elk knooppunt verbonden is met zijn naaste buren, wat O(log n) zoekopdrachten mogelijk maakt tegen hogere geheugenkosten.

Hybride retrieval: dense en sparse combineren

Puur vectorgebaseerde retrieval kan falen bij exacte keyword-matches en zeldzame termen. Pure lexicale zoekopdrachten (BM25) missen semantische similariteit. Hybride retrieval combineert beide, en in 2026 is dit de standaard voor productie-RAG-systemen.

Het standaardpatroon gebruikt Reciprocal Rank Fusion (RRF) om gerangschikte resultaten van beide retrievers samen te voegen:

# hybrid_retrieval.py
from rank_bm25 import BM25Okapi
import numpy as np

def reciprocal_rank_fusion(
    dense_results: list[str],
    sparse_results: list[str],
    k: int = 60
) -> list[str]:
    """Merge dense (vector) and sparse (BM25) results using RRF."""
    scores: dict[str, float] = {}

    for rank, doc_id in enumerate(dense_results):
        scores[doc_id] = scores.get(doc_id, 0) + 1 / (k + rank + 1)

    for rank, doc_id in enumerate(sparse_results):
        scores[doc_id] = scores.get(doc_id, 0) + 1 / (k + rank + 1)

    # Sort by combined RRF score, highest first
    return sorted(scores.keys(), key=lambda d: scores[d], reverse=True)

Hybride retrieval lost het "vocabulary mismatch" probleem op waarbij een gebruiker vraagt naar "het opzeggen van een abonnement" maar het relevante document de term "beëindigingsbeleid van de account" gebruikt. BM25 vangt de exacte termoverlap op, terwijl vectorzoekopdrachten de semantische relatie vastleggen.

Reranking: het tweede-fase filter

Retrieval levert kandidaten. Reranking sorteert ze op werkelijke relevantie. Cross-encoder rerankers zoals Cohere Rerank of bge-reranker-v2.5-gemma2-lightweight scoren elk query-documentpaar gezamenlijk, wat veel nauwkeurigere relevantiescores oplevert dan bi-encoder similariteit.

De tweefasige retrieval-pipeline — brede eerste-fase recall (top 50-100 kandidaten via vector + BM25), daarna precies reranking (top 5-10 voor de prompt) — is standaard in productiesystemen.

Agentic RAG: zelfcorrigerende systemen

Naïeve RAG haalt eenmaal op en genereert. Agentic RAG behandelt het LLM als een redenerende agent die beslist wanneer op te halen, wat op te halen, en of de opgehaalde context voldoende is.

In 2026 is agentic RAG het dominante patroon voor complexe queries die meerstapsredenering vereisen. De agent kan:

• Zelfbeoordeling: Evalueren of opgehaalde documenten de vraag beantwoorden
• Herschrijven: De zoekopdracht herformuleren als initiële resultaten onvoldoende zijn
• Routeren: Kiezen tussen verschillende kennisbronnen (vector DB, SQL-database, API)
• Verifiëren: Feiten kruislings controleren over meerdere opgehaalde passages

# agentic_rag.py
from langgraph.graph import StateGraph, END
from typing import TypedDict

class RAGState(TypedDict):
    question: str
    documents: list[str]
    generation: str
    retries: int

def retrieve(state: RAGState) -> RAGState:
    """Retrieve documents from vector store."""
    docs = vectorstore.similarity_search(state["question"], k=5)
    return {"documents": [d.page_content for d in docs]}

def grade_documents(state: RAGState) -> str:
    """Decide if documents are relevant enough to answer."""
    prompt = f"Are these documents relevant to: {state['question']}?\n"
    prompt += "\n".join(state["documents"])
    relevance = llm.invoke(prompt)  # returns 'relevant' or 'not_relevant'
    return "generate" if "relevant" in relevance.content else "rewrite"

def rewrite_query(state: RAGState) -> RAGState:
    """Reformulate the query for better retrieval."""
    new_query = llm.invoke(
        f"Rewrite this query for better search results: {state['question']}"
    )
    return {"question": new_query.content, "retries": state["retries"] + 1}

# Build the agent graph
workflow = StateGraph(RAGState)
workflow.add_node("retrieve", retrieve)
workflow.add_node("grade", grade_documents)      # conditional routing
workflow.add_node("rewrite", rewrite_query)
workflow.add_node("generate", generate_answer)

workflow.set_entry_point("retrieve")
workflow.add_edge("retrieve", "grade")
workflow.add_conditional_edges("grade", grade_documents,
    {"generate": "generate", "rewrite": "rewrite"})
workflow.add_edge("rewrite", "retrieve")          # retry loop
workflow.add_edge("generate", END)

Dit patroon — ophalen, beoordelen, eventueel herschrijven en opnieuw proberen — staat bekend als Corrective RAG (CRAG). Het LangGraph-framework modelleert de workflow als een gerichte cyclische graaf met conditionele vertakking, waardoor het eenvoudig is om verificatiestappen of human-in-the-loop checkpoints toe te voegen.

Graph RAG: gestructureerde kennisretrieval

Graph RAG extraheert entiteiten en relaties uit documenten naar een kennisgraaf, en bevraagt vervolgens zowel de graaf als de vectorstore. Deze architectuur vermindert hallucinaties bij feitelijke queries door antwoorden te verankeren in expliciete entiteitsrelaties in plaats van ongestructureerde tekstsimilariteit.

Graph RAG blinkt uit bij multi-hop redenervragen zoals "Welk team leidt het project dat het framework gebruikt dat in document X wordt genoemd?" — queries die het verbinden van feiten over meerdere documenten vereisen. Pure vectorzoekopdrachten falen hier omdat geen enkele chunk het volledige antwoord bevat.

RAG-evaluatiemetrieken

RAG-evaluatie wordt opgesplitst in retrieval-metrieken en generatiemetrieken. Beide moeten onafhankelijk worden gemeten om storingen te diagnosticeren.

Retrieval-metrieken:

• Recall@k: Verschenen de relevante documenten in de top-k resultaten?
• MRR (Mean Reciprocal Rank): Hoe hoog is het eerste relevante resultaat gerankt?
• NDCG: Komt de rangschikking overeen met de ideale relevantievolgorde?

Generatiemetrieken:

• Faithfulness: Gebruikt het antwoord alleen informatie uit de opgehaalde context? (Meet hallucinaties)
• Answer Relevance: Beantwoordt het antwoord de oorspronkelijke vraag?
• Context Precision: Worden de opgehaalde chunks daadwerkelijk gebruikt in het antwoord?

Frameworks zoals Ragas en DeepEval automatiseren deze evaluaties met LLM-as-judge patronen.

Failure modes in productie

RAG-systemen falen op voorspelbare manieren. Kennis van deze patronen is essentieel voor zowel sollicitaties als real-world deployment.

Context window vervuiling treedt op wanneer te veel opgehaalde chunks het relevante signaal verdunnen. Het LLM ontvangt 10 chunks maar slechts 2 bevatten nuttige informatie. De oplossing: gebruik een reranker om te filteren en verlaag de top-k van de retriever.

Chunking-artefacten ontstaan wanneer fixed-size splitting zinnen, tabellen of codeblokken midden in een element doorbreekt. Semantische chunking of document-aware splitting lost dit op.

Embedding drift ontstaat wanneer het embedding-model wordt bijgewerkt maar de vectorstore nog embeddings van het oude model bevat. Oplossing: het volledige corpus opnieuw embedden na elke modelwijziging.

Verouderde indexen leveren achterhaalde informatie omdat de ingestie-pipeline achterloopt op documentupdates.

Conclusie

• RAG combineert retrieval (vectorzoekopdrachten over een kennisbasis) met LLM-generatie om onderbouwde, feitelijke antwoorden te produceren zonder het model opnieuw te trainen
• De chunkingstrategie heeft de grootste impact op retrieval-kwaliteit — semantische chunking en late chunking presteren beter dan fixed-size splitting in de meeste gevallen
• Hybride retrieval (dense vectoren + sparse BM25) met Reciprocal Rank Fusion is de productiestandaard, die het vocabulary mismatch probleem oplost
• Cross-encoder rerankers voegen een precisielaag toe na brede retrieval, waarbij slechts een kleine kandidatenset wordt verwerkt
• Agentic RAG (ophalen, beoordelen, herschrijven, opnieuw proberen) en Graph RAG (entiteitsrelatie-extractie) vertegenwoordigen de twee belangrijkste architecturale vooruitgangen in 2026
• Evaluatie moet retrieval-metrieken (Recall@k, MRR) scheiden van generatiemetrieken (Faithfulness, Answer Relevance) om te diagnosticeren waar de pipeline faalt
• De meest voorkomende productiestoringen — contextvervuiling, chunking-artefacten, embedding drift, verouderde indexen — hebben allemaal eenvoudige oplossingen zodra ze zijn geïdentificeerd