# RAG und LLMs 2026: Retrieval-Augmented Generation im Data-Science-Interview

> RAG-Interviewleitfaden für Data Science 2026. Behandelt RAG-Pipelines, Vektordatenbanken, Chunking-Strategien, Embeddings, Agentic RAG und Graph RAG.

- Published: 2026-06-06
- Updated: 2026-06-06
- Author: SharpSkill
- Tags: data-science, rag, llm, interview
- Reading time: 12 min

---

Retrieval-Augmented Generation (RAG) hat sich als eine der wichtigsten Technologien für die Entwicklung von KI-Anwendungen etabliert. Im Jahr 2026 erwarten Unternehmen von Data-Science-Kandidaten nicht nur theoretisches Wissen über Large Language Models, sondern auch praktische Erfahrung mit RAG-Architekturen. Diese Systeme kombinieren die Stärken von Vektordatenbanken mit der Generierungsfähigkeit moderner Sprachmodelle und ermöglichen so präzise, faktenbasierte Antworten auf komplexe Fragen.

> **Was ist RAG in einem Satz?**
>
> RAG ist ein Architekturmuster, das relevante Dokumente aus einer Wissensbasis abruft und diese als Kontext an ein LLM übergibt, um halluzinationsfreie und aktuelle Antworten zu generieren.

## Die RAG-Pipeline: Architektur und Komponenten

Eine RAG-Pipeline besteht aus zwei Hauptphasen: der Offline-Indexierung und der Online-Abfrage. In der Indexierungsphase werden Dokumente in kleinere Chunks aufgeteilt, in Vektoren umgewandelt und in einer Vektordatenbank gespeichert. Bei der Abfrage wird die Nutzerfrage ebenfalls vektorisiert, ähnliche Dokumente werden abgerufen und zusammen mit der ursprünglichen Frage an das LLM übergeben.

Die folgende Implementierung zeigt eine vollständige RAG-Pipeline mit LangChain:

```python
# 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
```

Die Wahl von `temperature=0` gewährleistet deterministische Ausgaben, während Maximal Marginal Relevance (MMR) für Diversität in den abgerufenen Dokumenten sorgt und redundante Informationen vermeidet.

## Chunking-Strategien: Semantisch vs. Regelbasiert

Die Qualität eines RAG-Systems hängt maßgeblich von der Chunking-Strategie ab. Während regelbasierte Ansätze Dokumente nach festen Zeichenzahlen oder Trennzeichen aufteilen, berücksichtigt semantisches Chunking die inhaltliche Zusammengehörigkeit von Textabschnitten.

Drei Chunking-Ansätze dominieren Produktionssysteme im Jahr 2026:

**Fixed-Size Chunking** teilt Text bei einer festen Token-Anzahl (typischerweise 256-512 Token) mit Überlappung. Einfach zu implementieren, aber Sätze und Gedanken werden mitten im Text getrennt.

**Semantisches Chunking** erkennt Themenwechsel, indem die Embedding-Ähnlichkeit zwischen aufeinanderfolgenden Sätzen gemessen wird. Wenn die Ähnlichkeit unter einen Schwellenwert fällt, beginnt ein neuer Chunk.

**Late Chunking** wendet das Transformer-Modell zuerst auf das gesamte Dokument an, erzeugt kontextuelle Token-Embeddings und teilt dann in Chunks auf. Dadurch bleiben Langstrecken-Abhängigkeiten erhalten.

```python
# 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
```

Der zentrale Interview-Aspekt: Die Chunk-Größe ist ein Precision-Recall-Tradeoff. Kleine Chunks (100 Token) verbessern die Retrieval-Präzision, fragmentieren aber den Kontext. Große Chunks (1000 Token) bewahren den Kontext, verwässern aber die Embedding-Spezifität. Die meisten Produktionssysteme liegen bei 256-512 Token mit 10-20% Überlappung.

## Vektordatenbanken und Embedding-Modelle

