12 Min. Lesezeit · KI · Juni 2026

RAG über firmeneigene Dokumente aufbauen.

In jedem Unternehmen schlummert Wissen in Handbüchern, Richtlinien, Angeboten, Protokollen und E-Mails — verstreut über Laufwerke, SharePoint und Postfächer. Ein Sprachmodell kennt dieses Wissen nicht, denn es war nie Teil seines Trainings. Retrieval-Augmented Generation, kurz RAG, schließt diese Lücke: Das Modell bekommt die passenden Stellen aus Ihren eigenen Dokumenten zur Frage mitgeliefert und antwortet auf dieser Grundlage — mit Quellenangabe. Richtig gebaut wird daraus ein verlässlicher Assistent, falsch gebaut eine Maschine, die selbstbewusst danebenliegt.

Was RAG eigentlich tut — und was nicht.

RAG ist im Kern erstaunlich schlicht: Statt das Modell mit Firmenwissen zu trainieren, durchsucht man bei jeder Frage eine Wissensbasis nach den thematisch passendsten Textstellen und gibt sie dem Modell zusammen mit der Frage als Kontext mit. Das Modell formuliert dann eine Antwort aus genau diesen Stellen. Es „lernt“ nichts dauerhaft dazu — es liest jedes Mal frisch die mitgelieferten Auszüge.

Dieser Ansatz hat handfeste Vorteile gegenüber dem Fine-Tuning, also dem Nachtrainieren eines Modells auf eigenen Daten. Aktualisierungen sind trivial: Ein geändertes Dokument wird neu eingelesen, schon ist das Wissen aktuell — kein Training nötig. Quellen lassen sich mitliefern, sodass jede Aussage nachvollziehbar bleibt. Und sensible Daten bleiben in Ihrer Datenbank, statt in Modellgewichte einzufließen. Was RAG dagegen nicht leistet: Es macht das Modell nicht schlauer und ersetzt kein echtes Verständnis. Wenn die richtige Antwort in keinem Ihrer Dokumente steht, kann auch RAG sie nicht herbeizaubern.

Die Pipeline in fünf Schritten.

Ein RAG-System zerfällt sauber in zwei Phasen: das einmalige (bzw. periodische) Einlesen der Dokumente und das wiederholte Beantworten von Fragen. Im Detail durchläuft es fünf Stufen:

Einlesen & Aufbereiten: Dokumente werden aus ihren Quellen geholt (PDF, Word, Confluence, SharePoint, Tickets) und in reinen, strukturierten Text überführt. Tabellen, Überschriften und Metadaten wie Quelle und Datum bleiben erhalten.
Chunking: Lange Dokumente werden in handliche Abschnitte zerlegt. Diese Stufe entscheidet maßgeblich über die spätere Qualität — dazu gleich mehr.
Einbetten (Embeddings): Jeder Abschnitt wird in einen Zahlenvektor übersetzt, der seine Bedeutung repräsentiert. Inhaltlich ähnliche Texte landen im Vektorraum nahe beieinander.
Abrufen (Retrieval): Zur Frage wird ebenfalls ein Vektor gebildet, und die ähnlichsten Abschnitte werden aus der Vektordatenbank geholt.
Antworten (Generation): Frage und gefundene Abschnitte gehen ans Sprachmodell, das daraus eine Antwort mit Quellenangaben formuliert.

Chunking: die unterschätzte Schlüsselstelle.

Die meisten enttäuschenden RAG-Systeme scheitern nicht am Modell, sondern am Chunking. Schneidet man zu grob, enthält ein Abschnitt zu viele Themen, und der Abruf liefert verwässerte Treffer. Schneidet man zu fein, reißt man Zusammenhänge auseinander — die Antwort auf eine Frage steht dann verteilt über drei Abschnitte, von denen nur einer gefunden wird.

