Entraîner son propre modèle d'embedding : guide d'affinage d'Embedding Gemma 2

Un modèle d'embedding prêt à l'emploi connaît bien les données générales, mais il ignore vos documents, vos noms de produits et les sons qui comptent pour votre application. Embedding Gemma 2 se distingue précisément sur ce terrain : ouvert par Google sous licence Apache 2.0, il réunit texte, images, audio et vidéo dans un seul espace partagé à 768 dimensions . Selon la fiche publiée sur HuggingFace, le système totalise 740 millions de paramètres , avec une variante texte légère de 270 millions quand elle suffit. L'animateur commence par une démonstration en direct : une version affinée sur des paires question-passage tirées de ses propres enregistrements de chaîne répond à une question en renvoyant le moment exact, avec un horodatage cliquable. La question posée est nette : quelques minutes d'affinage rendent-elles le modèle nettement meilleur sur vos propres données, sans casser ce qu'il sait déjà faire ?

L'affinage n'a pas le même sens pour un modèle d'embedding que pour un grand modèle de langage. Avec un modèle de langage, on montre l'entrée et le texte exact à reproduire : les données d'entraînement contiennent déjà la bonne réponse mot pour mot. Un modèle d'embedding n'écrit rien : il convertit une entrée en liste de nombres, qui n'ont de sens que les uns par rapport aux autres. Ce réseau de relations s'appelle l' espace d'embedding , et il n'existe pas une liste correcte unique à consigner comme cible. Tout ce qu'on peut dire au modèle, c'est quels éléments doivent finir proches les uns des autres. La documentation Google pour développeurs cadre l'affinage exactement ainsi : combler l'écart entre compréhension générale et précision propre au domaine. Comprendre cette différence compte, car la forme des données d'entraînement en découle.

Paires et négatifs intra-lot

Les données d'entraînement se composent de paires question-passage réponse. L'animateur l'explique avec un service d'assistance pour maison connectée : chaque exemple associe une question de client au passage du centre d'aide qui y répond. Ni scores, ni mauvaises réponses étiquetées : on collecte seulement des questions avec les passages qui leur appartiennent. Cette simplicité fait l'attrait de la méthode, car la préparation des données ne devient jamais un projet d'étiquetage de plusieurs semaines. Vos documents existants et les vraies questions des utilisateurs suffisent le plus souvent. L'essentiel est que les paires soient propres et que chaque question trouve vraiment sa réponse dans son passage.

Rapprocher chaque question de son passage ne suffit pas, car le modèle pourrait entasser toutes les entrées au même endroit tout en obtenant un bon score. La parade consiste à entraîner par lots : dans un lot de 32 paires, chaque question considère son propre passage comme la bonne réponse et tous les autres passages du lot comme faux. Chaque étape fournit ainsi une abondance de contre-exemples gratuits, sans en étiqueter un seul. L'animateur y voit un examen à choix multiples où les autres paires du lot servent d'options fausses toutes prêtes. Dans la documentation SBERT, cette approche porte le nom de Multiple Negatives Ranking , et c'est la même idée qu'OpenAI avec CLIP pour réunir images et textes dans un seul espace. Tirer les négatifs de la structure du lot plutôt que les collecter à la main, voilà ce qui rend la méthode si pratique.

L'astuce a un prix : si le même texte de réponse figure deux fois dans un lot, la fonction de perte enseigne au modèle que la bonne réponse est fausse. Deux clients posant la même question sur une procédure de réinitialisation, tombant dans le même lot, repoussent la première question loin de son passage correct. La correction passe par un échantillonneur qui ne place jamais deux fois le même texte dans un lot, appelé dans l'écosystème SBERT échantillonneur sans doublons . Cela ressemble à un détail, mais avec des données répétitives, il fausse silencieusement tout l'entraînement. L'animateur insiste à dessein : c'est un défaut d'organisation des données, pas d'étiquetage, et aucune courbe de perte ne le révèle.

Format de prompt, LoRA et mesure

Le deuxième point à régler est la discipline de prompt. Embedding Gemma 2 attend une courte consigne de tâche devant la requête de recherche et un format titre-plus-texte pour les documents : le format utilisé à l'entraînement est donc celui que le code de recherche devra employer. L'animateur compare cela à la discipline des gabarits de prompt pour les modèles de langage : les gabarits d'entraînement et de production doivent coïncider exactement. Changer le format après coup invalide dans la nouvelle présentation les relations de proximité chèrement apprises. C'est pourquoi il faut verrouiller le gabarit de production avant même de préparer les données.

