Embedding Gemma 2: busca multimodal e RAG (Colab gratuito)

Ver no idioma original →

Autoria: Prompt Engineering · Assistir no YouTube

Vídeo de autoria do canal indicado, não da IANIA; todos os direitos pertencem ao criador. Transcrição, resumo e tradução gerados automaticamente; o conteúdo no idioma original é preservado na versão em idioma original.

Idioma original: inglês

Vídeo original: Embedding Gemma 2: Multimodal Search & RAG (Free Colab) · Canal: Prompt Engineering · 18:50 · Assistir no YouTube

Tópicos: Dados, bancos de dados e embeddings, Ferramentas de desenvolvimento com IA, Modelos locais e open source, RAG, busca e recuperação de informação

Resumo

O vídeo apresenta o Embedding Gemma 2, um modelo open source de embeddings multimodais que coloca texto, código, imagens, vídeos e áudio em um espaço vetorial compartilhado. O apresentador explica como o modelo funciona, compara sua abordagem com métodos anteriores e demonstra uma implementação em um notebook do Colab. Nos testes apresentados, o modelo tem bons resultados em busca de fotos, vídeos e documentos, mas é menos confiável para localizar efeitos sonoros. O vídeo também mostra como reduzir as dimensões dos vetores e usar apenas parte do modelo para fazer buscas com menos recursos.

Pontos-chave

• O Embedding Gemma 2 permite buscar entre modalidades diferentes sem converter imagens, vídeos ou áudio em texto primeiro.
• O modelo usa encoders de visão e áudio opcionais e uma backbone compartilhada para produzir embeddings no mesmo espaço vetorial.
• No teste com 1.000 fotos, a imagem correta apareceu em primeiro lugar em cerca de 86% das consultas e entre as cinco primeiras em 97% delas.
• A busca por voz consegue recuperar imagens sem uma etapa de transcrição de fala para texto.
• Nos testes com efeitos sonoros, o clipe correto apareceu primeiro em 24% das consultas; o apresentador recomenda testar o modelo com os próprios dados.
• O modelo pode buscar momentos em vídeos e páginas de documentos convertidas em imagens, sem depender de legendas ou extração de texto.
• Reduzir as dimensões do embedding diminui o armazenamento necessário, mas pode prejudicar a precisão, especialmente em dimensões menores.
• É possível criar um índice com o modelo completo e fazer buscas usando apenas a parte de texto, inclusive em dispositivos com recursos limitados.

Capítulos

Início	Capítulo	Resumo
00:00	O que é o Embedding Gemma 2	Apresentação do modelo multimodal e demonstração inicial de busca por voz entre modalidades.
01:03	Por que a busca multimodal importa	O vídeo explica as limitações da busca baseada somente em texto e descreve abordagens anteriores, de CLIP a modelos multimodais.
04:16	Como o modelo funciona	O apresentador explica os encoders, a backbone compartilhada, a criação dos vetores e as opções de dimensões e carregamento modular.
09:08	Configuração do notebook e testes iniciais	O notebook é executado no Colab, com observações sobre dependências, precisão numérica e comparações entre texto, fotos e sons.
11:46	Busca em fotos, áudio e vídeos	Os testes mostram resultados de busca em fotos multilíngues, consultas por voz e recuperação de momentos em vídeos.
16:15	Documentos, dimensões e conclusão	O vídeo testa busca em páginas de documentos, avalia a redução das dimensões e mostra como pesquisar usando apenas a parte de texto do modelo.

Citações

É um modelo open source de embeddings pequeno que coloca texto, código, imagens, vídeos e áudio no mesmo espaço vetorial. — 00:00

A foto correta aparece primeiro em cerca de 86% das vezes e está entre as cinco primeiras em 97% das vezes. — 12:21

O modelo está captando alguma coisa, mas ainda fica longe dos 86% que vimos para fotos. — 14:34

Para efeitos sonoros, como eu disse, ainda não está lá. — 18:20

Conceitos e entidades

• Embedding Gemma 2 (modelo): Modelo open source de embeddings que representa texto, código, imagens, vídeos e áudio em um espaço vetorial compartilhado.
• Gemini Embedding 2 (modelo): Modelo de embeddings multimodais da Google, disponibilizado como API e citado como referência para a arquitetura do Embedding Gemma 2.
• Colab (ferramenta): Ambiente de notebooks usado no vídeo para executar os testes em uma GPU T4 gratuita.
• Sentence Transformers (ferramenta): Biblioteca instalada no notebook para carregar o modelo e gerar embeddings.
• CLIP (modelo): Abordagem que alinha imagens e texto usando modelos treinados para aproximar imagens e suas descrições no espaço vetorial.
• ImageBind (modelo): Modelo da Meta que estendeu o alinhamento de modalidades ao usar imagens como referência para outras modalidades.
• ColPali (modelo): Abordagem mencionada para representar páginas de documentos por meio de imagens, sem depender de OCR.
• Matryoshka Representation Learning (conceito): Técnica que permite usar prefixos menores de um embedding como vetores de dimensão reduzida.
• mean pooling (conceito): Método que agrega as saídas dos tokens em um único vetor, conforme descrito no vídeo.
• Flickr (empresa): Serviço de fotos cuja coleção de imagens e legendas foi usada em um dos testes do notebook.
• ESC-50 (repo): Conjunto de dados de sons cotidianos usado para testar a busca por áudio.
• Big Buck Bunny (conceito): Filme usado para testar a recuperação de momentos em vídeo.

