RAG erklärt am Beispiel: Antworten aus den eigenen Dokumenten

Ein Sprachmodell (LLM) kennt nur, was in seinem Training stand. Deine Produkthandbücher, deine Reisekostenrichtlinie oder die Preisliste vom letzten Monat gehören nicht dazu. RAG ist der übliche Weg, das zu ändern, ohne das Modell selbst anzufassen. Wie das in einem Chatbot auf deiner Website aussieht und was der Betrieb kostet, steht im Artikel KI-Chatbot für die eigene Website. Hier geht es darum, was unter der Haube passiert.

Zuletzt habe ich RAG in neore gebaut, meiner eigenen KI-Plattform (quellverfügbar unter der Functional Source License FSL-1.1-ALv2, keine Open-Source-Lizenz). Nutzer laden dort PDFs, Word- und PowerPoint-Dateien, Markdown oder Webseiten in eine Wissensdatenbank, und der Chat antwortet daraus mit nummerierten Quellen. Was ich dabei gelernt habe, steht weiter unten.

Das Beispiel: Ein Hersteller und seine Handbücher

Stell dir einen Hersteller von Maschinen vor. Die Technik-Hotline beantwortet jeden Tag Fragen, deren Antwort irgendwo in einem PDF-Handbuch steht: „Welches Anzugsdrehmoment gilt für die Schrauben an der Spindel der X200?" Die Handbücher gibt es in mehreren Versionen, manche Abschnitte gelten nur für bestimmte Baujahre, und ein Teil der Dokumente ist nur für Servicetechniker freigegeben.

Das Ziel: Mitarbeitende stellen die Frage in eigenen Worten und bekommen eine kurze Antwort mit Verweis auf Handbuch, Version und Seite, damit sie nachschauen können.

Wie RAG funktioniert, Schritt für Schritt

Die ersten drei Schritte laufen einmal vorab und danach bei jeder Änderung der Dokumente. Die letzten drei laufen bei jeder Frage.

1. Dokumente einsammeln und bereinigen

   Die Handbücher werden aus dem Dateiserver oder dem Dokumentenmanagement geladen und in Text umgewandelt. Zu jedem Dokument merkt sich das System Metadaten: Titel, Version, gültig für welche Modelle, Stand und wer es sehen darf. Veraltete Versionen fliegen raus oder werden als veraltet markiert.

2. In Abschnitte zerlegen (Chunking)

   Ein ganzes Handbuch ist zu groß und zu unscharf für die Suche. Deshalb wird es in Abschnitte von meist einigen hundert Tokens zerlegt, am besten entlang der Struktur: ein Kapitel, eine Tabelle, ein Arbeitsschritt. Jeder Abschnitt behält seine Metadaten und einen Verweis auf Seite und Überschrift.

3. Embeddings berechnen und speichern

   Ein Embedding-Modell wandelt jeden Abschnitt in einen Vektor um, eine lange Zahlenreihe, die die Bedeutung des Textes abbildet. Texte mit ähnlicher Bedeutung liegen nah beieinander, auch wenn sie andere Wörter benutzen. Die Vektoren landen in einer Vektordatenbank oder in Postgres mit der Erweiterung pgvector.

4. Frage suchen (Retrieval)

   Die Frage „Drehmoment Spindelschrauben X200" wird mit demselben Modell in einen Vektor umgewandelt. Die Datenbank liefert die ähnlichsten Abschnitte, gefiltert nach Metadaten: nur Dokumente zur X200, nur aktuelle Versionen, nur was diese Person sehen darf. Oft kombiniert man das mit einer klassischen Stichwortsuche, weil Artikelnummern und Fachbegriffe dort besser gefunden werden.

5. Prompt mit Quellen bauen

   Die gefundenen Abschnitte gehen zusammen mit der Frage an das Sprachmodell, jeweils mit Titel und Fundstelle. Dazu kommt eine Anweisung: Antworte nur aus diesen Abschnitten, nenne die Quelle, und sag es, wenn die Antwort nicht drinsteht.

