EmbeddingGemma 2 étend la recherche sémantique aux images, à l’audio et à la vidéo

Un modèle multimodal pour retrouver du contenu

Google a présenté EmbeddingGemma 2 comme une extension multimodale de son précédent modèle d’embeddings textuels. Cette nouvelle version représente le texte — y compris le code —, les images, l’audio et la vidéo dans un espace vectoriel partagé. Elle sert à retrouver des contenus liés à une requête ; ce n’est pas un modèle conversationnel conçu pour rédiger des réponses ou générer des images, de l’audio ou de la vidéo.

Le modèle compte 740 millions de paramètres et associe un composant textuel à des encodeurs de vision et d’audio qui peuvent être chargés séparément. Google indique que le composant textuel compte 270 millions de paramètres, l’encodeur de vision 170 millions et celui d’audio 300 millions. La configuration activée est importante pour estimer les ressources : une implémentation limitée au texte ne charge pas nécessairement tous les composants du modèle multimodal.

EmbeddingGemma 2 produit des vecteurs de 768 dimensions et permet de les réduire à 512, 256 ou 128 dimensions grâce à l’apprentissage de représentations Matryoshka. Des vecteurs plus courts peuvent réduire le stockage et accélérer certaines recherches, mais la qualité varie selon la dimension et la tâche. Après la troncature, il faut normaliser le vecteur pour le comparer avec la similarité cosinus ; les requêtes et les documents de l’index doivent également avoir la même dimension.

Google distribue le modèle sous licence Apache 2.0. Cette licence ne supprime pas les coûts d’exécution et ne détermine pas, à elle seule, les obligations liées aux données d’une application. La fiche technique indique une fenêtre de contexte commune de 8 192 tokens pour les différentes modalités ; la limite effective dépend de la façon dont les entrées sont combinées et préparées.

Comment fonctionne la recherche multimodale

Un embedding est une représentation numérique d’un élément, comme une phrase, une image ou un extrait audio. Le système compare les vecteurs pour classer des résultats possibles selon leur similarité. Dans une recherche de documents, par exemple, une requête sur des « chaussures pour la pluie » pourrait faire ressortir une fiche de bottes imperméables, même si elle ne contient pas exactement le mot « pluie ». Il s’agit d’un résultat candidat, et non de la preuve que le modèle a compris l’usage prévu ou que la fiche est exacte.

EmbeddingGemma 2 permet de rechercher dans plusieurs modalités lorsque l’application prépare les données à cette fin : une requête textuelle peut ainsi être mise en relation avec les images d’un catalogue. Le modèle accepte également des entrées combinant texte et médias. Pour représenter un produit, une application peut inclure sa description et ses images ; pour une requête vidéo, elle peut fournir le texte de recherche et les images extraites des séquences selon la configuration retenue.

Les préfixes de tâche orientent les représentations textuelles. Dans une recherche asymétrique, la requête et les documents remplissent des rôles différents : la requête est préparée comme une demande de recherche, et les éléments du corpus comme des documents. Pour une tâche symétrique, comme le regroupement de textes ou la mesure de similarité entre phrases, les éléments comparés reçoivent le même type d’instruction. Ces préfixes s’appliquent au texte, pas aux images, à l’audio ou à la vidéo.

La configuration des entrées influe aussi sur la quantité de contenu qui tient dans la fenêtre de contexte. La fiche technique prévoit un budget commun aux différentes modalités ; combiner texte, images, audio et vidéo réduit donc la place disponible pour chacune. Pour la vidéo, l’échantillonnage des images et sa fréquence déterminent les informations représentées. Pour l’audio, le format indiqué est mono, à 16 kHz. Ces paramètres décrivent le traitement ; ils ne garantissent pas que tous les détails pertinents seront retrouvés.

Taille, contexte et configuration locale

Les 740 millions de paramètres correspondent à l’ensemble multimodal. Selon la fiche technique, la configuration texte seul utilise 270 millions de paramètres, la configuration texte et image 440 millions, la configuration texte et audio 570 millions, et le modèle complet 740 millions. Ces chiffres décrivent les configurations de chargement publiées, pas la consommation totale de mémoire d’une application en fonctionnement.

La taille des poids et l’utilisation de la mémoire dépendent de plusieurs facteurs, notamment la précision numérique, la bibliothèque, le matériel, la longueur des entrées et la taille des lots. Google recommande bfloat16 lorsque le matériel le prend en charge, et float32 dans les autres cas ; la fiche déconseille float16, qui peut produire des valeurs invalides ou des embeddings dégradés. Le nombre de paramètres ne suffit donc pas à estimer la mémoire nécessaire ou la latence d’un déploiement précis.

