EmbeddingGemma 2 porta il retrieval multimodale in locale

Google DeepMind ha pubblicato EmbeddingGemma 2 il 6 ottobre 2026. La model card ufficiale descrive un modello da 740 milioni di parametri che mappa testo e codice, immagini, video e audio — anche combinati nello stesso input — in uno spazio vettoriale condiviso da 768 dimensioni. I pesi sono disponibili su Hugging Face.

Non è un modello generativo. Produce rappresentazioni numeriche confrontabili per ricerca semantica, retrieval-augmented generation (RAG), classificazione, clustering e misure di similarità. Il cambiamento rispetto alla prima EmbeddingGemma è soprattutto l'estensione dal testo a un indice realmente multimodale.

Poiché le modalità finiscono nello stesso spazio vettoriale, una query testuale può essere confrontata direttamente con l'embedding di un'immagine, di un segmento audio o di frame video. Google indica una context window di 8.192 token e, con le impostazioni descritte al lancio, fino a circa 5,5 minuti di audio, 29 immagini o 58 frame video quando viene usata una sola modalità.

Per un archivio aziendale il pattern è concreto: manuali, PDF visuali, screenshot, fotografie tecniche, registrazioni, video e documentazione testuale possono condividere lo stesso livello di retrieval. Questo non elimina segmentazione, metadata, permessi o controllo degli accessi; riduce però la necessità di costruire una pipeline di rappresentazione completamente separata per ogni formato.

La model card separa un componente text-only da 270M parametri, un encoder vision da 170M e un encoder audio da 300M. La configurazione testo+immagini arriva a 440M, testo+audio a 570M e quella completa a 740M.

Nel post di lancio, Google riporta che con quantizzazione su Pixel 11 Pro i pesi text-only richiedono circa 191 MB di RAM attiva e la configurazione multimodale completa circa 567 MB. Sono misure del produttore, non benchmark indipendenti, ma mostrano il target del progetto: retrieval su laptop, smartphone ed edge device, non soltanto attraverso una API cloud.

Questo si collega direttamente alla scelta tra AI locale e cloud: eseguire l'embedding vicino al corpus può ridurre dipendenze esterne e trasferimenti di dati, ma file, vector database, permessi e pipeline di indicizzazione restano componenti da proteggere.

EmbeddingGemma 2 usa Matryoshka Representation Learning. Il vettore nativo da 768 dimensioni può essere troncato a 512, 256 o 128 dimensioni e poi normalizzato nuovamente. Passare da 768 a 256 dimensioni riduce a un terzo lo spazio occupato da ogni vettore; 128 dimensioni portano la riduzione a 6 volte.

Nei risultati pubblicati da Google, MTEB multilingual passa da 61,36 a 60,41 a 256d, MTEB Code da 78,68 a 76,18 e MMEB v2 complessivo da 59,01 a 56,24. A 128d MMEB v2 scende invece a 45,65, e la stessa documentazione raccomanda di validare questa configurazione con particolare attenzione per workload multimodali.

C'è anche un failure mode operativo poco visibile: la documentazione tecnica raccomanda `bfloat16` o `float32` e sconsiglia `float16`, perché il modello può produrre NaN o embedding degradati senza generare necessariamente un errore esplicito. Configurazione numerica e dimensionalità fanno quindi parte del test, non sono dettagli del runtime.

La valutazione pubblicata da Google mette EmbeddingGemma 2 a 61,36 su MTEB multilingual contro 61,15 della prima EmbeddingGemma. Sul testo, quindi, il salto dichiarato è piccolo.

Su MTEB Code il punteggio passa invece da 68,76 a 78,68. Se il risultato si trasferisce a repository reali, il caso d'uso diventa interessante per semantic code search, retrieval per coding agent e navigazione di codebase locali. Per immagini, documenti visuali, video e audio non esiste un confronto diretto con EmbeddingGemma 1, perché quelle modalità non erano supportate.

Al lancio, la maggior parte dei numeri dettagliati arriva ancora da Google. La model card dichiara supporto per oltre 100 lingue ma avverte anche che la qualità può non essere uniforme tra lingue. Per un corpus italiano o tecnico, i benchmark pubblici non sostituiscono una valutazione sul proprio materiale.

La model card indica licenza Apache 2.0 e specifica anche che i deployment devono aderire alla Gemma Prohibited Use Policy. La disponibilità dei pesi ha una conseguenza particolare per gli embedding: i vettori prodotti oggi possono restare in un database per anni, e cambiare modello significa normalmente ricalcolare il corpus.

Simon Willison ha evidenziato questo punto commentando il lancio: anche chi preferisce usare un servizio hosted può voler scegliere un modello con pesi disponibili, così da poterlo eseguire altrove se il provider smette di offrirlo.

Per un sistema aziendale il modello di embedding va quindi trattato come parte dello schema dell'indice, insieme a dimensionalità, strategia di chunking e metadata. Sostituirlo assomiglia più a una migrazione dati che al cambio di una API stateless.

EmbeddingGemma 2 rende plausibile un retrieval multimodale locale con un footprint contenuto, ma il test dovrebbe partire da un corpus rappresentativo: documenti italiani, PDF con layout reali, immagini, screenshot, registrazioni, video e codice a seconda del sistema da indicizzare. Servono poi query per cui sia già noto quali elementi dovrebbero essere recuperati.

A quel punto si possono confrontare configurazione text-only e multimodale, 768 contro 256 dimensioni, recall, latenza, memoria e dimensione dell'indice. È lo stesso principio usato nella nostra nota su come valutare un LLM locale prima della produzione: modello, runtime e workload vanno misurati insieme.

Il vantaggio del locale non è semplicemente evitare il cloud. È poter mettere modello, corpus e indice dentro un confine operativo definito e sapere, con test riproducibili, quale qualità di retrieval quel sistema mantiene nel tempo.