Tradução completa (pt-BR)

00:00 O Google acabou de lançar o Embedding Gemini 2. E isso é uma grande notícia para quem tem interesse em geração aumentada por recuperação multimodal. É um pequeno modelo de embedding open source que coloca texto, código, imagens, vídeos e áudios no mesmo espaço vetorial. E é pequeno o suficiente para você conseguir executá-lo em um celular. Então, isso vai abrir muitas possibilidades diferentes para desenvolvedores. A melhor parte é que você pode usar o modelo para muito mais do que recuperação. É possível fazer classificação e agrupamento em diferentes modalidades usando exatamente o

00:33 mesmo modelo. Então, neste vídeo, quero mostrar os diferentes recursos que esse novo Embedding Gemini 2 oferece. Mas, antes de mostrar como ele funciona, deixe-me apresentar uma demonstração rápida. >> Um cachorro pulando em um lago. >> Esta demonstração mostra uma busca entre modalidades. A fala é enviada ao modelo, que recupera quatro imagens diferentes. E são as mesmas quatro fotos que obtenho quando digito exatamente a mesma frase. Você não precisa transcrever a fala para texto.

01:03 Certo. Então, neste vídeo, quero abordar por que a recuperação multimodal é importante, como as pessoas resolviam isso antes, como esse modelo funciona por dentro e, depois, vamos percorrer um notebook do Colab que você pode executar por conta própria em uma GPU gratuita. Certo. Mas vamos falar sobre por que você precisaria de algo assim. A maioria dos sistemas de RAG, ou geração aumentada por recuperação, que construímos hoje se baseia especificamente em busca de texto. Você pega seus documentos, divide-os em

01:34 partes, transforma cada parte em um embedding e, quando chega uma pergunta, encontra as partes que estão mais próximas dela nesse espaço de embeddings. Mas pense onde realmente estão a maioria dos nossos dados. São coisas como fotos no celular, gravações de tela, mensagens de voz, notas de reuniões, apresentações de slides e documentos digitalizados. Uma recuperação baseada apenas em texto não consegue enxergá-las de forma alguma. Digamos que você queira encontrar um clipe em que seu cachorro pega um frisbee e não há texto no próprio vídeo.

02:04 Uma recuperação baseada em texto não vai conseguir encontrar esse vídeo específico para você. O mesmo se aplica aos agents, porque a memória deles só é tão boa quanto aquilo que conseguem recuperar. Portanto, a recuperação multimodal é essencial para aplicações de busca. Agora, vamos falar sobre como as pessoas têm resolvido isso. A abordagem mais comum é primeiro transformar tudo em texto. Você executa um modelo de geração de legendas em cada imagem, um modelo de fala para texto em cada arquivo de áudio e, depois, gera embeddings do texto. Funciona,

02:38 mas agora você tem três modelos encadeados. E o problema maior é que você só consegue encontrar aquilo que a legenda ou a transcrição registrou. Por exemplo, se o modelo de legendas disser “um cachorro no parque” e nunca mencionar o frisbee, sua busca não vai retornar aquele clipe. Agora, o artigo do Google sobre o Gemini Embedding 2, que é o modelo maior deles, disponível por API, mediu esse fenômeno especificamente para áudio. Gerar embeddings diretamente do áudio obteve 73,99 no benchmark de recuperação de sons

03:12 contra 70,40 quando geraram embeddings da transcrição. A segunda abordagem veio do CLIP, em 2021. Você treina dois modelos separados, um para imagens e outro para texto. Assim, a foto e sua legenda acabam ficando muito próximas uma da outra. Essa abordagem tornou a busca de texto para imagem muito boa, mas abrange apenas um par de modalidades e é treinada com legendas curtas.

