RAG verstehen: Wie KI auf Unternehmenswissen zugreifen kann

Ein Sprachmodell kann erstaunlich viele Fragen beantworten. Schwierig wird es jedoch, sobald Informationen benötigt werden, die nicht Bestandteil seines Trainings waren.

Interne Dokumentationen, Produktinformationen, Verträge, Support-Dokumente oder aktuelle Unternehmensdaten kennt ein öffentliches Sprachmodell normalerweise nicht.

Man könnte versuchen, diese Informationen direkt in den Prompt zu schreiben. Bei einigen wenigen Seiten funktioniert das durchaus. Bei tausenden Dokumenten ist dieser Ansatz jedoch nicht mehr praktikabel.

Genau hier kommt Retrieval-Augmented Generation, kurz RAG, ins Spiel.

Was ist RAG wirklich?

RAG kombiniert ein Sprachmodell mit einer externen Wissensquelle.

Statt vom Modell zu erwarten, dass es die Antwort bereits kennt, wird zunächst nach relevanten Informationen gesucht. Diese Informationen werden anschließend zusammen mit der eigentlichen Frage an das Sprachmodell übergeben.

Der grundlegende Ablauf sieht so aus:

Das Sprachmodell bekommt damit zusätzlichen Kontext, auf dessen Grundlage es die Antwort erzeugen kann.

Das ist ein wichtiger Unterschied: RAG bringt dem Modell das Unternehmenswissen nicht dauerhaft bei.

Die relevanten Informationen werden erst zur Laufzeit gesucht und dem Modell für die konkrete Anfrage zur Verfügung gestellt.

Warum reicht ein LLM allein nicht?

Ein Large Language Model besitzt keine klassische Wissensdatenbank, in der Informationen wie Datensätze gespeichert und gezielt abgerufen werden.

Das Wissen eines trainierten Modells steckt verteilt in seinen Parametern. Daraus kann das Modell sehr überzeugende Antworten generieren. Es kann aber nicht garantieren, dass eine bestimmte Information korrekt, aktuell oder überhaupt vorhanden ist.

Für Unternehmensanwendungen entstehen daraus mehrere Probleme:

• interne Dokumente waren nicht Bestandteil des Trainings
• Informationen können sich nach dem Training geändert haben
• Antworten können plausible, aber falsche Aussagen enthalten
• die Herkunft einer Aussage ist häufig nicht nachvollziehbar
• Zugriffsrechte auf Unternehmensinformationen müssen berücksichtigt werden

RAG verschiebt deshalb einen Teil der Verantwortung aus dem Sprachmodell heraus.

Die Anwendung sucht selbst nach geeigneten Informationen und stellt sie dem Modell zur Verfügung.

Die RAG-Pipeline

Ein produktives RAG-System besteht aus deutlich mehr als einem Sprachmodell und einer Vektordatenbank.

Typischerweise gibt es zunächst eine Ingestion-Pipeline, die Wissen für die spätere Suche vorbereitet.

Dabei lassen sich zwei Prozesse unterscheiden.

Die linke beziehungsweise obere Seite bereitet das Wissen vor. Dokumente werden eingelesen, zerlegt und indexiert.

Die zweite Seite läuft bei einer Benutzeranfrage. Die Anwendung sucht passende Inhalte und gibt sie an das Sprachmodell weiter.

Warum Dokumente in Chunks zerlegt werden

Angenommen, ein Unternehmen besitzt ein technisches Handbuch mit 600 Seiten.

Es wäre weder sinnvoll noch wirtschaftlich, dieses vollständige Handbuch bei jeder Frage an das Sprachmodell zu senden.

Stattdessen wird das Dokument in kleinere Abschnitte zerlegt, sogenannte Chunks.

Beispielsweise:

Dokument
│
├── Chunk 1: Installation
├── Chunk 2: Konfiguration
├── Chunk 3: Benutzerverwaltung
├── Chunk 4: Backup
├── Chunk 5: Wiederherstellung
└── ...

Bei der Frage

