Retrieval-Augmented Generation (RAG): LLMs mit aktuellem Wissen erweitern

Kernaussage: Retrieval-Augmented Generation (RAG) ist eine Architektur, bei der ein LLM vor der Antwortgenerierung relevante Dokumente aus einer Wissensdatenbank abruft und diese in seine Antwort einbezieht — die Lösung für Halluzinationen und veraltetes Modellwissen.

Was ist RAG?

Retrieval-Augmented Generation (RAG) kombiniert zwei Technologien: Informationsabruf (Retrieval) aus einer Dokumentensammlung und Textgenerierung durch ein Large Language Model. Das Ergebnis: ein System, das auf aktuelle, unternehmensspezifische Informationen zugreifen kann, anstatt sich nur auf sein (potenziell veraltetes oder unvollständiges) Vortraining zu stützen.

Das Grundprinzip: Wenn ein Nutzer eine Frage stellt, sucht das RAG-System zunächst in einer Wissensdatenbank nach den relevantesten Dokumenten oder Textausschnitten (Retrieval). Diese werden dann zusammen mit der Frage an das LLM übergeben (Augmentation), das auf Basis dieser konkreten Informationen antwortet (Generation).

RAG ist die bevorzugte Architektur für unternehmens-interne Wissensassistenten, weil sie LLM-Halluzinationen reduziert, aktuelle Informationen nutzt und Quellenangaben ermöglicht.

RAG-Architektur im Detail

Indexierung

Dokumente (PDFs, Wiki-Seiten, Verträge, Produktdokumentation) werden in Chunks aufgeteilt, in Embedding-Vektoren umgewandelt und in einer Vektordatenbank gespeichert.

Retrieval

Bei einer Nutzerfrage wird diese ebenfalls in einen Embedding-Vektor umgewandelt und anhand von Vektorähnlichkeit (semantische Ähnlichkeit) die relevantesten Chunks aus der Datenbank abgerufen.

Augmentation und Generation

Die abgerufenen Chunks werden dem LLM im Kontext mitgegeben ("Als Kontext: [relevante Dokumente]. Frage: [Nutzerfrage]"). Das LLM generiert eine Antwort, die sich auf diese konkreten Informationen stützt.

Vorteile von RAG

• Halluzinations-Reduktion: Das LLM antwortet auf Basis konkreter Dokumente, nicht aus dem "Gedächtnis".
• Aktualität: Wissensdatenbanken können ohne Modell-Retraining aktualisiert werden.
• Quellenangaben: RAG-Systeme können die verwendeten Quelldokumente angeben — für Nachvollziehbarkeit und Vertrauen.
• Datenschutz: Unternehmensinternes Wissen bleibt in eigener Infrastruktur, ohne in LLM-Training einzufließen.

Praxisbeispiele im DACH-Kontext

Versicherung in München: Ein interner RAG-Assistent durchsucht alle Produktunterlagen, Klauseln und internen Richtlinien. Mitarbeitende können Kundenanfragen beantworten, indem sie das System fragen — und erhalten zitierte Antworten aus den Original-Dokumenten.

B2B-Vertrieb in Wien: Ein RAG-System, das auf CRM-Notizen, Account-Historien und öffentlichen Firmeninformationen basiert, bereitet Vertriebsmitarbeitende vor Calls vor — mit konkreten Gesprächspunkten basierend auf realen Interaktionsdaten.

Wie Knowlee RAG einsetzt

Knowlee integriert RAG als Kerntechnologie: Alle unternehmensinternen Daten — Kontakthistorien, Firmenprofile, vergangene Interaktionen — fließen in die Vektordatenbank ein. KI-Agenten können bei jeder Aufgabe auf dieses Wissen zugreifen und kontextrelevante Empfehlungen generieren.

FAQ

Wann ist RAG besser als Fine-Tuning? RAG ist besser, wenn das Wissen häufig aktualisiert wird (neue Produkte, aktuelle Preise, neue Gesetze) oder wenn die Daten zu sensibel sind, um in Modellgewichten gespeichert zu werden. Fine-Tuning eignet sich für das Einbetten von Stil, Fachvokabular oder Verhaltensweisen.

Welche Vektordatenbanken eignen sich für RAG? Weit verbreitet: Pinecone, Weaviate, Qdrant, pgvector (PostgreSQL-Extension), Chroma und Milvus. Die Wahl hängt von Skalierungsanforderungen, Deployment-Modell und Budget ab.

Wie groß sollten die Chunks in einer RAG-Wissensdatenbank sein? Typisch: 200–500 Tokens pro Chunk, mit Überlappung von 50–100 Tokens. Zu kleine Chunks verlieren Kontext; zu große Chunks enthalten irrelevantes Rauschen. Optimal ist anwendungsfall-spezifisch und sollte experimentell ermittelt werden.