Comparer deux prompts ou deux modèles génératifs n'a rien à voir avec un A/B test de bouton. La non-déterminisme des LLM fausse les calculs classiques et produit des faux positifs en série si la méthode n'est pas adaptée.
Un A/B test web repose sur un postulat simple : le traitement appliqué à un utilisateur est stable. Si la variante B est la couleur d'un bouton, chaque utilisateur assigné à B voit exactement le même bouton. Toute la mécanique statistique qui en découle — calcul de puissance, taille d'échantillon minimale, erreurs de première et seconde espèce — est construite sur la prémisse que le traitement est constant pour tous les utilisateurs qui y sont assignés.
Un modèle génératif casse ce postulat. Le même prompt, envoyé au même modèle, produit des sorties différentes à chaque appel d'inférence dès que l'échantillonnage n'est pas déterministe. Le problème persiste même quand on pense avoir figé le hasard : des travaux menés à Penn State et chez Comcast AI Technologies ont montré que le batching continu, le chunk prefilling ou le prefix caching introduisent une non-déterminisme qu'un réglage « déterministe » ne supprime pas. Autrement dit, même en fixant la graine aléatoire et la température à zéro, deux appels identiques peuvent renvoyer des réponses différentes pour des raisons purement liées à l'infrastructure d'inférence.
Conséquence directe : parce que la sortie d'un LLM est non déterministe même à température zéro, les calculs de taille d'échantillon standard d'un A/B test produit sous-estiment ce dont ces tests ont réellement besoin. Un cabinet ou une équipe data qui applique un calculateur de taille d'échantillon classique à un test de prompt ou de modèle obtient donc un chiffre trop optimiste — et conclut à tort qu'une différence est significative.
La difficulté ne vient pas d'une seule source de bruit mais de deux, qui s'additionnent. Un ingénieur spécialisé dans l'évaluation des LLM les décrit ainsi : la variance entre questions (certaines questions sont plus difficiles que d'autres, et un échantillon de 100 exemples peut par hasard pencher vers le facile ou le difficile) et la variance intra-question (la même question, posée plusieurs fois, obtient des réponses différentes du même modèle).
Ignorer la seconde composante est l'erreur la plus fréquente. Une étude sur la variabilité des LLM dans les tâches créatives rappelle que les pratiques d'évaluation courantes qui reposent sur une seule génération traitent les sorties d'un LLM comme des estimations ponctuelles déterministes, ce qui s'avère statistiquement non fiable, en particulier pour les tâches ouvertes. Le même travail observe que ce risque n'est pas uniforme selon les modèles : pour les modèles les plus stables, un petit échantillon peut suffire pour un classement grossier, tandis que pour les modèles à forte variance, un échantillon unique présente un risque élevé d'inversion de classement, pouvant faire passer un modèle de premier plan pour un modèle moyen, ou l'inverse.
Un autre biais, moins visible, touche le plan d'expérience lui-même : des chercheurs en psychologie appliquée aux LLM notent que les réponses issues d'un même modèle ne sont pas des observations indépendantes, et les traiter comme telles gonfle le risque de faux positifs. Multiplier les appels à un même modèle sur un même prompt ne produit pas un échantillon de taille N indépendant — c'est un échantillon corrélé, et les tests statistiques classiques (t-test, chi², z-test de proportions) surestiment la confiance qu'on peut en tirer si cette corrélation n'est pas prise en compte.
Les ordres de grandeur concrets permettent de calibrer les attentes. Une analyse portant sur des évaluations de LLM montre que, pour un test non apparié, 200 lignes scorées permettent de détecter un écart d'environ 10 points, 500 lignes un écart d'environ 6,6 points, et 2 000 lignes un écart d'environ 3,4 points. Un gain de trois points entre deux versions de prompt, mesuré sur un échantillon de 100 exemples, se situe donc largement dans la zone de bruit : un gain de précision de 3 points sur un jeu de test de 100 exemples se situe bien dans la marge de bruit de la plupart des systèmes LLM.
Le design apparié — comparer les deux variantes sur les mêmes questions plutôt que sur des échantillons séparés — réduit sensiblement le besoin en volume. Pour un scénario de détection d'un gain de 3 points, un test apparié bien construit peut diviser par deux la taille d'échantillon nécessaire, la ramenant à environ 1 200 observations, contre un volume bien plus élevé pour un design non apparié. C'est un argument fort pour router les mêmes requêtes vers les deux variantes plutôt que de scinder le trafic au hasard, chaque fois que l'architecture le permet.
Quand les événements observés sont rares — un taux d'erreur faible, une intervention humaine peu fréquente — les tests asymptotiques classiques ne tiennent plus. La recommandation issue de la pratique de terrain est claire : il faut inspecter le nombre de succès et d'échecs attendus et utiliser une méthode exacte ou basée sur un modèle quand les effectifs sont faibles, par exemple un test exact de Fisher pour un tableau deux par deux plutôt que de forcer un test du chi² ou un z-test dont les conditions d'application ne sont pas remplies.
Enfin, la variance mesurée dans un pilote ne doit jamais être extrapolée telle quelle. Les auteurs d'un protocole de recherche sur les LLM avertissent que parce que les réponses des LLM sont bien moins variables que les réponses humaines, injecter des statistiques issues de LLM dans une formule de puissance standard produit une estimation d'échantillon excessivement optimiste, et recommandent de fonder le raisonnement sur la taille d'échantillon sur le nombre d'unités statistiquement indépendantes — conditions de prompt ou runs de modèle traités comme des clusters — et non sur le nombre brut d'observations.
Un A/B test sur un LLM échoue aussi souvent par mauvais choix de métrique que par sous-dimensionnement. Les scores purement lexicaux (BLEU, exact match) ne suffisent pas à juger la qualité d'une réponse générative : la documentation d'évaluation d'un éditeur spécialisé souligne que la nuance sémantique des sorties LLM n'est pas captée par les scoreurs statistiques, ce qui explique précisément pourquoi ils ne sont pas fiables comme métriques principales dans les expériences.
Plusieurs familles de métriques s'articulent en complément :
Sur ce dernier point, la bonne nouvelle est méthodologique : dès lors que la mesure porte sur un comportement utilisateur agrégé et non sur un score de qualité au niveau d'une sortie individuelle, les méthodes statistiques qui s'appliquent au test LLM sont les mêmes que celles qui s'appliquent à toute expérience comportementale, avec une adaptation importante : il faut tenir compte du fait que plusieurs sorties générées pour un même utilisateur ne sont pas indépendantes entre elles.
La littérature technique converge vers une séquence proche de la méthodologie des essais cliniques. Elle commence hors production, avant tout engagement de trafic réel : isoler une seule des couches testables — prompt, modèle, hyperparamètres, configuration système ou expérience utilisateur de bout en bout — dimensionner correctement l'échantillon, puis faire passer ce changement unique par une base d'évaluation hors ligne avant de songer à un test en production.
Toutes les comparaisons de variantes n'exigent pas la rigueur d'un A/B test figé. Les bandits manchots (multi-armed bandits) répondent à un objectif distinct : utiliser un bandit manchot quand l'objectif est l'optimisation — maximiser la récompense — plutôt que la signification statistique ; les bandits sont adaptés au test de variations de prompt ou de recommandations de contenu car ils orientent automatiquement le trafic vers la variante gagnante. À l'inverse, l'A/B test classique reste préférable pour les changements d'architecture majeurs ou les lancements à risque, là où la certitude statistique prime. Confondre les deux usages est une source fréquente de décisions prises trop tôt, sur un échantillon qui n'a jamais atteint la puissance nécessaire.
En pratique, trois réflexes limitent le risque de faux positif : ne jamais juger un changement de prompt ou de modèle sur une poignée d'exemples passés une fois en revue manuelle ; toujours prévoir plusieurs générations par entrée avant de lancer un test en production ; et documenter la formule de puissance utilisée pour que le résultat soit audité par une autre équipe. Ces principes rejoignent la discipline déjà appliquée dans d'autres contextes d'IA probabiliste, et c'est précisément ce que nous intégrons dans nos missions de conseil en industrialisation IA : la phase de cadrage d'un cas d'usage générique inclut systématiquement le calcul de la taille d'échantillon nécessaire avant tout déploiement en production.
Former les équipes data à ces notions — puissance statistique, variance intra-question, choix du test adapté au type de métrique — évite des mois de décisions prises sur du bruit. C'est un des volets que nous traitons dans nos parcours de formation data et IA destinés aux équipes qui pilotent des déploiements de modèles génératifs en production.
Nous utilisons des cookies de mesure d'audience et de suivi publicitaire pour comprendre la fréquentation du site et l'efficacité de nos annonces. Rien n'est déposé sans votre accord. En savoir plus