EmbeddingGemma 2 estende la ricerca semantica a immagini, audio e video

Un modello multimodale per trovare contenuti

Google ha presentato EmbeddingGemma 2 come un’estensione multimodale del precedente modello di embedding testuale. La nuova versione rappresenta testo — compreso il codice —, immagini, audio e video in uno spazio vettoriale condiviso. Serve a recuperare contenuti pertinenti a una query; non è un modello conversazionale progettato per formulare risposte o generare immagini, audio o video.

Il modello ha 740 milioni di parametri e combina un componente testuale con codificatori per la visione e l’audio, caricabili in modo selettivo. Google indica che il componente testuale conta 270 milioni di parametri, il codificatore visivo 170 milioni e quello audio 300 milioni. Questi dati e la configurazione attiva sono importanti per stimare le risorse: un’implementazione solo testuale non carica necessariamente tutti i componenti del modello multimodale.

EmbeddingGemma 2 produce vettori di 768 dimensioni e permette di ridurli a 512, 256 o 128 dimensioni con l’apprendimento di rappresentazioni Matryoshka. I vettori più corti possono ridurre lo spazio di archiviazione e accelerare alcune ricerche, ma la qualità può variare a seconda della dimensione e dell’attività. Dopo aver troncato un vettore, occorre normalizzarlo per confrontarlo con la similarità coseno; inoltre, le query e i documenti dell’indice devono avere la stessa dimensione.

Google distribuisce il modello con licenza Apache 2.0. La licenza non elimina i costi di esecuzione e non determina da sola gli obblighi relativi ai dati usati da un’applicazione. La scheda tecnica indica una finestra di contesto condivisa di 8.192 token per le diverse modalità; il limite effettivo dipende da come gli input vengono combinati e preparati.

Come funziona la ricerca multimodale

Un embedding è una rappresentazione numerica di un elemento, come una frase, un’immagine o un frammento audio. Il sistema confronta i vettori e ordina i risultati candidati in base alla loro similarità. Per esempio, una ricerca di documenti per «calzature per la pioggia» potrebbe recuperare una scheda di stivali impermeabili anche se non contiene esattamente la parola «pioggia». È una possibile corrispondenza, non la prova che il modello abbia compreso l’uso previsto o che la scheda sia corretta.

EmbeddingGemma 2 consente di cercare tra modalità diverse quando l’applicazione prepara i dati per questo scopo: per esempio, mettere in relazione una query testuale con le immagini di un catalogo. Il modello accetta anche input che combinano testo e contenuti multimediali. Per rappresentare un prodotto, un’applicazione può includere la descrizione e le immagini; per cercare in un video, può fornire la query testuale insieme ai fotogrammi elaborati secondo la configurazione scelta.

I prefissi delle attività aiutano a orientare le rappresentazioni testuali. Nella ricerca asimmetrica, query e documenti svolgono funzioni diverse: la query viene preparata come richiesta di ricerca, mentre gli elementi del corpus vengono trattati come documenti. Per attività simmetriche, come raggruppare testi o misurare la similarità tra frasi, si applica lo stesso tipo di istruzione agli elementi confrontati. I prefissi si applicano al testo, non a immagini, audio o video.

Anche la configurazione degli input influenza la quantità di contenuti che può entrare nella finestra di contesto. La scheda tecnica definisce un budget condiviso tra le modalità: combinare testo, immagini, audio e video riduce quindi lo spazio disponibile per ciascuno. Nei video, il campionamento dei fotogrammi e la frequenza influiscono sulle informazioni rappresentate; per l’audio, il formato indicato è mono a 16 kHz. Sono parametri di elaborazione, non garanzie che vengano recuperati tutti i dettagli pertinenti.

Dimensioni, contesto e configurazione locale

I 740 milioni di parametri si riferiscono al modello multimodale completo. Secondo la scheda tecnica, la configurazione solo testuale utilizza 270 milioni di parametri; quella testo e immagine, 440 milioni; quella testo e audio, 570 milioni; il modello completo, 740 milioni. Questi numeri descrivono le configurazioni di caricamento pubblicate, non il consumo totale di memoria di un’applicazione in esecuzione.

Le dimensioni dei pesi e l’uso della memoria dipendono da fattori come la precisione numerica, la libreria, l’hardware, la lunghezza degli input e la dimensione del batch. Google raccomanda bfloat16 quando l’hardware lo supporta e float32 negli altri casi; avverte che float16 può produrre valori non validi o embedding degradati. Il numero di parametri, quindi, non basta per stimare la memoria necessaria o la latenza di una specifica implementazione.

