Adopt

35

Algorithm Decision Record

L’éventail des options algorithmiques à disposition des data scientists est très large : choix de l’algorithme en lui-même, de son implémentation, stratégies d’entraînement… En parallèle, les contraintes entre un premier PoC et un algorithme déployé en production sont rarement les mêmes : volume et qualité de données ou hardware à disposition par exemple. Les solutions à disposition évoluent aussi rapidement : à l’échelle
de 6 à 12 mois les méthodes à l’état de l’art peuvent changer radicalement, comme on l’a vu depuis un an avec les modèles d’IA Générative.

Dans des contextes de R&D, il est crucial que les Data Scientists aient une vision claire des contraintes du produit développé et des impacts de chaque choix algorithmique, à la fois au moment du choix initial, et dans les évolutions ultérieures. Il est aussi important de pouvoir partager simplement avec les autres parties prenantes d’un projet les arbitrages liés à ce choix et leurs impacts.

Pour répondre à ces enjeux, nous nous sommes inspirés d’un outil standard dans le monde du développement : les Architecture Decision Record. Les éléments clés d’un Algorithm Decision Record sont :

• Contexte et problème adressé

• Critères de décision clé : critères habituels d’un ADR, ainsi que des questions algorithmiques : y a-t-il une implémentation existante fiable ? Y a-t-il des contraintes de hardware ? Quelle donnée (volume, qualité) puis-je avoir à disposition ?

• Choix des options et des recommandations : identifier au moins 3 options, e.g.
via des aggrégateurs comme Papers With Code ou HuggingFace

• Impacts du choix du modèle sur le produit

 

NOTRE POINT DE VUE

Les Algorithm Decision Records sont devenus la pratique standard de nos équipes de Data Scientists. Un effet de bord positif que nous avons observé est qu’au delà de leur impact sur un projet donné, ils encouragent les échanges entre équipes et facilitent le partage de connaissances.

Comme pour les Architecture Decision Records, l’usage des Algorithms Decision Records est recommandé en priorité pour des décisions impactantes, pour lesquelles le retour en arrière n’est pas trivial.

36

Métriques business

Sur les projets de Machine Learning, nous construisons des modèles pour résoudre des problèmes métiers. Pour évaluer ces modèles, les data scientists ont pour habitude d’utiliser des métriques issues du monde de la recherche. Ces métriques ne permettent pas toujours de mesurer correctement la valeur de l’outil pour un contexte métier donnée.

Prenons l’exemple d’un outil censé détecter automatiquement des erreurs sur des factures reçues par e-mail. L’outil va dans un premier temps classifier les pages des documents pour déterminer où se trouvent la facture et le bon de commande, avant de faire les vérifications nécessaires pour trouver des potentiels défauts. Une première manière d’évaluer la performance de cet outil serait d’utiliser des métriques comme l’accuracy globale pour l’étape

de classification et un f1-score sur la détection de défauts. Or, dans ce contexte métier, il suffit d’une erreur de l’algorithme sur un e-mail pour nécessiter une intervention humaine. On peut faire l’hypothèse qu’intervenir pour 2 erreurs sur un même e-mail n’est pas tellement plus impactant que d’intervenir pour une seule erreur. Afin de connaitre la valeur “business” de notre outil, il faut donc définir une métrique qui, à la moindre erreur sur un e-mail, estime que l’outil n’a pas été performant dans ce cas-là. Une métrique finale possible est donc le pourcentage d’e-mails traités sans erreurs.

Cette métrique, dite “business” permet donc d’évaluer à date si l’outil permet un gain de temps ou pas pour les comptables. On peut même assez facilement estimer le temps gagné grâce à l’outil à partir du pourcentage d’e-mails sans intervention humaine, et en déduire un réel gain business.

Pour établir une telle métrique, on passe souvent par des raccourcis. Une métrique business comprend donc parfois des biais qu’il est important d’identifier et de rappeler à chaque fois qu’on communique dessus. Dans notre exemple, la performance peut être extrêmement basse par rapport aux performances individuelles de chaque modèle.

Si mon détecteur de défauts fait de bonnes prédictions à 80 %, il suffit qu’il fasse 1 seule erreur sur chacun des documents pour que ma métrique globale soit pénalisée à chaque fois. D’où l’importance de garder des métriques plus spécifiques pour constater les progrès techniques sur les modèles, même si ceux-ci n’apportent pas encore de réelle valeur business.

 

