EmbeddingGemma 2 : construire un RAG multimodal qui reste sur l’appareil

Une information importante peut se cacher dans un PDF, une capture d’écran, un fichier de code ou l’enregistrement d’une réunion. Et si l’on pouvait retrouver ce contenu par une simple question, sans envoyer les documents à un service cloud ?

Le 6 octobre 2026, Google DeepMind a présenté EmbeddingGemma 2, un modèle d’embeddings ouvert, sous licence Apache 2.0, conçu pour rechercher dans plusieurs formats avec une représentation vectorielle commune. Son intérêt ne se limite pas à sa taille : il rend plus crédible un moteur de recherche sémantique multimodal exécuté localement.

Cette annonce invite à examiner une étape précise du RAG : l’indexation et la recherche sémantique des connaissances, avant toute génération de réponse. Quels formats peut-on interroger avec un même modèle ? Quelles données peuvent rester sur l’appareil ? Et dans quels cas cette approche offre-t-elle un avantage concret face à une API distante ?

Pourquoi déplacer la recherche sémantique vers l’appareil ?

Dans un système RAG (Retrieval-Augmented Generation), une application découpe les sources en passages, crée leurs embeddings, retrouve les éléments proches de la question et les fournit éventuellement à un modèle génératif. Cette recherche peut s’effectuer dans une infrastructure distante, sur un serveur privé, ou directement sur l’appareil qui possède les fichiers.

Lorsque les données sont publiques et partagées par des milliers d’utilisateurs, une API d’embeddings centralisée reste souvent une solution pragmatique. Le choix change pour un contrat confidentiel, un dépôt logiciel interne, des notes de réunion ou des captures d’écran métier : ces documents ne devraient pas circuler inutilement entre plusieurs prestataires.

• Moins de transferts : l’encodage, l’index et la recherche peuvent rester sur le poste.
• Un usage hors connexion : après téléchargement des modèles et préparation de l’index, la recherche peut fonctionner sans réseau.
• Un coût d’exploitation différent : moins de requêtes à facturer, mais davantage de CPU/GPU, de stockage et de maintenance côté appareil.

Il ne faut donc pas opposer systématiquement cloud et local. Le meilleur emplacement pour les embeddings dépend de la sensibilité des sources, de leur volume et des appareils réellement utilisés.

EmbeddingGemma 2 : un espace commun à cinq types de contenus

Basé sur Gemma 4, le modèle projette texte, code, images, images vidéo et audio dans un espace de 768 dimensions. Une requête textuelle peut ainsi être comparée à une image ou à un extrait sonore : elle n’a pas nécessairement besoin de passer par une transcription ou une légende générée au préalable. Les différents encodeurs produisent des vecteurs compatibles entre eux.

L’architecture est modulaire. Il n’est pas nécessaire de charger les composants dédiés à l’audio pour créer un moteur de recherche dans un dépôt Git.

Le contexte annoncé est de 8 192 tokens, partagé entre les modalités. Pour un document ou une vidéo longue, il reste essentiel de sélectionner des pages, passages ou segments cohérents. Un embedding global de tout un corpus n’est pas un substitut à l’indexation de ses contenus.

API, RAG texte local ou multimodal local : trois approches

Pour décider de l’architecture, trois situations méritent d’être comparées plutôt que de rechercher « le meilleur modèle » de manière abstraite.

Les trois approches peuvent partager des briques : segmentation, filtres métier, métadonnées et affichage des sources. Le passage au multimodal n’oblige pas à réécrire toute l’application si l’index a été conçu proprement.

Le pipeline d’un RAG multimodal fiable

Un modèle d’embeddings ne remplace pas l’architecture documentaire. Pour retrouver la bonne information et montrer d’où elle vient, il faut conserver les références aux fichiers et gérer les permissions dès le départ.

Le dernier point est important : un score de similarité élevé n’est pas une preuve que le contenu est exact. Une interface professionnelle doit permettre d’ouvrir le document d’origine et de constater, le cas échéant, qu’aucune réponse suffisamment fiable n’a été trouvée.

Tutoriel : tester une recherche locale avec Python

On peut commencer sans base vectorielle ni LLM. Ce prototype prend deux courts passages, calcule leurs embeddings avec la configuration texte et affiche celui qui se rapproche le plus d’une question. Il illustre la récupération de contenu, pas une application RAG prête pour la production.

1. Installer les dépendances

Google documente l’utilisation de sentence-transformers à partir de la version 6.1.0. La première utilisation télécharge les poids du modèle ; l’exécution locale hors connexion est possible ensuite, si les fichiers nécessaires sont bien en cache.

python -m venv .venv
source .venv/bin/activate  # Linux ou macOS
# Sous Windows : .venv\Scripts\activate
pip install -U "sentence-transformers[image,audio,video]" transformers

2. Encoder les documents et la question

from sentence_transformers import SentenceTransformer

model = SentenceTransformer(
    "google/embeddinggemma-2",
    config_kwargs={"vision_config": None, "audio_config": None},
)

documents = [
    "Une application contrôle les droits d’accès aux documents.",
    "Le compte rendu décrit une architecture de recherche locale.",
]
question = "Où retrouver les décisions sur la recherche hors ligne ?"

vectors = model.encode(
    documents,
    prompt_name="Document",
    normalize_embeddings=True,
)
query_vector = model.encode(
    question,
    prompt_name="SearchQuery",
    normalize_embeddings=True,
)

scores = model.similarity(query_vector, vectors)[0]
best_index = int(scores.argmax())

print(documents[best_index])
print("Score :", float(scores[best_index]))

