RAG-Evaluation: Antwortqualität & Halluzinationen messen

RAG-Evaluation heißt, die Antwortqualität eines KI-Assistenten mit Retrieval an festen Kennzahlen zu messen statt am Eindruck aus der Demo. Dafür brauchen Sie drei Dinge: ein Test-Set aus echten Fragen mit abgenommenen Referenzantworten, eine Handvoll RAG-Metriken wie Trefferquote des Retrievals und Grounding, und ein Monitoring, das dieselben Werte in Produktion weiterführt. Halluzinationen lassen sich so nicht völlig ausschließen, aber erkennen, einer Ursache zuordnen und gezielt senken.

Die Empfehlungen stützen sich unter anderem auf die Praxis unseres Gründers. In einem Projekt bei einem Premium-Automobilhersteller hat er einen LLM-Assistenten mit Retrieval über Diagnoseinhalte in eine Diagnoseplattform mit über 15.000 Nutzern pro Monat gebracht. Das geschah in verantwortlicher Rolle, nicht im Auftrag von Amperbytes AI. Die Antwortqualität wurde dort mit definierten Kennzahlen in Grafana und Kibana überwacht.

Warum die Demo für die Bewertung nicht reicht

RAG steht für Retrieval-Augmented Generation: Der Assistent sucht zuerst passende Abschnitte in Ihren Dokumenten und lässt das Sprachmodell die Antwort daraus formulieren. Wie das im Detail funktioniert und wann RAG besser passt als Fine-Tuning, erklären wir im Artikel KI mit eigenen Daten nutzen.

Für die Bewertung ist der zweistufige Aufbau entscheidend. Eine Antwort kann aus zwei Gründen falsch sein: Das Retrieval hat den relevanten Abschnitt nicht gefunden, oder das Modell hat trotz korrektem Kontext etwas hinzugefügt. In der Demo fallen beide Fehler selten auf, weil die Fragen bekannt sind. In Produktion stellen hunderte Nutzer Fragen in eigenen Worten, mit Tippfehlern, Abkürzungen und Annahmen, die in keinem Dokument stehen. Ohne Messung erfahren Sie erst davon, wenn der Fachbereich den Assistenten wieder meidet.

RAG-Evaluation: welche Metriken wirklich zählen

Wir empfehlen sieben Kennzahlen. Die ersten beiden messen Qualität im engeren Sinn, die übrigen zeigen, ob der Assistent im Alltag trägt.

Trefferquote des Retrievals. Für jede Testfrage ist hinterlegt, welcher Abschnitt die Antwort enthält. Liegt er unter den ersten fünf Treffern, zählt die Frage als Treffer. Sinkt dieser Wert, hilft weder ein besserer Prompt noch ein größeres Modell. Als Richtwert für den Go-Live empfehlen wir 85 bis 90 Prozent; den verbindlichen Zielwert legen Sie mit dem Fachbereich fest.

Grounding. Ein Prüfmodell zerlegt die Antwort in einzelne Aussagen und prüft jede gegen den übergebenen Kontext. Aussagen ohne Deckung sind Halluzinationen. Für Fachinhalte, bei denen eine falsche Antwort teuer ist, sollten Sie über 95 Prozent anstreben.

Antwortkorrektheit ergänzt das Grounding. Die Referenzantworten aus dem Test-Set prüfen eine zweite Frage: Ist die Antwort auch richtig und vollständig? Dasselbe Prüfmodell vergleicht die Antwort mit der Referenzantwort. Grounding allein erkennt keine Antwort, die zwar belegt ist, aber die Frage verfehlt. In englischsprachiger Fachliteratur heißen diese Werte Context Recall (Trefferquote), Faithfulness (Grounding) und Answer Correctness (Antwortkorrektheit).

Ablehnungs- und Eskalationsquote gehören zusammen. Ein Assistent, der bei Unsicherheit ablehnt, beantwortet weniger Fragen, liefert aber weniger falsche Antworten. Erst der Trend über Wochen zeigt, ob das System besser wird.

Latenz p95 ist ehrlicher als der Durchschnitt, weil Nutzer sich an die langsamen Antworten erinnern. Kosten pro Antwort ergeben sich aus den verbrauchten Tokens (Textbausteine, nach denen Modellanbieter abrechnen), der Suche und dem Anteil an der Infrastruktur. Sie ändern sich mit jeder Anpassung am Chunking (dem Zerlegen der Dokumente in Abschnitte) oder an der Kontextlänge und gehören deshalb neben die Qualitätswerte. Nutzerbewertungen mit Daumen hoch oder runter liefern wenige, aber wertvolle Signale: Die negativen zeigen, welche Fragen das Test-Set noch nicht abdeckt.

Halluzinationen erkennen und reduzieren

Eine Halluzination ist eine Aussage, die plausibel klingt, aber nicht durch die Quellen gedeckt ist. Um KI-Halluzinationen zu vermeiden, müssen Sie zuerst wissen, an welcher Stelle der Kette sie entstehen.

Retrieval-Fehlgriff oder Modellzusatz

