Wie misst man die Qualität eines RAG-Systems und begrenzt Halluzinationen?

Ein RAG-System kann technisch einwandfrei funktionieren und trotzdem falsche Antworten liefern.

Die Dokumente wurden indexiert. Die Suche funktioniert. Das Modell bekommt Kontext. Die API gibt eine Antwort zurück. Alles sieht gut aus - bis ein Nutzer fragt: Woher stammt diese Antwort?

Und es stellt sich heraus, dass das System das falsche Dokument gefunden hat. Oder eine entscheidende Information ausgelassen hat. Oder den richtigen Kontext bekommen, aber etwas hinzugefügt hat, das nicht darin stand. Oder auf der Faktenebene korrekt geantwortet, aber die eigentliche Frage des Nutzers nicht beantwortet hat.

All diese Situationen werden umgangssprachlich als "RAG-Halluzinationen" bezeichnet. Das ist eine zu starke Vereinfachung. OpenAI beschreibt Halluzinationen als überzeugend klingende, aber falsche Aussagen, die vom Modell generiert werden. In einem RAG-System kann eine fehlerhafte Antwort jedoch bereits entstehen, bevor das Modell überhaupt Text generiert - auf der Ebene der Daten oder der Suche.

Deshalb gibt es keine einzelne sinnvolle Metrik wie "unser RAG hat 92% Accuracy", die uns sagen würde, ob das gesamte System gut funktioniert. Um RAG zu diagnostizieren, muss man seine einzelnen Schichten separat messen.

Ein guter RAG-Evaluationsprozess sollte mindestens sechs Fragen beantworten. Befindet sich in der Wissensbasis die korrekte und aktuelle Information? Hat der Retriever die richtigen Fragmente gefunden? Hat er alle für die Antwort nötigen Informationen gefunden? Hat das Modell ausschliesslich auf Basis der verfügbaren Evidenz geantwortet? Löst die Antwort tatsächlich die Frage des Nutzers? Und kann das System schweigen, wenn es nicht genügend Daten hat?

Erst die Kombination dieser Informationen ermöglicht es festzustellen, warum eine Antwort falsch war und was konkret verbessert werden muss.

Was bedeutet "Halluzination" in einem RAG-System eigentlich?

In der Praxis ist es hilfreich, mindestens vier Fehlerklassen zu unterscheiden. Das ist keine offizielle, verbindliche RAG-Taxonomie. Es ist eine praktische diagnostische Einteilung, die hilft, ein Problem der richtigen Systemschicht zuzuordnen.

Fehler in den Quelldaten

Die für die Antwort benötigte Information fehlt im Korpus, oder die verfügbaren Quellen sind veraltet, fehlerhaft, unvollständig oder widersprüchlich.

Stellen Sie sich folgende Situation vor. In einem Unternehmen beträgt der aktuelle maximale Rabatt ohne Genehmigung des Direktors 10%, aber die Wissensbasis enthält ausschliesslich die alte Richtlinie mit einem Limit von 15%. Der Retriever findet das Dokument mit 15%. Das Modell antwortet: "Der Vertriebsmitarbeiter kann maximal 15% Rabatt gewähren."

Die Antwort ist geschäftlich falsch. Gleichzeitig kann man nicht sagen, dass das Modell oder der Retrieval versagt hat. Das System hat die einzige verfügbare Quelle korrekt genutzt. Das Problem liegt im Wissenskorpus.

In unserem System BLUP-FLOCK haben wir gesehen, wie stark die Antwortqualität davon abhängt, was vor jedem Modell passiert. Als wir den physischen Datenerfassungsprozess auf dem Freilandbetrieb änderten - neue Waagen, ein anderer Arbeitsablauf - verbesserte sich die Qualität der Systemergebnisse ohne Modelländerung. Kein Embedding repariert, was die Quelldaten nicht hergeben.

Suchfehler

Die korrekte Information existiert in der Datenbank, aber das System hat sie nicht gefunden oder die Ergebnisse falsch sortiert.

Im selben Beispiel - im Index befinden sich sowohl die alte Richtlinie mit 15% als auch die neue mit 10%. Der Nutzer fragt nach dem maximalen Rabatt. Der Retriever gibt das alte Dokument zurück, aber nicht das aktuelle. Das Modell antwortet erneut mit 15%.

