So bauen Sie 2026 eine RAG-Pipeline Schritt für Schritt auf

Retrieval-augmented generation (RAG) ist bereits vor Jahren keine reine Forschungskuriosität mehr gewesen. Im Jahr 2026 ist es die Standardmethode, ein LLM mit Ihren eigenen Dokumenten zu verbinden – ohne teures Feintuning eines Modells zu bezahlen oder das Risiko einzugehen, dass das Modell selbstbewusst falsche Antworten erfindet. Das zugrundeliegende Muster ist einfach zu beschreiben, aber bei der Implementierung voller Fallstricke: Finden Sie den richtigen Textausschnitt, übergeben Sie ihn dem Modell und lassen Sie das Modell die Antwort generieren.

Dies ist eine Bauanleitung – kein Übersichtsartikel. Am Ende dieses Leitfadens wissen Sie genau, welche Komponenten eine funktionierende RAG-Pipeline 2026 benötigt, welche konkreten Tools und Modellversionen sich dafür eignen und erhalten einen minimalen Code-Entwurf, den Sie entweder lokal oder über eine API ausführen können. Wir haben jede Versionsnummer, jeden Preis und jedes Benchmark-Ergebnis unten anhand aktueller Quellen überprüft – denn der schlimmste RAG-Fehler ist derjenige, den Sie aus einem Blogbeitrag kopieren, der für die Bibliotheken des Vorjahres geschrieben wurde.

So funktioniert eine RAG-Pipeline tatsächlich

Ein RAG-System besteht aus zwei Phasen. Indizierung erfolgt einmalig (oder immer dann, wenn sich Ihre Dokumente ändern): Sie teilen Quelldateien in Chunks auf, wandeln jeden Chunk mithilfe eines Embedding-Modells in einen Vektor um und speichern diese Vektoren in einer Datenbank. Abfrage erfolgt bei jeder Anfrage: Sie wandeln die Nutzerfrage in einen Vektor um, finden die ähnlichsten Chunks, bewerten sie optional neu (reranken), fügen die besten davon in eine Eingabeaufforderung (Prompt) ein und rufen ein LLM auf.

Das ist die gesamte Idee. Die technische Umsetzung liegt in den Details – etwa Chunk-Größe, Wahl des Embedding-Modells, Anzahl der abgerufenen Ergebnisse, Entscheidung für oder gegen ein Reranking sowie die Frage, wie Sie messen, ob Ihre Pipeline überhaupt funktioniert. Falls Sie zunächst das konzeptionelle Fundament verstehen möchten, bevor Sie mit dem Aufbau beginnen, bietet unser RAG-Erklärer die theoretischen Grundlagen; dieser Artikel konzentriert sich auf die praktische Umsetzung. Und falls Sie noch zwischen RAG und einer individuellen Modellanpassung (Fine-tuning) entscheiden müssen, ist der Vergleich zwischen Fine-tuning und RAG der richtige Ausgangspunkt – denn für die meisten Teams, die private, sich ständig ändernde Daten einem LLM zur Verfügung stellen, ist RAG die kostengünstigere und wartbarere Lösung.

Schritt 1: Teilen Sie Ihre Dokumente in Chunks auf

Embedding-Modelle weisen eine Kontextbegrenzung auf und – noch wichtiger – verlieren bei langen Textpassagen an Präzision. Daher teilen Sie Dokumente in Chunks auf. Der 2026 etablierte Konsens, gestützt durch Benchmarks statt bloßer Intuition, ist wenig spektakulär: Verwenden Sie einen rekursiven Zeichensplitter mit einer Zielgröße von etwa 512 Tokens und einer Überlappung von 10–20 % (50–100 Token).

Eine Bewertung vom Februar 2026 anhand von 50 realen Dokumenten ergab, dass die naive rekursive Aufteilung bei 512 Token eine Abrufgenauigkeit von 69 % erreichte, während die semantische Chunking-Methode – die versucht, an Bedeutungsgrenzen zu teilen – lediglich 54 % erzielte. Der Grund ist banal: Semantisches Chunking erzeugte durchschnittlich nur 43 Token lange Fragmente, was zu wenig Kontext für das Modell bietet, um präzise Antworten zu generieren. Eine separate Studie aus Januar 2026 mit SPLADE-Abruf stellte zudem fest, dass Überlappung zwar die Indexierungskosten erhöhte, aber auf dem verwendeten Datensatz keinerlei messbaren Nutzen brachte. Die ehrliche Erkenntnis lautet daher: Beginnen Sie mit festgrößenbasierten rekursiven Chunks und greifen Sie erst dann auf semantisches oder seitenbasiertes Chunking zurück, wenn Ihre Evaluationsmetriken eindeutig belegen, dass dies für Ihre spezifischen Dokumente erforderlich ist.

