L’IA pourrait vous aider à rejoindre une personne réelle plus rapidement

De nouvelles recherches montrent que les configurations d’IA de type ChatGPT open source peuvent potentiellement acheminer les appelants vers la bonne personne dans un centre d’appels en utilisant le langage naturel, sans suivre les choix de menu frustrants qui diffèrent chaque semaine, semblant délibérément obstructifs.

Essayer de joindre une personne réelle dans un centre d’appels peut être une expérience frustrante, en raison de la nécessité de naviguer dans des options à choix multiple à un rythme lent – souvent sans certitude quant à laquelle des options convient à votre cas. Si aucune d’entre elles ne convient, les utilisateurs expérimentés ont tendance à adopter des astuces et des contournements pour accéder à un conseiller humain et sortir de l’« enfer des options ». Beaucoup d’entre nous reconnaîtrons cela comme une expérience plus ou moins « combative » et hostile aux utilisateurs.

Il n’est pas surprenant que les centres d’appels soient en première ligne pour une augmentation ou un remplacement par des systèmes d’IA ; et, malgré une approche circonspecte recommandée par certaines parties, l’automatisation des centres d’appels par l’IA reste un fruit facile à cueillir pour les titres de l’actualité technologique, et pour la perspective de l’innovation basée sur l’IA qui peut offrir un ROI inhabituellement précoce.

Boutique fermée

Mais il y a des domaines où les principes open source et les données librement disponibles sont rarement appliqués ou disponibles, et c’est l’un d’entre eux. Cela a du sens : toute entreprise intéressée par l’automatisation de ses systèmes de réponse client aura un intérêt limité ou nul à partager les données qui alimentent leurs connaissances difficiles à acquérir, leurs méthodologies ou leur propriété intellectuelle.

Pour une chose, partager ces ressources leur coûterait un avantage sur la concurrence ; plus important encore, étant donné à quel point les systèmes à boucle d’IA sont enclins à divulguer des informations privilégiées, c’est juridiquement risqué.

Cela a conduit à un certain nombre de joueurs bien investis qui développent des systèmes de réponse de centre d’appels aidés par l’IA de manière indépendante les uns des autres (présumément avec une certaine redondance d’efforts inévitable) ; et à une prolifération de startups et de joueurs établis B2B catering à la demande croissante de capacités de réponse client basées sur l’IA.

Un assistant vocal PolyAI ouvre un appel de service client pour la société fictive ‘Augusta Lawn Care’, en tirant parti de grandes quantités de conversations de formation pour automatiser les réponses via l’infrastructure de centre d’appels existante. Source

De plus, la course pour supprimer la frustration de la navigation dans un labyrinthe de centre d’appels a prouvé être un stimulant pour les efforts de recherche – bien que la plupart de ces publications tendent à se produire à l’écart des réseaux de publication de recherche ouverts tels qu’Arxiv, conformément à la nature généralement clandestine du développement de la réponse vocale interactive (IVR).

Au lieu de cela, la recherche, les données et l’intelligence commerciale liées à l’automatisation des systèmes de réponse client par l’IA sont toutes jalousement gardées, avec très peu d’options open source disponibles – même si l’utilisation de systèmes et de données FOSS offrait une option juridiquement saine, ce qui est douteux.

Appel local

C’est donc rafraîchissant de voir un nouveau document de Colombie qui tente de sortir l’IVR de son coffre d’entreprise, ne serait-ce qu’un peu. Le nouveau travail, une entrée concise intitulée Beyond IVR Touch-Tones : Customer Intent Routing using LLMs, provient d’un chercheur de l’Universidad Distrital Francisco José de Caldas à Bogotá, et prétend être le premier projet non fermé à utiliser des modèles de langage grand (LLM) pour générer un schéma de travail pour un système de routage d’intention client (CIR).

Au lieu d’essayer d’accéder à des données d’appel réelles ou à des arbres de menu propriétaires, le nouveau projet génère tous les composants à partir de zéro en utilisant trois modèles d’IA : un pour inventer un menu de centre d’appels réaliste ; un autre pour simuler des centaines de plaintes d’appelants ; et un troisième pour agir comme un chatbot, en essayant d’acheminer ces plaintes vers la bonne destination.

