RAG — wie LLMs auf eigene Daten zugreifen
Wenn das Modell nicht aus dem Stand antworten kann, weil das Wissen in Ihren Dokumenten steckt, lässt man es erst lesen. Mechanik, Stellschrauben, Grenzen.
Ein Sprachmodell kennt das Wissen, mit dem es trainiert wurde — sonst nichts. Der Lieferantenvertrag aus Q3, das interne Wiki, die Polizze aus dem CRM: davon weiß GPT, Claude oder Gemini exakt nichts.
Wer ein LLM ohne Vorlauf einsetzt, lässt es bei jeder firmenspezifischen Frage entweder schweigen oder raten. Beides hilft niemandem im Tagesgeschäft.
Retrieval Augmented Generation — kurz RAG — lockert diesen Engpass. Vor jeder Antwort holt sich das System die relevanten Ausschnitte aus Ihren Dokumenten und legt sie dem Modell als Kontext vor. Das Modell liest. Dann antwortet es.
Der naheliegende Reflex vieler Häuser ist ein anderer: das Modell mit den eigenen Daten nachzutrainieren. Das ist meist die teurere und trägere Lösung. Sobald ein Vertrag ergänzt oder ein Produkt umbenannt wird, läuft der Trainingszyklus erneut. RAG tauscht stattdessen die Dokumentensammlung aus — Sekunden statt Tage.
Wie es technisch läuft
Drei Phasen. Die erste passiert einmalig oder bei Aktualisierungen, die zweite und dritte bei jeder Anfrage.
1. Indexierung — einmalig
Dokumente werden in kleinere Stücke zerlegt — sogenannte Chunks. Jeder Chunk wird in einen Zahlenvektor übersetzt, ein Embedding, das die Bedeutung kodiert. Diese Vektoren landen in einer Vektor-Datenbank wie Pinecone, Weaviate oder Qdrant. Aus 200 Seiten HR-Handbuch werden so vielleicht 800 Chunks und 800 Vektoren.
2. Retrieval — bei jeder Frage
Die Frage des Users wird ebenfalls zum Vektor. Das System sucht in der Datenbank die Chunks mit dem ähnlichsten Vektor, meist über Cosine-Similarity. Aus 800 Chunks werden die Top fünf bis zehn herausgezogen.
3. Generation — gleich danach
Diese Chunks wandern zusammen mit der ursprünglichen Frage in den Prompt. Das LLM antwortet auf der Grundlage dieser Ausschnitte — und kann auch ihre Quelle ausweisen.
Konkret. Ein Mitarbeiter fragt den HR-Chatbot, wie viele Urlaubstage er hat.
User: Wie viele Urlaubstage habe ich?
Modell: Ich habe keinen Zugriff auf Ihre Personaldaten.
(Oder schlimmer: rät anhand allgemeiner Faustregeln.)
User: Wie viele Urlaubstage habe ich?
System: → sucht „Urlaubstage" im Dokument-Index
→ findet HR-Handbuch, Seite 42
→ übergibt: „Vollzeitmitarbeiter erhalten 25 Urlaubstage pro Jahr."
Modell: Laut HR-Handbuch (S. 42) stehen Ihnen als Vollzeitmitarbeiter
25 Urlaubstage pro Jahr zu.
Warum es Entscheider angeht
Drei Punkte, die nicht in der Vendor-Folie stehen.
Erstens: Halluzinationen sinken messbar. Der direkteste Hebel gegen die Tendenz von LLMs, Fakten zu erfinden. Ein Modell, das vor der Antwort echte Quellen liest, halluziniert seltener — und kann zumindest auf die Quelle zeigen, wenn es trotzdem daneben liegt. In regulierten Bereichen wie Compliance, Recht oder Medizin ist diese Quellen-Pflicht oft das, was den Einsatz überhaupt erlaubt.
Zweitens: Aktualität ohne Re-Training. Trainingsdaten haben einen Stichtag. Ihre Vertragsdatenbank, Ihr CRM, Ihre Wiki ändern sich täglich. Statt das Modell ständig nachzuschulen — was Tage und Compute kostet — tauschen Sie nur den Inhalt der Vektor-Datenbank aus. Eine neue Version geht binnen Minuten in den Index, die nächste Frage zieht sie.
Drittens: Kontrolle über das Wissen. Beim Fine-Tuning verschmilzt Ihr Wissen mit den Modell-Gewichten — irreversibel und schwer prüfbar. Bei RAG bleibt es in einer Datenbank, die Sie löschen, ergänzen oder versionieren können. Wer einen Vertragsausschnitt aus dem Dokumenten-Pool entfernt, sorgt dafür, dass das Modell ihn nicht mehr sieht. Beim nachtrainierten Modell ist das praktisch unmöglich.
Wo RAG kippt
Drei Stellschrauben entscheiden, ob ein RAG-System trägt oder bröckelt.
Chunking — die unterschätzte Stellschraube
Wie Dokumente zerschnitten werden, entscheidet über die Antwort-Qualität. Zu kleine Chunks zerreißen Sätze. Zu große verwässern den Kontext.
Ein vernünftiger Startwert sind 500 bis 1.000 Tokens pro Chunk mit zehn bis zwanzig Prozent Überlappung an den Grenzen — dann hängt jeder Chunk noch mit dem Nachbarn zusammen, ohne überflüssig zu redundant zu werden. Das ist ein Startwert, keine Wahrheit. Welche Schnittlänge bei Ihren Dokumenten trägt, zeigt sich erst im Test.
Hybrid Search — Vektor allein reicht nicht
Reine Vektor-Suche findet semantisch ähnlichen Text — und übersieht exakte Begriffe. Wer nach „Schnoor & Co. KG" sucht, will den exakten Treffer, nicht das semantisch ähnliche „Hamburger Reederei".
Hybrid Search kombiniert die Vektor-Suche mit klassischer Stichwort-Suche (BM25). In der Praxis: zehn bis dreißig Prozent bessere Trefferqualität, vor allem bei Eigennamen, Produktcodes und Vertragsnummern.
Re-Ranking — ein zweites Paar Augen
Die Vektor-Suche liefert hundert Kandidaten in Millisekunden. Aber sie sind grob sortiert. Ein Re-Ranker — meist ein Cross-Encoder — bewertet die Top hundert noch einmal mit der Frage gemeinsam und zieht die wirklich relevanten Treffer nach oben. Kostet Rechenzeit, hebt aber die Antwort-Qualität messbar.
Anthropic hat dazu im September 2024 eine Untersuchung veröffentlicht: in Kombination mit kontextueller Embedding-Erweiterung reduzierte Re-Ranking die Retrieval-Fehlerrate um knapp 70 Prozent.
Tool-Stack — knapp gehalten
Frameworks und Vektor-Datenbanken (Stand 2026)
Die Werkzeug-Auswahl ist breit und wechselt quartalsweise. Häufige Setups:
- LangChain oder LlamaIndex als Framework — LangChain für breite Integrationen in Bestandssysteme, LlamaIndex spezifisch auf RAG hin gebaut.
- Pinecone, Weaviate oder Qdrant als Vektor-Datenbank — Pinecone managed (geringster Betriebsaufwand), Weaviate Hybrid-Search nativ, Qdrant schnell und filter-stark.
- pgvector als Postgres-Erweiterung, wenn ohnehin schon ein Postgres-Stack im Haus ist — keine zusätzliche Infrastruktur.
Die Entscheidung hängt am Bestand und am Budget für Betrieb, nicht an der Vendor-Folie.
Wann RAG nicht passt
RAG ist kein Universalheilmittel. Es lohnt sich nicht, wenn das Modell-Wissen ausreicht — etwa für allgemeine Sprache, Übersetzungen oder Code-Refactorings ohne firmenspezifischen Kontext. Es lohnt sich auch nicht, wenn es weniger ums Wissen als um Stil oder Konsistenz geht — dann ist Fine-Tuning oder besseres Prompt-Design das richtigere Werkzeug.
Und es löst nicht alle Halluzinations-Probleme: ein Modell kann die richtigen Quellen abrufen und sie trotzdem falsch zusammenfassen. Re-Ranking und Quellen-Zitierung helfen, sind aber kein Garant.
Die Architekten-Illusion gilt auch hier. Ein RAG-System auf einer fragmentierten Datenlandschaft ist kein Heilmittel — es macht die Lücken nur sichtbarer. Wer nicht weiß, wo welcher Vertrag liegt, kann auch keinen sauberen Index bauen. RAG fordert Datenhygiene, bevor es sie liefert.
Was zu tun ist
Drei pragmatische Schritte, wenn der Use Case erkennbar trägt.
1. Mit einem klaren Use Case anfangen
Nicht „RAG für alles", sondern „RAG für unsere HR-Anfragen" oder „RAG für die Vertragsrecherche". Ein klarer Anwendungsfall macht messbar, ob es funktioniert.
2. Mit der Datenbasis ehrlich sein
Bevor ein Vektor-Index gebaut wird, gehören drei Fragen geklärt: Welche Dokumente sind aktuell? Wer pflegt sie? Welche Versionen sind verbindlich? Das ist Projekt-Hausaufgabe, nicht IT-Aufgabe.
3. Mit einem managed Stack starten
Pinecone plus LlamaIndex plus ein Modell der Wahl. Ein Tag bis zum Prototyp, eine Woche bis zur ersten ehrlichen Bewertung. Selbst-gehostete Stacks und ausgefeilte Re-Ranking-Architekturen folgen, wenn der Bedarf erwiesen ist — nicht vorher.
Die kurze Antwort
Wer LLMs ernsthaft im Unternehmen einsetzt, kommt an RAG nicht vorbei. Es ist nicht der schillerndste Teil der KI-Welt — es ist das Stück, das den Unterschied zwischen einem Demo und einem produktiven System macht.
Wer es überspringt, baut entweder eine Bühne für Halluzinationen oder ein Modell, das nur weiß, was bis zum Stichtag in den Trainingsdaten stand.
Quellen
- Lewis, Patrick et al.: Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks. Facebook AI Research (Meta), NeurIPS 2020. Originalarbeit zur RAG-Architektur.
- Karpukhin, Vladimir et al.: Dense Passage Retrieval for Open-Domain Question Answering. EMNLP 2020. Grundlage moderner Embedding-basierter Suche.
- Robertson, Stephen / Zaragoza, Hugo: The Probabilistic Relevance Framework: BM25 and Beyond. Foundations and Trends in Information Retrieval, 2009. Referenzwerk für Stichwort-Retrieval und damit den Sparse-Anteil von Hybrid Search.
- Anthropic: Introducing Contextual Retrieval. Engineering-Blog, 19. September 2024. Untersuchung zu kontextueller Embedding-Erweiterung und Re-Ranking — mit Reduktion der Retrieval-Fehlerrate um knapp 70 % in Kombination.
- MIT NANDA: The GenAI Divide — State of AI in Business 2025. Empirischer Befund: Der ROI generativer KI hängt weniger am Modell als an der Anbindung an Unternehmensdaten.
RAG-System für Ihre Dokumente?
Im Erstgespräch klären wir, welcher Use Case bei Ihnen trägt, welche Daten dafür gebraucht werden und welcher Stack zu Ihrem Bestand passt. Eine Stunde bis eineinhalb. Keine Folien, keine Verpflichtung.