Warum Retrieval-Augmented Generation (RAG) scheitert und wie sich die Ergebnisse verbessern lassen

Retrieval-Augmented Generation (RAG) wird häufig eingesetzt, um Antworten von KI-Systemen zu verbessern, indem große Sprachmodelle mit externen Wissensquellen wie Dokumenten, Datenbanken und PDF-Dateien kombiniert werden. Grundsätzlich soll RAG dabei helfen, präzise, aktuelle und kontextbezogene Antworten bereitzustellen.

In der Praxis stellen jedoch viele Entwickler fest, dass ihre RAG-Implementierungen nicht wie gewünscht funktionieren. Statt hilfreicher Ergebnisse liefert das System mitunter irrelevante Inhalte, Halluzinationen, unvollständige Antworten oder veraltete Informationen. Das führt oft zu Frustration und Unsicherheit, insbesondere dann, wenn die technische Umsetzung auf den ersten Blick korrekt erscheint.

Tatsächlich scheitert RAG meist nicht an einem einzelnen großen Fehler. Häufig sind mehrere kleinere Schwächen in der Datenaufbereitung, der Qualität der Embeddings, der Retrieval-Logik, dem Prompt-Design und der Systemintegration dafür verantwortlich. Wer diese Schwachstellen erkennt, schafft die Grundlage für ein verlässliches RAG-System.

Wichtige Erkenntnisse

• RAG scheitert meist an schlechter Datenqualität und unzureichender Vorverarbeitung von Dokumenten.
• Ungeeignetes Chunking und minderwertige Embeddings verschlechtern die Präzision beim Retrieval.
• Eine schwache Retrieval-Strategie führt dazu, dass irrelevanter Kontext an das Modell übergeben wird.
• Schlechtes Prompt-Design verhindert, dass das Modell die abgerufenen Informationen sinnvoll nutzt.
• Fehlende Auswertung und Überwachung erschweren das Erkennen von Problemen.
• Schon kleine Optimierungen können die Qualität von RAG deutlich steigern.

So funktioniert RAG

Bevor man untersucht, warum RAG-Systeme scheitern, sollte man verstehen, wie sie grundsätzlich arbeiten. Eine typische RAG-Pipeline beginnt damit, Dokumente zu sammeln und in kleinere Abschnitte zu unterteilen. Diese Chunks werden anschließend mit Embedding-Modellen in numerische Vektoren umgewandelt. Danach werden die Vektoren in einer Vektordatenbank gespeichert. Stellt ein Nutzer eine Frage, wandelt das System auch diese Anfrage in einen Vektor um und sucht in der Datenbank nach ähnlichen Vektoren. Die relevantesten Chunks werden abgerufen und dem Prompt hinzugefügt, der an das Sprachmodell gesendet wird. Auf dieser Basis erstellt das Modell eine Antwort aus der Nutzerfrage und dem gefundenen Kontext.

Ist einer dieser Schritte schwach umgesetzt, fällt in der Regel auch die Qualität des Endergebnisses entsprechend schwach aus.

Wann RAG besser funktioniert als Fine-Tuning

Große Sprachmodelle sind leistungsfähig, haben aber auch klare Grenzen: Sie halluzinieren. Das bedeutet, dass sie Antworten mit großer Sicherheit formulieren können, obwohl diese sachlich falsch sind. Der Grund dafür ist, dass die Modelle nicht alles wirklich verstehen. Sie erkennen Muster und erzeugen Antworten auf Basis dessen, was sie während des Trainings gelernt haben. Wenn private Daten, interne Dokumente oder proprietäres Wissen nicht Teil dieses Trainings waren, hat das Modell keinen direkten Zugriff darauf. In solchen Fällen beginnt es zu raten, anstatt präzise zu antworten. Eine mögliche Lösung dafür ist Fine-Tuning.

Fine-Tuning bedeutet, ein Modell mit eigenen Daten nachzutrainieren, damit es die gewünschten Inhalte direkt erlernt. Dieser Ansatz kann die Genauigkeit verbessern, ist in realen Umgebungen jedoch schwer zu handhaben. Er erfordert teure GPU-Ressourcen, lange Trainingszyklen und eine saubere Verwaltung von Modellständen und Checkpoints. Jedes Mal, wenn sich die Datenbasis ändert, muss das Modell möglicherweise erneut trainiert werden. Auf Dauer wird die Pflege mehrerer Modellversionen teuer und operativ aufwendig. Fine-Tuning reduziert zwar die Notwendigkeit, ständig Kontext in Prompts mitzugeben, lässt sich aber nur schwer skalieren und warten.

