Suite à l’annonce de la release de Gemini par Google cette semaine, et du bad-buzz qui a suivi sur la démo semi fakée du géant du numérique; il n’en reste pas moins que je suis surexcité quant à l’avènement de l’ère de la multimodalité (amorcée, entre autres, par GPT-4 Vision) dans le monde des foundation models, c’est-à-dire les modèles d’IA capables de réaliser des tâches dont le spectre est très général.
J’ai d’ailleurs hâte que Gemini soit disponible pour me faire une idée de ses capacités ! Que la com’ de Google ait été ratée n’est pas la question, toutes les entreprises majeures de la tech, la Recherche, ainsi que la communauté open-source, sont engagées dans une course effrénée vers l’AGI (Artificial General Intelligence), qui en effraie certains et en grisent d’autres (je fais partie de la 2ème catégorie). Le nouveau Graal est la multimodalité.
Ainsi, que les capacités du modèle soient un franc-succès ou pas, la démarche de créer un modèle multi-modal dans son architecture est le précurseur d’inventions extraordinaires à mon sens. Comme je l’ai répété à l’envi à mes collègues cette semaine, j’ai l’impression d’être comme le contemporain d’Edison ou de Tesla, qui découvrait, à l’époque des premières innovations électriques, avec des yeux ébahis, l’avènement d’un miracle technologique qui allait changer la face du Monde.
Cela dit, vous risquez peut-être être lassés du terme « multi-modal », répété à chaque paragraphe depuis le début de cet article, alors commençons par là !
Qu’est-ce que la multimodalité ?
Une modalité, pour un modèle d’IA, fait tout simplement référence au type de données passé en entrée au modèle; par exemple, GPT-4, était à ses débuts unimodal, c’est-à-dire qu’il n’était capable « que » de comprendre le texte entré en input par l’utilisateur pour pouvoir générer son output. Depuis une composante « Vision » a été donnée au modèle et il est devenu multimodal, c’est-à-dire que des données de plusieurs types (ici texte et images) peuvent lui être passées, on peut maintenant lui envoyer des images. C’est ce qui permet aujourd’hui la description de photos par GPT-4.
C’est pourquoi, vous le remarquerez dans le titre de cet article, je ne parle pas de LLM (Large Language Model) mais bien de LMM (Large Multimodal Model). Ce qui me fait penser que la release de Gemini pourrait bien être une date à marquer d’une pierre blanche dans l’évolution de l’IA, c’est que Google propose déjà une fonctionnalité d’embeddings multi-modaux accessible programmatiquement depuis les APIs du GCP.
Embeddings ? Hein ?
Commençons par le terme embedding: ce terme fait référence à une manière de représenter de la donnée sous la forme vectorielle. Si vous êtes comme moi, et que vous avez dormi pendant le cours de Math au lycée, un vecteur est tout simplement une manière de représenter des points et la direction qu’ils prennent dans un espace à n dimensions.
Par exemple, on va considérer sur un plan à deux dimensions deux vecteurs:
Ainsi, toute paire de coordonnées (x, y) peut être représentée de la manière suivante avec cette matrice:
Cela permet d’appliquer, par exemple, des transformations à des figures géométriques en utilisant leur représentation vectorielle.
Dans la transformation ci-dessus, qui justement n’en opère aucune (identity transformation), la 1ère colonne de la matrice répond à la question « quelle transformation veut-on appliquer à l’axe horizontal ? » et la deuxième à la question « quelle transformation souhaite-t-on appliquer à l’axe vertical ? » … Mais, Yacine, quel rapport avec les LMMs me direz-vous ?
Hé bien, très schématiquement, c’est comme ça qu’un LLM voit le monde: chaque donnée, de n’importe quelle nature, est transformée en des vecteurs de nombre sur des centaines de dimensions (pas juste en 2D ou 3D). Par exemple le modèle BERT représente du texte en 768 dimensions ! On peut donc établir pour chaque mot, image, etc. (référence à la nature de la modalité) une magnitude et une direction à l’item considéré.
Le nombre élevé de dimensions dans ces vecteurs permet de capturer des nuances entre les concepts: c’est ce qui permet d’établir des relations sémantiques dans un contexte textuel. TL;DR: les vecteurs issues de données textes (embeddings), permettent d’encoder finement une information sémantique, une unité de sens donc.
Dans le vecteur de mon déplacement si je devais représenter l’idée « j’ai marché 3 kilomètres en direction du nord-est », la magnitude serait la distance parcourue et la direction serait « le nord-est », c’est à dire un angle. Comme vous le verrez, cela a son importance.
Nous allons maintenant montrer un exemple de génération d’embeddings à partir de contenus textuels. Ce que vous devez retenir: les données, de toute nature, passées à une IA, sont transformées en vecteurs de nombres.
Vous avez ici des snippets de code que vous pourrez run chez vous pour tester le concept. Dans l’exemple fourni je teste les APIs IA de Google (Vertex AI) pour générer des embeddings, ou représentations vectorielles de données (ici du texte) =>
Dans cet exemple, j’envoie 2 phrases liées, dans leur contexte, à l’endpoint de génération d’embeddings de Vertex AI; vous remarquerez que la dernière n’a absolument rien à voir avec les deux premières, c’est voulu 😉.
J’affiche ensuite les cinq premières rangées de ces embeddings pour chaque texte, en input; ça donne les trois tableaux séparés par des virgules, que vous voyez ici =>
Ok super, mais à quoi ça sert ?
C’est là que la « magie » des LLMs (et maintenant LMMs) opère: un calcul de similarité est effectué entre ces vecteurs pour déterminer s’ils sont proches sémantiquement (rappelez-vous, ce sont des mots à la base). Pour cela les mathématiciens et leurs professeurs (envers qui je m’excuse du peu d’attention que je leur ai accordé) ont mis à notre disposition une trousse à outils contenant notamment:
- la distance euclidienne
- la similarité cosine
Ce n’est vraiment pas de la « rocket science », comme aime à le répéter un de mes collègues de la squad IA, et je vous invite à vous refaire une santé mathématique, si c’est encore flou pour vous, sur le site de Khan Academy, qui est très pédagogique à cet égard.
Ces deux outils ont une approche différente de cette appréciation de la similarité entre deux vecteurs: le 1er (Euclide) va se focaliser sur la distance entre les points, et l’autre sur l’angle (la direction, vs la magnitude) entre ces points.
En pratique, dans le machine learning, on va favoriser la similarité cosine car, dans ce type de calculs, la magnitude du vecteur aura moins d’importance que dans le calcul de distance euclidien => le fait que le texte soit plus ou moins long aura moins d’impact sur les relations sémantiques qui peuvent être faites sur le texte dans un cas que dans l’autre, ce qui un impact direct sur la performance du modèle considéré !
J’ai tenté de vous montrer cela, en continuant l’exemple commencé plus haut =>
Dans l’exemple utilisant la distance euclidienne, on voit que la distance entre les deux premiers textes est plus courte que celle entre le 1er et le 3ème textes. Dans l’autre exemple c’est l’inverse car la similarité cosine va ressortir un nombre compris entre -1 et 1, -1 représentant un caractère orthogonal dans la similarité entre les deux vecteurs.
Comment le modèle sait que « théâtre » et « Shakespeare » sont liés ?
Il n’y a rien de magique derrière cela, ce sont les données d’entraînement des modèles (un immense corpus pour les derniers modèles) et la manière dont elles ont été labellisées, dont a été conduit l’entraînement, etc. qui a permis d’établir ces relations.
Cela suscite l’admiration et, petit laïus, cela pousse aussi à vraiment se méfier de l’impact potentiellement négatif que peuvent avoir les biais lors de cette phase cruciale de l’entraînement du modèle. Par exemple, une IA xénophobe pourrait avoir été entraînée à systématiquement, de par ses données en entrées, associer une valeur négative (dans notre entendement) dès lors que la communauté A ou B est mentionnée. Ce sont des risques que chaque utilisateur et concepteur de solutions IA doivent connaître.
Ces phénomènes de renforcement de conceptions existent déjà naturellement dans les sociétés humaines, mais le caractère industrialisé et automatique, scalable, de leur renforcement, est, je pense, un défi de notre siècle.
Dans le cas un peu moins grave de notre exemple shakespearien, les embeddings liés au théâtre et à Shakespeare renvoient le résultat attendu car le corpus d’entraînement du modèle (ici PaLM2) a probablement reçu en entrée des textes de Shakespeare et des pièces de théâtre. Il est donc capable, en fonction du texte donnée en entrée, de situer une similarité entre ce que vous lui dites et ces domaines.
Les embeddings multi-modaux
Jusque là, l’application commerciale des embeddings et sa version API les plus plébiscités ont été celles d’OpenAI avec ChatGPT Plus et ses endpoints d’API permettant de générer des embeddings.
Mais, à l’heure actuelle, même si on peut obtenir des embeddings programmatiquement avec l’API d’Open AI, on ne peut pas créer d’embeddings multi-modaux, dans la mesure où OpenAI n’accepte que du texte.
Là où Google revient sur le devant de la scène dans la course à l’IA, failed demo ou pas, c’est qu’on peut d’ores et déjà créer ce type d’embeddings avec Vertex AI.
Attention, cette vidéo n’a rien à voir avec Gemini, le modèle multimodal, il s’agit « simplement » d’une fonctionnalité permettant d’effectuer très facilement des calculs de similarité entre des données de nature complètement différentes. Et ça c’est complètement ouf !
Applications pratiques des embeddings multimodaux
Le fait de pouvoir établir des relations de similarité entre des vecteurs issues de données textuelles, ou d’images, permettait déjà d’aider à réaliser plusieurs tâches, dont l’exécution autrefois plutôt algorithmique, a profondément changé depuis l’industrialisation des réseaux neuronaux:
- recherche sémantique, cas le plus connu => les moteurs de recherche
- systèmes de recommendation => « j’ai regardé le contenu x, alors on me propose le contenu y de par sa similarité sémantique »
- les sytèmes de question/réponse => une réponse est générée en situant le domaine de savoir, compris dans la question de l’utilisateur
- la publicité ciblée
- la reconnaissance d’images
- etc.
Le fait de pouvoir maintenant envoyer à la fois une image et un texte, par exemple, à un endpoint API d’embeddings pour récupérer ces vecteurs de nombres permet par exemple de faire une recherche de produit avec juste une photo 🤯 !
Comment ça marche ?
- on envoie l’information « produit A », avec sa description, etc. pour générer un embedding textuel classique
- on envoie, en plus, une ou des images associées à ce produit, qui renvoient également des embeddings
Là où, auparavant, il fallait gérer la relation entre deux espaces d’embeddings complètement différents soi-même, la prouesse technique réside dans le fait que ces similarités sont nativement supportées aujourd’hui entre des données de nature complètement différentes. Cela augmente de manière significative la performance de l’établissement de liens de similarités entre un texte et une image, une image et une autre image, etc. Et cela préfigure des capacités d’abstraction décuplées de la part de modèles, que ce soit Gemini ou autres, dans leur compréhension du monde.
Dans l’exemple du product search, cela signifie qu’il n’y a plus besoin d’associer explicitement une image à un label, le nombre de labels étant nécessairement limité, pour ensuite requêter une base de données permettant d’établir une relation de similarité entre le label de l’image (et non l’image en soi) et ce que vous avez demandé dans votre barre de recherche. On se retrouve dans un tout autre niveau de nuances où en envoyant une image en input, on peut obtenir avec une granularité bien plus précise des résultats plus pertinents sur deux modalités à la fois: le texte et l’image. Cela permet de ne pas se soucier de la labellisation des images, lorsque l’on créé son dataset de produits par exemple, mais de se focaliser juste sur « quelle image va avec quel produit? ».
Un exemple concret: je gère une boutique d’e-commerce, je veux que mes utilisateurs puissent très facilement trouver un produit de manière exacte, mais aussi des produits similaires et matchant le plus possible avec leur requête. En 2023, j’aurais constitué mon jeu de données, avec le titre du produit, sa description d’une part; et un jeu d’images d’autre part. J’aurais été obligé de concevoir, ou de fine-tune, deux IA différentes pour permettre la souplesse d’une recherche sans identifiant précis sur ma plateforme:
- un LLM entraîné sur ou ayant accès à ma base de produits
- un modèle de classification d’images entraîné à reconnaître des vélos, des casques, etc.
Le tout aurait donné un résultat pas toujours précis car l’utilisateur peut uploader la photo d’un vélo x et obtenir en première page de résultats un vélo y, qui n’est pas du tout le produit en question, le tout dépendant fortement du travail de labellisation des données (et vous n’avez pas toujours des centaines de vélos du même modèle à donner en input à une IA pour les différencier lors de l’entraînement).
En 2024, pour réaliser la même tâche:
- vous envoyez à un endpoint d’embeddings (Vertex AI et bientôt d’autres providers) votre contenu texte sur le produit en même temps qu’une seule ou plusieurs images
- vous enregistrez ces embeddings, pour chaque produit, dans une base de données de vecteurs
- … et c’est tout
Maintenant, quand l’utilisateur n’aura plus la ref du produit par exemple, il enverra une image et le produit exact sera instantanément trouvé sur le store. De même, s’il désire un produit mais veut le décrire avec ses propres mots, il n’a qu’à taper un texte approximatif dans la barre de recherche et les résultats seront beaucoup plus proches de la réalité que ceux émis d’une labellisation nécessairement limitée des données.
La scalabilité et la rapidité de l’établissement de relations entre des données différentes de par leur structure s’en trouvent décuplées. C’est ce que permet la finesse de l’encodage des données en vecteurs de nombres réels ! Et ça, ce n’est qu’un aperçu de ce que l’on peut faire… Je vous invite à regarder la vidéo de Google Next incluse dans cet article pour explorer les possibilités offertes par la démarche « embed everything » qu’utilise une société invitée à l’évènement pour parler de son use-case.
Enfin, le fait de:
- pouvoir stocker des embeddings multimodaux
- les rechercher rapidement pour de la similarité
… va permettre de stocker dans des bases de données sur le long terme des expériences utilisateur complètes sur plusieurs années: l’hyper personnalisation de l’UX d’un produit ne fait que commencer !
Voilà, j’ai tenté dans cet article une vulgarisation sur la multimodularité et les embeddings dans les réseaux neuronaux, n’hésitez pas à me proposer des éditions de ce texte ou à signaler des points qui vous paraîtraient flous en commentaire !
