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

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.

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:

# 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.

# 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 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), um gerankte Ergebnisse beider Retriever zusammenzuführen:

# 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 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.

Agentic RAG: Über Single-Shot-Retrieval hinaus

Naives RAG ruft einmal ab und generiert. Agentic RAG 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

# 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 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.

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 und DeepEval 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