NOTRE POINT DE VUE

Une pratique essentielle dans la conception d’un projet de Machine Learning est de définir cette métrique avec les parties prenantes afin de pouvoir la suivre tout au long du projet et garantir que nos itérations apportent de la valeur au métier.

Trial

37

GitHub Copilot

Plus de 90% des développeurs intègrent de l’IA dans leur environnement de développement, en complétant automatiquement leur code. Une des principales technologies utilisées est GitHub Copilot.

Lancé en 2021, et s’appuyant sur un modèle de langage dérivé de GPT-3, Copilot vise à être
un pair-programmer virtuel.

Il accélère grandement leur travail :

  • proposition de la bonne syntaxe lors de l’utilisation d’une fonction
  • génération des tests
  • proposition de refactoring

La valeur ajoutée ne se situe pas seulement dans le gain de temps, mais également dans le confort de développement apporté.

La qualité de ses suggestions supprime le caractère rébarbatif de ces tâches, pour laisser le développeur se concentrer sur ce qui importe vraiment : la logique de développement.

Bien sûr, l’outil a ses limites, et propose parfois du code qui ne répond pas à ce qui était attendu. Les data scientists doivent rester attentifs, et relire systématiquement le contenu proposé. De plus, les profils moins expérimentés passent moins de temps à comprendre ce qu’ils produisent, les freinant dans leur apprentissage des bonnes pratiques. Le Tech Leader en est renforcé dans son rôle de garant de la qualité et de la formation de son équipe technique.

Sans surprise, nous avons observé que Copilot était beaucoup moins pertinent sur des technologies récentes, sur lesquelles peu de donnéesd’apprentissagesont disponibles (par exemple Polars ou LangChain en 2023).

Par ailleurs, il n’est pas possible de fonctionner uniquement en local : même si GitHub propose de ne pas partager le contenu généré avec GitHub Copilot ni l’utiliser pour entraîner le modèle, les projets les plus stricts en matière de sécurité ne pourront pas utiliser l’outil. Dans ce cas, on pourra s’orienter vers Tabnine, qui génère ses suggestions en local ou des modèles open source comme StarCoder.

NOTRE POINT DE VUE

Tous nos développeurs l’ont installé et sont unanimes quant à son utilité. Le confort apporté et les gains de temps sont du même ordre que ceux offerts par le passage d’un éditeur de texte à un vrai IDE. Les gains de productivité sont bien supérieurs au prix de la license.  Il nous paraît indispensable d’utiliser GitHub Copilot, notamment pour des projets de Machine Learning en Python. Nous considérons cependant manquer de recul sur certains effets de bord, notamment sur la progression des juniors.

38

Itérations courtes en IA

Dans des projets de développement classiques, on travaille généralement sur des fonctionnalités standards dont la complexité est estimable.
On peut itérer rapidement afin d’obtenir des retours, et la valeur d’une itération se trouve dans les fonctionnalités développées.

À l’inverse, en IA, les sujets sont souvent exploratoires : il faut comprendre la donnée, la traiter, choisir le bon modèle, l’entraîner et enfin l’évaluer pour savoir si l’on va dans la bonne direction. Pour de tels sujets, comment rester pragmatique et donner régulièrement de la visibilité dans ce tunnel, dont la durée est incertaine et le résultat flou ?

Chez Sicara, nous avons expérimenté avec succès la séparation de ces sujets exploratoires en deux types de segments :

• Le Proof of Concept (POC) : composé d’une majorité de tickets d’investigation, dont l’estimation n’est pas en complexité mais est un budget en temps, et dont le but peut être d’établir une stratégie technique via un Algorithm Decision Record (p.58), d’explorer les données, d’analyser les résultats d’un algorithme, etc. Contrairement à un développement standard où la valeur créée est une fonctionnalité mise à disposition de l’utilisateur final, la valeur créée par une investigation est un apprentissage : l’issue d’une “time-box” est une décision : soit d’arrêter d’explorer, soit de continuer à investiguer, soit de passer à l’implémentation.

• L’implémentation : composée de tickets standards à la complexité estimée, elle permet de construire une solution à la lumière de l’apprentissage de l’investigation.

