Tool Receipts, Not Zero-Knowledge Proofs: Practical Hallucination Detection for AI Agents

Das Paper stellt NabaOS vor, ein leichtgewichtiges Verifizierungsframework, das auf der indischen Erkenntnistheorie Nyaya Shastra basiert und durch HMAC-signierte Tool-Empfangsbestätigungen in Echtzeit Halluzinationen von KI-Agenten mit minimalem Latenzüberhead erkennt, wodurch es die Unpraktikabilität kryptografischer Zero-Knowledge-Beweise für interaktive Anwendungen überwindet.

Das Wesentliche

Hier ist eine einfache Erklärung der Forschungspapiere „Tool Receipts, Not Zero-Knowledge Proofs" (Quittungen statt Null-Wissens-Beweise) auf Deutsch, verpackt in anschauliche Bilder und Metaphern.

Das große Problem: Der lügende Assistent

Stellen Sie sich vor, Sie haben einen sehr intelligenten, aber manchmal etwas träumerischen persönlichen Assistenten (eine KI). Er erledigt Dinge für Sie: Er prüft Ihre E-Mails, schaut nach Aktienkursen oder sucht nach Rezepten.

Das Problem ist: Dieser Assistent halluziniert manchmal.

• Er sagt: „Ich habe 3 E-Mails von Alice gefunden", obwohl es nur 1 war.
• Er sagt: „Ich habe die E-Mail von Alice gelesen", obwohl er gar nicht auf den E-Mail-Server geklickt hat.
• Er erfindet eine Website, die es gar nicht gibt, und behauptet, er habe dort nachgeschaut.

Bisher gab es zwei Wege, dem auf die Schliche zu kommen:

1. Der „Magier"-Ansatz (Zero-Knowledge Proofs): Man verlangt von der KI einen mathematischen Beweis, dass sie die Aufgabe wirklich berechnet hat. Das ist wie ein unsichtbarer Zauberer, der beweist, dass er den Hasen aus dem Hut geholt hat. Das Problem: Es dauert ewig (Minuten statt Sekunden) und braucht riesige Computer. Für einen schnellen Chat-Assistenten ist das zu langsam.
2. Der „Vertrauens"-Ansatz: Man glaubt einfach dem Assistenten. Das ist gefährlich, weil er lügen kann.

Die Lösung: NabaOS – Der „Kassenbon"-Ansatz

Die Forscher schlagen eine neue Methode vor, die sie NabaOS nennen. Sie ist inspiriert von einer alten indischen Philosophie (Nyāya), die genau untersucht, woher ein Wissen kommt.

Statt eines komplizierten mathematischen Beweises nutzt NabaOS etwas viel Einfacheres: Digitale Quittungen (Receipts).

Die Analogie: Der Supermarkt-Kassenbon

