Was ist Retrieval Augmented Generation (RAG)?

Seit einigen Jahren sind große Sprachmodelle oder auch Large Language Models, kurz LLMs in aller Munde und werden von vielen Unternehmen als Chatbots oder für die Texterstellung genutzt. Es gibt verschiedene Methoden, die Effizienz dieser Modelle zu steigern:

1. Prompt Engineering,
2. Retrieval Augmented Generation (RAG)
3. und Feinabstimmung.

In diesem Beitrag geht es um Methode 2: Retrieval Augmented Generation, kurz RAG.

Lassen Sie uns starten!

Was ist die Definition von Retrieval Augmented Generation (RAG)?

RAG ergänzt ein Sprachmodell bei der Anfrage um passende, extern abgerufene Informationen, um aktuellere und präzisere Antworten liefern zu können. Dafür werden zu einer gestellten Frage relevante Daten oder Dokumente gesucht und dem Sprachmodell als zusätzlicher Kontext bereitgestellt. Früher galt RAG eher als eigene Architektur, heutzutage ist RAG eher als Baustein innerhalb größerer, oft selbstständig handelnder (agentischer) KI-Systeme zu verstehen.

Ein Beispiel aus der Praxis: Ein Kundensupport-Team hinterlegt seine internen Handbücher und Produktinformationen in einer Wissensdatenbank. Sobald ein Mitarbeiter dem Chatbot eine Frage zu einem bestimmten Produkt stellt, sucht das System in der Wissensdatenbank zunächst nach passenden Textstellen und übergibt sie dem Sprachmodell als zusätzlichen Kontext. So basiert die Antwort auf den tatsächlichen, aktuellen Unternehmensdaten und nicht nur auf dem allgemeinen Trainingswissen des Modells.

Schauen wir uns das genauer an. Wenn wir mit einem LLM „kommunizieren“, gehen wir davon aus, dass das System uns korrekt auf unsere Frage antworten wird. Hier ist die Herausforderung: In dem LLM-Trainingsprozess fließt all das Wissen, Konzepte und Theorien der Welt komprimiert in das Modell. Diese Wissenskomprimierung hat zwei Dinge zur Folge:

1. Das Wissen stagniert und wird nicht regelmäßig ergänzt/ upgedated.
2. LLMs verfügen zwar über viel öffentliches Fachwissen, kennen jedoch keine aktuellen, unternehmensinternen Daten. Diese Lücke kann auch nicht durch eine eingebaute Websuche der Chatbot-Anbieter geschlossen werden.

RAG setzt an diesen beiden Herausforderungen an und versucht die Grenzen von Large Language Models durch spezifischen Kontext zu erweitern. Zum Beispiel ergänzen (Augmenting) wir LLMs um Domänenspezifisches Wissen, welches regelmäßig aktualisiert wird.

Wie das funktioniert?

Im einfachsten Fall, der in Fachkreisen „Naive RAG“ genannt wird, stellt ein User eine Frage, der Retriever analysiert die Eingabe und findet mit Hilfe von Text-Embeddings passende Informationen in der Wissensdatenbank. Diese werden dann dem Prompt hinzugefügt, den das LLM anschließend beantwortet.

Heute jedoch kommen in der praktischen Anwendung meist noch weitere Schritte hinzu. Dazu gehören eine Vorverarbeitung der Anfrage, eine Kombination aus Stichwort- und Bedeutungssuche sowie ein nachträgliches Neusortieren der Treffer. Außerdem entscheidet das Sprachmodell zunehmend selbst, ob und wie oft es weitere Informationen nachladen muss.

In unserem YouTube Video erklären wir in 9 Minuten was RAG ist.

Grundsätzlich stellt der RAG-Ansatz eine kostengünstige Variante für die Anpassung großer Sprachmodelle (LLMs) an unternehmensspezifische Daten dar.

RAG oder reicht auch ein größeres Kontextfenster?

