💻 computer science

NTILC: Neural Tool Invocation via Learned Compression

NTILC ist ein neuronales Framework, das lineare In-Context-Tool-Registry-Lookups durch latente gelernte Abfragen und eine signaturbewusste zusammengesetzte Zielgröße ersetzt und dabei eine Reduktion der Kontext-Token um über 95 % sowie eine bis zu 74 % geringere Latenz erreicht, während es gleichzeitig eine hohe Selektionsgenauigkeit für agentische Tool-Calling-Modelle beibehält.

Ursprüngliche Autoren: Andrew Krikorian, Yayuan Li, Jason J. Corso

Veröffentlicht 2026-06-08

📖 4 Min. Lesezeit☕ Kaffeepausen-Lektüre

CC BY 4.0

Ursprüngliche Autoren: Andrew Krikorian, Yayuan Li, Jason J. Corso

Originalarbeit lizenziert unter CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dies ist eine KI-generierte Erklärung des untenstehenden Papers. Sie wurde nicht von den Autoren verfasst oder gebilligt. Für technische Genauigkeit konsultieren Sie das Originalpaper. Vollständigen Haftungsausschluss lesen

Stellen Sie sich vor, Sie sind ein hochqualifizierter persönlicher Assistent (die KI), der Aufgaben für Sie erledigen muss. Um dies zu tun, besitzen Sie ein riesiges Telefonbuch (das Tool Registry) mit tausenden verschiedenen Diensten: Wetterberichten, Taschenrechnern, Dateieditoren, Websuchmaschinen und vielem mehr.

Der alte Weg: Der „Alles-Lesen“-Ansatz

Derzeit muss Ihr Assistent, wenn Sie ihm eine Frage wie „Wie ist das Wetter in Ann Arbor?“ stellen, das gesamte Telefonbuch laut vorlesen, bevor er antworten kann.

Das Problem: Wenn Ihr Telefonbuch 5.000 Einträge hat, ist das viel Lesearbeit! Es dauert lange (Latenz), kostet viel Geld (Token-Verbrauch) und der Assistent wird durch all die irrelevanten Informationen verwirrt (wie das Lesen über „Dateieditierung“, wenn Sie eigentlich nur das Wetter wissen wollen).
Das Ergebnis: Wenn das Telefonbuch wächst, wird der Assistent langsamer und macht mehr Fehler, weil er von den Hintergrundgeräuschen überwältigt wird.

Der neue Weg: NTILC (Der „Smart Index“-Ansatz)

Das Paper stellt NTILC vor, ein neues System, das die Art und Weise verändert, wie der Assistent das richtige Werkzeug findet. Anstatt das ganze Telefonbuch zu lesen, nutzt NTILC einen intelligenten, vorgefertigten Index (wie einen digitalen Bibliothekskatalog).

So funktioniert es, Schritt für Schritt:

Die Anfrage: Sie fragen: „Wie ist das Wetter?“
Die Übersetzung: Anstatt das ganze Buch zu lesen, übersetzt das System Ihre Frage sofort in einen „Geheimcode“ (ein Embedding), der die Absicht Ihrer Anfrage repräsentiert.
Der Abgleich: Es vergleicht Ihren Geheimcode mit einer vorberechneten Liste von Geheimcodes für jedes Werkzeug im Register. Es findet in einem Bruchteil einer Sekunde die nächste Übereinstimmung (das Wetter-Werkzeug).
Die Aktion: Der Assistent schaut nur auf die spezifische Seite des Wetter-Werkzeugs, um die Details zu erhalten, die er benötigt, um Ihnen eine Antwort zu geben.

Der Zaubertrick: Der Assistent muss niemals das 5.000-seitige Telefonbuch lesen. Er liest nur die eine Seite, die er braucht. Dies reduziert die „Lesezeit“ (Kontextnutzung) um über 95 % und macht den Prozess viel schneller.

Der knifflige Teil: „Semantic Blur“

Es gibt ein spezifisches Problem, das das Paper löst. Stellen Sie sich zwei Werkzeuge in Ihrem Telefonbuch vor:

Werkzeug A: „Wetter abrufen“ (erfordert eine Postleitzahl).
Werkzeug B: „Wetter abrufen“ (erfordert Breitengrad und Längengrad).

Sie klingen exakt gleich! Wenn der Assistent nur nach den Namen sucht, könnte er das falsche Werkzeug wählen. Wenn Sie eine Postleitzahl angeben, er aber das Werkzeug wählt, das Breitengrad und Längengrad benötigt, wird das Werkzeug fehlschlagen. Das Paper nennt dies „Semantic Blur“ – wenn Werkzeuge gleich aussehen, aber unterschiedlich funktionieren.

Die Lösung: Die „Functional Margin“
NTILC verwendet eine spezielle Trainingsmethode namens Functional Margin Loss. Denken Sie an einen strengen Lehrer, der dem Assistenten nicht nur beibringt, den Namen des Werkzeugs zu erkennen, sondern auch dessen Form zu spüren.

