Fragen Sie ein allgemeines LLM nach der Rückgaberichtlinie Ihres Unternehmens oder den Support-Tickets der letzten Woche, und es wird entweder sagen, dass es das nicht weiß, oder etwas Plausibles erfinden. Sein Wissen endet dort, wo die Trainingsdaten aufhören. Es hat Ihre Dokumente nie gesehen und kann sie nicht mitten im Gespräch nachschlagen. Retrieval-Augmented Generation (RAG) behebt genau das: Bevor das Modell antwortet, findet ein separater Schritt den relevanten Text in Ihren eigenen Daten und gibt ihn dem Modell als Teil des Prompts mit.

Wie Retrieval-Augmented Generation wirklich funktioniert

Ein einfacher LLM-Aufruf ist ein einziger Schritt: Prompt rein, Antwort raus, nur mit dem, was das Modell während des Trainings gelernt hat. RAG teilt das in zwei Schritte: erst abrufen, dann generieren.

  1. Ihre Dokumente werden vorab in Chunks aufgeteilt, in Vektoren (Embeddings) umgewandelt und in einer Vektordatenbank gespeichert.
  2. Zur Abfragezeit wird die Frage des Nutzers auf dieselbe Weise in ein Embedding umgewandelt und mit den gespeicherten Chunks verglichen, um die nächsten Treffer zu finden.
  3. Die besten Treffer werden als Kontext in den Prompt eingefügt, und erst dann generiert das LLM eine Antwort.

Stellen Sie sich das wie eine Open-Book-Prüfung im Vergleich zu einer Closed-Book-Prüfung vor. Ein Closed-Book-LLM antwortet nur aus dem Gedächtnis, weshalb es Dinge erfindet, sobald die Frage über das Gelernte hinausgeht. RAG legt ihm zuerst die passende Seite vor, sodass es aus etwas antwortet, das vor ihm liegt, statt aus etwas, das es sich zusammenreimt.

Das Modell selbst ändert sich nie. Seine Gewichte bleiben exakt die von vor der RAG-Erweiterung; Retrieval ist der einzige neue Baustein. Deshalb lässt sich RAG auch so günstig aktuell halten: Sie bearbeiten ein Dokument, und die nächste Abfrage sieht die Änderung.

Eine RAG-Pipeline bauen: Chunking und Embedding Ihrer Daten

Die Ingestion ist die Hälfte der Pipeline, die läuft, bevor überhaupt jemand eine Frage stellt. Sie macht aus Ihren Dokumenten etwas, das eine Ähnlichkeitssuche abfragen kann.

Dokumente sind zu lang, um sie als einzelne Einheit in ein Embedding umzuwandeln. Ein 20-seitiges PDF, das als ein Vektor eingebettet wird, passt am Ende ein bisschen zu jeder Abfrage und gut zu keiner, also teilen Sie es zuerst in Chunks. Ein einfacher Splitter mit fester Größe und Overlap reicht zum Start:

1
2
3
4
5
6
7
8

def chunk_text(text, chunk_size=500, overlap=50):
    chunks = []
    start = 0
    while start < len(text):
        end = start + chunk_size
        chunks.append(text[start:end])
        start = end - overlap
    return chunks

500 Zeichen mit 50 Overlap sind ein vernünftiger Startpunkt. Produktions-Pipelines chunken meist nach Token-Anzahl statt nach Zeichen, mit einem Splitter, der den Tokenizer kennt, damit eine Chunk-Grenze nicht mitten in einem Wort landet. Der Overlap sorgt dafür, dass ein Satz, der zwischen zwei Chunks geteilt wird, trotzdem in mindestens einem davon vollständig erscheint.

Jeder Chunk wird anschließend eingebettet und gespeichert. Chroma ist eine gute erste Vektordatenbank, weil sie im selben Prozess läuft, ohne dass ein Server aufgesetzt werden muss, und ihre Standard-Embedding-Funktion (all-MiniLM-L6-v2) keinen API-Key braucht:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

import chromadb

client = chromadb.Client()
collection = client.create_collection(name="support-docs")

collection.add(
    ids=["doc1", "doc2", "doc3"],
    documents=[
        "The refund window is 30 days from the delivery date.",
        "Refunds go back to the original payment method within 5 business days.",
        "Store credit never expires and can be used on any future order.",
    ],
)

Das ist die gesamte Ingestion-Phase: chunken, einbetten, speichern. Sie läuft einmal pro Dokument und erneut, sobald sich ein Dokument ändert.

Wenn Sie keine Vektordatenbank lokal installieren möchten: Die meisten (Chroma, Weaviate, Milvus) liefern ein offizielles Image und laufen problemlos in einem Container; siehe was Docker eigentlich macht, falls Sie bisher keinen benutzt haben.

Wie Retrieval funktioniert: Embedding der Abfrage und Ranking der Treffer

Zur Abfragezeit wandelt dasselbe Embedding-Modell die Frage des Nutzers in einen Vektor um, und die Datenbank liefert die gespeicherten Chunks zurück, die diesem am nächsten liegen, je nach konfigurierter Distanzmetrik — cosine similarity und quadrierte L2-Distanz sind die beiden, die Sie am häufigsten sehen werden:

1
2
3
4
5
6
7
8

results = collection.query(
    query_texts=["How long do I have to return something?"],
    n_results=2,
)

print(results["documents"])
# [['The refund window is 30 days from the delivery date.',
#   'Refunds go back to the original payment method within 5 business days.']]