Moderne Sprachmodelle wie beispielsweise Gemini können heute sehr viel Text auf einmal verarbeiten. RAG bleibt aber trotzdem sinnvoll, sobald der Datenbestand größer als das Kontextfenster ist, die Kosten pro Anfrage eine Rolle spielen oder Antworten mit Quellenbelegen nachvollziehbar sein müssen.

Was sind Herausforderungen von Large Language Models?

RAG adressiert zwei zentrale Herausforderungen, die sich bei der Nutzung von LLMs ergeben.

1. Die erste Herausforderung besteht darin, dass LLMs aufgrund ihres Trainings auf großen, aber statischen Datensätzen oft nicht in der Lage sind, aktuelle oder spezifische Daten zu kennen. Dies führt dazu, dass sie veraltete Antworten geben oder sogar Fehlinformationen erzeugen können. In der Praxis führt es dann dazu, dass das LLM internes Wissen des Unternehmens, wie gängige Abkürzungen oder Produktdaten, nicht kennt und im schlimmsten Fall halluziniert. Auch wenn 2026 viele Chatbots diese Lücke mittlerweile über eine eingebaute Websuche schließen, bleibt RAG unverzichtbar, was den Zugriff auf unternehmensinterne Daten angeht, die nicht im Web zu finden sind.
2. Die zweite Herausforderung betrifft die Notwendigkeit für KI-Anwendungen, domänenspezifische Daten effektiv zu nutzen, um relevante und präzise Antworten zu liefern, insbesondere in Anwendungen wie Kundensupport-Bots oder internen Q&A-Systemen​​.

Die Lösung für diese Herausforderungen bietet die RAG-Architektur. RAG ermöglicht das Einbeziehen von unternehmensinternen Datenquellen (z.B. PDF, Handbücher, Produktstammdaten) für die Beantwortung einer Anfrage. Die Antwort ist somit auf dem neuesten Stand und spezifisch für den jeweiligen Anwendungsfall.

Diese Methode, bekannt als RAG, gilt technisch als das gängige Vorgehen für unternehmensspezifische KI-Anwendungen. Sie ermöglicht es Organisationen, LLMs auf Basis von geringen Kosten und Aufwand zu verwenden.

Sehen wir uns nun an, in welchen Branchen und Use-Cases Sie den RAG-Architekturansatz einsetzen können.

Was sind die Vorteile von RAG?

Einer der Hauptvorteile von RAG ist die Fähigkeit, unternehmensspezifische, personalisierte und qualitativ hochwertige Antworten zu liefern. Allgemeine Aktualität zu öffentlichen Themen liefern viele Chatbots heute bereits direkt per Websuche.

Der eigentliche Mehrwert von RAG liegt klarer beim Zugriff auf firmeneigene, nicht öffentliche Daten. Indem es sich auf aktuelle, unternehmenseigene Datenquellen stützt, überwindet RAG die Beschränkungen, die sich aus der alleinigen Verwendung von statischen, veralteten Trainingsdaten ergeben. Durch die Verwendung von RAG kann das LLM kontextbezogene Antworten liefern, die speziell auf die proprietären oder domänenspezifischen Daten einer Organisation zugeschnitten sind.

Ein weiterer wesentlicher Vorteil ist die Effizienz und Kosteneffektivität dieser Methode. Im Vergleich zu anderen Ansätzen, die eine Anpassung von LLMs an domänenspezifische Daten erfordern, ist RAG dennoch kostengünstig in der Implementierung. Organisationen können RAG einsetzen, ohne das Modell anpassen zu müssen. Dies ist besonders vorteilhaft, wenn Modelle regelmäßig mit neuen Daten aktualisiert werden müssen. Zusammenfassend ermöglicht RAG Organisationen, ihre LLM-Anwendungen ohne erheblichen finanziellen oder zeitlichen Aufwand zu optimieren und dabei genaue und relevante Ergebnisse zu erzielen.