Selbst wenn zwei Werkzeuge den gleichen Namen haben, aber ihre „Formen“ (die Argumente, die sie benötigen) unterschiedlich sind, drückt das System sie in seinem Speicher weit auseinander.
Dies stellt sicher, dass das System, wenn Sie nach „Wetter mit einer Postleitzahl“ fragen, genau weiß, welches der beiden „Wetter“-Werkzeuge es auswählen muss, um das falsche zu vermeiden.

Die Ergebnisse

Das Paper hat dies auf mehreren öffentlichen Datensätzen (wie ToolBench und API-Bank) getestet und festgestellt:

Geschwindigkeit: Es ist bis zu 74 % schneller als die alte Methode.
Effizienz: Es reduziert die Menge an „Lesen“, die die KI leisten muss, um über 95 %.
Genauigkeit: Es ist genauso genau wie die alte Methode, selbst wenn das Telefonbuch riesig wird (tausende Werkzeuge).

Zusammenfassung

NTILC ist wie ein Upgrade von einem Bibliothekar, der jedes einzelne Buch in der Bibliothek liest, um Ihre Antwort zu finden, hin zu einem Bibliothekar, der einen perfekten, sofortigen Index besitzt. Er weiß genau, welches Buch Sie brauchen, ohne jemals die anderen Bücher zu öffnen; das spart Zeit und verhindert Verwirrung, selbst wenn die Bibliothek auf Millionen von Büchern anwächst.

Technisches Resümee: NTILC (Neural Tool Invocation via Learned Compression)

1. Problemstellung

Agentische Systeme, die auf Large Language Models (LLMs) basieren, sind zunehmend auf umfangreiche Registerlisten von aufrufbaren APIs, Funktionen und lokalen Aktionen angewiesen. Der Standardansatz, In-Context Tooling (ICT), fügt die vollständige Textbeschreibung jedes verfügbaren Werkzeugs in den Prompt des Modells ein, bevor eine Benutzeranfrage verarbeitet wird. Während diese Methode für kleine Register effektiv ist, verursacht sie eine Token-Kostenstruktur, die linear ( $O(N)$ ) mit der Anzahl der Werkzeuge skaliert.

Mit wachsenden Registern (z. B. 5.000+ Werkzeuge) stößt ICT auf drei kritische Einschränkungen:

Kontext-Erschöpfung: Werkzeug-Schemata (durchschnittlich ~120 Token) verbrauchen schnell das Kontextfenster, wodurch wenig Raum für aufgabenspezifische Informationen bleibt.
Latenz und Kosten: Die Verarbeitung massiver Kontextfenster erhöht die Prefill-Zeit und die Inferenzkosten.
Degradierung der Auswahlgenauigkeit: Die Präsenz zahlreicher irrelevanter Werkzeuge („Distraktoren“) und semantische Unschärfe (semantic blur) – bei der Werkzeuge fast identische natürliche Beschreibungen teilen, aber inkompatible Ausführungssignaturen besitzen (z. B. unterschiedliche Argumenttypen) – führt zu höheren Fehlerraten bei der Werkzeugauswahl.

2. Methodik: NTILC

Die Autoren schlagen NTILC (Neural Tool Invocation via Learned Compression) vor, ein Framework, das das linear skalierende In-Context-Registry-Scanning durch einen externen, gelernten latenten Retrieval-Schritt ersetzt.

2.1 Inferenz-Pipeline

Anstatt das vollständige Register in den Prompt einzubetten, arbeitet NTILC wie folgt:

Intent-Generierung: Ein Backbone-LLM ( $M$ ) erhält die Benutzeranfrage ( $\chi$ ) und generiert einen Plan-Block ( $P$ ), der natürliche Sprach-Intents für die Werkzeuge enthält.
Kodierung: Ein dedizierter Encoder ( $E$ ) bildet diese Intents in einen trainierten Embedding-Raum ab.
Latente Retrieval: Eine Nearest-Neighbor-Suche (NNS) wird gegen ein vorgefertigtes, Offline-Tool-Index ( $V$ ) durchgeführt, um den relevantesten Werkzeug-Cluster-Identifikator ( $\hat{t}$ ) zu finden.
Beschränkte Generierung: Das Schema des abgerufenen Werkzeugs wird an das LLM übergeben. Unter Verwendung der Outlines-Bibliothek beschränkt ein endlicher Automat (Finite State Machine, FSM) das Vokabular des Modells, um sicherzustellen, dass die generierten Argumente syntaktisch korrekt sind und strikt der Signatur des ausgewählten Werkzeugs entsprechen.
Ausführung: Der Dispatcher führt das Werkzeug aus und gibt das Ergebnis an das LLM zurück, um die finale Antwortsynthese zu erstellen.

Dieser Ansatz reduziert die Registry-Prompt-Token-Kosten von $O(N)$ auf $O(1)$ , da das Register als Embedding-Index anstelle von Text im Kontextfenster externalisiert wird.

2.2 Trainingsziel

Eine zentrale Herausforderung besteht darin, die semantische Unschärfe zu lösen, bei der semantisch ähnliche Werkzeuge funktional inkompatibel sind. NTILC adressiert dies über ein zusammengesetztes Trainingsziel für den Encoder ( $E$ ):

