Die fehlende Ebene im Enterprise-RAG: Wissen, wann man der eigenen KI nicht vertrauen darf

Wie Uncertainty Estimation RAG-Pipelines befähigt, die eigenen Zweifel zu messen und die eigenen Grenzen zu kennen und so echte Zuverlässigkeit im Produktivbetrieb zu erreichen.

In der Luftfahrt ist ein Höhenmesser, der falsche Werte anzeigt, aber intakt wirkt, weitaus gefährlicher als einer, der offensichtlich defekt ist. Ein sichtbarer Ausfall erlaubt dem Piloten, sofort einzugreifen, während ein plausibler Fehler unbemerkt bleibt. Flugsysteme sind deshalb so ausgelegt, dass sie sich lieber vollständig abschalten, als ohne Warnung irreführende Werte anzuzeigen.

Enterprise-Systeme für Retrieval-Augmented Generation (RAG) stehen vor derselben Herausforderung. Unternehmen verbinden Large Language Models (LLMs) mit internen Wissensdatenbanken, in der Erwartung, dass die abgerufenen Informationen korrekt sind und dem Modell zusätzliche Sicherheit in seinen Antworten verleihen. Doch eine selbstsichere Antwort ist nicht automatisch eine richtige.

Interpretiert ein RAG-System Daten falsch oder ruft es unvollständigen Kontext ab, besteht ein hohes Risiko, dass es unbelegte Schlussfolgerungen mit voller Überzeugung präsentiert. Wie in der Luftfahrt ist auch bei einem LLM die Fähigkeit, die eigenen Grenzen zu erkennen, genauso wichtig wie die Fähigkeit, Antworten zu generieren. In unseren Projekten stellen wir jedoch immer wieder fest, dass genau diese essenzielle Funktion in den produktiven Chatbots und RAG-Anwendungen unserer Kunden fehlt.

Uncertainty Estimation liefert genau diese fehlende Sicherheitsebene: Die Pipeline kann Fallbacks auslösen, eine Antwort verweigern oder an einen menschlichen Prüfer eskalieren, statt Halluzinationen stillschweigend als Antwort auszugeben.

‍

Überzeugung ist nicht gleich Zuverlässigkeit: Unsicherheit in RAG-Systemen

Wer Überzeugung mit Gewissheit verwechselt, macht einen grundlegenden Fehler beim Entwurf zuverlässiger RAG-Systeme. Confidence Estimation quantifiziert, wie sicher sich ein Modell bei einer konkreten Vorhersage oder generierten Antwort ist. Sie spiegelt also die Überzeugung des Modells wider, dass seine Antwort korrekt ist. Uncertainty Estimation erfasst dagegen, wie viel Variabilität, Mehrdeutigkeit und Unvorhersehbarkeit in den Ausgaben eines Modells steckt, und liefert damit ein umfassenderes Maß dafür, wie sehr einer Antwort zu trauen ist.

Eine zentrale Schwierigkeit moderner LLMs besteht darin, dass ein hoher Grad an Überzeugung nicht automatisch Korrektheit bedeutet: Ein Modell kann eine äußerst sichere Antwort liefern, selbst wenn die vorliegende Evidenz nicht ausreicht oder die Antwort komplett halluziniert ist. Diese Diskrepanz entsteht, weil LLMs zu systematischer Selbstüberschätzung neigen und bei der Einschätzung der eigenen Verlässlichkeit durchweg scheitern: Sie antworten auch dann mit großer Sicherheit, wenn sie eigentlich unsicher sind [1], [2].

Black-Box Uncertainty: Unsicherheit ohne Modellzugriff messen

Kommerzielle APIs sind vollständige Black Boxen: Weder Gewichte noch Log-Wahrscheinlichkeiten sind zugänglich. Wer Unsicherheit in dieser Umgebung messen will, muss das Ausgabeverhalten empirischen Stresstests unterziehen, statt ins Innere des Modells zu schauen.

‍