Bewährt hat sich, an natürlichen Grenzen zu schneiden: Überschriften, Absätze, Listenpunkte. Ein Abschnitt sollte einen Gedanken vollständig enthalten. Hilfreich ist eine leichte Überlappung zwischen benachbarten Abschnitten, damit ein Satz an der Schnittkante nicht verlorengeht. Entscheidend ist außerdem, jedem Abschnitt Metadaten mitzugeben — aus welchem Dokument, welcher Version, welchem Datum er stammt. Diese Metadaten sind später Gold wert: für Quellenangaben, für Filter („nur Dokumente nach 2025“) und für das Aussortieren veralteter Stände.

Ein minimales Retrieval-Setup.

Der Kern eines RAG-Systems lässt sich überraschend kompakt darstellen. Das folgende vereinfachte Beispiel zeigt das Prinzip: Abschnitte einbetten, ähnlichste finden, dem Modell mit klarer Anweisung übergeben.

import anthropic

an = anthropic.Anthropic()

# 'suche' liefert die k aehnlichsten Abschnitte
# aus der Vektordatenbank, jeweils mit Quelle.
def beantworte(frage: str, k: int = 5) -> str:
    treffer = suche(frage, k=k)  # Vektor-Suche

    kontext = "\n\n".join(
        f"[Quelle: {t['quelle']}]\n{t['text']}"
        for t in treffer)

    msg = an.messages.create(
        model="claude-sonnet-4-5",
        max_tokens=800,
        system=("Beantworte die Frage AUSSCHLIESSLICH "
                "anhand des Kontexts. Nenne nach jeder "
                "Aussage die Quelle in Klammern. Wenn "
                "die Antwort nicht im Kontext steht, "
                "sage das offen. Erfinde nichts."),
        messages=[{"role": "user", "content":
            f"Kontext:\n{kontext}\n\nFrage: {frage}"}])

    return msg.content[0].text

Zwei Dinge sind hier zentral. Erstens die Systemanweisung: Sie zwingt das Modell, nur aus dem Kontext zu antworten und Wissenslücken offen zuzugeben statt sie zu überspielen. Zweitens das Mitgeben der Quelle pro Abschnitt — nur so kann das Modell belegen, woher eine Aussage stammt. Diese beiden Disziplinen unterscheiden ein vertrauenswürdiges System von einer Plausibilitätsmaschine.

Hybridsuche: Vektoren reichen oft nicht.

Reine Vektorsuche ist stark bei Bedeutungsähnlichkeit, aber schwach bei exakten Begriffen. Wer nach einer konkreten Artikelnummer, einem Vertragsparagraphen oder einem Eigennamen sucht, wird mit semantischer Ähnlichkeit allein oft enttäuscht — der exakte Treffer geht in der „ungefähr passenden“ Masse unter.

Deshalb kombinieren gute Systeme zwei Verfahren: die semantische Vektorsuche und die klassische Stichwortsuche (oft BM25 genannt). Die Ergebnisse beider Verfahren werden zusammengeführt und neu sortiert. Häufig schiebt man noch ein sogenanntes Re-Ranking dahinter: ein spezialisiertes Modell, das die wenigen Kandidaten noch einmal genau gegen die Frage prüft und die wirklich relevanten nach oben sortiert. Dieser Zusatzschritt kostet etwas Zeit, hebt die Antwortqualität aber spürbar — gerade bei großen, heterogenen Wissensbasen.

Ehrlich über die Grenzen.

RAG ist kein Allheilmittel, und seriöse Beratung benennt das. Die typischen Schwachstellen:

Grenze	Was dahintersteckt
Lücken in der Wissensbasis	Was nirgends dokumentiert ist, kann RAG nicht beantworten. „Stillschweigendes“ Erfahrungswissen fehlt.
Veraltete Dokumente	Liegen alte und neue Stände parallel vor, wird mitunter der falsche zitiert. Versionierung und Metadaten sind Pflicht.
Schlechter Abruf	Findet die Suche die richtige Stelle nicht, hilft das beste Modell nichts — die Antwort baut auf den falschen Auszügen auf.
Widersprüchliche Quellen	Stehen zwei Dokumente im Widerspruch, kann das Modell nicht wissen, welches gilt. Es braucht Regeln, welche Quelle Vorrang hat.
Rest-Risiko Halluzination	Auch mit Kontext kann ein Modell eine Aussage leicht verfälschen. Quellenpflicht und Stichproben senken das Risiko, beseitigen es aber nicht.