Retrieval-Augmented Generation, kurz RAG, verfolgt einen praktischeren Ansatz. Statt das Modell selbst zu verändern, wird verändert, wie Informationen an das Modell übergeben werden. Das Modell bleibt unverändert. Anstatt zu versuchen, dass es sich alles merkt, ermöglicht RAG dem Modell, genau die Informationen abzurufen, die es in dem Moment zur Beantwortung einer Frage benötigt. Dadurch ist das Modell nicht mehr nur auf sein internes Wissen beschränkt, sondern kann mit echten und aktuellen Daten arbeiten.

Eine einfache Möglichkeit, RAG zu verstehen, ist der Vergleich mit einer Open-Book-Prüfung. Man stelle sich einen Studenten vor, der versucht, ein ganzes Lehrbuch auswendig zu lernen. Wird das Buch aktualisiert, muss er alles erneut lernen. Dieser Student steht für Fine-Tuning. Nun stelle man sich einen zweiten Studenten vor, der das Buch mit in die Prüfung nehmen darf. Taucht eine Frage auf, sucht er die passende Stelle, liest sie nach und formuliert die Antwort in eigenen Worten. Dieser Student steht für RAG. Das Modell ruft also zuerst die passenden Informationen ab und erzeugt erst danach auf dieser Basis die Antwort. Es rät nicht zuerst, sondern liest zuerst und antwortet dann.

Die RAG-Pipeline Schritt für Schritt erklärt

Der RAG-Workflow beginnt damit, die Informationen zu sammeln, die das System nutzen können soll. Dazu können PDFs, Handbücher, Artikel, Datenbankinhalte, Dokumente oder andere relevante Quellen gehören. Gemeinsam bilden diese Ressourcen eine private Wissensbasis.

Da lange Dokumente nicht sinnvoll als Ganzes verarbeitet werden können, werden sie in kleinere Einheiten aufgeteilt. Dieser Schritt wird als Chunking bezeichnet. Idealerweise behandelt jeder Chunk ein einzelnes Thema oder eine konkrete Idee, damit das System ihn gezielter abrufen und verwenden kann.

Anschließend wird jeder Chunk in ein Embedding umgewandelt. Dabei handelt es sich um eine numerische Repräsentation der Bedeutung des Textes. Inhalte mit ähnlicher Bedeutung erhalten ähnliche Embeddings. Ausdrücke wie „training models on GPUs“ und „GPU-based model training“ liegen mathematisch daher nahe beieinander.

Die Embeddings werden in einer Vektordatenbank gespeichert. Anders als eine klassische Keyword-Suche kann diese Datenbank nach semantischer Ähnlichkeit suchen. Wenn ein Nutzer eine Frage stellt, wird auch diese Frage in ein Embedding umgewandelt.

Das System vergleicht anschließend dieses Frage-Embedding mit den gespeicherten Embeddings und ruft die relevantesten Chunks ab. Dieser Retrieval-Schritt konzentriert sich auf Bedeutung und Absicht, statt nur exakte Wörter abzugleichen.

Danach werden die ausgewählten Chunks zur Eingabe des Modells hinzugefügt. Dies wird häufig als Synthese bezeichnet. Das Modell erhält sowohl die Nutzerfrage als auch den abgerufenen unterstützenden Kontext und erzeugt auf dieser Grundlage eine Antwort, anstatt sich ausschließlich auf sein internes Wissen zu stützen.

Viele RAG-Implementierungen ergänzen Guardrails, um das Verhalten des Modells zu steuern. Diese Regeln helfen sicherzustellen, dass Antworten nur dann gegeben werden, wenn sie durch die abgerufenen Inhalte gestützt werden. Ist die benötigte Information beispielsweise nicht verfügbar, kann das System angewiesen werden, mit „Ich weiß es nicht“ zu antworten, statt zu raten. Dadurch werden RAG-Systeme zuverlässiger.

RAG ist effektiv, weil es mehrere praktische Herausforderungen gleichzeitig löst. Neue Informationen können hinzugefügt werden, ohne das Modell erneut zu trainieren. Werden Quelldokumente aktualisiert, kann die Vektordatenbank einfach neu befüllt oder aktualisiert werden. Dadurch entfallen Kosten und Aufwand für erneutes Training oder erneutes Deployment großer Modelle, während gleichzeitig der GPU-Bedarf im Vergleich zum Fine-Tuning sinkt und Teams schneller iterieren können. Da Antworten auf tatsächlichen Dokumenten basieren, hilft RAG außerdem, Halluzinationen zu reduzieren.

