T-Tech automatise 45 % des sessions du support client avec un modèle Qwen affiné

Le problème

Le support client à grande échelle repose sur des logiciels de workflow d'entreprise, où les opérateurs naviguent d'écran en écran pour résoudre chaque dossier. L'automatiser avec des scripts écrits à la main est lent à mettre en place et casse dès que les écrans ou les processus changent. Les agents d'IA généralistes effectuent de nombreux appels au modèle par dossier, si bien que les petites erreurs s'additionnent et que le coût est élevé.

Ce qu'ils ont construit

T-Tech a construit un agent d'IA qui fonctionne au sein de sa plateforme de gestion des processus métier (BPM), le logiciel que les opérateurs utilisent pour traiter les chats de support. L'agent lit une vue structurée de l'écran et propose l'action suivante, comme cliquer sur un contrôle, transférer un chat ou envoyer un message. Un second modèle, appelé critique, évalue le niveau de confiance de l'agent. Seules les étapes à forte confiance s'exécutent seules. Pour tout ce qui est incertain, l'agent rend le dossier à un opérateur et reprend à partir de l'écran mis à jour.

Le modèle est le Qwen2.5-Instruct-7B d'Alibaba, à poids ouverts, affiné sur les propres données de T-Tech. Les auteurs ont choisi la taille 7B parce qu'elle offrait le meilleur équilibre entre vitesse et débit pour leur budget de serving.

Comment ils s'y sont pris

Le déploiement comporte trois étapes. D'abord, la plateforme se contente d'enregistrer ce que font les opérateurs. Ensuite, le modèle fonctionne comme copilote : les opérateurs acceptent sa suggestion ou la corrigent, et ce retour entraîne le modèle de confiance. Enfin, le système exécute en arrière-plan les étapes à forte confiance. Les auteurs indiquent qu'un nouveau processus atteint l'automatisation sélective en environ deux semaines, sans règles écrites à la main.

Le trafic de support est réparti par types de demande, chacun avec ses propres modèles, afin qu'une dérive dans un domaine puisse être isolée. Si les signaux de qualité se dégradent pour un segment, l'automatisation s'y désactive et le système revient en mode copilote pour recueillir de nouveaux retours. Les données d'entraînement sont anonymisées avant usage.

Résultats

Les auteurs indiquent que le système a automatisé entièrement 45 % des sessions en production. Dans un test A/B avec 15,5 k clients par groupe sur 7 jours, le temps actif moyen de l'opérateur par client est passé de 227,37 secondes à 139,15 secondes (-39 %) par rapport à un traitement exclusivement humain. Face au chatbot existant à étapes scriptées (77 k clients par groupe, 32 jours), il est passé de 124,67 à 104,72 secondes (-16 %). Une revue aveugle par des opérateurs n'a relevé aucune différence statistiquement significative de qualité de résolution dans les deux tests.

Les opérateurs ont accepté les actions de routine, comme le transfert d'un chat, dans 91,7 % des cas, mais les réponses en texte libre seulement dans 50,81 % des cas. Les auteurs désignent la messagerie en langage naturel comme la principale limite à une automatisation plus poussée.

Ce qui a mal tourné

Les opérateurs ont rejeté une partie des suggestions. Les auteurs ont analysé ces rejets et constaté que 37,2 % correspondaient à des actions acceptables que l'opérateur avait simplement choisi d'effectuer autrement, par exemple en adoucissant la formulation d'un message. Les cas hors des données d'entraînement, comme de nouveaux éléments d'écran ou des demandes inhabituelles, sont un point faible connu, ce qui explique pourquoi le système s'en remet aux personnes quand il hésite.

Ce qu'il faut retenir

Faites d'abord fonctionner le système comme copilote et utilisez les clics d'acceptation et de correction des opérateurs comme données d'entraînement. Automatisez les étapes répétitives à faible risque avant tout ce qui s'adresse au client. Suivez le temps d'opérateur par client dans un test contrôlé, et ajoutez un interrupteur qui renvoie un type de dossier au traitement humain lorsque la qualité baisse.