1. Aktuelles, benutzerdefiniertes Wissen: Die Antworten der RAG Lösung basieren auf aktuellen, benutzerspezifischen Dokumenten und Daten (können strukturiert aber auch unstrukturiert sein). Beispiele hierfür sind PDF-Dokumente, Handbücher aber auch Kaufdaten von Kunden. Die Antworten basieren somit auf aktuellen, benutzerdefinierten Dokumenten und Daten, nicht nur auf Trainingsdaten.
2. Reduziert das Risiko von Halluzinationen: Wenn ein Large Language Model (wie GPT 5 oder Claude Opus 4.5) die Antwort auf eine Frage nicht in seinem Trainingsdatensatz finden kann, neigt es zu Halluzinationen. Im Gegensatz dazu verankert RAG die Modelleingaben in externem Wissen und kann Quellen zitieren, wodurch das Risiko falscher Antworten reduziert wird. Aktuelle Herstellerzahlen bestätigen, dass die Falschinformationsrate mit Zugriff auf externe Quellen spürbar sinkt, während sie bei reinem Modellwissen ohne Werkzeuge höher ist.
3. Domänenspezifische Kontextualisierung: Kann spezialisierte, domänenspezifische Anfragen bearbeiten, indem es eigene oder domänenspezifische Daten (z.B. ihren Produktkatalog aus dem PIM oder Produkthandbücher für technische Fragen) verwendet.
4. Effizienz und Kosteneffektivität: Ermöglicht die Anpassung mit Daten ohne die Notwendigkeit der Feinabstimmung, was Entwicklungszeit und -kosten reduziert.

RAG ist nach dem Prompt Engineering die am wenigsten komplexe Möglichkeit, ein Sprachmodell an spezifische Bedürfnisse anzupassen, ohne das Modell selbst zu verändern, und hat sich in der Praxis bewährt.

Seit 2024/25 gibt es zusätzlich Agentic RAG. Dabei handelt es sich um einen selbstständig handelnden KI-Agenten, bei dem das Modell ebenfalls nicht verändert wird.

Im Betrieb ist eine solche Lösung jedoch oft aufwendiger als klassisches RAG. Laut Gartner (2025) werden über 40 Prozent der Agentic-AI-Projekte bis Ende 2027 wegen zu hoher Kosten oder unklarem Nutzen wieder eingestellt. Diesen Realitätscheck sollten Sie vor dem Einstieg einplanen.

Lassen Sie uns im nächsten Abschnitt auf die häufigsten Anwendungsfälle von RAG eingehen.

Was sind typische Anwendungsfälle von RAG?

RAG findet in einer Reihe von Bereichen Anwendung, wobei Frage-Antwort-Chatbots laut Bitkom (2025) mit Abstand der größte KI-Anwendungsbereich deutscher Unternehmen bleiben, von denen 88 Prozent den Kundenkontakt als Einsatzfeld nennen.

Bei Chatbots ermöglicht RAG eine automatische Ableitung präziserer Antworten aus Unternehmensdokumenten und internen Wissensdatenbanken. Das ermöglicht zum Beispiel die Entlastung des Support-Teams oder steigert die Produktivität ihres Vertriebs- oder Marketingteams. Als Empfehlungsdienst kann das RAG-angereicherte LLM potenziellen Käufern individuelle Empfehlungen vorschlagen, was zu einer Steigerung der Verkaufsrate führt. Im Handel entwickeln sich solche Empfehlungssysteme außerdem zunehmend zu eigenständig handelnden Kauf-Agenten weiter.

Aber auch als Suchmaschine entlastet die RAG-Architektur Mitarbeiter, indem sie in Sekunden wichtige Antworten zu Verträgen, Produktinformationen oder HR-Wissen bereitstellt.

In der folgenden Tabelle haben wir Ihnen wichtige Branchen und die jeweiligen Einsatzmöglichkeiten von RAG zusammengetragen.

