Ein Unternehmen besitzt tausend aktuelle Dokumente und trotzdem beantwortet sein KI-Assistent eine einfache Richtlinienfrage falsch. Das Sprachmodell ist nicht zwingend das Problem. Vielleicht wurde die richtige Passage nie gefunden, eine alte Version höher gerankt oder ein Dokument abgerufen, das der fragende Nutzer gar nicht sehen dürfte. RAG mit eigenen Dokumenten beginnt deshalb nicht beim Chatfenster. Es beginnt bei der Frage, welche Evidenz das System zur richtigen Zeit finden und verwenden darf.
Retrieval-Augmented Generation, kurz RAG, verbindet ein Sprachmodell zur Laufzeit mit einer externen Wissensbasis. Das kann Antworten aktueller und nachvollziehbarer machen, ohne die Modellgewichte neu zu trainieren. Es garantiert aber keine Wahrheit. RAG verschiebt einen Teil des Fehlerrisikos aus dem Modell in Suche, Dokumentpflege, Rechte und Kontextauswahl. Genau dort entscheidet sich, ob ein nützlicher Wissensassistent oder bloss eine freundlichere Oberfläche für schlechte Suche entsteht.
Was RAG ist und was es nicht ist
Die ursprüngliche RAG-Architektur von Lewis und Kollegen koppelte ein generatives Modell mit einem externen, nichtparametrischen Speicher. Vereinfacht läuft das System in drei Schritten. Zuerst werden Dokumente vorbereitet und durchsuchbar gemacht. Dann ruft ein Retriever zur Nutzerfrage passende Passagen ab. Schliesslich erhält das Sprachmodell diese Passagen als Kontext und formuliert daraus eine Antwort.
Der entscheidende Unterschied zu einem normalen Chatmodell liegt im Zeitpunkt. Trainingswissen steckt in den Modellgewichten und lässt sich nach dem Training nicht wie eine Dokumentablage aktualisieren. RAG führt Wissen bei jeder Anfrage neu zu. Eine geänderte Richtlinie steht nach ihrer Indexierung ohne neuen Trainingslauf für das Retrieval bereit. Ob sie tatsächlich in der Antwort landet, hängt weiterhin von Ranking, Rechten und Kontextauswahl ab.
RAG ist jedoch nicht gleichbedeutend mit einer Vektordatenbank. Ein System kann klassische Volltextsuche, Metadatenfilter, SQL-Abfragen, einen bestehenden Suchindex, semantische Vektorsuche oder eine Kombination daraus verwenden. Für Produktnummern, exakte Paragrafen und Eigennamen ist lexikalische Suche oft stark. Für unterschiedlich formulierte Fragen kann semantische Suche helfen. Welche Speicher- und Sucharchitektur dafür genügt, behandelt der separate DeepDive zu Vector Databases und Retrieval-Qualität.
Die Kurzentscheidung: Wann RAG sinnvoll ist
RAG lohnt sich, wenn Wissen ausserhalb des Modells liegt und zur Laufzeit austauschbar bleiben muss. Typische Fälle sind interne Richtlinien, technische Dokumentation, Produktinformationen, Verträge, Forschungsbestände oder Supportwissen. Besonders stark ist der Ansatz, wenn Antworten auf konkrete Quellen zurückgeführt werden sollen und Dokumente regelmässig wechseln.
Nicht jede Dokumentaufgabe braucht RAG. Bei wenigen kurzen Dateien kann ein ausreichend grosses Kontextfenster genügen. Für eine klar strukturierte Tabelle ist eine SQL-Abfrage meist zuverlässiger als semantische Suche. Wenn Nutzer eigentlich nur bekannte Dokumente finden wollen, kann eine gute klassische Suche das bessere Produkt sein. Und wenn das Problem im Verhalten des Modells liegt, etwa in Format, Ton oder einer wiederkehrenden Klassifikationsaufgabe, adressiert Fine-Tuning eine andere Ebene.
Eine belastbare Vorentscheidung beantwortet vier Fragen: Ändert sich das Wissen häufig? Muss jede Antwort belegbar sein? Darf nicht jeder Nutzer jedes Dokument sehen? Ist der Bestand zu gross oder zu dynamisch, um ihn bei jeder Anfrage vollständig in den Kontext zu legen? Je häufiger die Antwort Ja lautet, desto plausibler wird RAG.
RAG, langer Kontext und Fine-Tuning lösen verschiedene Probleme
Grosse Kontextfenster haben RAG nicht überflüssig gemacht. Sie erlauben, mehr Material direkt an ein Modell zu senden. Doch Kapazität ist nicht dasselbe wie zuverlässige Nutzung. Die peer-reviewte Studie «Lost in the Middle» zeigte, dass Modelle relevante Informationen je nach Position im langen Kontext unterschiedlich gut verwenden. Dazu kommen Kosten, Latenz und die Frage, ob ein Nutzer den gesamten Dokumentbestand überhaupt sehen darf.
Langer Kontext ist sinnvoll, wenn der relevante Bestand klein, bereits ausgewählt und in einer Anfrage vollständig interpretierbar ist. RAG wird wichtiger, sobald erst entschieden werden muss, welche Passagen aus einem grösseren oder laufend aktualisierten Korpus in den Kontext gehören.
Fine-Tuning verändert dagegen Modellgewichte. Es eignet sich für wiederkehrendes Verhalten, Ausgabeformate, Stil oder aufgabenspezifische Muster. Als Dokumentablage ist es schlecht kontrollierbar: Einzelne Fakten lassen sich nicht einfach löschen, versionieren oder mit einer Quelle versehen. RAG und Fine-Tuning können kombiniert werden, doch die Rollen sollten getrennt bleiben. Das eine wählt Evidenz aus, das andere verändert Modellverhalten.
Fünf Fehlerquellen: Warum RAG trotz guter Modelle scheitert
Der häufigste Fehler liegt vor der Generierung. Ist die Wissensbasis veraltet, widersprüchlich oder schlecht strukturiert, kann der Retriever keine verlässliche Evidenz liefern. Ein Sprachmodell formuliert schlechte Treffer lediglich flüssiger. Deshalb braucht jedes Dokument einen nachvollziehbaren Status: Quelle, Version, Gültigkeit, Eigentümer und gegebenenfalls Ablaufdatum.
Beim Chunking entsteht der nächste Verlust. Zu kleine Abschnitte trennen Aussagen von Voraussetzungen oder Ausnahmen. Zu grosse Abschnitte bringen viel irrelevanten Text in den Kontext. Starre Zeichenzahlen sind ein Startwert, keine allgemeine Lösung. Vertrag, Handbuch und Ticketsystem verlangen unterschiedliche Schnitte und Metadaten.
Auch semantische Ähnlichkeit ist noch keine Relevanz. Eine Passage kann sprachlich sehr ähnlich klingen und trotzdem die falsche Produktversion, Rechtsordnung oder Abteilung betreffen. Hybrid Search, Metadatenfilter und Re-Ranking können helfen. Sie ersetzen aber kein Testset mit echten Fragen und erwarteten Belegstellen.
Schliesslich kann das Modell gute Quellen ignorieren, falsch verbinden oder über deren Aussage hinausgehen. Ein RAG-System braucht deshalb Regeln für Zitate, Unsicherheit und Fälle ohne ausreichende Evidenz. Eine ehrliche Antwort wie «In den freigegebenen Dokumenten finde ich dafür keinen Beleg» ist oft wertvoller als eine vollständige klingende Vermutung.
Zitate sind dabei mehr als Dekoration. Ein Link auf das richtige Dokument beweist noch nicht, dass der zitierte Abschnitt die konkrete Antwort trägt. Gute Systeme speichern deshalb Herkunft und Position jeder Passage, zeigen die tatsächlich verwendete Stelle und prüfen, ob Behauptung und Beleg zusammenpassen. Fehlt diese Verbindung, sollte die Antwort als unbelegt gelten, auch wenn ihre Formulierung plausibel klingt.
Signal der Woche abonnieren
Eine Nachricht. Eine Analyse. Jeden Freitag im Newsletter.
Kostenlos als Member. Gratis abonnieren
Rechte und Sicherheit beginnen vor dem Prompt
Ein RAG-System darf dem Modell nur Material zuführen, das der fragende Nutzer auch ohne KI sehen dürfte. Kein unberechtigter Chunk darf Prompt, Logs oder Antwort erreichen. Autorisierungsbewusstes Retrieval ist dafür die robusteste Ausgangslage; eine verlässlich durchgesetzte Schutzgrenze zwischen Suche und Modellkontext kann ebenfalls filtern. Zugriffskontrolle muss an Dokument, Index und Query gebunden sein und bei Rollenwechseln oder Löschungen zuverlässig nachgeführt werden.
Auch die Quellen selbst sind eine Angriffsfläche. OWASP führt Prompt Injection weiterhin als zentrales Risiko generativer Systeme. Eine versteckte Anweisung in einer Webseite, einem PDF oder einem Supportticket kann über Retrieval in den Modellkontext gelangen. Das Modell muss Daten und Instruktionen unterscheiden, doch diese Trennung ist technisch nicht perfekt. Der DeepDive zu Prompt Injection und Agentensicherheit zeigt, warum bessere System-Prompts allein das Architekturproblem nicht lösen. Vertrauenszonen, Quellenfreigabe, minimale Toolrechte und Tests mit manipulierten Dokumenten bleiben nötig.
Auch die Aufbereitung verdient einen eigenen Test. OCR-Fehler, verlorene Tabellenüberschriften, abgeschnittene Fussnoten oder falsch erkannte Spalten können den Inhalt verändern, bevor die Suche beginnt. Stichproben müssen deshalb nicht nur Trefferlisten, sondern auch die extrahierten Passagen mit dem Original vergleichen. Sonst bewertet das Team einen Retriever gegen einen bereits beschädigten Korpus.
Lokaler Betrieb reduziert je nach Architektur die Weitergabe an externe Anbieter. Er schafft aber keine automatische Sicherheit. Ein lokaler Index ohne saubere Rechte, Löschung und Protokollierung kann vertrauliche Inhalte ebenso falsch ausliefern. Entscheidend ist der gesamte Datenweg von der Quelle über Index und Retriever bis zum Modell und zur Antwort.
RAG getrennt messen: Suche und Antwort
Wer nur die fertige Antwort bewertet, weiss bei einem Fehler nicht, welche Komponente versagt hat. Hat der Retriever die richtige Passage gefunden? Lag sie unter den ersten Treffern? Wurde sie durch Duplikate verdrängt? Hat das Modell den gelieferten Beleg korrekt verwendet? Diese Fragen brauchen getrennte Messungen.
Für Retrieval beginnt die Evaluation mit einem Goldset aus realen Nutzerfragen und erwarteten Dokumentstellen. Recall@k misst, ob relevante Passagen unter den ersten Treffern auftauchen. MRR und NDCG berücksichtigen zusätzlich deren Position beziehungsweise abgestufte Relevanz. Der BEIR-Benchmark zeigt, wie stark Retrieval über Domänen und Fragetypen variiert. Ein öffentliches Benchmarkresultat ersetzt deshalb keinen Test am eigenen Korpus.
Die Antwortseite prüft Quellenbezug, Vollständigkeit, Widerspruchsfreiheit und korrektes Nichtwissen. RAGChecker ist ein Beispiel für einen komponentenbezogenen Evaluationsansatz; die Arbeit erschien zunächst als Preprint und sollte als Methodenrahmen, nicht als universelles Gütesiegel gelesen werden. In der Praxis zählt, ob sich ein Fehler reproduzierbar dem Korpus, Retrieval oder Generator zuordnen lässt.
Monitoring gehört danach in den Betrieb. Dokumentänderungen, neue Modellversionen oder ein anderes Embedding-Modell können die Trefferverteilung verschieben. Ein einmal grünes Testset ist keine dauerhafte Garantie.
So startet ein RAG-Projekt ohne Toolzirkus
Der erste Schritt beginnt mit einem begrenzten Bestand und klaren Eigentümern, nicht mit einem Framework. Ein Team wählt eine Dokumentklasse, entfernt veraltete Versionen, definiert Rechte und sammelt echte Nutzerfragen. Erst danach werden Chunking und Retrieval gebaut.
Der zweite Schritt ist eine Baseline. Klassische Stichwortsuche und einfache Metadatenfilter sollten gegen semantisches oder hybrides Retrieval antreten. Wenn die einfache Suche das Goldset bereits zuverlässig löst, gibt es keinen Preis für zusätzliche Architektur.
Der dritte Schritt verbindet Treffer mit Antworten. Quellen müssen sichtbar bleiben, unzureichende Evidenz muss zu einer kontrollierten Nichtantwort führen, und Nutzerfeedback darf nicht ungeprüft als Qualitätsmetrik gelten. Eine freundlich bewertete Antwort kann sachlich falsch sein.
Erst im vierten Schritt lohnt die Skalierungsfrage: Aktualisierungsfrequenz, Latenz, Mandantentrennung, Kosten und Betrieb. Damit bleibt die Toolwahl eine Folge gemessener Anforderungen.
Viele RAG-Projekte kaufen Suchtechnik, bevor geklärt ist, welches Dokument im Streitfall gelten soll. Damit machen sie die Widersprüche ihrer Wissensbasis schneller abrufbar. Die unbequeme Vorarbeit heisst Versionierung, Rechte und ein Goldset aus echten Fragen.
Fazit
RAG ist sinnvoll, wenn ein Sprachmodell aktuelles, internes oder belegpflichtiges Wissen zur Laufzeit auswählen muss. Der Ansatz ist unnötig, wenn eine kleine Dokumentmenge direkt in den Kontext passt, eine SQL-Abfrage die Frage präziser beantwortet oder klassische Suche bereits genügt.
Die entscheidende Reihenfolge lautet: Wissensbasis und Rechte klären, Retrieval gegen eine einfache Baseline messen, Quellenbezug und Nichtwissen gestalten, erst danach Tools skalieren. Ein starkes Modell kann fehlende Evidenz nicht ersetzen. Ein gutes RAG-System sorgt dafür, dass diese Evidenz auffindbar, erlaubt und überprüfbar ist.
Braucht jedes RAG-System eine Vektordatenbank?
Nein. Je nach Korpus genügen Volltextsuche, SQL, Metadatenfilter, ein bestehender Suchindex oder ein langer Kontext. Vektorsuche ist eine Option für semantisches Retrieval, keine Definition von RAG.
Verhindert RAG Halluzinationen?
Nicht zuverlässig. RAG kann passende Quellen bereitstellen, übernimmt aber Fehler aus Korpus, Retrieval und Kontextauswahl. Das Modell kann gute Belege weiterhin falsch verwenden oder ignorieren.
Ist langer Kontext eine Alternative zu RAG?
Bei wenigen bereits ausgewählten Dokumenten ja. Bei grossen, dynamischen oder zugriffsgeschützten Beständen muss weiterhin entschieden werden, welches Material in den Kontext gehört.
Wann ist Fine-Tuning besser?
Wenn Verhalten, Format, Stil oder eine wiederkehrende Aufgabe angepasst werden sollen. Für austauschbares, versioniertes und belegbares Wissen ist RAG meist leichter kontrollierbar.