03:42 Então, em 2023, o ImageBind, da Meta, ampliou a ideia para seis modalidades, alinhando cada uma delas às imagens. E, para documentos, o Call Polly começou a gerar embeddings diretamente de capturas de tela das páginas, dispensando o OCR, mas armazenando muitos vetores por página. Assim, o índice cresce muito rápido. Tenho vários vídeos sobre isso, caso tenha interesse. Os links estarão na descrição. A abordagem mais recente usa um modelo com um backbone único que processa todas as modalidades. O Gemini Embedding 2, do Google,

04:16 funciona assim, mas é um modelo disponível por API. E é aí que entra o Embedding Gemini 2. Ele traz o mesmo design para menos de um bilhão de parâmetros, com pesos open source. Certo, então é assim que ele funciona. Primeiro, uma breve recapitulação. Um embedding é basicamente uma lista de números que captura o significado de uma entrada. Entradas com significados semelhantes recebem números semelhantes. Assim, você pode comparar significados, em vez de palavras exatas.

04:47 Um modelo que processa texto não consegue ler pixels ou ondas sonoras diretamente. Por isso, o Embedding Gemini 2 tem dois pequenos encoders na entrada. O encoder de visão, com 170 milhões de parâmetros, recebe uma imagem ou um quadro de vídeo e o transforma em tokens. O encoder de áudio, com 300 milhões de parâmetros, faz o mesmo com o áudio. Esses tokens são então inseridos na mesma sequência que os tokens de texto.

05:17 Então, do ponto de vista do modelo, uma foto é apenas mais algumas centenas de tokens na entrada. Por padrão, uma imagem custa 280 tokens. Um quadro de vídeo custa 140, e um segundo de áudio custa cerca de 25 tokens. O context window tem 8.192 tokens. Portanto, uma entrada pode conter cerca de 29 imagens, cerca de 58 quadros de vídeo ou aproximadamente 5 minutos e meio de áudio.

05:48 E é assim também que se obtém uma entrada mista. Você pode pegar uma página de produto com descrição, uma foto e um vídeo curto e gerar um embedding de tudo isso em um único vetor, o que é muito legal. A vantagem é que tudo isso passa por um backbone compartilhado, que é um modelo de texto com 270 milhões de parâmetros baseado no Gemma 4. No final, o modelo calcula a média da saída de cada token em um único vetor, processo chamado mean pooling, e depois projeta esse vetor em 768 números, ou dimensões.

06:22 Agora, vamos entender como uma foto de um flamingo acaba ficando próxima da frase sobre flamingos. O Google ainda não publicou um relatório técnico sobre esse modelo, mas diz que ele foi criado com a mesma tecnologia do Gemini Embedding. O artigo sobre os modelos Gemini Embedding descreve o treinamento contrastivo. Você mostra ao modelo pares que combinam, como uma foto e sua legenda, ou um clipe e sua transcrição, e o treina para aproximar esses pares e afastar todo o restante do lote.

06:57 Se você repetir esse processo em um conjunto de dados enorme e misto, todas as modalidades acabam no mesmo mapa compartilhado. Certo. Há mais duas escolhas de design que importam quando você quer colocar isso em produção. A primeira é o aprendizado de representações Matryoshka. O modelo é treinado para que os primeiros 512, 256 ou até mesmo 128 desses números, ou dimensões, ainda funcionem por conta própria como um embedding. Então, essencialmente, você pode reduzir essas dimensões para conjuntos menores, e

07:30 elas ainda vão funcionar. Vetores menores significam um índice menor. Então, com 128 números, você armazena seis vezes menos, mas há uma desvantagem. Na tabela do próprio Google, o texto quase não muda com 128 dimensões, enquanto a pontuação multimodal cai de 59 para cerca de 46. E vou mostrar alguns exemplos disso no notebook. Certo, a segunda escolha é o carregamento modular. Os encoders de visão e áudio são opcionais. Se você só tem texto e código, carrega

08:03 esses 270 milhões de parâmetros. Se adicionar visão, são 420 milhões. E, se adicionar áudio, são 570 milhões de parâmetros. O modelo completo tem 740 milhões. Todos eles compartilham o mesmo espaço vetorial, então você pode indexar suas fotos uma vez com o modelo completo e pesquisá-las usando um modelo menor em um celular. Com quantização, o Google diz que a versão apenas de texto precisa de cerca de 191

08:37 MB de RAM em um Pixel 7 Pro. E o modelo completo precisa de cerca de 567 MB. Certo, a vantagem é que ele é muito melhor do que o modelo anterior, Embedding Gemma, e também tem recursos de recuperação bastante poderosos em comparação com alguns dos modelos maiores na mesma área. Vou colocar alguns links para os benchmarks na descrição do vídeo, caso tenha interesse. Certo, chega de teoria. Vamos abrir o notebook e ver