Konsistenzbasierte Methoden messen, wie stabil die Ausgaben über mehrere Generierungen hinweg bleiben. Bei üblicher Stichprobenvarianz und hardwarebedingtem Nichtdeterminismus liefert ein Modell, das sich auf klaren Kontext stützen kann, semantisch identische Antworten, während die Generierungen bei schwachem Kontext weit auseinanderlaufen. Techniken wie Degree Matrix [3], Eccentricity [3] und EigV [3] berechnen diese „Bedeutungsvielfalt“ über mehrere Stichproben hinweg und quantifizieren so verborgene Instabilität.

Dasselbe Stabilitätsprinzip lässt sich auf die gesamte RAG-Pipeline ausweiten, deren Zuverlässigkeit von der Konsistenz zwischen Sub-Queries, abgerufenen Kontext-Chunks, Prompt-Strukturen und den Zwischenschritten des Reasonings abhängt. Perturbationsbasierte Methoden wie R²C [4] machen sich das gezielt zunutze: Sie verändern diese Elemente bewusst, variieren etwa Sub-Queries, greifen in Zwischenschritte des Reasonings ein oder fordern das Modell auf, seine Antwort noch einmal zu prüfen. Anschließend beobachten sie, ob sich die finale Antwort ändert. Statt sich allein auf die Stochastizität des Decodings zu verlassen, prüfen diese Methoden, ob die Antwort semantisch konsistent bleibt, wenn man die Pipeline leicht verändert. Kippt schon eine kleine Änderung die Schlussfolgerung, kann das ein starkes Signal dafür sein, dass die ursprüngliche Antwort unzuverlässig ist.

So einfach das Konzept klingt: In der Produktion liefern Black-Box-Techniken bemerkenswert starke Unsicherheitssignale. Der Preis dafür sind Rechenkosten und Latenz, weil pro Nutzeranfrage mehrere API-Aufrufe nötig sind. Für unternehmenskritische Workflows mit Compliance- oder Finanzrisiken ist dieser Mehraufwand allerdings ein geringer Preis für operative Sicherheit.

White-Box Estimation: Unsicherheit mit vollem Modellzugriff messen

Wer Open-Source-Modelle selbst hostet, hat vollständigen Zugriff auf die inneren Zustände des Systems: Token-Wahrscheinlichkeiten, versteckte Repräsentationen und die Attention Maps jeder einzelnen Schicht. Diese vollständige Sicht auf die Architektur erlaubt es, Unsicherheitssignale direkt aus den internen Zuständen und Zwischenrepräsentationen abzuleiten.

• Token-Probability- und Likelihood-Methoden: Manche Closed-Source-APIs geben zwar rohe Log-Wahrscheinlichkeiten heraus, ohne jedoch die internen Repräsentationen des Modells offenzulegen. Diese Zwischenstufe des Zugriffs wird oft als Grey-Box Estimation bezeichnet. Die gängigsten Grey-Box-Signale stützen sich auf die Wahrscheinlichkeitsverteilung der Modellausgabe. Entropiebasierte Methoden erweitern konsistenzbasierte Ansätze, indem sie die Wahrscheinlichkeitsverteilungen über mehrere generierte Stichproben hinweg einbeziehen und so Konsistenz und Token-Likelihoods gemeinsam messen. Predictive Entropy [1] etwa misst die reine Token-Zufälligkeit über die generierten Stichproben, während Semantic Entropy [5] die Stichproben in semantische Äquivalenzklassen gruppiert und die Entropie über diese Cluster statt über exakte Token-Sequenzen berechnet. Andere Methoden wie P(true) [6] bitten das Modell um eine Selbsteinschätzung und messen die Log-Wahrscheinlichkeit, die Bestätigungstokens wie „True“ zugewiesen wird.
• Embedding- und vektorbasierte Methoden: Andere Verfahren nutzen Vektorrepräsentationen, um schon vor oder parallel zur Generierung ein proaktives Risk Scoring durchzuführen. KnowingMore [7] fusioniert Query- und Kontext-Embeddings, um einen leichtgewichtigen Uncertainty Predictor zu kalibrieren, während UtilityRanker [8] die Ausrichtung von Embeddings analysiert, um den tatsächlichen Nutzen der abgerufenen Dokumente zu bewerten, noch bevor die Generierung abgeschlossen ist.
• Attention- und Information-Flow-Methoden: Noch tiefer gehen White-Box-Ansätze, die direkt in die internen Attention-Mechanismen schauen und beobachten, wie Information Schicht für Schicht durch das Modell fließt. Techniken wie FOCUS [9] und Attention Score [10] extrahieren Attention Scores über alle Schichten des Modells, verfolgen so den internen Informationsfluss und verdichten dieses Signal zu einem Unsicherheitswert zur Laufzeit. Darauf aufbauend prüfen Methoden wie Information Flow Reveals When to Trust Language Models [11] anhand dieser internen Attention-Flüsse, ob das Modell seine Aufmerksamkeit tatsächlich auf die für die Anfrage relevanten Kontext-Token richtet. Wer diese Pfade berücksichtigt, erhält einen direkten Beleg dafür, ob eine Ausgabe wirklich in der abgerufenen Evidenz verankert ist oder ob das Modell den Kontext umgeht und halluziniert.