Schritt 2: Wählen Sie ein Embedding-Modell

Dies ist die folgenreichste Entscheidung in der gesamten Pipeline – und der Unterschied zwischen den Optionen ist tatsächlich spürbar. Im Folgenden finden Sie die im Juni 2026 relevanten Alternativen mit verifizierten Kennzahlen.

Für einen Prototypen beginnen Sie lokal mit nomic-embed-text — es ist schnell, kostenlos, läuft problemlos auf einem Laptop mit 16 GB RAM und schlägt laut Berichten OpenAIs älteres Modell text-embedding-ada-002Umso mehr: Für Produktionsumgebungen hat der Open-Source-Bereich wirklich aufgeholt: BGE-M3 ist das MIT-lizenzierte Arbeitstier, auf das die meisten selbstgehosteten Stacks standardmäßig setzen; Voyage-3.5 und Gemini Embedding führen hingegen bei den Managed-API-Benchmarks. Die einzige entscheidende Regel lautet: Mit welchem Modell Sie Ihre Dokumente einbetten, mit demselben Modell müssen Sie auch Ihre Abfragen einbetten. Das Mischen verschiedener Modelle zerstört den Abruf stillschweigend.

Schritt 3: Speichern Sie die Vektoren in einer Vektordatenbank

Sobald Sie die Embeddings vorliegen haben, benötigen sie einen Speicherort, der schnelle nearest-neighbor-Suche unterstützt. Im Jahr 2026 stehen Ihnen drei sinnvolle Ebenen zur Verfügung.

Eine detailliertere Aufschlüsselung finden Sie in unserem Leitfaden zu Vektordatenbanken, doch für die meisten Teams reduziert sich die Entscheidung auf folgende Faustregeln: Bereits PostgreSQL im Einsatz → pgvector; starke Filteranforderungen oder Milliarden von Vektoren nötig → Qdrant oder Milvus; reine Experimente → Chroma.

Schritt 4: Abrufen und Neubewerten (Reranking)

Der eigentliche Abruf erfolgt in einem einzigen Schritt: Das Abfrage-Embedding wird erzeugt, und die Datenbank liefert die k nächsten Nachbar-Chunks (typischerweise k = 20–50). Doch reine Vektorähnlichkeit ist ein grobes Instrument. Ein Reranker – ein Cross-Encoder, der jedes Abfrage-Dokument-Paar individuell bewertet – sortiert diese Kandidaten neu und hebt die tatsächlich relevanten Ergebnisse hervor, bevor sie das LLM erreichen.

Standardvorgehen: Abruf der Top-50 mittels Bi-Encoder, anschließender Rerank, Behalten der Top-5 bis Top-10. Cohere Rerank 3.5 kostet 0,002 USD pro Suchvorgang (2 USD pro 1.000 Anfragen) und verursacht typischerweise eine zusätzliche Latenz von rund 100–300 ms. Falls Sie über eine GPU verfügen und keine laufenden Kosten pro Abfrage wünschen, bietet der Open-Source-Reranker BGE-reranker-v2-m3 eine Laufzeit von ca. 50–100 ms und unterstützt mehrsprachige Inhalte. Reranking gehört zu den wirkungsvollsten und zugleich einfachsten Verbesserungen einer Pipeline – die meisten Systeme, die „Müll abrufen“, fehlt genau dieser Schritt.

Schritt 5: Anreichern der Eingabeaufforderung (Prompt) und Generieren

Nun stellen Sie den Prompt zusammen: eine kurze Systemanweisung, die das Modell auffordert, ausschließlich auf Basis des bereitgestellten Kontexts zu antworten, gefolgt von den rerankten Chunks und der Nutzerfrage. Danach rufen Sie Ihr LLM auf.

Für das Generierungsmodell können Sie entweder lokal oder über eine API arbeiten. Lokal über Ollamaist der 2026er Sweet Spot ein Modell der 8B-Klasse – etwa Qwen3 8B oder Llama 3.1 8B in Q4_K_M-Quantisierung –, das in 8–12 GB VRAM Platz findet und auf einer modernen GPU über 40 Token/Sekunde verarbeitet. Qwen3 14B (~8–9 GB bei Q4) stellt einen deutlichen Leistungssprung dar und bietet ein 128K-Kontextfenster, um noch mehr abgerufene Texte einzufügen. Für gehostete Lösungen mit höherem Leistungspotenzial eignen sich Frontier-API-Modelle gut; unser Claude-API-Chatbot-Tutorial führt diesen Weg Schritt für Schritt durch. Eine nützliche Erinnerung von Praktikern: Bei RAG zählt meist die Abrufqualität mehr als die Modellgröße – saubere Chunks plus ein gutes Embedding-Modell plus ein kleines LLM übertrifft ein riesiges Modell, das mit schlechtem Kontext gefüttert wird.