La riduzione Matryoshka permette di scegliere tra vettori di 768, 512, 256 e 128 dimensioni. Nei risultati pubblicati da Google, passando da 768 a 256 dimensioni il vettore si riduce a un terzo e cambiano alcuni punteggi dei benchmark. A 128 dimensioni, alcuni punteggi multimodali diminuiscono maggiormente. Questi risultati appartengono ai test e alle metriche indicati dal fornitore: non stabiliscono quale dimensione sia migliore per uno specifico corpus o un’applicazione concreta.

Per utilizzare i vettori troncati con la similarità coseno, bisogna normalizzarli dopo il troncamento. Il vettore della query e quelli degli elementi indicizzati devono avere la stessa dimensione. Cambiare dimensione richiede di rigenerare o adattare l’indice in modo coerente; confrontare direttamente un vettore di 768 dimensioni con uno di 128 non è un’operazione valida.

Come valutare la qualità del recupero

Un confronto utile parte da un’attività concreta e da criteri di pertinenza definiti prima del test. Un benchmark può misurare il recupero su uno specifico insieme di dati, ma non garantisce lo stesso risultato in un altro idioma, dominio o tipo di contenuto. La scheda tecnica di Google pubblica punteggi per test distinti di testo, codice, immagini, documenti visivi, video e audio; ogni punteggio corrisponde a una metrica e a un insieme di valutazione specifici.

Per valutare una ricerca testo-immagine, prepara query reali e un insieme di immagini con etichette di pertinenza. Per cercare audio o video, definisci cosa consideri un risultato pertinente: una registrazione completa, un segmento o un fotogramma. Se il sistema combina modalità diverse, specifica come vengono preparati e ponderati gli input prima di interpretare le metriche.

Confronta il modello con un’alternativa usando le stesse query, lo stesso corpus, le stesse istruzioni, la stessa dimensione dei vettori e le stesse regole di ranking. Misura separatamente la qualità del recupero, la latenza e le risorse utilizzate. Registra la precisione numerica, l’hardware, la lunghezza degli input e la configurazione delle modalità, così da poter interpretare e ripetere il test.

La valutazione dovrebbe includere gli idiomi e le condizioni d’uso previsti. La documentazione del modello segnala che le prestazioni possono variare tra idiomi e risentire di ambiguità e sfumature linguistiche. Un punteggio aggregato non sostituisce il controllo delle query che l’applicazione riceverà davvero.

Cosa mostrano i risultati e quali sono i loro limiti

Google pubblica risultati ottenuti con diversi benchmark e confronta alcune attività testuali con EmbeddingGemma, il modello precedente. Nel benchmark MTEB multilingue, il punteggio pubblicato per EmbeddingGemma 2 è 61,36, contro 61,15 per il modello precedente; nel test di codice MTEB, il punteggio pubblicato è 78,68, contro 68,76. Queste differenze descrivono i risultati riportati per i test specifici, non garantiscono un miglioramento in qualsiasi sistema di ricerca.

La scheda presenta anche risultati per immagini, documenti visivi, video e audio. Questi valori provengono da benchmark specifici e non dimostrano che il modello comprenda in generale una scena, una conversazione o un evento. Il fatto che una ricerca collochi un video pertinente tra i primi risultati non dimostra che il sistema identifichi tutti i fatti contenuti, risponda correttamente a domande aperte o spieghi perché il video sia rilevante.

Il modello genera rappresentazioni, non risposte conversazionali. Un’applicazione può usare i risultati recuperati come contesto per un altro componente generativo, ma la qualità finale dipende anche da quel componente, dal corpus e dalle regole dell’applicazione. È utile valutare separatamente il recupero e la risposta generata in seguito.

Google indica che EmbeddingGemma 2 è distribuito con licenza Apache 2.0 e mette a disposizione pesi aperti. La scheda tecnica spiega che i modelli di embedding non ricevono un successivo allineamento di sicurezza né una moderazione dell’output come i modelli generativi; le misure di sicurezza dell’applicazione, quali i filtri per il recupero e i test di equità, spettano a chi la distribuisce. La licenza aperta non trasforma una ricerca in una verifica dei fatti e non elimina la necessità di valutare pregiudizi, privacy e usi previsti.

Continua a esplorare

Correzioni e trasparenza

Se trovi un dato errato o non aggiornato, inviaci la pagina e la fonte da verificare.