Diese Vielfalt an Einsatzmöglichkeiten zeigt, wie RAG die Grenzen herkömmlicher LLM-Anwendungen erweitert, indem es sie mit dynamischen, kontextbezogenen und aktuellen Daten versorgt. Dadurch wird nicht nur die Genauigkeit der Antworten verbessert, sondern auch das Risiko von inkorrekten oder erfundenen Informationen (Halluzinationen) reduziert. RAG ermöglicht es Unternehmen, ihre LLM-Systeme effizient und kostengünstig an ihre spezifischen Bedürfnisse anzupassen.

Um Ihnen zu zeigen, wie Sie RAG zur Optimierung Ihres LLM verwenden können, stellen wir Ihnen im folgenden Absatz einen Use Case vor, den wir für unseren Kunden umsetzen durften.

Unsere Case Study für ein Wein-Empfehlungssystem mit RAG-Architektur

Für unseren Kunden – einen internationalen Weinhändler – durften wir das bestehende LLM mit einer RAG-Architektur personalisieren. Das Ziel war es, den Kunden des Weinhändlers einen Empfehlungsdienst auf der Website zu ermöglichen in Form eines Chatbots. Dafür pflegten wir die unternehmensinternen Daten über Produktinformationen zu einzelnen Weinen in das Modell ein.

Der Kunde hat die Möglichkeit, dem Chatbot Fragen zu stellen, wie Beispielsweise „Welcher Wein passt am besten zu Lamm?“ Als Antwort folgt eine Empfehlung basierend auf den Vorlieben des Kundenprofils. Die User Query wird innerhalb weniger Sekunden mit den Informationen zu verfügbaren Produkten abgeglichen.

Der Chatbot schlägt dem Kunden schließlich den Wein/ die Weinsorten vor, die am besten zu seiner Anfrage passen. Durch den im Vorab von uns erstellten Prompt werden unseriöse Anfragen mit entsprechenden Hinweisen zu einem verantwortungsvollen Umgang mit Alkohol beantwortet.

Schritt-für-Schritt-Anleitung für RAG-Anwendungen

Die Implementierung eines RAG-Systems kann je nach spezifischen Anforderungen und Datencharakteristika variieren. Ein häufig angewandter Workflow umfasst mehrere Schlüsselschritte:

1. Datenvorbereitung: Zuerst werden Dokumentendaten zusammen mit Metadaten gesammelt und einer ersten Verarbeitung unterzogen, wie beispielsweise der Handhabung von personenbezogenen Informationen.
2. Indexierung relevanter Daten: Anschließend erfolgt die Erstellung von Dokumenten-Embeddings, die in einen Vector Search Index eingespeist werden.
3. Abrufen relevanter Daten: Dabei werden Teile der Daten abgerufen, die für eine Nutzeranfrage relevant sind, und dann als Teil der Eingabeaufforderung für das LLM verwendet. Bei modernen Systemen (Agentic Retrieval) plant das System diesen Suchschritt zunehmend selbst. So stellt es bei Bedarf mehrere Teilanfragen parallel und sortiert die Ergebnisse automatisch nach Relevanz.
4. Aufbau von LLM-Anwendungen: Die Komponenten der Eingabeerweiterung und das Abfragen des LLMs werden in einem Endpunkt zusammengeführt, der dann für Anwendungen wie Q&A-Chatbots über eine einfache REST-API zugänglich gemacht werden kann.
5. Qualitätsprüfung/Evaluation: Anbieter wie Databricks oder Microsoft zählen diesen Schritt heute als eigenständigen Baustein, der von Anfang an mitgedacht wurde, anstatt einer nachgelagerten Prüfung am Ende. Mehr dazu im Abschnitt Evaluation von RAG Systemen

Zu den Schlüsselelementen einer RAG-Architektur gehören unter anderem Vektordatenbanken für schnelle Ähnlichkeitssuchen, klassische Stichwortsuche und das Unity AI Gateway für die Standardisierung von Schnittstellen. Diese Elemente tragen dazu bei, dass das eingesetzte Sprachmodell Zugang zu aktuellen Informationen hat und effizient genutzt werden kann​​.

