Große Sprachmodelle haben ein Gedächtnisproblem. Sie wissen, was sie im Training gelernt haben. Sonst nichts. Frag nach internen Dokumenten deines Unternehmens, nach den Nachrichten von gestern oder nach allem, was nach ihrem Trainingsstichtag passiert ist, und sie raten entweder oder geben Unwissenheit zu.
RAG behebt das. So ungefähr.
Retrieval-Augmented Generation ist genau das, wonach es klingt: Bevor eine Antwort generiert wird, ruft das System relevante Informationen aus externen Quellen ab und nutzt sie dann, um eine genauere Antwort zu erzeugen. Das Modell muss dein Unternehmenshandbuch nicht auswendig gelernt haben, wenn es zuerst nachschlagen kann.
Die Grundidee, ganz einfach
Denk daran, wie du Fragen beantwortest, wenn du dir nicht sicher bist. Du rätst nicht einfach. Du schlägst erst etwas nach und formulierst dann deine Antwort auf Basis dessen, was du gefunden hast. RAG funktioniert genauso, nur dass das „Nachschlagen“ automatisch passiert, bevor die KI antwortet.
So läuft es ab, wenn du einem RAG-System eine Frage stellst:
- Deine Frage wird in eine numerische Darstellung umgewandelt (ein Embedding)
- Das System durchsucht eine Datenbank nach Inhalten mit ähnlichen Darstellungen
- Die relevantesten Textabschnitte werden herausgezogen und zu deiner Frage hinzugefügt
- Das Sprachmodell erhält sowohl deine Frage als auch den abgerufenen Kontext
- Es erzeugt eine Antwort auf Basis dieser kombinierten Eingabe
Wie Nutzer ozr auf Hacker News erklärt hat: “It’s right there in the name - first you Retrieve relevant information (often a vector lookup) then you use it to Augment the prompt, then you Generate an answer.”
Das Sprachmodell „lernt“ deine Daten nie. Es sieht sie nur in dem Moment, in dem es antwortet – als würde man ihm direkt vor einer Prüfungsfrage eine passende Seite aus einem Lehrbuch in die Hand drücken.
Warum das wichtig ist
Sprachmodelle halluzinieren. Sie erzeugen plausibel klingende, aber falsche Informationen, weil sie Muster zuordnen, nicht Fakten prüfen. Trainingsdaten können veraltet, unvollständig oder für deine konkrete Situation schlicht falsch sein.
RAG greift dieses Problem direkt an. Indem du das Modell in abgerufenen Dokumenten verankerst, gibst du ihm echte Quellen, mit denen es arbeiten kann, statt es rein auf statistische Muster aus dem Training zu stützen. Ein Modell kann nur bis zu einem gewissen Punkt halluzinieren, wenn du ihm die richtige Antwort buchstäblich hinlegst, aus der es ziehen kann.
Das löst drei Probleme auf einmal:
Aktualität: Modelle haben Trainingsstichtage. Informationen ändern sich. RAG lässt dich ein Modell an kontinuierlich aktualisierte Quellen anschließen, ohne neu zu trainieren.
Spezifität: Ein Modell, das auf dem allgemeinen Internet trainiert wurde, weiß nichts über interne Abläufe, Produkte oder Begriffe deines Unternehmens. RAG lässt dich es auf deine konkrete Wissensbasis ausrichten.
Überprüfbarkeit: Wenn Antworten aus abgerufenen Quellen stammen, kannst du sie zurückverfolgen. Das Modell erfindet nicht einfach alles aus statistischen Korrelationen.
Wie hirako2000 es auf Hacker News formulierte: “RAG’s point is to remove the limit LLMs alone have which is that they are limited to the training data as source of information.”
Wie das Abrufen wirklich funktioniert
Der Abruf-Schritt ist der Teil, der technisch interessant wird. Die meisten RAG-Systeme nutzen Vektorsuche, auch semantische Suche genannt. Deine Dokumente werden in numerische Vektoren (Embeddings) umgewandelt, die ihre Bedeutung abbilden sollen. Wenn eine Frage reinkommt, bekommt sie die gleiche Behandlung. Anschließend findet das System Dokumente, deren Vektoren mathematisch am nächsten am Vektor der Frage liegen.
Das funktioniert besser als reine Stichwortsuche, weil es Bedeutung erfasst – nicht nur Wörter. Eine Frage nach „Urlaubsregelung für Mitarbeitende“ kann zu einem Dokument mit dem Titel „PTO-Richtlinien“ passen, obwohl sie keine identischen Wörter teilen.
Aber Vektorsuche ist nicht die einzige Option. Wie der KI-Forscher Simon Willison auf Hacker News anmerkte: “You don’t have to use vector search to implement RAG. You can use other search mechanisms instead or as well.”
Manche Praktiker bevorzugen für bestimmte Anwendungsfälle klassische Textsuche (BM25). Ein Kommentator in einem jüngeren Hacker-News-Thread über lokales RAG stellte fest: “In a lot of the cases bm25 has been the best approach used in many of the projects we deployed.” Andere kombinieren Ansätze und nutzen sowohl Stichwort- als auch semantische Suche, um unterschiedliche Arten von Relevanz einzufangen.
Die richtige Wahl hängt von deinen Daten ab. Dichte technische Dokumente mit konkreter Terminologie funktionieren oft besser mit Stichwortsuche. Gesprächige Inhalte mit vielen Formulierungsvarianten brauchen eher semantische Treffer. Speziell für Code merkte ein Entwickler an: “Don’t use a vector database for code, embeddings are slow and bad for code. Code likes bm25+trigram.”
Was RAG nicht kann
Die meisten Fehlschläge entstehen, weil man die Grenzen von RAG missversteht. Die Methode ist stark, aber eng abgegrenzt.
RAG macht Sprachmodelle nicht klüger. Es gibt ihnen Zugriff auf Informationen, die sie sonst nicht hätten. Aber wenn das Modell über diese Informationen nicht gut schlussfolgern kann oder der Abruf die falschen Dokumente zieht, bekommst du trotzdem schlechte Antworten.
Ein Hacker-News-Nutzer brachte eine einprägsame Analogie: “Using RAG feels like asking an acquaintance to write a book report by giving them semi-randomly cut out paragraphs from the book.”
Das ist die grundlegende Einschränkung: RAG holt Abschnitte, kein Verständnis. Wenn deine Frage erfordert, Informationen über ein ganzes Dokument hinweg zu bündeln oder Erkenntnisse aus mehreren Quellen auf komplexe Weise zu verknüpfen, liefert abschnittsbasierter Abruf dem Modell womöglich nicht das, was es braucht.
Ein weiterer Kommentator im selben Thread beschrieb die Grenze noch präziser: “Simple RAG works well when questions are highly correlated with specific chunks of documents. It does not allow an LLM to synthesize an entire corpus to an answer (e.g. a book report).”
RAG verhindert Halluzinationen außerdem nicht vollständig. Es senkt das Risiko, indem es faktische Verankerung liefert, aber Modelle können trotzdem:
- Abgerufene Dokumente falsch interpretieren
- Aus mehrdeutigen Quellen selbstsicher antworten
- Lücken zwischen abgerufenen Abschnitten mit erfundenen Details füllen
- Korrekte Zitate zu falschen Schlussfolgerungen zusammensetzen
Die Technik funktioniert am besten, wenn Fragen klare, lokale Antworten in deiner Dokumentensammlung haben. Sie tut sich schwer mit Fragen, die ganzheitliches Verständnis oder Synthese über große Textmengen hinweg erfordern.
RAG vs. Feintuning
Eine häufige Frage: Wann solltest du RAG nutzen – und wann Feintuning eines Modells auf deinen Daten?
Feintuning passt die Gewichte des Modells anhand deiner Daten an und bringt ihm damit effektiv neue Muster bei. RAG lässt das Modell unverändert, liefert aber zur Anfragezeit externe Informationen.
Das dient völlig unterschiedlichen Zwecken.
Feintuning verändert, wie das Modell schreibt und schlussfolgert. Es ist nützlich, um einem Modell den Ton deines Unternehmens, die Terminologie deiner Branche oder dein bevorzugtes Ausgabeformat beizubringen. Es fügt nicht zuverlässig neue Fakten hinzu. Modelle tun sich schwer damit, feingetunte Informationen von ihrem Basistraining zu unterscheiden.
Wie es ein Praktiker ausdrückte: “Fine tuning is not good for really adding/removing facts but is great for changing the form of the output.”
RAG ergänzt Informationszugriff. Es lässt Modelle Fragen zu Inhalten beantworten, die sie im Training nie gesehen haben. Der Stil des Modells bleibt gleich, aber sein Wissen erweitert sich.
Für die meisten geschäftlichen Anwendungen willst du beides zusammen: ein Modell, das auf deinen Kommunikationsstil feingetunt ist, und das über RAG an deine aktuelle Dokumentation angebunden ist. Keines von beiden löst allein das ganze Problem.
Wann RAG sinnvoll ist
RAG funktioniert gut für:
Kundensupport-Systeme: Verbinde einen Chatbot mit deiner Hilfe-Dokumentation. Fragen werden passenden Artikeln zugeordnet, und das Modell erzeugt natürlichsprachliche Antworten, die in deinen echten Support-Inhalten verankert sind.
Interne Wissensdatenbanken: Mitarbeitende können Fragen zu Richtlinien, Prozessen und Dokumentation stellen, ohne sich durch Ordnerstrukturen oder Wikis zu wühlen.
Produktdokumentation: Nutzer können in natürlicher Sprache fragen, wie Produkte funktionieren, und Antworten bekommen, die aus der tatsächlichen Dokumentation gezogen werden.
Rechtliche oder regulatorische Vorgaben: Wenn Antworten auf konkrete Quelldokumente zurückführbar sein müssen, liefert RAG die Nachweiskette, die reine Modellantworten nicht bieten können.
Der gemeinsame Nenner: Situationen, in denen das Modell mit spezifischen, begrenzten, überprüfbaren Informationen arbeiten muss – statt mit Allgemeinwissen.
Wann Alternativen sinnvoll sind
RAG ist nicht immer die richtige Wahl.
Modelle mit langem Kontext: Modelle mit sehr großen Kontextfenstern (100K+ Tokens) können manchmal ganze Dokumentensammlungen direkt aufnehmen. Wenn deine Wissensbasis klein genug ist, brauchst du womöglich gar keinen Abruf. Wie ein Praktiker beobachtete: “85 % of the time we don’t need the vectordb” – nachdem sie festgestellt hatten, dass einfachere Ansätze ihren Anwendungsfall lösen.
Abfragen strukturierter Daten: Wenn deine Informationen in Datenbanken mit sauberen Schemata liegen, sind klassische Abfragesysteme oft besser als Vektorsuche. RAG ist stark bei unstrukturiertem Text, nicht bei tabellarischen Daten.
Echtzeitinformationen: RAG setzt voraus, dass deine Wissensbasis bereits aufgebaut ist. Für wirklich live Daten (Aktienkurse, Wetter, aktuelle Nachrichten) brauchst du API-Integrationen, keinen Dokumentenabruf.
Komplexe Denkaufgaben: Fragen, die mehrstufiges Schlussfolgern über viele Quellen verlangen, fordern den abschnittsbasierten Ansatz von RAG heraus. Manche Probleme brauchen Agentensysteme, die suchen, schlussfolgern und iterieren können, statt einmal abzurufen und dann zu generieren.
Realität der Umsetzung
Produktionsreife RAG-Systeme zu bauen bedeutet mehr Entscheidungen, als es Tutorials vermuten lassen. Die Segmentgröße ist entscheidend: zu klein, und du verlierst Kontext; zu groß, und du verschwendest die Aufmerksamkeit des Modells auf irrelevanten Inhalt. Die Qualität des Abrufs schwankt stark – je nach Embedding-Modell und Suchparametern.
Viele Praktiker haben festgestellt, dass einfache Ansätze komplexe oft schlagen. Die Werkzeuglandschaft ist noch nicht stabil. Manche Entwickler finden kommerzielle RAG-Plattformen hilfreich. Andere bauen lieber aus einfachen Bausteinen. “SQLite works shockingly well,” merkte ein Hacker-News-Kommentator über sein Produktionssystem an.
Eine weitere Beobachtung aus der Praxis: “A little BM25 can get you quite a way with an LLM.” Die Aussage ist klar. Starte einfach. Miss die Ergebnisse. Füge Komplexität nur dann hinzu, wenn Messungen zeigen, dass du sie brauchst.
Was funktioniert, hängt stark von deinen Daten, deinen Fragen und deinen Genauigkeitsanforderungen ab. Die Unternehmen, die echten Nutzen aus RAG ziehen, haben meist einfach angefangen, Ergebnisse sorgfältig gemessen und anhand realer Leistung iteriert – nicht nach theoretisch besten Praktiken.
Das große Ganze
RAG ist eine konkrete Architekturentscheidung: Halte das Sprachmodell allgemein, aber verbinde es zur Anfragezeit mit spezialisiertem Wissen. Das tauscht etwas Leistungsfähigkeit gegen Flexibilität. Deine Informationen bleiben in Quellen, die du kontrollierst, Updates passieren ohne erneutes Training, und Antworten lassen sich gegen abgerufene Dokumente überprüfen.
Wie minimaxir auf Hacker News schrieb: “RAG is the one paradigm of modern AI that’s completely uncontroversial (hallucinations aside) and will persist even if there’s an AI-industry crash.”
Die Kernidee, Generierung mit Abruf anzureichern, löst ein echtes Problem, das auch mit besseren Basismodellen nicht verschwindet.
Weniger klar ist, ob heutige Implementierungen das volle Potenzial ausschöpfen. Aktuelle RAG-Systeme machen meist einfache Ähnlichkeitssuche und anschließend eine einmalige Generierung. Es gibt ausgefeiltere Ansätze: solche, die iterativ suchen, abgerufene Informationen verifizieren oder über viele Quellen hinweg synthetisieren. Das sind weiterhin aktive Entwicklungsfelder.
Die Technik hat ihren Wert für schmale, faktenbasierte Fragen gegen strukturierte Wissensbasen bewiesen. Ob sie auf unordentlichere, ambitioniertere Anwendungen skaliert, ist offen. Unternehmen, die RAG erfolgreich einsetzen, sind meist ehrlich mit seinen Grenzen gewesen – und haben es dort verwendet, wo es wirklich hilft, statt es in Probleme zu pressen, die andere Lösungen brauchen.
Für die meisten Organisationen, die KI erkunden, lohnt es sich, RAG zu verstehen. Nicht weil es alles löst. Sondern weil zu wissen, was es tut – und was nicht –, dir hilft, bessere Entscheidungen darüber zu treffen, wo KI deine Arbeit tatsächlich unterstützen kann.
