Adopt

12

DINOv2 comme modèle d'embedding d'image

Un besoin assez récurrent en computer vision est d’obtenir de bonnes représentations vectorielles (embeddings) d’images pouvant être utilisés pour des tâches spécifiques en aval (comme le clustering, la classification, la détection, la segmentation, etc.). Par exemple, une classification simple peut être composé des étapes suivantes :

  1. Calcul de représentation d’un ensemble d’images

  2. Stockage et indexation dans une base de données vectorielle

  3. Détermination de la classe grâce à un algorithme simple comme k-NN ou un modèle linéaire

Il n’est pas toujours possible de construire un modèle pour calculer de bonnes représentations, pour un problème donné, pour des raisons de disponibilité de données d’entraînement : images annotées non disponibles, chères à produire, ou inexistantes en début de projet. Il est alors intéressant de considérer des modèles génériques pré-entrainés sur de vaste corpus de donnée généraliste. Pendant longtemps, notre référentiel à Sicara furent des CNN (typiquement et dans l’ordre chronologique : VGG, ResNet, EfficientNet) pré-entrainés sur imagenet-1K (~1.2M images).

Depuis 5 ans, plusieurs innovations ont changé la donne :

• le perfectionnement de techniques d’entrainements dites “self-supervized” permettant de s’affranchir d’annotation pendant l’entrainement et donc de s’appuyer sur des bases d’images beaucoup plus grandes (e.g., 1.2B images pour DinoV2)

• l’apparition des transformers, une nouvelle architecture basée sur les mécanismes d’attention (Attention is all you need, 2017) d’abord en NLP (BERT) puis en vision (An Image is Worth 16x16 Words, 2020) avec les modèles ViT (Vision Transformers) qui atteignent et dépassent les CNNs en termes de performance, de flexibilité et de scaling à de grands jeux de donnée proposés par Meta qui est une évolution de son prédécesseur Dino (2021) qui combine et bénéficie de ces deux approches. Les personnes qui s’intéressent à son fonctionnement pourront regarder l’excellente analyse de Yannick Kilcher sur Youtube à ce sujet à ce sujet. Outre l’excellence académique du papier, Meta a rendu public les poids des modèles pré-entrainées présentant de nombreux avantages :

  • la licence Apache 2.0 permet un usage commercial

  • les poids sont disponibles sur Torch Hub

  • plusieurs tailles de modèle sont disponibles, entre 21M et 1.1B de paramètres

  • les embeddings obtenus par ces modèles permettent de construire sans fine- tuning des classifieurs très performants (83.5% sur imagenet 1K en kNN, 86.7% sur image-net avec une couche linéaire)

  • les mécanismes d’attention des ViT permettent une amélioration de l’explicabilité du modèle en permettant de déterminer les pixels de l’image entrant le plus en jeux pour la sortie

 

NOTRE POINT DE VUE

Nous recommandons l’usage des modèles DinoV2 (architecture et poids) comme modèle d’embedding sur étagère sans ré- entrainement.

Le fine-tuning ou l’entrainement complet avec DinoV2 est réservé à un public averti et nécessite à la fois une grande puissance de calcul et un gros volume de donnée.

13

GPT-4

GPT-4, le Large Language Model (LLM) le plus performant actuellement d’OpenAI, est un modèle de génération de texte auto-régressif développé par OpenAI. Il est probablement constitué d’une “Mixture of Experts” de plusieurs modèles de plus de 200 milliards de paramètres chacun (comme confirmé par plusieurs leaks). Pouvant aussi accepter des images en entrée, GPT-4 résout la plupart des tâches de traitement de texte ou d’image (traduction, synthèse, compréhension, rédaction... etc. comme on peut s’en rendre compte en utilisant ChatGPT Plus). GPT-4 prouve son utilité dans divers domaines tels que la récupération d’informations textuelles, l’automatisation des flux de travail de support client, et le traitement automatisé de documents. Sur la quasi-totalité des tâches, GPT-4 surpasse très largement les alternatives open-source et dépasse nettement les autres modèles propriétaires (Claude, PalM, etc.).