Schritt 6: Minimaler Code-Entwurf

Im Folgenden sehen Sie eine vollständige lokale Pipeline mit LangChain 1.x, Chroma und Ollama. Sie indexiert ein Dokument und beantwortet eine Frage – ohne API-Schlüssel.

# pip install langchain langchain-community langchain-chroma langchain-ollama
from langchain_community.document_loaders import TextLoader
from langchain_text_splitters import RecursiveCharacterTextSplitter
from langchain_ollama import OllamaEmbeddings, ChatOllama
from langchain_chroma import Chroma

# 1. Laden + Chunking (~512 Token, ~15 % Überlappung; Größenangaben in Zeichen)
docs = TextLoader("handbook.txt").load()
chunks = RecursiveCharacterTextSplitter(
    chunk_size=2000, chunk_overlap=300
).split_documents(docs)

# 2. Einbetten + 3. Speichern
embeddings = OllamaEmbeddings(model="nomic-embed-text")
store = Chroma.from_documents(chunks, embeddings)

# 4. Abrufen (Top 4)
retriever = store.as_retriever(search_kwargs={"k": 4})

# 5. Anreichern + Generieren
llm = ChatOllama(model="qwen3:8b")
question = "Wie lange beträgt die Rückgabefrist?"
context = "\n\n".join(d.page_content for d in retriever.invoke(question))
prompt = (f"Antworten Sie ausschließlich anhand des Kontexts. Ist die Information nicht vorhanden, geben Sie dies an.\n\n"\
          f"Kontext:\n{context}\n\nFrage: {question}")
print(llm.invoke(prompt).content)

Damit ist die gesamte Pipeline abgeschlossen. Um Reranking einzufügen, integrieren Sie einfach einen ContextualCompressionRetriever mit einem Cross-Encoder zwischen den Schritten 4 und 5. Mit LlamaIndex 0.14.x erfordert derselbe Ablauf typischerweise weniger Code dank seiner speziell für Retrieval entwickelten Abstraktionen – es ist die bessere Wahl für retrieval-lastige Anwendungen, während LangChains LangGraph-Laufzeit besonders dann überzeugt, wenn Sie zustandsbehaftete, mehrstufige Agenten benötigen. (Die Wahl einer Orchestrierungsschicht ist ein Thema für sich; siehe unseren Vergleich von KI-Agent-Frameworks.)

Schritt 7: Evaluieren – überspringen Sie diesen Schritt nicht

Der Unterschied zwischen einer Demo und einem Produkt ist die Messung. Das Standardwerkzeug hierfür ist RAGAS, das mit einem LLM als „Richter“ die Treue („Hat die Antwort sich an den Kontext gehalten?“), die Kontextpräzision und den Kontextrecall bewertet. Erstellen Sie einen kleinen Satz von 20–50 Frage-Antwort-Paaren aus Ihren echten Dokumenten und führen Sie RAGAS bei jeder Änderung aus.

So stellen Sie auch sicher, dass alle früheren Entscheidungen ehrlich getroffen werden. Sollten Sie auf semantisches Chunking umsteigen? Einen Reranker hinzufügen? Den Parameter k von 4 auf 8 erhöhen? Raten Sie nicht – ändern Sie eine Variable, führen Sie RAGAS erneut aus und behalten Sie die Änderung nur dann bei, wenn sich die Kennzahlen verbessern. Ohne diese Schleife optimieren Sie im Blindflug.

Häufig gestellte Fragen (FAQ)

Wie hoch sind die Kosten für den Betrieb einer RAG-Pipeline?

Nahezu kostenlos für Prototypen. Mit lokalen Ollama-Embeddings, Chroma und einem lokales LLM, entstehen Ihnen lediglich Stromkosten. Im großen Maßstab fallen vor allem die Kosten für die Vektordatenbank an (eine selbstgehostete Qdrant- oder pgvector-Instanz auf Ihrer eigenen VM ist deutlich günstiger als verwaltete Dienste, die bei 100 Millionen Vektoren monatlich über 5.000 US-Dollar kosten können) sowie – falls Sie APIs nutzen – für Embeddings (OpenAI text-embedding-3-large kostet 0,13 US-Dollar pro Million Tokens) und Generierungsaufrufe.

Brauche ich eine Vektordatenbank oder reicht eine herkömmliche Datenbank aus?

