Retrouver une procédure devant une machine
Une technicienne arrive devant un équipement en panne. Sur sa tablette, elle possède un manuel, des photos prises lors d’interventions et des enregistrements de maintenance. Elle cherche « le raccord à vérifier quand la pression chute ». Le bon passage peut employer un autre terme, et une photo utile ne possède peut-être aucune légende. Ce scénario hypothétique servira de fil conducteur : que faut-il calculer pour lui présenter les bons éléments ?
Google a lancé EmbeddingGemma 2 le 6 octobre 2026. Ce modèle d’embeddings traite plusieurs types de contenus, dits modalités, pour préparer leur recherche. Les poids sont publiés sous licence Apache 2.0. Le dossier examine ses possibilités et l’infrastructure à construire autour ; les mesures matérielles citées proviennent de Google. Annonce officielle.
Un vecteur sert à retrouver les contenus
Un embedding est une liste de nombres, appelée vecteur, calculée à partir d’un contenu. Le modèle apprend à produire des vecteurs dont la proximité aide à retrouver des contenus pertinents. L’application compare celui de la question aux vecteurs des passages déjà indexés, puis affiche les résultats les mieux classés. Elle peut ainsi retrouver une idée formulée avec d’autres mots. Principe de la recherche sémantique.
La technicienne reçoit d’abord une sélection de passages ou de médias. Si l’application doit aussi rédiger une explication, elle peut confier ces résultats à un modèle génératif. Cette récupération d’informations avant la génération constitue un RAG, pour Retrieval-Augmented Generation. EmbeddingGemma 2 intervient dans la sélection des informations ; il ne produit pas lui-même le paragraphe de réponse.
Le classement reste une estimation de pertinence. Un score de similarité de 0,8 ne signifie pas que la réponse est correcte avec une probabilité de 80 %. Une procédure visuellement proche peut concerner une autre version de l’équipement. L’application doit conserver la source et sa version pour que le résultat puisse être vérifié.
Un modèle commun, des encodeurs que l’on peut choisir
Les configurations annoncées vont d’environ 270 millions de paramètres pour le texte et le code à 740 millions pour l’ensemble texte, vision et audio. Un encodeur transforme chaque modalité en représentations exploitables par le réseau partagé. Pour une base de manuels textuels, charger les encodeurs des images et de l’audio ajoute du poids sans aider la tâche. Ils peuvent être désactivés au chargement. Configurations documentées.
Le réseau adapté de Gemma 4 utilise une attention bidirectionnelle : il exploite les informations situées des deux côtés d’un token, un morceau de texte ou une représentation intermédiaire. Les sorties sont regroupées par moyenne, projetées puis normalisées pour former un vecteur de 768 coordonnées. La vision et l’audio entrent dans ce traitement commun, ce qui permet de comparer leurs résultats à ceux d’une question écrite. Architecture dans Transformers.
L’apprentissage rapproche des paires pertinentes et les distingue de contre-exemples. Google emploie aussi une distillation depuis Gemini Embedding 2, puis affine l’espace avec des objectifs contrastifs. Cette origine ne garantit pas que les vecteurs des deux modèles soient interchangeables. En revanche, les configurations d’encodeurs d’un même checkpoint EmbeddingGemma 2 partagent l’espace documenté. Rapport technique, guide développeur.
Séparer l’indexation de la recherche
Avant l’intervention, l’application extrait le texte du manuel et le découpe en passages. Elle conserve pour chacun l’identifiant du document, la section, la version et le contenu nécessaire à l’affichage. Elle calcule ensuite ses embeddings et les stocke dans un index. Cette préparation peut être longue, mais elle n’a pas à être répétée pour chaque question.
Lors de la recherche, seule la nouvelle question doit être encodée. L’index est interrogé pour obtenir des candidats. Un second modèle peut les reclasser en examinant chaque passage avec la question : c’est le reranking. Cette étape est optionnelle et possède son propre coût. Recherche puis reclassement.
Un manuel corrigé demande de mettre à jour ses passages modifiés et de retirer les anciens. Un changement de modèle ou de recette d’encodage peut demander de reconstruire l’index. Notre recommandation est d’enregistrer le modèle, sa révision, les préfixes de tâche, la dimension des vecteurs et l’empreinte des contenus. Deux listes de 768 nombres n’appartiennent pas nécessairement au même espace.
Ajouter photos et enregistrements sans perdre leurs références
Pour les photos de maintenance, une requête écrite peut être comparée directement aux vecteurs des images. Une application qui utilisait un modèle pour décrire chaque photo puis un autre pour encoder cette description peut tester un traitement visuel natif à la place. Cela évite une représentation intermédiaire qui peut perdre des détails, mais ne garantit pas un gain sur chaque tâche. Google propose des démonstrations de recherche croisée dans AI Edge Gallery. Exemples officiels.
Un enregistrement peut contenir des paroles et des sons sans paroles. L’encodeur audio traite directement le signal ; l’application peut donc tester la recherche sur les deux, avec des extraits et des requêtes adaptés. Pour les bruits particuliers d’une machine, l’évaluation doit porter sur ces sons : un résultat moyen sur des tâches audio générales ne répond pas à ce besoin précis. Évaluation audio du rapport.
Le besoin de restitution reste décisif. Retrouver une page scannée et recopier fidèlement une référence de pièce sont deux objectifs différents. Une recherche visuelle peut sélectionner la page ; une extraction de texte ou une lecture spécialisée reste utile si l’application doit citer exactement ses caractères. De même, un embedding audio peut aider à retrouver un extrait, alors qu’une transcription sert à afficher les paroles.
La fenêtre documentée est de 8 192 tokens partagés entre les modalités. Le chemin Transformers échantillonne la vidéo à une image par seconde et conserve au maximum 32 images par défaut. Une application qui cherche un événement bref doit donc choisir son découpage et son échantillonnage, plutôt que supposer que chaque instant a été observé. Pour retrouver un moment précis, elle indexe des segments avec leurs positions temporelles. Traitement multimodal.
Où l’infrastructure peut économiser du travail
Reprenons la tablette. Si elle utilise uniquement les manuels, le chemin texte suffit. Si elle ajoute les photos, elle charge la vision. Si les recherches et l’index restent locaux, les questions et les contenus n’ont pas à traverser un réseau pour cette étape. Le coût est transféré vers l’appareil : stockage du modèle, préparation initiale et calcul des nouvelles questions.
| Choix | Travail potentiellement réduit | Coût ou contrainte à mesurer |
|---|---|---|
| Indexer avant les recherches | Réencodage des documents à chaque question | Préparation initiale et mises à jour |
| Encoder directement un média | Chaîne description/transcription puis embedding | Qualité sur la tâche et besoin de restitution exacte |
| Charger les modalités utiles | Poids et allocations des encodeurs inutilisés | Disponibilité des formats et du backend |
| Raccourcir les vecteurs | Octets stockés et calcul des comparaisons | Perte de pertinence et surcoût propre à l’index |
| Rechercher sur l’appareil | Allers-retours et charge du serveur de recherche | Mémoire, énergie et versions à distribuer |
| Envoyer moins de passages au générateur | Texte à traiter pendant sa phase d’entrée | Risque d’écarter une source nécessaire |
Une seule famille de modèles peut simplifier le déploiement, mais les décodeurs de fichiers, la préparation des images et les mises à jour restent à maintenir. Le passage à un encodeur commun ne signifie pas non plus que les résultats des différents médias sont parfaitement comparables pour votre corpus. Il faut vérifier si un type de contenu domine le classement au détriment des autres.
Pour un parc de tablettes partageant les mêmes manuels, recalculer toute la base sur chaque appareil peut gaspiller du travail. Une architecture hybride peut préparer un index commun sur serveur puis le distribuer, tandis que les photos privées restent indexées sur la tablette. Il faut alors conserver des recettes d’encodage compatibles et prévoir le volume des synchronisations. Ce choix relève de l’application, pas d’une propriété automatique du modèle.
Réduire l’entrée du générateur peut aussi changer son coût
Si la technicienne demande une réponse rédigée, seuls les passages retenus peuvent être transmis au générateur avec la question. Réduire le contexte fourni peut raccourcir son prefill Phase initiale d'une inférence LLM : les tokens du prompt sont traités en parallèle pour construire l'état du contexte. Cette réutilisation augmente l'intensité arithmétique et peut rendre la phase limitée par le calcul ; le régime exact dépend du modèle, du batch, du contexte et du backend. Approfondir dans le glossaire , la phase qui traite les tokens d’entrée, et diminuer les états de son KV cache Mémoire des vecteurs clé et valeur déjà calculés pour chaque token traité par un LLM. Évite de recalculer l'attention sur tout l'historique, au prix d'une consommation mémoire qui croît avec le contexte. Approfondir dans le glossaire , qui mémorise les clés et valeurs de l’attention. Le gain exige que la sélection conserve les informations nécessaires.
Le coût total comprend alors l’encodage de la question, la recherche, le reclassement éventuel et la génération. Ajouter un reranker qui coûte plus de temps qu’il n’en fait gagner peut allonger la réponse. À l’inverse, une sélection plus précise peut éviter d’envoyer un long document au modèle génératif. Il faut mesurer la chaîne complète, comme l’explique notre analyse du benchmark MLPerf RAG.
La réponse doit enfin utiliser des documents autorisés pour cette personne et cette intervention. Les droits d’accès, la version de la machine et la validité de la procédure sont des filtres de recherche, pas de simples décorations de l’interface. Une similarité élevée ne doit pas contourner ces conditions.
Compter les poids, le runtime et l’index séparément
La mémoire des poids dépend de leur format. À titre de calcul, 270 millions de paramètres stockés en FP32, sur quatre octets chacun, représentent environ 1,08 Go. Cela ne comprend ni les activations temporaires, ni les bibliothèques, ni les médias décodés. Le paquet quantifié complet proposé pour LiteRT-LM est annoncé à 485 Mo à télécharger : une taille de fichier n’est pas une mesure de RAM en fonctionnement. Artefacts et formats LiteRT-LM.
Le rapport publie un pic mémoire de 191 Mo pour le texte seul et 567 Mo pour le multimodal complet, sur Pixel 11 Pro avec la recette Q4_C. La quantification utilise des formats plus courts pour les poids et une préparation adaptée à cette précision. Ces nombres sont propres à cette configuration ; les tableaux LiteRT emploient aussi des métriques système qui peuvent exclure la mémoire de l’accélérateur. Il faut préciser le protocole avant de les comparer. Rapport, section quantification, conditions de mesure LiteRT.
Sur la tablette, un chargement réussi ne prouve donc pas que l’application pourra traiter les plus gros passages tout en affichant les médias et en faisant tourner le générateur. Le pic utile est celui de l’ensemble en activité. Un service qui conserve le modèle chargé évite de payer son initialisation à chaque question, au prix d’une mémoire occupée même entre les recherches.
Raccourcir les vecteurs réduit une autre partie de la mémoire
L’entraînement Matryoshka rend utilisables des préfixes du vecteur complet : 512, 256 ou 128 coordonnées au lieu de 768. Après réduction, il faut renormaliser les vecteurs et utiliser la même dimension pour les questions et les documents. Cela agit sur les représentations stockées ; charger moins d’encodeurs agit sur les poids du modèle. Les deux leviers sont distincts. Principe de Matryoshka Representation Learning.
| Dimension | Octets par vecteur FP32 | Un million de vecteurs, Go décimaux |
|---|---|---|
| 768 | 3 072 | 3,072 |
| 512 | 2 048 | 2,048 |
| 256 | 1 024 | 1,024 |
| 128 | 512 | 0,512 |
Le facteur six entre 768 et 128 concerne ces octets bruts, pas automatiquement toute la base. Une structure de recherche ajoute ses propres données. La qualité se dégrade aussi selon la tâche : dans les résultats publiés d’EmbeddingGemma 2, la réduction à 128 dimensions affecte davantage certaines tâches multimodales. Commencer à 768 ou 256 puis comparer les bons résultats retrouvés donne une décision plus utile qu’une compression maximale choisie par défaut. Évaluations selon la dimension.
Le format des poids, le nombre de tokens visuels et la dimension du vecteur forment ensemble une configuration. Validez les changements séparément, puis leur combinaison : une bonne qualité avec des poids BF16 ne prouve pas celle d’un paquet quantifié qui réduit aussi la précision des entrées et des sorties.
L’index devient lui-même un choix d’infrastructure
Pour quelques passages, un tableau de vecteurs suffit : l’application compare la question à chaque ligne et trie les scores. Avec des vecteurs normalisés, leur produit scalaire correspond à la similarité cosinus, qui compare leur orientation. Ce calcul évite d’exécuter à nouveau le modèle sur les documents, mais son travail augmente avec leur nombre et leur dimension. Distances et normalisation dans Faiss.
Quand le corpus grandit, un index de voisins approximatifs peut réduire le nombre de candidats examinés. HNSW organise par exemple les vecteurs dans un graphe de voisinage ; ses liens consomment de la mémoire et ses réglages échangent vitesse et rappel, la proportion de résultats pertinents effectivement retrouvés. Faiss distingue explicitement le coût des vecteurs de celui de ces structures. Types d’index Faiss.
Le placement du calcul suit ensuite les usages. Un petit index local fonctionne pendant une coupure réseau. Un serveur mutualise le calcul et les mises à jour pour plusieurs utilisateurs, mais ajoute les échanges et les files d’attente. Une recherche hybride peut combiner correspondances exactes et proximité sémantique : pour une référence de pièce ou une version de GPU, préserver le bon identifiant peut compter davantage qu’une proximité de sens.
Lire les benchmarks sans leur faire dire toute la recherche
Le gain sur le code est net dans les résultats publiés. Le texte multilingue évolue beaucoup moins, et l’agrégat anglais recule légèrement face à la première version. Les chiffres ci-dessous sont ceux présentés par Google, pas une évaluation du corpus de maintenance.
| Benchmark, moyenne par tâche | EmbeddingGemma 1 | EmbeddingGemma 2 | Qwen3-Embedding-0.6B |
|---|---|---|---|
| MTEB multilingue v2 | 61,15 | 61,36 | 64,34 |
| MTEB anglais v2 | 69,67 | 68,46 | 70,47 |
| MTEB Code | 68,76 | 78,68 | 75,42 |
Les 9,92 points gagnés sur le code correspondent à environ 14,4 % d’augmentation relative de ce score. Ils ne décrivent pas une accélération ni une amélioration générale de 14 % du RAG. Qwen3-Embedding-0.6B reste une référence pertinente pour le texte seul ; un assistant Qwen génératif remplit, lui, un autre rôle. Rapport, tableau 6, fiche Qwen3-Embedding.
Dans le cas de la tablette, il faut mesurer si les procédures correctes sont retrouvées, si les anciennes versions sont écartées et si le classement reste utile en français. Un score moyen multilingue ne répond pas séparément à ces questions.
Une latence mobile dépend de l’entrée et du backend
La fiche LiteRT publie 8,3 ms pour le texte sur Pixel 11 Pro avec son accélérateur TPU intégré, sur la signature de 128 tokens, le chemin compilé pour cette taille d’entrée. Le test texte et vision atteint 49 ms, avec un budget visuel de 70 tokens. Il s’agit de moyennes sur cinq itérations dans ce protocole, sans inclure toute l’ingestion et la recherche d’une application. Un manuel de 8 192 tokens ne correspond pas à cette entrée courte. Protocole LiteRT-LM.
LiteRT et MediaPipe fournissent des chemins d’exécution sur appareil. Universal Embedder produit les vecteurs et Semantic Retriever ajoute des fonctions de stockage et de recherche. Le support d’un NPU Neural Processing Unit. Accélérateur spécialisé dans les opérations des réseaux de neurones. Selon sa conception et son logiciel, il peut servir à l’inférence, à l’entraînement ou aux deux. Les opérateurs et formats pris en charge dépendent du matériel.
Approfondir dans le glossaire
, un accélérateur spécialisé dans les réseaux de neurones, dépend du matériel et de l’artefact compilé. Les signatures disponibles dans un paquet mobile peuvent aussi différer des budgets proposés par le modèle dans Transformers. Universal Embedder, Semantic Retriever.
Un comparatif utile relève donc l’entrée exacte, le format, le backend et le nombre de requêtes simultanées. Il sépare le premier chargement des requêtes avec modèle déjà en mémoire. Pour l’autonomie, il faut une mesure d’énergie ; la seule réduction du nombre de paramètres ne fournit pas des joules par recherche.
Exécuter une recherche textuelle sur CPU
L’exemple fourni utilise six notes techniques courtes, un modèle texte en FP32 et des vecteurs normalisés de 256 dimensions. Il enregistre l’index dans un fichier NumPy, puis recharge cet index pour les recherches. Il n’appelle aucune API d’inférence et ne génère pas de réponse. Le téléchargement initial des poids et des paquets nécessite Internet ; le mode --offline utilise ensuite les fichiers mis en cache.
Le script Python, les dépendances et le corpus français sont disponibles séparément ou dans l’archive complète. Enregistrez-les dans un dossier, puis utilisez un environnement Python isolé. Les instructions ci-dessous lancent le Python de cet environnement.
python -m venv .venv
# Activez .venv, puis installez les variantes CPU compatibles :
python -m pip install torch==2.15.0 torchvision==0.29.2 --index-url https://download.pytorch.org/whl/cpu
python -m pip install -r requirements.txt
python local_search.py index --documents example_fr.json --index index-fr.npz
python local_search.py search --index index-fr.npz --offline --query "Comment rechercher mes documents sans les envoyer sur Internet ?"Sous PowerShell, l’activation se fait avec .venv\Scripts\Activate.ps1 ; sous un shell POSIX, avec source .venv/bin/activate. Le script épingle une révision du modèle, désactive la vision et l’audio, applique Document aux passages et SearchQuery à la question. Le manifeste conservé dans l’index permet de refuser un encodage de question incompatible. Il refuse aussi les passages qui dépasseraient le contexte au lieu de les tronquer silencieusement.
Les dépendances comprennent Pillow et TorchVision : dans les versions testées, le processeur importe des classes de prétraitement d’images et de vidéos même avec les encodeurs correspondants désactivés. Le paquet conserve donc ces dépendances logicielles, tandis que les poids chargés restent ceux du chemin texte.
Le programme affiche séparément le chargement du modèle, l’encodage de la question et le classement. Ces temps internes ne couvrent pas les imports Python ni la lecture du fichier d’index. Chaque commande search démarre un processus et recharge le modèle ; un service persistant conserverait celui-ci en mémoire. Le script sert à comprendre les étapes. Pour une mesure de bout en bout, chronométrez également la commande complète.
Après mise en cache des poids, la vérification locale a créé les deux index et exécuté les questions proposées en mode hors ligne. La note local, consacrée à la recherche sans API distante, arrive en première position dans chaque langue. Les vecteurs sont finis, normalisés et de dimension 256 ; un index déclarant une autre révision du modèle est refusé. Le rapport de vérification conserve ces résultats et leur périmètre.
Mesurer le gain sur l’application réelle
Avant un déploiement, constituez des questions avec leurs passages attendus, dont des cas ambigus et des questions sans réponse dans le corpus. Comparez les modèles sur le même découpage, les mêmes filtres et le même nombre de résultats. Un bon passage présent parmi les premiers candidats peut ensuite être déclassé par un reranker ou mal utilisé par un générateur : chaque étape mérite son contrôle.
Pour l’infrastructure, rapportez le temps et le volume de l’indexation, le pic mémoire complet, le temps des mises à jour et la latence des recherches sous la charge visée. Le p50 décrit la médiane ; le p95 est le seuil sous lequel se situent 95 % des latences mesurées, avec un échantillon suffisant pour être utile. Conservez séparément démarrage à froid et fonctionnement avec caches. Si l’objectif est d’économiser du réseau ou de l’énergie, mesurez également ces ressources.
Notre recommandation est de commencer par une recherche utile sur le texte, puis d’ajouter la modalité qui manque réellement au produit. Le manuel, la photo et l’enregistrement ne demandent pas forcément le même découpage ni la même précision. EmbeddingGemma 2 rapproche leurs représentations ; l’architecture de l’application décide où le calcul se fait, combien de fois il est répété et si le résultat aide l’utilisateur.
Sources et méthode
Analyse arrêtée au 12 novembre 2026. Le lancement date du 6 octobre et le rapport technique v1 du 27 octobre. La révision examinée du modèle est f9972ac22e696a105c482202646979e33e4b5a1e. Les tailles 270/740 millions sont les arrondis publics ; le rapport utilise des comptes plus précis. Les faits d’architecture et d’API sont vérifiés dans la documentation Transformers, le guide développeur et le guide multimodal.
Les scores et les mesures matérielles sont des résultats rapportés par Google, sans reproduction locale de ces benchmarks. Les latences et les métriques mémoire conservent les limites de la fiche LiteRT-LM. Les formats BF16, FP32 et la recette quantifiée mobile ne sont pas présentés comme équivalents. Les mécanismes de recherche sont documentés par Sentence Transformers, son reclassement, Faiss et la normalisation des vecteurs.
La vérification fonctionnelle LeCompute utilise Windows, un Intel Core Ultra 9 275HX, Python 3.13.13, PyTorch 2.15.0 CPU, TorchVision 0.29.2 CPU, Sentence Transformers 6.3.0, Transformers 5.22.2, NumPy 2.5.4 et Pillow 13.0.0. Le modèle tourne en FP32 avec quatre threads PyTorch, sur six notes par langue. Cette vérification porte sur les index, les recherches hors ligne et le refus d’un index incompatible. Elle ne mesure ni la qualité sur un grand corpus, ni les médias, ni le pic mémoire, ni l’énergie, ni un appareil mobile.
Le stockage FP32 et la hausse relative du score de code sont des calculs explicités. Le scénario de maintenance et les six notes de démonstration sont des exemples construits pour expliquer le parcours, sans jeu de test représentatif. Les choix de placement, d’indexation et de mesure sont des recommandations d’ingénierie à valider sur le corpus cible. La couverture est une illustration conceptuelle originale, avec son attribution et son prompt accessibles sous l’image.
