Réponse à la question
Historiquement, le support client a évolué d'une monopole d'opérateurs humains vers l'automatisation à travers des chatbots basés sur des règles, qui, cependant, frustrent souvent les utilisateurs en raison de scénarios rigides. La phase moderne se caractérise par l'introduction de Modèles de Langage de Grande Taille (LLM) comme GPT-4 ou Claude, capables de mener des dialogues contextuels et de résoudre des problèmes complexes sans une programmation stricte de la logique. Le problème d'évaluation de l'efficacité de tels systèmes est aggravé par le fait que les métriques traditionnelles (temps de résolution, coût par ticket) corrèlent avec la qualité du service de manière non linéaire : une réduction des coûts peut conduire à une diminution du CSAT, tandis qu'une augmentation de l'automatisation peut entraîner une frustration accrue lors d'escalades infructueuses.
La définition du problème nécessite l'isolement de l'effet pur de l'assistant AI, séparé de la saisonnalité (les soldes de fin d'année modifient le profil des demandes), de l'effet de nouveauté (les utilisateurs expérimentent le bot plus activement dans les premières semaines) et de l'endogénéité de l'auto-sélection (les demandes simples vont au bot, les complexes directement aux humains). La randomisation classique est impossible, car la désactivation du support pour le groupe de contrôle pendant les heures de pointe crée des risques éthiques et commerciaux, et l'escalade du dialogue du bot vers un humain pollue l'effet pur.
La solution optimale est d'utiliser le Regression Discontinuity Design (RDD) à la limite de la longueur de la file d'attente. Lorsque le nombre d'utilisateurs en attente dépasse un seuil N (par exemple, 5 personnes), le système propose automatiquement l'assistant AI comme alternative à l'attente d'un opérateur. Cela crée une expérience naturelle : les utilisateurs à gauche et à droite du seuil sont statistiquement identiques en termes de caractéristiques observables et non observables. Pour prendre en compte l'effet d'apprentissage du modèle, une méthode de Difference-in-Differences est appliquée avec un groupe de remplacement - par exemple, les utilisateurs de nuit, où le bot fonctionne en continu, sont comparés à une fenêtre temporelle similaire avant l'introduction. Pour analyser l'hétérogénéité des effets (différent impact pour différentes catégories de demandes), des Causal Forests sont utilisées, permettant de construire des effets moyens conditionnels de traitement (CATE).
Situation de la vie réelle
Dans un grand projet de e-commerce avec 500K demandes par mois, l'équipe a décidé d'introduire un assistant LLM pour traiter des demandes telles que "où est ma commande" et "changer l'adresse de livraison". Le problème était que le pilote coïncidait avec la saison de Noël, lorsque le trafic a triplé, et que les données historiques montraient une diminution saisonnière du CSAT en raison de retards logistiques, indépendamment de la qualité du support.
La première option considérée était une comparaison directe des métriques un mois avant et un mois après l'introduction. Avantages : simplicité de mise en œuvre, aucune modification de l'infrastructure requise. Inconvénients : absence totale de contrôle saisonnier, impossible de séparer l'effet de l'AI de l'effet d'augmentation du trafic général et de la variation des assortiments (les articles de Noël ont un profil de retours différent). Cette approche a été immédiatement rejetée.
La deuxième option était un test A/B géo-split, où dans certaines régions, le bot était activé, dans d'autres, non. Avantages : randomisation pure, interprétation simple. Inconvénients : effets réseau (un utilisateur peut vivre dans la région A mais passer une commande dans la région B pour un ami), l'infrastructure logistique différente influence la nature des demandes, et pendant les heures de pointe, la surcharge dans une région créerait un risque de perte de clients. Il a été décidé de chercher une alternative.
La solution choisie était le RDD avec un seuil de longueur de file d'attente de 3 personnes. Lorsque la file d'attente dépassait 3 attentes, le système proposait l'assistant AI avec la possibilité de rester en attente pour un humain. Pour corriger l'effet d'escalade, une analyse Intent-to-Treat (ITT) a été utilisée : on comparait tous ceux à qui le bot a été proposé, indépendamment de l'utilisation effective, ce qui évitait le biais d'auto-sélection par littératie technique. De plus, un Synthetic Control a été construit à partir de données historiques de catégories de demandes similaires, où le bot n'était pas utilisé (par exemple, réclamations complexes), afin de filtrer les fluctuations saisonnières.
Le résultat final : il a été mesuré que l'assistant AI réduit le temps moyen de résolution des demandes simples de 8 à 2 minutes sans chute statistiquement significative du CSAT (différence de 0,1 point dans l'intervalle de confiance). Cependant, un effet négatif a été découvert pour le segment "retours" : lors de l'escalade du bot à l'humain, le CSAT était de 15% inférieur à celui d'une demande directe à un opérateur, ce qui a conduit à la création d'un parcours accéléré séparé pour ces demandes. Les coûts opérationnels ont été réduits de 30% grâce au déchargement de la première ligne.
Ce que les candidats oublient souvent
Comment traiter correctement l'endogénéité de l'escalade, lorsque l'utilisateur, déçu par le bot, passe à un humain avec une frustration accrue ?
Les candidats proposent souvent de comparer uniquement les dialogues réussis avec le bot contre les dialogues avec un humain, ignorant le biais de survie. La bonne approche est l'analyse de l'Effet de Traitement Moyen Local (LATE) via des variables instrumentales : utiliser des pannes techniques aléatoires dans le fonctionnement du bot (quand il n'est temporairement pas disponible) comme instrument pour évaluer l'effet spécifiquement pour ceux qui auraient été servis par le bot si cette possibilité avait été présente. Cela permet de séparer l'effet de la technologie elle-même de l'effet de sélection en fonction du type de demande.
Pourquoi les métriques standards de précision du bot (F1-score, BLEU) ne sont-elles pas appropriées pour l'évaluation produit de l'impact causal ?
Souvent, les analystes se concentrent sur la qualité de génération des réponses, oubliant que l'objectif produit est de modifier les métriques commerciales, et non la perfection technique. Un LLM peut générer des réponses correctes mais non pertinentes, ou vice versa - donner des instructions techniquement inexactes mais résolvant le problème de l'utilisateur (par exemple, "essayez de redémarrer l'application"). L'approche correcte est d'évaluer l'uplift au niveau de la session utilisateur en utilisant le Propensity Score Matching pour faire correspondre la complexité des demandes, plutôt que la précision de la génération de texte.
Comment prendre en compte la non-stationnarité de l'effet lors du ré-entraînement continu du modèle sur de nouvelles données ?
Les candidats oublient que le LLM en production est soumis à un apprentissage continu : le modèle est réentraîné sur des dialogues annotés quotidiennement, donc l'effet de la semaine 1 n'est pas comparable avec l'effet de la semaine 4. Il est nécessaire d'utiliser des modèles d'Effets de Traitement Varie au Temps avec une évaluation à fenêtre glissante ou Séries Temporelles Structurelles Bayésiennes (BSTS) pour un ajustement dynamique de la référence. Ignorer cela conduit à une sous-estimation de l'effet à long terme, lorsque le bot "s'apprend" sur la spécificité du produit, ou à une surestimation de l'effet de nouveauté.