Ein einfacher Vergleich zwischen Fine-Tuning und RAG ist Navigation: Fine-Tuning ist wie das Auswendiglernen jeder Straße in einer Stadt. Sobald sich das Straßennetz ändert, kann dieses Wissen veraltet sein. RAG ist eher wie die Nutzung eines GPS, weil bei jeder Anfrage aktuelle Informationen geprüft werden. Deshalb setzen viele KI-Systeme auf RAG, um präzise, anpassungsfähig und aktuell zu bleiben, ohne ständig neu trainiert werden zu müssen.

RAG vs. Fine-Tuning vs. Prompt Engineering

Um den Unterschied zwischen RAG, Fine-Tuning und Prompt Engineering besser zu verstehen, hilft das Bild eines sehr intelligenten Schülers mit guter Allgemeinbildung, der aber nicht alles weiß.

Prompt Engineering: Bessere Anweisungen geben

Prompt Engineering lässt sich damit vergleichen, dem Schüler bessere Fragen zu stellen.

Fragt man:

„Erzähl mir etwas über den Klimawandel.“

dann erhält man womöglich eine eher allgemeine Antwort.

Formuliert man stattdessen:

„Erkläre den Klimawandel in einfachen Worten mit aktuellen Beispielen.“

dann fällt die Antwort meist klarer und nützlicher aus.

Das Wissen des Schülers hat sich dabei nicht verändert. Verbessert wurde nur die Art der Kommunikation. Vereinfacht gesagt bedeutet Prompt Engineering, die Eingabe so zu gestalten, dass das Modell genau versteht, was gewünscht ist. Dieser Ansatz ist schnell, kostengünstig und leicht zu testen, kann dem Modell jedoch kein neues Wissen vermitteln.

Fine-Tuning: Spezialisiertes Training für den Schüler

Fine-Tuning ähnelt dem Besuch eines spezialisierten Trainingsprogramms. Nach diesem Training ist der Schüler in einem bestimmten Bereich besonders kompetent, etwa bei medizinischen Begriffen, juristischen Texten oder im Kundensupport. Werden anschließend passende Fragen gestellt, antwortet er besser, weil dieses Wissen fest verankert wurde. Kommen jedoch neue Inhalte hinzu, muss erneut trainiert werden. Das kostet Zeit, Geld und Aufwand. In KI-Systemen bedeutet Fine-Tuning, ein Modell mit eigenen Daten nachzutrainieren, um die Leistung in einem bestimmten Fachgebiet zu verbessern. Verhalten und Stil lassen sich dadurch optimieren, die Aktualisierung des Wissens bleibt jedoch teuer.

RAG: Dem Schüler Zugang zu einer Bibliothek geben

RAG ist so, als würde der Schüler während der Prüfung Zugang zu einer gut organisierten Bibliothek erhalten. Statt sich allein auf sein Gedächtnis zu verlassen, kann er kurz die neuesten Bücher und Unterlagen prüfen, bevor er antwortet. So bleibt er auch dann präzise, wenn sich Informationen verändert haben. Im KI-Kontext bedeutet das: RAG verbindet das Modell mit externen Dokumenten, Datenbanken oder Wissensspeichern. Bevor eine Antwort erzeugt wird, ruft das System passende Informationen ab und nutzt sie als Referenz. Dadurch eignet sich RAG besonders gut für dynamische, große und häufig aktualisierte Datenbestände.

Wann Fine-Tuning sinnvoll ist und wann RAG die bessere Wahl ist

Die Entscheidung zwischen Fine-Tuning und Retrieval-Augmented Generation (RAG) gehört zu den wichtigsten Fragen beim Aufbau eines KI-Systems. Beide Ansätze können die Leistung eines Modells verbessern, lösen jedoch unterschiedliche Probleme. Wer weiß, wann welcher Ansatz sinnvoll ist, kann Systeme entwickeln, die präzise, skalierbar und kosteneffizient sind.

Wann Fine-Tuning die bessere Wahl ist

Fine-Tuning eignet sich besonders dann, wenn verändert werden soll, wie sich ein Modell verhält, und nicht in erster Linie, was es weiß. Dabei wird das Modell mit eigenen Daten trainiert, damit es einen gewünschten Tonfall, Schreibstil, ein bestimmtes Ausgabeformat oder domänenspezifische Muster übernimmt.

Fine-Tuning ist sinnvoll, wenn:

Fine-Tuning sollte in Betracht gezogen werden, wenn:

• ein konsistenter Ton und eine einheitliche Markenkommunikation erforderlich sind,
• strukturierte Ausgaben wie JSON, Berichte oder Vorlagen benötigt werden,
• in einem spezialisierten Bereich mit stabilem Wissen gearbeitet wird,
• möglichst vorhersehbare Antworten gewünscht sind,
• sich die zugrunde liegenden Daten nur selten ändern.