Diesmal war das Wissen verfügbar. Die Suchphase hat versagt. Das ist eine Situation, in der Metadaten - Gültigkeitsdatum, Dokumentstatus, Version - die Retrieval-Qualität wesentlich verbessern können, vorausgesetzt die Pipeline nutzt sie aktiv zum Filtern, Ranking oder zur Quellenauswahl. Das blosse Vorhandensein eines Feldes valid_from=2026 ändert nichts, wenn der Retriever es nicht berücksichtigt. Mehr dazu in unserem Artikel über die Vorbereitung von Unternehmensdaten für RAG.

Fehler bei der Antwortgenerierung

Der Retriever hat das richtige Fragment gefunden: "Der Vertriebsmitarbeiter kann selbstständig einen Rabatt von bis zu 10% gewähren." Aber das Modell antwortet: "Er kann einen Rabatt von bis zu 15% gewähren."

Die Evidenz war verfügbar, aber die finale Aussage folgt nicht aus dem gelieferten Kontext. Genau dieser Fall kommt dem am nächsten, was bei der RAG-Evaluation als Faithfulness oder Groundedness gemessen wird. Ragas definiert Faithfulness durch die Prüfung, welcher Anteil der Aussagen in der Antwort durch den abgerufenen Kontext gestützt wird.

Korrekte, aber nutzlose Antwort

Der Nutzer fragt: "Kann ich den Vertrag heute kündigen?" Das System antwortet: "Die Kündigungsregeln finden Sie in §12 der Geschäftsordnung."

Die Information kann vollkommen wahr sein. Sie kann korrekt auf einer Quelle basieren. Aber der Nutzer weiss immer noch nicht, ob er den Vertrag kündigen kann. Das ist kein Problem der Factual Correctness oder Groundedness. Es ist ein Problem der Aufgabenerfüllung und der Antwortrelevanz.

Warum ist diese Unterscheidung wichtig?

Weil jede Fehlerklasse eine andere Intervention erfordert. Wenn das richtige Dokument nicht in der Datenbank ist - wird eine Änderung des System Prompts nichts reparieren. Wenn der Retriever das Dokument nicht gefunden hat - kann auch ein Austausch des Generierungsmodells nichts ändern. Wenn der Retrieval sehr gut funktioniert, aber das Modell regelmässig Informationen ausserhalb des Kontexts ergänzt - dann liegt das Problem tatsächlich näher an der Generierungsschicht.

Eine fehlerhafte Antwort ist das Ergebnis der gesamten Pipeline, nicht nur der Arbeit des LLM.

Es gibt keine einzige "RAG-Accuracy"

LangSmith schlägt vor, die RAG-Evaluation unter anderem in Correctness, Relevance, Groundedness und Retrieval Relevance aufzuteilen. Jede dieser Bewertungen vergleicht unterschiedliche Systemelemente miteinander - Antwort mit Referenzantwort, Antwort mit Frage, Antwort mit abgerufenen Dokumenten oder Dokumente mit Frage. Ragas unterteilt verschiedene Qualitätsaspekte ähnlich und bietet unter anderem Context Precision, Context Recall und Faithfulness an.

In der Praxis lohnt es sich, in Schichten zu denken. Auf der Retrieval-Ebene fragen wir: Haben wir die richtigen Informationen gefunden (Retrieval Relevance), stehen die relevanten Ergebnisse weit oben im Ranking (Context Precision) und haben wir alles Nötige gefunden (Context Recall)? Auf der Generierungsebene fragen wir: Folgt die Antwort aus dem Kontext (Faithfulness/Groundedness) und beantwortet sie tatsächlich die Frage des Nutzers (Answer Relevance)? Auf der End-to-End-Ebene prüfen wir die finale Korrektheit (Answer Correctness). Und auf Systemebene - wann antwortet er und wann verweigert er (Coverage, Error Rate, Abstention).

Wichtig ist das Wort "hilft". Ein niedriger Answer Correctness sagt nicht automatisch, welche Schicht versagt hat. Die Ursache kann eine fehlerhafte Quelle sein, ein falscher Retrieval, fehlender Kontext, ein Grounding Failure oder ein Problem mit der Referenzantwort selbst. Metriken sind in erster Linie diagnostische Werkzeuge.

Context Precision - stehen die richtigen Fragmente weit oben?

