Unternehmenswissen.
Präzise abrufbar.

RAG steht für Retrieval-Augmented Generation – sinngemäß: Antworten werden durch gezielt abgerufenes Wissen erweitert. Das System sucht passende interne Informationen und nutzt ein großes Sprachmodell (Large Language Model, kurz LLM), um daraus Antworten mit Quellenhinweisen zu formulieren.

Die Grundidee

Erst suchen.
Dann antworten.

Ein Sprachmodell kennt nicht automatisch Ihre Verträge, Handbücher, Projektdokumente oder aktuellen Produktdaten. RAG sucht deshalb zuerst die relevanten Textstellen und gibt sie dem Modell als begrenzten, nachprüfbaren Kontext.

RRetrieval
Abruf: Das System sucht die zur Frage passenden Textstellen und Daten.
AAugmented
Erweitert: Die Anfrage wird um gefundene, für den Nutzer freigegebene Textstellen ergänzt.
GGeneration
Erzeugung: Das Sprachmodell formuliert daraus eine Antwort mit Quellen.

Dafür werden Dokumente in sinnvolle Abschnitte zerlegt. Ein Embedding-Modell übersetzt jeden Abschnitt in einen Zahlenvektor, den eine Vektordatenbank für die Suche speichert. Ähnliche Bedeutungen liegen im Vektorraum nahe beieinander – auch wenn die Formulierungen unterschiedlich sind. So kann eine Frage nach einer Kündigungsfrist auch einen Abschnitt finden, der stattdessen vom Vertragsende spricht. Der passende Kontext wird anschließend gefiltert und nach Relevanz sortiert.

Das LLM erhält anschließend die ausgewählten Treffer, klare Antwortregeln und Verweise auf die Originalquellen. Neue Informationen lassen sich über den Suchindex bereitstellen, ohne das Sprachmodell dafür erneut zu trainieren. Passende Treffer sind jedoch nicht automatisch richtige Fakten: Quellenqualität, Aktualität und Antworttreue müssen geprüft werden.

Wann lohnt sich RAG?

Wenn Wissen über mehrere Systeme verteilt ist, sich häufig ändert, wiederholt gesucht wird oder Antworten zwingend Quellen und Zugriffsrechte berücksichtigen müssen.

RAG-Pilot und Umsetzung ansehen ↗
AWS-Erklärung des RAG-Datenflusses ↗

Systemdiagramm

Vom Dokument zur belegten Antwort

Zwei Abläufe greifen ineinander: Die Aufbereitung macht Wissen suchbar. Bei einer Frage sucht das System passende Abschnitte als Grundlage für die Antwort.

Aufbereitung Anfrage

Verständliche Anleitung

RAG in sieben Schritten.

