Erklärung zu RAG: Verhindern Sie, dass Chatbots Firmendaten erfinden
Ein praktischer Leitfaden durch den RAG-Pipeline-Prozess – Lader, Chunking, Embeddings, Vektordatenspeicher, Neubewertung der Ergebnisse, hybride Suche sowie RRF – plus Hinweise darauf, wann man die Informationsabrufung überhaupt nicht verwenden sollte.
Eine gängige Aufgabe für frühe Chatbots lautet etwa: Fragen aus Unternehmensdateien beantworten. Ein schnelles Prototyp klingt oft professionell – und erfindet dabei Fakten. Er könnte behaupten, „24/7-Unterstützung in 12 Ländern“ anzubieten, obwohl die Unterstützung nur in einem Land verfügbar ist, ausschließlich innerhalb der Geschäftszeiten und nur dann, wenn eine bestimmte IT-Mitarbeiterin/der bestimmte IT-Mitarbeiter verfügbar ist.
Dieses Versagen ist genau der Punkt hinter RAG (Retrieval-Augmented Generation): Ein Modell, das *kann*, eine Antwort zu liefern, ist nicht dasselbe wie ein Modell, das *die* tatsächlichen Daten des Unternehmens *hat*. Ohne solche Grundlagen verhalten sich fließend sprechende Modelle wie ein selbstbewusster Verwandter, der bei einer Hochzeit Familiengeschichten erfindet – etwa zu vierzig Prozent richtig und zu hundert Prozent sicher.
Teil 1: Was ist RAG eigentlich?
RAG steht für Retrieval-Augmented Generation. Die Idee ist einfach.
Anstatt vom Modell zu verlangen, allein aus dem Trainingsgedächtnis zu antworten, holt das System zunächst relevante Materialien ab und bittet anschließend um eine Antwort, die auf diesem Material beruht.
Betrachten Sie das Textmodell als einen überheblichen, aber fähigen Praktikanten: hervorragend im Schreiben, schwach beim Erinnern an die HR-Richtlinien von 2023. Die Aufgabe von RAG besteht darin, der richtigen Seite dem Praktikanten *vor* Beginn der Antwort in die Hände zu geben.
Sonst ohne RAG: Die Antworten stützen sich auf das Gedächtnis (veraltet, allgemein oder firmenunabhängig). Mit RAG: Die Antworten stützen sich auf das Gedächtnis *plus* die für diese Frage abgerufenen Dateien.
Eine prägnante Formel, die immer gilt:
Richtige Informationen × Richtiger Kontext × Richtige Anfrage = Richtige Antwort
Teil 2: Der RAG-Prozess
Die Erweiterung durch Informationsabruf ist keine einzige magische Aktion. Es handelt sich um einen mehrstufigen Prozess: Wenn eine Stufe fehlschlägt, kommen die Antworten zu spät oder sind falsch.
Stopp 1 – Wissensquellen
Wo befindet sich das Material? PDFs, Word-Dateien, Notion-Seiten, SQL-Tabellen, Slack-Exporte sowie vergessene Tabellenkalkulationen zählen alle zu den Wissensquellen.
Stopp 2 – Dokumentladegeräte (Einholen der Daten)
Durch die Verarbeitung werden PDF/HTML/CSV usw. in eine saubere, einheitliche Form gebracht – oft ähnlich wie folgt:
Document(
page_content="The quick brown fox...",
metadata={"source": "annual_report.pdf", "page": 12, "author": "Finance Team"}
)
Das Übergehen einer sorgfältigen Verarbeitung und das Einfügen roher PDF-Bytes in den Datenfluss führt dazu, dass Überschriften und Fußzeilen als „Fakten“ angesehen werden („Laut Seite 47 von 92…“). Niemand hat den Seitenrahmen verlangt.
Lektion: Eine unsaubere Verarbeitung führt zu unsauberer Abfrage und unsauberen Antworten. Sauberkeit schon bei der Eingabe.
Stopp 3 – In Teilblöcke aufteilen (auch „Pizza in Scheiben schneiden“ genannt)
Ein 200-seitiges PDF kann nicht einfach in eine Anfrage eingefügt werden. Die Kontextfenster sind begrenzt, und das Überfluten des Modells mit einem ganzen Kochbuch, obwohl nur ein Rezept gewünscht wurde, beeinträchtigt die Genauigkeit.
Dokumente werden daher in Segmente aufgeteilt.
Häufige Strategien:
- Festgrößiges Aufteilen – Jeder N Token werden abgetrennt. Schnell, aber es kommt zu Unterbrechungen mitten im Satz.
- Festgrößiges Aufteilen mit Überschneidung – Die gleichen Abtrennungen mit geringer Überschneidung, damit der Kontext an den Grenzen erhalten bleibt. Eine gängige Standardlösung.
- Hierarchisches/rekursives Aufteilen – Zuerst Abschnitte und Paragraphen berücksichtigen, bevor abgetrennt wird.
- Semantisches Aufteilen – Sätze mit dem gleichen Thema über Embeddings zusammenfassen. Intelligenter, erfordert aber mehr Rechenleistung.
- LLM-basiertes / aggressives Aufteilen – Ein Modell fragen, wo die Abtrennungen stattfinden sollen. Teuer, nützlich für rechtliche/medizinische Texte.
Eine praktische Regel nach dem Beobachten der Aufteilung eines Vertrags, bei der „shall NOT be liable“ nach „shall“ steht: beginnen Sie mit festem Format plus Überschneidung; fügen Sie nur dann Komplexität hinzu, wenn die Suchqualität tatsächlich schlecht ist.
Stopp 4 – Embeddings (Wörter in GPS-Koordinaten umwandeln)
Ein Embedding wandelt einen Satz in eine Zahlenserie um, die die Bedeutung und nicht die Schreibweise erfassen. Sätze mit ähnlicher Bedeutung liegen auch dann nah beieinander, wenn sie keine gemeinsamen Wörter haben.
„Wie kann ein Passwort zurückgesetzt werden?“ und „Die Anmeldedaten wurden vergessen“ weisen fast keine gemeinsamen Elemente auf, bedeuten aber nahezu dasselbe. Eine Schlüsselwortsuche überseht diese Verbindung; ein Embedder erkennt sie durch den Vergleich der Bedeutung.
Die Entwicklung verlief von Bag-of-Words (zählt nur) → TF-IDF → Word2Vec → BERT → modernen Embedding-APIs und offenen Modellen (OpenAI, Cohere, BGE, E5 sowie ähnliche), die den Kontext berücksichtigen.
Analogie: Bag-of-Words ist eine Wort-für-Wort-Maschinenübersetzung. Moderne Embeddings ähneln eher jemandem, der in beiden Kulturen gelebt hat und die Absicht erkennt.
Stopp 5 – Vektordatenspeicher (die Bibliothek, in der all diese Zahlenserien aufbewahrt werden)
Sobald Segmente zu Vektoren werden, benötigen sie eine schnelle Speicherung und Suche: Pinecone, Qdrant, Weaviate, Milvus, ChromaDB, FAISS sowie ähnliche Systeme.
Bei einer Abfrage werden die top-K Segmente zurückgegeben, deren Vektoren dem Abfragevektor am nächsten liegen. Zu den Indexierungsoptionen gehören:
- Brute Force – Vergleich aller Elemente. Präzise, aber bei großen Mengen langsam.
- ANN (Approximate Nearest Neighbor) – etwas weniger präzise, aber deutlich schneller. Geeignete Standardlösung.
- IVF – Zuerst Clustern bilden; nur in vielversprechenden Clustern suchen.
- HNSW – Schneller Durchlauf eines Nachbargraphen. Häufig in produktiven RAG-Systemen verwendet.
Brute Force bei Millionen von Vektoren „für perfekte Genauigkeit“ kann Abfragen, die eigentlich in Millisekunden abgeschlossen werden sollten, auf längere Laufzeiten verlängern. Passen Sie den Index an die Datenmenge an – nicht an Stolz.
Schritt 6 – Abruf (Ähnlichkeitssuche)
Sobald eine Frage eintrifft, wird sie mit dem dieselben Modell verarbeitet wie Dateien – das Mischen von Modellen ist ein klassischer Fehler – anschließend werden die top-K ähnlichen Abschnitte abgerufen.
Kosinusähnlichkeit ist die übliche Messgröße: Sie zeigt an, inwieweit zwei Vektoren in ihrer Richtung übereinstimmen, wobei die Länge ignoriert wird. Sie ist eine stabile Standardmethode unabhängig von der Länge des Textes.
Schritt 7 – Erweiterung (dem Assistenten die richtige Datei zur Verfügung stellen)
Die abgerufenen Abschnitte werden zusammen mit der Benutzerfrage in die Anweisung eingefügt. Das ist der „Erweiterte“ Schritt:
System: You are a helpful assistant. Only answer using the context below.
Context: [retrieved chunk 1] [retrieved chunk 2] [retrieved chunk 3]
Question: What is our refund policy?
Schritt 8 – Generierung (das LLM spricht endlich)
Nur dann erstellt das Modell die endgültige Antwort – basierend auf dem abgerufenen Kontext und nicht auf anderen Faktoren.
Teil 3: Was „es funktioniert“ von „es funktioniert gut“ unterscheidet
Tutorials enden oft bei dem grundlegenden Ablauf. Für die Qualität von Live-Systemen sind in der Regel weitere Aspekte notwendig.
Neubewertung – denn das erste Suchergebnis ist nicht immer das beste Ergebnis
Die Bi-Encoder-Methode ist schnell, aber grob: Abfrage und Dokument werden getrennt kodiert und anschließend verglichen. Sie eignet sich hervorragend, um Millionen von Einträgen auf etwa 50 Kandidaten einzugrenzen.
„Schnell und grob richtig“ bedeutet nicht immer „tatsächlich richtig“. Deshalb bewertet ein langsamerer cross-encoder-basierter Neubewertungsmechanismus Abfrage und Dokument zusammen, wodurch Nuancen, Negationen und Kontext berücksichtigt werden. Er arbeitet nur mit der vorläufigen Liste und hebt die wirklich besten Ergebnisse hervor.
Analogie: Bi-Encoder durchsehen Lebensläufe, um eine vorläufige Liste zu erstellen; Cross-Encoder führen das Vorstellungsgespräch durch.
In einem medizinischen FAQ-Bot ohne Neubewertung können Fragen zu Wechselwirkungen mit Alkohol ein anderes Medikament ans Licht bringen, das lediglich denselben Begriffsvorrat teilt. Ein cross-encoder-basierter Neubewertungsmechanismus behebt das in der Regel umgehend. Wenn Präzision von Bedeutung ist (rechtlich, medizinisch, finanziell), ist eine Neubewertung zwingend erforderlich und nicht optional.
Hybrid-Suche – weil sowohl die lexikalische Suche als auch die Vektorsuche für sich genommen etwas unvollständig sind
Die Vektorsuche erfasst die Bedeutung, kann aber genaue Token übersehen – wie SKU-Codes, Fehlernummern oder Eigennamen. Die BM25-lexikalische Suche erfasst exakte Zeichenfolgen, vernachlässigt jedoch Synonyme.
Hybrid-Suche kombiniert BM25 und Vektorabruf: Präzision bei Schlüsselwörtern plus semantische Vollständigkeit. Wenn man unsicher ist, ist die Hybrid-Suche eine gute Standardlösung – selten schlechter, oft besser.
RAG-Fusion – mehrere Meinungen wie in einem Gruppenprojekt kombinieren (und diesmal tatsächlich funktionieren)
Mehrere Suchalgorithmen (dicht, Schlüsselwörter, domänenspezifisch) erzeugen mehrere gerankte Listen. RAG Fusion verschmilzt sie mithilfe von Reciprocal Rank Fusion (RRF).
Die Idee ist einfach, auch wenn die Formel formal erscheint: Ein Dokument, das in mehreren unabhängigen Methoden weit oben gerankt wird, ist vermutlich relevant. RRF belohnt die Konsistenz zwischen den Listen anstelle von Rohwerten, die zwischen den Suchalgorithmen nicht vergleichbar sind.
RRF(d) = Σ 1 / (k + rank_i(d))
Hier beträgt k in der Regel 60 – eine Branchenkonvention eher als eine abgeleitete Konstante.
Metadaten – die Labels, die Ihnen später das Leben retten
Metadaten sind Daten über Daten: Titel, Autor, Datum, Quelle, Zugriffsstufe. Sie erscheinen langweilig, bis eine Zugriffsregel auftaucht – „Zeigen Sie interne HR-Dokumente niemals externen Benutzern“ – und dann werden die access_level: internal-Tags plötzlich wichtig.
Metadaten ermöglichen Filter, Erneut-Ranking-Verfahren, Zugriffskontrolle sowie Fehlerbehebung („Warum hat ein Dokument aus dem Jahr 2019 auf eine Frage aus dem Jahr 2026 geantwortet?“ → fehlende Datumsfilter).
Gedächtnis und Caching – weil niemand zweimal für dieselbe Berechnung bezahlen möchte
Zwei oft verwechselte Konzepte:
- Gedächtnis = langfristiges Speichern von Präferenzen, vorherigen Interaktionen sowie dauerhaften Fakten.
- Caching = kurzfristige Wiederverwendung teurer Ergebnisse (Modellantworten, Suchergebnisse) bei wiederholten Anfragen.
Gedächtnis sorgt dafür, dass Assistenten konsistent wirken. Caching macht sie schnell und kostengünstig. Die Kombination beider – zum Beispiel das „Caching“ von Präferenzen mit einer Gültigkeitsdauer von zehn Minuten – kann dazu führen, dass der Benutzernamen mitten im Chat verschwindet. Halten Sie die Konzepte getrennt.
Teil 4: Wann sollten Sie RAG NICHT verwenden?
Retrieval Augmentation ist kein Allzweckwerkzeug.
Verwenden Sie RAG nicht, wenn:
- Die Frage betrifft allgemeines Wissen, mit dem das Modell bereits umgehen kann (“Hauptstadt Frankreichs” benötigt keinen Vektorindex).
- Fakten ändern sich ständig (Preise, Live-Ergebnisse) – hier ist eine API vorzuziehen.
- Die Aufgabe ist rein kreativ (Poesie, Brainstorming) – das Abrufen von Informationen hilft selten.
- Das Korpus ist klein genug, um es direkt in die Anfrage aufzunehmen.
- Ultra-niedrige Latenzzeiten erlauben keinen zusätzlichen Abrufschritt.
Mannchmal liegt die Lösung im Formulieren der Anfrage oder im Feintunen des Modells, nicht in einem vollständigen Vektorfluss. Wählen Sie das richtige Werkzeug, bevor Sie etwas aufbauen.
Teil 5: Aus Erfahrungen gelernte Best Practices
- Teilien Sie den Text klug auf, aber nicht zu klein. Zu kleine Segmente führen zum Verlust des Kontexts; zu große Segmente beeinträchtigen die Genauigkeit. Ziehen Sie Überschneidungen vor.
- Verwenden Sie denselben Embedder für Dateien und Abfragen. Das Mischen von Modellen führt zu unvollständigen Ergebnissen.
Teams, die das Abrufen von Informationen als nachrangige Aufgabe betrachten, stoßen in der Regel wieder auf dieselben Fehlermuster: stille Schema-Veränderungen in den Ladeverfahren, Chunk-Grenzen, die Negationen teilen, Unstimmigkeiten zwischen dem eingebetteten Modell und den Online-Anfragen sowie Dashboards, die nur die „Antwortverzögerung“ messen und dabei die Genauigkeit ignorieren. Eine solide RAG-Praxis betrachtet jeden Schritt im Prozess als Produktbereich mit Verantwortlichen, Tests und Rollback-Plänen – insbesondere dann, wenn der Assistent Kunden oder regulierten Arbeitsabläufen gegenübersteht.
Beim Bewerten von Änderungen sollten Paarversuche bevorzugt werden: derselbe Fragekatalog, dieselbe Bewertungskriterienliste, Vergleich von Recall@k und Groundedness vor und nach einer Anpassung der Chunking-Logik oder des Re-Rankers. Kleine Verbesserungen beim Abrufen von Informationen übertrumpfen oft größere Anpassungen allein am Prompt, da der Generierer nicht auf Inhalte verweisen kann, die niemals in das Kontextfenster gelangt sind.
Das RAG-Mantra
Richtige Informationen → Richtiger Kontext → Richtige Anfrage → Richtige Antwort.
RAG ist Technik, keine Magie. Eine saubere Dateneingabe, sinnvolle Abrufmethode, ehrliche Erweiterung sowie eine präzise Anfrage führen dazu, dass ein überheblicher „Verwandter“ zu einem gut informierten Spezialisten wird, der zunächst die Datei liest – und aufhört, eine globale 24/7-Unterstützung zu erfinden, die nie existiert hat.