Beim Fine-Tuning wird ein Modell wie Llama oder Mistral mit einem eigenen Datensatz nachtrainiert. Dabei werden die Gewichte des neuronalen Netzwerks auf Basis dieser Daten angepasst. Das Ergebnis ist ein Modell, dessen Antworten stärker auf die eigenen Inhalte abgestimmt sind.

Beispiel: Chatbot für den Kundensupport

Problem

Ein Unternehmen betreibt einen Chatbot im Kundensupport. Zwar liefert dieser oft korrekte Antworten, aber sein Tonfall ist uneinheitlich. Manche Antworten wirken zu technisch oder unnatürlich, Markenrichtlinien werden nicht immer eingehalten und die Reaktionen unterscheiden sich zu stark.

Lösung: Fine-Tuning

Das Unternehmen sammelt hochwertige Support-Konversationen und trainiert das Modell damit nach. Nach dem Fine-Tuning formuliert der Chatbot seine Antworten im Stil des Unternehmens. Der Ton wirkt freundlicher und konsistenter, außerdem hält sich das System zuverlässiger an vorgegebene Antwortvorlagen. Dadurch verhält sich der Chatbot eher wie ein geschulter Support-Mitarbeiter. In diesem Fall ist RAG weniger hilfreich, weil es primär um ein einheitliches Verhalten und nicht um dynamisches Wissen geht.

Wann RAG (Retrieval-Augmented Generation) eingesetzt werden sollte

RAG ist die bessere Wahl, wenn ein System auf externe, sich verändernde oder private Informationen angewiesen ist. Statt Wissen im Modell selbst zu speichern, ruft RAG dieses in Echtzeit aus Datenbanken, Dateien oder APIs ab. Vereinfacht gesagt sorgt RAG dafür, dass das Modell genau dann Zugriff auf Informationen erhält, wenn es sie benötigt.

RAG ist sinnvoll, wenn:

RAG sollte verwendet werden, wenn:

• sich die Daten häufig ändern,
• mit internen Dokumenten gearbeitet wird,
• große Datenmengen verarbeitet werden müssen,
• nachvollziehbare Quellen benötigt werden,
• aktuelle Antworten gefragt sind,
• häufiges Retraining nicht möglich ist.

Bei RAG bleibt das Wissen außerhalb des Modells und kann unabhängig davon aktualisiert werden.

Beispiel: Interner Wissensassistent

Ein Unternehmen möchte einen KI-Assistenten für Mitarbeitende bereitstellen, der Fragen zu folgenden Themen beantwortet:

• HR-Richtlinien
• Urlaubsregelungen
• Projektdokumentation
• Technische Handbücher

Diese Dokumente werden monatlich aktualisiert.

Würde das Unternehmen hier auf Fine-Tuning setzen, müsste das Modell bei jeder Änderung der Dokumente erneut trainiert werden. Das würde Kosten verursachen und Verzögerungen mit sich bringen, während veraltete Richtlinien unter Umständen weiterhin im Modell verankert blieben. In diesem Fall ist RAG die bessere Lösung. Sämtliche Dokumente werden in einer Vektordatenbank gespeichert.

Fragt ein Mitarbeiter dann:

„Wie lautet die aktuelle Homeoffice-Regelung?“

dann führt das System folgende Schritte aus:

• Es durchsucht die HR-Dokumente.
• Es ruft die aktuellste Richtlinie ab.
• Es übergibt diese an das LLM.
• Es erzeugt daraus die Antwort.

Ergebnis

Die Antworten bleiben aktuell, ohne dass ein erneutes Training notwendig ist.

Eine einfache Faustregel lautet:

Fine-Tuning steuert, wie das Modell antwortet. RAG steuert, was das Modell weiß.

Wenn das Hauptproblem im Verhalten liegt, ist Fine-Tuning die bessere Wahl. Wenn es vor allem um Wissen geht, ist RAG sinnvoller. Wenn beides wichtig ist, lassen sich beide Ansätze kombinieren.

Häufige Gründe, warum ein RAG-System schwache Ergebnisse liefert

Viele Entwickler gehen davon aus, dass es genügt, Dokumente in eine Vektordatenbank zu laden, um ein leistungsfähiges RAG-System zu erhalten. In der Realität ist deutlich mehr erforderlich. Eine starke RAG-Pipeline hängt davon ab, wie gut Dokumente vorbereitet werden, wie präzise sie abgerufen werden und wie effektiv der passende Kontext an das Sprachmodell übergeben wird. Ohne sauberes Chunking, gutes Ranking, Evaluation und Monitoring können selbst sehr leistungsfähige Modelle unzuverlässige Antworten liefern. Wer diese verborgenen Schwächen versteht, kann Systeme entwickeln, die auch im produktiven Einsatz stabil funktionieren.