Stellen Sie sich vor, Sie gehen mit Ihrem Assistenten in einen Supermarkt (das sind die „Tools" wie E-Mail-Server oder Wetter-Apps).

• Das alte Problem: Der Assistent kommt zurück und sagt: „Ich habe 5 Äpfel gekauft." Sie sehen die Äpfel nicht. Er könnte lügen oder sich irren.
• Die NabaOS-Lösung: Jedes Mal, wenn der Assistent etwas im Supermarkt tut, druckt die Kasse automatisch einen unfälschbaren Kassenbon aus.
  • Auf dem Bon steht: „3 Äpfel gekauft", „Zeit: 14:00 Uhr", „Kassierer: E-Mail-Server".
  • Der Bon ist mit einem geheimen Siegel (einem HMAC-Signatur) versehen. Der Assistent kann dieses Siegel nicht fälschen, weil er den Schlüssel nicht hat. Nur die Kasse (das System) kann ihn drucken.

Wenn der Assistent zu Ihnen nach Hause kommt und sagt: „Ich habe 5 Äpfel", schauen Sie sofort auf den Bon.

• Steht dort „3"? -> Lüge! (Er hat die Menge falsch angegeben).
• Gibt es gar keinen Bon für Äpfel? -> Lüge! (Er hat gar nicht eingekauft).
• Steht dort „3", aber er sagt „Ich habe 3 Äpfel"? -> Wahrheit!

Das passiert alles in Millisekunden. Es ist so schnell wie ein Blick auf einen Kassenbon.

Wie funktioniert das genau? (Die 5 Wissens-Quellen)

NabaOS schaut sich nicht nur an, ob die Zahlen stimmen, sondern auch, wie der Assistent zu seiner Antwort kommt. Es nutzt dafür fünf Kategorien (inspiriert von der indischen Philosophie):

1. Direkte Beobachtung (Pratyaks.a): Der Assistent sagt: „Es regnet." -> Check: Steht im Kassenbon des Wetter-Tools „Regen"? Wenn ja: Verifiziert. (Höchste Sicherheit).
2. Schlussfolgerung (Anumāna): Der Assistent sagt: „Alice ist gestresst." (weil sie viele E-Mails geschrieben hat). -> Check: Der Bon zeigt viele E-Mails. Der Assistent schließt daraus auf Stress. Das ist keine direkte Tatsache, aber eine logische Schlussfolgerung. Das System sagt: „Das ist eine Vermutung, keine harte Tatsache."
3. Zeugnis (Śabda): Der Assistent sagt: „Laut Reuters steigen die Zinsen." -> Check: Hat der Assistent wirklich die Reuters-Seite aufgerufen? Wenn ja, wird die Quelle bestätigt.
4. Fehlen (Abhāva): Der Assistent sagt: „Ich habe keine E-Mails gefunden." -> Check: Steht im Bon „0 Ergebnisse"? Wenn ja, ist die Aussage wahr.
5. Ungegründet: Der Assistent sagt: „Ich glaube, morgen wird es schneien." (ohne Tool-Check). -> Check: Kein Bon vorhanden. Das System warnt: „Das ist nur eine Meinung."

Warum ist das besser als alles andere?

• Geschwindigkeit: Es kostet weniger als 15 Millisekunden. Sie warten nicht, während der Assistent einen mathematischen Beweis schreibt.
• Präzision: Es fängt 94 % der Lügen über Tools auf.
• Verständlichkeit: Statt nur „Verifiziert" oder „Nicht verifiziert" zu sagen, gibt es ein Vertrauens-Signal.
  • „Voll verifiziert" (Der Bon stimmt genau).
  • „Meistens verifiziert" (Die Fakten stimmen, aber die Schlussfolgerung ist Ihre Interpretation).
  • „Unzuverlässig" (Hier wurde gelogen oder erfinden).

Zusammenfassung

Stellen Sie sich NabaOS wie einen polizeilichen Ermittler vor, der nicht fragt: „Hast du die Tat begangen?" (was schwer zu beweisen ist), sondern einfach den Tatort-Beweis (den Kassenbon) prüft.

• Wenn der Assistent sagt, er habe etwas getan, gibt es einen Bon.
• Wenn der Bon nicht passt, lügt er.
• Wenn der Bon fehlt, hat er nichts getan.

Das macht KI-Assistenten nicht nur schneller, sondern auch ehrlicher, indem es dem Nutzer zeigt: „Ich habe das gesehen" (Bon vorhanden) oder „Ich habe das nur geraten" (kein Bon). Es ist der Unterschied zwischen blindem Vertrauen und einem klaren, überprüfbaren Kassenbon.

Technische Zusammenfassung

Hier ist eine detaillierte technische Zusammenfassung des Papers „Tool Receipts, Not Zero-Knowledge Proofs: Practical Hallucination Detection for AI Agents" auf Deutsch:

1. Problemstellung: Die Vertrauenslücke bei KI-Agenten

Large Language Model (LLM) Agenten übernehmen zunehmend autonome Aufgaben (E-Mails, Finanzen, Code-Deployments). Ein zentrales Problem ist die Halluzination: Agenten erfinden Tool-Aufrufe, verfälschen Ausgabeanzahlen oder präsentieren Schlussfolgerungen als überprüfte Fakten.

• Das „Cryptographic Wall"-Problem: Nutzer können nicht unterscheiden, ob ein Agent tatsächlich ein Tool aufgerufen hat oder ob die Ergebnisse erfunden sind.
• Versagen bestehender Lösungen (Zero-Knowledge Proofs - ZK): Ansätze wie zkAgent oder zkLLM bieten zwar kryptografische Garantien für die korrekte Ausführung des Modells, sind jedoch für interaktive Agenten unpraktisch:
  • Latenz: Minutenlange Beweiserstellung pro Abfrage (inakzeptabel für Echtzeit).
  • Hardware: Erfordert spezialisierte GPU-Infrastruktur.
  • Semantische Lücke: ZK beweist, dass die Berechnung korrekt lief, nicht aber, dass das Ergebnis faktisch wahr ist. Ein Modell kann einen „korrekt berechneten" Halluzinationsausgang liefern.

2. Methodik: NabaOS und epistemische Verifikation

Die Autoren schlagen NabaOS vor, ein leichtgewichtiges Verifikationsframework, das von der indischen Philosophie Nyāya Śāstra (einer Schule der Erkenntnistheorie) inspiriert ist.

A. Epistemische Klassifizierung (Pramāṇa)

Anstatt einer binären „verifiziert/nicht verifiziert"-Aussage klassifiziert NabaOS jede Behauptung in einer Antwort nach ihrer Erkenntnisquelle (Pramāṇa):

1. Pratyakṣa (Direkte Wahrnehmung): Direkter Tool-Ausgang (z. B. „3 E-Mails von Alice").
2. Anumāna (Schlussfolgerung): Logische Ableitung aus Tool-Daten (z. B. „Alice scheint besorgt").
3. Śabda (Zeugnis): Externe Quellen (z. B. Zitate von Nachrichtenportalen).
4. Abhāva (Abwesenheit): Behauptung, dass nichts gefunden wurde.
5. Ungrounded (Unbegründet): Keine Evidenzbasis.

B. HMAC-signierte Tool-Receipts (Quittungen)

Das Kernstück der Architektur ist die Generierung von Tool Execution Receipts:

• Ablauf: Der Agent-Runtime führt den Tool-Aufruf aus (nicht das LLM), generiert eine kryptografisch signierte Quittung (HMAC-SHA256) und übergibt die Ausgabe samt Receipt-ID an das LLM.
• Inhalt der Receipt: Tool-Name, Hash der Eingabe, Hash der Ausgabe, Ergebnisanzahl, extrahierte Fakten, Zeitstempel und Signatur.
• Sicherheit: Da das LLM keinen Zugriff auf den HMAC-Geheimt Schlüssel hat, kann es keine gültigen Quittungen für nicht ausgeführte Tools fälschen.
• Verifikation: Die Engine prüft in Echtzeit (<15 ms Overhead), ob die im Text des LLM genannten Receipt-IDs existieren, ob die Signaturen gültig sind und ob die behaupteten Fakten (z. B. Anzahl der E-Mails) mit den in der Receipt gespeicherten Fakten übereinstimmen.

C. Cross-Checking-Protokoll für autonome Agenten

Für tiefgreifende autonome Agenten, bei denen der Runtime keine Kontrolle über alle internen Schritte hat, wird ein Cross-Checking-Protokoll eingesetzt:

• Unabhängiges Neuladen von URLs.
• Replay deterministischer Berechnungen.
• Prüfung der zeitlichen Konsistenz.
• Abgleich mit unabhängigen Datenquellen.

3. Schlüsselbeiträge

1. Pramāṇa-Klassifikation: Mapping der sechs epistemischen Kategorien von Nyāya auf den Verifikationsstatus von Agenten-Behauptungen.
2. Unfälschbare Receipts: HMAC-signierte Datenstrukturen, die die Ausführung und Ausgabe von Tools deterministisch nachweisen.
3. Cross-Checking-Protokoll: Ein Mechanismus zur unabhängigen Überprüfung von URLs und Berechnungen für autonome Agenten.
4. NyayaVerifyBench: Ein neuer Benchmark mit 1.800 Szenarien in vier Sprachen (Englisch, Hindi, Chinesisch, Spanisch) und sechs Halluzinationstypen.
5. Kalibrierte Vertrauenssignale: Empirischer Nachweis, dass die abgeleiteten Vertrauenslevel (z. B. „Fully Verified") hochkorreliert mit der tatsächlichen Richtigkeit sind.

4. Ergebnisse

Die Evaluation auf NyayaVerifyBench zeigt folgende Leistungen:

• Erkennungsraten:
  • 94,2 % bei erfundenen Tool-Aufrufen (Fabricated Tool Calls).
  • 87,6 % bei falschen Anzahlen (Count Mismatches).
  • 91,3 % bei falschen Abwesenheitsbehauptungen (False Absence).
  • 78,4 % bei erfundenen Quellen (Source Fabrication).
• Overhead:
  • <15 ms pro Antwort (im Vergleich zu Minuten bei ZK-Proofs).
  • Keine zusätzlichen GPU-Ressourcen erforderlich.
• Vergleich mit Baselines:
  • NabaOS übertrifft Self-Consistency-Checks (45 % Erkennung, +3–5 s Latenz) und RAG-Grounding (52 % Erkennung, hohe False-Positive-Rate).
  • Die Erkennungsrate bleibt über alle vier Sprachen hinweg stabil (ca. 88–93 %), da die Verifikation auf strukturierten Receipt-Daten (nicht auf Text) basiert.
• Vertrauenskalibrierung:
  • Antworten mit dem Label „Fully Verified" sind zu 98,7 % faktisch korrekt.
  • Als „Unreliable" markierte Antworten sind nur zu 23,4 % korrekt.

5. Bedeutung und Fazit

NabaOS adressiert das fundamentale Problem der semantischen Integrität (sind die Behauptungen wahr?) statt nur der computationalen Integrität (wurde der Code korrekt ausgeführt?).

• Praktikabilität: Im Gegensatz zu Zero-Knowledge-Proofs ist NabaOS für interaktive, persönliche Agenten geeignet, da es extrem geringe Latenz und keine spezielle Hardware benötigt.
• Nuancierte Transparenz: Durch die epistemische Klassifizierung erhalten Nutzer nicht nur ein Ja/Nein-Signal, sondern verstehen, wie der Agent zu einer Erkenntnis gelangt (direkte Beobachtung vs. Schlussfolgerung). Dies ermöglicht dem Nutzer, das Vertrauen situativ anzupassen.
• Zukunftsperspektive: Die Autoren sehen NabaOS als komplementär zu ZK-Proofs an (Kombination aus Berechnungs- und semantischer Verifikation), betonen aber, dass für den aktuellen Bedarf an vertrauenswürdigen Agenten die receipt-basierte Verifikation die kosteneffizienteste und effektivste Lösung ist.

Das Paper schließt mit der Freigabe von NyayaVerifyBench und der Rust-Implementierung als Open-Source-Software.