Zurück zum Glossar
R
Definition

RAG IT-Definition

Retrieval-Augmented Generation: Architektur, die Informationssuche und Generierung durch ein LLM kombiniert, um Antworten zu produzieren, die auf verifizierten Quellen verankert sind.

Das RAG (Retrieval-Augmented Generation) ist das dominante Architekturmuster für die Nutzung eines LLM auf Geschäftsdaten. Es besteht darin, die relevanten Passagen einer Dokumentenbasis abzurufen (Suche) und sie dann in den Prompt des Modells einzuspeisen (Generierung), damit es eine Antwort produziert, die auf diesen Quellen verankert ist, statt allein auf seinem Training.

Das RAG ist zum Standard-Ansatz geworden, um Halluzinationen zu reduzieren, aktuelle oder proprietäre Daten zu verarbeiten und beglaubigbare Antworten zu liefern. Laut Gartner stützen sich mehr als 80 % der 2025 bereitgestellten Unternehmens-GenAI-Projekte auf eine RAG-Architektur, gegenüber weniger als 20 % im Jahr 2023.

Warum RAG existiert

Ohne RAG antwortet ein LLM nur aus seinen internen Parametern — was drei Probleme aufwirft:

  • Knowledge cutoff: .
  • Private Daten: interne Dokumente sind nicht in seinem Korpus.
  • Halluzinationen: ohne zu zitierende Quelle erfindet das Modell plausibel.

Wie eine RAG-Pipeline funktioniert

Eine typische RAG-Pipeline umfasst fünf Schritte:

  1. Indexierung: Quelldokumente werden in Chunks zerlegt, eingebettet (in Vektoren umgewandelt) und in einer Vector Database (Pinecone, Weaviate, Qdrant, pgvector) gespeichert.
  2. Benutzerfrage.
  3. Abruf: die Frage wird eingebettet, dann durch Vektor-Ähnlichkeit mit den indexierten Chunks verglichen. Die Top-k relevantesten Chunks werden zurückgegeben.
  4. Augmentation: die abgerufenen Chunks werden in den Prompt des LLM mit der Frage eingespeist.
  5. Generierung: das LLM produziert eine Antwort, die sich auf diese Chunks stützt, idealerweise unter Zitation der Quellen.

RAG-Varianten

  • Naive RAG: .
  • Advanced RAG: .
  • GraphRAG: .
  • Hybrid RAG: .
  • Agentic RAG: ein KI-Agent entscheidet wann und wie er abruft.
  • Self-RAG: .

RAG vs. Fine-Tuning vs. langer Kontext

  • RAG: dynamisch relevanten Kontext pro Frage abrufen. Industrie-Standard.
  • Fine-Tuning: die Gewichte des Modells an eine Domäne anpassen.
  • Langer Kontext: das gesamte Korpus in das Kontextfenster pushen.

Die drei Ansätze sind komplementär.

Herausforderungen des RAG in Produktion

  • Qualität des Chunking: .
  • Angepasste Embeddings: .
  • Metadaten: .
  • Berechtigungen und Vertraulichkeit: .
  • Evaluierung: .
  • Inferenzkosten: .
  • Aktualisierung: .

RAG und SI-Kontext

Um interne Fragen zu beantworten («Wer ist Eigentümer dieser Anwendung?», «Wie viel geben wir für Slack aus?»), muss das RAG aus dem lebenden Patrimonium des SI schöpfen. Genau das exponiert Kabeen — über REST-API, MCP und einen dedizierten RAG-Endpoint.

Gängige RAG-Werkzeuge

  • Vector Databases: Pinecone, Weaviate, Qdrant, Milvus, pgvector, Chroma.
  • Frameworks: LangChain, LlamaIndex, Haystack, DSPy.
  • Embeddings: OpenAI, Cohere, Voyage, BGE, Mistral Embed.
  • Verwaltete Plattformen: Azure AI Search, AWS Kendra, Vertex AI Search.
  • Evaluierung: Ragas, TruLens, DeepEval.

Häufig gestellte Fragen

Was ist RAG?

+

Das RAG (Retrieval-Augmented Generation, oder durch Abruf augmentierte Generierung) ist eine Architektur, die Informationssuche und Generierung durch ein LLM kombiniert. Statt aus seinen alleinigen Parametern zu antworten, erhält das LLM in seinem Prompt die relevanten Passagen einer internen Dokumentenbasis — was die Antwort auf verifizierte Quellen verankert und Halluzinationen drastisch reduziert.

Warum RAG statt eines rohen LLM verwenden?

+

Drei Gründe: (1) ein alleiniges LLM ignoriert alles, was nach seinem Training passiert ist (Knowledge cutoff), (2) ein alleiniges LLM kennt nicht die internen Daten Ihres Unternehmens, (3) ohne zu zitierende Quelle erfindet ein LLM plausibel (Halluzinationen). Das RAG löst diese drei Probleme: aktuelle Quellen, beherrschte private Daten, beglaubigbare Antworten.

Unterschied zwischen RAG und Fine-Tuning?

+

Das RAG ruft dynamisch den relevanten Kontext bei jeder Frage ab — flexibel, leicht zu aktualisieren, beglaubigt. Das Fine-Tuning passt die Gewichte des Modells an eine Domäne an — besser für den Ton, das Format oder sehr spezifische Aufgaben, aber kostspielig im Training und in der Aktualisierung. Die beiden sind komplementär: die Mehrheit der ernsthaften Bereitstellungen kombiniert RAG auf Geschäftsdaten und leichtes Fine-Tuning auf das Antwortformat.

Was sind die Fallen des RAG in Produktion?

+

Sieben wiederkehrende Wachsamkeitspunkte: die Qualität des Chunking, die Wahl der an die Domäne angepassten Embeddings, der Reichtum der Metadaten zum Filtern, die Berücksichtigung der Benutzerberechtigungen (oft vergessen), die Einrichtung eines eigenen Eval-Sets, die Inferenzkosten im großen Maßstab und die Strategie der Neuindexierung zur Verwaltung der Aktualisierungen. Ein RAG, das in der Demo funktioniert und in Produktion bricht, scheitert fast immer an einem dieser Punkte.

Brauchen Sie Hilfe bei der Kartierung Ihrer IT-Landschaft?

Kabeen hilft Ihnen, Ihr Anwendungsportfolio zu inventarisieren, zu analysieren und zu optimieren.

Kostenlos testen