Ces variables générées par l'IA qui faussent vos analyses : le piège caché

Un analyste ajoute des thèmes extraits par un LLM à partir d'enregistrements d'appels dans une table client. Les clients sans transcription reçoivent une valeur NULL. Cette valeur NULL est ensuite remplacée par zéro, par "aucun problème mentionné", ou simplement ignorée comme catégorie de référence. En une seule ligne de prétraitement, le pipeline transforme n'a pas contacté le support en n'a pas ressenti de frustration liée à la facturation.

LES VARIABLES GÉNÉRÉES PAR L'IA NE SONT PAS DES OBSERVATIONS

Cette pratique est de plus en plus courante dans les analyses industrielles. Les thèmes extraits des appels, des chats, des résumés de tickets, des avis clients, des transcriptions de ventes ou des réponses libres de sondages sont traités comme des mesures directes de l'état du client. Pourtant, ces colonnes ne sont pas des observations : ce sont des variables générées par un pipeline, conditionnées par le fait qu'un client ait effectué une action laissant une trace textuelle, puis conditionnées par le fait que cette trace survive au modèle d'extraction.

Chaque étape de ce conditionnement a des conséquences sur ce que la variable signifie dans un modèle causal en aval, et la plupart de ces conséquences restent invisibles dans la table fusionnée. Quatre problèmes majeurs se cachent derrière ces variables : la sélection, le timing, la mesure et le rôle.

1. LA SÉLECTION : QUI GÉNÈRE DU TEXTE ET QUI NE GÉNÈRE PAS

Un thème existe pour un client parce que ce client a appelé, s'est plaint, publié ou répondu. Tout ce qui a poussé cette action est probablement corrélé au traitement, à l'issue, ou aux deux. Remplacer les valeurs NULL par zéro ou par "aucun problème mentionné" suppose que ne pas générer de texte signifie ne pas ressentir le problème sous-jacent. Pourtant, un client qui n'a pas appelé a pu ressentir de la frustration liée à la facturation et l'avoir résolue en annulant son abonnement, en changeant de fournisseur, en se plaignant sur les réseaux sociaux, ou en abandonnant. Le remplissage par zéro transforme toutes ces situations en "pas de frustration".

Restreindre l'analyse aux clients ayant généré du texte est honnête sur la population étudiée, mais cela change l'objet de l'étude. L'effet du traitement sur les clients ayant appelé n'est pas l'effet du traitement sur l'ensemble des clients. Pourtant, la plupart des analyses prétendent estimer ce dernier.

2. LE TIMING : AVANT, PENDANT OU APRÈS LE TRAITEMENT ?

Un texte généré avant le traitement peut jouer le rôle d'un confondant. Par exemple, un client qui a appelé au sujet de la facturation en janvier et a reçu une offre de rétention en mars a produit un appel qui capture quelque chose sur son état de client, influençant à la fois qui a reçu l'offre et qui a résilié. Conditionner sur ce thème peut réduire le biais de variables omises, à condition que le thème reflète réellement le construit pertinent et que les problèmes de sélection soient traités.

Un texte généré pendant le traitement est partie intégrante de l'intervention. Par exemple, si le traitement est un appel d'un agent de rétention et que le thème provient de cet appel, le thème fait partie de l'intervention. Conditionner dessus ne corrige pas le biais de confusion ; cela supprime une partie de l'effet que l'analyste essaie de mesurer.

Un texte généré après le traitement est la catégorie la plus dangereuse, car il est souvent mal classé comme confondant par un analyste travaillant à partir d'une table plate sans index temporel. Un client qui a reçu une offre de rétention en mars et a appelé pour se plaindre en avril a produit une transcription qui reflète, au moins en partie, sa réponse au traitement. Conditionner sur un thème extrait de cet appel revient à conditionner sur une variable post-traitement. Cela peut bloquer les chemins de médiation, induire des associations de collider, ou décaler l'estimand loin de l'effet du traitement que l'analyste pense estimer.

3. LA MESURE : L'ÉTIQUETTE N'EST PAS LA RÉALITÉ

L'étiquette "frustration liée à la facturation" n'est pas la frustration liée à la facturation. C'est ce que le pipeline a détecté comme un langage ayant la forme de la frustration liée à la facturation. La précision du classifieur est finie, et cette précision peut différer entre les groupes de traitement, car un traitement qui change la façon dont les clients parlent change aussi la façon dont le modèle les lit. Le bruit de mesure n'est pas orthogonal à ce qui est étudié.

Un traitement qui modifie la façon dont les clients s'expriment peut réduire le taux auquel le modèle détecte le langage de "frustration liée à la facturation" sans réduire la frustration sous-jacente. Le bruit de l'étiquette n'est plus de moyenne nulle. Il est corrélé au traitement, et conditionner sur l'étiquette bruitée biaise l'effet estimé du traitement dans une direction que l'analyste ne peut pas facilement déterminer.