09:08 como isso funciona na prática, incluindo alguns casos em que não funcionou tão bem. Certo, aqui está um notebook. O link estará na descrição. Ele é executado em uma GPU T4 gratuita no Colab em cerca de 15 minutos. Então, primeiro, vamos falar sobre a configuração. A primeira célula instala o sentence transformers com extras para imagens e vídeos. E há duas pegadinhas com que me deparei. O extra para vídeos não

09:39 instalar o torch codec, e sem ele a decodificação de vídeo falha. Então, tive que adicioná-lo por conta própria e pulei o extra de áudio, porque ele instala uma versão mais antiga do NumPy que o pip compila do código-fonte no Colab por vários minutos. O áudio funciona bem sem ele. Então, tenha isso em mente se tiver algum problema aqui. Depois, carregue o modelo novamente, e esta parte é importante. Não execute este modelo em float16. O cartão do modelo diz que ele sofre

10:10 de overflow de ativação e, em vez de um erro, você obtém NaN ou embeddings incorretos. O modelo não oferece suporte nativo a ponto flutuante de 16 bits. Então, aqui usamos float32. Em uma GPU mais recente, use bfloat16, e isso vai funcionar. Para os dados, estou usando 1.000 fotos do Flickr, cada uma acompanhada de cinco legendas escritas à mão por pessoas, 50 clipes de sons cotidianos de um conjunto de dados chamado ESC-50 e, depois, os primeiros 5 minutos de Open

10:40 Movie Big Buck Bunny, e o artigo “Attention Is All You Need” em PDF. Então, essas são diferentes modalidades que vamos testar. Certo, vamos começar com a ideia central da primeira parte. Peguei seis conceitos, como um cachorro, um bebê chorando e ondas do mar, e cada um existe como uma frase, uma foto e um som. Se tudo realmente estiver em um único espaço, como descrito, os pares correspondentes devem ter as pontuações mais altas, o que aparece como

11:11 uma diagonal brilhante aqui. Então, texto para foto forma uma diagonal nítida. Texto para som acerta a maioria. E foto para som é a combinação mais ruidosa, o que faz sentido, de certa forma, porque compara uma imagem diretamente com um clipe de som, sem texto no meio. Agora, lembre-se disso, porque o som volta mais adiante com resultados bem interessantes. Além disso, observe que todas essas pontuações ficam entre cerca de 0,5 e 0,7. Então, use-as para ordenar os resultados e não escolha um limite fixo, a menos que tenha testado isso com seus próprios dados.

11:46 Escolher o limite pode realmente afetar os resultados que você vai obter. Certo, vamos falar de busca por fotos. Agora, vamos criar um índice de verdade. Cada foto recebe um embedding uma única vez, e essa é a parte lenta. Isso leva cerca de 8 minutos em uma T4. Depois disso, cada busca exige um embedding de texto e uma comparação. Então, lembre-se do exemplo do começo: um cachorro pega um Frisbee. Aqui está o mesmo exemplo. As duas fotos no topo mostram um Frisbee no ar. Mas alguns bons exemplos não dizem muita coisa. Então, podemos medir isso de fato.

12:21 Cada foto aqui tem cinco legendas escritas por pessoas, o que nos dá 5.000 consultas para as quais sabemos a resposta correta. Nos meus experimentos, a foto correta aparece em primeiro lugar cerca de 86% das vezes entre as 1.000 fotos, e fica entre as cinco primeiras em 97% das vezes, o que é realmente impressionante para um modelo desse tamanho. Especialmente em tarefas de recuperação, você não quer usar apenas o primeiro resultado; normalmente, as pessoas usam top K. K pode ser cinco

12:53 ou 10. E, para top cinco ou K5, o resultado é realmente bom. Agora, aqui está a melhor parte. O lado de texto entende mais de 100 idiomas, porque Gemma é multilíngue. Então, uma consulta em alemão sobre um cachorro correndo na neve retorna um cachorro na neve. Em espanhol, pedi uma mulher tocando violão, e os dois primeiros resultados estão corretos. O terceiro é uma mulher tocando harpa. Então, é parecido, mas não é bem isso. O melhor é que a consulta não precisa

13:27 ser texto. Se eu usar a foto de uma pessoa surfando como consulta, recebo mais duas fotos de surfe e, depois, pessoas praticando wakeboard. Então, ele encontra pessoas andando de prancha na água, não apenas a cor azul. Isso é incrível. Na verdade, você pode criar sistemas de busca privada com base em fotos da sua própria galeria. É realmente impressionante. Certo. Agora, vamos ver a busca por voz. Este é o exemplo do começo do vídeo. Eu gero uma pergunta falada: “um cachorro pulando em um lago”. E passo o áudio diretamente para o modelo, sem nenhuma etapa de transcrição. Agora, as quatro fotos que ele retornou eram as mesmas que eu obtinha ao escrever a mesma frase em texto. E acontece o mesmo com uma menininha em um balanço, certo? Então, basicamente, ele faz essa busca entre modalidades no mesmo espaço. Certo. Agora, é aqui que ele fica mais fraco. Peguei 50 sons cotidianos, um clipe de cada, e, para cada nome de som, verifiquei se o clipe correspondente aparecia em primeiro lugar. Isso

