Retrieval-Augmented Generation (RAG) von Grund auf selbst bauen: Konzept und Praxis

Artikel-Übersicht

In diesem Leitfaden baust du gemeinsam mit mir ein Verständnis dafür auf, was Retrieval-Augmented Generation – kurz RAG – wirklich ist und wie du es von Grund auf selbst implementierst. Wir starten mit der Kernfrage, warum RAG überhaupt existiert: Sprachmodelle halluzinieren, ihr Wissen hat einen Stichtag und sie kennen deine internen Dokumente nicht. RAG löst genau diese drei Probleme, indem es dem Modell vor der Antwort die passenden Wissensbrocken in den Kontext legt. Danach gehen wir die komplette Architektur Schritt für Schritt durch: Dokumente laden, sinnvoll in Chunks zerlegen, in Embeddings (Vektoren) übersetzen, in einer Vektordatenbank speichern, bei einer Frage die relevantesten Chunks abrufen (Retrieval), diese optional mit einem Re-Ranker schärfen und schließlich zusammen mit der Frage an ein LLM zur Generierung geben. Im Praxisteil schreiben wir eine minimale, aber vollständig lauffähige Pipeline in Python mit Chroma als Vektordatenbank, OpenAI-Embeddings und Claude als Generator. Anschließend vertiefen wir die Themen, die in der Praxis über Erfolg und Misserfolg entscheiden: Chunk-Größe und Overlap, Hybrid-Suche aus semantischer und Stichwortsuche, Re-Ranking mit Cross-Encodern und die Evaluierung mit dem RAGAS-Framework. Zum Schluss bekommst du eine ehrliche Liste der häufigsten Fehler und einen kompakten Werkzeugkasten mit verifizierten Ressourcen – alles auf dem aktuellen Stand 2026.

Einleitung: Warum dein LLM ein Gedächtnis von außen braucht

Stell dir ein Large Language Model wie einen brillanten, aber etwas weltfremden Professor vor, der vor einigen Monaten das letzte Mal eine Zeitung gelesen hat und seitdem in einem fensterlosen Büro sitzt. Er kann eloquent über fast jedes Thema referieren, formuliert druckreife Sätze und zieht erstaunliche Verbindungen. Aber: Er weiß nicht, was gestern passiert ist. Er kennt deine Firmen-Wiki nicht. Und wenn er etwas nicht weiß, neigt er dazu, es selbstbewusst zu erfinden, statt zu schweigen.

Genau hier setzt Retrieval-Augmented Generation an. Die Idee ist im Kern verblüffend einfach: Statt das Modell aus dem Gedächtnis antworten zu lassen, reichen wir ihm vor der Antwort die relevanten Unterlagen an – so, als würden wir dem Professor genau die drei Aktenordner auf den Tisch legen, die er für die Frage gerade braucht. Das Modell muss dann nicht mehr raten, sondern darf aus konkretem, von dir kuratiertem Material schöpfen.

Der Name verrät bereits die zwei Phasen: Retrieval (das Abrufen passender Information) und Generation (das Erzeugen der Antwort). Das „Augmented" in der Mitte ist der Clou – wir erweitern die Generierung um abgerufenes Wissen. RAG ist damit kein einzelnes Produkt, sondern ein Architekturmuster, das sich seit 2023 zum De-facto-Standard für wissensintensive KI-Anwendungen entwickelt hat. Und das Beste: Du kannst es vollständig verstehen und selbst bauen, ohne ein eigenes Modell trainieren zu müssen.

Warum RAG? Drei Probleme, eine Lösung

Bevor wir Code schreiben, lohnt es sich, präzise zu benennen, welche Probleme RAG eigentlich löst. Denn nur dann triffst du später die richtigen Architekturentscheidungen.

