Il 6 ottobre 2026 Google ha lanciato EmbeddingGemma 2, un modello open‑weight da 740 milioni di parametri con licenza Apache 2.0. Il modello mappa testo, codice, immagini, video e audio nello stesso spazio vettoriale, come dettagliato nella pubblicazione tecnica di DeepMind del 27 ottobre. Per chi vuole capire come funziona un embedding e provarlo senza un abbonamento cloud, è il punto di partenza più concreto dell’autunno.

Perché gli embedding locali contano ora

Un embedding trasforma un contenuto in un vettore di numeri. Due contenuti con significato simile finiscono vicini nello spazio vettoriale, anche se non condividono una sola parola. È il meccanismo che permette di trovare un documento sul backup quando si cerca “copie di sicurezza dei dati”, oppure una foto di tramonto quando si digita “sole che tramonta sul mare”.

Fino a poco tempo fa, ottenere questo risultato su più formati voleva mettere in fila più modelli: uno per il testo, uno per le immagini, un sistema di trascrizione per l’audio. Ogni anello aggiungeva latenza, consumo di memoria e un punto in cui i dati lasciavano la macchina. EmbeddingGemma 2 sostituisce quella catena con encoder modulari che proiettano tutto in un solo spazio a 768 dimensioni.

Secondo il riepilogo di ottobre di Google, ripreso da Mezha, il modello è pensato per la ricerca multimodale privata e offline su dispositivi edge. Google parla di una riduzione dello storage dei vettori fino a 6 volte grazie al design modulare e alla troncatura delle dimensioni. Calcoli alla mano il numero torna, e lo verificheremo al passo 11.

Caratteristiche tecniche di EmbeddingGemma 2

Cinque modalità, un solo spazio vettoriale: il modello accetta testo, codice, immagini (anche documenti visivi come slide e grafici), frame video e audio grezzo. Ogni input produce un vettore di 768 dimensioni confrontabile con tutti gli altri. Una query testuale come “onde del mare al tramonto” può quindi pescare sia una fotografia sia una registrazione sonora.

InfoQ ha raccontato il passaggio dal solo testo della prima versione al multimodale completo. Sul fronte della qualità, Google riporta un miglioramento del 14 % sul benchmark MTEB (Code) rispetto a EmbeddingGemma 1, e dichiara di aver mantenuto l’accuratezza sul testo multilingue della versione precedente. Per chi lavora in italiano la seconda affermazione conta più della prima, ma va comunque verificata sul proprio corpus.

Pesi modulari e configurazioni consigliate

    • Solo testo e codice – 270 M parametri – ideale per appunti, wiki, repository.
    • Testo e visione – 440 M parametri – adatto a fototeche, slide, PDF convertiti in immagini.
    • Testo e audio – 570 M parametri – per riunioni registrate, memo vocali.
    • Multimodale completo – 740 M parametri – per archivi misti con video e voce.

Il contesto è di 8 192 token, quattro volte quello di EmbeddingGemma 1, e il budget è condiviso tra tutte le modalità presenti in una richiesta. Secondo le pagine ufficiali, il modello accetta fino a circa 5,5 minuti di audio, 29 immagini o 58 frame video per chiamata.

Matryoshka Representation Learning e troncatura delle dimensioni

Gli embedding usano la Matryoshka Representation Learning. Si possono tenere solo le prime 512, 256 o 128 dimensioni e rinormalizzare il vettore. Google indica che a 256 dimensioni lo storage scende a un terzo e la qualità resta alta su testo e codice, mentre si mantiene circa il 95 % su immagini, video e voce. A 128 dimensioni il risparmio è sestuplo ma la perdita si sente di più, soprattutto nel multimodale.

Prerequisiti, versioni e hardware consigliati

    • Python 3.12 con ambiente virtuale.
    • sentence‑transformers ≥ 6.1.0 (identificativo modello google/embeddinggemma-2 su Hugging Face).
    • transformers, pillow, soundfile, torchcodec.
    • PyTorch recente; su GPU NVIDIA usare build con supporto CUDA e bfloat16.
    • ffmpeg nel PATH (necessario per indicizzare video o convertire audio).
    • Spazio disco: prevedere qualche gigabyte di margine per cache e indice.
    • Account Hugging Face solo se il repository richiede accettazione delle condizioni d’uso; esportare il token in HF_TOKEN.