6. Antwort mit Quellenangabe

   Das Modell antwortet, zum Beispiel: „Laut Handbuch X200, Version 3, Abschnitt 4.2 gilt …", mit einem Link auf die Stelle. Wer der Antwort nicht traut, prüft sie mit einem Klick. Findet die Suche nichts Passendes, sagt der Assistent das, statt zu raten.

Wie Schritt 5 im Code aussieht

Ein minimales Beispiel mit der Anthropic-API in TypeScript. chunks sind die Treffer aus Schritt 4. Jeder Abschnitt geht als eigenes Dokument mit eingeschalteten Zitaten an das Modell. Die API gibt dann zu jeder Aussage die zitierte Textstelle und den Dokumenttitel zurück (Anthropic-Doku zu Citations, abgerufen am 11. November 2026).

import Anthropic from "@anthropic-ai/sdk";

const client = new Anthropic();

export const answer = async (question: string, chunks: { title: string; text: string }[]) =>
    client.messages.create({
        model: "claude-sonnet-5-5",
        max_tokens: 1024,
        system: "Answer only from the documents. If they do not contain the answer, say so.",
        messages: [
            {
                role: "user",
                content: [
                    ...chunks.map((chunk) => ({
                        type: "document" as const,
                        source: { type: "text" as const, media_type: "text/plain" as const, data: chunk.text },
                        title: chunk.title,
                        citations: { enabled: true },
                    })),
                    { type: "text" as const, text: question },
                ],
            },
        ],
    });

Das ist der kleinste Teil der Arbeit. Ob die Antwort stimmt, entscheidet sich fast immer in den Schritten 1 bis 4.

Was das kostet und wie groß „zu groß" ist

Das Berechnen der Embeddings ist fast nie der Kostentreiber. Eine eigene Beispielrechnung: 500 Seiten Handbuch mit den rund 800 Tokens pro Seite, die OpenAI für seine Seitenangaben annimmt, sind etwa 400.000 Tokens. Mit text-embedding-3-small kostet das einmalige Einlesen weniger als einen Cent. Die laufenden Kosten für das Sprachmodell selbst stehen im Chatbot-Artikel. Der echte Aufwand steckt in Aufbereitung, Rechten und Tests.

RAG, Fine-Tuning oder einfach ein langer Prompt?

Langer Prompt. Aktuelle Modelle verarbeiten sehr viel Text auf einmal: Die Claude-Modelle haben laut Anthropic ein Kontextfenster von einer Million Tokens. Anthropic selbst schreibt in seinem Beitrag zu Contextual Retrieval, dass du bei einem Bestand unter 200.000 Tokens, etwa 500 Seiten, den ganzen Bestand in den Prompt geben kannst, mit Prompt-Caching auch schneller und günstiger. Für ein einzelnes Handbuch oder eine Handvoll Richtlinien ist das oft die einfachste Lösung. Die Grenzen: Jede Anfrage schickt alles mit, Zugriffsrechte lassen sich nicht pro Abschnitt umsetzen, und bei großen Beständen passt es irgendwann nicht mehr.

Fine-Tuning. Fine-Tuning verändert das Modell durch zusätzliches Training. Das eignet sich für einen bestimmten Stil oder ein Ausgabeformat, aber schlecht für Fakten, die sich ändern: Jede neue Preisliste hieße neu trainieren, und eine Quelle kann das Modell danach nicht nennen. Mehr dazu im Vergleich RAG oder Fine-Tuning?.

Meine Faustregel: Passt der Bestand in den Prompt und dürfen alle alles sehen, fang mit dem langen Prompt an. Wenn nicht, RAG. Fine-Tuning erst, wenn Ton oder Format trotz guter Quellen nicht passen.

Was in der Praxis schiefgeht

