BECHERCustom Software Development

Unternehmenswissen.
Präzise abrufbar.

RAG steht für Retrieval-Augmented Generation – sinngemäß: Antworten werden durch gezielt abgerufenes Wissen erweitert. So verbindet das System Ihre aktuellen internen Informationen mit einem Sprachmodell und liefert verständliche, überprüfbare Antworten mit Quellen.

Von ·

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 Frage wird um diese geprüften Fundstellen 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. Ä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 nur die stärksten Treffer, klare Antwortregeln und Referenzen auf die Originalquellen. So bleibt das System aktueller, kontrollierbarer und meist günstiger als ein spezielles Modelltraining.

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. Der Anfragepfad holt den richtigen Kontext in 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. Für die spätere Evaluation entsteht ein kleiner, repräsentativer Goldstandard.

    • Welche Fragen muss das System sicher beantworten?
    • Wann soll es bewusst „nicht genug Information“ melden?
    • Welche 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 Source of Truth behalten
    • Berechtigungen bereits beim Retrieval durchsetzen
    • Lösch- und Aktualisierungsprozesse festlegen
  3. 03

    Dokumente fachgerecht aufbereiten

    Überschriften, Tabellen und Seitenbezüge erhalten. Chunks entlang semantischer Grenzen bilden, statt Texte blind nach Zeichenanzahl zu schneiden.

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

    Embedding und Vector Store auswählen

    Dimension, Sprache, Datenmenge, Filterbedarf und Betriebsmodell bestimmen. Für viele Business-Anwendungen ist eine verwaltete Lösung oder PostgreSQL mit Vektor-Erweiterung ausreichend.

    • 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

    Semantische und klassische Stichwortsuche kombinieren, Filter anwenden und die Kandidaten mit einem Reranker neu bewerten.

    • Top-k nicht pauschal wählen, sondern messen
    • Abkürzungen und Fachbegriffe gezielt behandeln
    • Dublettenkontrolle und Mindestscore vorsehen
  6. 06

    LLM-Aufbereitung begrenzen

    Der System-Prompt verlangt eine Antwort ausschließlich aus dem gelieferten Kontext, trennt Fakten von Schlussfolgerungen und erzeugt anklickbare Quellen.

    • Kontext gegen Prompt Injection absichern
    • Belegpflicht für zentrale Aussagen definieren
    • Fallback bei fehlenden oder widersprüchlichen Quellen
  7. 07

    Qualität kontinuierlich betreiben

    Retrieval und Antwort getrennt evaluieren. Nutzerfeedback, Groundedness, Quellenabdeckung, Latenz 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?

Recall, Precision, Filter, Hybrid Search und Reranking werden mit echten Beispielfragen geprüft.

Generation

Bleibt die Antwort im belegten Kontext?

Groundedness, Zitierqualität, Vollständigkeit und ein kontrollierter „weiß ich nicht“-Pfad verhindern falsche Sicherheit.

Praxisregel

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

Weiterlesen · Primärquellen

Technische Grundlagen

Originalpaper: Retrieval-Augmented Generation (Lewis et al.)↗ AWS: So funktionieren Bedrock Knowledge Bases↗ AWS: Managed und Customer-managed Knowledge Bases↗ AWS Well-Architected: Datenarchitektur für GenAI↗

Vom Wissen zum Produkt

Welcher Prozess braucht
bessere Antworten?

CSD Becher konzipiert und entwickelt RAG-Systeme vom ersten Datencheck bis zum überwachten Betrieb.

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