Prüfen Sie bei jeder falschen Antwort aus Test-Set oder Stichprobe zuerst den übergebenen Kontext. War der richtige Abschnitt nicht dabei, liegt ein Retrieval-Fehlgriff vor: Das Modell hat die Lücke mit Wissen aus dem Training gefüllt. Abhilfe schaffen besseres Chunking, eine Hybrid-Suche aus Vektor- und Stichwortsuche oder Synonymlisten. War der Abschnitt dabei und die Antwort trotzdem falsch, handelt es sich um einen Modellzusatz. Hier helfen Prompt, Kontextlänge oder ein anderes Modell. Wer beide Fälle getrennt zählt, verbessert gezielt die richtige Stufe.

Nur aus dem Kontext antworten

Die Datenschutzkonferenz (DSK) nennt in ihrer Orientierungshilfe zu generativen KI-Systemen mit RAG-Methode (Version 1.0, Oktober 2025, geprüft am 29.09.2026) als mögliche Maßnahme einen Systemprompt, der das RAG-System anweist, „ausschließlich mithilfe der referenzierten Quellen zu antworten“. Dort steht die Maßnahme im Zusammenhang mit der Richtigkeit personenbezogener Daten. Die DSK weist außerdem auf zwei Risiken hin. Bei widersprüchlichen Inhalten können Modelle Trainingswissen wiedergeben und die Referenzdokumente verwerfen. Unvollständige oder veraltete Dokumente führen zu unrichtigen Ausgaben. Das ist eine Einordnung der Aufsichtsbehörden, keine Rechtsberatung für Ihren Einzelfall; Datenschutzfragen behandelt der Artikel DSGVO-konforme LLM-Integration.

Über die DSK hinaus empfehlen wir, das Modell im Systemprompt zusätzlich anzuweisen, bei fehlender Information abzulehnen.

Ablehnungsquote bewusst steuern

Ein Assistent, der nie ablehnt, halluziniert zwangsläufig bei Fragen ohne Antwort in den Dokumenten. Deshalb enthält das Test-Set bewusst 10 bis 15 Prozent solcher Fragen, bei denen die richtige Antwort eine Ablehnung ist. Messen Sie zwei Werte getrennt: Wie oft lehnt der Assistent korrekt ab, und wie oft lehnt er ab, obwohl die Antwort im Suchindex (der durchsuchbaren Sammlung aller Abschnitte) steht. Der zweite Wert zeigt, ob die Anweisung zu streng eingestellt ist.

Quellenpflicht

Jede Antwort nennt die Abschnitte, auf denen sie beruht, mit Dokumenttitel und Versionsdatum. Das hat zwei Effekte: Nutzer können eine Aussage in Sekunden prüfen, und Sie können Aussagen ohne Quellenverweis automatisch markieren. Nach der DSK-Orientierungshilfe ermöglicht eine Dokumentation der genutzten Quellen die Nachvollziehbarkeit des Inputs, den das Modell erhalten hat.

Grounding-Schwelle

Für heikle Themen lohnt eine Schwelle vor der Ausgabe: Liegt der Grounding-Wert einer Antwort unter einem festgelegten Wert, zeigt der Assistent statt der Antwort die gefundenen Quellen oder verweist an eine zuständige Person. Die Schwelle legen Sie mit dem Fachbereich anhand des Test-Sets fest. Sie kostet Latenz, weil die Prüfung vor der Ausgabe läuft, und lohnt sich dort, wo eine falsche Antwort teurer ist als eine Rückfrage.

Ein Test-Set aus echten Fragen bauen

Ein Test-Set ist eine Liste von Fragen mit Referenzantwort und Quellenangabe. Es ist das Gegenstück zu automatisierten Tests in der Softwareentwicklung: Bei jeder Änderung an Prompt, Modell, Chunking oder Index läuft es durch.

1. Fragen sammeln. Quellen sind Ticketsysteme, Suchprotokolle des Intranets, Schulungsunterlagen und Gespräche mit den Menschen, die die Fragen heute beantworten. Übernehmen Sie die Formulierungen so, wie sie gestellt werden.
2. Referenzantworten schreiben. Zu jeder Frage die korrekte Antwort in zwei bis vier Sätzen und der Abschnitt, der sie belegt. Rechnen Sie pro Frage mit 10 bis 20 Minuten.
3. Kategorien mischen. Faktenfragen, Fragen über mehrere Abschnitte, Fachjargon und Abkürzungen sowie die Fragen ohne Antwort in den Dokumenten.
4. Vom Fachbereich abnehmen lassen. Zwei Personen prüfen jede Referenzantwort. Ohne diese Abnahme messen Sie gegen die Meinung eines Entwicklers.
5. Versionieren. Das Test-Set liegt im Repository neben dem Code. Ändert sich ein Dokument, ändert sich die Referenzantwort.

Im Projekt unseres Gründers beim Automobilhersteller wurden die KI-Services anhand echter Diagnosefragen nach Antwortqualität, Kosten, Latenz und Datenschutz verglichen; Rückmeldungen aus Werken und Aftersales flossen in diese Bewertung ein. Erst mit dieser gemeinsamen Grundlage ließ sich über Änderungen an Modell, Prompt und Retrieval anhand von Zahlen statt Einzelbeispielen entscheiden. Wie Sie Modelle und Kaufprodukte gegeneinander abwägen, beschreibt der Artikel KI Build vs. Buy.

