Résumé
Chez VoiceBooker, nous constatons chaque jour que les grands modèles de langage ne se comportent pas comme un logiciel classique déterministe. Leurs sorties reposent sur des probabilités, ce qui signifie qu'à entrée identique, le comportement peut varier. Cela apparaît très vite dans le function calling. Les modèles modernes sont beaucoup plus fiables que les générations précédentes, mais des prompts précis, un débogage rigoureux et la compréhension des interactions de contexte restent essentiels pour obtenir des résultats prévisibles. Pour garantir la stabilité et la fiabilité des applications IA, les End-to-End-Tests automatisés aident à vérifier systématiquement le comportement du bot et à détecter les régressions tôt.
Introduction
Quand on vient du développement logiciel classique, travailler avec de grands modèles de langage (LLM) provoque souvent un petit choc culturel. Pendant des décennies, nous avons eu l'habitude de construire des systèmes déterministes: si un programme produit une erreur pour une entrée donnée, nous corrigeons le code - et une fois la correction validée, nous pouvons supposer qu'elle fonctionnera à nouveau pour la même entrée. Même entrée, même sortie. C'est le monde dans lequel vivent les développeurs logiciels depuis des décennies. Avec les LLM, la réalité est différente.
Des programmes déterministes aux machines à probabilités
Un grand modèle de langage ne fonctionne pas comme un programme classique avec des arbres de décision fixes. Il s'appuie plutôt sur des probabilités. Chaque réponse, chaque décision et chaque appel de fonction résulte d'un scoring statistique des étapes suivantes possibles. Cela entraîne un phénomène qui frustre beaucoup de développeurs au début: Un même déroulement de conversation peut produire des résultats différents lors de deux exécutions. On peut comparer cela à la roulette: le cadre est identique, mais le résultat peut quand même varier. Les développeurs qui viennent du monde des API, des bases de données et de la logique métier trouvent souvent cette absence de déterminisme inhabituelle, voire problématique au début.
Nos premières expériences avec le function calling
Lorsque nous avons essayé pour la première fois, en 2023, de gérer une réservation de rendez-vous via un LLM, nous avons parfois failli désespérer. Le déroulement de la conversation était identique:
- L'utilisateur exprime son souhait de rendez-vous
- Le bot collecte les informations nécessaires
- La fonction de réservation doit être appelée
Et pourtant, voici ce qui s'est passé: Lors du premier test, la fonction a été appelée correctement. Lors du deuxième test, avec un déroulement pratiquement identique, elle n'a soudainement pas été exécutée. Pour quelqu'un qui a développé des logiciels classiques, cela ressemble d'abord à un bug. En réalité, il ne s'agit souvent pas d'une erreur du système, mais d'une conséquence naturelle d'un modèle probabiliste qui interprète le contexte et prend des décisions selon des probabilités.
La bonne nouvelle: les modèles deviennent de plus en plus fiables
Depuis l'époque des premiers GPT-3.5, énormément de choses ont changé. Les modèles modernes sont beaucoup meilleurs pour:
- suivre les instructions
- utiliser des outils
- faire du function calling
- comprendre le contexte
- respecter des prompts complexes
La prévisibilité s'est ainsi énormément améliorée. Il reste toutefois un équilibre important entre fiabilité et latence.
Pourquoi plus de déterminisme signifie souvent plus de latence
Beaucoup des modèles les plus performants d'aujourd'hui fonctionnent de manière plus structurée et plus fiable que leurs prédécesseurs. Le prix à payer est souvent un surcroît de raisonnement. En simplifiant: Le modèle réfléchit plus longtemps, analyse davantage de contexte et prend ainsi des décisions plus robustes. Cela augmente la probabilité qu'une fonction souhaitée soit appelée correctement. En même temps, le temps de réponse augmente.
Dans le domaine vocal en particulier, cela peut devenir problématique. Un assistant téléphonique qui doit réfléchir plusieurs secondes à chaque appel de fonction paraît vite artificiel pour l'appelant. C'est pourquoi beaucoup de systèmes en production choisissent volontairement des modèles plus petits et plus rapides. Ces modèles offrent une excellente latence et appellent aussi les fonctions de manière étonnamment fiable - mais seulement si les prompts laissent le moins possible de place à l'interprétation. De petits changements de contexte peuvent suffire à faire interpréter différemment un flux qui fonctionnait parfaitement auparavant.
Quand les function calls cessent soudainement
Un schéma typique en pratique: Un bot fonctionne de manière fiable pendant des semaines. Puis une modification de prompt en apparence anodine est introduite. Soudain, une certaine fonction n'est appelée qu'occasionnellement - ou plus du tout. Dans ce genre de situation, il vaut mieux ne pas accuser le modèle trop vite. Souvent, la cause est une interaction inattendue entre plusieurs instructions. Une nouvelle règle peut entrer en conflit, sans le vouloir, avec une instruction existante. Le modèle se retrouve alors face à des objectifs contradictoires et prend logiquement la décision de ne pas appeler la fonction.
Débogage des prompts plutôt que débogage du code
Alors que les développeurs logiciels classiques déboguent du code, les développeurs LLM déboguent de plus en plus des prompts. Une approche qui a bien fonctionné chez nous: Nous téléchargeons le transcript complet au format JSON - y compris les system prompts, les définitions d'outils et les entrées utilisateur - puis nous laissons un autre LLM analyser pourquoi un certain comportement s'est produit. Les résultats sont souvent surprenants. Très souvent, le modèle identifie des contradictions ou des ambiguïtés que nous avions nous-mêmes manquées en rédigeant le prompt. Il nous arrive même souvent d'être d'accord avec le modèle: À y regarder de plus près, l'instruction n'était réellement pas assez précise ou entrait en conflit avec une autre instruction. Fait intéressant, les humains réagissent souvent de manière similaire dans ce genre de situations. Si deux instructions sont formulées de façon contradictoire, des marges d'interprétation apparaissent forcément.
Des unit tests aux bot tests
Une autre leçon importante tirée de la pratique: Les tests manuels ne passent pas à l'échelle. Quiconque vérifie chaque modification du bot par des conversations ou des appels de test manuels perd rapidement énormément de temps. C'est pourquoi nous avons introduit dans VoiceBooker des End-to-End-Tests. Un bot peut appeler un autre bot ou discuter avec lui. Par exemple, un bot de test peut recevoir la tâche suivante:
Réserve une table pour quatre personnes mardi à 18 h.
Comme le bot de test est lui-même programmable, des paramètres comme la date, l'heure ou le nombre de personnes peuvent être variés automatiquement. On obtient ainsi, en quelque sorte, des tests unitaires pour l'IA conversationnelle. Les avantages sont évidents:
- scénarios de test répétables
- tests de régression automatisés
- validation rapide des changements de prompt
- détection précoce des changements de comportement inattendus
En mode chat en particulier, des centaines de cas de test peuvent être exécutés en peu de temps, car le débit dépend surtout de la latence des modèles utilisés.
Conclusion
Le plus grand changement mental lorsqu'on travaille avec des LLM consiste probablement à abandonner l'idée d'un déterminisme absolu. Les LLM ne sont pas des programmes classiques. Ce sont des machines à probabilités. Cela ne signifie pas qu'il soit impossible de construire des systèmes fiables. Avec des prompts précis, des définitions d'outils propres, un débogage systématique des prompts et des End-to-End-Tests automatisés, il est aujourd'hui possible de créer des applications IA remarquablement robustes et prévisibles. La différence essentielle avec le développement logiciel classique est qu'on n'optimise plus seulement du code - on façonne de plus en plus le comportement d'un système intelligent. Et c'est à la fois le plus grand défi et la plus grande fascination du développement IA moderne.