Il faut cependant veiller à ne pas tomber dans des extrêmes : un POC chaotique ou vague,
ou à l’inverse une approche bureaucratique documentant chaque choix, même mineur.

 

NOTRE POINT DE VUE

Nous savons qu’il est complexe et éprouvant de se forcer à découper et de faire des plus courtes itérations, en particulier dans le cadre de projets d’IA. Nous considérons cependant que le jeu
en vaut la chandelle, et qu’à la clef, le rythme d’apprentissage des équipes et l’adéquation aux enjeux métier en seront accrus. Nous vous recommandons d’essayer et serons ravis d’échanger avec vous à ce sujet.

39

Test-Driven Machine Learning

La pratique standard en machine learning est de suivre une métrique de performance de l’algorithme, mesurée sur un dataset de test. Cependant, cette approche ne prend pas en compte l’évolution de la performance spécifique de l’algorithme sur des sous-problèmes : une amélioration de la métrique peut cacher une baisse de performance sur un sous-ensemble de données critique.

Pour répondre à ce besoin de finesse, nous nous appuyons sur le Test-Driven Machine Learning (TDML) : une approche de développement d’IA qui s’inspire du Test-Driven Development (TDD).

Le TDD est une pratique du développement logiciel dans laquelle les tests sont écrits avant le code. Le développeur rédige d’abord un test automatisé qui correspond aux spécifications fonctionnelles, puis écrit le code nécessaire pour faire passer ce test. Puis réitère autant de fois que nécessaire. Ainsi :

  • Le développement est guidé par un objectif clair, donc plus efficace.
  • Le processus en cycles courts permet de découvrir les problèmes au fur et à mesure.
  • Les tests constituent une documentation “vivante” intégrée au code.

Le TDML est l’adaptation du TDD au monde du Machine Learning :

• À la notion de spécification fonctionnelle, correspond la notion de performance
du modèle sur un périmètre délimité via un sous-ensemble d’inputs du modèle. Elle sous-entend la définition de Métriques business compréhensibles par le métier. Un seuil permet de déterminer si le test associé est OK ou KO.

• À la notion de processus itératif (ajout de nouveaux tests), correspond le concept de slices : nous découpons le test set en sous-ensembles appelés slices qui constituent chacun un test. L’ajout d’un nouveau test peut se faire par augmentation du test set global et/ou par un nouveau découpage en slices du test set existant. En IA, une partie de la logique fonctionnelle est fournie par un modèle qui n’est pas programmé directement par un humain mais obtenu à travers un processus d’entrainement. Le TDML permet de contrôler la qualité des outputs et la non- régression de ces modèles après entrainement.

Le TDML apporte aussi des avantages spécifiques au ML :

  • L’ajout de nouvelles slices venant de la production peut permettre de détecter une baisse de la performance du modèle dans le temps (data drift).
  • L’un des principaux challenges lors du développement d’un modèle IA est la généralisation à un nombre de cas croissants de la vie réelle. l'ajout de nouvelles slices couvrant ces nouveaux cas permet de refleter ce challenge et de guider le travail des data scientists. 
     


NOTRE POINT DE VUE

Bien que nous considérions la pratique du TDML comme saine, nous mettons ce blip en “Trial” de part le manque de ressources théoriques disponibles (le TDML est une pratique largement interne à Sicara) et par conséquent le manque de framework / outils pour son implémentation et son intégration dans les écosystèmes ML existants. Nous réservons notre recommandation à un public averti. Elle est pertinente dans des phases d’itérations sur un algorithme éprouvé, moins lors de phase de PoC.

40

Sicarator

Au lancement d’un projet de Machine Learning, on a deux options principales en termes de stack technique : la première est d’utiliser une Plateforme de ML end-to-end, les composants sur l’étagère testés et approuvés sont un gain de temps. Cette solution est cependant accompagnée des inconvénients classiques des solutions managées (coût, fonctionnalités “boîtes
noires”, moins de personnalisation, intégration limitée avec d’autres outils, vendor lock-in). La seconde option est d’utiliser des outils open- source et du code sur-mesure pour se constituer sa propre stack. On évite alors les problèmes de la solution managée, au prix d’un investissement initial à la fois sur les choix de briques techniques et leur mise en place.

