Une note vocale, trois photos et un extrait vidéo dorment sur un téléphone. Une phrase tapée au clavier suffit à retrouver celui qui parle du bon sujet, sans qu’un seul octet parte vers un serveur. Google DeepMind vient de publier le modèle qui rend ce scénario réaliste : EmbeddingGemma 2.
Un modèle d’embedding transforme un contenu en vecteur, une longue liste de nombres, de sorte que deux contenus de sens proche reçoivent des vecteurs voisins. C’est la brique qui fait tourner la recherche sémantique et le RAG (retrieval augmented generation, la génération appuyée sur des documents retrouvés).
Un même espace pour le texte, l’image, le son et la vidéo
La première version, sortie l’an dernier, ne traitait que le texte et a dépassé 20 millions de téléchargements, d’après Google. La seconde s’appuie sur l’architecture de Gemma 4 et place texte, code, images, audio et vidéo dans un seul espace d’embedding. Un mémo vocal peut ainsi servir de requête pour retrouver un extrait vidéo, ou l’inverse.
Le modèle est modulaire. Le socle texte pèse 270 millions de paramètres, un encodeur de vision en ajoute 170 millions et un encodeur audio 300 millions : l’addition donne les 740 millions annoncés. Une application qui n’indexe que du texte ne charge donc que le premier bloc.
La fenêtre de contexte passe à 8 000 tokens, quatre fois plus que la première version. Cela représente jusqu’à 5,5 minutes d’audio, 29 images ou 58 images d’une vidéo, ou une combinaison de ces éléments. Le modèle est publié sous licence Apache 2.0, avec des poids disponibles sur Hugging Face et Kaggle.
191 Mo pour le texte seul, 567 Mo pour tout le reste
Google chiffre l’empreinte sur un Pixel 11 Pro, avec quantification (les poids sont stockés avec moins de précision pour occuper moins de place) : environ 191 Mo de RAM active pour les seuls poids texte, environ 567 Mo pour le modèle multimodal complet. Unsloth, qui propose des versions GGUF, parle d’un peu plus de 0,5 Go. Ces deux ordres de grandeur restent compatibles avec une application mobile ordinaire, mais la formule « 740 millions de paramètres dans 191 Mo » ne vaut que pour la version texte.
Second levier, l’apprentissage de représentations dites « poupées russes » (Matryoshka Representation Learning, MRL). Les vecteurs de 768 dimensions peuvent être tronqués à 512, 256 ou 128, ce qui divise jusqu’à six fois le stockage de la base vectorielle locale. De premiers essais dans le navigateur via WebGPU font état de 20 à 70 millisecondes par requête.
Côté qualité, le score sur MTEB Code (Massive Text Embedding Benchmark) passe de 68,76 à 78,68, soit près de 10 points. Google affirme aussi dépasser des modèles spécialisés deux fois plus gros sur l’image, la vidéo, les documents et l’audio. Ces mesures viennent de l’éditeur : elles donnent un rapport qualité par paramètre, pas la tenue sur votre corpus, car des mémos vocaux bruités ou des captures d’écran mal cadrées ne figurent pas dans un benchmark. Les documents publiés ne donnent par ailleurs aucun chiffre de consommation de batterie pour l’indexation.
Des vecteurs qui ne quittent plus l’appareil
Avec un embedding distant, chaque photo et chaque enregistrement envoyé à une API fabrique une copie quelque part. En local, ni le contenu ni l’index ne sortent, et aucune clé d’API n’est nécessaire. Associé à un petit modèle génératif comme Gemma 4, l’ensemble forme un RAG hors ligne complet. Google cite l’indexation d’une base de code locale, la recherche sémantique de code et la récupération pour les agents de programmation.
Pour un développeur, une ligne de coût se déplace : plus de facturation au volume d’embeddings, mais un coût d’indexation payé en calcul et en énergie sur l’appareil de l’utilisateur. Le choix de la dimension, 128 ou 768, devient un arbitrage de produit entre précision de la recherche et taille de l’index.
Fin 2027, des galeries photo qui cherchent sans le cloud
Notre pronostic : d’ici fin 2027, la recherche dans les galeries et les mémos d’au moins un grand système mobile reposera sur un embedding multimodal exécuté sur l’appareil. Les applications de notes ou de gestion documentaire qui envoient encore tout vers un cloud devront alors justifier ce choix auprès de leurs utilisateurs.
Pour que cela se produise, la batterie vient en premier : les 567 Mo ne doivent pas se payer en autonomie, et l’indexation initiale d’une photothèque de plusieurs milliers de fichiers reste à mesurer. Les moteurs d’inférence mobiles et navigateurs (WebGPU, runtimes GGUF) devront ensuite traiter l’audio et la vidéo aussi bien que le texte. Enfin, la qualité devra tenir hors des benchmarks de l’éditeur, sur des données réelles, bruitées, multilingues.
Le scénario inverse est plausible. Si l’indexation d’une photothèque fait chauffer un téléphone d’entrée de gamme, le local restera un argument réservé au haut de gamme, et le cloud gardera le marché du grand public. Il suffira d’un premier produit capable d’indexer en tâche de fond plusieurs années de photos et de vocaux sans que son utilisateur remarque la charge pour faire basculer l’équilibre.
Sources
Ils m’ont fait confiance
« Il ne se contente pas de corriger les symptômes, il cherche à comprendre l'origine des problèmes et à sécuriser les modifications effectuées. J'ai réellement le sentiment d'avoir trouvé un développeur qui comprend à la fois la technique et les enjeux globaux du projet. »
Évaluation client · projet WordPress · septembre 2026
5,0/5 sur 17 évaluations
Faire appel à mes services →