13:59 um cachorro pulando em um lago. E passe o áudio diretamente para o modelo. Sem uma etapa de transcrição. Agora, as quatro fotos que ele retornou eram a mesma foto que apareceu quando escrevi a mesma frase em texto. E acontece o mesmo com uma menininha em um balanço, certo? Então, basicamente, ele está fazendo essa busca entre modalidades no mesmo espaço. Certo. Agora, é aqui que ele fica mais fraco. Peguei 50 sons do dia a dia, um clipe de cada, e, para o nome de cada som, verifiquei se o clipe correspondente aparecia em primeiro lugar. Isso

14:34 acontece em 24% das vezes. Já um palpite aleatório acertaria 2%. Então, o modelo está captando alguma coisa, mas ainda está longe dos 86% que vimos para fotos, especialmente em K ou na posição um. Dá para ver isso nas consultas. “Alguém rindo” encontra o clipe de risadas. E “uma descarga sendo dada” encontra o som da descarga. Mas “um cachorro latindo” retorna um corvo, e “chuva caindo” retorna vento. O encoder de áudio é mais forte com fala,

15:09 como o exemplo de voz também nos mostrou. Se você precisa de efeitos sonoros ou sons ambientais, acho que vai precisar testá-lo primeiro com seus próprios clipes. Certo. Agora, vamos ver o vídeo. Cortei os primeiros 5 minutos de Big Buck Bunny em trechos de cinco segundos e gerei um embedding para cada um como vídeo. Por padrão, o modelo analisa um frame por segundo, e uma consulta de texto retorna o timestamp. Então, “um pássaro esticando a asa em um galho” aparece aos 15 segundos

15:42 no nosso conjunto de dados. E “um buraco escuro no chão” corresponde à toca do coelho, aos 30 segundos. “O coelho cheirando uma flor branca” aparece em um minuto e cinco segundos. E “a borboleta roxa” aparece aos 3 minutos e 20 segundos. Então, encontrar um momento no vídeo funciona sem nenhuma legenda, o que é incrível. E lembre-se: é exatamente o mesmo modelo, com menos de um bilhão de parâmetros, que funciona em diferentes modalidades. Certo. Agora, vamos ver documentos. Transformei cada página do artigo de atenção

16:15 em uma imagem e gerei um embedding da imagem da página, sem extrair nenhum texto. Agora, pedir “o diagrama da arquitetura Transformer” retorna a página três, que contém essa figura muito famosa, que basicamente deu início a tudo. “Multi-head attention” retorna a página quatro, e “a tabela de blue score” retorna a página oito. Então, tentei dar a cada página quatro vezes mais tokens de imagem, uma configuração que você pode alterar. Isso levou cerca de nove vezes mais tempo e

16:45 encontrou as mesmas páginas. Então, mantenha a configuração padrão, a menos que precise de detalhes finos, como números pequenos em uma tabela densa. Certo. Agora, lembre-se da ressalva sobre as dimensões menores: o modelo oferece suporte a embeddings Matryoshka. Aqui está o resultado nos nossos dados. A foto correta aparece em primeiro lugar 86% das vezes. Com 256 dimensões, são 84%, usando três vezes menos armazenamento. Mas, com 128, cai para 75%.

17:16 Então, você realmente vai precisar experimentar as dimensões finais que quer usar, porque, em determinado ponto, a queda na precisão será bastante significativa. No nosso código, você passa truncate dimension e normalize embeddings para encode e define esses valores. Certo, nesta última seção, vou mostrar como carregar o que você precisa e descartar o que não precisa. Aqui, carrego apenas a parte de texto do modelo, que tem 270 milhões de parâmetros, e pesquiso no índice de fotos

17:48 que criamos com o modelo completo. Lembre-se: você pode criar o índice com o modelo completo e depois usar apenas a parte de texto do modelo para pesquisar imagens, vídeos ou áudios. O embedding da consulta é exatamente o mesmo, assim como o recall. Então, você pode indexar suas fotos uma vez em um servidor e pesquisá-las em um celular com o modelo pequeno. Assim, você pode basicamente fazer buscas em fotos e vídeos com uma nota de voz, sem transformar nada em texto, certo? Então, para fotos, vídeos e