Le Function Calling, intégré à GPT-4, permet d’utiliser des «fonctions» prédéfinies, ou des schémas, dans les appels de modèles. Cela facilite la génération de sorties structurées, plutôt que de se limiter au texte brut. Les fonctions permettent aussi d’interagir avec des outils externes tels que l’exécution de code, l’accès à des API ou l’exécution de commandes shell.

Récemment, OpenAI a sorti GPT- 4 Turbo qui est une itération sur GPT-4 ayant des coûts ~3x plus faibles, un temps d’inférence plus rapide et une fenêtre de contexte maximale à 128k tokens (~40k mots). Il reste relativement lent à inférer, par rapport à GPT-3.5 par exemple, qui est plus adapté pour du temps réel, et cher (~$0.1 pour un appel avec 4k tokens en entrée et 2k tokens en sortie).

Enfin, attention à la fiabilité de la version Turbo, toujours en bêta, dont la précision de la réponse peut s’avérer moins fiable. Dans un contexte ou la qualité de l’output est particulièrement critique, nous recommandons de rester sur la version stable de GPT-4 pour le moment.

 

NOTRE POINT DE VUE

GPT-4 bat tous les modèles accessibles au public et est particulièrement peu susceptible à l’hallucination. L’intégration du Function Calling et OpenAI Assitants API et la récente réduction des coûts avec GPT-4 Turbo renforcent sa position de leader.

Si la réduction des coûts de Run ou de la latence est plus importante que la performance brute, alors préférez plutôt GPT-3.5 ou un autre “petit” LLM. Pour des contraintes de sécurité ou de contrôle particulières, il existe aussi les LLM Open Source.

14

PyTorch

La démocratisation du Machine Learning dans les années 2010 est imputable à plusieurs facteurs, l’un d’entre eux étant l’apparition de packages open-source de calcul de tenseurs et de gradients, comme PyTorch en 2016 (ou TensorFlow en 2015).

Conçu par MetaAI et initialement orienté vers la recherche, il a étendu son influence à l’industrie et permet la configuration et l’entraînement de modèles de Machine Learning (notamment de réseaux de neurones), ainsi que le traitement de données qui est essentiel à l’entraînement. PyTorch permet de détailler précisément les boucles d’entraînement des modèles tout en gardant une syntaxe relativement facile à prendre en main, et il existe des surcouches telles que PyTorch Lightning qui permettent de simplifier encore la syntaxe et le déploiement.

Un avantage significatif de PyTorch par rapport à ses concurrents réside dans la richesse des modèles disponibles au sein de la communauté. Sur des plateformes telles que Papers With Code et HuggingFace, la majorité des modèles sont implémentés en PyTorch, en comparaison avec une présence minoritaire de TensorFlow, par exemple. De plus, PyTorch offre une bonne rétrocompatibilité, minimisant les risques lors des mises à jour de versions, ce qui est crucial pour des applications en production.

 

NOTRE POINT DE VUE

Nous recommandons vivement l’utilisation de PyTorch, principalement pour sa flexibilité et la richesse de sa communauté. Attention aux cas d’usage d’IA embarquée car PyTorch Mobile est encore en Beta. Malgré cela, PyTorch demeure un choix solide pour une variété de cas d’usages, offrant un package complet pour le développement et l’entraînement de modèles de Machine Learning.

15

Retrievial Augmented Generation

Les Large Language Models (LLMs) ont gagné une grande popularité grâce à leurs compétences généralistes en zero-shot learning et leur comportement de base de connaissances universelle interactive. Or, cette connaissance ne comprend que des données publiques et s’arrêtent à la date d’entrainement du modèle.

La Retrieval Augmented Generation (RAG) permet de complémenter ce savoir d’une base de connaissances externe (Notion, Confluence, PDFs, documentation interne, etc.). On peut alors interroger cette base via du langage naturel.