Context Precision bewertet das Ranking der abgerufenen Fragmente. Ragas beschreibt diese Metrik als Bewertung der Fähigkeit des Retrievers, relevante Chunks höher als irrelevante Fragmente zu platzieren.

Nehmen wir an, das System ruft 10 Fragmente ab und zwei enthalten die Antwort. Wenn sie auf den Positionen 1 und 2 stehen - sieht das Ranking deutlich besser aus als auf den Positionen 9 und 10. In beiden Fällen hat das System "die Antwort gefunden". Aber die Retrieval-Qualität ist nicht dieselbe.

Das ist besonders wichtig, wenn dem Modell nur eine begrenzte Anzahl der besten Ergebnisse übergeben wird. Oder wenn eine grosse Menge zusätzlichen Textes die Kosten erhöht und den Kontext verkompliziert - das Phänomen "Lost in the Middle", das wir in unserem vorherigen Artikel beschrieben haben, ist hier sehr real.

Context Recall - haben wir nichts Wichtiges übersehen?

Precision und Recall beantworten zwei verschiedene Fragen. Precision: Wie viel von dem, was wir gefunden haben, ist nötig? Recall: Wie grossen Anteil des Nötigen haben wir gefunden?

Ragas weist darauf hin, dass Context Recall eine Form von Referenz erfordert - eine Referenzantwort, Referenzkontexte oder im ID-basierten Variante Identifikatoren der Fragmente, die abgerufen werden sollten.

Ein konkretes Beispiel. Der Nutzer fragt: "Welche Voraussetzungen muss ein Kunde erfüllen, um kostenlosen Service zu erhalten?" Die korrekte Antwort erfordert drei Elemente - einen aktiven Vertrag, eine Inspektion innerhalb der letzten 12 Monate und keine offenen Zahlungsrückstände. Der Retriever findet die ersten beiden Bedingungen. Die gefundenen Fragmente können sehr treffend sein. Die Precision kann also gut aussehen. Aber der Retrieval ist unvollständig. Genau dieses Problem hilft Recall sichtbar zu machen.

Faithfulness bedeutet nicht Correctness

Das ist eine der wichtigsten Unterscheidungen in der RAG-Evaluation.

Nehmen wir an, das System hat ein Dokument abgerufen: "Die Kündigungsfrist beträgt 60 Tage." Das Modell antwortet: "Die Kündigungsfrist beträgt 60 Tage." Die Antwort stimmt perfekt mit dem Kontext überein. Sie hat hohe Groundedness. Aber das Dokument stammt aus 2023, und die aktuelle Geschäftsordnung sagt: 30 Tage. Die Antwort ist also faithful, aber falsch.

Ragas misst Faithfulness als Übereinstimmung der Aussagen in der Antwort mit dem gelieferten Kontext. LangSmith trennt Groundedness - Antwort versus abgerufene Dokumente - von Correctness, wo die Antwort gegen eine Referenzantwort bewertet wird.

Ein hoher Faithfulness-Wert beantwortet die Frage "Hat sich das Modell an die Quellen gehalten?", nicht "Haben die Quellen die Wahrheit gesagt?". Das sind zwei verschiedene Probleme. Und deshalb ist es so wichtig, dass die Quellen im Korpus aktuell und korrekt versioniert sind - ohne das garantiert selbst perfektes Grounding keine korrekten Antworten.

Wer bewertet den Bewerter?

Wir haben eine Metrik - zum Beispiel Faithfulness. Aber wir müssen noch festlegen, wie wir sie messen. Diese Unterscheidung ist entscheidend: Die Metrik ist das, was wir messen wollen, der Evaluator ist das Wie der Messung.

Ein Evaluator kann deterministischer Code sein, ein Identifikatorvergleich, eine Textähnlichkeitsmethode, eine Geschäftsregel, ein Mensch oder LLM-as-a-Judge. LangSmith unterstützt Evaluation durch Code, Menschen, LLM-as-a-Judge und Pairwise-Vergleiche. Ragas zeigt den Unterschied gut am Beispiel Context Precision und bietet Varianten mit LLM, Non-LLM-Methoden basierend auf Textähnlichkeit und ID-basierte Varianten an.

Ist das Ergebnis von LLM-as-a-Judge "Wahrheit"?

