La revanche du data scientist

• Avec l’arrivée des API de LLM, les data scientists et les MLE ont été écartés du parcours critique de mise en production de l’IA, mais l’essence du travail réel — conception d’expériences, mesure de métriques, débogage de systèmes probabilistes — n’a pas disparu
• Le cas de Codex chez OpenAI comme le projet auto-research de Karpathy montrent tous deux qu’un harness composé de tests, de métriques et d’une stack d’observabilité est l’élément central, et qu’une grande partie de ce harness relève de la data science
• Sur le terrain, cinq pièges récurrents des evals — métriques génériques, modèles-juges non vérifiés, mauvaise conception expérimentale, mauvaises données et labels, automatisation excessive — dégradent la qualité des systèmes d’IA
• La cause commune de chacun de ces pièges est l’absence de fondamentaux en data science ; l’analyse exploratoire des données, l’évaluation de modèles, la conception d’expériences, la collecte de données et le ML en production restent les bonnes réponses
• « Regarder directement les données » reste l’activité au ROI le plus élevé, tout en étant la plus souvent omise, et le rôle du data scientist demeure central même à l’ère des LLM

---

Le retour du data scientist

• Le data scientist a un temps été présenté comme « le métier le plus sexy du XXIe siècle », avec des rémunérations élevées
  • Le poste exigeait des compétences multiples : modélisation prédictive, mesure de la causalité, exploration des motifs dans les données
  • Par la suite, les tâches de modélisation prédictive se sont séparées sous le rôle de Machine Learning Engineer (MLE)
• L’arrivée des LLM (grands modèles de langage) a changé la donne : dans les entreprises qui déploient de l’IA, les data scientists et les MLE ne font plus forcément partie du chemin obligatoire
  • Grâce aux API de foundation models, les équipes peuvent intégrer l’IA de manière autonome
• Mais l’entraînement de modèles ne résume pas le métier de data scientist, et la conception d’expériences, le débogage et la conception de métriques restent des missions essentielles
  • Le simple fait d’appeler une API de LLM ne fait pas disparaître ce travail
• La conférence “The Revenge of the Data Scientist” à PyAI Conf aborde ce point à travers des cas concrets et souligne que le rôle de la data science reste crucial

La véritable nature du harness relève de la data science

• Le concept de Harness Engineering chez OpenAI décrit une structure dans laquelle un agent développe du code de façon autonome dans un environnement entouré de tests et de spécifications
  • Le harness inclut une stack d’observabilité avec logs, métriques et traces, permettant à l’agent de détecter lui-même des comportements anormaux
• Le projet auto-research d’Andrej Karpathy suit lui aussi le même schéma d’optimisation itérative fondée sur une métrique de validation loss
• Appeler un LLM via une API ne supprime ni la conception d’expériences, ni le débogage, ni la conception de métriques ; une large part du harness, c’est de la data science
  • Par le passé, on passait beaucoup de temps à vérifier les données, la cohérence des labels et la conception des métriques
  • Aujourd’hui, on a plutôt tendance à s’en remettre au « ressenti » du modèle, ou à utiliser telles quelles des bibliothèques open source de métriques
• Le manque de compréhension des données entraîne en particulier beaucoup de malentendus dans les domaines du RAG (Retrieval-Augmented Generation) et des evals
• On voit apparaître des affirmations comme RAG is dead, evals are dead, alors même que les équipes qui les avancent construisent des systèmes qui reposent sur ces concepts
• Chez les ingénieurs sans bagage data, on observe souvent une tendance à éviter ce qu’ils ne comprennent pas, particulièrement dans les domaines du retrieval et des evals
• Appeler un LLM via une API ne supprime ni la conception d’expériences, ni le débogage, ni la conception de métriques ; une large part du harness, c’est de la data science

Les 5 pièges des evals

• Piège 1 : les métriques génériques (Generic Metrics)

  • Des métriques génériques comme le helpfulness score, le coherence score ou le hallucination score sont trop larges pour diagnostiquer les véritables pannes d’une application
  • Un data scientist n’adopte pas une métrique telle quelle : il commence par explorer directement les données et les traces pour comprendre ce qui casse réellement
  • « Regarder les données » signifie lire soi-même les traces, créer un visualiseur de traces sur mesure et mener une analyse d’erreurs afin de classer les échecs
  • Des métriques de similarité génériques comme ROUGE ou BLEU conviennent très mal aux sorties de LLM ; il faut des métriques spécifiques à l’application comme « Calendar Scheduling Failure » ou « Failure to Escalate To Human »
  • Regarder les données est l’activité au ROI le plus élevé, et pourtant celle qu’on omet le plus souvent