18:20 documentos, sim; funciona muito bem para um modelo desse tamanho. Para efeitos sonoros, como eu disse, ainda não está pronto. O melhor é que você pode fazer fine-tune deste modelo para suas próprias aplicações. Aliás, me diga se tiver interesse: vou fazer um vídeo de acompanhamento sobre como fazer fine-tune do modelo Embedding Gemma 2. E, se você estiver criando busca ou RAG com esse tipo de dado, este é realmente o primeiro modelo open source que eu experimentaria. E, perto do fim do notebook, tenho algumas regras que você pode tentar para

18:50 a recuperação, certo. Enfim, acho que isso é muito empolgante, especialmente o modelo de embedding que está sendo lançado pelo Google, e ele é multimodal. Você pode executá-lo em um celular. Ele pode potencializar projetos como o local GPT. Provavelmente vou incluí-lo no próprio projeto. Mas, enfim, me diga se você achou isso interessante; vou fazer alguns vídeos de acompanhamento. Enfim, espero que este vídeo tenha sido útil. Obrigado por assistir e, como sempre, até o próximo. >> [limpa a garganta]

Transcrição original

[00:00] Google just released embedding Gemini 2. And this is a big news for people who are interested in multimodal retrieval augmented generation. It’s a small open embedding model that puts text, code, images, videos, and audios into the same vector space. And it’s small enough that you can actually run this on a phone. So, it’s going to open up so many different possibilities for developers. The best part is that you can use this beyond retrieval. You can do classification and clustering on different modalities using the exact

[00:33] same model. So, in this video, I want to show you different capabilities that this new embedding Gemini 2 offers. But before I show you how it works, let me show you a quick demo. >> A dog jumping into a lake. >> This demo shows cross modality search. The speech goes into the model, and it will retrieve four different pictures. And these are the same four photos I get if I type the exact same sentence. You don’t need speech to text transcription.

[01:03] Okay. So, in this video, I want to cover why multimodal retrieval matters, how people solved it before this, how this model works under the hood, and then we will walk through a Colab notebook that you can run yourself on a free GPU. All right. But let’s talk about why you would even need something like this. Most of the rag or retrieval augmented generation systems we build today are based specifically on text search. You take your documents, split them into

[01:34] chunks, turn each chunk into an embedding, and when a question comes in, you find the chunks that are closest to it in that embedding space. But think about where most of our data actually lives. These are things like photos on your phone, screen recordings, voice memos, meeting notes, slide decks, scanned documents. A text-only retrieval cannot see it in any way. Say, you want to find a clip where your dog catches a frisbee and there’s no text in the video itself.

[02:04] A text-based retrieval will not be able to find that specific video for you. Now, the same applies to agents because agents’ memory is only as good as what it is able to do retrieve. So, multimodal retrieval is very critical for search-based applications. Now, let’s talk about how people have been solving this. The most common approach is to turn everything into text first. You run a captioning model on every image, a speech-to-text model on every audio file, and then embed the text. It works,

[02:38] but now you have three models chained together. And the bigger problem is that you can only find what the caption or transcription wrote down. For example, if the captioner said “a dog in the park” and never mentioned the frisbee, your search is not going to return that clip. Now, Google’s paper on Gemini Embedding 2, which is their larger API model, measured this specific phenomenon for audio. Embedding the audio directly scored 73.99 on their sound retrieval benchmark

[03:12] versus 70.40 when they embedded the transcript instead. Now, the second approach came from CLIP in 2021. You train two separate models, one for images and one for text. So, that photo and its caption is going to end up very close to each other. Now, this approach made text-to-image search really good, but it only covers one pair of modalities and it’s trained on short captions.

[03:42] Then, in 2023, Meta’s ImageBind extended the idea of six modalities by aligning each one to images. And for documents, Call Polly started embedding screenshots of pages directly, which skips OCR, but it stores many vectors per page. So, the index gets really big really quickly. I have quite a few videos on that if you’re interested. Links to those are going to be in the description. The newest approach is one model with a single backbone that reads every modality. Google’s Gemini embedding 2

[04:16] works this way, but it’s an API model. And this is where embedding Gemini 2 comes in. It brings the same design down to under a billion parameters with open weights. Okay, so here’s how it actually works. First, a quick refresher. An embedding is basically a list of numbers that captures the meaning of an input. Inputs that mean similar things get similar numbers. Uh so, you can compare meaning instead of exact words.

[04:47] Now, a model that reads text cannot read pixels or sound waves directly. So, embedding Gemini 2 has two small encoders in front of it. The vision encoder, which is 170 million parameters, takes an image or a video frame and turns it into tokens. The audio encoder, which is 300 million parameters, does the same thing for audio. Those tokens then go into the same sequence as the text tokens.

[05:17] So, from the model’s point of view, a photo is just a few hundred uh more tokens in the input. By default, an image costs 280 tokens. A video frame costs 140, and a second of audio costs about 25 tokens. The context window is 8,192 tokens. So, one input can hold about 29 images, about 58 video frames, or around 5 and 1/2 minutes of audio.