Wie kann ich ein Backup wiederherstellen?

soll das Retrieval möglichst die Abschnitte über Backup und Wiederherstellung finden und nicht das gesamte Handbuch liefern.

Die Größe und Überlappung dieser Chunks hat erheblichen Einfluss auf die Qualität eines RAG-Systems.

Zu kleine Chunks können wichtigen Zusammenhang verlieren. Zu große Chunks enthalten dagegen viel irrelevanten Kontext.

Chunking ist deshalb keine nebensächliche technische Einstellung, sondern eine der Architekturentscheidungen eines RAG-Systems.

Embeddings verstehen

Damit relevante Textabschnitte gefunden werden können, braucht das System eine Möglichkeit, deren Bedeutung miteinander zu vergleichen.

Dafür werden häufig Embeddings verwendet.

Ein Embedding-Modell wandelt Text in einen Vektor aus Zahlen um.

Vereinfacht:

"Wie erstelle ich eine Datensicherung?"
                ↓
         Embedding-Modell
                ↓
 [0.18, -0.42, 0.73, ..., 0.11]

Ein anderer Text wie

„Backup der Datenbank erstellen“

erzeugt einen anderen Vektor. Liegen beide Vektoren im Vektorraum nahe beieinander, interpretiert das System die Texte als semantisch ähnlich.

Dadurch muss die Suchanfrage nicht exakt dieselben Wörter enthalten wie das Dokument.

Das unterscheidet semantische Suche von einer einfachen Stichwortsuche.

Was macht ein Vector Store?

Die Embeddings der einzelnen Chunks müssen gespeichert und effizient durchsucht werden können.

Dafür werden häufig Vektordatenbanken oder Datenbanken mit Vektorsuche eingesetzt.

Bekannte Beispiele sind:

• pgvector für PostgreSQL
• Qdrant
• Weaviate
• Pinecone
• Chroma

Bei einer Anfrage wird ebenfalls ein Embedding erzeugt. Anschließend sucht das System nach den ähnlichsten gespeicherten Vektoren.

Der Vector Store beantwortet die ursprüngliche Frage dabei nicht.

Er findet lediglich Inhalte, die wahrscheinlich relevant sind.

Diese Trennung ist wichtig: Retrieval und Generation sind zwei unterschiedliche Aufgaben.

Ein minimales Beispiel

Das Grundprinzip einer semantischen Suche lässt sich auch ohne großes RAG-Framework nachvollziehen.

Vereinfacht könnte eine Anwendung so aussehen:

question = "Wie kann ich ein Backup wiederherstellen?"

query_embedding = embedding_model.embed(question)

documents = vector_store.search(
    query_embedding,
    limit=5,
)

context = "\n\n".join(document.text for document in documents)

response = llm.generate(
    f"""
    Beantworte die Frage ausschließlich anhand des bereitgestellten Kontexts.

    Kontext:
    {context}

    Frage:
    {question}
    """
)

Produktive Systeme benötigen natürlich zusätzliche Komponenten. Das Beispiel zeigt aber den entscheidenden Mechanismus.

Zuerst wird gesucht. Danach wird generiert.

RAG ist mehr als Vektorsuche

Eine häufige Vereinfachung lautet:

RAG bedeutet, Dokumente in eine Vektordatenbank zu schreiben.

Das greift zu kurz.

Ein gutes Retrieval-System kann beispielsweise zusätzlich verwenden:

• klassische Volltextsuche
• Metadatenfilter
• Benutzerberechtigungen
• Keyword-Suche
• semantische Suche
• Re-Ranking
• mehrere Retrieval-Strategien

Eine Anfrage nach einer internen Richtlinie könnte beispielsweise zunächst auf Dokumente einer bestimmten Abteilung eingeschränkt werden. Erst innerhalb dieser Dokumente findet anschließend eine semantische Suche statt.

Moderne RAG-Systeme kombinieren deshalb häufig mehrere Suchverfahren.

RAG, Prompting oder Fine-Tuning?