L’algorithme fonctionne en deux étapes :

1. Retrieval : récupération des documents les plus proches de la question en comparant une représentation (i.e. un embedding vectoriel) de la requête à des représentations des documents qui sont stockées dans une base de données (voir Recherche vectorielle avec des Bases de Données standards et Bases de Données vectorielles dédiées)

2. Generation : utilisation d’un Large Language Model (LLM) pour générer une réponse à la question à partir des documents récupérés.

Cette méthode permet de s’adapter à sa propre donnée, sans passer par du fine-tuning, ce qui a plusieurs avantages :

  • Éviter des coûts de GPUs qui peuvent être importants avec des LLMs.
  • Renforcer l’explicabilité : on sait exactement sur quelle donnée se base la réponse. Cela permet aussi de renvoyer ces sources aux utilisateurs qui ne souhaitent pas attendre le temps de génération du LLM.
  • Permettre de s’adapter continuellement à l’évolution de la base de connaissance, sans avoir à entraîner à nouveau le modèle.
  • Améliorer la sécurité, en limitant l’accès aux données sensibles aux personnes non autorisées (via l’utilisation des metadatas dans la base de données vectorielle).
  • Limiter les hallucinations du modèle, en demandant au LLM de s’appuyer sur les documents du prompt.

Cependant, un RAG est un système plus complexe à gérer qu’un modèle unique (si on opte pour le LLM Fine-Tuning supervisé sur des questions / réponses (p.40)) et plus cher à l’inférence (puisque le prompt sera relativement large, pour contenir les documents). Aussi, sans fine-tuning, le modèle d’embedding et le LLM ne s’adapteront pas au domaine spécifique de la base de données de connaissances, ce qui rendra la compréhension de certains jargons plus compliquée. Enfin, le Retrieval est souvent le bottleneck de précision : si cette étape échoue à trouver de l’information pertinente, le LLM (qui aurait pu répondre correctement dans le cas du fine-tuning) ne pourra pas fournir de réponse pertinente.

 

NOTRE POINT DE VUE

Malgré ces points, les RAGs sont généralement à préférer au fine-tuning lorsqu’un contrôle sur la donnée utilisée pour générer la réponse est nécessaire (e.g. pour la renvoyer à l’utilisateur ou la filtrer pour des raisons de sécurité) ou lorsque la donnée évolue fréquemment (e.g. une documentation qui évolue au quotidien).

Mettre une V1 de RAG en place pour tester la valeur produite est très simple, même sans compétence de code via les GPTs de ChatGPT+, l’API Assistants d’OpenAI ou des boiler-plates ou frameworks comme LangChain. Cependant, maximiser la valeur du produit nécessite généralement des itérations spécifiques.

16

SHAP

Les modèles de Machine Learning complexes sont considérés comme des boites noires peu interprétables. Pour donner confiance dans ces modèles, des méthodes d’explicabilité sont utilisées. SHAP (SHapley Additive exPlanations) est une méthode qui en fait partie et qui fournit une vision transparente et compréhensible de la manière dont les prédictions sont faites, quel que soit le type de modèle utilisé. Elle est pertinente pour les cas où les données d’entrée sont structurées.

Avant l’avènement de SHAP, l’interprétation des modèles ML complexes reposait largement sur des méthodes plus simplistes, telles que la feature importance. SHAP, en revanche, utilise la théorie des jeux coopératifs pour attribuer à chaque caractéristique sa contribution locale à la prédiction.

SHAP a l’avantage majeur d’être local par nature et permet donc d’analyser la contribution de chaque variable en un point unique ou sur un cluster de points de données précis. Les valeurs de SHAP forment elles-mêmes des distributions statistiques qu’on peut analyser et visualiser pour aller plus loin qu’un simple bar chart.

La principale limitation de SHAP est sa complexité de calcul, particulièrement pour les modèles avec beaucoup de paramètres ou sur des jeux de données massifs.

 