Unabhängig von der gewählten Methode ist es wichtig, eine Lösung strukturiert und modular aufzubauen, um Flexibilität für Anpassungen und Weiterentwicklungen zu gewährleisten​​.

Fertige Bausteine statt alles selbst zu bauen

Nicht jedes Unternehmen möchte eine RAG-Lösung vollständig von Grund auf entwickeln. Databricks und Microsoft bieten dafür mittlerweile vorkonfigurierte Bausteine an, die viele Aufbauschritte automatisch übernehmen können.

Databricks Agent Bricks ist eine automatisiert vorkonfigurierte RAG-Lösung, die seit Juni 2025 verfügbar ist. Das System kann eigenständig passende Testdaten und Bewertungsmaßstäbe für den jeweiligen Anwendungsfall erstellen, sodass ein Agent von Anfang an auf hohe Genauigkeit ausgelegt wird. Für Fragen und Antworten auf Basis eigener Dokumente steht dafür der sogenannte Knowledge Assistant Agent bereit.

Microsoft verfolgt bei Azure einen ähnlichen Weg. Die sogenannte integrierte Vektorisierung kann Dokumente beim Einlesen automatisch in durchsuchbare Daten umwandeln, inklusive der Aufteilung in passende Textabschnitte. Eine separate, selbst gebaute Vektorisierungs-Pipeline entfällt damit.

Für Unternehmen, die bereits auf Databricks oder Microsoft Fabric setzen, kann ein Vorteil darin bestehen, dass der Einstieg in RAG deutlich schneller gelingt und ohne dass jeder Baustein einzeln zusammengesetzt werden muss.

Es gibt noch weitere Möglichkeiten, LLMs zu optimieren. Diese stellen wir Ihnen im nächsten Abschnitt vor.

Typische Herausforderungen für RAG-Applikationen

Auch wenn die RAG-Architektur einfach zu implementieren ist, stellen sich typischerweise eine Reihe von Herausforderungen, um eine hohe Qualität zu erreichen. Diese beziehen sich zumeist explizit auf den Retrieval-Prozess, also an den Schritt, wo Dokumente für den Kontext gesammelt werden oder aber auf den Generation-Prozess, also den Teil der RAG-Architektur, wo die Antwort aus dem Kontext generiert wird.

Retrieval-Probleme

Als die drei gängigsten Herausforderungen beim Retrieval können folgende Aspekte herausgestellt werden:

1. Vollständigkeit: Es kann sein, dass das Dokument, welches zum Beantworten der Frage benötigt wird, nicht im Kontext ist. Der zuverlässige Standard dabei ist die sogenannte Hybride Suche, eine Kombination aus Stichwort- und Bedeutungssuche. Eine reine Bedeutungssuche über Embeddings erkennt inhaltlich verwandte Texte auch bei anderer Wortwahl, kann aber exakte Eigennamen, Produktnummern oder Fachbegriffe leichter übersehen als eine klassische Stichwortsuche. Durch die Kombination beider Trefferlisten und das Zusammenführen zu einem gemeinsamen Ranking, sollen am Ende weder inhaltlich noch wörtlich passende Dokumente verloren gehen.
2. Granularität: Es besteht eine gewisse Freiheit, wie groß oder klein die sogenannten Chunks im Vectorindex sind. Sind sie zu groß, passen die Texte nicht ins Kontextfenster; sind sie zu klein, gehen Zusammenhänge verloren. Da es keine universell beste Chuck-Größe gibt, setzen neuere Verfahren die Textgrenzen zunehmend anhand der inhaltlichen Bedeutung statt starr nach Zeichenanzahl.
3. Metadaten: Manchmal möchte man nur eine gewisse Art von Dokumenten retrieven, beispielsweise bei unserem Weinempfehler nur die Rotweine. Metadaten an den Dokumenten helfen dabei, vorab die passenden Filter zu setzen, sodass falsche Dokumente gar nicht erst infrage kommen.