Die Abfrage benutzt an keiner Stelle das Wort „Rückerstattung“ (refund) und findet trotzdem den passenden Treffer. Genau deshalb lohnt sich Embedding statt Grep: Zwei Texte landen im Vektorraum nah beieinander, wenn sie Ähnliches bedeuten, nicht wenn sie dieselben Wörter teilen.

Der letzte Schritt fügt die abgerufenen Chunks in den Prompt ein:

1
2
3
4
5
6
7
8

context = "\n".join(results["documents"][0])

prompt = f"""Answer the question using only the context below. If the context doesn't contain the answer, say so.

Context:
{context}

Question: How long do I have to return something?"""

prompt geht an die Chat-Completion-API, die Sie ohnehin schon nutzen. RAG erfordert kein bestimmtes Modell oder Provider; es ist ein Muster dafür, was Sie vor dem Absenden in den Prompt packen. Braucht dieser API-Aufruf einen Key, halten Sie ihn aus Ihrem Image heraus wie jedes andere Credential auch: als Umgebungsvariable oder gemountetes Secret, nie als Build-Argument. Umgebungsvariablen und Secrets in Docker erklärt den Unterschied.

RAG gegen Fine-Tuning: Was löst Ihr Problem?

Beide sollen ein LLM für Ihren konkreten Anwendungsfall besser machen, verändern aber unterschiedliche Dinge.

RAGFine-Tuning
Was sich ändertNichts am Modell; Sie fügen einen Retrieval-Schritt hinzuDie Gewichte des Modells selbst, durch weiteres Training
Wissen aktualisierenDokument bearbeiten oder hinzufügen, nächste Abfrage sieht esNeu trainieren (oder einen weiteren Fine-Tuning-Lauf)
Geeignet fürFakten, aktuelle Daten, alles, was sich oft ändertTon, Ausgabeformat, aufgabenspezifische Denkmuster
Kosten für UpdatesGering — kein TrainingslaufHoch — braucht einen Trainingslauf und einen Datensatz
Versagt, wennRetrieval den falschen Chunk übersieht oder falsch einstuftSich das benötigte Verhalten nicht auf Eingabe-Ausgabe-Beispiele reduzieren lässt

Ein Support-Bot, dessen Rückgaberichtlinie sich jedes Quartal ändert, ist ein RAG-Problem: Fine-Tunen Sie ihn auf die Richtlinie des letzten Quartals, ist er bei der neuen selbstbewusst falsch. Ein Modell, das jedes Mal ein bestimmtes JSON-Schema ausgeben oder einen bestimmten Denkstil einhalten muss, kommt einem Fine-Tuning-Problem näher: Keine Menge an abgerufenem Kontext ändert, wie ein Modell seine Ausgabe formatiert. Viele Produktionssysteme nutzen beides: ein fine-getuntes Modell für Ton und Struktur, gefüttert mit Fakten aus RAG.

Wo Retrieval-Augmented Generation versagt

RAG-Demos wirken einfach, weil die Demo drei Dokumente und eine offensichtliche Antwort hat. Produktionssysteme haben Tausende Dokumente, und jeder der folgenden Punkte kann eine Antwort still und leise ruinieren:

  • Chunking, das die Struktur ignoriert. Ein Splitter mit fester Größe, der eine Tabelle mittendurch schneidet oder eine Überschrift von dem Absatz trennt, den sie einleitet, erzeugt Chunks, die außerhalb ihres Kontexts wie Kauderwelsch wirken — und Kauderwelsch wird schlecht eingebettet und schlecht abgerufen.
  • Ein veralteter Index. Vektorsuche hat kein Gefühl für Zeit. Wird ein Dokument aktualisiert, aber nie neu eingebettet, wird weiterhin die alte Version abgerufen, und nichts in der Pipeline zeigt an, dass sie veraltet ist.
  • Der richtige Chunk existiert, landet aber nicht weit genug oben. Top-k-Retrieval liefert nur die k nächsten Treffer; ist die tatsächliche Antwort der 15.-nächste Chunk und Sie rufen nur 5 ab, sieht das Modell sie nie.
  • Zu viel Kontext, schlecht platziert. Zehn abgerufene Chunks in den Prompt zu stopfen heißt nicht, dass das Modell sie alle gleich gewichtet. Modelle sind messbar schlechter darin, Informationen in der Mitte eines langen Kontexts zu nutzen als am Anfang oder Ende.
  • Keine Auswertung über „die Demo-Antwort sah richtig aus“ hinaus. Ohne ein Set aus Fragen und erwarteten Antworten bleibt eine Retrieval-Regression durch eine Chunking-Änderung oder einen Reindexierungsfehler unbemerkt.

Die meisten davon sind Retrieval-Fehler, keine Modellfehler, und jeder ist sichtbar, wenn Sie die abgerufenen Chunks statt nur die endgültige Antwort prüfen.

Wie Sie Ihre erste RAG-Pipeline bauen

Bauen Sie zuerst die Drei-Schritt-Version: chunken Sie eine Handvoll echter Dokumente, betten Sie sie in Chroma oder einem anderen lokalen Store ein, und verdrahten Sie die abgerufenen Chunks genau wie oben gezeigt mit einem Prompt. Stellen Sie ihm dann die 10 Fragen, die Sie von echten Nutzern erwarten. Prüfen Sie, ob die abgerufenen Chunks die Antwort enthalten, bevor Sie die generierte Antwort beurteilen — ein falsches Retrieval macht eine falsche Antwort unvermeidlich, egal wie der Prompt formuliert ist. Erst wenn dieser Kreislauf bei echten Fragen zuverlässig funktioniert, lohnt es sich, die Chunk-Größe anzupassen, das Embedding-Modell zu wechseln oder einen Reranker hinzuzufügen.

Verwandte Artikel