NOTRE POINT DE VUE

Nous appliquons la méthode SHAP systématiquement sur nos projets où l’explicabilité des décisions prises par les modèles est indispensable, e.g. dans les secteurs réglementés comme la finance ou la santé. Nous l’utilisons également pour analyser finement nos modèles dans le but de les améliorer, lorsque les données d’entrée sont structurées.

Nous recommandons donc l’adoption de SHAP dans ces applications.

17

SpaCy

SpaCy est une librairie open-source de traitement du langage naturel (NLP) en Python, conçue pour une utilisation en production. Son approche privilégie l’efficacité, offrant des modèles en mode «boîte noire» pour une mise en production rapide et des résultats fiables. Contrairement à d’autres outils comme NLTK ou Stanford NLP, orientés vers la recherche, SpaCy vise à fournir des solutions concrètes, avec une bonne performance et une grande variété de fonctionnalités NLP, de la reconnaissance d’entités nommées à la classification de texte.

La simplicité d’utilisation de SpaCy est parmi ses atouts majeurs. La possibilité d’entraîner des modèles rapidement à partir d’un fichier de configuration, ainsi que l’intégration des commandes CLI en tant que fonctions Python, facilitent l’intégration de SpaCy dans divers environnements de développement. Cette facilité d’adaptation, combinée à son architecture orientée objet, rend la navigation et l’utilisation de la librairie intuitive, même pour ceux qui sont relativement nouveaux dans le domaine du NLP. En outre, SpaCy supporte nativement tous les modèles disponibles via la librairie Transformers de HuggingFace et des multiples LLM propriétaires via des APIs telles que OpenAI mais aussi des LLM open-source obtenus via HuggingFace (finetuné ou pas).

Cependant, il est important de noter que SpaCy, tout en permettant des itérations sur les données d’entraînement et les hyperparamètres des modèles, offre une marge de manœuvre limitée pour des modifications en profondeur des modèles eux-mêmes. Cette caractéristique souligne la philosophie de SpaCy : obtenir des résultats rapides et fiables, tout en simplifiant le processus de développement.

 

NOTRE POINT DE VUE

SpaCy est un outil historique et représente une valeur sûre. C’est pourquoi nous recommandons fortement l’adoption de SpaCy pour les projets NLP classiques (hors LLM) qui ont des contraintes de robustesse ou de performance.

Nous n’avons pas eu l’opportunité d’utiliser SpaCy-LLM en production donc ne partageons pas de recommandation concernant son utilisation.

18

YOLO

Les modèles YOLO (You Only Look Once) sont des algorithmes de détection d’objets en temps réel.

Le premier modèle YOLO, sorti en 2016, se distingue d’autres modèles de détection d’objets (comme le R-CNN/Fast R-CNN) notamment par sa vitesse d’inférence. En effet, les modèles jusqu’alors impliquaient généralement des étapes séparées pour générer des propositions de régions et les classifier, alors que les modèles YOLO intègrent ces deux étapes en un seul réseau de neurone dans lequel on ne passe qu’une fois (ce qui lui a valu son nom).

Au fil des années, plusieurs versions de YOLO sont sorties, améliorant les performances : YOLOv4 dépasse largement en 2020 son concurrent Faster RCNN-FPN+ en termes de vitesse (5 fois plus rapide) et de précision (9.4 pts de Box AP en plus sur le benchmark MS COCO).

Après YOLOv4, l’entreprise privée Ultralytics a repris le flambeau et passé les nouvelles itérations sous licence AGPL-3.0, ce qui rend plus difficile son utilisation à des fins commerciales. Ces versions améliorent légèrement la performance (de quelques points) mais offrent surtout des implémentations avec une bonne qualité de code, ce qui les rend plus facilement exploitables. Aujourd’hui, les dernières versions de YOLO restent l’état de l’art sur des benchmarks de détection d’objets en temps réels et se sont généralisés à des problèmes connexes comme la segmentation, le tracking d’objets ou la pose estimation.

 