Schlechte Datenqualität und eine unvollständige Wissensbasis

Einer der häufigsten Gründe für schwache RAG-Ergebnisse sind schlechte Eingangsdaten. Sind die Dokumente veraltet, unvollständig, schlecht strukturiert oder voller Störinformationen, ruft das System entsprechend minderwertige Inhalte ab. Ein Sprachmodell kann keine präzisen Antworten erzeugen, wenn das Ausgangsmaterial selbst unzuverlässig ist. Viele Entwickler versäumen es außerdem, ihre Wissensbasis regelmäßig zu aktualisieren. Mit der Zeit erscheinen dadurch veraltete Informationen in den Antworten. In manchen Fällen werden Dokumente direkt aus Webseiten oder PDF-Dateien übernommen, ohne sie zu bereinigen. Das führt zu fehlerhaftem Formatierungsballast, wiederholten Überschriften und irrelevanten Metadaten. Genau solche Elemente verschlechtern die Retrieval-Qualität.

Wenn die Datenbasis schwach ist, kann selbst das beste Modell das nicht ausgleichen.

Ungeeignete Strategie beim Dokument-Chunking

Chunking bezeichnet das Zerlegen großer Dokumente in kleinere Teile, bevor sie eingebettet werden. Wird dieser Schritt schlecht umgesetzt, sinkt die Qualität des Retrievals deutlich. Sind Chunks zu groß, enthalten sie mehrere Themen gleichzeitig, was eine präzise Zuordnung erschwert. Sind sie zu klein, verlieren sie den Zusammenhang und werden zu isolierten Fragmenten mit wenig Aussagekraft. Beides verwirrt die Retrieval-Schicht. Ein weiterer häufiger Fehler besteht darin, Texte ohne Rücksicht auf Satzgrenzen oder logische Abschnitte zu teilen. Dadurch entstehen unnatürliche Chunks, die die semantische Klarheit schwächen. Ohne sauberes Chunking wird relevante Information oft nicht gefunden, obwohl sie in der Datenbank vorhanden ist.

Minderwertige oder unpassende Embeddings

Embeddings sind dafür zuständig, Texte in numerische Darstellungen umzuwandeln. Passt das verwendete Embedding-Modell nicht zum Fachgebiet der Daten, wird die Ähnlichkeitssuche unzuverlässig. Wird beispielsweise ein allgemeines Embedding-Modell für medizinische, juristische oder technische Inhalte eingesetzt, entstehen oft schwache semantische Repräsentationen. Die Folge ist ein schlechtes Matching zwischen Nutzerfragen und gespeicherten Inhalten. Problematisch ist auch das Vermischen verschiedener Embedding-Modelle innerhalb derselben Datenbank, da dadurch Inkonsistenzen entstehen. Das System kann relevante Inhalte dann unter Umständen nicht zuverlässig abrufen, weil die Vektoren nicht sinnvoll vergleichbar sind. Die Qualität der Embeddings beeinflusst die Präzision des Retrievals unmittelbar.

Schwache Retrieval- und Ranking-Mechanismen

Retrieval bedeutet nicht nur, ähnliche Vektoren zu finden. Ebenso wichtig ist es, diese Ergebnisse korrekt zu gewichten. Viele RAG-Systeme verlassen sich ausschließlich auf einfache Similarity-Scores, was oft nicht ausreicht. Manchmal werden Inhalte abgerufen, die nur teilweise relevant sind. In anderen Fällen fehlt entscheidender Kontext, weil die Top-k-Ergebnisse schlecht sortiert sind. Ohne Re-Ranking, Filterlogik oder hybride Suchverfahren wird das Retrieval unzuverlässig. Hinzu kommt ein weiteres Problem: Es werden entweder zu viele oder zu wenige Dokumente abgerufen. Zu viele Dokumente überladen den Prompt und verwirren das Modell. Zu wenige Dokumente liefern nicht genug Kontext und erhöhen das Risiko von Halluzinationen. Ein ausgewogenes Retrieval ist daher zentral für eine gute RAG-Leistung.

Schwaches Prompt Engineering und schlechte Kontextformatierung