Nein. Wenn der Evaluator selbst ein Sprachmodell verwendet, ist sein Ergebnis eine automatische Bewertung nach definierten Kriterien, kein direkt beobachtbarer Fakt.

LangSmith weist ausdrücklich darauf hin, dass LLM-as-a-Judge eine Überprüfung der Ergebnisse und ein Tuning des Evaluator-Prompts erfordert. Die Dokumentation beschreibt den Prozess des Vergleichs von Judge-Bewertungen mit Experten-Annotationen und der iterativen Verbesserung der Übereinstimmung des Evaluators mit der menschlichen Bewertung.

Daher sollte ein Ergebnis wie faithfulness = 0.91 nicht als "das System ist objektiv zu 91% faithful" interpretiert werden. Zuerst muss man wissen, wie die Metrik definiert war, welcher Evaluator sie verwendet hat, auf welchem Datensatz sie berechnet wurde und wie hoch die Übereinstimmung des Evaluators mit der Expertenbewertung war.

Deterministisch, wo es möglich ist

Wenn Sie eine harte Referenz haben, nutzen Sie sie ohne unnötige Einbeziehung eines LLM. Wenn wir für eine Frage wissen, dass der Retriever die Dokumente policy_2026 und discount_rules zurückgeben sollte - können wir ihre IDs mit den Retrieval-Ergebnissen vergleichen. Wir brauchen kein Sprachmodell, um festzustellen, ob das erwartete Dokument gefunden wurde.

LLM-as-a-Judge ist nützlicher dort, wo eine semantische Bewertung nötig ist - ob die Antwort tatsächlich das Problem des Nutzers löst, ob eine Aussage durch ein anders formuliertes Fragment gestützt wird, ob zwei unterschiedlich formulierte Antworten inhaltlich gleichwertig sind.

Ohne guten Datensatz keine gute Evaluation

Man kann ein grossartiges Dashboard mit Metriken bauen und trotzdem wenig über die RAG-Qualität wissen, wenn man auf einem schlechten Fragensatz testet.

LangSmith empfiehlt, mit manuell erstellten, hochwertigen Beispielen zu beginnen, die sowohl typische Szenarien als auch Grenzfälle abbilden. Später kann der Datensatz um echte Produktions-Traces und Fälle erweitert werden, bei denen Nutzer Probleme gemeldet haben.

Bei RAG lohnt es sich, verschiedene Arten von Ground Truth zu sammeln.

Frage plus erwartete Antwort - die einfachste Variante. Frage: "Welchen maximalen Rabatt kann ein Vertriebsmitarbeiter ohne Genehmigung des Direktors gewähren?" Referenz: "10%." Ermöglicht die Bewertung der finalen Correctness, hat aber Einschränkungen. Zwei Antworten - "10%" und "Der Vertriebsmitarbeiter kann selbstständig einen Rabatt von bis zu 10% gewähren" - sind inhaltlich gleichwertig. Deshalb reicht bei generativen Antworten ein Exact Match oft nicht aus, und LangSmith empfiehlt LLM-as-a-Judge als eine Methode der semantischen Bewertung.

Frage plus richtige Quellen - wir notieren, dass für eine bestimmte Frage die richtige Quelle sales_policy_v4, Abschnitt 7.2 ist. Damit können wir den Retrieval unabhängig von der Generierung testen. Wenn das System falsch antwortet, wissen wir, ob das richtige Dokument gefunden wurde, auf welcher Position es stand und ob es dem Modell übergeben wurde. Das liefert oft mehr diagnostische Informationen als der blosse Vergleich der finalen Antworten.

Frage plus erwartetes Systemverhalten - nicht jede Frage sollte mit einer Antwort enden. Wenn der Nutzer nach etwas fragt, das nicht in der Wissensbasis ist, kann das erwartete Verhalten eine Verweigerung sein: "Ich finde diese Information nicht in der verfügbaren Dokumentation." Ein solches Beispiel sollte ebenfalls im Datensatz enthalten sein. Andernfalls testen wir das System hauptsächlich mit beantwortbaren Fragen und wissen nicht, wie es sich bei fehlender Evidenz verhält.

Der Datensatz muss schwierige Fälle enthalten

Ein realistischer Datensatz sollte nicht nur aus einfachen Fragen wie "Wie lang ist die Garantiezeit?" bestehen.