4. LE RÔLE : UNE VARIABLE PEUT ÊTRE TOUT, SELON LE CONTEXTE

Un thème extrait par un LLM hérite d'une empreinte de sélection du canal par lequel il est passé, d'une empreinte temporelle du moment où le texte a été généré, et d'une empreinte de mesure du pipeline qui l'a extrait. La régression en aval ne voit qu'une colonne de zéros et de uns.

Le rôle d'une variable dans un modèle causal n'est pas déterminé par son nom, mais par sa position dans le graphe causal. Une variable valide dans un rôle peut devenir une source de biais dans un autre. Par exemple, un thème extrait d'un appel post-traitement peut sembler être un confondant, mais il agit en réalité comme un médiateur ou un résultat. Le graphe causal décide, pas le nom de la colonne.

EXEMPLE CONCRET : L'OFFRE DE RÉTENTION QUI FAIT CHURNER

Considérons un scénario synthétique mais réaliste en entreprise. Les clients sont ciblés pour une offre de rétention en fonction d'un modèle qui détecte leur sensibilité aux prix. À la fois l'attribution de l'offre et le churn du client dépendent de cette sensibilité aux prix sous-jacente, que l'analyste n'observe pas. Les clients plus sensibles aux prix sont plus susceptibles de recevoir l'offre (car le modèle de ciblage les sélectionne) et plus susceptibles de résilier, peu importe l'offre. Ils sont aussi plus susceptibles d'appeler le support et d'exprimer un choc lié à la facturation. Le thème "choc lié à la facturation" est généré à partir de ces appels post-traitement.

L'analyste naïf fusionne le thème dans la table client, remplit les valeurs NULL par zéro, et exécute une régression logistique du churn sur l'offre plus le choc lié à la facturation :

import numpy as np
import pandas as pd
import statsmodels.api as sm

rng = np.random.default_rng(7)
n = 20000

price_sens = rng.normal(0, 1, n)
offer = rng.binomial(1, 1 / (1 + np.exp(-(0.8 * price_sens))))
churn = rng.binomial(1, 1 / (1 + np.exp(-(-1.0 + 1.2  price_sens - 0.5  offer))))
called = rng.binomial(1, 1 / (1 + np.exp(-(-1.5 + 0.7  price_sens + 0.9  churn))))

themeprob = 1 / (1 + np.exp(-(-0.5 + 0.8 * pricesens)))
billshock = np.where(called == 1, rng.binomial(1, themeprob), 0)

df = pd.DataFrame({"churn": churn, "offer": offer, "billshock": billshock})

X = sm.addconstant(df[["offer", "billshock"]])
naive = sm.Logit(df["churn"], X).fit(disp=0)
print(naive.params)

L'effet réel de l'offre sur le churn est de −0,50 en log-odds. L'offre est censée réduire le churn, et dans le processus de génération de données, c'est bien le cas. Voici ce que quatre spécifications retournent :

Deux observations découlent de ce tableau. Premièrement, la spécification naïve est incorrecte dans sa direction. Deuxièmement, supprimer la variable de choc lié à la facturation ne corrige pas l'analyse. La spécification sans cette variable est aussi positive, et seule la spécification oracle, qui conditionne directement sur le confondant non observé, retrouve l'effet réel. Dans une analyse réelle, l'analyste n'a pas cette colonne. C'est le point. Supprimer un mauvais contrôle est nécessaire, mais pas suffisant, et un thème post-traitement extrait d'une sous-population de clients ayant appelé n'est pas un substitut pour l'identification.

POURQUOI L'OFFRE DEVIENT POSITIVE DANS LA RÉGRESSION NAÏVE ?

Le mécanisme derrière l'inversion du signe dans la spécification naïve mérite d'être détaillé. Le churn affecte la probabilité d'appeler, car les clients qui partent sont plus susceptibles d'appeler. Le choc lié à la facturation n'est observé que pour les clients ayant appelé, car le thème nécessite une transcription. Conditionner sur le choc lié à la facturation revient donc à conditionner sur une conséquence en aval du churn. Parmi les clients avec un choc lié à la facturation égal à un, la relation entre l'offre et la sensibilité aux prix a été déformée, car les deux variables aident maintenant à expliquer pourquoi le client a été signalé. Le coefficient sur l'offre absorbe cette association induite.

Ce point méthodologique se généralise. Une variable dérivée d'une transcription a une position dans le graphe causal déterminée par le moment où le texte a été généré par rapport au traitement, par qui l'a généré et par le processus qui a produit l'étiquette. Rôle et timing sont la même question vue sous différents angles. Ces variables viennent avec une empreinte structurelle que l'analyste est responsable de tracer, et la table fusionnée n'est pas l'endroit où ce traçage a lieu.