NOTRE POINT DE VUE

Les modèles YOLO sont un choix robuste pour les applications nécessitant une détection d’objets en temps réel par leur capacité à fournir des détections rapides et précises. Il existe cependant des modèles plus lents, mais plus précis.

Nous avons utilisé YOLOv4 sur de nombreux cas d’application, y compris de l’embarqué (compressé en tflite). Bien que la qualité du code de ces modèles open source ait parfois rendu complexe leur entrainement, cela n’a pas été bloquant. Nous ne recommandons pas les versions d’Ultralytics (v5 et plus) pour des raisons de license.

Trial

19

Boruta

Lorsqu’on entraîne un modèle de Machine Learning sur des données structurées, un écueil classique est de se retrouver  avec un grand nombre de features qui n’améliorent pas le modèle voire le détériorent. Cela dégrade la qualité, allonge inutilement le temps d’entraînement et d’inférence, et complexifie les analyses et les itérations.

Boruta est une méthode de sélection de features pour les modèles de Machine Learning, conçue pour identifier celles qui sont les plus utiles pour la prédiction, éliminant ainsi le bruit et la redondance.
Le principe :

  1. Des “shadow features” aléatoires sont créées à partir des vraies features en mélangeant aléatoirement leurs valeurs.

  2. Un modèle de random forest est entraîné sur l’ensemble des features, qui sont ensuite classées en fonction de leur feature-importance au sein du modèle. Boruta ne retient alors que les  features statistiquement plus importantes que les shadow features.

Il existe d’autres méthodes de sélection de features, notamment des méthodes statistiques classiques comme l’analyse en composantes principales (PCA) ou la brique de feature-selection intégrée à scikit-learn.

Boruta se distingue par sa capacité à capturer l’importance de toutes les variables, y compris celles qui interagissent de manière complexe (e.g. haute non-linéarité) avec d’autres. De plus, la méthode Boruta-Shap permet d’utiliser les SHAP values à la place des features-importances pour classer les features et obtenir des résultats plus fiables.

L’algorithme Boruta peut cependant être coûteux en calcul, surtout avec de très grands ensembles de données et de variables, et nécessite d’optimiser certains hyper-paramètres comme les seuils de signification pour le test d’importance.

 

NOTRE POINT DE VUE

Nous recommandons donc d’utiliser Boruta principalement comme un outil en première approche, afin d’identifier rapidement les features qui sont les plus utiles. En revanche, il est toujours préférable de tester le modèle avec et sans les features et de se baser sur les performances réelles pour faire un choix quant à l’exclusion ou non des features.

20

Causal Impact

Un problème classique dans les modèles de séries temporelles est de mesurer l’impact d’une intervention sur la série. Par exemple, mesurer l’impact d’une campagne marketing sur le volume de ventes. Les approches classiques (A/B Testing, tests randomisés en double aveugle) nécessitent un groupe de contrôle sur lequel aucune intervention n’est faite comme point de comparaison. Il n’est pas toujours simple d’identifier et isoler un groupe de contrôle ayant un comportement similaire.

Causal Impact est une méthode de mesure d’impact causal d’un événement (”intervention”) sur une série temporelle ne nécessitant pas de groupe de contrôle. Initialement publiée par une équipe de recherche de Google, cette approche utilise une méthode d’inférence causale (par défaut un modèle “Bayesian structural time- series”) pour prédire un contrôle synthétique. Ce dernier va servir de comparaison avec les données réellement observées post-intervention. Il représente l’évolution prédite de la série temporelle après la date d’intervention, si cette dernière n’avait pas eu lieu. Le modèle nécessite de disposer de séries temporelles qui ne doivent pas être impactées par l’intervention. Ces features pré-intervention sont utilisées pour entraîner le modèle, qui sert ainsi à prédire le contrôle synthétique après intervention.

