KI SpotlightNewsDeterministische Namensauflösung soll Tool-Halluzinationen bei KI-Agenten verhindern
Ein Blog-Artikel beschreibt eine deterministische Übersetzungsschicht gegen Tool-Halluzinationen.
Mit KI erstellt◆ Fakten auf einen Blick
- LLMs halluzinieren leicht veränderte Tool-Namen, kürzen lange Bezeichner oder machen Tippfehler, was in Standard-MCP-Implementierungen zu 'Tool not found'-Fehlern führt.
- Das vorgestellte Verfahren führt eine deterministische Übersetzungsschicht zwischen Intent und Ausführung ein, um nicht allein auf die Schema-Adhärenz des LLM zu vertrauen.
- Das Verfahren implementiert eine vierstufige Auflösungshierarchie, die mit einer Exact-Match-Prüfung beginnt und einen Fuzzy Matcher verwendet.
- Das Verfahren zielt darauf ab, Retry-Zyklen zu vermeiden, die Latenz, Token-Verbrauch und das Risiko des Verlusts des Aufgabenkontexts erhöhen.
- Bestehende Verteidigungen wie Tool-Auswahl und Gating setzen voraus, dass der emittierte Call sich auf ein echtes Tool bezieht, und können daher halluzinierte Calls nicht ablehnen.
- Ein training-freier, closed-world resolver (Registry-Mitgliedschaft plus Signaturprüfung) wird als Referenzpunkt vorgeschlagen.
Deterministische Übersetzungsschicht gegen Tool-Halluzinationen
Ein Blog-Artikel stellt ein Verfahren vor, das Tool-Halluzinationen in KI-Agenten durch eine deterministische Übersetzungsschicht verhindern soll. Statt sich allein auf die Fähigkeit des Sprachmodells zu verlassen, das Schema eines Werkzeugs exakt einzuhalten, wird eine nicht-modellbasierte Komponente zwischen Absicht und Ausführung geschaltet. Diese Komponente arbeitet nicht mit Wahrscheinlichkeitsverteilungen, sondern mit einer festen Registry registrierter Tool-Namen und regelbasierten Algorithmen: Der vom LLM erzeugte Bezeichner wird gegen diese Registry geprüft und bei Abweichungen deterministisch aufgelöst. Dadurch ist die Namensauflösung vorhersagbar, transparent und unabhängig von der Token-Vorhersage des Modells.
Der Autor beschreibt das Problem: Auch leistungsfähige Modelle unterliegen sprachlicher Drift. Sie halluzinieren leicht veränderte Tool-Namen, kürzen lange Bezeichner ab oder produzieren Tippfehler. In einer Standard-Implementierung des Model Context Protocol führt das zu einem terminalen Fehler: 'Tool not found'. Der Agent versucht einen Aufruf, scheitert, beobachtet den Fehler, versucht es erneut mit korrigiertem Namen – und erst dann gelingt der Aufruf. Diese Schleife ist nicht nur Latenz, sondern verschwendet Token und erhöht die Wahrscheinlichkeit, dass der Agent während des Wiederholungszyklus den ursprünglichen Aufgabenkontext verliert. Die vorgeschlagene Lösung setzt deshalb nicht auf probabilistische Token-Vorhersage, sondern auf eine deterministische Übersetzungsschicht, die Tool-Namen auflöst.
Vierstufige Auflösung mit Exact Match und Fuzzy Matcher
Die Auflösung folgt einer vierstufigen Hierarchie, die der Autor als priorisierte Suche beschreibt. An erster Stelle steht die Exact-Match-Prüfung: Der vom Agenten gesendete Bezeichner muss exakt mit einem registrierten Tool-Namen übereinstimmen. Ist das nicht der Fall, kommt ein Fuzzy Matcher zum Einsatz, der ähnliche Bezeichner erkennt und zuordnet. Die weiteren Stufen der Hierarchie werden im Beitrag nicht im Detail beschrieben, aber sie dienen dazu, Mehrdeutigkeiten aufzulösen, die Exact Match und Fuzzy Matcher nicht behandeln können.
Ziel des Verfahrens ist es, Retry-Zyklen zu vermeiden. Jeder fehlgeschlagene Aufruf kostet Latenz, verbraucht Token und erhöht das Risiko, dass der Agent während der Wiederholung den ursprünglichen Aufgabenkontext verliert. Die deterministische Übersetzungsschicht übernimmt die Namensauflösung, sodass der Agent nicht selbst den Fehler beobachten und einen neuen Versuch starten muss. Stattdessen wird der Bezeichner direkt aufgelöst, bevor eine Ausführung versucht wird. Dadurch entfällt der Beobachtungs- und Korrekturschritt des Agenten, der sonst zusätzliche Token und Latenz verursacht. Der Beitrag beschreibt die Komponente als Übersetzungsschicht zwischen Intent und Ausführung, die Tool-Auswahl nicht als binäre Existenzprüfung, sondern als priorisiertes Suchproblem behandelt.
