Google DeepMind ha presentato EmbeddingGemma 2, un nuovo modello open-weight da 740 milioni di parametri progettato per trasformare testo, codice, immagini, video e audio in rappresentazioni vettoriali collocate all’interno dello stesso spazio di embedding a 768 dimensioni. Il modello viene distribuito con licenza Apache 2.0 ed è stato progettato esplicitamente per funzionare anche su hardware consumer e direttamente sui dispositivi, con l’obiettivo di rendere possibili sistemi di ricerca semantica, retrieval multimodale, routing e Retrieval-Augmented Generation senza dover necessariamente inviare i dati a infrastrutture cloud. La caratteristica centrale è proprio l’unificazione delle diverse modalità: una query testuale può essere confrontata direttamente con un’immagine, un segmento video o una registrazione audio, una nota vocale può essere utilizzata per trovare un momento specifico all’interno di un video e una descrizione testuale può interrogare raccolte estese di audio senza richiedere una precedente trascrizione. EmbeddingGemma 2 utilizza tecnologie derivate dalla stessa famiglia che alimenta i Gemini Embedding e rappresenta l’evoluzione del primo EmbeddingGemma, introdotto nel 2025 come modello leggero specializzato negli embedding testuali e che, secondo Google, ha superato i 20 milioni di download grazie soprattutto all’impiego in sistemi di ricerca locale e pipeline RAG orientate alla privacy.
L’architettura di EmbeddingGemma 2 è basata su Gemma 4 ed è stata progettata in modo modulare, così che non sia necessario caricare l’intero modello quando l’applicazione utilizza soltanto alcune modalità. La configurazione di base per testo e codice utilizza 270 milioni di parametri, suddivisi tra un backbone transformer da 130 milioni e un componente embedder da 140 milioni; a questa base può essere aggiunto un encoder visuale da 170 milioni di parametri, portando il totale a 440 milioni per testo, codice e immagini, oppure un encoder audio da 300 milioni, raggiungendo 570 milioni per testo, codice e audio. La configurazione completa combina tutti i componenti e arriva a 740 milioni di parametri. Nonostante gli encoder siano specializzati per modalità differenti, tutti proiettano i rispettivi risultati nello stesso spazio vettoriale a 768 dimensioni, permettendo quindi il confronto diretto tra rappresentazioni provenienti da fonti completamente diverse senza dover concatenare modelli separati per captioning delle immagini, speech-to-text e embedding testuale. L’architettura comprende 24 layer, meccanismi di grouped-query e multi-query attention, un vocabolario da 262.144 token, mean pooling e un livello di proiezione che converte le rappresentazioni interne da 512 a 768 dimensioni. La finestra di contesto è pari a 8.192 token per tutte le modalità, quattro volte superiore a quella del primo EmbeddingGemma, ma ogni tipo di contenuto consuma questo budget in maniera differente: un’immagine occupa 280 token, ogni frame video 140 token e l’audio 25 token al secondo. Utilizzando una sola modalità per input, il modello può quindi elaborare fino a 29 immagini, 58 frame video oppure circa 5,5 minuti di audio, mentre gli input interleaved consentono di combinare testo, immagini, video e audio all’interno della stessa sequenza mediante appositi placeholder che ne mantengono la posizione relativa.
Sul fronte delle prestazioni, EmbeddingGemma 2 mantiene sostanzialmente il livello del predecessore negli embedding testuali multilingue, ma registra un incremento marcato nella comprensione del codice, con il punteggio MTEB Code che passa da 68,76 a 78,68, pari a un miglioramento di 9,92 punti. Nei risultati full precision pubblicati da Google il modello raggiunge 61,36 su MTEB Multilingual v2, 64,64 su MIEB Lite, 57,28 su MMEB v2 per il retrieval di immagini, 67,84 nel retrieval di documenti visivi, 50,67 nel video retrieval, 69,54 su MSEB per la ricerca basata sui suoni e 49,39 su MAEB per le attività audio. Google lo posiziona come uno dei modelli multimodali più competitivi sotto il miliardo di parametri e afferma che, in diversi benchmark, riesce a superare modelli specialistici di dimensioni più che doppie. Il miglioramento sul codice è particolarmente rilevante per applicazioni di indicizzazione locale di repository, ricerca semantica all’interno di grandi codebase e strumenti agentici per lo sviluppo software, perché consente di creare embedding sia delle query in linguaggio naturale sia dei frammenti di codice e confrontarli direttamente nello stesso spazio. In una dimostrazione riportata nella documentazione per sviluppatori, Google ha indicizzato il repository di transformers di Hugging Face utilizzando la configurazione text-only da 270 milioni di parametri e ha successivamente utilizzato gli embedding come base per la ricerca all’interno della codebase da parte di un agente basato su Gemma 4 26B A4B.
EmbeddingGemma 2 supporta inoltre Matryoshka Representation Learning, una tecnica che permette di ridurre la dimensionalità degli embedding senza dover addestrare versioni separate del modello. I vettori prodotti nativamente a 768 dimensioni possono essere troncati a 512, 256 oppure 128 dimensioni, consentendo di ridurre in maniera consistente spazio di archiviazione, memoria utilizzata dal vector database e costo delle operazioni di similarity search. Secondo i dati pubblicati da Google, il passaggio a 256 dimensioni permette di conservare la maggior parte della qualità originale su testo e codice e circa il 95% delle prestazioni su retrieval di immagini, video e parlato, riducendo nel contempo di circa tre volte lo spazio necessario per memorizzare i vettori. A 128 dimensioni la riduzione dello storage arriva invece fino a sei volte: testo e codice mantengono circa il 90% della qualità iniziale, mentre le prestazioni multimodali scendono a circa il 75%, motivo per cui questa configurazione viene indicata soprattutto per grandi indici testuali o come primo stadio di selezione prima di un successivo re-ranking. Un indice contenente un milione di vettori a 768 dimensioni in precisione bfloat16 richiede indicativamente circa 1,5 GB, mentre lo stesso numero di vettori ridotti a 128 dimensioni occupa circa 250 MB. La possibilità di utilizzare lo stesso modello modificando in fase di deployment sia gli encoder effettivamente caricati sia la dimensionalità finale dei vettori permette quindi di adattare EmbeddingGemma 2 a dispositivi e applicazioni con requisiti hardware molto differenti senza cambiare completamente pipeline o spazio semantico di riferimento.
Il modello è stato inoltre ottimizzato specificamente per l’esecuzione locale. Nei test su Pixel 11 Pro, utilizzando la quantizzazione, Google riporta un consumo di circa 191 MB di RAM attiva per i soli pesi della configurazione text-only e di circa 567 MB per il modello multimodale completo. Questa impostazione permette di utilizzare gli embedding direttamente sul dispositivo per applicazioni in cui latenza, privacy o assenza di connettività rendono poco conveniente il ricorso continuo a servizi remoti. Google AI Edge ha integrato il modello nei propri strumenti MediaPipe e LiteRT, mentre una Decision Task API di MediaPipe può utilizzarlo anche come motore di classificazione e routing multimodale in tempo reale. In questo scenario il modello non deve necessariamente essere fine-tuned: gli input possono essere confrontati direttamente con descrizioni o etichette rappresentate nello stesso spazio vettoriale, ottenendo sistemi zero-shot capaci di classificare intenzioni o instradare richieste in pochi millisecondi. Google ha mostrato applicazioni di questo approccio attraverso le demo Instant Media Search e Video Moments Finder disponibili nella Google AI Edge Gallery, mentre l’applicazione Google AI Edge Foresight utilizza EmbeddingGemma 2 per il recupero locale dei file e Gemma 4 per la successiva elaborazione contestuale. I due modelli condividono inoltre il tokenizer testuale e l’architettura dell’encoder audio, caratteristica che riduce ulteriormente l’impronta di memoria quando vengono utilizzati insieme all’interno della stessa pipeline RAG on-device.
Per gli sviluppatori, EmbeddingGemma 2 può essere utilizzato attraverso transformers, sentence-transformers dalla versione 6.1.0 in poi, MLX, vLLM, llama.cpp, SGLang, Ollama e LMStudio; sono disponibili indicazioni specifiche per il fine-tuning tramite Unsloth e per l’esecuzione direttamente nel browser attraverso transformers.js e WebGPU. I pesi sono distribuiti su Hugging Face e Kaggle, mentre versioni ottimizzate per l’utilizzo sui dispositivi sono disponibili tramite LiteRT Community. La stessa API di sentence-transformers può ricevere file o oggetti appartenenti alle varie modalità e produrre embedding direttamente confrontabili tra loro: per esempio, una query testuale come “ocean waves at sunset” può essere comparata contemporaneamente con l’embedding di una fotografia e con quello di una registrazione audio, mentre un singolo oggetto multimodale può incorporare descrizione testuale, foto e video producendo una sola rappresentazione vettoriale dell’intero contenuto. L’audio viene elaborato nativamente senza passare obbligatoriamente attraverso una trascrizione intermedia e i video vengono campionati, per impostazione predefinita, a un frame al secondo. Google prevede inoltre di rendere EmbeddingGemma 2 disponibile prossimamente nel Model Garden della Gemini Enterprise Agent Platform.
Dal punto di vista dei dati e delle limitazioni operative, EmbeddingGemma 2 è un modello di embedding pre-addestrato e non è stato sottoposto a post-training alignment, safety tuning o moderazione degli output paragonabili a quelli applicati ai modelli generativi. Le misure di sicurezza sono state concentrate principalmente sulla preparazione del dataset, con più stadi di filtraggio per materiale di abuso sessuale sui minori e procedure automatizzate per ridurre la presenza di informazioni personali e altri contenuti sensibili. I dati di addestramento comprendono documenti provenienti dal web, codice, immagini, video, audio e coppie di contenuti cross-modali, mentre la componente testuale web copre più di 140 lingue e utilizza dati con cutoff a gennaio 2025. Il modello supporta oltre 100 lingue, ma Google precisa che le prestazioni non sono necessariamente uniformi in tutti gli idiomi e che, nel caso degli input testuali, l’omissione dei prefissi di istruzione raccomandati per il tipo di task può diminuire la precisione degli embedding. Esiste inoltre una limitazione numerica rilevante per l’inferenza: l’intervallo delle attivazioni può superare quello rappresentabile correttamente in float16, con il rischio di produrre valori NaN oppure embedding degradati senza errori espliciti, per cui Google raccomanda l’utilizzo di bfloat16 o float32. Le applicazioni costruite sul modello devono infine rispettare la Gemma Prohibited Use Policy e resta responsabilità degli sviluppatori applicare eventuali protezioni a livello applicativo, compresi filtri sul retrieval, controlli sui dati recuperati e valutazioni di fairness appropriate al contesto di impiego.
Questo articolo è stato redatto con il supporto di strumenti di intelligenza artificiale (AI)