Tool Calling

Der typische Ablauf

Die Anwendung beschreibt verfügbare Werkzeuge mit Name, Zweck und erwarteten Parametern. Ein Werkzeug kann beispielsweise freie Termine abfragen, ein Ticket anlegen oder einen Bestellstatus lesen. Das Modell erhält diese Beschreibungen zusammen mit dem Gesprächskontext. Wenn ein Werkzeug benötigt wird, erzeugt es einen strukturierten Vorschlag mit Funktionsname und Argumenten.

Anschließend übernimmt die Anwendung. Sie validiert die Struktur, prüft Berechtigungen und führt die hinterlegte Funktion aus. Das Ergebnis wird dem Dialog wieder zur Verfügung gestellt. Erst danach formuliert das System eine Antwort oder fordert weitere Angaben an. Offizielle Dokumentationen zu Function Calling beschreiben diese Trennung ausdrücklich: Das Modell erzeugt Argumente, während die Entwickleranwendung den eigentlichen Funktionsaufruf kontrolliert.

Sicherheit und Kontrolle

Tool Calling ist eine Vertrauensgrenze. Modellvorschläge sind Eingaben und müssen wie andere externe Daten validiert werden. Die Anwendung sollte nur bekannte Werkzeuge akzeptieren, Parameter gegen ein Schema prüfen und pro Werkzeug minimale Berechtigungen vergeben. Ein Lesewerkzeug für Terminverfügbarkeit benötigt keine Berechtigung, Termine zu löschen.

Schreibende Aktionen brauchen zusätzliche Kontrollen. Dazu können explizite Bestätigung, Identitätsprüfung, Wertebereiche, Idempotenzschlüssel und nachvollziehbare Protokolle gehören. Freitext aus dem Gespräch darf nicht ungeprüft zu Datenbankabfragen oder Shell-Befehlen werden. Fehlermeldungen sollten dem Dialog genug Kontext für eine sichere Rückfrage geben, aber keine internen Geheimnisse offenlegen.

• Werkzeugdefinition: Name, Zweck und zulässige Parameter.
• Modellvorschlag: strukturierter Aufruf, noch keine ausgeführte Aktion.
• Anwendungsprüfung: Schema, Berechtigung, Geschäftsregel und Bestätigung.
• Ergebnis: strukturierte Antwort oder kontrollierter Fehler zurück an den Dialog.

Tool Calling in Voice AI

In einem Telefonprozess macht Tool Calling aus einem reinen Auskunftsdialog eine kontrollierte Prozessschnittstelle. Ein Voice-Agent kann nach einer Kundennummer fragen, den Bestellstatus abrufen oder nach ausdrücklicher Bestätigung einen Termin buchen. Speech-to-Text liefert die gesprochenen Angaben, die Dialoglogik sammelt fehlende Werte, und das Werkzeug spricht mit dem Zielsystem.

Die Telefonumgebung erhöht die Anforderungen. Zahlen und Namen können falsch erkannt werden, und die anrufende Person sieht die Parameter nicht auf einem Bildschirm. Kritische Werte sollten deshalb hörbar wiederholt und bestätigt werden. Während ein langsames Zielsystem antwortet, benötigt der Dialog eine passende Zwischenmeldung. Bei einem Fehler muss klar sein, ob die Aktion gar nicht ausgeführt wurde oder ihr Ergebnis nur nicht zurückkam.

Betrieb und Tests

Ein Testkatalog umfasst nicht nur den Erfolgsfall. Fehlende Pflichtwerte, falsche Formate, abgelaufene Berechtigungen, Zeitüberschreitungen, doppelte Aufrufe und teilweise Ausfälle müssen reproduzierbar behandelt werden. Für schreibende Werkzeuge ist besonders wichtig, dass eine wiederholte Anfrage nicht versehentlich zwei Tickets oder zwei Termine erzeugt.

Im Monitoring sollten Werkzeugname, Laufzeit, Ergebnisstatus und eine datensparsame Fehlerklasse erfasst werden. Geschäftliche Erfolgsmetriken prüfen zusätzlich, ob die richtige Aktion mit den richtigen Daten ausgeführt wurde. Ein flüssig klingender Dialog kann fachlich trotzdem falsch sein; ein korrektes Tool-Ergebnis kann durch eine unklare Sprachausgabe missverstanden werden. Beide Ebenen brauchen eigene Tests.