Il modello completo occupa circa 1,5 GB in bfloat16 (2 byte per parametro). La versione solo testo in float32 (4 byte) occupa circa 1,1 GB. Un portatile con 16 GB di RAM regge il modello completo; la versione solo testo gira anche su macchine più modeste.

Architettura del progetto semsearch

Il progetto si chiama semsearch e separa le responsabilità in sette moduli più un database SQLite. Ogni modulo è contenuto in un file breve e testabile, facilitando lo sviluppo e la manutenzione. I moduli principali sono:

    • loader: gestisce il download dei pesi e la selezione degli encoder.
    • preprocess: converte testo, codice, immagini, video e audio nei formati richiesti.
    • embedder: chiama sentence‑transformers per generare i vettori.
    • indexer: inserisce i vettori nel file SQLite con metadati.
    • search: confronta la query dell’utente con i vettori indicizzati usando la similarità coseno.
    • utils: funzioni di logging, gestione degli errori e normalizzazione.
    • tests: suite di test che verifica il funzionamento senza scaricare i pesi, usando mock di tensori.

Passi pratici per creare il motore di ricerca locale

Il percorso di dodici passi, della durata complessiva di circa 75 minuti, prevede:

    • Creare e attivare un ambiente virtuale Python.
    • Installare le dipendenze con pip install -r requirements.txt.
    • Scaricare i pesi di EmbeddingGemma 2 (solo i moduli desiderati).
    • Configurare il tipo di precisione (bfloat16 su GPU, float32 su CPU).
    • Preparare il dataset locale (cartelle per testi, codici, immagini, audio, video).
    • Eseguire lo script di preprocessing per ogni tipologia di file.
    • Generare gli embedding con lo script embedder.py.
    • Creare l’indice SQLite tramite indexer.py.
    • Verificare l’indice con la suite di test automatizzati.
    • Truncare le dimensioni a 256 o 128 se necessario per risparmiare storage.
    • Eseguire benchmark di velocità e qualità per convalidare i risultati.
    • Integrare il motore di ricerca in un’applicazione locale o in un server MCP Python.

Il risultato è un motore di ricerca semantica che gira interamente sul portatile, indicizza appunti, codice, foto e registrazioni vocali in un unico file SQLite, risponde a query scritte in italiano e non invia un byte a servizi esterni. La stessa base serve poi ad alimentare un agente: un indice locale diventa lo strumento di recupero di un server MCP in Python, realizzando la promessa della privacy by design richiesta dal GDPR.

Considerazioni finali e prospettive future

EmbeddingGemma 2 non è un modello generativo e non va confuso con Gemma 4, anche se ne condivide l’architettura. Produce esclusivamente vettori; per generare risposte in linguaggio naturale occorre un secondo modello, come indicato nei consigli avanzati della guida. Al 4 novembre 2026 Google non indica alcun prezzo per i pesi locali: la licenza Apache 2.0 consente l’uso commerciale, i costi reali sono hardware ed elettricità.

La possibilità di eseguire embedding multimodali in locale apre scenari interessanti per le aziende europee, dove la protezione dei dati personali è obbligatoria. Con i pesi in locale, ogni operazione resta dentro il perimetro dell’organizzazione, eliminando la necessità di giustificare trasferimenti verso API esterne. Inoltre, la riduzione della latenza e il risparmio di banda rendono la soluzione adatta anche a contesti edge, come dispositivi IoT o workstation remote.

In sintesi, EmbeddingGemma 2 rappresenta un salto qualitativo nella ricerca multimodale offline. Con la guida a dodici passi, anche chi non dispone di infrastrutture cloud può sperimentare una ricerca semantica avanzata, mantenendo il controllo totale sui propri dati. La comunità open‑source è già al lavoro per estendere la suite con modelli di generazione del linguaggio e per ottimizzare ulteriormente la compressione delle dimensioni, promettendo un ecosistema sempre più completo per la privacy e l’efficienza.