Google lança EmbeddingGemma 2 com suporte a código, imagem, vídeo e áudio num único espaço vetorial

O Google lançou nesta segunda-feira (19/10) o EmbeddingGemma 2, um modelo de embeddings open-weight e multimodal construído sobre o Gemma 4 e distribuído sob licença Apache 2.0. A novidade em relação à primeira versão, lançada em 2025, é o escopo: o modelo deixa de lidar só com texto e passa a representar código, imagens, vídeo e áudio dentro do mesmo espaço vetorial. O anúncio foi reportado pelo InfoQ e o modelo já está disponível no Hugging Face.

Para quem constrói busca semântica e RAG↳RAG6 conteúdosTécnica RAG com a biblioteca Langchain: tutorial para aplicar agoraData · jun 2024Como avaliar LLMs, RAG e Agentes de IA: Teoria e prática.AI · abr 2026RAG Não É Memória: O Problema Real dos Agentes de IAAI · mai 2026Ver tudo em AI → no Brasil, o detalhe que importa não é a lista de modalidades suportadas, mas o fato de o modelo rodar inteiro em hardware de consumo: notebook, celular, servidor modesto. Isso muda a conta de quem hoje paga por embeddings via API para indexar bases internas, prontuários, repositórios de código ou catálogos de produto com imagem.

Um espaço vetorial único para cinco modalidades

O recurso central do EmbeddingGemma 2 é representar texto, código, imagens, vídeo e áudio dentro do mesmo espaço de 768 dimensões. Na prática, isso significa que um pipeline de busca pode comparar a similaridade semântica entre uma consulta em texto e um trecho de vídeo, ou entre uma captura de tela e uma descrição em linguagem natural, sem manter índices separados e incompatíveis para cada tipo de mídia.

Segundo o Google, isso habilita cenários como:

• Encontrar documentos, capturas de tela e gravações relevantes a partir de uma consulta em texto;
• Buscar trechos de código-fonte usando linguagem natural;
• Recuperar vídeos a partir de descrições textuais.

O modelo é modular: o desenvolvedor carrega só os encoders que precisa, escalando de 270 milhões de parâmetros (quando o uso é restrito a texto e código) até 740 milhões para suporte multimodal completo. Essa granularidade importa para quem roda em edge: um app de busca de código não precisa carregar os pesos de áudio e vídeo que nunca vai usar.

Código entra como cidadão de primeira classe

O Google afirma que o EmbeddingGemma 2 "supera significativamente o EmbeddingGemma 1 em busca de código e recuperação técnica, tornando-o ideal para indexação local de bases de código e busca de código agêntica". É o ponto que mais conversa diretamente com quem desenvolve: indexar um repositório inteiro localmente, sem enviar código para uma API externa, e permitir que um agente de código busque trechos relevantes por descrição em linguagem natural é um caso de uso que hoje normalmente depende de serviços pagos de terceiros.

Para equipes brasileiras preocupadas com dados sensíveis saindo do país, ou simplesmente com o custo recorrente de chamadas de API para indexar bases grandes, rodar esse encoder localmente muda a equação tanto de privacidade quanto de latência.

Matryoshka: menos espaço, com perda de precisão

O modelo suporta Matryoshka Representation Learning (MRL), técnica que permite truncar os vetores de embedding em versões mais curtas, reduzindo o espaço de armazenamento. O ganho é concreto: armazenar um milhão de vetores de 768 dimensões em precisão bfloat16 ocupa cerca de 1,5 GB de memória; truncando para 128 dimensões, o mesmo milhão de vetores cabe em aproximadamente 250 MB, uma redução de seis vezes.

Esse ganho de espaço tem contrapartida em qualidade de recuperação, e o Google é explícito sobre o trade-off:

A recomendação do próprio Google é usar truncamento só quando armazenamento ou velocidade de busca forem restrição real do projeto. Para quem decide implementar MRL, a ordem das operações importa, como aponta um comentário da comunidade abaixo.

O que a comunidade já apontou sobre o modelo

Na discussão que se formou no Reddit após o anúncio, dois comentários resumem bem o que muda (e o que não muda tanto) na prática. O usuário Distinct-Target7503 destacou o ganho multimodal, mas qualificou a melhoria em tarefas só de texto:

O que impressiona nesse modelo é que ele consegue embutir imagens e áudio em um espaço semântico compartilhado, mas só para texto não é uma melhoria tão grande.

The impressive thing about this one is that it can embedd images and audio in a shared semantic space, but for text only it is not a massive improvement.Distinct-Target7503, usuário do Reddit

Já o usuário Open-Adhesiveness-86 alertou para dois erros comuns de implementação que já tinham afetado a primeira versão do modelo e que, segundo ele, provavelmente ainda se aplicam:

Duas coisas que me pegaram no primeiro EmbeddingGemma e provavelmente ainda se aplicam: os prefixos de tarefa não são opcionais, indexar documentos com o prefixo de consulta em vez de title: none | text: prejudicou visivelmente o recall. E se você truncar para o MRL, corte primeiro e depois normalize com L2 o vetor mais curto; normalizar em 768 dimensões e cortar depois gera vetores fora da norma.

Two things that bit me on the first embeddinggemma and probably still apply: the task prefixes aren't optional, indexing docs with the query prefix instead of "title: none | text: " noticeably hurt recall. And if you truncate for MRL, slice first then L2-normalize the shorter vector, normalizing at 768 and then cutting gives you off-norm vectors.Open-Adhesiveness-86, usuário do Reddit

São dois avisos operacionais concretos para quem for colocar o modelo em produção: respeitar o prefixo de tarefa correto na indexação (usar title: none | text: para documentos, não o prefixo de consulta) e, ao aplicar MRL, truncar o vetor antes de normalizá-lo com L2, nunca depois.

O que muda para quem constrói no Brasil

O EmbeddingGemma original, lançado em 2025, já tinha foco declarado em "cenários offline e sensíveis à privacidade, como busca em arquivos pessoais localmente, pipelines de RAG móveis com Gemma 3n, ou chatbots de domínio específico". O EmbeddingGemma 2 estende esse mesmo compromisso de rodar fora da nuvem para um conjunto maior de tipos de dado.

Para equipes que hoje mantêm pipelines de RAG dependentes de APIs de embedding cobradas por token ou por chamada, a proposta é direta: times que já indexam catálogos com imagem, repositórios de código e gravações de áudio em paralelo, com stacks de embedding diferentes para cada modalidade, passam a ter a opção de consolidar tudo num único modelo, rodando localmente, sob licença permissiva.

O que ainda fica em aberto é o quanto essa unificação se sustenta em produção: um dos comentários da comunidade no Reddit pondera que o ganho de qualidade em tarefas puramente textuais é modesto, e a comunidade já identificou armadilhas de implementação (prefixo de tarefa, ordem de truncamento) que exigem atenção redobrada de quem for adotar o modelo sem testar a fundo antes.

Fonte: InfoQ