Les prompts Document et SearchQuery sont ceux du guide Google. Le résultat est un passage classé, pas une réponse rédigée. Dans une version métier, je conserverais également les identifiants des fichiers, leurs URLs locales ou chemins autorisés et les métadonnées indispensables pour citer le bon extrait.

3. Préparer le passage à l’échelle

• Découper les longs documents en passages cohérents, sans mélanger des sujets sans lien.
• Réindexer uniquement les éléments modifiés et conserver un identifiant stable par segment.
• Ajouter un index local persistant (par exemple SQLite pour les métadonnées et une recherche vectorielle adaptée au volume).
• Évaluer la pertinence sur des questions réelles avant de connecter un modèle génératif.

Retrouver une image, un son ou un moment de vidéo

Pour la recherche multimodale, on charge les encodeurs utiles puis on passe le média au modèle sous forme d’objet décrivant sa modalité. L’exemple suivant correspond à l’API présentée dans le guide développeur :

from sentence_transformers import SentenceTransformer

model = SentenceTransformer("google/embeddinggemma-2")

image_vector = model.encode({"image": "capture-interface.png"})
audio_vector = model.encode({"audio": "extrait-reunion.wav"})
query_vector = model.encode(
    "discussion sur l'architecture de l'application",
    prompt_name="SearchQuery",
)

print("Image :", model.similarity(query_vector, image_vector))
print("Audio :", model.similarity(query_vector, audio_vector))

Les fichiers doivent être présents localement et compatibles avec le runtime. Pour la vidéo, le guide indique une prise en charge MP4 avec un échantillonnage des images à une image par seconde par défaut. L’audio doit notamment être préparé en mono 16 kHz.

Les transcriptions et légendes ne deviennent pas inutiles. Elles peuvent faciliter l’accessibilité, l’audit, le filtrage de mots exacts et la citation de ce que la personne a réellement dit.

Combien de mémoire et d’espace de stockage prévoir ?

Google annonce environ 191 Mo de RAM active en texte seul et 567 Mo pour le multimodal complet sur Pixel 11 Pro. Ces chiffres proviennent de configurations optimisées sur un appareil précis : ils ne représentent ni le pic mémoire universel, ni le coût total d’un pipeline Python ou Web. Il faut ajouter le runtime, les médias, les activations, l’index et éventuellement le LLM.

EmbeddingGemma 2 utilise aussi le principe Matryoshka Representation Learning (MRL), permettant de tronquer les vecteurs de 768 dimensions à 512, 256 ou 128. Ce choix agit surtout sur l’espace occupé par les embeddings ; son effet sur le rappel doit être mesuré sur les données du projet.

Google indique qu’à 256 dimensions, ses évaluations conservent environ 95 % de la qualité de référence en recherche image, vidéo et parole. Ce n’est pas un résultat garanti pour tous les corpus. L’appel model.encode(..., truncate_dim=256, normalize_embeddings=True) permet de tester cette configuration ; requêtes et documents doivent utiliser la même dimension.

Poste, mobile, navigateur : ce qui est disponible et ce qui arrive

Les poids du modèle et des intégrations sont proposés dans plusieurs environnements, dont Transformers, sentence-transformers, MLX, Ollama et LiteRT. Google montre également deux démonstrations déjà annoncées dans AI Edge Gallery : Instant Media Search et Video Moments Finder. La première utilise notamment un index SQLite local et un classement par similarité cosinus.

Sur Mac, Google présente aussi AI Edge Foresight, un compagnon de réunion expérimental qui associe notes, conversations et fichiers privés avec du traitement local. Pour un projet métier, ces exemples constituent des références d’architecture, pas la promesse qu’une intégration navigateur est prête sans adaptation.

Pour une intégration Web, la conception doit prévoir la taille du téléchargement initial, le cache des poids, les limites mémoire d’un onglet, le stockage local de l’index et les navigateurs compatibles. Un prototype qui fonctionne sur un poste haut de gamme n’est pas automatiquement adapté à tous les smartphones.

« Sans cloud » ne veut pas automatiquement dire « sécurisé »

Déplacer les embeddings sur l’appareil élimine certains transferts, mais ne suffit pas à garantir la confidentialité. Les vecteurs eux-mêmes peuvent révéler des informations sur leurs sources, et un composant de génération distant peut réintroduire un échange réseau.

Le local est une propriété d’architecture à vérifier : elle porte sur l’ingestion, les embeddings, l’index, la recherche et la génération éventuelle, pas seulement sur le nom du modèle.

Comment évaluer EmbeddingGemma 2 : une méthode reproductible

Pour comparer ces architectures, on peut préparer un corpus de test autorisé et représentatif : documentation technique, fichiers source, captures d’écran et extraits audio. L’objectif n’est pas de démontrer que le local est toujours supérieur, mais d’identifier les volumes, les appareils et les contraintes de confidentialité qui rendent ce choix pertinent. Le protocole ci-dessous est une proposition méthodologique, et non le compte rendu de tests déjà réalisés.

Un scénario d’évaluation possible consiste à indexer un corpus documentaire de démonstration associant code, schémas et extraits de réunion, puis à vérifier que chaque résultat renvoie au bon fichier, passage ou horodatage. Les mesures obtenues permettraient de décider si un index multimodal local apporte une réelle valeur par rapport aux autres architectures. Ce scénario ne décrit pas un produit déjà déployé.

Questions fréquentes

Retrouvez les réponses aux principales questions sur l’exécution locale, les modèles et les environnements compatibles.

Le point essentiel : EmbeddingGemma 2 ne règle pas à lui seul les questions de qualité documentaire, de permissions ou de sécurité. Il apporte en revanche une brique intéressante pour construire des recherches texte, image et audio exécutées près des utilisateurs, sans imposer une API distante à chaque requête. C’est une piste à mesurer, pas une promesse universelle.