Er sollte Situationen umfassen, in denen die Antwort in mehreren Dokumenten liegt, ähnliche Dokumente für verschiedene Produkte existieren, eine alte und eine neue Version eines Dokuments vorliegt, der Nutzer eine andere Terminologie als das Unternehmen verwendet, die Frage mehrdeutig ist, Quellen widersprüchlich sind, keine Antwort existiert oder die richtige Reaktion eine Bitte um Präzisierung ist.

Genau diese Grenzfälle zeigen am häufigsten, ob eine Architektur robust ist oder nur bei Demonstrationsfragen gut funktioniert.

In unseren Agent-Projekten haben wir das mehrfach erlebt. Beim Bau unseres Ads Agent, der mehrere Google-Ads-Konten gleichzeitig bearbeitet, stiessen wir auf einen Fall, in dem der Agent im Briefing Daten verschiedener Kundenkonten vermischte - er erstellte eine schlüssig klingende, aber fehlerhafte Analyse. Bei einfachen Fragen zu einem einzelnen Konto sah alles gut aus. Das Problem zeigte sich erst beim Datensatz mit mehreren Kunden - genau der Typ Edge Case, der in Tests mit "Happy Path"-Szenarien leicht übersehen wird.

"Ich weiss nicht" muss auch gemessen werden

Die reine Accuracy-Messung kann ein System bevorzugen, das häufiger rät.

OpenAI hat dieses Problem an einem Evaluationsbeispiel gezeigt, bei dem ein Modell mit höherer Abstention-Neigung eine etwas niedrigere Accuracy hatte, aber gleichzeitig eine deutlich niedrigere Error Rate als ein häufiger ratendes Modell. Eine falsche Antwort und eine bewusste Antwortverweigerung sollten nicht als derselbe Fehlertyp behandelt werden.

Gleichzeitig beweist eine hohe Abstention Rate allein nichts. Ein System, das auf jede Frage mit "Ich weiss nicht" antwortet, wird wahrscheinlich sehr wenige falsche Informationen generieren. Es wird auch praktisch nutzlos sein.

Deshalb lohnt es sich, mindestens vier Kategorien zu unterscheiden: Correct Answer (System hat geantwortet und hatte recht), Incorrect Answer (hat falsch geantwortet), Correct Abstention (hat zu Recht nicht geantwortet) und Unnecessary Abstention (hat trotz verfügbarer Evidenz verweigert).

Darauf basierend kann man die Answer Coverage beobachten - auf welchen Anteil der Anfragen das System eine Antwort versucht - sowie die Error Rate unter den gegebenen Antworten. Das ist ein deutlich nützlicheres Bild als eine einzelne "Abstention Rate".

Metriken lassen sich nicht unabhängig maximieren

Das ist eines der wichtigsten Probleme beim Design von RAG-Systemen. In der Produktion optimieren wir nicht nur Precision, Recall und Faithfulness isoliert. Es kommen weitere Einschränkungen hinzu: Quality versus Coverage versus Latency versus Cost versus Safety. Eine Änderung eines Pipeline-Elements kann eine Metrik verbessern und gleichzeitig einen anderen Systemaspekt verschlechtern.

Grösseres k beim Retrieval - wir rufen mehr Kandidaten ab und erhöhen die Chance, das nötige Dokument zu finden. Aber ein grösseres k bedeutet auch mehr Ergebnisse zur Weiterverarbeitung. Wichtig: Man darf die Erhöhung der vom Retriever abgerufenen Dokumente nicht mit der Übergabe von mehr Fragmenten an den LLM-Prompt verwechseln. Das sind nicht dieselben Schritte.

Mehr Kontext ist nicht automatisch besser - zusätzliche Fragmente können nötige Evidenz liefern, aber auch das Rauschen erhöhen, mehr Context Budget verbrauchen und Kosten sowie Latenz steigern. Es geht nicht darum, dem Modell möglichst viele Dokumente zu übergeben. Es geht darum, ausreichend relevanten Kontext für die konkrete Aufgabe zu liefern.

