L’ANALISI
EmbeddingGemma 2: embeddings multimodali locali per ricerca e RAG
Analisi pratica di EmbeddingGemma 2: pesi, modalità, memoria, contesto, integrazioni locali, limiti e checklist per ricerca e RAG multimodali.

In breve: EmbeddingGemma 2 è un encoder multimodale leggero per indicizzare e confrontare testo, codice, immagini, audio e video senza inviare necessariamente i contenuti a un servizio cloud. Il vantaggio pratico dipende però dalla qualità misurata sul proprio corpus e dalla pipeline locale completa.
Che cosa è stato rilasciato
EmbeddingGemma 2 è un modello da 740 milioni di parametri basato su Gemma 4, distribuito con licenza Apache 2.0. Google pubblica i pesi su Hugging Face e Kaggle insieme a model card, guida di sviluppo e percorsi di inferenza.
Un solo spazio per più modalità
Il modello produce rappresentazioni confrontabili per testo, codice, immagini, audio e frame video. La composizione è modulare: circa 270 milioni di parametri per il testo, con encoder opzionali da 170 milioni per la visione e 300 milioni per l’audio.
Memoria, vettori e contesto
Google dichiara vettori da 768 dimensioni riducibili a 512, 256 o 128 con Matryoshka Representation Learning. Il contesto è di 8K token e può contenere, nelle condizioni indicate dal progetto, fino a 5,5 minuti di audio, 29 immagini o 58 frame video.
Dove può essere utile
I casi più concreti sono ricerca semantica locale, indicizzazione di codebase, recupero cross-modale e RAG su archivi che combinano documenti, registrazioni e immagini. Le integrazioni elencate includono Transformers, sentence-transformers, MLX, vLLM, llama.cpp, SGLang, Ollama, LM Studio, LiteRT e WebGPU.
Prestazioni dichiarate e confine locale
Google riporta circa 191 MB di RAM attiva per i pesi solo testo quantizzati e circa 567 MB per il modello multimodale completo su Pixel 11 Pro. Locale descrive l’inferenza del modello: ingestione, database vettoriale, telemetria e modello generativo devono essere configurati separatamente per restare sul dispositivo.
Condizioni e limitazioni
I benchmark e le misure di memoria sono dichiarazioni Google su set e dispositivi specifici. Un embedding condiviso non garantisce qualità sufficiente sul proprio corpus: recall, latenza, RAM, quantizzazione e privacy della pipeline vanno misurate end to end.
Checklist per una prova controllata
- Fissare checkpoint, quantizzazione, libreria e dispositivo di prova.
- Preparare query e risultati attesi per ogni modalità realmente usata.
- Misurare recall@k e precisione su testo, codice, immagini e audio separatamente.
- Confrontare vettori da 768, 512, 256 e 128 dimensioni su qualità e memoria.
- Misurare latenza, RAM e spazio dell’indice sull’hardware di destinazione.
- Verificare che ingestione, indice e telemetria restino locali quando richiesto.
- Documentare errori cross-modali e mantenere un percorso di fallback.