Wie bringt man LLMs dazu, aktuelle und faktentreue Antworten aus eigenen Datenbeständen zu generieren? Retrieval-Augmented Generation verbindet intelligente Suche mit generativen Modellen. Dieser Artikel gibt einen Überblick über die Herausforderungen und fortgeschrittenen Techniken moderner RAG-Systeme – von Retrieval-Optimierung über Caching-Strategien bis hin zu robusten Evaluation-Frameworks und Use-Cases
Grundlagen und Architektur von RAG-Systemen – ein Überblick
Mittlerweile nutzen viele Menschen KI-Systeme auf Basis von Sprachmodellen (engl. Large Language Models, LLMs) zur Abfrage von Informationen. Bekannte Vertreter sind Produkte wie OpenAIs ChatGPT, Anthropics Claude oder Mistrals LeChat. Diese haben Zugriff auf öffentliche Informationen, wie sie im öffentlichen Internet verfügbar sind, die im Rahmen des Trainings in den internen Gewichten des LLMs gespeichert wurden.
Wie ist es jedoch, wenn man Informationen aus z.B. internen Dokumenten benötigt, die in einem Unternehmen oder einer Verwaltung vorliegen, also einem LLM nicht bekannt sind? Retrieval-Augmented Generation (RAG) bietet die Möglichkeit, diese internen Dokumente dem LLM „mitzugeben“, so dass das LLM auf Basis des Wissens, das in den Dokumenten enthalten ist, gezielt Antworten auf Nutzerfragen generiert. Hierbei ist zu beachten, dass der sog. Kontext eines Modelles, also die Menge der Informationen, die das LLM zusätzlich zu dessen internen Gewichten nutzen kann, stark begrenzt ist. Grob vereinfacht kann man sagen, das Langzeitgedächtnis entspricht den Gewichten des LLMs und das Kurzzeitgedächtnis dem Kontext. Dementsprechend ist eine Auswahl der relevanten internen Dokumente notwendig, aus denen das LLM dann eine Antwort generieren kann.
RAGs verbinden damit die Stärken großer Sprachmodelle mit einer zusätzlichen Wissensbasis, sodass Antworten nicht nur flüssig formuliert, sondern auch durch relevante, domänenspezifische Quellen (wie das interne Wissen eines Unternehmens) gestützt sind. RAG lässt sich dabei als Pipeline denken, die Textdaten aus einer Wissensbasis in einen durchsuchbaren „Wissensraum“ überführt und diesen bei jeder Anfrage selektiv in den Kontext eines LLM einspielt. Damit werden Halluzinationen reduziert, Aktualität gewährleistet und Nachvollziehbarkeit durch Zitate ermöglicht.
image2
Abbildung 1: Bestandteile eines RAGs
Überblick über RAGs: Eine RAG-Pipeline beginnt mit der Erfassung und Aufbereitung von Eingangsdaten. Dokumente können aus sehr unterschiedlichen Quellen stammen: internen Wikis und Tickets, PDF-Berichten, HTML-Seiten, Quellcode-Repositories, Datenbanken oder externen APIs. Vor der Nutzung in einem RAG-System werden sie bereinigt und segmentiert, also zerteilt, um diese Teile gezielt dem LLM zuzuführen. Diese Segmentierung (Chunking) ist zentral für die Funktion des RAGs: Zu große Blöcke („Chunks“) erhöhen das Rauschen im Kontext, zu kleine zerstückeln Zusammenhänge. In der Praxis kombiniert man semantisches Splitten (z. B. entlang von Überschriften, Absätzen, Code-Blöcken) mit Längenbegrenzungen und moderater Überlappung, um Kohärenz zu wahren. Eine Anreicherung um Metadaten wie Quelle, Autor, Zeitstempel, Sprache, Sicherheitslabel und Themen erleichtert spätere Filterung und Governance.
Embeddings bilden das Herz der Abfrage von relevanten Inhalten, dem sogenannten semantischen Retrieval. Dazu wird ein sogenanntes Embedding der Chunks durchgeführt. D. h., die Chunks werden in eine numerische Repräsentation in Form eines Vektors übersetzt, um die weitere Verarbeitung mit LLMs zu ermöglichen. D.h., anstelle einer naiven, klassischen Codierung wie TF-IDF (Term Frequency-Inverse Document Frequency) werden neuere, günstigere Repräsentationen genutzt. Die Repräsentation sollte so beschaffen sein, dass die weitere Verarbeitung leicht möglich ist und semantische Ähnlichkeit der Chunks numerisch repräsentiert wird. Erreicht wird dies durch ein neuronales Netz, welches Teil des genutzten LLMs ist. Dazu projiziert das Embedding-Modell die Chunks in einen hochdimensionalen Vektorraum, in dem semantisch ähnliche Inhalte nah beieinander liegen.
Speicherung und Nutzung der Chunks: Eine Vektordatenbank speichert Embeddings von Text- oder Code-„Chunks“ und ermöglicht eine schnelle Ähnlichkeitssuche (Approximate Nearest Neighbor). So lassen sich semantisch passende Passagen zu einer Frage finden, auch wenn Begriffe nicht exakt übereinstimmen. Häufig werden Metadaten-Filter (Zeitfenster, Quelle, Sprache, Sicherheitslabel) mit der Vektorsuche kombiniert, um irrelevante Treffer früh auszusortieren.
Ablauf der Abfrage: Eine Abfrage kann in zwei Stufen erfolgen. Zunächst erfolgt ein semantisches Retrieval, optional ergänzt durch eine Keyword-Suche. Semantisches Retrieval bedeutet, dass Chunks in der Datenbank gesucht werden, die wahrscheinliche passende Informationen zu der Anfrage enthalten. Hierzu muss die Anfrage ebenfalls „embedded“ werden und eine Funktion (z. B. der Kosinus-Abstand) definiert werden, welche die Ähnlichkeit bewertet. Im zweiten Schritt werden die Top-Treffer nach Relevanz sortiert und diejenigen ausgewählt, die dem LLM zur Verfügung gestellt werden.
Generierung der Antwort: Aus den ausgewählten Chunks soll eine Antwort generiert werden. Dies geschieht jedoch nicht für sich allein, sondern wesentlich für die Qualität und Passgenauigkeit der Antwort ist es, dem LLM mitzuteilen, wie die Antwort beschaffen sein soll. Dies geschieht über den Prompt. Der Prompt fasst Systemregeln, die Nutzerfrage und ausgewählte Textauszüge zusammen; optional kommen kurze Beispiele hinzu, wie die Antwort aussehen soll. Gute Prompts erzwingen Quellenbezug, Zitate und das Markieren von Unsicherheit; fehlt Evidenz, soll das System transparent bleiben. Nach der Generierung folgen leichte Checks: Format und Zitate prüfen, Policies einhalten, optional eine Faithfulness-Prüfung (stehen die Aussagen wirklich in den Quellen?). Bei Bedarf werden Antwortteile strukturiert (z. B. kurze Zusammenfassung, dann Details).
Überblick über den weiteren Artikel: Grundsätzlich scheint die Nutzung von RAGs einfach zu sein. In der Praxis ergeben sich jedoch eine Reihe von Problemen, welche zu schlechten Antworten und damit z. B. zur Nicht-Akzeptanz des RAGs durch Nutzerinnen und Nutzer führen können. Dieser Artikel beschreibt daher eingehend die Grundlagen von RAGs und hilfreiche Vorgehensweisen, um RAGs erfolgreich einsetzen zu können.
Datenqualität, -verfügbarkeit und –auffindbarkeit
Die Auswahl relevanter Datenquellen spielt beim Aufbau eines RAG-Systems eine zentrale Rolle, wobei hauptsächlich in die Kategorien Datenqualität, Datenverfügbarkeit und ‑auffindbarkeit und Dateitypen zu unterscheiden ist.
Datenqualität: Generell sollten vorhandene Daten aktuell, mit einer Versionsnummer versehen und nicht redundant abgelegt sein. Gibt es Versionen, sind diese bestenfalls mit einem Änderungslog und „single source of truth“ zu versehen und zu kennzeichnen. Sensible Daten sollten vorab automatisiert erkannt und geschwärzt werden. Metadaten sollten einheitlich, z. B. über eine ID, den Titel, eine URI oder über Tags, identifizierbar sein. Wichtig ist zudem eine korrekte Kodierung, im Falle einer Spracherkennung eine gut strukturierte Transkription und eine Normalisierung hinsichtlich Unicode-Repräsentation sowie die Berücksichtigung einheitlicher Leer- und Sonderzeichen. Die Dokumentenhierarchie sollte möglichst über alle Dokumente gleich sein (Dokument → Abschnitt → Absatz → Tabelle → Zeile). Um die Verarbeitung für RAG möglichst strukturiert vorzubereiten, sollten Chunking-Sizes von 200–400 Tokens und 10–20 % Overlap verwendet sowie bei Überschriften, Absätzen oder Seitenumbrüchen geschnitten werden. In der Regel werden Tabellen separat behandelt, z. B. zeilenweise und kontextualisiert werden, über eine Tabellenüberschrift.
Datenverfügbarkeit und ‑auffindbarkeit: Hinsichtlich des Zugriffs auf die Daten ist es essenziell, zuverlässige Konnektoren bzw. Schnittstellen (Beispiele: SharePoint, LDAP, Active Directory, Confluence, Datenbanken und APIs) zur Verfügung zu haben. Für die Auffindbarkeit von Daten sind ein Metadaten-Schema und der Lebenszyklus der Metadaten (gültig ab/bis) wichtig. Häufig wird auch eine hybride Suche (BM25 Suchalgorithmus sowie Vektordatenbank) verwendet, sodass ein Metadatenfilter verwendet werden muss.
Einige typisch vorkommende Dateitypen und Tipps für den Umgang in RAG-Systemen sind in folgender Tabelle dargestellt
| Typ | Extraktionsbesonderheiten | RAG-spezifische Tipps |
| PDF (digital) | Lesereihenfolge, Spalten/Footers, Seitenzahlen | Seiten-/Abschnitts-ID speichern; Heading-basiertes Chunking |
| DOCX/PPTX | Kommentare/Änderungen, Notizen, eingebettete Bilder | Kommentare optional; Folientitel + Notizen für Kontext |
| HTML | Boilerplate entfernen, Navigation/Ads | Nur Hauptinhalt; kanonische URL; H1–H3 als Struktur |
| Markdown/TXT | Frontmatter, Codeblöcke | Frontmatter als Metadaten; Code separat/mit Sprache taggen |
| CSV/Excel | Header, gemergte Zellen, Datentypen/Einheiten | Spaltenbeschreibung als Kontext; zeilenweises chunking |
| JSON | Verschachtelte Arrays/Objekte, Schemas | Felder flach abbilden; Schema-Version mitführen |
| Bilder | OCR, Diagramm-Erkennung | Bildunterschrift/Alt-Text; Regionen mit Koordinaten speichern |
| Audio/Video | ASR, Sprache, Sprecherdiarisierung | Zeitstempel, Sprecher + Kapitel als Chunks |
| Code/Repos | Mehrere Sprachen, Abhängigkeiten, Lizenz | Datei-/Symbol-Ebene indexieren; README/Docs priorisieren |
| Wikis/SharePoint | Berechtigungen, Vorlagen, Versionen | ACLs übernehmen; Space/Seite/Abschnitt als Hierarchie |
Wichtig beim Aufbau der Datengrundlage sind vor allem das Beachten der Mehrsprachigkeit (ein Modell für alle Sprachen vs. pro Sprache ein Modell) und die Neuberechnung von Embeddings nach einem Modellwechsel. Bei der Generierung der Antwort muss darauf geachtet werden, dass das Kontextfenster begrenzt wird, eine Zitierung der gefundenen Dokumente stattfindet, sowie die Halluzination minimiert wird. Letzteres kann durch strikte Kontextnutzung und durch das Herabsetzen der Sampling-Temperatur erreicht werden.
Vektordatenbanken und Indexierungsmethoden
Dokumentenverarbeitung und Chunking-Strategien
In der Psychologie wird Chunking als eine Methode beschrieben, wie Menschen Informationen im Gedächtnis bündeln. Das folgende Beispiel zeigt, wie Chunking funktioniert. Die Ziffern 1,5, 1 und 0 beinhalten vier Informationseinheiten. Angenommen, ich sei am 15.10. geboren, ließen sich diese vier Informationseinheiten in nur eine, nämlich in „mein Geburtstag“, umwandeln und zusammenfassen. Chunking wird hier also verwendet, um die ohnehin begrenzte Kapazität des Kurzzeitgedächtnisses effizienter zu gestalten. Im Kontext von LLM und dem Aufbau von RAG-Systemen ist Chunking eine wichtige Methode zur Strukturierung, also dem richtigen Einteilen, von unstrukturierten Daten.
Warum ist es wichtig, unstrukturierte Daten in sinnvolle Abschnitte einzuteilen? Dies ist primär notwendig, um kontextuell relevante Informationen an das Sprachmodell weiterzugeben. Wie in [1] beschrieben, gibt es folgende verschiedene Chunking-Strategien, die sich in semantische/dynamische und fixe Chunking-Methoden einteilen lassen. Fixe Chunking-Methoden sind solche mit fester (Token-) Länge, satzbasiertes Chunking und paragraphbasiertes Chunking. Dynamische Chunking-Verfahren sind z.B. das Sliding Window Chunking, semantisches Chunking, rekursives Chunking, kontextangereichertes Chunking, modalitätsspezifisches Chunking, agentisches Chunking, unterdokument-Chunking und hybrides Chunking.
Embedding
Ein zentraler Bestandteil zum Aufbau eines RAG-Systems sind Embedding-Modelle, die sprachliche Einheiten numerisch repräsentieren. Sie wandeln Wörter, Sätze oder Dokumente in Vektoren eines hochdimensionalen Raums um. Ähnliche Bedeutungen werden dabei durch ähnliche Vektoren abgebildet. Grundlage ist die distributionale Semantik, die besagt, dass Wörter mit ähnlichem Kontext ähnliche Bedeutungen haben. Frühe Embedding-Ansätze wie Word2Vec (Mikolov et al., 2013) und GloVe (Pennington et al., 2014) lernen Wortrepräsentationen, indem sie Konkurrenzmuster in großen Textkorpora analysieren. Word2Vec nutzt neuronale Netze zur Vorhersage von Kontextwörtern (Skip-Gram, CBOW), während GloVe statistische Wortkonkurrenzen in eine faktorisierte Matrix einbettet. Neuere Modelle wie BERT (Devlin et al., 2018) verwenden Transformer-Architekturen, die Kontextabhängigkeit berücksichtigen: Ein Wort erhält unterschiedlich lange Vektoren je nach Satzumgebung.
Vorteile von Embeddings liegen in der kompakten und kontinuierlichen Abbildung semantischer Strukturen. Sie ermöglichen semantische Suche, Textklassifikation und Clustering mit hoher Effizienz und Genauigkeit. Zudem lassen sie sich domänenübergreifend anwenden und feinjustieren (Fine-Tuning).
Grenzen bestehen in der Abhängigkeit von Trainingsdaten: Vorurteile oder Ungleichverteilungen in den Daten führen zu Verzerrungen in den Embeddings (Bias). Die semantische Bedeutung der Dimensionen ist nicht direkt interpretierbar, was die Erklärbarkeit einschränkt. Weiterhin erfordern große Embeddingmodelle erhebliche Rechen- und Energieressourcen.
Wichtig beim Aufbau der Datengrundlage sind vor allem das Beachten der Mehrsprachigkeit (ein Modell für alle Sprachen vs. pro Sprache ein Modell) und die Neuberechnung von Embeddings nach einem Modellwechsel. Bei der Generierung der Antwort muss darauf geachtet werden, dass das Kontextfenster begrenzt wird, eine Zitierung der gefundenen Dokumente stattfindet, sowie die Halluzination minimiert wird. Letzteres kann durch strikte Kontextnutzung und durch das Herabsetzen der Sampling-Temperatur erreicht werden.
Quellen
https://masteringllm.medium.com/11-chunking-strategies-for-rag-simplified-visualized-df0dbec8e373
Mikolov, T., Chen, K., Corrado, G., & Dean, J. (2013). Efficient Estimation of Word Representations in Vector Space. arXiv:1301.3781.
Pennington, J., Socher, R., & Manning, C. (2014). GloVe: Global Vectors for Word Representation. EMNLP.
Devlin, J., Chang, M.-W., Lee, K., & Toutanova, K. (2018). BERT: Pre-training of Deep Bidirectional Transformers for Language Understanding. arXiv:1810.04805.