LA POPULATION RÉELLE EST REDEFINIE AVANT MÊME LA RÉGRESSION

La plupart des analyses industrielles utilisant des transcriptions de support redéfinissent implicitement la population de "clients" à "clients ayant généré du langage de support". L'estimand change avant même que la régression ne commence. C'est la partie qui compte le plus dans les workflows des praticiens, et c'est là que le workflow standard est le plus fragile.

Le texte existe parce que le client a fait quelque chose : appelé, posté, se plaint, répondu. Cette action est un comportement, pas une mesure. Elle est influencée par les caractéristiques du client, par le canal disponible, par l'urgence du problème sous-jacent, et souvent par le traitement lui-même. Aucun de ces facteurs n'est aléatoire. Aucun n'est typiquement orthogonal au résultat.

COMMENT LES ANALYSTES TRAITENT-ILS LES VALEURS NULL ?

Il existe trois approches courantes pour gérer les valeurs NULL, et chacune repose sur une hypothèse forte.

Remplir les NULL par zéro ou par "aucun problème mentionné" suppose que ne pas générer de texte est informatif sur l'absence du construit sous-jacent. Pour la plupart des thèmes dignes d'intérêt, cette hypothèse est peu plausible. Les clients qui n'ont pas appelé peuvent avoir ressenti de la frustration liée à la facturation et l'avoir résolue en annulant, en changeant de fournisseur, en se plaignant sur les réseaux sociaux, ou en abandonnant. Le remplissage par zéro transforme toutes ces situations en "pas de frustration".

Supprimer les lignes avec des thèmes NULL, en restreignant l'analyse à la sous-population ayant appelé, est au moins honnête sur la population étudiée, mais cela change l'estimand. L'effet du traitement parmi les clients ayant appelé n'est pas l'effet du traitement parmi tous les clients, et la différence entre les deux est souvent le cœur de la question métier. Une offre de rétention qui affecte les clients enclins à résilier et ayant appelé est une quantité utile. Ce n'est pas la quantité que la plupart des analyses prétendent estimer.

Traiter la présence de texte comme un mécanisme de données manquantes et appliquer un IPW (Inverse Probability Weighting) basé sur un modèle de qui appelle est, méthodologiquement, la bonne approche. Le piège réside dans le modèle de propension lui-même. Modéliser qui génère du texte nécessite de formaliser ce qui pousse à appeler, et ce modèle dépend des données démographiques, de la durée de relation, des problèmes antérieurs, de l'exposition au traitement et de la frustration non mesurée, qui est le construit que le thème était censé aider à mesurer en premier lieu. L'IPW est principié, mais il est aussi rarement aussi principié qu'il en a l'air.

Le point plus profond est que la sélection dans le texte est un comportement qui interagit avec le traitement. Une offre de rétention peut changer les taux d'appels. Une modification des prix peut changer les taux de plaintes. Un lancement de fonctionnalité peut changer les types de problèmes que les clients articulent. Chacun de ces éléments rend le mécanisme de sélection lui-même dépendant du traitement, ce qui signifie que même un thème parfaitement extrait et parfaitement chronométré est mesuré sur une population dont la composition se déplace avec le traitement. Les corrections observationnelles standard supposent que le mécanisme de sélection est stable. Quand le traitement déplace la sélection, les corrections ne fonctionnent plus.

LES VARIABLES GÉNÉRÉES PAR L'IA NE SONT PAS INUTILES, MAIS ELLES DOIVENT ÊTRE UTILISÉES CORRECTEMENT

Cela ne signifie pas que les variables dérivées de transcriptions sont inutiles. Cela signifie que l'analyste doit à son lecteur une déclaration explicite de la population sur laquelle l'effet est estimé, du mécanisme qui a produit le texte, et de l'hypothèse faite sur tous ceux dont le texte n'existe pas.

Les anciennes sorties de NLP semblaient bruitées. Les poids TF-IDF, les comptages de mots-clés clairsemés, les vecteurs de sujets LDA : aucun d'eux ne ressemblait à ce qu'un client ressentait. Les praticiens les méprisaient par réflexe, et ce réflexe a sauvé beaucoup d'analyses médiocres.

Les sorties de LLM ne semblent pas bruitées. Elles ressemblent à des construits latents. Une étiquette comme "frustration liée à la facturation" ou "érosion de la confiance" ou "anxiété de renouvellement" semble décrire l'état mental d'un client. L'étiquette est articulée, les catégories sont sémantiquement cohérentes, et les modes de défaillance ne s'annoncent pas dans la colonne. Le problème de persuasion est réel avant même que le problème statistique ne commence.