Diese drei Begriffe werden häufig miteinander vermischt, lösen aber unterschiedliche Probleme.

Wenn sich Unternehmenswissen regelmäßig verändert, ist Fine-Tuning normalerweise kein Ersatz für RAG.

Eine neue Produktdokumentation kann bei einem RAG-System neu indexiert werden. Das Basismodell muss dafür nicht neu trainiert werden.

Eine hilfreiche Faustregel lautet:

In realen Systemen können diese Ansätze natürlich miteinander kombiniert werden.

Wie sieht RAG im Unternehmen aus?

Ein Unternehmenssystem besteht meist aus wesentlich mehr Komponenten als das vereinfachte RAG-Diagramm.

Neben Retrieval und Sprachmodell werden beispielsweise Authentifizierung, Berechtigungen, Monitoring und Dokumentverwaltung benötigt.

Besonders die Berechtigungen sind wichtig.

Wenn Mitarbeiter A ein Dokument im ursprünglichen System nicht lesen darf, darf ein RAG-System dessen Inhalt nicht plötzlich über eine KI-Antwort zugänglich machen.

Ein produktives RAG-System muss deshalb nicht nur relevante Informationen finden, sondern auch wissen, welche Informationen für den jeweiligen Benutzer überhaupt zugänglich sind.

Was RAG nicht automatisch löst

RAG wird manchmal dargestellt, als würden dadurch Halluzinationen verschwinden.

Das stimmt nicht.

Ein RAG-System kann weiterhin falsche Antworten erzeugen.

Das Retrieval kann beispielsweise die falschen Dokumente finden. Ein relevanter Chunk kann fehlen. Dokumente können veraltet oder widersprüchlich sein. Und selbst mit korrektem Kontext kann das Sprachmodell Informationen falsch interpretieren.

Deshalb müssen bei RAG mindestens zwei unterschiedliche Qualitätsfragen betrachtet werden:

Retrieval:
Haben wir die richtigen Informationen gefunden?

Generation:
Hat das Modell aus diesen Informationen eine korrekte Antwort erzeugt?

Genau daraus entsteht ein weiteres wichtiges Gebiet moderner KI-Systeme: Evaluation.

Es reicht nicht zu testen, ob die Anwendung technisch eine Antwort liefert. Man muss messen, ob Retrieval und Antwort tatsächlich gut sind.

Wann ist RAG sinnvoll?

RAG ist besonders interessant, wenn ein Sprachmodell auf Informationen zugreifen soll, die:

• unternehmensintern sind
• regelmäßig aktualisiert werden
• sehr umfangreich sind
• aus vielen Dokumenten stammen
• mit Quellen nachvollziehbar bleiben sollen

Typische Anwendungen sind interne Wissensassistenten, technischer Support, Produktdokumentationen, Richtlinien, Vertragsarchive oder große Dokumentensammlungen.

Nicht jede KI-Anwendung benötigt jedoch RAG.

Wenn alle notwendigen Informationen bereits in einer kurzen Anfrage enthalten sind, bringt eine zusätzliche Retrieval-Infrastruktur möglicherweise nur unnötige Komplexität.

Fazit

Retrieval-Augmented Generation erweitert ein Sprachmodell um externes Wissen.

Das grundlegende Prinzip ist einfach:

Frage
  ↓
relevantes Wissen suchen
  ↓
Wissen als Kontext bereitstellen
  ↓
Antwort generieren

Die eigentliche Herausforderung beginnt jedoch hinter diesem einfachen Modell.

Dokumente müssen sinnvoll zerlegt, Embeddings erzeugt, Informationen zuverlässig gefunden, Zugriffsrechte berücksichtigt und die Qualität des Gesamtsystems gemessen werden.

RAG ist deshalb weniger ein einzelnes KI-Feature als eine Architektur für wissensbasierte KI-Anwendungen.

Und genau diese Sichtweise ist entscheidend, wenn aus einer beeindruckenden Demo ein verlässliches Unternehmenssystem werden soll.