Chunk Size ist ein Kompromiss - es gibt keinen universellen Wert wie "der beste Chunk hat 500 Token". Microsoft weist darauf hin, dass die Wahl der Chunking-Strategie von der Dokumentstruktur, der Art der Anfragen und den verwendeten Modellen abhängt. Grössere Chunks können den vollständigen Kontext besser bewahren, kleinere können einzelne Fragmente bei der Suche besser repräsentieren. Die Parameter sollten auf einem realen Datensatz verglichen werden.

Hybrid Search ist kein magischer Schalter - Vector Search kommt gut mit semantischer Ähnlichkeit zurecht, Keyword Search ist besonders nützlich bei genauen Zeichenketten - Symbolen, Produktnummern, Nachnamen, Daten, Fachbegriffen. Azure AI Search kombiniert beide Ansätze über Reciprocal Rank Fusion. Microsoft berichtet über Relevanzvorteile für Hybrid Retrieval mit Semantic Ranking in seinen Tests, aber das bedeutet nicht, dass jede Anwendung automatisch bessere Ergebnisse erzielt, ohne eigene Evaluation.

Reranking verbessert das Ranking auf Kosten eines zusätzlichen Schritts - der Retriever kann zunächst einen grösseren Kandidatenpool finden, und ein separater Schritt sortiert die Ergebnisse neu, bevor sie dem Generator übergeben werden. Das trennt Candidate Retrieval von Final Context Selection. Aber Reranking bedeutet zusätzliche Arbeit in der Pipeline, und seine Auswirkung sollte zusammen mit Qualität, Latenz und Kosten bewertet werden.

Restriktive Abstention erhöht die Sicherheit, kann aber die Coverage verringern - wir können das System so konfigurieren, dass es nur bei ausreichend starker Evidenz antwortet. Wenn das Gating zu restriktiv ist, beginnt das System auch dort zu verweigern, wo eine Antwort möglich war. Es gibt keinen universellen "sichersten Schwellenwert". Für ein System, das einen Arzt unterstützt, sind die Kosten einer falschen Antwort völlig andere als für eine interne Dokumentationssuche.

Similarity Score ist nicht "Antwortsicherheit"

Das ist ein häufiger Implementierungsfehler. Eine Vektordatenbank gibt einen Score zurück, der mit der Ähnlichkeit oder dem Ranking von Dokumenten zusammenhängt. Das bedeutet nicht, dass 0,87 eine 87-prozentige Wahrscheinlichkeit für eine korrekte Antwort ist.

In Azure AI Search haben verschiedene Ranking-Mechanismen verschiedene Ergebnisskalen - BM25, Vector Similarity, RRF und Semantic Ranker geben Scores auf unterschiedliche Weise und in unterschiedlichen Bereichen zurück.

Deshalb sollte ein Gating wie if similarity > 0.8: answer() nicht als universeller Mechanismus zur Halluzinationskontrolle betrachtet werden. Der Schwellenwert sollte mit einem auf den konkreten Daten des konkreten Systems validierten Signal verknüpft sein - das kann eine Kombination aus Retrieval-Qualität, Reranker-Ergebnis, Vorhandensein der erforderlichen Quellen, Evidenzqualitätsbewertung und Geschäftsregeln sein.

Am wichtigsten ist nicht, wie elegant die Zahl aussieht, sondern ob sie im Datensatz tatsächlich die Fälle trennt, in denen das System antworten sollte, von denen, in denen es verweigern sollte.

Was tun, wenn sich Quellen widersprechen?

Das ist einer der Fälle, die unbedingt in die Tests gehören. Nehmen wir an, der Retrieval gibt zwei Dokumente zurück - eines sagt "Die Kündigungsfrist beträgt 30 Tage", das andere "60 Tage". Das Modell sollte nicht selbstständig raten, welches Dokument richtig ist.

Die Architektur kann je nach verfügbaren Daten verschiedene Strategien anwenden. Aktualitätspriorität - wenn Dokumente verlässliche Gültigkeitsdaten haben, bevorzugt das System das aktuelle Dokument. Autoritätspriorität - eine offizielle Geschäftsordnung kann höhere Priorität haben als eine FAQ, eine Mitarbeiternotiz oder eine Präsentation. Information über den Konflikt - das System antwortet: "In den verfügbaren Dokumenten befinden sich widersprüchliche Informationen: eines nennt 30 Tage, das andere 60 Tage." Oder Abstention - in einer Hochrisikoanwendung kann die richtige Reaktion sein: "Ich kann die Antwort auf Basis der verfügbaren Quellen nicht eindeutig bestimmen."

