IA d’analyse : 4 erreurs récurrentes sur 3 jeux de données

Deux variantes d’un même modèle ont été confrontées à trois fichiers courants et à des questions d’équipe commerciale. Quatre travers sont apparus à plusieurs reprises : conclusions inversées à cause de données manquantes, chiffres rédigés sans exécution de code, métrique confondue et granularité défectueuse. Les vérifications automatiques n’ont pas suffi : certaines ont validé l’erreur, d’autres ont dégradé une bonne réponse.

Des blancs qui retournent le sens des tendances et des comparaisons

Sur le suivi des commandes, une exécution rapide a affirmé une accélération entre la semaine 1 à 3.2 jours et la semaine 3 à 1.0 jour. Les valeurs existent, mais l’interprétation est fausse : le fichier s’arrête le 21 janvier, donnant environ 3 jours aux commandes de la semaine 3 pour se compléter contre 17 pour celles de la semaine 1. Sur 10 commandes de la semaine 3, 7 n’ont pas de date de livraison, ne laissant mesurer que les plus rapides. La moyenne descend de 3.17 à 1.00 alors que la part de commandes non résolues grimpe de 20% à 70%. Un passage plus lent avec Luna a, lui, signalé spontanément que cette amélioration était illusoire. Sur le fichier olympique, la comparaison de tailles a conclu à un écart minime de 0.3 cm chez les médaillés. Le calcul est exact mais il porte sur 126 lignes seulement, 226 hauteurs vides ayant été écartées sans mention, soit une réduction d’échantillon de 64%. Or, les athlètes renseignés en taille décrochent une médaille 54% du temps contre 23% pour les non renseignés, avec un test du chi carré à p = 9e-09. Avant 2016, seules 76 lignes sur 302 ont une taille et 26.5% de médailles ; à partir de 2016, les 50 lignes ont toutes une taille et 80% de médailles. Dans ce fichier, hauteur renseignée, période récente et médaille sont fortement corrélées : l’échantillon de 126 lignes est ainsi biaisé. Les contrôles utiles consistent à compter les lignes restantes après filtrage, puis à déterminer si les blancs sont aléatoires.

Des chiffres rédigés hors exécution et des écarts massifs

Une réponse sur les livraisons indiquait « 22 sur 50 » commandes dotées d’une date et « 28 » en attente. Le fichier contient 40 lignes : seul le 22 est correct, les 50 et 28 n’ayant jamais été calculés. Leur cohérence arithmétique interne masque l’erreur externe. Sur les ventes régionales, une sortie a proclamé APAC à 3.68M et 32% des revenus, alors qu’APAC totalise 3675.49 dans l’unité du fichier et 30.4% de part. L’ordre de grandeur est gonflé d’environ mille fois, un symbole monétaire inexistant est ajouté et une part non calculée est arrondie. Le journal montre que le code n’a pas été exécuté. Même en exécutant, un passage Luna a écrit qu’APAC dépassait de plus de 60% US West et US East combinés, alors que ces deux régions cumulent 3575.70 face aux 3675.49 d’APAC, soit 2.8%. Dans le même paragraphe, l’avance de 32% sur europe_north était exacte à 32.2%. À retenir : les nombres dans le code sont calculés, ceux du texte sont écrits. Les vérifications utiles exigent de confirmer l’exécution effective et de faire correspondre chaque chiffre du texte à une sortie calculée. Il faut aussi contrôler la granularité : trois doublons gonflent us_west de 30.3%, et en normalisant par les années (entre 1 et 15 selon les régions), us_west passe en tête à 290.9 contre 245.0 pour APAC.

Métrique confondue : 2.6 jours reportés au lieu de 6.09 demandés

À la question du délai moyen vécu par un client, la réponse a calculé le temps de transport (delivered_date moins shipped_date) et annoncé 2.6 jours. La métrique utile côté client est le délai commande-à-porte, à 6.09 jours en moyenne. La valeur fournie est 2.4 fois inférieure car les colonnes ne correspondent pas à la question. L’erreur n’est pas technique : le code est valide et aucun test de type ne l’expose. Ship-to-door renseigne l’entrepôt quand order-to-door décrit l’attente client ; la confusion n’était pas signalée dans le résumé. Le contrôle consiste à confronter explicitement la question aux colonnes employées dans le calcul.

Ce que recèlent vraiment les trois fichiers utilisés

Shipment_tracking aligne 40 commandes uniques, passées entre le 1er et le 21 janvier 2024, avec trois jalons de dates. Dix-huit entrées restent sans expédition ni livraison. Regional_sales est prévu pour 59 lignes couvrant 8 régions de 2007 à 2025 avec une valeur unique par couple région-année, mais six couples ont plusieurs lignes, dont trois doublons exacts en us_west. Quatre combinaisons portent des chiffres contradictoires, tel apac 2015 avec 173.46 et 126.78, et l’année 2012 pour us_west figure à quatre reprises avec trois valeurs distinctes. L’amplitude de l’historique diffère fortement d’une région à l’autre, allant de 1 à 15 ans. Olympics_athletes_events décrit 352 lignes pour 336 athlètes, sur 15 Jeux et 167 épreuves ; 11 athlètes figurent plusieurs fois, dont un six fois, et 120 lignes portent une médaille. Ces caractéristiques influent sur les classements et agrégats : des doublons peuvent gonfler us_west de 30.3%, et un indicateur par an peut changer de leader après normalisation (290.9 pour us_west contre 245.0 pour APAC).

Protocole, modèles et vérifications mises en défaut

Le protocole associait trois jeux de données et des questions opérationnelles courantes à deux variantes d’un même modèle : GPT-5.6 Terra pour des passages rapides et GPT-5.6 Luna pour des exécutions plus lentes, le tout sur Pandas et SciPy. Une étape de relecture demandait au modèle de vérifier ses propres chiffres destinés à un rapport exécutif. Les résultats montrent que certaines vérifications détectent un comptage erroné tout en validant une conclusion inversée, et que d’autres « corrections » transforment une bonne réponse en erreur. Exécuter le code ne suffit pas systématiquement ; il faut planifier des contrôles qui relient chaque chiffre du texte à une sortie calculée et qui valident les hypothèses de granularité et de complétude.