Le résultat est un lit de test entièrement synthétique mais convaincant, présentant une société de télécoms fictive, ainsi que 920 requêtes distinctes de l’utilisateur, permettant à l’expérience de contourner les risques juridiques tout en explorant à quel point l’IA actuelle peut interpréter un discours vague et désordonné, et toujours connecter l’appelant à la bonne personne.

Les tests indiquent que le système du schéma peut faire correspondre les plaintes des appelants à la destination de centre d’appels correcte avec une précision allant jusqu’à 89,13 %, en particulier lorsqu’on lui donne des options de menu « aplaties » au lieu de descriptions verbales (plus sur cela plus tard).

L’étude a également constaté que lorsque les appelants utilisaient un langage plus décontracté ou varié, l’IA se trompait davantage ; mais que certaines de ces erreurs se produisaient non pas parce que l’IA avait mal compris, mais parce que le menu téléphonique lui-même était confus.

Exemples d’interactions client, partagés dans le cadre du nouveau projet. Source

Les données du projet ont été rendues publiques.

Méthode

Le premier modèle de l’approche tripartite crée un menu de téléphone détaillé pour une société de télécoms fictive ; le deuxième génère des messages d’appelants uniques – certains simples, d’autres réphrasés ou rendus plus décontractés – pour simuler la façon dont les gens parlent réellement lorsqu’ils appellent pour obtenir de l’aide. À cet égard, 920 exemples ont été générés pour le projet.

Le troisième modèle a reçu la tâche de connecter chaque appelant à la bonne destination, sur la base uniquement du message et d’une version du menu. Ce schéma a permis à l’expérience d’être entièrement reproductible, tout en contournant le besoin de données d’appel réelles ou d’exposer des informations client :

Les trois systèmes choisis pour l’approche tripartite. Source

Les trois modèles utilisés, respectivement, étaient gpt-3.5-turbo ; gpt-4o-mini ; et gpt-4.1-mini.

Pour simuler un environnement de service client convaincant, il a été nécessaire de synthétiser un menu de téléphone complexe à partir de zéro. En raison de la rareté des ensembles de données pertinentes, le modèle gpt-3.5-turbo a été invité à générer une structure de menu complète et à plusieurs branches pour un fournisseur de télécoms fictif.

Chaque branche a été configurée pour représenter des domaines de service tels que la facturation, le support technique la gestion de compte, et les nouveaux services, avec des sous-options réalistes et une profondeur variable dans l’arbre. À partir de ce menu artificiel, deux versions ont été créées pour les tests ultérieurs : une sous forme de hiérarchie de texte brut, pour imiter la façon dont un humain pourrait lire l’ensemble du menu ; et une autre sous forme de liste de points de terminaison, chacun avec sa propre séquence de presses de bouton.

Cela a permis au système d’être testé à la fois sur une version détaillée et sur une version « épurée » du défi de routage :

Deux versions du menu de téléphone ont été fournies à l’IA : une hiérarchie de texte détaillée et une liste simplifiée d’options de menu directes, pour comparer à quel point chaque format soutenait la routage des appelants vers le bon endroit.

Pour créer les messages d’appelants nécessaires aux tests, un deuxième modèle de langage a été utilisé pour produire un ensemble de plaintes ou de demandes originales, avec dix exemples uniques créés pour chaque point de terminaison du menu.

Chacun de ces exemples a ensuite été élargi en plusieurs versions réphrasées, pour imiter la gamme de façons dont les appelants réels pourraient formuler leurs problèmes, et introduire des changements de longueur, de ton et même de petites erreurs ou ‘mots de remplissage’.

Les 920 messages d’appelants générés au départ ont été conçus à la fois pour tester la précision du système et pour simuler l’imprévisibilité du discours réel.

La troisième étape a testé à quel point le modèle final pouvait mapper chaque message d’appelant à la bonne destination de menu, sur la base des deux façons différentes de présenter le système IVR (voir image ci-dessus).

Dans la première version, l’IA a reçu une description détaillée et complète de l’arbre de téléphone, avec chaque branche et sous-option décrite sous forme de texte. Dans la deuxième, elle n’a vu qu’une liste de destinations finales, chacune liée à une séquence de boutons.