Metadaten, Versionierung und Quellhierarchie helfen, einen Teil solcher Probleme zu lösen. Sie garantieren jedoch keine Wissenskonsistenz. Sie sind ein Element des Evidence-Management-Systems, keine automatische Lösung des Datenqualitätsproblems.

Zuerst feststellen, welche Schicht versagt

Der häufigste Fehler bei der Verbesserung von RAG sieht so aus: "Das System hat falsch geantwortet. Verbessern wir den Prompt." Der Prompt ist nur eines der Pipeline-Elemente.

Ein sinnvollerer diagnostischer Prozess beginnt mit einem einfachen Entscheidungsbaum.

Existiert das korrekte Wissen im Korpus? Nein - Datenproblem. Ja - weiter.

Hat das System es gefunden? Nein - Retrieval-Problem. Ja - weiter.

Ist das richtige Fragment beim Generator angekommen? Nein - Problem mit Ranking oder Kontextauswahl. Ja - weiter.

Folgt die Antwort aus dieser Evidenz? Nein - Grounding Failure. Ja - weiter.

Ist die Antwort tatsächlich korrekt und nützlich? Nein - wir prüfen Quellen, Ground Truth und die Art der Aufgabenerfüllung.

Kann das System bei fehlender Evidenz aufhören zu raten? Nein - ein Abstentions- oder Gating-Mechanismus wird benötigt.

Erst diese Diagnostik ermöglicht ingenieurtechnische Entscheidungen auf Datenbasis statt auf Vermutungen.

In der Praxis sieht das so aus: Ein niedriger Retrieval Recall bedeutet, dass Chunking, Query Rewriting, Hybrid Retrieval und Metadata Filtering geprüft werden sollten. Gute Retrieval-Ergebnisse bei schwacher Groundedness deuten auf ein Problem mit den Generierungsanweisungen, dem Modell oder dem Evidenzformat hin. Hohe Groundedness bei niedriger Correctness wirft die Frage nach der Aktualität der Quellen und der Qualität des Ground Truth auf. Korrekte, aber nutzlose Antwort - das ist ein Problem der Aufgabenerfüllung und des Antwortformats. System rät bei fehlender Evidenz - eine Abstention Policy wird benötigt. System verweigert zu oft - man muss prüfen, ob False Abstention korrekte Antworten blockiert.

Diese Diagnostik ist wichtiger als jede Liste "10 Wege zu besserem RAG". Denn dieselbe Technik kann in einem System sehr effektiv und in einem anderen völlig überflüssig sein.

Offline-Evaluation ist nicht das Ende

Vor dem Deployment können wir das System auf einem vorbereiteten Datensatz testen. Aber Nutzer werden fast immer Fragen stellen, die das Projektteam nicht vorhergesehen hat. Deshalb braucht man auch produktive Observability.

LangSmith trennt Offline-Evaluation - durchgeführt an vorbereiteten Beispielen, oft mit Referenzen - von Online-Evaluation an echten Produktions-Traces, wo eine Referenzantwort in der Regel nicht verfügbar ist.

In der Praxis lohnt es sich, mindestens die Nutzerfrage, die verarbeitete Retriever-Anfrage, abgerufene Dokumente und Chunks, die Ergebnisreihenfolge und Reranking-Ergebnisse, den an den LLM übergebenen Kontext, die finale Antwort, die in der Antwort verwendeten Quellen, die Entscheidung über Antwort oder Abstention, Nutzer-Feedback und Evaluator-Ergebnisse zu speichern.

Damit hört eine fehlerhafte Antwort auf, ein einzelnes Ereignis vom Typ "Die KI hat sich wieder etwas ausgedacht" zu sein. Sie wird zu einem Fall, der reproduziert, der richtigen Schicht zugeordnet und dem Regressionstestset hinzugefügt werden kann.

So bauen wir unsere Agent-Systeme. Beim Ads Agent durchläuft jede vorgeschlagene Aktion - Budgetänderung, Anzeigenpause, Strategiemodifikation - eine Approve/Reject-Pipeline, in der wir die Empfehlung, den historischen Kontext und die menschliche Entscheidung protokollieren. Wenn etwas korrigiert werden muss, können wir nachvollziehen, auf welchen Daten der Agent seinen Vorschlag basiert hat. Das ist dieselbe Denkrichtung bei der Observability, die auch bei RAG funktioniert.