On peut mesurer la précision du modèle grâce à la sortie du modèle bayésien, une distribution de probabilité. On peut alors en déduire la probabilité que cet impact soit dû au hasard.

Avec la bonne combinaison de modèle et de features prédictives, il est possible d’observer l’impact local de l’intervention isolé d’autres variables, mais cette combinaison peut être difficile à trouver selon le problème. Pour faire le meilleur choix, il est conseillé de calculer une mesure d’impact en considérant uniquement la donnée pré-intervention. Dans ce cas, une bonne combinaison de modèle et de features devrait toujours donner un impact nul.

On peut ensuite conserver cette combinaison pour mesurer l’impact de l’intervention sur la courbe à l’étude. 

 

NOTRE POINT DE VUE

Nous recommandons d’essayer Causal Impact dans un contexte de mesure d’impact sur des séries temporelles sans groupe contrôle, car la méthode apporte une robustesse statistique à une mesure de changement post-intervention. Comme le package original de Google est seulement disponible en R, nous conseillons la librairie tfcausalimpact de Willian Fuks pour une implémentation simplifiée en Python.

21

OpenAI Assistants API

Les LLMs se basent sur le contenu acquis pendant son entraînement pour nous répondre. Or, nous cherchons à avoir des réponses nécessitant des connaissances précises, c’est pourquoi, par exemple, nous implémentons des RAG (Retrieval Augmented Generation (p.32)). Cela est coûteux de mettre en place les systèmes nécessaires (comme LangChain pour l’orchestration, Qdrant pour la base de données vectorielle), alors qu'ils sont très communs entre les cas d’usages. L’Assistant API d’OpenAI offre une solution clé en main (reposant sur GPT-4 (p.30) ou GPT-3.5) pour accélérer et gérer ces cas d’usages où un LLM interagit avec des outils externes (base de connaissance, APIs externes, environnement de calcul, etc.) et répondre aux mêmes cas d’usages en quelques clics.

Cette API, actuellement en phase beta, prend en charge trois types d’outils : Code Interpreter, Retrieval (utilisation de connaissances externes au modèle) et Function calling (appels de fonction déclenchés par le modèle). L’interaction avec l’API repose sur des objets abstraits (l’Assistant, le Thread, le Message et le Run), laissant la gestion de la fenêtre de contexte et de l’historique de chat au backend OpenAI (du point de vue de l’utilisateur, il n’y a pas de limite sur la taille de l’historique d’un Thread).

Attention néanmoins au coût des fichiers de la base de connaissances : c’est en fonction de l’espace disque utilisé ($0.20/GB/jour). Donc, si on stocke autre chose que du texte brut, cela peut représenter un coût significatif. De plus, le lock-in et le manque de maitrise sur le comportement du modèle (ingestion, chunking, logique de recherche, etc.), sont un revers inévitable d’une API haut-niveau managée.

 

NOTRE POINT DE VUE

Nous avons l’habitude de développer nous-mêmes les solutions comme les RAGs, mais nous réfléchissons de plus en plus à l’utiliser l’Assistant API pour créer des assistants LLM qui accède à une base de connaissance, des outils externes et un environnement Python. Nous attendons d’avoir plus de recul sur son utilisation en production à grande échelle pour avoir une recommandation définitive.

 

22

LLM Fine-Tuning supervisé sur des questions / réponses

Les Large Language Models (LLMs) à l’état de l’art sont des modèles généralistes entrainés sur de la donnée publique. L’enjeu d’adapter ces modèles à des données propriétaires est majeur. Fine-tuner un LLM de manière supervisée consiste à continuer à entraîner un modèle pré-entraîné (e.g. Mixtral, Llama, GPT3.5, ...) avec un set de questions/réponses pour adapter les réponses du modèle et le rendre plus spécifique. Cela s’avère notamment utile lorsque le prompt engineering seul ne suffit pas, par exemple pour guider le format de sortie souhaité ou pour incorporer un concept spécifique, par exemple résumer des textes avec du vocabulaire propre à une entreprise.