Hybride Suche

Bei der reinen Bedeutungssuche über Embeddings werden regelmäßig Eigennamen, Produktnummern oder Fachbegriffe übersehen, weil sie auf inhaltlicher Ähnlichkeit statt auf exakter Übereinstimmung beruhen. Als heutiger Standard hat sich deshalb die hybride Suche etabliert. Sie kombiniert die Bedeutungssuche mit einer klassischen Stichwortsuche und führt beide Trefferlisten zu einem gemeinsamen Ergebnis zusammen. Bei unserem Weinempfehler würde das zum Beispiel dabei helfen, einen konkret genannten Winzernamen oder Jahrgang zuverlässig zu finden, selbst wenn die reine Bedeutungssuche ihn nicht automatisch als relevant einstuft. 

Generation-Probleme

Auf Seite der Generation tauchen hingegen andere Probleme auf. Hauptsächlich kann man die folgenden Herausforderungen festmachen:

1. Kontextkuration: Es kann sein, dass das wichtige Dokument zur Beantwortung einer Frage zwar im Kontext enthalten ist, aber in der Menge der anderen Dokumente untergeht. Insbesondere trifft dies zu, wenn das Dokument in der Mitte des Kontexts liegt („Lost in the middle“ Problem). Hier bietet sich als Lösung das Reranking an, wo mit Hilfe von verschiedenen Metriken der Kontext nochmal umsortiert wird, sodass das wichtigste Dokument auch wirklich an erster Stelle steht.
2. Fachwissen: Ein RAG-System verfügt zwar für jede Frage über Kontext, lernt aber nicht wirklich domänenspezifisches Vokabular von selbst. Dies kann verbessert werden, indem man feste Regeln im System Prompt einpflegt.
3. Qualitätskontrolle: Ein LLM-Judge, also ein weiteres Sprachmodell, das die generierte Antwort nach festen Regeln bewertet, ist inzwischen Standard. Je nach Formulierung der Prüfungsanweisung kann derselbe Judge jedoch zu unterschiedlichen Urteilen kommen. Moderne Ansätze verfolgen daher einzelne Aussagen bis zu ihrer Quelle zurück, anstatt nur die gesamte Antwort neu zu bewerten.

Die hier beschriebenen Probleme sind zwar die häufigsten, aber nicht die einzigen. Bei Fragen, die sich nicht nur auf ein einzelnes Dokument beziehen, sondern den gesamten Datenbestand betreffen, wie beispielsweise „Was sind die Hauptthemen in unserem Wissensarchiv?“, stößt klassisches Chunk-Retrieval an Grenzen. An der Stelle setzt der von Microsoft entwickelte Graph-RAG-Ansatz an, der Beziehungen zwischen Informationen als Wissensnetz abbildet. Eine naive RAG-Implementierung hingegen reicht in der Praxis selten aus.

Evaluation von RAG-Systemen

In konventionellen Machine-Learning-Systemen wird die Modellqualität durch vordefinierte Metriken wie Accuracy, Precision, Recall oder den F1-Score bewertet, um zu bestimmen, ob die Performance zufriedenstellend ist. In RAG-Systemen gestaltet sich die Evaluation jedoch deutlich komplexer, da es oft kein direktes quantitatives Maß gibt, um die Qualität der generierten Antworten präzise zu messen.

Genau wie bei den Herausforderungen macht es Sinn die Evaluationen auf beide Schritte anzuwenden: Retrieval und Generation. Jede dieser Phasen muss separat evaluiert werden, da Fehler sowohl im Abrufprozess als auch bei der anschließenden Textgenerierung auftreten können.