Wie sollte ein reifer RAG-Evaluationsprozess aussehen?

Ich würde nicht mit der Frage beginnen "Welche Bibliothek soll ich für Evals verwenden?" Ich würde mit der Definition von Failure Modes beginnen - was bedeutet in diesem konkreten System ein Fehler? Wir definieren ihn anders für eine Wissenssuche, einen Support-Bot, ein Rechtssystem, einen internen Copilot und einen Vertriebsassistenten.

Dann - einen repräsentativen Datensatz aufbauen. Typische Fragen, schwierige Fragen, fehlende Antworten, Quellkonflikte und verschiedene Formulierungen desselben Problems einbeziehen. Jeder wichtigen Failure Mode eine Metrik zuordnen. Nicht alles messen, nur weil die Bibliothek 20 Metriken anbietet.

Den Evaluator wählen. Wenn eine harte Referenz existiert - nutzen. Wenn eine semantische Bewertung nötig ist - LLM-as-a-Judge in Betracht ziehen. Und den Evaluator selbst verifizieren - besonders dann, wenn von seinem Ergebnis Entscheidungen über Modell- oder Architekturänderungen abhängen.

Kompromisse definieren. Was ist im konkreten Produkt wichtiger - Coverage, Minimierung falscher Antworten, Latency, Kosten oder Vollständigkeit der Antworten? Änderungen regressiv testen - eine Änderung von Chunking, Retriever, Modell oder Prompt sollte auf demselben Datensatz verglichen werden. Und den Datensatz mit Produktionsproblemen speisen - Online-Monitoring sollte neue Fälle für die nächsten Offline-Evals liefern.

Dann wird die Evaluation Teil des Produktentwicklungszyklus und nicht ein Test, der einmal vor dem Deployment durchgeführt wird.

Was uns RAG-Metriken nicht sagen werden

Metriken sind nötig, aber keine von ihnen kann allein die Frage beantworten "Ist unser RAG gut?"

Context Precision kann die Ranking-Qualität zeigen, sagt aber nicht, ob die Quellen wahr sind. Context Recall kann zeigen, ob der Retrieval nötige Evidenz verloren hat, erfordert aber eine entsprechende Referenz. Faithfulness zeigt, ob die Antwort sich an den Kontext hält, garantiert aber nicht, dass der Kontext aktuell ist. Answer Correctness kann eine Abweichung von Ground Truth zeigen, sagt aber allein nicht, ob die Daten, der Retrieval oder die Generierung schuld waren. LLM-as-a-Judge ermöglicht die Automatisierung semantischer Bewertungen, aber sein Ergebnis erfordert ebenfalls Kontrolle und kann eine Kalibrierung gegen Expertenbewertungen benötigen. Und der Similarity Score des Retrievers ist keine Wahrscheinlichkeit, dass die finale Antwort korrekt ist.

Deshalb besteht eine reife RAG-Evaluation nicht darin, eine einzige ideale Metrik zu finden. Sie besteht darin, einen Prozess aufzubauen, der folgende Fragen beantwortet: Was genau ist schiefgelaufen? Woher wissen wir das? Welche Änderung sollte es beheben? Und haben wir nach dieser Änderung das System tatsächlich verbessert, ohne ein anderes wichtiges Element zu verschlechtern?

Erst dann wird die Evaluation zu einem ingenieurtechnischen Werkzeug und nicht nur zu einem Dashboard mit Zahlen.

Sehen Sie, wie wir produktive KI-Systeme und LLM-Integrationen bauen →

Quellen

• OpenAI - Why language models hallucinate.
• LangChain / LangSmith - Evaluate a RAG application.
• LangSmith - Evaluation concepts.
• LangSmith - Application-specific evaluation approaches.
• LangSmith - Improve LLM-as-a-judge evaluators using human feedback.
• Ragas - Context Precision.
• Ragas - Context Recall.
• Ragas - Faithfulness.
• Microsoft Learn - Chunk large documents for RAG and vector search in Azure AI Search.
• Microsoft Learn - Hybrid search using vectors and full text in Azure AI Search.
• Microsoft Learn - Relevance scoring in hybrid search using Reciprocal Rank Fusion.