Le fine-tuning de LLM a été énormément simplifié au cours de 2023: Des techniques comme QLora (Quantization des poids et Low-Rank Adaption - qui consiste à n’adapter qu’un sous-ensemble des poids) permettent d’effectuer ce fine-tuning de manière efficiente et donc économique (quelques dizaines d’euros pour un modèle de 7B paramètres). Seulement quelques milliers d’exemples (questions/réponses) de qualité sont nécessaires pour obtenir de bons résultats.

Cependant, le fine-tuning est une opération coûteuse en temps, nécessitant la préparation d’un dataset adapté (qu’on pourra générer via GPT-4 (p.30)) et plusieurs itérations pour obtenir des résultats optimaux. De plus, fine-tuné sur une tâche spécifique, le modèle perdra une partie de ses capacités généralistes.

Il y a plusieurs alternatives, notamment des méthodes sans réentraînement. Ces méthodes nécessitent souvent des prompts bien plus gros (pour contenir les informations sur lesquelles la réponse doit s’appuyer) et sont donc plus chères et longues à l’inférence. Ces méthodes peuvent être limitées (par ex comprendre du jargon spécifique).

Ces méthodes sont :

  • Le Retrieval Augmented Generation qui permet aussi de s’adapter à de la donnée spécifique et permet notamment d’avoir un meilleur contrôle sur la donnée et d’éviter la complexité du fine-tuning supervisé (création de dataset de questions/réponses…).
  • Le prompt engineering pour préciser le contenu de la tâche. Du few-shot learning (i.e. montrer dans le prompt quelques exemples de questions/réponses) peut-être utilisé pour guider plus précisément le modèle comparé a une simple explication.
  • Le fine-tuning non supervisé : cela consiste à apprendre au modèle à compléter des textes. Le modèle perdra probablement ses capacités de question/réponse en conséquence. Cette méthode n’est donc que recommandée pour des cas d’utilisations de complétions (par ex un copilote de rédaction ou de code).
  • Reinforcement-Learning from Human Feedback (RLHF) : cela consiste à utiliser du feedback humain pour entrainer un reward model, à noter l’output de notre LLM et à utiliser une méthode appelée PPO pour fine-tuner le LLM à partir du reward model. Cependant, cette méthode est très couteuse en termes de collecte de feedbacks humains et d’entrainement (>$10M en ordre de grandeur). De plus, elle est très instable et nécessite donc de nombreuses itérations.
  • DirectPreference Optimization (DPO) : cette méthode consiste à fine-tuner un modèle en fournissant des exemples de bonnes et mauvaises réponses pour chaque question (généralement obtenues via du feedback humain). Bien que plus simple, plus stable et plus efficiente que le RLHF, elle reste beaucoup plus couteuse que le fine-tuning supervisé sur de simples questions/réponses.

 

NOTRE POINT DE VUE

Privilégiez le prompt engineering d’un modèle puissant tel que GPT-4 au fine-tuning, notamment en phase de POC. Quand des limitations claires sont identifiées et qu’il devient nécessaire de s’adapter à de la donnée spécifique, faites le choix entre Retrieval Augmented Generation et le fine-tuning supervisé sur des questions/réponses. Dès la phase de POC, mettez votre outil à disposition d’utilisateurs tests et utilisez des outils comme LangSmith pour récolter les questions que posent les utilisateurs : une donnée précieuse pour préparer un dataset de fine-tuning.

 

Assess

23

LLM Open Source

Les modèles de langage à l’état de l’art sont historiquement open- source (jusqu’à BERT et GPT-2 en 2018/19), mais cela a changé avec GPT-3 (2020) dont les poids n’ont pas été publiés par OpenAI.

Pour le moment, les modèles closed-source (accessibles par API), notamment GPT- 4, restent bien plus performants que les alternatives open-source. Avec la sortie de Mixtral (8x7B) on atteint une performance légèrement supérieure à GPT 3.5, relançant le débat sur si les modèles open- source atteindront l’état de l’art dans les prochaines années.

