Andy Garcia · dev freelance
FRENES
Retour au blog
IA & Confidentialité

Le nouveau modèle d'embedding ouvert de Google met la recherche multimodale sur un téléphone. Avant d'indexer des PDF scannés avec, vérifie le budget d'image

7 octobre 2026 6 min de lecture

Le 6 octobre, Google DeepMind a publié EmbeddingGemma 2, un modèle d'embedding ouvert qui projette texte, code, images, vidéo et audio dans un même espace partagé de 768 dimensions. Il compte 740 millions de paramètres, il est construit sur Gemma 4 et il est distribué sous Apache 2.0. La fiche du modèle dit qu'il est conçu pour du matériel grand public comme les téléphones et les portables, et la fiche on-device de Google donne des temps mesurés sur un iPhone.

J'ai lu l'annonce, la fiche du modèle et la fiche on-device le soir même, avec une question en tête. Je construis une LegalTech qui traite des documents de brevets, et je publie des apps iOS à côté. Dans ces deux mondes, la première question sur un modèle d'embedding est rarement « est-il bon ? ». C'est « où va le document quand je l'indexe ? ».

Ce que Google a vraiment livré

Le modèle est modulaire. Le socle texte fait 270M de paramètres (130M de transformer, 140M de table d'embeddings). Un encodeur vision de 170M et un encodeur audio de 300M sont optionnels. Texte plus vision font 440M ; le tout, 740M. Toutes les configurations partagent un même espace vectoriel : une requête encodée avec la configuration texte seul peut donc être comparée à des pages encodées avec le modèle complet.

La fenêtre de contexte est de 8 192 tokens, quatre fois celle du premier EmbeddingGemma. Une image coûte 280 tokens par défaut, donc environ 29 images tiennent dans une entrée. La fiche annonce plus de 100 langues. La sortie est entraînée avec Matryoshka Representation Learning : tu peux ne garder que les 512, 256 ou 128 premières dimensions, pour jusqu'à six fois moins de stockage.

La licence a changé aussi. Le premier EmbeddingGemma est sur Hugging Face sous la licence « gemma », derrière un accès filtré où tu acceptes les conditions d'usage de Google. La version 2 est étiquetée apache-2.0, sans filtre. La fiche du modèle précise toujours que les déploiements doivent respecter la Gemma Prohibited Use Policy, qu'une équipe juridique voudra lire à côté de la licence.

Les chiffres, et ce à quoi ils sont comparés

La fiche du modèle compare EmbeddingGemma 2 à un seul modèle : son prédécesseur. Le texte multilingue est stable (61,36 contre 61,15 sur MTEB multilingual v2). Le code bondit de 68,76 à 78,68 sur MTEB Code, soit les 9,92 points du titre. Tout le reste est nouveau, donc sans point de comparaison : 64,64 sur MIEB lite pour les images, 50,67 sur MMEB v2 vidéo, 69,54 sur MSEB pour la recherche audio.

L'annonce ajoute trois graphiques qui le situent par taille face à des modèles ouverts : Qwen3-Embedding 0.6B et 8B pour le code, jina-embeddings-v5-omni et LCO-Embedding-Omni pour les images et l'audio, entre autres. Le haut de chaque graphique appartient à un modèle bien plus gros, Qwen3-Embedding-8B pour le code et LCO-Embedding-Omni (3B, puis 7B) pour les images et l'audio. L'argument est la qualité par paramètre, et les graphiques sont dessinés pour le montrer exactement. Le modèle hébergé de Google, Gemini Embedding 2, n'apparaît sur aucun d'eux.

Le chiffre qui m'intéresse est un autre : MMEB v2 VisDoc, la recherche de documents visuels, 67,84 en NDCG@5. C'est ce qui ressemble le plus, sur la fiche, à « retrouver la bonne page scannée ». Rien n'est placé à côté.

Pourquoi un embedder multimodal local compte pour les documents

La plupart des documents que je manipule ne sont pas du texte propre. Les dossiers de brevets mêlent revendications et dessins. L'art antérieur arrive en PDF scannés. Une figure avec des numéros de référence porte un sens que l'OCR aplatit ou perd. Le pipeline habituel enchaîne l'OCR, parfois un modèle de légendage, puis un embedder de texte, et chaque maillon est un endroit où quelque chose casse ou quitte ta machine. L'équipe edge de Google décrit le même problème pour les médias : un seul modèle « reduces the latency and memory overhead of chaining separate image captioning, speech-to-text, and text-embedding models » (réduit la latence et la charge mémoire de l'enchaînement de modèles distincts de légendage d'images, de reconnaissance vocale et d'embedding de texte).

Un embedding n'est pas non plus anonyme à la création. Pour le calculer, un service hébergé doit recevoir le document entier. Quand la question est « qui voit cette invention avant son dépôt ? », « un grand fournisseur cloud, sous contrat » est une réponse. « Personne, ça tourne sur notre machine » en est une meilleure. Un modèle de 740M sous Apache 2.0 peut tourner sur ton propre serveur, dans la région que tu as choisie, derrière sentence-transformers, vLLM, llama.cpp ou Ollama, que Google liste tous comme pris en charge.

L'argument du coût est plus faible qu'on ne croit

J'ai vérifié l'équivalent hébergé de Google le même jour. Gemini Embedding 2 accepte texte, images, vidéo, audio et PDF. Sur l'offre payante, une image coûte 0,00012 $, ou 0,00006 $ en batch. Cent mille pages scannées reviennent à environ 12 $, ou 6 $ en batch. Personne ne devrait changer d'architecture pour économiser 12 $.

Deux autres lignes de cette page de tarifs comptent davantage. L'offre gratuite est marquée « Used to improve our products: Yes » (utilisé pour améliorer nos produits : oui). L'offre payante est marquée « No ». Mes side projects démarrent en général sur des offres gratuites, et c'est la ligne à lire avant d'indexer ce qu'un utilisateur t'a confié.

Le vrai coût est celui que Simon Willison a soulevé sur Hacker News le jour du lancement. Les embeddings se calculent par milliers ou par millions et se stockent. Si un fournisseur retire son modèle, tu paies pour tout ré-encoder. Sa nuance mérite d'être gardée : il préférerait payer un fournisseur pour l'héberger, en sachant que les poids ouverts sont là si le fournisseur s'arrête. Les poids ouverts n'obligent pas à auto-héberger. Ils te donnent une sortie.

Ce que la version téléphone abandonne

Pour iOS, la fiche LiteRT de Google publie de vrais temps. Sur le GPU d'un iPhone 18 Pro, un embedding de texte prend 11,6 ms et texte plus une image 69,8 ms, avec 85 Mo et 196 Mo de mémoire. Le bundle texte et vision pèse 388 Mo au téléchargement, et ta fiche App Store le ressentira.

Maintenant, lis les notes de bas de page. Ces temps utilisent une entrée texte de 128 tokens et une image de 70 tokens. Les bundles LiteRT n'acceptent que des budgets d'image de 70 ou 140 tokens. Le défaut de la fiche du modèle est 280 et peut monter à 1 120, et elle dit qu'un budget plus grand améliore la « fine-grained visual understanding » (compréhension visuelle fine). Une photo de vacances peut survivre à 70 tokens. Une page dense de revendications avec de petits numéros de référence, peut-être pas. Les benchmarks ont été exécutés sur le checkpoint en pleine précision, et aucune des deux fiches ne donne de score de recherche de documents pour la configuration téléphone.

Mon partage serait donc : les documents encodés côté serveur au budget par défaut ou plus, le téléphone gérant les requêtes et la recherche média légère. Les deux atterrissent dans le même espace vectoriel, ce qui rend ce partage possible.

Ce que je ferais lundi

Construire un petit jeu d'évaluation à partir de tes propres documents avant de choisir quoi que ce soit : cinquante vraies requêtes et les pages qui devraient revenir. Le lancer à 768, 512 et 256 dimensions, et avec deux budgets d'image. Le guide développeur de Google recommande 768 ou 512 pour la recherche de documents visuels, et dit que 128 fait tomber la recherche d'images et de voix à environ 75 % de la qualité maximale.

Stocker la configuration avec chaque vecteur : modèle, dimension, budget d'image, préfixe de tâche. Des vecteurs issus de réglages différents ne sont pas comparables, et un jour tu devras savoir lesquels refaire.

Se méfier des trois pièges que la fiche du modèle énonce. Ne jamais l'exécuter en float16 : ses activations dépassent la plage du format, et tu obtiens des NaN ou des embeddings dégradés en silence au lieu d'une erreur. Re-normaliser après troncature, sinon la qualité du classement se dégrade « silently » (en silence). Et utiliser les préfixes de tâche : SearchQuery pour les requêtes, « title: {title} | text: {content} » pour les documents.

L'API elle-même est petite. Voici le schéma du guide développeur avec sentence-transformers 6.1 ou plus, en chargeant texte et vision seulement :

from sentence_transformers import SentenceTransformer

# Text, images, and video (440M parameters)
model = SentenceTransformer(
    "google/embeddinggemma-2",
    config_kwargs={"audio_config": None},
)
page_emb = model.encode({"image": "scan_page_017.png"})
query_emb = model.encode("hinged lid with a magnetic latch", prompt_name="SearchQuery")
print(model.similarity(query_emb, page_emb))

Dernière règle, celle qui survit à ce modèle : garde les pages sources, pas seulement les vecteurs. Ce sont ta seule vraie protection contre le prochain modèle, ouvert ou non.

Sources

Un projet du même genre ?

Je conçois et déploie des produits comme celui-ci. Parlons-en.

Discutons