Nous avons développé un générateur de projet, Sicarator afin de simplifier cette seconde option : il permet d’initier en quelques minutes une base de code de qualité pour un projet de Machine Learning, intégrant des technologies open-source récentes.

Créé en 2022 pour un usage interne, il a été open-sourcé un an plus tard après avoir prouvé son efficacité sur une vingtaine de projets.

La promesse est de pouvoir, en suivant une interface en ligne de commande, générer un projet répondant aux meilleures pratiques que nous avons identifiées, comme :

• Intégration continue avec plusieurs checks de qualité (tests unitaires, linting, typage)

• Visualisation des données avec un dashboard Streamlit 

• Tracking et visualisation des données et des expériences en combinant DVC et Streamlit (comme expliqué dans le blip DVC)

Le code correspondant est généré avec la documentation nécessaire pour l’utiliser. L’outil a été conçu avec une approche centrée sur le code, pour donner un maximum de contrôle aux data scientists / ingénieurs ML. L’outil cherche à refléter les bonnes pratiques à mesure que l’écosystème évolue. Par exemple, Ruff a récemment remplacé PyLint et Black comme linter / formateur de code.

Il apportera cependant une réponse moins complète que ce que proposent les plateformes les plus avancées, demandant un travail supplémentaire de mise en place. Par exemple, à date, le lancement automatisé d’instances d’entraînement de modèles n’est pas intégré.

 

NOTRE POINT DE VUE

Ce blip est particulier, car il reflète à la fois l’outil Sicarator et nos convictions sur la stack technique que ce dernier met en place. Nous serons heureux que vous le testiez et d’échanger avec vous sur les choix faits et les prochaines fonctionnalités à intégrer.

Nous l’utilisons sur n’importe quel projet de ML impliquant du code Python, même ceux utilisant des Plateformes de ML end-to-end - dans ces cas précis, on bénéficiera surtout des bonnes pratiques de développement Python incluses dans le générateur. C’est cependant sur des projets avec lesquels on souhaite combiner des technologies open-source comme DVC, Streamlit, FastAPI, etc., que l’outil apportera un maximum de valeur.

Nous conseillons donc Sicarator pour initialiser des projets de ML en Python à toutes les équipes IA avec une expertise en code et souhaitant mettre en place un outillage ML orienté open-source.

41

MTEB Massive Text Embedding Benchmark

L’information sémantique du texte est habituellement encodée sous formes de vecteurs de
taille fixe, appelés embeddings. Des modèles de deep learning spécifiques permettent de calculer ces embeddings à partir du texte brut. Il en existe de nombreux sur étagère et il peut être complexe de sélectionner le plus adapté à son cas d’utilisation.

Le Massive Text Embedding Benchmark (MTEB) permet de comparer les différents modèles d’embedding de texte, en agrégeant 129 datasets différents (début 2024) pour mieux généraliser, regroupés en 8 tâches différentes.

Cependant, MTEB présente certaines limitations importantes. Premièrement, il se concentre uniquement sur trois langues : l’anglais, le chinois et le polonais. Deuxièmement, il n’y a pas de benchmark cross-language. Les modèles d’embedding comme “text-embedding-ada-2” d’OpenAI ou ceux de Cohere ont pour atout de pouvoir gérer efficacement des datasets multilingues sans nécessiter de traduction préalable (qui résulte souvent en une perte d’information).

Enfin, la nature open source des datasets utilisés dans MTEB présente à la fois des avantages et des inconvénients. D’un côté, cela facilite l’accès et l’utilisation par la communauté. D’un autre côté, cela peut permettre aux modèles dont les datasets d’entraînement ne sont pas publics (e.g. Cohere et OpenAI) de s’entraîner spécifiquement sur ces benchmarks pour gagner des points à l’évaluation, sans pour autant refléter une amélioration de leur performance réelle.

 

NOTRE POINT DE VUE

MTEB est une référence pour le choix d’un modèle d’embedding de texte lorsque l’on travaille avec de la donnée monolingue en anglais, chinois ou polonais. Naturellement, si les contraintes du projet le permettent, une solution plus fiable - mais plus coûteuse en temps
- reste de construire un dataset labellisé représentatif de sa tâche, afin de s’évaluer sur les différents modèles.

Assess

42

LLM-as-a-judge