Keine dieser Grenzen ist ein Ausschlusskriterium — aber jede ist ein Grund, das System mit Prüfpunkten und ehrlicher Erwartungshaltung einzuführen statt mit dem Versprechen der allwissenden Maschine.

Qualität messen statt behaupten.

Ob ein RAG-System taugt, lässt sich nicht erfühlen, sondern muss gemessen werden. Bewährt hat sich, einen Satz realer Fragen mit bekannten, von Fachleuten geprüften Antworten anzulegen — ein Testset aus dem echten Arbeitsalltag. Daran prüft man zwei Dinge getrennt: Findet die Suche die richtigen Stellen (Retrieval-Qualität)? Und baut das Modell daraus eine korrekte, quellenbelegte Antwort (Antwort-Qualität)? Beide Stufen separat zu betrachten ist wichtig, denn ein Fehler kann an der Suche oder an der Formulierung liegen — und die Gegenmittel sind völlig verschieden.

Genauso wertvoll ist Feedback aus dem laufenden Betrieb: Ein simpler Daumen-hoch/-runter pro Antwort, ausgewertet über Wochen, zeigt zuverlässiger als jede Demo, wo das System trägt und wo es hakt.

Kosten und Datenschutz nüchtern betrachtet.

Die laufenden Kosten eines RAG-Systems sind oft niedriger als befürchtet. Embeddings sind günstig, und sie fallen nur beim Einlesen und bei jeder Frage einmal an. Die Antwortkosten entstehen pro Frage am Sprachmodell und bewegen sich je nach Umfang im Cent-Bereich. Wie immer steckt der eigentliche Aufwand nicht im Token-Preis, sondern in der Anbindung der Datenquellen, der Rechte- und Sichtbarkeitslogik und dem laufenden Betrieb.

Beim Datenschutz gilt: Sobald Firmendokumente über eine Cloud-API verarbeitet werden, gehören Auftragsverarbeitungsvertrag, Datenstandort und der Umgang mit personenbezogenen Inhalten geklärt. Besonders heikel ist die Berechtigungsfrage — ein RAG-System darf einem Nutzer nur Stellen zurückliefern, die er auch sehen dürfte. Wer die Zugriffsrechte des Quellsystems ignoriert, baut sich ein Datenleck. Diese Logik gehört von Anfang an mitgedacht, nicht nachträglich verschraubt. Für besonders sensible Umgebungen kann ein lokal betriebenes Modell sinnvoll sein — auf Kosten von Setup-Aufwand und Modellqualität. Dies ist keine Rechtsberatung; die konkrete Ausgestaltung gehört mit der Datenschutzfunktion abgestimmt.

Was ich aus der Praxis mitgebe.

Klein und fokussiert starten. Eine gut gepflegte Wissensdomäne — etwa nur die Produktdokumentation — schlägt ein riesiges, ungeordnetes Sammelsurium. Datenqualität schlägt Datenmenge.
Quellenpflicht ist nicht verhandelbar. Jede Antwort muss zeigen, woraus sie stammt. Das schafft Vertrauen und macht Fehler überhaupt erst überprüfbar.
Retrieval vor Modell optimieren. Die meisten Probleme liegen im Finden, nicht im Formulieren. Erst wenn die richtigen Stellen zuverlässig oben landen, lohnt der Feinschliff am Prompt.
Erfolg messen statt behaupten. Ein Testset und ein Feedback-Knopf sagen mehr als jede Demo. Wie oft trifft das System wirklich? Diese Quote ehrlich erheben.

Sie wollen das Wissen aus Ihren Dokumenten per Frage-Antwort zugänglich machen — mit Quellen und sauberen Zugriffsrechten? Unverbindlich anfragen — wir prüfen Datenquellen, Berechtigungen, Datenschutz und einen sinnvollen Pilot-Bereich.