Ein zentrales Problem ist das Fehlen eines „Single Ground Truth“ – also einer einzigen korrekten Antwort. Oft gibt es mehrere valide Möglichkeiten, eine Frage zu beantworten, was eine rein objektive Bewertung erschwert. Deshalb ist es nicht trivial, eine einzige Metrik festzulegen, die die Leistung des Systems angemessen widerspiegelt.

LLM as a Judge

Wie schon zuvor angemerkt ist bei RAG-Systemen der Einsatz von Large Language Models (LLMs) als „Judge“  sinnvoll, also das Nutzen eines LLMs, um die generierten Antworten auf deren Qualität hin zu bewerten. Der Judge dient dabei als eine Art „intelligente Instanz“, die sowohl die Richtigkeit als auch die Vollständigkeit der generierten Texte beurteilen kann. Heute hat sich dieser Ansatz unter anderem bei Databricks und Microsoft bereits zum Industriestandard entwickelt.

Ein Vorteil dieser Methode ist, dass das LLM in der Lage ist, mehrere korrekte Antwortmöglichkeiten zu erkennen und nicht nur an einer festen Ground Truth festhält. Diese flexiblere Bewertung kann besonders in Anwendungsfällen nützlich sein, bei denen es mehrere richtige Antworten oder Interpretationen gibt, wie z.B. in offenen Fragestellungen oder kreativen Textgenerierungen. Eine aktuelle Studie zeigt allerdings, dass selbst etablierte Bewertungswerkzeuge dabei wichtige Fehler übersehen können. Eine hohe Übereinstimmung mit dem Urteil des Sprachmodells reicht daher nicht allein als Qualitätsnachweis.

Metriken zur Evaluation von RAG-Systemen

Trotz der Herausforderungen gibt es verschiedene Metriken, die zur Bewertung von RAG-Systemen herangezogen werden können. Diese decken unterschiedliche Aspekte der Retrieval- und Generationsprozesse ab:

1. Retrieval Performance:
   • Recall@K: Diese Metrik misst, wie oft das relevante Dokument unter den ersten K abgerufenen Dokumenten zu finden ist. Je höher der Wert, desto besser ist das Retrieval-Modul des RAG-Systems.
   • Mean Reciprocal Rank (MRR): Diese Metrik bewertet den Rang, an dem das erste relevante Dokument gefunden wird. Je niedriger der Rang, desto besser die Abrufqualität.
2. Generative Performance:
   • In der Praxis haben sich mittlerweile Sprachmodell-gestützte Kennzahlen wie Faithfulness (Wird die Antwort durch die gefundenen Quellen gedeckt?), Answer Relevancy und Context Precision/Recall durchgesetzt. Ergänzend werden teils weiterhin die klassischen Textvergleichs-Metriken ROUGE, BLEU und METEOR eingesetzt. Hier eine kleine Einordnung, falls Ihnen die Begriffe begegnen sollten:
   • ROUGE (Recall-Oriented Understudy for Gisting Evaluation): Misst, wie gut der generierte Text mit einem Referenztext übereinstimmt. ROUGE-L fokussiert sich dabei auf die Länge der längsten gemeinsamen Sequenzen.
   • BLEU (Bilingual Evaluation Understudy Score): Misst die Ähnlichkeit zwischen dem generierten und dem referenzierten Text auf Basis von n-Grammen. Vor allem bei maschinellen Übersetzungen populär, aber auch für generative Tasks nützlich.
   • METEOR: Eine Metrik, die Synonyme und Wortstämme berücksichtigt und damit flexibler auf verschiedene Ausdrucksweisen eingeht als ROUGE oder BLEU.
3. Human Evaluation:
   • Human-Rated Quality: Um die generierten Antworten ganzheitlich zu bewerten, werden oft menschliche Experten herangezogen. Diese bewerten die Relevanz, Richtigkeit, Kohärenz und Lesbarkeit der Antworten.