Sie benötigen zwar Vektor-Suche, aber nicht unbedingt ein dediziertes Produkt. pgvector fügt diese Funktionalität zu PostgreSQL hinzu und bewältigt 1 Million Vektoren mit niedriger p95-Latenz (ein- bis zweistellige Millisekunden auf NVMe, etwas höher auf Cloud-SSDs); wenn Sie bereits PostgreSQL betreiben, können Sie daher völlig auf neue Infrastruktur verzichten. Greifen Sie erst dann zu einer dedizierten Datenbank wie Qdrant, wenn Sie umfangreiche Metadatenfilterung oder Milliarden von Vektoren benötigen.

Welche Chunk-Größe sollte ich verwenden?

Beginnen Sie mit etwa 512 Tokens und einer Überlappung von 10–20 % mithilfe eines rekursiven Splitters. Ein Benchmark aus dem Jahr 2026 ergab, dass dieser Ansatz die Abrufgenauigkeit gegenüber semantischem Chunking mit 69 % zu 54 % übertraf. Wechseln Sie erst dann zu anspruchsvolleren Chunking-Verfahren, wenn Ihre Evaluationsmetriken belegen, dass dies bei Ihren konkreten Dokumenten tatsächlich hilft.

Ist ein Reranker wirklich notwendig?

Nicht, um eine funktionierende Lösung zu erhalten – doch ist er eine der kostengünstigsten Qualitätsverbesserungen überhaupt. Rufen Sie zunächst einen breiten Satz ab (die Top-50-Ergebnisse), werten Sie diese mit Cohere Rerank 3.5 oder dem Open-Source-Modell BGE-reranker-v2-m3 neu ein und behalten Sie nur die besten 5–10 Ergebnisse. Die meisten Pipelines, die irrelevante Chunks zurückliefern, fehlt einfach dieser Schritt.

Kann ich RAG auch ohne LangChain oder LlamaIndex bauen?

Ja. Die Kernschleife – Embedding, Suche, Prompting, Generierung – umfasst etwa 40 Zeilen reinen Python-Codes, die direkt Ihr Embedding-Modell, den Client für die Vektordatenbank und das LLM aufrufen. Frameworks sparen Zeit bei Loadern, Rerankern und agentischer Orchestrierung, sind jedoch optional; ein Aufbau von Grund auf bietet Ihnen volle Kontrolle über jeden einzelnen Schritt.

Sollte ich für die Generierung ein lokales Modell oder eine API verwenden?

Ein lokales Modell (über Ollama mit einem 8B-Modell auf 8–12 GB VRAM) ist ideal für Datenschutz, Kostenkontrolle und Offline-Nutzung. Eine API bietet Ihnen eine höhere Qualitäts-Obergrenze und entbindet Sie vollständig von Betriebsaufwand. Viele Teams prototypisieren lokal, um kostengünstig iterieren zu können, und wählen dann je nach Einsatzszenario – basierend auf Datensensitivität und Budget – die passende Lösung für die jeweilige Produktionseinführung.

Wie halte ich den Index aktuell, wenn sich die Dokumente ändern?

Re-embedden und upserten Sie nur die geänderten Inhalte, statt den gesamten Index neu zu erstellen. Verfolgen Sie pro Quelldokument einen Inhalts-Hash oder ein Änderungsdatum und löschen Sie beim Update die alten Chunks dieses Dokuments, bevor Sie die neuen einfügen. Die meisten Vektordatenbanken unterstützen Upserts und Löschvorgänge anhand von Metadatenfiltern – so gestaltet sich die inkrementelle Aktualisierung unkompliziert.

Fazit

Eine RAG-Pipeline zu bauen, ist 2026 tatsächlich gut machbar: sechs Phasen, eine Handvoll ausgereifter Tools und rund 40 Codezeilen für einen funktionsfähigen Prototypen. Die Fallstricke liegen nicht in der Architektur – sondern in den Standardeinstellungen. Nutzen Sie langweilige 512-Token-Chunks, stellen Sie sicher, dass Ihr Query- und Dokument-Embedder identisch sind, integrieren Sie einen Reranker und optimieren Sie niemals ohne RAGAS in der Schleife. Beginnen Sie lokal und kostenlos mit nomic-embed-text, Chroma und einem 8B-Ollama-Modell; rüsten Sie einzelne Komponenten – wie pgvector, Qdrant, Voyage oder eine Spitzen-API – erst dann nach, wenn Ihre Evaluationszahlen – und nicht ein Blogeintrag – dies eindeutig nahelegen. Stimmen Sie die Retrieval-Komponente richtig ab, und schon ein kleines Modell wird Sie überraschend weit bringen.