Modèle d'apprentissage machine = algorithme + données

En IA classique, l’appellation modèle désigne un algorithme entraîné sur des données dans le but de réaliser un objectif prédictif bien spécifique en fonction du jeux de données source. Les types de prédiction peuvent être de différents ordres (régression, classification, clusterisation), les algorithmes à disposition sont multiples (supervisés ou non supervisés, géométriques ou probabilistes) mais la caractéristique principale est que le modèle créé en tant qu’association algorithme-dataset dépend fortement des données d’entraînement et n’est donc pas généralisable, autrement dit je ne peux pas passer le modèle que j’ai entraîné à mon voisin, sauf si ses données sont exactement structurées comme les miennes et si son objectif prédictif est strictement identique.

On retrouve cette adhérence exclusive entre algorithme et données dans les techniques de NLP classiques, dont l’enjeu est de trouver la manière la plus performante d’encoder des données textuelles afin d’en saisir la signification.

En passant, une évidence : quelles que soient les données de départ (numériques, qualitatives, textuelles), un algorithme ne peut travailler dessus que si elles sont converties en nombres, puisque par définition un algorithme est un processus calculatoire qui manipule des chiffres. Sur des datasets structurés contenant des données quantitatives et/ou qualitatives, cette conversion en dataset numérique relève de la phase de préparation des données généralement très chronophage et assez touchy (dans le sens où elle mobilise à la fois des compétences de data scientist et la connaissance métier des données afin de faire les bons choix).