[05:48] And that’s also how you get mixed input. You can take a product listing with description, a photo, and a short video, and embed all of it into one vector, which is extremely neat. Now, the beauty is that all of this goes through one shared backbone, which is 270 million parameter text model based on Gemma 4. At the end, the model averages the output of every token into one vector, which is called mean pooling, and then projects it into those 768 numbers or dimensions.

[06:22] Now, let’s understand how does a photo of a flamingo end up next to the sentence about flamingo? So, Google hasn’t published a technical report on this model yet, but they say it’s built from the same technology as the Gemini embedding. The paper for Gemini embedding models describes contrastive training. You show the model pairs that belong together, like a photo and its caption, or a clip and its transcript, and you train it to pull those pairs closer and push everything else in the batch away.

[06:57] Now, if you repeat this process over a huge mixed data set, you are going to see that every modality ends up in one shared map. Okay. Now, there are two more design choices that matters when you want to deploy this into production. The first one is Matryoshka representation learning. The model is trained so that the first 512 to 256 or even 128 of those numbers or dimensions still work as an embedding on their own. So, essentially, you can cut those dimension into smaller dimensions, and

[07:30] they will still work. Smaller vectors mean a smaller index. So, at 128 numbers, you store six times less, but there is a catch. In Google’s own table, the text barely changes at 128 dimensions, while the multimodal score drops from 59 to about 46. And I’ll show you some example of this in the notebook. Okay, the second is modular loading. The vision and audio encoders are optional. If you only have text and code, you load

[08:03] those 270 million parameters. If you add vision, that’s 420 million. And if you add audio instead, that is going to be 570 million parameters. The full model is 740 million. Now, all of these share the same vector space, so you can index your photo once at the full model and search them from a phone with a small one. So, with quantization, Google says that the text-only version needs about 191

[08:37] MB of RAM on a Pixel 7 Pro. And the full model is going to be about 567 MB. Okay, so the beauty is that it’s actually much better compared to the previous embedding Gemma model, and also has pretty powerful retrieval capabilities compared to some of the bigger models in the same space. I’ll put some links to the benchmarks in the video description if you are interested. Okay, so that’s enough theory. Let’s open the notebook and see

[09:08] how well this works in practice. Including some places where it did not work that well. Okay, so here’s a notebook. Link is going to be in the description. And it runs on free T4 GPU in Colab in about 15 minutes. So, first let’s talk about the setup. The first cell installs sentence transformers with image and videos extras. And there are two gotchas here that I ran into. The video extra doesn’t

[09:39] install torch codec, and without it video decoding fails. So, I had to add that myself, and I skipped the audio extra because it pulls in an older version of NumPy that pip compiles from source on Colab for several minutes. Audio actually works fine without it. So, keep that in mind if you run into some issues here. Then, reload the model, and this part is actually important. Don’t run this model in float 16. The model card says it’s

[10:10] activation overflow, and instead of an error, you get NaN or wrong embeddings. A default doesn’t support floating point 16 natively. So, here we use the float 32. On a newer GPU, use Bfloat 16, and that will work. For data, I’m using 1,000 Flickr photos that each come with five human handwritten captions, 50 everyday sound clips from a data set called ESC-50, and then uh first 5 minute of the open

[10:40] movie Big Buck Bunny, and uh the activation is all you need paper as a PDF. So, these are different modalities that we’re going to be testing on. Okay, so let’s start with the core idea from the first part. I took six concepts like a dog, a crying baby, and ocean waves, and each one exists as a sentence, a photo, and a sound. If everything really lives in one space as it’s described, the matching pairs should score highest, which shows up as

[11:11] a bright diagonal here. So, text to photo is a clean diagonal. Text to sound gets most of it right. And a photo to sound is the noisiest, which kind of makes sense because it compares a picture directly with a sound clip with no text in between. Now, keep that in mind because sound comes back later with some really interesting results. Also, notice that all these scores sit between about 0.5 and 0.7. So, use them to rank results and don’t pick a fixed cutoff unless you have tested this on your own data.

[11:46] Picking the threshold can really impact on the results that you’re going to get. Okay, let’s talk about photo search. So, now let’s build a real index. Every photo gets embedded once, which is the slow part. This takes about 8 minutes on T4. After that, every search is one text embedding and one comparison. So, remember the example from the start, a dog catches a Frisbee. Here it is, the same example. The top two photos both have Frisbee in the air. But a few good examples don’t tell you much. So, we can actually measure it.