Circle Loss: Wird für die allgemeine Abgleichung von Query und Werkzeug verwendet, wobei paarweise Ähnlichkeiten gewichtet werden, um die Gradientensignale nahe der Entscheidungsgrenze der Retrieval-Entscheidung zu konzentrieren.
Functional Margin (FM) Loss: Ein neuartiger Verlustterm, der darauf ausgelegt ist, Werkzeuge mit ähnlichen Beschreibungen, aber inkompatiblen Signaturen zu trennen.
- Er berechnet einen Kompatibilitäts-Score ($compat$) basierend auf der Schnittmenge von Argumentnamen, Typen und Rückgabe-Schemata.
- Er weist Paaren mit funktionaler Inkompatibilität ein Repulsionsgewicht ( $w_{ij}$ ) zu.
- Er wendet eine Margin-Strafe speziell auf „Hard Negatives“ an (semantisch nah stehende, aber funktional distinkte Werkzeuge), um diese im Embedding-Raum voneinander weg zu drücken.

Das Gesamtziel ist $L_{dispatch} = \lambda_1 L_{circle} + \lambda_2 L_{FM}$ .

3. Zentrale Beiträge

Framework-Innovation: Einführung von NTILC, welches die Kapazität eines Agenten vom Prompt-Längen-Verhältnis entkoppelt, indem es das Werkzeug-Register in einen gelernten Embedding-Index externalisiert und so die Registry-Prompt-Tokens von $O(N)$ auf effektiv Null reduziert.
Functional Margin Loss: Vorschlag einer signatur-bewussten Verlustfunktion, die explizit die Trennung zwischen semantisch ähnlichen, aber funktional inkompatiblen Werkzeugen erzwingt und damit das Problem der „semantischen Unschärfe“ direkt adressiert.
Umfassende Evaluierung: Evaluierung über fünf öffentliche Datensätze (ToolBench, BFCL, API-Bank, MetaTool, ToolEyes), die die Leistung über variierende Registry-Größen hinweg demonstriert.

4. Experimentelle Ergebnisse

Die Autoren evaluierten NTILC gegen ICT-Baselines (einschließlich Qwen3-27B, Ministral 3, Kimi Moonlight und proprietäre Modelle wie ChatGPT 5 und Claude Sonnet 4.6) auf öffentlichen Datensätzen.

Kontext-Reduktion: NTILC reduziert den Verbrauch des Kontextfensters um über 95 %. Für ein Register von 5.000 Werkzeugen benötigt ICT ca. 600.000 Input-Token, während NTILC nur den Intent und das ausgewählte Schema benötigt (<5.000 Token).
Latenz: NTILC reduziert die Inferenzlatenz um bis zu 74 % im Vergleich zu Long-Context-ICT-Baselines (z. B. sank die Latenz bei ToolBench von 5.663 ms auf 1.452 ms).
Genauigkeit: NTILC hält Parität mit State-of-the-Art ICT-Modellen in der Top-1- und Top-5-Genauigkeit.
- Auf ToolBench erreichte NTILC eine Top-1-Genauigkeit von 98 % bei null Registry-Prompt-Token.
- In semantisch unscharfen Teilmengen verbesserte die Einbeziehung des Functional Margin Loss die Genauigkeit bei semantischer Unschärfe (Semantic-Blur Accuracy) von 70,8 % (nur Circle Loss) auf 75,0 %, während die funktionale Fehlerrate auf 8,7 % gesenkt wurde.

5. Bedeutung und Ansprüche

Das Paper behauptet, dass NTILC zeigt, dass Werkzeug-Register keine Notwendigkeit im Kontextfenster haben. Durch die Überführung des Registers in einen kompakten Embedding-Index ermöglicht das Framework:

Entkopplung der Kapazität von der Kontextlänge: Die Leistung des Agenten degradiert nicht, wenn das Werkzeug-Register skaliert.
Lösung des „Semantische Unschärfe“-Problems: Durch den Functional Margin Loss lernt das Modell, zwischen textuell ähnlichen, aber funktional distinkten Werkzeugen zu unterscheiden – ein Ausfallmodus, der bei standardmäßigem semantischem Retrieval häufig auftritt.
Ermöglicht Skalierbarkeit: Der Ansatz erlaubt den Einsatz von Agenten mit massiven Werkzeug-Registern, ohne prohibitive Token-Kosten oder Latenzstrafen zu verursachen.

Die Autoren weisen auf Limitationen hin, insbesondere dass NTILC eine Offline-Indizierung erfordert und bei hochdynamischen oder zustandsabhängigen Werkzeug-Dokumentationen ohne häufige Re-Indizierung Schwierigkeiten haben könnte. Sie betonen zudem, dass während NTILC die Selektionseffizienz verbessert, Sicherheits- und Richtlinienanforderungen (z. B. Allow-Lists) separate Anliegen bleiben, die mit dem Dispatch-Mechanismus kombiniert werden müssen.