• Piège 2 : les modèles-juges non vérifiés (Unverified Judges)

  • La plupart des équipes qui utilisent un LLM comme juge n’ont pas de réponse claire à la question « pourquoi faire confiance au juge ? »
  • Un data scientist traite le juge comme un classifieur (classifier), obtient des labels humains et mesure sa fiabilité via une séparation train/dev/test
    • Les exemples few-shot viennent du jeu d’entraînement, le prompt du juge est amélioré sur le dev set, et le test set est conservé pour vérifier le surapprentissage
  • Lors du reporting, il faut utiliser precision et recall plutôt qu’une simple accuracy — si un mode d’échec ne représente que 5 %, l’accuracy masque les performances réelles
  • La validation de classifieurs est devenue une compétence disparue dans l’IA moderne

• Piège 3 : une mauvaise conception expérimentale (Bad Experimental Design)

  • Constitution du test set : la plupart des équipes demandent au LLM de « générer 50 requêtes de test », mais cette méthode produit des données génériques non représentatives
    • Un data scientist commencerait par examiner les véritables données de production, identifier les dimensions importantes, puis générer des exemples synthétiques alignés sur ces dimensions
    • Les données synthétiques doivent être produites à partir de logs ou de traces réels, avec injection de cas limites
  • Conception des métriques : mettre toute la rubrique d’évaluation dans un seul appel LLM et utiliser par défaut une échelle de Likert de 1 à 5 revient à masquer l’ambiguïté et à repousser les décisions difficiles sur la performance du système
    • Il faut remplacer cela par des jugements binaires (pass/fail) sur des critères à portée limitée

• Piège 4 : mauvaises données et mauvais labels (Bad Data and Labels)

  • Comme le labelling est peu valorisé, on tend à le déléguer à l’équipe de développement ou à l’externaliser, alors qu’un data scientist exige que le marquage soit fait directement par des experts métier
  • Au-delà de la qualité des labels, il existe une raison plus profonde : le concept de « criteria drift » mis en évidence dans des travaux de Shreya Shankar et d’autres — les utilisateurs ont besoin de critères pour évaluer des sorties, mais ces critères se définissent justement en évaluant les sorties. Autrement dit, on ne sait pas ce qu’on veut avant d’avoir vu les sorties du LLM
  • Il faut placer les experts métier et les PM face aux données brutes, pas face à un score de synthèse

• Piège 5 : trop d’automatisation (Automating Too Much)

  • Les LLM peuvent aider à écrire le code de plomberie (plumbing), générer du boilerplate et connecter des évaluations
  • Mais le fait de regarder directement les données n’est pas automatisable — précisément parce qu’« on ne sait pas ce qu’on veut avant d’avoir vu les sorties »
  • Parmi les autres pièges évoqués : mauvais usage des scores de similarité, questions ambiguës posées au juge comme « est-ce utile ? », exposition des annotateurs à du JSON brut, reporting de scores non calibrés sans intervalle de confiance, data drift, surapprentissage, mauvais échantillonnage, tableaux de bord difficiles à interpréter

Mise en correspondance avec les fondamentaux de la data science

• Les cinq pièges ont tous la même cause profonde : l’absence de fondamentaux en data science
• Correspondance entre chaque piège et les méthodologies classiques :
  • Lecture des traces et classification des échecs → analyse exploratoire des données (EDA)
  • Validation d’un juge LLM à l’aide de labels humains → évaluation de modèle (Model Evaluation)
  • Construction d’un test set représentatif à partir de données de production → conception expérimentale (Experimental Design)
  • Labelling par des experts métier → collecte de données (Data Collection)
  • Surveillance du comportement d’un produit en production → ML en production (Production ML)
• Les noms ont changé, mais le travail reste le même
• Python reste la meilleure boîte à outils pour explorer et manipuler les données
• Publication d’un plugin open source (evals-skills) pour analyser des pipelines d’evals et diagnostiquer ce qui ne va pas