Ce processus d’encodage (de conversion texte-chiffres pour rendre les données “machine-understandable“) puis de décodage (chiffres-texte pour restituer les calculs sous une forme “human-understandable”) constitue le coeur des technologies de Natural Language Processing (NLP) : en-dehors de méthode de comptage de type N-grams, les tâches de NLP s’appuient sur des algorithmes de création d’embeddings (“plongements lexicaux" en français) c’est-à dire de transformation de de mots en vecteurs numériques, qui aboutissent à représenter un texte entier en espace vectoriel multi-dimensionnel sur lequel des processus calculatoires peuvent être appliqués. Le degré de captation de la sémantique du texte dépend donc fortement de la méthode d’encodage utilisée : avant l’apparition des LLM, les types d’approche pour la création des embeddings allaient du “basique” bags of words au word embeddings word2vec de Google, et un des enjeux majeur de la recherche en NLP était justement de parvenir à encoder non pas seulement des mots mais des séquences de mots en vertu de principe de linguistique bien connu selon lequel le sens d'un mot découle autant de sa définition stricte que de son contexte.

Attention is all you need

Le papier Attention is all you need de 2017 est de ce point de vue fondateur et marque le saut technologique à la base des LLM : cet article présente des réseaux de neurones d’un nouveau type appelés “Transformers” (le T de GPT) capables d’encoder des séquences de mots entières selon le principe de “self-attention” qui prend en compte les positions mutuelles de chaque mot dans une séquence (y compris les mots vides) tout en le pondérant différemment selon la séquence (le contexte) et génère un encodage positionnel bidirectionnel du groupe de mot rendant ce type d’encodage apte à "comprendre" les associations grammaticales et capter la sémantique des associations de mots. En résumé, la rupture technologique induite par les réseaux de neurones de type Transformers a considérablement accru la capacité des modèles d'IA appliqués au NLP à décrypter la complexité grammaticale du langage naturel et capter le sens des mots en fonction de leur contexte par le biais d'encodages statistiques positionnels très performants. Pour tenter d'illustrer ce mécanisme interne d'encodage au coeur des réseaux de neurones de type Transformer, on peut utiliser la démo de l'outil interactif Language Model Transparency Tool développé par Meta et qui permet de retracer graphiquement la circulation de l'information entre chaque couche de neurones et de visualiser la contribution de chaque neurone au mécanisme d'attention.

Source : https://github.com/facebookresearch/llm-transparency-tool

De ce fait, en très peu de temps, les méthodes d'interaction programmatiques avec des données textuelles ont été complètement révolutionnées avec la mise à disposition des Large Language Models : de très gros modèles de langage à vocation généraliste et universelle car pré-entraînés (le P de GPT) sur des corpus de connaissances gigantesques avec des réseaux de neurones Transformers capables de convertir des milliards de tokens en espace multi-dimensionnel de vecteurs aux coordonnées sémantiques.

Spécifiquement en NLP, mais aussi de manière bien plus globale pour ce qui concerne l'extraction de données structurées à partir de données non structurées, les modes d'accès et d'utilisation des modèles sont donc complètement transformés : là où, après avoir entrainé et créé son modèle local, il fallait coder les scripts permettant l'exécution des commandes (faire le résumé d'un texte, détecter les entités nommées, extraire les topics…), il suffit maintenant de coder l'accès au LLM pré-entrainé de son choix, puis de passer ses instructions en langage naturel. La plupart du temps de plus, recourir aux LLM permet de s'affranchir des laborieuses contraintes de multi-linguisme puisque les LLM sont capables grâce à des dictionnaires de généraliser la compréhension de structures grammaticales et de passer d'une langue à l'autre entre langues de même origine (grammaticalement proches).

Interactions avec des LLM : l’inférence

Les LLM sont donc des espaces de mots représentés numériquement par embeddings (des espaces de vecteurs), prêts à l’emploi et généralisables pour un large panel de tâches en vertu de la masse de leur corpus d’entraînement. Ces espaces de très grande dimension dépassent nos capacités cognitives de représentation, mais on tout de même saisir à quoi ressemble un espace d'embeddings en utilisant des techniques de réduction dimensionnelle qui donnent ce genre de cartographie tridimensionnelle

Source : https://projector.tensorflow.org/

Faire de l’inférence sur des LLM consiste à interagir avec le modèle (ie exploiter les embeddings) afin d’exécuter l’opération fondamentale de l’IA : faire des prédictions, en l’occurrence ici générer du contenu (le G de GPT).

Que se passe-t-il donc quand on pose une question à un modèle de langage via une UI, un framework ou une console ? La question est convertie en embeddings, puis projetée dans l'espace vectoriel du modèle, le modèle génère ainsi la suite du contenu (la réponse, mot après mot dans une boucle rétroactive) en calculant les distances entre tous les vecteurs du voisinage de celui représentant le prompt et choisit le plus proche. C'est le fonctionnement de base des modèles dits de fondation, qui permet à l'algorithme de produire des phrases qui font sens grammaticalement.

On comprend également trois choses :

• que le choix de la méthode de calcul de la distance entre vecteurs a une forte influence sur le contenu généré (se baser sur la distance euclidienne ou la distance Manhattan ne retournera pas forcément le même mot le plus proche)
• comment se forme le phénomène dit des hallucinations parfois bien difficiles à détecter : à chaque interaction avec l'utilisateur, l'endroit de l'espace dans lequel est projetée la question se déplace, les nouveaux calculs de proximité sont opérés et la réponse peut "dériver" dans n'importe quel sens. Un peu comme le principe de sensibilité aux conditions initiales dans la théorie du chaos, où même dans un système déterministe une faible variation dans les valeurs de départ des variables (ici une question formulée légèrement différemment) peut rendre le modèle imprédictible…
• (qu'en l’état) une IA générative n’est pas une intelligence qui manipule des concepts avec une connaissance cognitive du monde qui l’entoure, mais une représentation numérique d’un certain contexte sur laquelle s’applique un dispositif calculatoire de proximité, bref juste un outil mathématique (un réseau de neurones) à aucun moment source d'informations fiables.

Se familiariser avec le monde des LLM

GPT a été beaucoup (trop) cité, mais uniquement en raison de son acronyme extrêmement bien choisi qui résume à lui seul l’essence même des LLM. Si GPT via sa variante conversationnelle ChatGPT est à l'origine de la vague de démocratisation de l’accès aux LLM et reste à ce jour l’étalon de mesure de la performance d’un LLM dans la plupart des benchmarks d’évaluation, OpenAI est loin d'avoir une position de monopole sur le "marché" des IA génératives.

D'un côté la guerre économique fait rage entre OpenAI, les GAFAM et une foultitude de nouveaux acteurs (xAI d'Elon Musk, Anthropic, AI21*...) à coup de nouveaux LLM la plupart payants à l'usage, de l'autre les avancées en IA générative aujourd'hui proviennent en grande partie d'une activité débridée dans l'éco-système collaboratif de l'open source et la tendance est clairement à l'ouverture des modèles ainsi qu'au développement d'outils libres et open source facilement appropriables par tout à chacun dans son environnement local et le respect de la confidentialité des données personnelles.

• AI21 est d'ailleurs en cheville avec Clarivate pour le développement de la nouvelle version dopée à l'IA de l'outil de découverte Primo d'Exlibris

HuggingFace

La plateforme phare pour le stockage et la diffusion de modèles d’IA est HuggingFace, dont d’ailleurs le périmètre dépasse de plus en plus celui de simple entrepôt de modèle et de datasets en fournissant des services associés tels que des environnements d’exécution d’applications Streamlit ou Gradio, des endpoints d’inférence, des services de déploiements de modèles sur GPU dans le cloud….

Quoi qu’il en soit HuggingFace se positionne comme le pendant de Github dans le domaine des modèles d’apprentissage machine en général et d’IA génératives en particulier, en permettant le stockage, le versioning, la documentation et le partage de modèles et données d’entraînement : chaque modèle est décrit et téléchargeable dans ses diverses versions depuis une notice qui peut être plus ou moins riche et normalisée selon le contributeur et donne des éléments tels que son auteur, sa description, les consignes de syntaxe pour les prompts, les paramètres principaux (fenêtre de contexte…), l’architecture du réseau de neurone, des exemples de code, le compatibilité avec des clients ou outils standards… avec bien sûr dans l’esprit collaboratif la possibilité de proposer des pull requests ou des issues

Comment évaluer l’ouverture d’un modèle ?

On trouve donc sur HuggingFace à peu près tous les modèles à partir du moment où ils sont ouverts, sachant que cette notion d’ouverture appliquée aux modèles d’IA génératives, si elle fondamentale pour pouvoir exécuter des LLM localement, n’est pas binaire mais plutôt étalée sur une échelle graduelle rendant délicate l’appellation open-source appliquée aux LLM

• open weights : les poids dont il est question sont les poids de chaque neurone du réseau de neurones utilisé par le modèle lors de son pré-entraînement. La plupart du temps un modèle est dit open source alors qu’il est “seulement” open weights, c’est-à dire que seuls les paramètres de son pré-entraînement sont accessibles, sachant que les possibilités de réutilisation dépendent aussi des éventuelles conditions restrictives qui leur sont associées (usage commercial, droits de modification etc…). Néanmoins la mise à disposition des poids du modèle est la condition nécessaire et suffisante pour faire de l’inférence ou du fine-tuning à partir du modèle.
• open source : un modèle complètement ouvert expose les données d’entraînement, l’architecture du réseau de neurones et ses hyper-paramètres, le code source du processus d’entraînement, et toute la documentation nécessaire.
• entre ces deux statuts toutes les modalités d’exposition sont possibles

Paramètres

Modèle à 7 billions de paramètres à 3 trillions de paramètres... Le nombre de paramètres représente en général l'information de base associée à un modèle, car elle donne une idée de sa taille. En réalité les paramètres d'un LLM (d'un réseau de neurone de type Transformer) sont similaires aux poids d'un réseau de neurones standard, c'est-à dire à des valeurs numériques qui sont initialisées aléatoirement puis ajustées au fur et à mesure de l'entraînement du modèle pour minimiser la perte. Les poids et les biais définissent les connections entre (et les activations de) neurones qui elles même déterminent le comportement du modèle.

Quantization

Sur HuggingFace on trouve donc tous les modèles à minima open weight, et parfois leur version quantizée : la quantization est une technique de réduction de la taille du réseau de neurones d’un modèle en modifiant la précision de ses poids afin de réduire la RAM nécessaire à son exécution.

Plus les poids sont stockés de manière précise (le plus précisément correspondant à un modèle 32 bits, soit des paramètres de type Float(32)), plus le modèle est performant mais plus il nécessite de la puissance de calcul (de la RAM). A l’inverse, en abaissant le nombre de bits requis pour chaque poids (en passant à des paramètres de type Float(16), Float(8) etc...), le temps de calcul diminue mais au prix d’une précision moindre de l’output du modèle.

Pour fixer sur quelques données, le coût du fine-tuning en mémoire GPU d'un modèle 32 bits est de 4GB par billion de paramètres (ce qui représente 280GB de GPU pour le modèle Llama2 à 70 billions de paramètres), et tombe à 1GB pour le même modèle quantizé en 8 bits.

Choisir un modèle dans un format quantizé revient donc à arbitrer entre la taille du modèle et la RAM nécessaire versus sa performance, sachant qu’en général plusieurs niveaux de compression sont proposés

Source : https://huggingface.co/TheBloke/Llama-2-7B-Chat-GGUF

Concrètement, et ce jour en terme de formats, la quantization des modèles se traduit par leur diffusion au format .ggml ou .gguf, ce qui a dans une large mesure démocratisé la libre réutilisation des modèles d’IA en rendant possible leur stockage sur un PC classique et l’exécution d’inférence sur du CPU. A noter que sur HuggingFace les modèles disponibles en version quantizés le sont quasiment tous dans l’espace de TheBloke

Source : https://huggingface.co/TheBloke

Modèles de base et variantes

En explorant HuggigFace on constate que plusieurs variantes sont potentiellement disponibles pour un même modèle : en effet un modèle peut être livré dans sa version de base en plusieurs tailles donc, ainsi que dans des versions affinées (fine-tunées) pour un usage spécifique. Généralement ces différentes versions sont reconnaissables via le nommage du modèle qui comprend d'une part un suffixe caractérisant le nombre de paramètres ("-2b", "-7b", "-70b"...) et d'autre part un suffixe “-chat” ou “-instruct”, chacune d'entre elles peuvant évidemment faire aussi l’objet de quantization multiples.

Fine-tuning

Le fine-tuning consiste à compenser le manque de performance d’un modèle dans certains domaines de connaissances ou pour réaliser certains types de tâches en complétant son entraînement avec des données spécifiques. Par exemple, le chatbot ChatGPT que nous utilisons ne repose pas sur le modèle GPT de base mais sur sa variante conversationnelle ChatGPT qui est une version fine-tunée de GPT avec des jeux de données de conversation pour lui “apprendre” à interagir de manière conversationnelle. Les deux suffixes les plus courants -chat et -instruct indiquent donc des modèles spécialisés pour tenir une conversation ou suivre des instructions bien précises. Il est évidemment possible de fine-tuner soi-même localement un modèle existant selon ses besoins, et c'est bien aussi tout l'enjeu de l'ouverture des modèles d'IA, tout en notant que ce type de "sur-entrainement", en modifiant les poids du modèle, peut s'avérer long et coûteux en terme de ressources.

Fenêtre de contexte (context window)

La fenêtre de contexte d'un LLM désigne le nombre de tokens que le modèle accepte en input pour la génération de contenus, c’est-à dire le périmètre de texte que le LLM “voit” pour créer une réponse, encore autrement dit le sous-ensemble de l’espace vectoriel dans lequel sont effectués les calculs de distance entre vecteurs sémantiques. La taille de la fenêtre de contexte est un enjeu technique et “marketing” important pour la performance d’un modèle, et on remarque d’ailleurs que la tendance est à l’augmentation constante de ce périmètre : en effet, plus la fenêtre de contexte est grande et plus le modèle est capable de prendre en considération un nombre élevé de tokens pour une réponse de meilleure qualité, mais plus aussi le nombre d’opérations calculatoires des distances augmente de manière quadratique, impactant potentiellement le temps de latence de la génération et/ou l'infrastructure matérielle nécessaire pour faire tourner le modèle.