Selbst wenn das Retrieval gut funktioniert, kann das Modell scheitern, wenn der Prompt schlecht gestaltet ist. Das Sprachmodell benötigt klare Anweisungen dazu, wie die abgerufenen Inhalte zu verwenden sind. Trennt der Prompt den Kontext nicht sauber von der eigentlichen Frage, übersieht das Modell möglicherweise wichtige Informationen. Sind die Instruktionen zu vage, greift das Modell eher auf sein internes Wissen zurück, statt die bereitgestellten Dokumente zu nutzen. Ein weiteres Problem ist die Überladung des Prompts. Wenn zu viel Text eingefügt wird, gehen wichtige Details im Gesamtumfang unter. Das Modell hat dann Schwierigkeiten, das Wesentliche zu erkennen. Starkes Prompt-Design ist deshalb ein entscheidender Erfolgsfaktor für RAG.

Grenzen des Modells und Beschränkungen des Kontextfensters

Jedes Sprachmodell kann nur eine begrenzte Menge an Kontext gleichzeitig verarbeiten. Werden Prompt, abgerufene Inhalte und Anweisungen zu lang, können Teile der Eingabe abgeschnitten oder ignoriert werden. Dadurch können Antworten unvollständig oder ungenau ausfallen.

Kleinere Modelle haben zudem häufig Schwierigkeiten, Zusammenhänge über sehr lange Kontextfenster hinweg korrekt zu erfassen. Selbst wenn die richtigen Dokumente bereitgestellt werden, kann es vorkommen, dass das Modell die enthaltenen Informationen nicht korrekt miteinander verknüpft. Für anspruchsvolle RAG-Anwendungsfälle kann ein Modell mit begrenzten Fähigkeiten daher zu schwachen oder unzuverlässigen Ergebnissen führen.

Fehlende Evaluation und kontinuierliche Verbesserung

Viele Teams bauen RAG-Systeme und bewerten sie anschließend nicht systematisch. Ohne Benchmarks, Feedback-Schleifen und Testdatensätze ist es sehr schwer zu verstehen, was tatsächlich schiefläuft. Probleme werden häufig erst sichtbar, wenn sich Nutzer beschweren. Dann ist es wesentlich schwieriger, die eigentliche Ursache zu identifizieren. Werden Retrieval-Qualität, Halluzinationsrate und Antwortqualität nicht überwacht, wird Optimierung zum Rätselraten. RAG-Systeme benötigen laufende Weiterentwicklung und nicht nur eine einmalige Einrichtung.

Strategien zur Verbesserung der RAG-Leistung

Ein leistungsfähiges Retrieval-Augmented-Generation-System entsteht nicht allein dadurch, dass eine Datenbank mit einem LLM verbunden wird. Um präzise, verlässliche und kontextbezogene Antworten zu liefern, setzen moderne RAG-Pipelines auf mehrere fortgeschrittene Verfahren. Diese Methoden verbessern, wie Dokumente abgerufen, sortiert, verarbeitet und bewertet werden, bevor sie das Sprachmodell erreichen.

Re-Ranking für höhere Präzision

In vielen RAG-Workflows ist die erste Retrieval-Phase darauf optimiert, Ergebnisse möglichst schnell zurückzugeben – nicht unbedingt darauf, sie perfekt nach Relevanz zu sortieren. Dadurch enthalten die zunächst abgerufenen Chunks nicht immer die relevantesten Informationen.

Re-Ranking hilft, dieses Problem zu lösen, indem nach dem Retrieval ein leistungsfähigeres Modell eingesetzt wird, das die ausgewählten Chunks erneut bewertet und nach ihrer Relevanz sortiert. So wird der hilfreichste Kontext an die oberste Stelle gesetzt, was die Qualität der Antworten verbessern und das Risiko von Halluzinationen verringern kann.

Zwar verursacht Re-Ranking zusätzlichen Rechenaufwand, es ist jedoch besonders wertvoll in Anwendungsfällen, bei denen eine hohe Genauigkeit entscheidend ist.

from sentence_transformers import CrossEncoder

reranker = CrossEncoder("cross-encoder/ms-marco-MiniLM-L-6-v2")

def rerank(query, chunks, top_k=5):
    pairs = [(query, chunk) for chunk in chunks]
    scores = reranker.predict(pairs)

    ranked = sorted(
        zip(chunks, scores),
        key=lambda x: x[1],
        reverse=True
    )

    return [chunk for chunk, _ in ranked[:top_k]]

Agentic RAG für intelligenteres Retrieval

Agentic RAG ermöglicht es dem System, sich wie ein intelligenter Assistent zu verhalten, der selbst entscheidet, wie Informationen abgerufen werden sollen. Statt einer festen Suchmethode analysiert ein Agent die Anfrage und wählt die passenden Werkzeuge aus, zum Beispiel Vektorsuche, Schlagwortsuche, Websuche oder Datenbankabfragen.

