Google unifie la recherche multimodale avec EmbeddingGemma 2, un modèle léger exécuté sur l'appareil

Google a publié EmbeddingGemma 2, un modèle open source conçu pour gérer la recherche de texte, de code, d'images, de vidéos et d'audio au sein d'un même framework léger. Publié le 6 octobre 2026, ce modèle de 740 millions de paramètres permet aux développeurs d'exécuter des tâches complexes de récupération directement sur les appareils mobiles, sans dépendre d'une infrastructure cloud ni d'étapes de prétraitement lourdes comme la transcription.

Ce qui s'est passé

Le nouveau modèle mappe cinq types d'entrées distincts dans un espace vectoriel partagé de 768 dimensions. Cette architecture élimine la nécessité de générer des légendes textuelles pour les images ou des transcriptions pour les fichiers audio avant qu'ils ne puissent être recherchés. Lors de tests internes sur un Pixel 11 Pro, le modèle entièrement quantifié consommait environ 567 Mo de RAM active. Google a publié les poids du modèle sous licence Apache 2.0, les rendant disponibles gratuitement pour un usage commercial et privé. Les outils de déploiement sont déjà accessibles via LiteRT et MediaPipe Tasks, avec une intégration Android ML Kit dotée d'une accélération NPU attendue dans les prochaines semaines.

Une caractéristique architecturale clé est sa modularité. Les développeurs n'ont pas besoin de charger l'intégralité du modèle de 740 millions de paramètres si leur application ne requiert que certains types de données. L'encodeur de base pour le texte et le code utilise 270 millions de paramètres et occupe environ 191 Mo de RAM. L'ajout de l'encodeur de vision pour les images et la vidéo porte le nombre à 440 millions de paramètres, tandis que l'ajout de l'encodeur audio le porte à 570 millions. Le chargement de tous les encodeurs résulte en la totalité du nombre de paramètres. Comme chaque configuration projette dans le même espace d'embedding, les équipes peuvent commencer avec un index texte uniquement et ajouter des capacités image ou audio plus tard sans ré-encoder les données existantes.

Détails clés

• Le modèle prend en charge une fenêtre de contexte de 8 192 jetons, contre 2 048 dans la version précédente, lui permettant de traiter jusqu'à 5,5 minutes d'audio, 29 images ou 58 images vidéo en une seule entrée.
• Le traitement vidéo échantillonne par défaut une image par seconde, ce qui signifie que la limite de 58 images couvre moins d'une minute de métrage.
• Google a entraîné le modèle en utilisant l'apprentissage de représentation Matryoshka, qui permet de tronquer les embeddings à 512, 256 ou 128 dimensions sans réentraînement.
• La troncature à 256 dimensions réduit un index d'un million de vecteurs d'environ 1,5 Go à 500 Mo tout en conservant la majeure partie de la qualité pour le texte et le code, et environ 95 % de la qualité pour la récupération multimodale.
• À 128 dimensions, la qualité de récupération tombe à environ 90 % pour le texte et le code, et à environ 75 % pour les images, la vidéo et la parole, nécessitant des tests rigoureux avant le déploiement.
• Le modèle a atteint un score MTEB Code de 78,68, une amélioration significative par rapport au score de 68,76 de l'EmbeddingGemma original.

Contexte

Les systèmes de Génération Augmentée par Récupération (RAG) reposent généralement sur des modèles d'embedding pour convertir les données en vecteurs numériques représentant la signification sémantique. Traditionnellement, la gestion de différents types de médias nécessitait des pipelines séparés : reconnaissance optique de caractères pour les images, reconnaissance automatique de la parole pour l'audio et tokenisation standard pour le texte. Ces étapes intermédiaires ajoutent de la latence, des coûts et des points de défaillance potentiels. Les modèles d'embedding mappent ces entrées dans un espace vectoriel de haute dimension où les concepts similaires sont situés près les uns des autres, permettant aux moteurs de recherche de trouver des informations pertinentes basées sur le sens plutôt que sur de simples correspondances de mots-clés.

L'apprentissage de représentation Matryoshka est une technique qui répond à la charge de stockage de ces vecteurs. En entraînant le modèle à maintenir des informations utiles même lorsque les dimensions du vecteur sont réduites, il permet aux développeurs de troquer une petite perte de précision de récupération contre des économies significatives en stockage et en utilisation mémoire. Ceci est particulièrement critique pour les périphériques edge comme les smartphones ou les serveurs locaux, où les ressources sont contraintes par rapport aux centres de données cloud.

Pourquoi c'est important

Pour les équipes gérant des logiciels auto-hébergés, cette développement réduit la complexité de la construction de fonctionnalités de recherche multimodale. Auparavant, créer un système capable de rechercher dans des enregistrements de réunions, des documents scannés et des dépôts de code nécessitait de maintenir plusieurs modèles spécialisés et services de prétraitement. EmbeddingGemma 2 consolide ceux-ci en une seule dépendance. La capacité de charger uniquement les encodeurs nécessaires signifie qu'un portail de documentation pourrait n'avoir besoin que de l'encodeur texte, gardant son empreinte mémoire minimale, tandis qu'un outil de gestion d'actifs médiatiques pourrait activer l'encodeur de vision sans changer le schéma de la base de données sous-jacente.

Les gains d'efficacité impactent également le fonctionnement des agents locaux. En utilisant le modèle pour des tâches de classification via MediaPipe Decision, les applications peuvent évaluer des centaines d'options en millisecondes sans invoquer un grand modèle de langage. Cela empêche la consommation inutile de jetons et réduit la latence dans les boucles de prise de décision. Pour les responsables IT soucieux de la confidentialité des données, la capacité d'effectuer tout l'indexing et la recherche sur l'appareil garantit que les données audio ou visuelles sensibles ne quittent jamais l'environnement local, s'alignant ainsi sur des exigences strictes de conformité.

Ce que vous pouvez faire

• Évaluez vos pipelines RAG actuels pour identifier si les étapes de prétraitement séparées pour l'audio ou les images peuvent être remplacées par un embedding direct avec EmbeddingGemma 2.
• Testez les encodeurs modulaires pour déterminer si votre application peut fonctionner avec uniquement la base texte et code, économisant près de 300 Mo de RAM par rapport au modèle complet.
• Expérimentez avec la troncature Matryoshka à 256 dimensions pour réduire les coûts de stockage d'index, en vérifiant que la baisse de 5 % de la qualité de récupération multimodale est acceptable pour votre cas d'utilisation.
• Préparez-vous pour l'intégration Android ML Kit à venir si vous développez des applications mobiles, en vous assurant que votre matériel supporte l'accélération NPU pour des performances optimales.
• Envisagez d'utiliser le modèle pour des tâches de classification dans les workflows d'agents afin de réduire la dépendance aux grands modèles génératifs pour les étapes simples de prise de décision.
• Examinez les termes de la licence Apache 2.0 pour confirmer la conformité avec les politiques d'utilisation open source de votre organisation avant d'intégrer les poids dans des systèmes de production.