Schlechte Quelldokumente. Gescannte PDFs ohne Textebene, Tabellen, die beim Umwandeln zerfallen, drei Versionen desselben Handbuchs mit unterschiedlichen Werten: RAG findet genau das, was drinsteht. Widersprüchliche Dokumente führen zu widersprüchlichen Antworten. Die Aufbereitung ist oft der größte Posten im Projekt.

Ungünstiges Chunking. Zerschneidet die Aufteilung eine Tabelle oder trennt einen Arbeitsschritt von seiner Überschrift, findet die Suche den Abschnitt nicht mehr oder er ergibt allein keinen Sinn. Ein Abschnitt, in dem nur der Wert für das Anzugsdrehmoment steht, sagt nicht, für welches Modell das gilt. Hilfreich ist, jedem Abschnitt seinen Kontext mitzugeben (Dokument, Kapitel, Modell). Anthropic hat diesen Ansatz als Contextual Retrieval beschrieben: In Anthropics eigenen Tests sank der Anteil fehlgeschlagener Suchen mit so angereicherten Embeddings um 35 %, zusammen mit einer ebenso angereicherten Stichwortsuche (BM25) um 49 % und mit zusätzlichem Reranking um 67 % (Anthropic, September 2024). Das sind Werte aus deren Testdaten, nicht aus deinen: Ob es bei dir hilft, zeigen erst deine eigenen Tests.

Veraltete Inhalte. Der Index ist eine Kopie. Ändert sich ein Dokument und niemand liest es neu ein, antwortet das System mit dem alten Stand, und zwar mit Quellenangabe, also sehr überzeugend. Plane deshalb von Anfang an ein, wie Änderungen automatisch in den Index kommen und wie gelöschte Dokumente wieder herausfallen.