Problem 1: Halluzinationen. Ein LLM erzeugt statistisch wahrscheinliche Wortfolgen. Wenn es eine Antwort nicht sicher weiß, produziert es trotzdem flüssigen Text – und der klingt oft genauso überzeugend wie eine korrekte Antwort. RAG reduziert das spürbar, weil das Modell seine Aussagen an den mitgelieferten Quellen festmachen kann. Mit einem guten Prompt („Antworte ausschließlich auf Basis des folgenden Kontexts") und sauberen Quellenangaben wird aus dem freien Fabulieren ein nachvollziehbares Zitieren.

Problem 2: Veraltetes Wissen. Jedes Modell hat einen Trainings-Stichtag. Ereignisse, Preise, Produktversionen oder Gesetzesänderungen danach kennt es nicht. RAG umgeht das elegant: Du aktualisierst einfach deine Wissensdatenbank, ohne das Modell anzufassen. Neuer Stand, neue Antworten – ganz ohne erneutes Training.

Problem 3: Fehlendes proprietäres Wissen. Das wertvollste Wissen deines Unternehmens steht in keinem öffentlichen Datensatz: interne Handbücher, Support-Tickets, Verträge, Produktspezifikationen. Ein Standardmodell hat davon nie etwas gesehen. RAG macht genau dieses private Wissen nutzbar – und zwar ohne dass deine sensiblen Daten ins Training fließen müssen.

Die naheliegende Alternative wäre Fine-Tuning, also das Nachtrainieren des Modells auf deinen Daten. Doch in der Praxis ist RAG für Faktenwissen fast immer die bessere Wahl: Es ist günstiger, schneller aktualisierbar, liefert nachvollziehbare Quellen und vermeidet, dass das Modell veraltete Fakten „auswendig lernt". Fine-Tuning glänzt dagegen, wenn es um Stil, Format oder ein bestimmtes Verhalten geht – nicht um Wissen, das sich ändert.

Die RAG-Architektur im Überblick

RAG zerfällt in zwei zeitlich getrennte Abläufe. Der erste passiert einmalig (oder regelmäßig im Hintergrund), der zweite bei jeder einzelnen Anfrage.

Die Indexierung (offline):

Dokumente laden ? in Chunks zerlegen ? Embeddings berechnen ? in Vektordatenbank speichern

Die Abfrage (online, pro Frage):

Frage ? Embedding der Frage ? Ähnlichkeitssuche ? (optional) Re-Ranking ? Kontext + Frage an LLM ? Antwort

Diese Trennung ist wichtig zu verstehen: Das aufwendige Aufbereiten und Vektorisieren deiner Dokumente erledigst du vorab. Zur Laufzeit muss nur noch die Frage vektorisiert, die Datenbank durchsucht und das LLM einmal aufgerufen werden – das ist schnell genug für interaktive Anwendungen.

Gehen wir die einzelnen Bausteine jetzt der Reihe nach durch.

Schritt 1 & 2: Dokumente laden und intelligent chunken

Am Anfang steht das Laden der Rohdaten. Das können PDFs, Word-Dokumente, Webseiten, Markdown-Dateien, Confluence-Seiten oder Datenbankeinträge sein. In der Praxis ist das oft der unterschätzte Teil: Schlecht extrahierter Text – zerstückelte Tabellen, verlorene Überschriften, kaputte Umlaute – ruiniert jede noch so gute Pipeline. Garbage in, garbage out gilt hier gnadenlos.

Der wirklich entscheidende Schritt ist jedoch das Chunking: das Zerlegen langer Dokumente in kleinere Häppchen. Warum überhaupt zerlegen? Aus zwei Gründen. Erstens haben Embedding-Modelle ein Eingabelimit, und ein 50-seitiges PDF in einen einzigen Vektor zu pressen würde alle Nuancen zu Brei vermischen. Zweitens willst du dem LLM später nur die wirklich relevanten Passagen geben, nicht das ganze Dokument – das spart Tokens, Geld und verbessert die Antwortqualität.

Die zentrale Stellschraube ist die Chunk-Größe im Zusammenspiel mit dem Overlap (Überlappung). Als Faustregeln auf Stand 2026 haben sich bewährt:

Anwendungsfall	Chunk-Größe	Overlap	Retrieval-Strategie
Chat/FAQ über allgemeine Dokumente	256–512 Tokens	10–15 %	Top-20 bis Top-30 abrufen, auf Top-5 re-ranken
Technische/juristische Korpora	800–1200 Tokens	10–15 %	Top-10 bis Top-20, auf Top-3 re-ranken
Langdokument-QA mit starkem Generator	1500–2048 Tokens	10–15 %	Wenige Chunks, langer Kontext

Der Overlap ist kein Detail, sondern verhindert ein typisches Problem: Wenn die Antwort genau an einer Chunk-Grenze liegt, wird sie ohne Überlappung in zwei Hälften zerschnitten und keiner der beiden Chunks enthält die vollständige Information. 10–20 % Überlappung fangen diese „Kontext-Klippen" ab. Bei einem 500-Token-Chunk wären das also 50–100 Tokens, die sich der nächste Chunk mit dem vorherigen teilt.

Beim Wie des Chunkings gibt es eine klare Empfehlung: Beginne strukturbasiert. Splitte entlang natürlicher Grenzen wie Überschriften, Absätzen oder – bei Code – Funktionsgrenzen. Das ist robust, schnell und bewahrt die Bedeutungseinheiten. Erst wenn du langen Fließtext ohne saubere Struktur hast, lohnt sich semantisches Chunking, bei dem ein Embedding-Modell die Themenwechsel erkennt und dort schneidet. In LangChain ist der RecursiveCharacterTextSplitter der pragmatische Standard, weil er hierarchisch zuerst an Absätzen, dann an Sätzen und zuletzt an Wörtern trennt.

Schritt 3: Embeddings – Text in Bedeutung übersetzen

Jetzt kommt das Herzstück. Ein Embedding ist ein Vektor – eine lange Liste von Zahlen –, der die Bedeutung eines Textstücks in einem hochdimensionalen Raum repräsentiert. Die Magie dabei: Texte mit ähnlicher Bedeutung landen in diesem Raum nah beieinander, auch wenn sie keine einzige Wortübereinstimmung haben. „Wie storniere ich meine Bestellung?" und „Auftrag rückgängig machen" liegen dicht zusammen, obwohl sie sprachlich verschieden sind. Genau diese semantische Nähe nutzen wir später für die Suche.

Bei der Wahl des Embedding-Modells hast du 2026 die Qual der Wahl. Die wichtigsten Optionen:

OpenAI text-embedding-3-small – der pragmatische Einstieg für die meisten Projekte. Mit rund 0,02 $ pro 1 Mio. Tokens extrem günstig und für 90 % der Fälle völlig ausreichend.
OpenAI text-embedding-3-large – stärker bei schwierigen Retrieval-Aufgaben, 3072 Dimensionen, ca. 0,13 $ pro 1 Mio. Tokens.
Cohere embed-v4 – top in unabhängigen Benchmarks (MTEB), 1024 Dimensionen, ca. 0,10 $ pro 1 Mio. Tokens, mit dem nützlichen Detail, dass es zwischen search_document und search_query unterscheidet und so Indexierung und Abfrage getrennt optimiert.
Voyage AI voyage-3-large – führend bei Code und technischer Dokumentation.
Open-Source-Modelle wie die bge- oder nomic-Familien – wenn du komplett lokal und datenschutzfreundlich arbeiten willst, ohne dass ein Byte das Haus verlässt.

Ein entscheidender, oft übersehener Punkt: Frage und Dokumente müssen mit demselben Modell eingebettet werden. Mischst du hier, vergleichst du Äpfel mit Birnen, und die Ähnlichkeitssuche liefert Müll.

Schritt 4: Die Vektordatenbank als Wissensspeicher

Die berechneten Embeddings müssen irgendwo hin – und zwar so, dass du in Millisekunden den nächsten Nachbarn zu einem Anfragevektor findest, selbst bei Millionen von Einträgen. Genau dafür gibt es Vektordatenbanken. Sie nutzen spezielle Index-Strukturen (meist Varianten von HNSW – Hierarchical Navigable Small World), um die teure Ähnlichkeitssuche näherungsweise, aber blitzschnell zu erledigen.

Die wichtigsten Vertreter 2026 im Überblick:

Datenbank	Charakter	Wann nehmen?
Chroma	Schlank, entwicklerfreundlich, läuft lokal	Prototypen und kleine Produktion – ideal zum Lernen
pgvector	Erweiterung für PostgreSQL	Wenn du ohnehin Postgres nutzt und alles in einem System willst
Qdrant	In Rust geschrieben, sehr schnell, starke Filter	Open-Source-Produktion mit Fokus auf Latenz
Weaviate	Native Hybrid-Suche, eingebaute Embedding-Module	Wenn du viel Komfort willst
Milvus	Auf Milliarden-Skala ausgelegt, hoher Durchsatz	Sehr große, verteilte Workloads
Pinecone	Voll gemanagt, null Betrieb	Wenn du dich um nichts kümmern willst und es Geld kosten darf

Für den Einstieg und diesen Artikel nehmen wir Chroma: Es ist quelloffen, läuft mit einer Zeile Code lokal und du musst nichts hosten. Wächst dein Projekt, ist der Umstieg auf pgvector oder Qdrant überschaubar, weil das Grundkonzept identisch bleibt. Eine tiefergehende Gegenüberstellung findest du übrigens in meinem separaten Artikel zum Vergleich der Vektordatenbanken.

Schritt 5 bis 7: Retrieval, Re-Ranking und Generierung

Jetzt sind wir im Online-Teil. Kommt eine Frage herein, passiert Folgendes:

Retrieval: Die Frage wird mit demselben Embedding-Modell vektorisiert. Die Vektordatenbank sucht die k ähnlichsten Chunks (z. B. die Top-20) per Cosinus-Ähnlichkeit.
Re-Ranking (optional, aber wirkungsvoll): Die schnelle Vektorsuche ist gut darin, viele plausible Kandidaten zu liefern (hoher Recall), aber nicht perfekt darin, die wirklich besten ganz nach oben zu sortieren (Precision). Ein Re-Ranker – meist ein Cross-Encoder – nimmt Frage und jeden Kandidaten gemeinsam unter die Lupe und vergibt einen präzisen Relevanz-Score. Aus den Top-20 werden so die echten Top-3 herausgefiltert. In Benchmarks bringt das auf NDCG@5 oft 0,10 bis 0,15 Punkte, in Domänen wie Recht und Medizin spürbar mehr.
Generierung: Die finalen Chunks werden zusammen mit der ursprünglichen Frage in einen Prompt gepackt und an das LLM geschickt. Das Modell formuliert die Antwort – jetzt auf Basis von Fakten, nicht aus dem Gedächtnis.

Beim Re-Ranking hast du 2026 zwei gute Wege: die gemanagte API von Cohere (aktuelle Linie Rerank 4.0, der Vorgänger Rerank 3.5 unterstützt über 100 Sprachen) oder ein lokales Open-Source-Modell wie bge-reranker-v2-m3, das in unabhängigen Tests fast gleichauf liegt. Wichtig zu wissen: Re-Ranking hilft, wenn der Recall hoch, die Precision aber niedrig ist. Holt deine Suche die richtigen Dokumente gar nicht erst ein, kann auch der beste Re-Ranker nichts mehr retten.

Praxis: Eine minimale RAG-Pipeline in Python

Genug Theorie – bauen wir es. Unser Stack: Chroma als Vektordatenbank, OpenAI für die Embeddings und Claude (über die Anthropic-API) für die Generierung. Das ist eine realistische, robuste Kombination für 2026.

Zuerst die Installation:

pip install chromadb openai anthropic

Setze deine API-Schlüssel als Umgebungsvariablen (OPENAI_API_KEY und ANTHROPIC_API_KEY) – niemals fest in den Code schreiben.

Schritt 1: Dokumente vorbereiten und chunken

Für das Beispiel nehmen wir ein paar Textbausteine. In der Realität würdest du hier PDFs oder Webseiten laden. Wir bauen einen einfachen Chunker mit Overlap selbst, damit du das Prinzip siehst:

def chunk_text(text: str, chunk_size: int = 500, overlap: int = 75) -> list[str]:
    """Zerlegt Text in überlappende Chunks (grob anhand von Wörtern)."""
    woerter = text.split()
    chunks = []
    schritt = chunk_size - overlap
    for start in range(0, len(woerter), schritt):
        chunk = " ".join(woerter[start:start + chunk_size])
        if chunk:
            chunks.append(chunk)
    return chunks

# Beispiel-Wissensbasis (in der Praxis aus Dateien geladen)
dokumente = [
    "Die Rückgabe von Produkten ist innerhalb von 30 Tagen nach Erhalt möglich. "
    "Die Ware muss unbenutzt und in der Originalverpackung sein.",
    "Unser Support ist von Montag bis Freitag zwischen 9 und 17 Uhr erreichbar. "
    "Am Wochenende antworten wir per E-Mail innerhalb von 24 Stunden.",
    "Versandkosten betragen 4,95 Euro. Ab einem Bestellwert von 50 Euro liefern wir kostenlos.",
]

# Hier sind die Dokumente kurz – bei langen Texten würdest du chunk_text() anwenden.
chunks = dokumente

Schritt 2: Embeddings berechnen und in Chroma speichern

import chromadb
from openai import OpenAI

openai_client = OpenAI()

def embed(texte: list[str]) -> list[list[float]]:
    """Berechnet Embeddings mit OpenAI text-embedding-3-small."""
    antwort = openai_client.embeddings.create(
        model="text-embedding-3-small",
        input=texte,
    )
    return [d.embedding for d in antwort.data]

# Chroma-Client (in-memory; für Persistenz: PersistentClient(path="./db"))
chroma_client = chromadb.Client()
collection = chroma_client.create_collection(name="wissensbasis")

collection.add(
    ids=[f"doc-{i}" for i in range(len(chunks))],
    documents=chunks,
    embeddings=embed(chunks),
)

Wir geben Chroma die Embeddings hier bewusst selbst mit, damit du den vollen Ablauf siehst. Chroma kann Embeddings auch automatisch berechnen, aber so behältst du die Kontrolle über das Modell.

Schritt 3: Retrieval – die passenden Chunks finden

def retrieve(frage: str, k: int = 3) -> list[str]:
    """Findet die k ähnlichsten Chunks zur Frage."""
    frage_embedding = embed([frage])[0]
    ergebnis = collection.query(
        query_embeddings=[frage_embedding],
        n_results=k,
    )
    return ergebnis["documents"][0]

Schritt 4: Generierung mit Claude und Kontext

Jetzt fügen wir alles zusammen. Der Prompt weist das Modell ausdrücklich an, nur den gelieferten Kontext zu nutzen – das ist der wichtigste Hebel gegen Halluzinationen:

import anthropic

claude = anthropic.Anthropic()

def beantworte(frage: str) -> str:
    kontext_chunks = retrieve(frage, k=3)
    kontext = "\n\n".join(f"[{i+1}] {c}" for i, c in enumerate(kontext_chunks))

    prompt = f"""Beantworte die Frage des Nutzers ausschließlich auf Basis des
folgenden Kontexts. Wenn der Kontext die Antwort nicht enthält, sage ehrlich,
dass du es auf Basis der vorliegenden Informationen nicht beantworten kannst.

Kontext:
{kontext}

Frage: {frage}"""

    antwort = claude.messages.create(
        model="claude-opus-4-8",
        max_tokens=1024,
        messages=[{"role": "user", "content": prompt}],
    )
    return antwort.content[0].text

print(beantworte("Wie lange habe ich Zeit, etwas zurückzugeben?"))
# ? "Du hast 30 Tage nach Erhalt Zeit, ein Produkt zurückzugeben. Die Ware
#    muss dabei unbenutzt und in der Originalverpackung sein. [1]"

Das war's – eine vollständige, lauffähige RAG-Pipeline in unter 60 Zeilen. Sie lädt Wissen, vektorisiert es, sucht relevante Stücke und lässt Claude eine fundierte Antwort formulieren. Als Modell habe ich claude-opus-4-8 gewählt; für Anwendungen mit hohem Volumen ist claude-sonnet-4-6 ein guter Kompromiss aus Qualität und Kosten, für sehr einfache Antworten reicht oft claude-haiku-4-5.

Ein Hinweis zur Praxis: Frameworks wie LangChain oder LlamaIndex nehmen dir viele dieser Schritte ab und bringen fertige Lader, Splitter und Retriever mit. Für den Anfang ist es aber unbezahlbar, die Mechanik einmal selbst gesehen zu haben – dann verstehst du auch, was die Frameworks unter der Haube tun.

Hybrid-Suche: Semantik trifft auf exakte Treffer

Reine Vektorsuche hat eine bekannte Schwäche: Sie ist großartig bei Bedeutung, aber schlecht bei exakten Zeichenketten. Sucht jemand nach einer konkreten Artikelnummer „SKU-4471-X", einem Fehlercode „ERR_503" oder einem Eigennamen, kann die semantische Suche danebenliegen, weil diese Tokens kaum Bedeutung im klassischen Sinn tragen.

Die Lösung heißt Hybrid-Suche: die Kombination aus dichter Vektorsuche und klassischer Stichwortsuche. Letztere basiert meist auf BM25, einem bewährten lexikalischen Scoring-Verfahren, das exakte Wortübereinstimmungen belohnt. Beide Methoden sind perfekte Gegenspieler – die eine glänzt bei Synonymen und Umschreibungen, die andere bei exakten Begriffen. Man kombiniert ihre Ergebnislisten, häufig mit einem Verfahren namens Reciprocal Rank Fusion (RRF), das die Ränge aus beiden Quellen fair verrechnet.

Der Effekt ist messbar: In Benchmarks erreicht Hybrid-Suche plus Re-Ranking einen MRR von rund 66 % gegenüber etwa 57 % bei reiner Semantik-Suche – ein Plus von rund neun Punkten. Viele moderne Vektordatenbanken (Weaviate, Qdrant, pgvector mit Erweiterungen) bringen Hybrid-Suche bereits eingebaut mit. Wenn deine Nutzer nach IDs, Codes oder Namen suchen, solltest du Hybrid-Suche fast immer einplanen.

Evaluierung: Woher weißt du, ob dein RAG gut ist?

Ein RAG-System „funktioniert" gefühlt schnell – aber funktioniert es auch gut? Ohne Messung tappst du im Dunkeln. Genau dafür gibt es RAGAS (Retrieval-Augmented Generation Assessment), ein Open-Source-Framework, das die Qualität entlang mehrerer Dimensionen quantifiziert, ohne dass du für jede Frage mühsam Goldstandard-Antworten von Hand schreiben musst.

Die vier zentralen RAGAS-Metriken solltest du kennen:

Context Precision (Kontext-Präzision): Sind die abgerufenen Chunks tatsächlich relevant, oder ist viel Rauschen dabei? Misst die Qualität des Retrievals.
Context Recall (Kontext-Vollständigkeit): Wurden alle für die Antwort nötigen Informationen abgerufen? Hier zeigt sich, ob dein Retrieval etwas Wichtiges übersieht.
Faithfulness (Treue): Stützt sich die generierte Antwort wirklich auf den Kontext, oder fängt das Modell wieder an zu halluzinieren? Das ist der direkte Halluzinations-Indikator.
Answer Relevancy (Antwort-Relevanz): Geht die Antwort überhaupt auf die Frage ein, oder weicht sie aus?

Der Clou: Diese Metriken trennen sauber zwischen Retrieval-Problemen und Generierungs-Problemen. Ist die Context Recall niedrig, liegt es an deinem Chunking oder Embedding – nicht am LLM. Ist die Faithfulness niedrig, obwohl der Kontext gut war, liegt es am Prompt oder Modell. Diese Diagnose ist Gold wert, weil du sonst stundenlang an der falschen Stelle schraubst. Baue Evaluierung deshalb von Anfang an ein, mit einem kleinen Satz repräsentativer Testfragen.

Die häufigsten Stolperfallen – und wie du sie umgehst

Zum Abschluss die ehrliche Liste der Fehler, die fast jeder beim ersten RAG-System macht:

Falsche Chunk-Größe. Zu kleine Chunks zerreißen den Kontext, zu große verwässern die Embeddings und füllen den Prompt mit Ballast. Teste verschiedene Größen messbar, statt zu raten.
Kein Overlap. Ohne Überlappung gehen Antworten an Chunk-Grenzen verloren. 10–20 % sind ein guter Startwert.
Embedding-Modell für Frage und Dokumente gemischt. Klassischer und tückischer Fehler – die Suche liefert dann scheinbar zufällige Ergebnisse.
Schlechte Dokumentenextraktion. Kaputte Tabellen, verlorene Struktur, Mojibake bei Umlauten. Investiere in saubere Lader – das ist die unsichtbare Grundlage.
Nur Vektorsuche, wo Hybrid nötig wäre. Wenn Nutzer nach exakten Codes oder Namen suchen, ist reine Semantik-Suche unterlegen.
Zu viele Chunks in den Prompt stopfen. Mehr Kontext ist nicht automatisch besser. Relevanter Kontext schlägt umfangreichen Kontext – „Lost in the Middle" lässt grüßen, wenn die wichtige Information in der Mitte eines überlangen Prompts untergeht.
Re-Ranking als Allheilmittel sehen. Es schärft die Precision, kann aber schlechten Recall nicht reparieren. Erst das Retrieval reparieren, dann re-ranken.
Keine Evaluierung. Ohne Messung optimierst du nach Bauchgefühl. RAGAS oder eine eigene kleine Testsuite sind Pflicht.
Quellenangaben weglassen. Ohne Verweis auf die Quelle kann niemand die Antwort prüfen – und das Vertrauen in das System bröckelt schnell.

Zusammenfassung und praktische Tipps

Retrieval-Augmented Generation ist das wichtigste Architekturmuster, um Sprachmodelle vom weltfremden Professor zum verlässlichen Wissensarbeiter zu machen. Du hast gesehen, dass das Grundprinzip verblüffend einfach ist – relevante Unterlagen vor der Antwort auf den Tisch legen – und dass der Teufel wie immer im Detail steckt: in der Chunk-Größe, im passenden Embedding-Modell, in der Hybrid-Suche und im sauberen Messen.

Meine wichtigsten Tipps für deinen Start:

Fang klein und ehrlich an. Bau die Pipeline einmal von Hand wie oben, bevor du zu einem Framework greifst. Du verstehst dann, was passiert.
Wähle den pragmatischen Stack. Chroma plus text-embedding-3-small plus ein gutes LLM bringt dich für die meisten Projekte erstaunlich weit – und kostet fast nichts.
Beginne mit strukturbasiertem Chunking und Overlap; semantisches Chunking nur bei strukturlosem Fließtext.
Plane Hybrid-Suche ein, sobald exakte Begriffe (IDs, Codes, Namen) eine Rolle spielen.
Füge Re-Ranking hinzu, wenn dein Recall stimmt, aber die Top-Ergebnisse noch nicht präzise genug sind.
Miss von Tag eins an mit RAGAS oder einer eigenen Testsuite – und trenne dabei Retrieval- von Generierungs-Problemen.
Zwinge das Modell zur Ehrlichkeit: Lass es ausschließlich aus dem Kontext antworten und Quellen nennen.

Wenn du diese Prinzipien beherzigst, baust du kein Spielzeug, sondern ein System, das echtes, aktuelles und firmeneigenes Wissen verlässlich nutzbar macht. Und das Schöne daran: Du hast jeden einzelnen Baustein selbst verstanden und kannst ihn gezielt verbessern.