White-Box-Methoden zeichnen ein umfassenderes Bild der Unsicherheit, weil sie die internen Signale und Repräsentationen des Modells nutzen, statt sich allein auf dessen finale Ausgaben zu stützen. Der Zugriff auf Attention-Muster, versteckte Repräsentationen, Token-Wahrscheinlichkeiten und Informationsflüsse liefert zusätzliche Anhaltspunkte dafür, wie das Modell die Anfrage und den abgerufenen Kontext verarbeitet, und damit eine tiefere Grundlage, um zu verstehen, warum eine Ausgabe zuverlässig oder unsicher sein könnte.

Proxy-Modelle: Die Brücke zwischen Black-Box- und White-Box-Estimation

Wer hinter einer geschlossenen API sitzt, ist von White-Box-Techniken nicht völlig ausgeschlossen. Die Kernidee proxybasierter Estimation: Die generierte Antwort des Black-Box-Modells wird per Teacher-Forcing durch ein Open-Source-Surrogatmodell geführt, das näherungsweise interne Signale wie Token-Wahrscheinlichkeiten, versteckte Zustände und die Attention-Dynamik der einzelnen Schichten rekonstruiert [9], [10].

Indem man die Antwort durch diesen transparenten Stellvertreter prüft, lassen sich interne Unsicherheitsmetriken auf eine ansonsten opake Ausgabe anwenden. Erstaunlicherweise erreichen diese aus dem Surrogat abgeleiteten Signale eine Qualität, die echter White-Box-Estimation bemerkenswert nahekommt [9], [12]. Das ist ein wirkungsvoller Kompromiss zwischen der Undurchsichtigkeit einer API und tiefem Einblick in die Architektur.

Ob sich ein Surrogatmodell lohnt, hängt von den konkreten operativen Anforderungen und der eigenen Infrastruktur ab. Steht ein Open-Source-Modell ähnlicher Größenordnung zur Verfügung, das die Ziel-API abbilden kann, ist der Proxy-Ansatz eine attraktive Alternative: Die Unsicherheitsschätzung schrumpft auf einen einzigen Forward Pass zusammen, statt mehrere Generierungsaufrufe zu benötigen. Am Ende steht eine Abwägung zwischen API-Aufrufvolumen und Infrastrukturkomplexität, denn ein zusätzliches Surrogatmodell zu betreiben bringt eigenen Deployment- und Wartungsaufwand mit sich.

‍

Leistungsfähigkeit bewerten: Wie man Methoden benchmarkt und die beste auswählt