Die Wahl der richtigen Vektordatenbank ist entscheidend für die Skalierbarkeit und Performance eines RAG-Systems. [Embedding-Modelle](https://huggingface.co/spaces/mteb/leaderboard) im Jahr 2026 haben sich um einige leistungsstarke Optionen konsolidiert. OpenAIs `text-embedding-3-large` (3072 Dimensionen) und Open-Source-Alternativen wie `bge-m3` von BAAI oder Coheres `embed-v4` bieten starke mehrsprachige Retrieval-Ergebnisse.

| Datenbank | Indexierung | Verwaltet | Stärke |
|-----------|-------------|-----------|--------|
| Pinecone | Proprietär | Ja | Einfachheit, Serverless-Skalierung |
| Weaviate | HNSW | Ja/Self | Hybridsuche (Vektor + BM25) |
| Milvus | IVF, HNSW | Ja/Self | Milliarden-Datensätze |
| Qdrant | HNSW | Ja/Self | Filterung + Payload-Speicher |
| pgvector | IVF, HNSW | Self | PostgreSQL-Integration |

Für Interview-Diskussionen ist das Verständnis des HNSW-Algorithmus (Hierarchical Navigable Small World) entscheidend: Er baut einen mehrschichtigen Graphen auf, in dem jeder Knoten mit seinen nächsten Nachbarn verbunden ist, und ermöglicht O(log n)-Suche auf Kosten eines höheren Speicherverbrauchs.

## Hybrid Retrieval: Dense und Sparse kombinieren

Reine Vektorsuche versagt bei exakten Keyword-Matches und seltenen Begriffen. Reine lexikalische Suche (BM25) verpasst semantische Ähnlichkeit. Hybrides Retrieval kombiniert beide Ansätze, und im Jahr 2026 ist dies der Standard für produktive RAG-Systeme.

Das Standardmuster verwendet [Reciprocal Rank Fusion (RRF)](https://plg.uwaterloo.ca/~gvcormac/cormacksigir09-rrf.pdf), um gerankte Ergebnisse beider Retriever zusammenzuführen:

```python
# 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)
```

Hybrides Retrieval löst das "Vocabulary Mismatch"-Problem, bei dem ein Nutzer nach "Kündigung eines Abonnements" fragt, aber das relevante Dokument den Begriff "Kontobeendigungsrichtlinie" verwendet. BM25 erfasst den exakten Begriffsüberlapp, während die Vektorsuche die semantische Beziehung erkennt.

## Reranking: Der zweistufige Filter

Retrieval liefert Kandidaten. Reranking sortiert sie nach tatsächlicher Relevanz. Cross-Encoder-Reranker wie [Cohere Rerank](https://cohere.com/rerank) oder `bge-reranker-v2.5-gemma2-lightweight` bewerten jedes Query-Dokument-Paar gemeinsam und liefern deutlich genauere Relevanzscores als die Bi-Encoder-Ähnlichkeit.

Die zweistufige Retrieval-Pipeline — breiter First-Stage-Recall (Top 50-100 Kandidaten via Vektor + BM25), dann präzises Reranking (Top 5-10 für den Prompt) — ist der Standard in Produktionssystemen.

> **Reranking-Interview-Erkenntnis**
>
> Cross-Encoder sind genauer als Bi-Encoder, da sie Query und Dokument gemeinsam durch alle Transformer-Schichten verarbeiten. Bi-Encoder betten sie unabhängig voneinander ein und verlieren dabei feinkörnige Interaktionssignale. Der Kompromiss ist die Geschwindigkeit: Cross-Encoder können nicht vorindiziert werden.

## Agentic RAG: Über Single-Shot-Retrieval hinaus

Naives RAG ruft einmal ab und generiert. [Agentic RAG](https://arxiv.org/abs/2501.09136) behandelt das LLM als Reasoning-Agenten, der entscheidet, wann abgerufen wird, was abgerufen wird und ob der abgerufene Kontext ausreichend ist.

Im Jahr 2026 ist Agentic RAG das dominierende Muster für komplexe Abfragen, die mehrstufiges Reasoning erfordern. Der Agent kann:

- **Selbstbewertung**: Evaluieren, ob abgerufene Dokumente die Frage beantworten
- **Neuformulierung**: Die Suchanfrage umformulieren, wenn die ersten Ergebnisse unzureichend sind
- **Routing**: Zwischen verschiedenen Wissensquellen wählen (Vektor-DB, SQL-Datenbank, API)
- **Verifizierung**: Fakten über mehrere abgerufene Passagen kreuzprüfen

```python
# 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)
```

Dieses Muster — Abrufen, Bewerten, optional Umformulieren und Wiederholen — ist als Corrective RAG (CRAG) bekannt. Das LangGraph-Framework modelliert den Workflow als gerichteten zyklischen Graphen mit bedingter Verzweigung.

## Graph RAG: Strukturierte Wissensabfrage

[Graph RAG](https://microsoft.github.io/graphrag/) extrahiert Entitäten und Beziehungen aus Dokumenten in einen Wissensgraphen und fragt dann sowohl den Graphen als auch den Vektorspeicher ab. Diese Architektur reduziert Halluzinationen bei faktischen Abfragen, indem sie Antworten in expliziten Entitätsbeziehungen verankert.

Graph RAG eignet sich besonders für Multi-Hop-Reasoning-Fragen wie "Welches Team leitet das Projekt, das das in Dokument X erwähnte Framework verwendet?" — Abfragen, die das Verknüpfen von Fakten über mehrere Dokumente hinweg erfordern.

> **Graph RAG Tradeoff**
>
> Graph RAG verbessert die faktische Genauigkeit erheblich (bis zu 40% weniger Halluzinationen bei entitätslastigen Abfragen), erfordert jedoch eine ausgereifte Entity-Extraction-Pipeline. Eine fehlerhafte Extraktion erzeugt einen fehlerhaften Graphen, der die Ergebnisse unter das Niveau von naivem RAG senken kann.

## RAG-Systeme evaluieren: Die richtigen Metriken

Die RAG-Evaluierung teilt sich in Retrieval-Metriken und Generierungs-Metriken. Beide müssen unabhängig gemessen werden, um Fehler zu diagnostizieren.

**Retrieval-Metriken:**
- **Recall@k**: Wurden die relevanten Dokumente in den Top-k-Ergebnissen gefunden?
- **MRR (Mean Reciprocal Rank)**: Wie hoch ist das erste relevante Ergebnis gerankt?
- **NDCG**: Entspricht das Ranking der idealen Relevanzreihenfolge?

**Generierungs-Metriken:**
- **Faithfulness**: Verwendet die Antwort nur Informationen aus dem abgerufenen Kontext? (Misst Halluzinationen)
- **Answer Relevance**: Beantwortet die Antwort die ursprüngliche Frage?
- **Context Precision**: Werden die abgerufenen Chunks tatsächlich in der Antwort verwendet?

Frameworks wie [Ragas](https://docs.ragas.io/) und [DeepEval](https://docs.confident-ai.com/) automatisieren diese Evaluierungen mit LLM-as-Judge-Mustern.

## Produktions-Fehlermodi und Debugging

RAG-Systeme versagen auf vorhersehbare Weise. Die Kenntnis dieser Muster ist sowohl für Interviews als auch für den realen Einsatz unerlässlich.

**Context-Window-Verschmutzung** tritt auf, wenn zu viele abgerufene Chunks das relevante Signal verwässern. Das LLM erhält 10 Chunks, aber nur 2 enthalten nützliche Informationen. Die Lösung: Reranker zum Filtern verwenden und den Top-k-Wert des Retrievers reduzieren.

**Chunking-Artefakte** entstehen, wenn Fixed-Size-Splitting Sätze, Tabellen oder Codeblöcke mitten im Element trennt. Semantisches Chunking oder dokumentbewusstes Splitting löst dieses Problem.

**Embedding-Drift** entsteht, wenn das Embedding-Modell aktualisiert wird, der Vektorspeicher aber noch Embeddings des alten Modells enthält. Lösung: Den gesamten Korpus nach jeder Modelländerung neu einbetten.

**Veraltete Indizes** liefern veraltete Informationen, weil die Ingestion-Pipeline hinter Dokumentaktualisierungen zurückbleibt.

## Zusammenfassung

- RAG kombiniert Retrieval (Vektorsuche über eine Wissensbasis) mit LLM-Generierung, um fundierte, faktische Antworten zu erzeugen, ohne das Modell neu zu trainieren
- Die Chunking-Strategie hat den größten Einfluss auf die Retrieval-Qualität — semantisches Chunking und Late Chunking übertreffen Fixed-Size-Splitting in den meisten Anwendungsfällen
- Hybrides Retrieval (Dense Vektoren + Sparse BM25) mit Reciprocal Rank Fusion ist der Produktionsstandard und löst das Vocabulary-Mismatch-Problem
- Cross-Encoder-Reranker fügen eine Präzisionsschicht nach dem breiten Retrieval hinzu und verarbeiten nur eine kleine Kandidatenmenge
- Agentic RAG (Abrufen, Bewerten, Umformulieren, Wiederholen) und Graph RAG (Entitäts-Beziehungs-Extraktion) stellen die beiden großen Architekturfortschritte im Jahr 2026 dar
- Die Evaluierung muss Retrieval-Metriken (Recall@k, MRR) von Generierungs-Metriken (Faithfulness, Answer Relevance) trennen, um Pipeline-Fehler zu diagnostizieren
- Die häufigsten Produktionsfehler — Context-Verschmutzung, Chunking-Artefakte, Embedding-Drift, veraltete Indizes — haben alle einfache Lösungen, sobald sie identifiziert sind

---

Source: SharpSkill (https://sharpskill.dev), tech interview preparation for your real stack.
HTML version of this page: https://sharpskill.dev/de/blog/data-science/rag-retrieval-augmented-generation-llm-data-science-interview-2026