La partie la plus intéressante concerne ce qui est vraiment entraîné. Au lieu de mettre à jour tous les poids, les essais utilisent LoRA : de petites matrices entraînables ajoutées à côté des couches figées, sans toucher aux poids d'origine. Dans les essais présentés, cela représentait moins de 2 % des poids, si bien qu'un petit fichier d'adaptateur suffit au lieu d'une copie complète du modèle. Le guide GoogleBlog pour développeurs met en avant la même conception modulaire, avec des encodeurs de texte, de vision et d'audio chargeables à la demande. L'annonce du blog Google va dans le même sens : un modèle à faible latence qui tourne sur du matériel grand public. Le tronc commun comporte pourtant un risque : texte, images, vidéo et audio traversent la même colonne, donc entraîner sur l'audio modifie aussi la partie qui traite les photos et le texte. Ce prix doit être mesuré à part.

Le dernier principe touche à la mesure. La baisse de la perte d'entraînement montre seulement que le modèle s'est amélioré sur les exemples vus ; la vraie question est la qualité de recherche sur des questions jamais vues, faute de quoi le résultat relève du par cœur plutôt que de la capacité. On met donc de côté un jeu de test, découpé par source : si des passages d'un même article figurent à la fois dans l'entraînement et dans le test, le modèle a déjà vu la réponse. Le bon découpage se fait par article, par vidéo ou par enregistrement. Ce dispositif répond aussi à une seconde question : le modèle a-t-il acquis une écoute ou une compréhension générale, ou seulement les étiquettes fournies ? L'animateur construit ses deux expériences autour de cette question.

Deux petites études et trois règles

La première étude vise le point faible de la vidéo précédente : les sons du quotidien. La collection ESC50 rassemble de courts extraits de 50 sons courants comme les aboiements, la pluie ou la tronçonneuse, et sa page GitHub recense 2000 enregistrements en 50 classes. Chaque nom de son devient une phrase, ce qui transforme la classification en recherche : le modèle plonge l'extrait et la phrase d'étiquette, puis retient la plus proche. Avant l'entraînement, le modèle ne plaçait le bon son en premier qu'une fois sur quatre, soit environ 25 % de précision. Les paires phrase-clips audio ont ensuite été entraînées pendant sept minutes et demie sur un accélérateur A100. Sur des extraits inédits, la précision du premier rang est passée d'une fois sur quatre à environ deux sur trois, et des sons comme le brossage de dents sont devenus reconnaissables presque à chaque fois. Puis l'animateur a entièrement caché 10 sons de l'entraînement : les sons entraînés progressaient comme avant, les sons cachés pas du tout. Le modèle avait appris les étiquettes fournies, pas l'écoute en général. Côté coût, la recherche de photos et de voix n'a pas bougé tandis que la recherche de texte général reculait d'environ 4 points . Un piège d'ingénierie est aussi apparu : le premier contrôle s'était effondré vers zéro, non à cause de l'adaptateur mais du processeur enregistré avec lui, qui taillait chaque extrait en millisecondes. Une correction d'une ligne, réutilisant le processeur du modèle de base, a tout réglé. La leçon est claire : après avoir enregistré puis rechargé un adaptateur audio, mesurez à nouveau la performance.

La seconde étude reprend la démonstration d'ouverture : l'animateur a découpé les relevés écrits de 120 de ses vidéos en courts passages. Sans questions associées, il a demandé à un modèle Gemini de rédiger une question de spectateur par passage, produisant exactement les paires question-passage réponse attendues par la théorie. Le découpage s'est fait par vidéo, si bien que les questions de test venaient de vidéos jamais vues à l'entraînement. Avant l'entraînement, le bon passage revenait premier environ deux fois sur trois ; après moins de trois minutes d'entraînement, ce taux montait à trois sur quatre. Le coût en texte général se répétait à environ 4 points. Le verdict est à double tranchant : quelques minutes d'affinage ont nettement amélioré le modèle sur ses propres sons et vidéos, mais il a appris des étiquettes plutôt que des capacités générales, en cédant quelques points de recherche textuelle générale. L'animateur en tire trois règles : convertir vos données en paires en tenant les doublons hors des lots, tester sur des données inédites découpées par source, et vérifier ce qui a changé d'autre après l'entraînement, puisque toutes les modalités partagent la colonne.