L’objectif était de voir si une version épurée du menu rendrait-il plus facile pour le modèle de décider où chaque appel devrait aller. Dans les deux cas, le système a reçu un message à la fois et a été invité à retourner seulement le chemin, sans mots ou explications supplémentaires, pour faciliter la notation automatique.

Isolation

Pour éviter de contaminer les résultats des tests, l’expérience a gardé chaque modèle isolé des autres : le menu de téléphone a été rédigé par le premier modèle, mais ensuite finalisé manuellement, de sorte qu’il est resté inconnu des autres systèmes.

Les messages d’appelants ont ensuite été générés séparément par gpt-4o-mini, en utilisant uniquement les noms des points de terminaison, et sans accès à la structure du menu. Enfin, gpt-4.1-mini, qui a géré le routage, n’a vu que le texte du menu et les messages entrants, et n’a pas participé à la création de l’un ou de l’autre.

Métriques

Pour mesurer à quel point le système de routage a performé, deux métriques standard ont été utilisées : la précision a été définie comme le pourcentage de cas où le modèle a retourné le chemin exactement correct (comme 1‑2‑3). Pour isoler l’emplacement des erreurs, des matrices de confusion ont également été générées*, montrant à quel point chaque chemin a été confondu avec d’autres. Les évaluations ont été exécutées en Python en utilisant les bibliothèques pandas et scikit-learn.

Résultats

Dans les tests, la précision du modèle dépendait fortement de la façon dont le menu de téléphone était présenté : lorsque l’on lui donnait la liste aplatie des chemins de menu, le système a atteint 89,13 % de précision sur l’ensemble de données plus simple, par rapport à 81,30 % lorsqu’il utilisait la version descriptive complète du menu :

Précision de routage pour le troisième modèle (LLM3), sur différents formats de prompt et types de données, indiquant que les chemins de menu aplaties ont constamment surpassé les descriptions hiérarchiques, et que la précision a légèrement diminué lorsque les entrées étaient augmentées avec un langage paraphrasé ou informel.

Ce modèle s’est maintenu pour l’ensemble de données plus important et varié en termes de langage, où la version aplatie a à nouveau performé mieux, avec un score de 86,52 % contre 77,07 % pour le format descriptif.

Ces résultats, note l’article, suggèrent que des invites plus simples et sous forme de liste ont aidé le modèle à faire correspondre les requêtes de manière plus fiable que les descriptions hiérarchiques longues.

La précision a également baissé légèrement lorsque des versions paraphrasées et informelles des messages d’appelants ont été introduites, indiquant que une plus grande variété améliore la réalisme, mais rend également la classification plus difficile.

L’article conclut :

‘Nos résultats montrent que les LLM routent les intentions avec plus de précision lorsqu’ils reçoivent des chemins IVR aplaties (jusqu’à 89,13) que des descriptions de menu verbales (aussi basses que 77,07%), suggérant que des invites concises et structurées réduisent le bruit et s’alignent mieux sur la tâche de routage.

‘Cela soutient le principe que la clarté et la brièveté améliorent les performances des LLM dans les paramètres de classification.

‘Importamment, transformer les menus en chemins aplaties est un processus simple et automatisable pour une utilisation dans le monde réel.’

Conclusion

Il est rafraîchissant de voir au moins quelques travaux ouverts se produire dans l’un des domaines de recherche les plus cloisonnés et exclusifs de la littérature. Ce qui reste à voir est si des architectures de « mise en cadre » qui contextualisent les LLM seront nécessaires à l’avenir, ou si le modèle n’aura besoin d’accéder qu’à l’intelligence commerciale (disponible localement), ce qui rendrait inutile le partage de données par l’entreprise avec des fournisseurs tiers.

En fin de compte, les principes de conception plus larges à l’œuvre ici semblent susceptibles d’être adoptés naturellement par les futurs systèmes d’IA, même dans des domaines au-delà du service client, sans nécessiter un alignement délibéré sur cet usage.

* Veuillez vous référer à l’article source pour ceux-ci.

Publié pour la première fois mercredi 29 octobre 2025