Function calling dans les assistants vocaux: comment la gestion d'état réduit les hallucinations

Résumé

Les grands modèles de langage peuvent halluciner des paramètres techniques comme des identifiants de produits ou de tarifs lors des appels de fonction, surtout lorsque plusieurs valeurs doivent être transmises en même temps. Dans des parcours de commande complexes, cela peut entraîner des requêtes backend incorrectes ou invalides. Une approche beaucoup plus fiable consiste à collecter les décisions de l'utilisateur étape par étape et à stocker chaque choix dans un état persistant avant d'exécuter la transaction finale. VoiceBooker prend en charge cette approche grâce à une gestion d'état intégrée et permet ainsi de créer des bots de service robustes, très fiables et avec un faible taux d'erreur.

Introduction

Les assistants téléphoniques complexes pour les lignes de support doivent souvent récupérer des données à partir de systèmes backend, identifier des informations clients ou exécuter des transactions sur un compte utilisateur. Les assistants vocaux modernes basés sur des LLM permettent un dialogue naturel et peuvent interagir avec des systèmes externes via le function calling.

En pratique, une difficulté apparaît toutefois rapidement: la fiabilité des appels de fonction dépend fortement de la manière dont les informations sont collectées et traitées pendant le dialogue.

Le problème: paramètres et identifiants halluciné(e)s

Prenons un exemple typique du secteur des télécommunications. Un client souhaite souscrire à un forfait mobile. Le parcours de commande se compose de plusieurs décisions:

1. Choisir entre prépayé et postpayé
2. Si le prépayé est choisi: sélectionner un pack de minutes
3. Choisir un pack SMS

Chacune de ces options possède dans le backend un identifiant technique unique. Par exemple, les produits disponibles pourraient être modélisés comme suit:

Une approche naïve consiste à laisser d'abord l'assistant vocal collecter toutes les informations nécessaires, puis à exécuter un seul appel de fonction:

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

À première vue, cette approche semble logique. En pratique, elle pose toutefois souvent des problèmes.

Les grands modèles de langage ont tendance à halluciner. Cela signifie qu'ils peuvent inventer des informations qui n'existent pas réellement. Cela devient particulièrement critique lorsqu'il s'agit d'identifiants techniques. Si un modèle doit remplir plusieurs paramètres en même temps, la probabilité de confondre des valeurs ou d'en inventer une augmente.

Au lieu d'utiliser l'ID valide 202, par exemple, le modèle peut soudain générer un identifiant inexistant comme 205. Plus il y a d'options et de paramètres à traiter simultanément, plus ce risque augmente.

Pourquoi la complexité croît de manière exponentielle

Le problème fondamental est la taille de l'espace de recherche.

S'il existe par exemple deux types de produits, cinq packs de minutes et quatre packs SMS, on obtient déjà:

2 × 5 × 4 = 40

combinaisons possibles.

Dans des produits réels, des centaines ou des milliers de combinaisons valides peuvent apparaître rapidement. Le modèle doit alors non seulement identifier la bonne option, mais aussi sélectionner plusieurs identifiants corrects et les combiner de manière cohérente.

Ce type de complexité combinatoire augmente fortement la probabilité d'erreurs.

Une meilleure approche: collecte d'informations basée sur l'état

Une stratégie beaucoup plus robuste consiste à collecter les informations étape par étape et à les stocker dans un état central.

Le dialogue pourrait se dérouler ainsi:

Étape 1: choisir le type de produit

{
  "product_type_id": 101
}

La valeur est stockée dans l'état.

Étape 2: choisir le pack de minutes

{
  "minutes_package_id": 202
}

La nouvelle valeur est également stockée dans l'état.

Étape 3: choisir le pack SMS

{
  "sms_package_id": 302
}

Cette valeur est elle aussi enregistrée dans l'état.

À chaque étape, l'assistant vocal n'a plus qu'une seule décision à prendre. Au lieu de choisir parmi toutes les combinaisons possibles en même temps, il se concentre sur un ensemble limité d'options à chaque étape.

Ce n'est qu'une fois toutes les informations collectées que l'engagement final est exécuté:

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

Comme tous les identifiants ont déjà été validés et stockés au préalable, le risque d'hallucination diminue fortement.

Pourquoi cette approche est plus fiable

L'avantage décisif réside dans la réduction de la charge cognitive pour le modèle.

Avec un seul appel de fonction contenant de nombreux paramètres, le LLM doit:

• prendre plusieurs décisions à la fois
• mémoriser les bons identifiants
• former la bonne combinaison
• renvoyer toutes les valeurs en une seule étape

Avec l'approche basée sur l'état, en revanche, le modèle doit seulement:

• prendre une décision
• sélectionner un identifiant
• l'enregistrer dans l'état

La probabilité d'erreurs baisse ainsi considérablement. Au lieu d'un grand problème combinatoire, on crée plusieurs tâches petites et beaucoup plus simples.

VoiceBooker et la gestion d'état intégrée

VoiceBooker prend en charge ce paradigme grâce à une gestion d'état intégrée.

Tout au long de la conversation, un objet JSON est disponible et peut être lu et mis à jour à chaque étape du dialogue. Les informations déjà recueillies restent ainsi disponibles de manière persistante et n'ont pas besoin d'être reconstruites par le modèle.

Un état typique pourrait par exemple ressembler à ceci:

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

Chaque nouvelle décision de l'utilisateur ne fait qu'enrichir l'état existant. Ce n'est que lorsque toutes les informations requises sont présentes que la transaction réelle est déclenchée.

Ce schéma conduit à des appels de fonction beaucoup plus fiables et minimise les hallucinations sur les paramètres techniques.

Conclusion

Le function calling est une technologie centrale pour les assistants vocaux et de support modernes. La plus grande difficulté n'est toutefois pas l'appel de fonction lui-même, mais l'identification fiable des paramètres nécessaires.

Lorsque plusieurs identifiants et décisions sont traités en même temps, la probabilité d'hallucinations et d'appels de fonction incorrects augmente fortement. Une approche basée sur l'état, dans laquelle les informations sont collectées et enregistrées étape par étape, réduit considérablement la complexité.

Grâce à la gestion d'état intégrée de VoiceBooker, ce type de dialogue peut être implémenté efficacement. Les identifiants et autres paramètres techniques sont stockés en toute sécurité dans l'état pendant la conversation et peuvent ensuite être utilisés de manière fiable pour la transaction finale. On obtient ainsi des bots de service robustes, évolutifs et de haute qualité, capables de modéliser de manière fiable même des processus métier complexes.