COMMENT CORRIGER LES ERREURS DE MESURE INDUITES PAR LES CLASSIFIEURS ?

Il existe une littérature sur la correction des erreurs de mesure induites par les classifieurs. Egami et ses collègues développent un workflow d'échantillonnage par division pour l'inférence causale avec des mesures découvertes par le texte comme traitements ou résultats dans "Comment faire des inférences causales en utilisant des textes". Mozer et ses collègues appliquent l'appariement augmenté par le texte aux dossiers médicaux électroniques et montrent comment les covariables basées sur le texte changent les effets estimés dans une étude médicale réelle dans "Exploiter les données textuelles pour l'inférence causale en utilisant les dossiers médicaux électroniques". Pour le paysage plus large, Keith, Jensen et O'Connor passent en revue comment le texte a été utilisé pour supprimer la confusion dans diverses applications dans "Texte et inférence causale : un aperçu de l'utilisation du texte pour supprimer la confusion des estimations causales". Ces méthodes existent et valent la peine d'être utilisées quand l'analyse compte. Elles nécessitent aussi que l'analyste reconnaisse qu'une étiquette est une mesure avec une erreur, ce qui est le geste que la plupart des workflows sautent.

CINQ QUESTIONS À SE POSER AVANT D'UTILISER UNE VARIABLE GÉNÉRÉE PAR L'IA

Une analyse causale qui utilise une variable générée dérivée de transcriptions peut encore être défendable. Elle doit simplement répondre à cinq questions avant que la régression ne soit exécutée :

1. Quel rôle j'assume pour cette variable ?

   Confondant, médiateur, traitement, résultat ou caractéristique descriptive. Le graphe causal décide. Le nom de la colonne ne décide pas.

2. Quand le texte a-t-il été généré par rapport au traitement ?

   Pré-traitement, simultané ou post-traitement. Si l'analyste ne peut pas répondre à cette question à partir des données, la variable n'entre pas dans le modèle comme confondant.

3. Quel mécanisme de sélection a produit le texte, et que j'assume sur tous ceux dont le texte n'existe pas ?

   Remplissage par zéro, suppression, IPW : chacun est une hypothèse. Choisissez-en une et énoncez-la clairement.

4. Comment l'étiquette a-t-elle été produite, et sa fiabilité pourrait-elle différer entre les groupes de traitement ?

   Si le traitement change plausiblement la façon dont les clients expriment le construit sous-jacent, la précision du classifieur n'est pas constante entre les groupes de comparaison que l'analyse effectue.

5. À quoi ressemble le résultat sous un test de résistance ?

   Reformulez le modèle sans la variable dérivée du texte. Si le coefficient principal est fragile, le résultat n'est pas assez stable pour porter une affirmation causale par lui-même.

Ces cinq questions ne sont pas une solution. Ce sont un diagnostic. Un analyste qui peut y répondre n'est pas garanti d'obtenir un effet identifié. Un analyste qui ne peut pas y répondre fait du travail descriptif avec un langage causal attaché.

LE PIÈGE DES VARIABLES GÉNÉRÉES PAR L'IA N'EST PAS NOUVEAU, MAIS LES LLMS L'ONT RENDU PLUS DANGEREUX

Ce schéma est plus ancien que les LLM. Les variables générées sont des sorties de pipeline qui ressemblent à des observations mais sont en réalité des sorties de modèles conditionnées par la sélection. Elles apparaissent dans les scores de fraude, les métriques de pertinence des recommandations, les indices de sentiment, les scores de propension réutilisés comme covariables, et toute estimation de trait latent produite par un modèle en amont et consommée par une analyse en aval. Les LLM n'ont pas inventé cette erreur. Ils l'ont rendue accessible à une échelle et une fluidité que les anciennes sorties de NLP n'ont jamais atteintes. Les étiquettes ressemblent à des construits latents, les colonnes ressemblent à des mesures, et le workflow ressemble à de l'inférence causale.

Les anciens systèmes NLP semblaient bruyants et peu fiables. Les praticiens les méprisaient par réflexe, et ce réflexe a sauvé beaucoup d'analyses médiocres. Les sorties de LLM, en revanche, semblent articulées et fiables. Elles ressemblent à des mesures directes de l'état d'un client. Pourtant, elles restent des sorties de modèles conditionnées par la sélection, le timing et la mesure. Le problème de persuasion est réel avant même que le problème statistique ne commence.

En résumé : les variables générées par l'IA ne sont pas des observations. Elles sont des sorties de pipeline qui héritent de processus de génération de données que l'analyse en aval n'a jamais modélisés. Traiter ces variables comme des mesures directes mène à des conclusions erronées, parfois radicalement inverses. La solution n'est pas d'éviter ces variables, mais de les utiliser en explicitant leurs hypothèses et leurs limites.