Function Calling in Sprachassistenten: Wie Zustandsmanagement Halluzinationen reduziert


André Martin
André Martin
28. August 2025  - 5 Min. Lesezeit
Function Calling in Sprachassistenten: Wie Zustandsmanagement Halluzinationen reduziert

Zusammenfassung

Große Sprachmodelle können bei Function Calls technische Parameter wie Produkt- oder Tarif-IDs halluzinieren, insbesondere wenn mehrere Werte gleichzeitig übergeben werden müssen. In komplexen Bestellprozessen kann dies zu fehlerhaften oder ungültigen Backend-Anfragen führen. Eine deutlich zuverlässigere Lösung besteht darin, Benutzerentscheidungen schrittweise zu erfassen und jede Auswahl in einem persistenten Zustand (State) zu speichern, bevor die finale Transaktion ausgeführt wird. VoiceBooker unterstützt dieses Vorgehen durch integriertes State-Management und ermöglicht dadurch die Entwicklung robuster Service-Bots mit hoher Zuverlässigkeit und geringer Fehlerquote.

Einführung

Komplexe Telefonassistenten für Support-Hotlines müssen häufig Daten aus Backend-Systemen abrufen, Kundendaten ermitteln oder Transaktionen auf einem Benutzerkonto durchführen. Moderne LLM-basierte Sprachassistenten ermöglichen dabei eine natürliche Gesprächsführung und können über Function Calling mit externen Systemen interagieren.

In der Praxis zeigt sich jedoch schnell eine Herausforderung: Die Zuverlässigkeit von Function Calls hängt maßgeblich davon ab, wie Informationen während des Dialogs gesammelt und verarbeitet werden.

Das Problem: Halluzinierte Parameter und IDs

Betrachten wir ein typisches Beispiel aus der Telekommunikationsbranche. Ein Kunde möchte einen Mobilfunktarif erwerben. Der Bestellprozess besteht aus mehreren Entscheidungen:

  1. Auswahl zwischen Prepaid und Postpaid
  2. Falls Prepaid gewählt wird: Auswahl eines Minutenpakets
  3. Auswahl eines SMS-Pakets

Jede dieser Optionen besitzt im Backend eine eindeutige technische ID. Beispielsweise könnten die verfügbaren Produkte folgendermaßen modelliert sein:

Option ID
Prepaid 101
Postpaid 102
100 Minuten 201
500 Minuten 202
100 SMS 301
500 SMS 302

Ein naiver Ansatz besteht darin, den Sprachassistenten zunächst alle benötigten Informationen sammeln zu lassen und anschließend einen einzigen Function Call auszuführen:

{
  "product_type_id": 101,
  "minutes_package_id": 202,
  "sms_package_id": 302
}

Auf den ersten Blick wirkt dieser Ansatz sinnvoll. In der Praxis treten jedoch häufig Probleme auf.

Große Sprachmodelle neigen dazu zu halluzinieren. Das bedeutet, dass sie Informationen erfinden können, die nicht tatsächlich vorhanden sind. Besonders kritisch wird dies bei technischen IDs. Muss ein Modell mehrere Parameter gleichzeitig ausfüllen, steigt die Wahrscheinlichkeit, dass einzelne Werte verwechselt oder sogar vollständig erfunden werden.

Anstatt beispielsweise die gültige ID 202 zu verwenden, könnte das Modell plötzlich eine nicht existierende ID wie 205 generieren. Je mehr Auswahlmöglichkeiten und Parameter gleichzeitig verarbeitet werden müssen, desto größer wird dieses Risiko.

Warum die Komplexität exponentiell wächst

Das zugrunde liegende Problem ist die Größe des Suchraums.

Wenn beispielsweise zwei Produkttypen, fünf Minutenpakete und vier SMS-Pakete existieren, ergeben sich bereits:

2 × 5 × 4 = 40

mögliche Kombinationen.

Bei realen Produkten können schnell hunderte oder tausende gültige Kombinationen entstehen. Das Modell muss dann nicht nur die richtige Option identifizieren, sondern gleichzeitig mehrere korrekte IDs auswählen und konsistent miteinander kombinieren.

Diese Art von kombinatorischer Komplexität erhöht die Fehleranfälligkeit erheblich.