L’évaluation des Large Language Models (LLMs) est souvent plus complexe que pour les autres modèles, car il y a généralement un nombre indéfinissable de bonnes réponses, ce qui empêche de faire des métriques automatisées simplement en vérifiant l’égalité de la réponse du modèle et du label attendu.

Le “LLM-as-a-judge” consiste à utiliser un LLM pour évaluer la réponse d’un LLM. Cela a du sens dans 3 cas:

  • Si le LLM jugeant est plus performant que le LLM qu’il évalue.

  • Si un raisonnement avancé est utilisé (par ex. “chain of thoughts”) par le LLM jugeant, qui serait trop couteux en argent et/ou en temps à l’inférence.

Si la réponse attendue est suffisamment proche d’un label manuel, pour que le LLM jugeant puisse dire si c’est correct ou non.

L’avantage de cette méthode est de pouvoir s’évaluer automatiquement sur un large nombre d’exemples. Cependant, ce domaine de recherche est récent et peu mature. Ses principaux inconvénients sont :

  • Le fait d’utiliser de l’IA pour s’évaluer : l’outil jugeant la pertinence des réponses est lui-même sujet à des erreurs. Poussé à l’extrême, faut-il une pipeline d’évaluation pour la pipeline d’évaluation ?
  • Le fait d’avoir une nouvelle logique à maintenir (si la pipeline évolue, les prompts d’évaluation utilisés le devront aussi)
  • Le coût (notamment dans le cas de chain-of-thoughts)

L’alternative principale à cette méthode est de s’évaluer manuellement, ce qui a pour avantage d’être plus fiable et de mieux se familiariser avec la donnée et le comportement du modèle, et pour désavantage d’être chronophage et donc de limiter le nombre d’itérations et d’exemples sur lesquels s’évaluer.

 

NOTRE POINT DE VUE

Les LLM-as-a-judge permettent d’accélérer le développement de modèles basés sur des LLMs et d’élargir le panel de réponses évaluées. Cependant, ils comportent de nombreux défauts : nous recommandons donc de l’utiliser avec précaution, et de compléter une évaluation via LLM
par des évaluations manuelles régulières pour s’assurer qu’il n’y a pas de dérive et mieux analyser le comportement du modèle.

Hold

43

Itérations sans métriques sur des modèles basés sur les LLMs

Les métriques sont un standard en data science. Cependant, du fait de la simplicité à obtenir des résultats décents avec les Large Language Models (LLMs), il est tentant de s’abstraire de cette étape clé, ce qui empêche souvent le produit d’aller jusqu’en production.

En effet, contrairement aux autres modèles de Deep Learning, les LLMs n’ont (la plupart du temps) pas besoin d’être fine-tuné pour exécuter une tâche précise. La collection d’un dataset d’évaluation n’est donc pas nécessaire pour faire rapidement un Proof Of Concept (POC).

Cependant, pour passer en production, la performance initiale ne sera la plupart du temps pas suffisante, ce qui nécessitera des adaptations spécifiques. Il est alors essentiel de collecter un dataset d’évaluation (doublé idéalement d’un dataset de test) pour s’assurer que les itérations sont pertinentes et qu’elles généralisent sur l’ensemble de la donnée, mieux prioriser les améliorations à apporter et tout simplement connaître la performance du modèle.

Néanmoins, l’évaluation de LLMs est souvent plus complexe que pour les autres modèles, car
il y a un nombre indéfinissable

de bonnes réponses, ce qui empêche de faire des métriques automatisées simplement en vérifiant l’égalité de la réponse du modèle et du label attendu. La pratique la plus fiable reste alors l’évaluation manuelle. Cette dernière est cependant très chronophage, ce qui limite le nombre d’évaluations possibles et la quantité de donnée évaluée. Des méthodes plus expérimentales consistent à utiliser les LLMs pour s’évaluer. 

 

NOTRE POINT DE VUE

Nous encourageons le fait d’innover rapidement sans dataset d’évaluation dans 2 cas :

  • si la performance n’est pas critique (par ex. un outil à usage personnel) ou pour dé risquer les grandes orientations du produit.
Dans les autres cas, s’évaluer est essentiel. Quand l’évaluation automatique via des labels n’est pas possible, nous recommandons a minima l’évaluation manuelle pour sa fiabilité, qui peut être doublée par l’utilisation de LLM-as-a-judge pour accélérer les itérations.