Ein gutes System beginnt nicht mit der Vector-Datenbank, sondern mit einer klaren Frage: Welche Entscheidung soll mit welchem Wissen zuverlässiger werden?

  1. 01

    Anwendungsfall und Messlatte definieren

    Beispielfragen, Nutzergruppen und erwartete Antwortform festlegen. Fachlich geprüfte Musterantworten bilden einen Referenzsatz, den sogenannten Goldstandard, für spätere Qualitätstests.

    • Welche Fragen muss das System sicher beantworten?
    • Wann soll es bewusst „nicht genug Information“ melden?
    • Welche Antwortzeit (Latenz) und welche Kosten pro Anfrage sind akzeptabel?
  2. 02

    Quellen, Rechte und Aktualität ordnen

    Nur freigegebene Quellen aufnehmen. Eigentümer, Vertraulichkeit, Gültigkeitsdatum und Zielgruppe als Metadaten erfassen.

    • Originale unverändert als nachvollziehbare Referenz behalten
    • Berechtigungen bereits beim Retrieval durchsetzen
    • Lösch- und Aktualisierungsprozesse festlegen
  3. 03

    Dokumente fachgerecht aufbereiten

    Überschriften, Tabellen und Seitenbezüge erhalten. Dokumente in inhaltlich zusammenhängende Abschnitte (Chunks) zerlegen, statt sie nur nach Zeichenanzahl zu schneiden.

    • Chunk-Größe anhand echter Fragen testen
    • Dokumenttitel und Abschnittspfad mitführen
    • Fehler bei Texterkennung (OCR) und Dokumentauswertung (Parsing) sichtbar machen
  4. 04

    Embedding und Vector Store auswählen

    Embedding-Modell und Vektorspeicher (Vector Store) müssen zusammenpassen. Sprache, Datenmenge, benötigte Filter und Betriebsaufwand bestimmen die Auswahl. Möglich sind etwa verwaltete Vektordatenbanken oder PostgreSQL mit Vektor-Erweiterung.

    • Dasselbe Embedding-Modell für Dokumente und Fragen verwenden
    • Metadatenfilter und Mandantentrennung früh testen
    • Indexversion und Embedding-Version protokollieren
  5. 05

    Retrieval-Pipeline abstimmen

    Prüfen, ob die Kombination aus Bedeutungs- und Stichwortsuche (Hybrid Search) bessere Treffer liefert. Filter begrenzen die Suche auf erlaubte Inhalte; ein Reranker kann die Treffer anschließend genauer nach Relevanz sortieren.

    • Anzahl der übernommenen Treffer (Top-k) mit Beispielfragen bestimmen
    • Abkürzungen und Fachbegriffe gezielt behandeln
    • Dublettenkontrolle und Mindestscore vorsehen
  6. 06

    LLM-Aufbereitung begrenzen

    Die Antwortregeln im System-Prompt verlangen, nur den gelieferten Kontext zu verwenden und Fakten von Schlussfolgerungen zu trennen. Ob die Antwort diese Regeln einhält und ihre Quellen tatsächlich passen, wird zusätzlich geprüft.

    • Manipulative Anweisungen in Dokumenten (Prompt Injection) als Angriff behandeln
    • Belegpflicht für zentrale Aussagen definieren
    • Bei fehlenden oder widersprüchlichen Quellen eine klare Rückmeldung statt einer Vermutung vorsehen
  7. 07

    Qualität kontinuierlich betreiben

    Suchergebnisse und Antworten getrennt bewerten. Prüfen, ob Aussagen durch die gefundenen Quellen gedeckt sind (Groundedness), und Nutzerfeedback, Quellenabdeckung, Antwortzeit und Kosten beobachten.

    • Regressionstests bei Modell- oder Indexwechseln
    • Fehlfragen in den Goldstandard übernehmen
    • Daten- und Promptversionen gemeinsam ausrollen

Qualität vor Demo-Effekt

Drei Stellen entscheiden.

Ein überzeugendes Modell kann schwaches Retrieval sprachlich kaschieren. Deshalb müssen die Ebenen einzeln messbar bleiben.

Daten

Ist die richtige Information überhaupt im System?

Quellenabdeckung, Aktualität, Parsing-Qualität und Berechtigungen sind die Grundlage jeder Antwort.

Retrieval

Wird der richtige Abschnitt zuverlässig gefunden?

Mit echten Beispielfragen prüfen, wie viele relevante Stellen gefunden werden (Recall) und wie viele Treffer tatsächlich passen (Precision). Dabei auch Filter und Trefferrangfolge testen.

Generation

Bleibt die Antwort im belegten Kontext?

Quellenbezug, passende Zitate, Vollständigkeit und eine klare Rückmeldung bei fehlendem Wissen helfen, unbelegte Antworten zu erkennen und zu begrenzen.

Praxisregel

Wenn die gesuchte Passage nicht in den Top-Treffern liegt, kann auch das beste LLM keine verlässliche Antwort daraus erzeugen.

Vom Wissen zum Produkt

Welcher Prozess braucht
bessere Antworten?

CSD Becher konzipiert und entwickelt RAG-Systeme vom Datencheck über den Pilot bis zur Einführung und Betriebsübergabe. Weitere Begleitung erfolgt nach Vereinbarung.

Nächster Schritt

info@csd-becher.de ↗

Bringen Sie drei typische Fragen und zwei repräsentative Dokumente mit. Daraus lässt sich bereits viel ableiten.

RAG-Projekt besprechen