Der bessere Ansatz: Zustandsbasiertes Sammeln von Informationen

Eine deutlich robustere Strategie besteht darin, Informationen schrittweise zu erfassen und in einem zentralen Zustand (State) zu speichern.

Der Dialog könnte beispielsweise wie folgt verlaufen:

Schritt 1: Produkttyp auswählen

{
  "product_type_id": 101
}

Der Wert wird im State gespeichert.

Schritt 2: Minutenpaket auswählen

{
  "minutes_package_id": 202
}

Der neue Wert wird ebenfalls im State gespeichert.

Schritt 3: SMS-Paket auswählen

{
  "sms_package_id": 302
}

Auch dieser Wert landet im State.

Der Sprachassistent muss dabei jeweils nur eine einzelne Entscheidung treffen. Anstatt aus allen möglichen Kombinationen gleichzeitig auszuwählen, konzentriert er sich pro Schritt auf eine begrenzte Menge von Optionen.

Erst nachdem alle Informationen vollständig gesammelt wurden, erfolgt ein finaler Commit:

{
  "product_type_id": 101,
  "minutes_package_id": 202,
  "sms_package_id": 302
}

Da sämtliche IDs bereits zuvor validiert und gespeichert wurden, reduziert sich das Risiko von Halluzinationen drastisch.

Warum dieser Ansatz zuverlässiger ist

Der entscheidende Vorteil liegt in der Reduktion der kognitiven Last für das Modell.

Bei einem einzelnen Function Call mit vielen Parametern muss das LLM:

  • Mehrere Entscheidungen gleichzeitig treffen
  • Die korrekten IDs erinnern
  • Die richtige Kombination bilden
  • Alle Werte in einem Schritt ausgeben

Beim zustandsbasierten Ansatz dagegen muss das Modell jeweils nur:

  • Eine Entscheidung treffen
  • Eine einzige ID auswählen
  • Diese im State speichern

Dadurch sinkt die Wahrscheinlichkeit von Fehlern erheblich. Statt eines großen kombinatorischen Problems entstehen mehrere kleine und deutlich einfachere Aufgaben.

VoiceBooker und integriertes State Management

VoiceBooker unterstützt dieses Paradigma durch ein integriertes State-Management.

Während der gesamten Gesprächsdauer steht ein JSON-Objekt zur Verfügung, das bei jedem Dialogschritt gelesen und aktualisiert werden kann. Bereits erfasste Informationen bleiben dadurch persistent verfügbar und müssen nicht erneut vom Modell rekonstruiert werden.

Ein typischer State könnte beispielsweise folgendermaßen aussehen:

{
  "customer_id": "12345",
  "product_type_id": 101,
  "minutes_package_id": 202,
  "sms_package_id": 302
}

Jede neue Benutzerentscheidung ergänzt lediglich den bestehenden Zustand. Erst wenn alle erforderlichen Informationen vorliegen, wird die eigentliche Transaktion ausgelöst.

Dieses Muster führt zu deutlich zuverlässigeren Function Calls und minimiert Halluzinationen bei technischen Parametern.

Fazit

Function Calling ist eine zentrale Technologie für moderne Sprach- und Support-Assistenten. Die größte Herausforderung besteht jedoch nicht im Aufruf von Funktionen selbst, sondern in der zuverlässigen Ermittlung der benötigten Parameter.

Werden mehrere IDs und Entscheidungen gleichzeitig verarbeitet, steigt die Wahrscheinlichkeit von Halluzinationen und fehlerhaften Function Calls deutlich an. Ein zustandsbasierter Ansatz, bei dem Informationen schrittweise gesammelt und gespeichert werden, reduziert die Komplexität erheblich.

Mit dem integrierten State-Management von VoiceBooker lassen sich genau solche Dialoge effizient umsetzen. IDs und andere technische Parameter werden während des Gesprächs sicher im Zustand abgelegt und können am Ende zuverlässig für die finale Transaktion verwendet werden. Dadurch entstehen robuste, skalierbare und qualitativ hochwertige Service-Bots, die auch komplexe Geschäftsprozesse zuverlässig abbilden können.

Tags
Voice AIFunktionsaufrufeZustandsmanagementHalluzinationenGesprächsdesignTechnisch