Les modèles open-source offrent cependant plus de contrôle, ce qui a plusieurs avantages :

  • Disponibilité du modèle : avoir son propre modèle permet d’avoir le contrôle sur le serving et la charge, évitant latences et/ou downtimes sont parfois observés sur les APIs d’OpenAI; 

  • Flexibilité d’utilisation des tokens en sortie du modèle (e.g. avec Guidance (p.53) );

  • Efficience du modèle en quantité de calcul et en consommation énergétique en utilisant un petit modèle spécialisé plutôt qu’un gros modèle généraliste ;

  • Sécurité des données et propriété intellectuelle du modèle dans le cas de fine- tuning

    Les coûts sont aussi à prendre en compte : se servir d’un LLM open-source est relativement cher, comparé à l’utilisation d’un modèle API où l’on paie quelques centimes par call, surtout si l’utilisation est peu intense. Si la charge est suffisamment élevée, la tendance peut s’inverser. De plus, des outils comme vLLM viennent faciliter le serving et diminuer ses coûts.

     

    NOTRE POINT DE VUE

    Pour les organisations ayant les ressources et l’expertise nécessaires, l’adoption d’un LLM open source peut être une stratégie viable, offrant à la fois flexibilité et contrôle sur les modèles. Pour les applications nécessitant la plus haute fiabilité et les meilleures performances, GPT-4 (p.30) reste actuellement le meilleur choix. Plus généralement, pour un POC démontrant valeur produit et faisabilité technique, nous recommandons d’initier les projets avec un modèle à l’état de l’art, avant d’envisager des alternatives open- source.

Hold

24

Few-shot learning classique

Un problème classique pour entraîner des modèles de machine learning est de n’avoir qu’un faible nombre d’exemples annotés par classe. Le plus simple est d’annoter suffisamment de données, mais ce n’est pas toujours possible, pour des raisons de coût, de disponibilité de la data, ou lorsque les toutes les classes ne sont pas connues à l’avance.

Le Few-Shot Learning (FSL) est la branche du ML qui vise à apprendre de nouvelles tâches avec un petit nombre d’exemples d’entraînement. Quelques techniques classiques :

  • l’apprentissage de bonne représentation avec du metric learning : apprendre un espace de représentation dans lequel les exemples d’une même classe sont proches entre eux et éloignés de ceux des autres classes. Par exemple avec des réseaux siamois entrainés avec une fonction de coût contrastive, en montrant des exemples positifs (même classe) et négatifs (autre classe).
     
  • le meta-learning, une approche qui consiste à « apprendre à apprendre », c'est-à-dire apprendre à un algorithme à s’adapter rapidement à de nouvelles tâches avec peu d’exemples. Par exemple MAML où le modèle apprend une initialisation de poids rapide à fine-tuner pour de nouvelles tâches.
Ces techniques ont été remises en question : notamment l’article “A closer look at few-shot classification” montre que des performances au niveau de l’état de l’art peuvent être obtenues par un pré-entrainement supervisé de représentation puis un fine- tuning. De plus, l’arrivée d’une nouvelle génération de modèle

à la suite de la révolution des transformers à partir de 2019 a permis l’émergence de modèles proposant des représentations “universelles” d’une qualité suffisante pour la plupart des uses-cases.“universelles” d’une qualité suffisante pour la plupart des uses-cases.

 

NOTRE POINT DE VUE

Nous avons régulièrement utilisé des approches few- shot learning dans nos projets, dont les réseaux siamois et les entrainements contrastifs. Cependant, l’expressivité des représentations proposées par les modèles de fondation s’est améliorée : le travail sur la fin de la chaîne algorithmique (ex. : méthode de choix des représentants par classe ou métrique utilisée) devient suffisant. Nous recommandons donc de ne plus commencer par des approches visant à optimiser les représentations pour le few-shot.