[12:21] So, every photo here has five captions written by people, which gives us 5,000 queries where we know the right answer. Now, in my experiments, the right photo comes back first about 86% of the time out of the 1,000 photos, and it’s in the top five 97% of the time, which is actually pretty impressive for the model of this size. Especially when it comes to retrieval, you don’t want to use the top one, but normally people use top K. K can be five

[12:53] or 10. And for top five or K5, this actually is pretty good. Now, here is the best part. The text side understands over 100 languages because Gemma is multilingual. So, a German query for a dog running in the snow returns dog in the snow. In Spanish, I asked for a woman playing the guitar, and the first two are right. The third one is a woman playing a harp. So, it is close, but not quite. Now, the beauty is that the query doesn’t have to

[13:27] be text either. If I use the surfer photo as the query, I get two more surfing shots and then people wakeboarding. So, it matches people riding boards on water, not just the color blue. Which is pretty amazing. You can actually build private photo-based search things on your own gallery. Which is pretty incredible. Okay. So, next let’s look at voice search. So, this is the demo from the start of the video. I generate a spoken question, a

[13:59] dog jumping into a lake. And pass the audio right to the model. With no transcription step. Now, the four photos it return were the same photo if I write the same sentence in text. And the same happens for a little girl on a swing, right? So, it basically is doing this cross-modality search in the same space. Okay. Now, here’s where it gets weaker. So, I took 50 everyday sounds, one clip each, and for every sound name, I check whether its clips comes back first. That

[14:34] happens actually 24% of the times. Now, random guessing would get 2%. So, the model is picking up something, but that’s the long way from 86% that we saw for photos, especially for K or pass at one. You can see it in the queries. Someone laughing finds the laughing clip. And a toilet flushing finds the toilet. But a dog barking comes back as a crow and a rain falling comes back as wind. So, the audio encoder is strongest on speech,

[15:09] which is what the voice demo showed us as well. If you need sound effects or environmental sounds, I think you’ll need to test it on your own clips first. Okay. Now, let’s look at the video. So, I cut the first 5 minutes of um Big Buck Bunny into five uh second chunks and embed each one in as a video. By default, the model looks at one frame per second and a text query that returns the timestamp. So, a bird stretching its wing on a branch lands at 15 seconds for

[15:42] our data set. And a dark hole in the ground is the rabbit’s burrow at 30 seconds. And the rabbit smelling a white flower is at a minute and five. And the purple butterfly is at 3 minutes 20 seconds. So, finding a moment in the video works without any captions, which is incredible. Uh and keep in mind, it’s exactly the same model under the billion parameter, which works across different modalities. Okay. Now, let’s look at documents. So, I turned every page of the attention

[16:15] paper into an image and embedded the picture of the page with no text extraction at all. Now, asking for the diagram of the Transformer architecture returns page three, which is this very famous figure, which started basically everything. Multi-head attention returns page four, and the table of blue score returns page eight. So, I tried giving each page four times more image tokens, which is a setting that you can change. So, it took about nine times longer and

[16:45] found the same pages. So, keep the default unless you need fine details like small numbers in a dense table. Okay. Now, uh remember the catch with the smaller factors because it does support Matryoshka’s embedding. So, here it is on our data. The right photo comes first 86% of the time. At 256, it’s 84 with three times less storage. Uh but at 128, it drops to 75.

[17:16] So, you will actually need to play around with the final dimensions that you want to use because at um certain point, the accuracy drop is going to be pretty significant. In our code, you pass truncate dimension and normalize embeddings to encode and define those values. Okay, in this last section, I’ll show you uh how do you load things that you need and you drop things that you don’t. So, here I load only the text part of the model, which is 270 million parameters and uh search the photo index

[17:48] we built with the full model. Remember, you can build the index with the full model and then only use the text part of the model to do search over images, videos, or audios. The query embedding comes out exactly the same and so does the recall. So, you can index your photo once on a server and search them uh from a phone uh with the small model. So, you can essentially [snorts] run search over photos, videos with a wise note without turning anything into text, right? So, for photos, videos, and

[18:20] documents, yes, and it works really well for a model this size. For sound effects, as I said, it’s not there yet. The beauty is that you can fine-tune this model for your own applications. By the way, let me know if you’re interested, I’ll make a follow-up video on how to fine-tune the embedding Gemma 2 model. And if you’re building um search or rag over that kind of data, this is really the first open model that I would try. And towards the end of the notebook, I have a few rules that you can try to get

[18:50] the retrieval right. Anyways, this is I think really exciting, especially the embedding model coming out of Google and it’s multimodal. You can run it on a phone. It can power projects like local GPT. I’ll probably include that in the project itself. But anyways, do let me know if you found this interesting, I’ll make some follow-up videos. Anyways, I hope you found this video useful. Thanks for watching and as always, see you in the next one. >> [clears throat]