Zugriffsrechte. Der kritischste Punkt. Wenn die Servicehandbücher nur für Techniker freigegeben sind, darf die Vertriebsassistenz auch keine Antwort daraus bekommen, auch nicht indirekt. Das lässt sich nicht mit einer Anweisung im Prompt lösen („Zeig Vertrieblern keine Servicedaten"). Die Rechte müssen bei der Suche gelten: Die Datenbank liefert nur Abschnitte, die die fragende Person im Quellsystem sehen darf. Was das Modell nie bekommt, kann es auch nicht verraten.

Anweisungen in Dokumenten. Ein Dokument kann Text enthalten, der wie eine Anweisung an das Modell aussieht. Bei internen Handbüchern ist das Risiko klein, bei hochgeladenen Kundendokumenten oder Webseiten nicht. Ein RAG-Assistent sollte deshalb nur antworten und keine Aktionen auslösen, ohne dass ein Mensch zustimmt.

Was ich bei neore gelernt habe

• Vektorsuche allein reicht nicht. neore sucht in zwei Durchgängen: per Embedding und per Stichwortsuche (BM25). Beide Trefferlisten werden zusammengeführt. Fällt ein Durchgang aus, antwortet der andere.
• Einem Reranker nicht blind vertrauen. Das Reranking-Modell, das ich nutze, ist auf Englisch und Chinesisch am stärksten. Für deutsche Dokumente ersetze ich die bisherige Reihenfolge deshalb nicht durch seine, sondern führe beide zusammen.
• Rechte an jeder Stelle prüfen. Die Suche filtert nach der fragenden Person, und jeder Treffer wird danach noch einmal gegen Eigentümer und freigegebene Dateien geprüft. Trotzdem fand ich nach dem Start eine Lücke: Die Suche innerhalb eines Chats lief zunächst nicht durch dieselbe Sperre wie gesperrte Chats. Seitdem deckt ein Test genau diesen Fall ab.
• Beim Löschen aufräumen. Wurde eine Datei gelöscht, während sie noch eingelesen wurde, blieben Vektoren ohne zugehörigen Text im Index. Jetzt bleiben Vektoren nur, wenn der Text gespeichert ist.
• Suche und Antwort getrennt messen. Ein eigener Eval-Lauf prüft, ob die erwarteten Quellen gefunden werden, und bewertet danach, ob die Antwort bei diesen Quellen bleibt.

Wie du RAG testest: Evals

Ob ein RAG-System gut antwortet, lässt sich nicht durch Ausprobieren beurteilen. Du brauchst Evals: eine Liste echter Fragen mit der erwarteten Antwort und der Quelle, in der sie steht. Für das Beispiel wären das Fragen aus den Tickets der Hotline.

Prüfe zwei Dinge getrennt:

• Findet die Suche die richtigen Abschnitte? Steht die erwartete Quelle unter den Treffern? Wenn nicht, liegt der Fehler bei Chunking, Embeddings oder Filtern, und das beste Modell hilft nicht.
• Antwortet das Modell richtig aus den Treffern? Stimmt die Antwort, nennt sie die richtige Quelle, und sagt das System „steht nicht drin", wenn die Antwort fehlt?

Dazu gehören Fragen, die bewusst schiefgehen sollen: Fragen ohne Antwort in den Dokumenten, Fragen zu veralteten Versionen und Fragen von Personen ohne Zugriff auf die passende Quelle. Lass die Evals nach jeder Änderung laufen, also bei neuen Dokumenten, anderem Chunking und jedem Modellwechsel.

Datenschutz in Kürze

Die Grundlagen stehen ausführlicher im Chatbot-Artikel. Für RAG kommt hinzu, dass deine Dokumente an mehreren Stellen liegen: im Quellsystem, in der Vektordatenbank und bei jeder Anfrage beim Modellanbieter.

• Auftragsverarbeitung: Mit jedem Dienst, der Inhalte mit Personenbezug verarbeitet, brauchst du einen Vertrag nach Art. 28 DSGVO. Das gilt für den Anbieter des Sprachmodells, des Embedding-Modells und der gehosteten Vektordatenbank.
• EU-Hosting: Wähle für Datenbank und Modelle wo möglich Rechenzentren in der EU und prüfe, dass API-Daten nicht zum Training genutzt werden.
• Drittland: Sitzt ein Anbieter in den USA oder einem anderen Drittland, braucht die Übermittlung eine Grundlage nach Art. 44 ff. DSGVO, etwa eine Zertifizierung unter dem EU-US Data Privacy Framework oder Standardvertragsklauseln im DPA.
• Löschen: Wird ein Dokument im Quellsystem gelöscht oder muss eine Person nach Art. 17 DSGVO gelöscht werden, gilt das auch für Abschnitte und Vektoren im Index und für gespeicherte Chatverläufe.
• Lokale Modelle: Embedding- und Sprachmodelle gibt es auch als offene Modelle, die auf deinem eigenen Server laufen. Dann verlassen die Dokumente dein Haus nicht. Der Preis dafür ist Betriebsaufwand und meist eine geringere Antwortqualität als bei den großen Modellen. Prüfe mit deinen Evals, ob sie für deine Fragen reicht.

Das ist keine Rechtsberatung; die Prüfung für deinen Fall gehört zu deiner Datenschutzbeauftragten oder deinem Datenschutzbeauftragten.

Fazit

• RAG gibt einem Sprachmodell pro Frage die passenden Abschnitte aus deinen Dokumenten und lässt es mit Quellenangabe antworten.
• Erst prüfen, ob ein langer Prompt reicht. Unter etwa 500 Seiten und ohne unterschiedliche Rechte ist das oft der einfachere Weg.
• Die Qualität entsteht vor dem Modell: saubere Dokumente, Chunking entlang der Struktur, aktueller Index und Rechte, die bei der Suche gelten.
• Ohne Evals keine Aussage darüber, ob es funktioniert. Teste Suche und Antwort getrennt, mit echten Fragen.

Stand der Quellen: 11. November 2026.