4. LLM Evaluation:
   • LLM-based Scores: Hier wird das LLM selbst zur Bewertung eingesetzt, indem es den generierten Output auf inhaltliche Korrektheit, Kohärenz und Vollständigkeit hin überprüft. Dies erfolgt entweder über skalierte Bewertungen oder durch Klassifizierungsansätze, bei denen das LLM den Output als korrekt oder falsch einordnet.

Die Bedeutung eines Single Ground Truth

Trotz der Flexibilität von LLMs als Bewertungshilfen bleibt das Konzept eines Single Ground Truth in vielen Fällen wichtig. Besonders bei spezifischen, faktischen Informationen (z.B. technische Dokumentationen, juristische Texte oder wissenschaftliche Antworten) muss eine genaue Übereinstimmung zwischen der generierten Antwort und der festgelegten korrekten Lösung bestehen. In solchen Szenarien sollten RAG-Systeme präzise und faktisch korrekt arbeiten.

Das Problem der Mehrdeutigkeit stellt sich oft stärker bei kreativen oder offenen Fragen. In diesen Fällen sind Metriken wie ROUGE oder BLEU möglicherweise weniger geeignet, da sie nur Wortübereinstimmungen bewerten und keine inhaltliche Tiefe. Hier kommt die Human Evaluation oder LLM as a Judge ins Spiel, um die Vielfalt der richtigen Antworten besser abzubilden.

Die Evaluation von RAG-Systemen ist also weitaus komplexer als bei klassischen Machine-Learning-Modellen. Es gibt keine einfache Metrik, die alle Aspekte der Systemleistung angemessen abbilden kann. Vielmehr ist ein kombinierter Ansatz aus Retrieval-Metriken, generativen Metriken sowie menschlicher und LLM-basierter Bewertung notwendig, um eine umfassende und präzise Evaluation zu gewährleisten. Besonders in Anwendungsbereichen, in denen es nicht nur eine richtige Antwort gibt, müssen flexible Bewertungssysteme eingesetzt werden, um die tatsächliche Qualität des Systems abzubilden.

Genau hier setzen moderne Bewertungswerkzeuge an. RAGAS, Databricks Agent Evaluation und die Bewertungsfunktionen in Microsoft Foundry benötigen keine einzelne festgelegte Musterantwort mehr, sondern können ein LLM als Gutachter beurteilen lassen, ob eine Antwort inhaltlich korrekt und durch die Quellen gedeckt ist, auch wenn sie anders formuliert ist als erwartet.

Fazit

RAG hat sich von einer einfachen Kombination aus Suche und Antwort zu einem festen Baustein moderner KI-Architekturen entwickelt, ergänzt um hybride Suche, Reranking und zunehmend eigenständig agierende KI-Agenten. Für die meisten Unternehmen lohnt sich der Einstieg weiterhin über eine klassische, gut abgesicherte RAG-Lösung, bevor komplexere agentische Varianten in Betracht gezogen werden. Wer schon heute mit unternehmensinternen Daten arbeitet und aktuelle, nachvollziehbare Antworten braucht, sollte sich jetzt mit RAG beschäftigen, unabhängig davon, wie groß das Kontextfenster der eingesetzten Sprachmodelle bereits ist. Entscheidend ist am Ende weniger die einzelne Technologie als eine solide Datenbasis und ein klar abgegrenzter erster Anwendungsfall.

FAQ – Die wichtigsten Fragen schnell beantwortet

Vinzent Wuttke

Geschäftsführer

Lassen Sie uns sprechen und Ihr Potenzial entdecken.

Ob und wie künstliche Intelligenz Ihnen weiterhelfen kann, können Sie in einem ersten, unverbindlichen Gespräch mit uns herausfinden.

In diesem Gespräch erfahren Sie:

• Wie Ihr Use-Case technisch am besten umgesetzt werden kann
• Wie wir maximal sicher mit Ihren Kundendaten umgehen
• Wie lange wir für die Umsetzung benötigen und wie ein konkreter Projektplan aussehen könnte

Jetzt Erstgespräch vereinbaren