Einführung in RAG

Was ist RAG?

RAG (Retrieval-Augmented Generation) ist eine Architektur, die ein Information-Retrieval-System mit einem großen Sprachmodell (LLM) kombiniert. Anstatt sich allein auf das interne Wissen des Modells zu verlassen, sucht RAG zunächst in einer Datenbank nach relevanten Informationen und injiziert diese anschließend in den Prompt, um eine Antwort zu generieren, die auf realen Daten basiert.

Warum ist RAG unverzichtbar geworden? Weil LLMs drei fundamentale Einschränkungen aufweisen, die sich alle im selben Moment zeigen: wenn jemand eine Frage zu Ihrem Unternehmen stellt. Erstens eingefrorenes Wissen: Ein Modell weiß nur, was es während des Trainings gelernt hat, und kennt daher nichts über Ihren Preisanpassung vom letzten Monat. Zweitens Halluzinationen: Wenn nach einem internen Verfahren gefragt wird, das es nicht kennt, liefert das Modell eine plausible, aber völlig falsche Antwort mit absoluter Sicherheit. Drittens ist interne Daten per Design unerreichbar: Das Modell hat keinen Zugriff auf Ihre internen Dokumente, und Sie wollen diese ohnehin nicht in einen Trainingskorpus einfließen lassen.

RAG löst alle drei Probleme, indem es einen Abrufschritt vor der Generierung hinzufügt. Das Modell hört auf, als abzufragender Speicher zu fungieren, und wird zu einem Schreibmaschinen-Engine, die auf von Ihnen kontrollierten Dokumenten angewendet wird.

RAG-Architektur

Die RAG-Pipeline gliedert sich in zwei Hauptphasen: eine Indexierungsphase, die im Voraus durchgeführt wird, gefolgt von einem Zyklus, der für jede Frage ausgeführt wird. Die folgenden vier Schritte bilden das Rückgrat der kommenden Lektionen.

Nur der erste Schritt erfordert erhebliche Rechenzeit; die nächsten drei laufen in weniger als einer Sekunde ab. Dies ist der Grund, warum die Architektur für einen kontinuierlich abgefragten Dienst machbar ist: Sie kodieren Ihre Dokumentation einmal, und jede Frage kostet nur einen Embedding-Aufruf und einen Generierungsaufruf.

RAG im Vergleich zum Feinabstimmung

RAG und Feinabstimmung lösen ähnliche Probleme, aber auf unterschiedliche Weise. Die folgende Tabelle, hier als Python-Struktur dargestellt, stellt die beiden Ansätze in fünf Kriterien gegeneinander.

# RAG vs. Feinabstimmung Vergleich

comparison = {
    "RAG": {
        "update": "Sofortig (Dokumente hinzufügen/entfernen)",
        "cost": "Niedrig (kein Neutraining)",
        "traceability": "Ausgezeichnet (Sie wissen, woher die Information stammt)",
        "hallucinations": "Reduziert (Antworten basieren auf Quellen)",
        "use_cases": "Dokumentation, FAQs, Wissensdatenbanken",
    },
    "Feinabstimmung": {
        "update": "Teuer (Neutraining erforderlich)",
        "cost": "Hoch (GPUs, Zeit, annotierte Daten)",
        "traceability": "Niedrig (Wissen ist im Modell 'gebacken')",
        "hallucinations": "Möglich (Modell kann extrapolieren)",
        "use_cases": "Schreibstil, Ausgabeformat, spezifische Aufgaben",
    },
}

Die Zeile „Update” entscheidet oft. Die Behebung eines Fehlers in einem Verfahren bedeutet bei RAG das Ersetzen einer Datei und das Neukodieren weniger Abschnitte – eine Angelegenheit von Minuten. Bei der Feinabstimmung erfordert dieselbe Korrektur das Neuaufbauen eines Datensatzes und das erneute Durchführen des Trainings, ohne Garantie dafür, dass die alte Version wirklich vergessen wurde. In der Praxis ist RAG in der Regel die beste Wahl für die Integration sich entwickelnden faktischen Wissens, während die Feinabstimmung besser geeignet ist, um das Verhalten oder den Stil des Modells zu ändern. Die beiden Ansätze schließen sich nicht gegenseitig aus: Ein Modell, das feinabgestimmt wurde, um in dem von Ihrem Unternehmen erwarteten Format zu antworten, kann weiterhin durch RAG gespeist werden.

Die Technologie-Stack

Das Aufbau einer RAG-Pipeline mit Mistral erfordert lediglich drei Bibliotheken, und die Installation erfolgt in einer Zeile.

# Wesentliche Abhängigkeiten
# pip install mistralai faiss-cpu numpy

from mistralai.client import Mistral  # LLM + Embeddings
import faiss                    # Vektorspeicher
import numpy as np              # Vektorberechnungen

Die mistralai-SDK verwaltet beide Modellaufrufe eigenständig: Embeddings mit mistral-embed und Generierung mit mistral-large. faiss-cpu, die Bibliothek von Meta für schnellen Vektorsuch, übernimmt, sobald eine erschöpfende Vergleichung zu langsam wird – jenseits von einigen zehntausend Vektoren. Schließlich übernimmt numpy die Vektor-Matrix-Operationen, die alles zusammenhalten. In den folgenden Lektionen bauen Sie jeden Schritt dieser Pipeline von Grund auf auf, von der Datenvorbereitung bis zur Antwortgenerierung.

Wann RAG verwenden?

RAG eignet sich besonders gut, wenn Sie interne Dokumente – technische Dokumentation, Verfahrensanweisungen, Verträge – besitzen, die kein öffentliches Modell jemals gesehen hat. Es ist auch die richtige Wahl, wenn sich Informationen häufig ändern: Preise, Verfügbarkeit, Vorschriften. Ein Dienst, der veraltete Preise zitiert, kostet mehr als einer, der gar nicht antwortet.

Drei weitere Situationen weisen natürlich auf RAG hin. Erstens der Bedarf an Nachvollziehbarkeit, wenn Sie wissen müssen, woher jede Information stammt – eine gängige Anforderung in regulierten Sektoren und in jedem Fall eine Bedingung für das Vertrauen der Nutzer. Zweitens das Ziel, Halluzinationen zu reduzieren, da ein Modell mit dem richtigen Auszug keinen Grund hat, etwas zu erfinden. Drittens das Budget: Wenn Sie die Ressourcen oder annotierten Daten für eine Feinabstimmung nicht haben, bietet RAG einen praktischen Weg mit nur wenigen Dokumenten und einigen Stunden Arbeit.

Kernaussagen

• RAG kombiniert Information-Retrieval mit LLM-Generierung
• Die Architektur gliedert sich in: Indexierung, Abruf, Anreicherung, Generierung
• RAG ist gegenüber der Feinabstimmung vorzuziehen, wenn es um sich entwickelndes faktisches Wissen geht
• Mistral bietet beide wesentlichen Bausteine: Embeddings und LLM
• FAISS ist die Referenzbibliothek für Vektorsuche