Dieser Ansatz ist besonders nützlich, wenn Nutzerfragen komplex oder schwer vorhersehbar sind. Das System kann seine Strategie dynamisch anpassen, benötigt dafür aber auch komplexere Logik.

Knowledge Graphs für beziehungsbasiertes Schlussfolgern

In manchen Fachgebieten, etwa im Finanzwesen, in der Medizin oder in der Forschung, spielen Beziehungen zwischen Entitäten eine zentrale Rolle. Knowledge Graphs speichern Informationen als verbundene Knoten und Kanten und helfen dem RAG-System so, Beziehungen zwischen Konzepten besser zu verstehen.

Anstatt isolierte Chunks abzurufen, kann das System miteinander verbundene Fakten einbeziehen, was tieferes Schlussfolgern unterstützt. Der Aufbau und die Pflege eines solchen Wissensgraphen erfordern jedoch erhebliche Infrastruktur.

# Pseudocode

entities = extract_entities(query)
nodes = graph.find_nodes(entities)
neighbors = graph.expand(nodes)

context = collect_text(neighbors)
answer = llm.generate(query, context)

Query Expansion bei mehrdeutigen Fragen

Nutzerfragen sind häufig kurz oder unpräzise formuliert. Query Expansion unterstützt das Retrieval, indem mehrere alternative Formulierungen derselben Anfrage erzeugt werden. Diese Varianten geben dem System zusätzliche Möglichkeiten, relevante Inhalte zu finden. Dadurch kann der Recall verbessert werden, allerdings entstehen zusätzliche LLM-Aufrufe.

def expand_query(query, llm):

    prompt = f"Generate 3 search queries for: {query}"

    variants = llm.generate(prompt).split("\n")

    return variants


def expanded_search(query):

    queries = expand_query(query, llm)

    docs = []
    for q in queries:
        docs.extend(vector_search(q))

    return docs

Kontextuelles Retrieval für besonders wichtige Dokumente

Kontextuelles Retrieval verbessert die Genauigkeit, indem jeder Chunk bereits bei der Verarbeitung mit zusätzlichen Metadaten, Zusammenfassungen oder umgebendem Kontext angereichert wird. Dadurch wird jeder Chunk aussagekräftiger, wenn er später abgerufen wird. Diese Methode erhöht zwar die Kosten beim Indexieren, kann die Qualität des Retrievals bei besonders wertvollen Dokumenten jedoch deutlich verbessern.

def contextual_chunk(doc):

    summary = summarize(doc)

    chunks = split(doc)

    enriched = [
        f"Summary: {summary}\nContent: {c}"
        for c in chunks
    ]

    return enriched

Kontextbewusstes Chunking

Context-Aware Chunking teilt Dokumente nicht ausschließlich anhand einer festen Zeichen- oder Tokenanzahl auf. Stattdessen berücksichtigt es strukturelle Elemente wie Absätze, Überschriften und semantische Einheiten. Dadurch bleiben zusammengehörige Informationen häufiger erhalten, und die entstehenden Chunks sind inhaltlich leichter verständlich und sinnvoller nutzbar.

Der Nachteil besteht darin, dass die Verarbeitung beim Ingest etwas mehr Zeit in Anspruch nehmen kann. Dafür sind die erzeugten Chunks in der Regel qualitativ hochwertiger und für Retrieval-Aufgaben besser geeignet.

import nltk

def semantic_chunk(text):

    paragraphs = text.split("\n\n")

    chunks = []

    for p in paragraphs:
        if len(p) > 500:
            chunks.extend(nltk.sent_tokenize(p))
        else:
            chunks.append(p)

    return chunks

Selbstverbesserndes RAG

Selbstverbesserndes oder selbstreflektierendes RAG erlaubt es dem Modell, seine eigenen Antworten zu prüfen. Nachdem eine Antwort erzeugt wurde, bewertet das System diese auf Fehler, fehlende Informationen oder schwache Belege und generiert sie bei Bedarf erneut.

Gerade für Recherche- und Analyseaufgaben ist das besonders nützlich, auch wenn sich dadurch die Latenz erhöht.

def self_reflective_rag(query, context):

    answer = llm.generate(query, context)

    review = llm.generate(
        f"Check this answer for errors:\n{answer}"
    )

    if "incorrect" in review.lower():
        answer = llm.generate(query, context)

    return answer

FAQs

Ist RAG besser als Fine-Tuning?