Nach Black-Box-, White-Box- und Surrogat-Ansätzen bleibt die Frage, welcher Uncertainty Estimator in der Praxis der richtige ist. Die Antwort ist selten eindeutig: Die eine „beste“ Methode gibt es nicht. Die passende Wahl hängt davon ab, welchen Aspekt von Unsicherheit man erfassen will, sowie von Beschaffenheit und Komplexität der jeweiligen Aufgabe und Daten.

Um zu beurteilen, wie gut sich diese Methoden in der Praxis bewähren, sind einige zentrale Evaluationsmetriken hilfreich:

• AUROC [5]: Wer ein schwellenwertfreies Maß dafür sucht, wie gut ein Unsicherheitswert unzuverlässige oder halluzinierte Generierungen von korrekten trennt, findet in AUROC die naheliegende Wahl. Die Metrik zeigt, ob das Modell weniger zuverlässige Ausgaben generell als unsicherer einstuft, ohne dass ein konkreter Cutoff festgelegt werden muss.
• AUPRC [13]: Sind Halluzinationen oder andere Fehler relativ selten, liefert AUPRC oft ein aussagekräftigeres Bild als AUROC. Die Metrik misst gezielter, wie gut der Unsicherheitswert die wenigen unzuverlässigen Ausgaben unter vielen korrekten identifiziert.
• ECE [14]: Ob ein Unsicherheitswert tatsächlich das aussagt, was er verspricht, lässt sich mit ECE überprüfen. Weist eine Methode einer Gruppe von Ausgaben beispielsweise 80 % Unsicherheit zu, sollten diese Ausgaben nur in etwa 20 % der Fälle korrekt sein. ECE misst, wie genau die vorhergesagten Unsicherheitsniveaus mit dem tatsächlichen Ergebnis übereinstimmen, und macht so sichtbar, welche Methoden systematisch zu viel oder zu wenig Sicherheit ausweisen.

Braucht eine Anwendung klare Schwellenwerte, um unsichere Ausgaben umzuleiten oder abzulehnen, sind Selective-Prediction-Metriken besonders nützlich. Die Risk-Coverage-Kurve [15] zeigt, wie sich die Fehlerrate des Systems verändert, wenn man die Coverage reduziert, indem man unsichere Vorhersagen herausfiltert. AURC (Area Under the Risk-Coverage Curve) fasst diesen Trade-off in einer einzigen Zahl zusammen: Je niedriger der AURC, desto früher erkennt das System unsichere Ausgaben und desto schneller sinkt das Risiko, wenn die Coverage abnimmt.

Letztlich lässt sich kein Uncertainty Estimator isoliert beurteilen. Die richtige Wahl entsteht durch das Benchmarking der Kandidaten auf der eigenen Aufgabe und den eigenen Daten sowie durch die Prüfung, wie gut ihre Unsicherheitsschätzungen unzuverlässige Ausgaben erkennen, kalibriert bleiben und die Entscheidungen tragen, die die Anwendung treffen muss. Diese empirische Evaluation entscheidet, welcher Estimator das nützlichste Signal für die eigene Produktions-RAG-Pipeline liefert.

RAG in der Praxis: Warum Uncertainty Estimation im Realbetrieb entscheidend ist

Auch RAG-Systeme können mit voller Überzeugung falschliegen. Uncertainty Estimation bietet einen Weg, zu erkennen, wann eine Antwort möglicherweise nicht vertrauenswürdig ist, und gibt dem System ein zusätzliches Signal für die Entscheidung, was als Nächstes geschehen soll. In der Praxis lassen sich diese Signale nutzen, um RAG-Pipelines gezielter auf die Verlässlichkeit jeder einzelnen Antwort reagieren zu lassen. Einige zentrale operative Verbesserungen, die wir für unsere Kunden umsetzen:

• Sichere Antworten direkt an die Nutzer weitergeben und unsichere automatisch in ein erneutes Retrieval, an ein stärkeres Modell oder in die menschliche Prüfung umleiten.
• Halluzinierte Ausgaben in risikoreichen Anwendungsbereichen blockieren oder schwärzen, bevor sie die Endnutzer erreichen.
• Routineanfragen von schnellen, kostengünstigen Modellen beantworten lassen und aufwendige Reasoning-Architekturen für die wenigen kritischen Grenzfälle reservieren.
• Aggregierte Unsicherheit über die Zeit verfolgen, um veraltete Vektorindizes, Retrieval-Lücken und Prompt-Drift zu erkennen, bevor sie flächendeckende Probleme verursachen.
• Unsicherheit in der Benutzeroberfläche klar kennzeichnen: Das steuert die Erwartungen der Nutzer, beugt übermäßigem Vertrauen in vorläufige Antworten vor und stärkt zugleich das Vertrauen in belastbare.

Bei Uncertainty Estimation geht es darum, Fehler sichtbar zu machen. Fließen Unsicherheitssignale in die Ausführungslogik einer RAG-Pipeline ein, kann das System entscheiden, wann es antwortet, wann es verifiziert und wann es stoppt, statt jede Ausgabe mit derselben Gewissheit zu behandeln. Das Ziel ist nicht, RAG-Systeme unfehlbar zu machen, sondern zu verhindern, dass Fehler stillschweigend als vertrauenswürdige Antworten akzeptiert werden.

Quellen:

[1] S. Kadavath et al., "Language models (mostly) know what they know," arXiv preprint arXiv:2207.05221, 2022.

[2] M. Xiong et al., "Can LLMs express their uncertainty? An empirical evaluation of confidence elicitation in LLMs," in Proc. Int. Conf. Learn. Represent. (ICLR), 2024. 

[3] Z. Lin, S. Trivedi, and J. Sun, "Generating with confidence: Uncertainty quantification for black-box large language models," Trans. Mach. Learn. Res., 2024.

[4] H. Soudani, H. Zamani, and F. Hasibi, "Uncertainty quantification for retrieval-augmented reasoning," arXiv preprint arXiv:2510.11483, 2025.

[5] L. Kuhn, Y. Gal, and S. Farquhar, "Semantic uncertainty: Linguistic invariances for uncertainty estimation in natural language generation," in Proc. Int. Conf. Learn. Represent. (ICLR), 2023.

[6] S. Kadavath et al., "Language models (mostly) know what they know," arXiv preprint arXiv:2207.05221, 2022.

[7] S. Zhang, C. Gong, and E. Choi, "Knowing more about questions can help: Improving calibration in question answering," arXiv preprint arXiv:2106.01494, 2021.

[8] L. Perez-Beltrachini and M. Lapata, "Uncertainty quantification in retrieval augmented question answering," Trans. Mach. Learn. Res., 2025.

[9] T. Zhang et al., "Enhancing uncertainty-based hallucination detection with stronger focus," in *Proc. Empir. Methods Nat. Lang. Process. (EMNLP)*, 2023.

[10] G. Sriramanan et al., "LLM-Check: Investigating detection of hallucinations in large language models," in Adv. Neural Inf. Process. Syst. (NeurIPS), vol. 37, 2024.

[11] R. Xu, Y. Chen, J. Chen, and S. Xie, "Information flow reveals when to trust language models," in Proc. Int. Conf. Mach. Learn. (ICML), 2026. 

[12] Z. Atf et al., "The challenge of uncertainty quantification of large language models in medicine," arXiv preprint arXiv:2504.05278, 2025.

[13] P. Manakul, A. Liusie, and M. J. F. Gales, "SelfCheckGPT: Zero-Resource Black-Box Hallucination Detection for Generative Large Language Models," in Proc. Empir. Methods Nat. Lang. Process. (EMNLP), 2023, pp. 9004–9017.

[14] C. Guo, G. Pleiss, Y. Sun, and K. Q. Weinberger, "On calibration of modern neural networks," arXiv preprint arXiv:1706.04599, 2017.

[15] F. Zhu, Z. Cheng, X.-Y. Zhang, and C.-L. Liu, "Rethinking confidence calibration for failure prediction," in *Proc. Eur. Conf. Comput. Vis. (ECCV)*, 2022, pp. 518–536.

‍