Qualität in Produktion überwachen

Das Test-Set prüft, was Sie erwarten. Produktion zeigt, was Sie nicht erwartet haben. Im genannten Projekt wurde die Antwortqualität mit definierten Kennzahlen in Grafana und Kibana überwacht. Für Kennzahlen wie Latenz, Ablehnungsquote und Kosten eignet sich ein Metrik-Dashboard, für Fragen, gefundene Abschnitte und Antworten eine durchsuchbare Log-Ablage.

Drei Bausteine reichen für den Anfang:

• Alarme auf drei Werte: Ablehnungsquote steigt, Latenz p95 steigt, Kosten pro Antwort steigen.
• Feedback-Buttons mit optionalem Freitext. Negative Bewertungen zeigen fehlende Dokumente und Lücken im Test-Set.
• Wöchentliche Stichproben. Eine Person aus dem Fachbereich liest 30 bis 50 zufällige Gespräche und bewertet sie nach festem Schema: Kontext passend, Antwort korrekt und belegt, Ton angemessen. Eine Stunde pro Woche findet Fehler, die weder Nutzer melden noch Kennzahlen zeigen.

Jede Änderung am System läuft vorher gegen das Test-Set und danach zwei Wochen unter Beobachtung der Dashboards.

Typische Fehlerquellen

• Chunking. Zu kleine Abschnitte verlieren den Zusammenhang, zu große bringen Rauschen in den Kontext. Häufig werden Tabellen an Chunk-Grenzen zerrissen. Auch die DSK-Orientierungshilfe empfiehlt, dass Chunks möglichst abgeschlossene Sinnabschnitte enthalten und Kopf- und Fußzeilen vorher bereinigt werden. Abschnitte entlang der Dokumentstruktur mit Überlappung schneiden meist besser ab als feste Zeichenlängen.
• Veraltete Dokumente. Alte und neue Versionen liegen parallel im Index, und der Assistent zitiert korrekt aus dem falschen Dokument. Jedes Dokument braucht Versionsdatum und Quelle, der Index einen festen Aktualisierungsrhythmus.
• Fehlende Berechtigungen. Berechtigungen gehören als Filter in die Suche, nicht als nachträgliche Prüfung der Antwort.
• Zu lange Kontexte. Drei bis fünf gut gerankte Abschnitte schlagen zehn mittelmäßige: weniger Ablenkung für das Modell, weniger Latenz und Kosten.
• Formulierungslücke. Nutzer schreiben „Fehlercode“, das Dokument sagt „DTC“ (Diagnostic Trouble Code). Hybrid-Suche und Synonymlisten aus dem Fachbereich schließen die Lücke.
• Änderungen ohne Messung. Ein Prompt wird wegen einer Antwort nachgebessert, drei andere werden schlechter, und ohne Test-Set merkt es niemand.

Vorgehen in sechs Schritten

1. Zielwerte festlegen. Mit dem Fachbereich vereinbaren, welche Trefferquote, welches Grounding und welche Ablehnungsquote für den Go-Live reichen.
2. Test-Set bauen. 50 Fragen mit Referenzantworten, abgenommen.
3. Baseline messen. Den Prototyp einmal vollständig durchlaufen lassen und alle sieben Kennzahlen notieren.
4. Eine Variable pro Iteration ändern. Chunking, dann Retrieval, dann Prompt, dann Modell, jeweils mit Messung.
5. Monitoring vor dem Go-Live aufsetzen. Dashboards, Alarme, Feedback und Stichprobentermin stehen, bevor die erste Nutzergruppe startet.
6. Betrieb einplanen. Monatlicher Qualitätsbericht, Pflege des Test-Sets und Zeit für Verbesserungen. Ein RAG-Assistent ist ein Produkt, kein Projekt mit Enddatum.

Fazit

Die Antwortqualität eines RAG-Assistenten ist eine Kennzahl, kein Gefühl. Ein Test-Set aus 50 bis 200 echten Fragen, sieben RAG-Metriken und ein wöchentlicher Blick in die Produktion zeigen Verschlechterungen, bevor Nutzer sie melden. Halluzinationen senken Sie am wirksamsten, wenn Sie Retrieval-Fehlgriffe und Modellzusätze getrennt zählen und mit Kontextbindung, Quellenpflicht und einer Grounding-Schwelle arbeiten. Wer diese Messung vor dem Go-Live aufbaut, entscheidet über Änderungen anhand von Zahlen statt Einzelbeispielen.

Wenn Sie einen Wissensassistenten über Ihr Firmenwissen planen oder einen Prototyp produktionsreif machen wollen, finden Sie unser Vorgehen unter KI-Chatbot für Unternehmen. Wie der Assistent im Projekt unseres Gründers aufgebaut war, beschreibt das Praxisbeispiel KI-Assistent mit Retrieval für die Fahrzeugdiagnose. Für eine erste Einschätzung Ihres Vorhabens nehmen Sie Kontakt auf.