RAG und Fine-Tuning lösen unterschiedliche Anforderungen. RAG eignet sich besser für dynamische und sich häufig ändernde Informationen, während Fine-Tuning sinnvoller ist, wenn bestimmte Stile oder Verhaltensweisen gelernt werden sollen. Viele Systeme kombinieren beide Ansätze.

Warum halluziniert mein RAG-System trotzdem noch?

Halluzinationen entstehen häufig dann, wenn die dem Modell bereitgestellten Informationen unvollständig, für die Frage irrelevant oder gar nicht vorhanden sind. Sie können außerdem durch ungeeignete Prompting-Strategien oder Retrieval-Systeme verursacht werden, die keinen ausreichend relevanten Kontext zur Unterstützung der Antwort liefern.

Wie viele Dokumente sollten pro Anfrage abgerufen werden?

Eine feste Zahl gibt es nicht, doch in vielen Fällen genügen drei bis acht hochwertige Chunks. Entscheidend ist die Relevanz und nicht die Menge.

Benötige ich für RAG zwingend eine Vektordatenbank?

Die meisten produktiv eingesetzten RAG-Systeme nutzen Vektordatenbanken, da sie die für größere Workloads erforderliche Geschwindigkeit und Skalierbarkeit bieten. Für Prototypen oder kleinere Umgebungen kann jedoch auch eine In-Memory-Suche eine praktikable Alternative sein.

Kann RAG offline eingesetzt werden?

Ja. RAG kann vollständig lokal betrieben werden, wenn die Dokumente auf eigener Infrastruktur gespeichert und das Modell On-Premises ausgeführt wird. Der Nachteil besteht darin, dass Updates, Wartung und Skalierung in der Regel komplexer werden.

Was sind die häufigsten Gründe dafür, dass RAG-Systeme scheitern?

1. Veraltetes Wissen

Wenn Dokumente aktualisiert werden, kann das System trotzdem noch auf ältere Inhalte zugreifen.

Lösung: Dokumentänderungen sollten nachverfolgt und der Index automatisch aktualisiert werden.

2. Nachlassende Suchgenauigkeit

Mit wachsender Datenmenge wird es schwieriger, die relevantesten Treffer zu finden.

Lösung: Eine Kombination aus schlüsselwortbasierter und semantischer Suche verbessert das Retrieval.

3. Minderwertiger Kontext als Eingabe

Schlecht strukturierte Chunks können den Kontext des Modells mit irrelevanten Informationen füllen und dadurch die Genauigkeit der Antworten verringern.

Lösung: Verwende gut strukturierte Chunks, filtere qualitativ minderwertige Treffer heraus und verdichte die abgerufenen Inhalte, bevor die Antwort generiert wird.

4. Fehlendes Performance-Monitoring

Ohne eine konsistente Erfolgsmessung können Fehler und Schwachstellen im praktischen Einsatz unentdeckt bleiben.

Lösung: Bewerte die Antworten kontinuierlich anhand geeigneter Metriken für Qualität, Genauigkeit und Zuverlässigkeit.

Wie oft sollte eine Wissensbasis aktualisiert werden?

Das hängt vom jeweiligen Einsatzgebiet ab. In schnelllebigen Bereichen können tägliche oder wöchentliche Updates nötig sein. Bei eher statischen Inhalten reicht oft eine monatliche Aktualisierung.

Fazit

RAG kann äußerst effektiv sein, sollte jedoch nicht als automatische Universallösung betrachtet werden. Wenn ein RAG-System schlechte Ergebnisse liefert, liegt die Ursache meist irgendwo in der Pipeline: Die Quelldaten können von geringer Qualität sein, die Chunks ungeeignet strukturiert, die Embeddings unpassend gewählt, das Retrieval ungenau, die Prompts ineffektiv oder das Monitoring unzureichend. In vielen Fällen ist nicht das Modell selbst das Hauptproblem, sondern das umgebende System.

Entwickler können Genauigkeit und Zuverlässigkeit verbessern, indem sie RAG als vollständigen Workflow betrachten und nicht als Funktion, die sich einfach hinzufügen und anschließend ignorieren lässt. Eine durchdachte Architektur, regelmäßige Tests und kontinuierliche Optimierung sind entscheidend, um dauerhaft gute Ergebnisse zu erzielen.

Richtig umgesetzt hilft RAG dabei, KI-Anwendungen zuverlässiger zu machen und Antworten stärker auf relevantes Wissen zu stützen. Schlecht implementiert kann es jedoch ebenso viele Probleme verursachen, wie es lösen soll. Zu verstehen, warum ein RAG-System scheitert, ist daher der erste Schritt auf dem Weg zu einer besseren Lösung.