La réduction Matryoshka permet de choisir des vecteurs de 768, 512, 256 ou 128 dimensions. Dans les résultats publiés par Google, le passage de 768 à 256 dimensions divise par trois la taille des vecteurs et modifie plusieurs scores de benchmark. À 128 dimensions, certains scores multimodaux baissent davantage. Ces résultats correspondent aux tests et aux métriques indiqués par le fournisseur ; ils ne déterminent pas la dimension la plus adaptée à un corpus ou à une application donnée.

Pour utiliser des vecteurs tronqués avec la similarité cosinus, il faut les normaliser après la troncature. Le vecteur d’une requête et ceux des éléments indexés doivent avoir la même dimension. Changer de dimension implique de régénérer ou d’adapter l’index de manière cohérente ; comparer directement un vecteur de 768 dimensions à un vecteur de 128 dimensions n’est pas valide.

Comment évaluer la qualité de la recherche

Une comparaison utile commence par une tâche précise et un critère de pertinence défini avant le test. Un benchmark peut mesurer la recherche sur un jeu de données particulier, mais ne garantit pas le même résultat dans une autre langue, un autre domaine ou un autre type de contenu. La fiche technique de Google publie des scores pour différents tests portant sur le texte, le code, les images, les documents visuels, la vidéo et l’audio. Chaque score correspond à une métrique et à un jeu d’évaluation déterminés.

Pour évaluer une recherche texte-image, préparez des requêtes réelles et un ensemble d’images avec des critères de pertinence. Pour l’audio et la vidéo, définissez ce qui constitue un résultat pertinent : un enregistrement complet, un segment ou une image. Si le système combine plusieurs modalités, précisez la préparation et la pondération des entrées avant d’interpréter les métriques.

Comparez le modèle à une solution de référence en utilisant les mêmes requêtes, le même corpus, les mêmes instructions, la même dimension de vecteur et les mêmes règles de classement. Mesurez séparément la qualité de la recherche, la latence et les ressources utilisées. Notez la précision numérique, le matériel, la longueur des entrées et la configuration des modalités afin de pouvoir interpréter et reproduire le résultat.

L’évaluation doit couvrir les langues et les conditions d’utilisation prévues. La documentation du modèle indique que les performances peuvent varier d’une langue à l’autre et être affectées par les ambiguïtés et les nuances du langage. Un score agrégé ne remplace pas la vérification des requêtes que l’application recevra réellement.

Ce que montrent les résultats et leurs limites

Google publie des résultats issus de plusieurs benchmarks et compare certaines tâches textuelles à EmbeddingGemma, le modèle précédent. Pour MTEB multilingue, le score publié pour EmbeddingGemma 2 est de 61,36, contre 61,15 pour le modèle précédent ; pour le test de code MTEB, il est de 78,68, contre 68,76. Ces écarts décrivent les résultats rapportés pour les tests concernés. Ils ne garantissent pas une amélioration dans tous les systèmes de recherche.

La fiche présente aussi des résultats pour les images, les documents visuels, la vidéo et l’audio. Ces chiffres proviennent de benchmarks précis et ne prouvent pas que le modèle comprenne de façon générale une scène, une conversation ou un événement. Qu’une recherche place une vidéo pertinente parmi les premiers résultats ne signifie pas que le système identifie tous les faits qu’elle contient, réponde exactement à des questions ouvertes ou explique pourquoi cette vidéo est pertinente.

Le modèle génère des représentations, pas des réponses conversationnelles. Une application peut utiliser les résultats trouvés comme contexte pour un autre composant génératif, mais la qualité finale dépendra aussi de ce composant, du corpus et des règles de l’application. Il convient d’évaluer séparément la recherche et la réponse produite ensuite.

Google indique qu’EmbeddingGemma 2 est distribué sous licence Apache 2.0 et que ses poids sont ouverts. La fiche technique précise que les modèles d’embeddings ne bénéficient pas d’un ajustement de sécurité après entraînement ni d’une modération des sorties comme les modèles génératifs. Les mesures de protection de l’application, telles que les filtres de recherche et les tests d’équité, relèvent des personnes qui la déploient. Une licence ouverte ne transforme pas une recherche en vérification des faits et ne dispense pas d’examiner les biais, la confidentialité et les usages prévus.

Poursuivre l’exploration

Corrections et transparence

Si vous repérez une information incorrecte ou obsolète, envoyez-nous la page et la source à vérifier.