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

De nouvelles recherches montrent que les systèmes 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 irritants 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 de choix multiples à un rythme lent – souvent sans certitude quant à laquelle de ces 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 de quelque sorte, et pour sortir de l’« enfer des options ». Beaucoup d’entre nous reconnaîtront cela comme une expérience plus ou moins « combative » et hostile à l’utilisateur.

Il n’est pas surprenant que les centres d’appels soient en première ligne pour l’augmentation ou le 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 pour les titres de technologie, 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’eux. Cela a du sens: toute entreprise intéressée par l’automatisation de ses systèmes de réponse aux clients aura un intérêt limité ou nul à partager les données qui alimentent ses connaissances approfondies, ses méthodes ou son IP d’entreprise.

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

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

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

En outre, la course pour supprimer la frustration de la navigation dans un labyrinthe de centre d’appels a prouvé un stimulus 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 de la réponse aux clients 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 solide, ce qui est douteux.

Appel local

Avec cela en tête, c’est rafraîchissant de voir un nouveau document de la Colombie qui tente de sortir l’IVR de son coffre d’entreprise, au moins un peu. Le nouveau travail, une entrée concise intitulée Au-delà des touches de l’IVR: acheminement des intentions des clients en utilisant les LLM, 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 d’acheminement des intentions des clients (CIR).

Plutôt que 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 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, mettant en vedette une société de télécoms fictive, ainsi que 920 requêtes d’utilisateurs distinctes, 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 correspondre les plaintes des appelants à la destination de centre d’appels correcte avec une précision allant jusqu’à 89,13 %, en particulier lorsqu’il est donné 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 ne comprenait pas, 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 pour le 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 vraiment lorsqu’ils appellent pour demander de l’aide. À ce sujet, 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 répétable, 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é de jeux de données pertinents, le modèle gpt-3.5-turbo a été incité à générer une structure de menu à 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 de 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: l’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é étendu à plusieurs versions réécrites, pour imiter la gamme de façons dont les appelants réels pourraient formuler leurs problèmes, et a introduit des changements dans la longueur, le ton et même des erreurs mineures ou des « mots de remplissage ».

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

La troisième étape a testé avec quelle précision le modèle final pouvait mapper chaque message d’appelant à la bonne destination de menu, sur la base des deux différentes présentations du système IVR (voir image ci-dessus).

Dans la première version, l’IA a reçu une description détaillée de l’arbre de téléphone, avec chaque branche et sous-option décrite dans un formulaire 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 simplifié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 maintenu 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 l’autre.

Métriques

Pour mesurer la performance du système de routage, 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 (tels que 1‑2‑3). Pour isoler l’emplacement des erreurs, des matrices de confusion ont également été générées*, montrant combien de fois 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 a dépendu fortement de la façon dont le menu de téléphone a été présenté: lorsque le menu a été présenté sous forme de liste de chemins de menu aplaties, 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 rappel et types de jeux 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 a été maintenu pour l’ensemble de données plus important et varié, 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 le document, suggèrent que des invites plus simples, basées sur des listes, ont aidé le modèle à correspondre les requêtes plus fiablement que les descriptions hiérarchiques détaillées.

La précision a également diminué 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.

Le document conclut:

‘Nos résultats montrent que les LLM routent les intentions avec plus de précision lorsqu’ils sont donnés des chemins IVR aplaties (jusqu’à 89,13) que des descriptions de menu verbales (aussi bas 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, la transformation des menus en chemins aplaties est un processus simple et automatisable pour une utilisation réelle.’

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 les plus exclusifs de la littérature. Ce qui reste à voir est si des « architectures de mise en contexte » qui contextualisent les LLM seront nécessaires à l’avenir, ou si le modèle n’aura besoin que d’accéder à l’intelligence commerciale (localement disponible), ce qui rendrait superflu le partage de données 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 au document source pour ces.

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