EmbeddingGemma 2 amplia a pesquisa semântica a imagens, áudio e vídeo

Um modelo multimodal para encontrar conteúdo

A Google apresentou o EmbeddingGemma 2 como uma expansão multimodal do modelo de embeddings de texto anterior. A nova versão representa texto — incluindo código —, imagens, áudio e vídeo num espaço vetorial partilhado. A sua função é ajudar a recuperar conteúdos relacionados com uma consulta; não é um modelo conversacional concebido para redigir respostas nem para gerar imagens, áudio ou vídeo.

O modelo tem 740 milhões de parâmetros e combina um componente de texto com codificadores de visão e áudio que podem ser carregados seletivamente. A Google indica que o componente de texto tem 270 milhões de parâmetros, o codificador de visão 170 milhões e o de áudio 300 milhões. A soma e a configuração ativa são relevantes para estimar os recursos necessários: uma implementação apenas de texto não tem necessariamente de carregar todos os componentes do modelo multimodal.

O EmbeddingGemma 2 produz vetores de 768 dimensões e permite reduzi-los a 512, 256 ou 128 dimensões através da aprendizagem de representações Matryoshka. Vetores mais curtos podem reduzir o armazenamento e acelerar determinadas pesquisas, mas a qualidade pode variar consoante a dimensão e a tarefa. Depois de truncar um vetor, é necessário normalizá-lo para o comparar com similaridade do cosseno; além disso, as consultas e os documentos do índice devem usar a mesma dimensão.

A Google publica o modelo sob a licença Apache 2.0. Essa licença não elimina os custos de execução nem determina, por si só, as obrigações relacionadas com os dados de uma aplicação. A ficha técnica descreve um contexto partilhado de 8.192 tokens para as modalidades; o limite efetivo depende da forma como as entradas são combinadas e preparadas.

Como funciona a pesquisa multimodal

Um embedding é uma representação numérica de um elemento, como uma frase, uma imagem ou um excerto de áudio. O sistema compara os vetores para ordenar candidatos de acordo com a sua semelhança. Numa pesquisa de documentos, por exemplo, uma consulta sobre «calçado para a chuva» pode recuperar uma ficha de botas impermeáveis, mesmo que não contenha exatamente a palavra «chuva». Esse resultado é um candidato relevante, não uma prova de que o modelo compreendeu a utilização pretendida ou de que a ficha está correta.

O EmbeddingGemma 2 permite pesquisar entre modalidades diferentes quando a aplicação prepara os dados para essa tarefa: por exemplo, relacionar uma consulta textual com imagens de um catálogo. O modelo também aceita entradas que combinam texto e meios de comunicação. Para representar um produto, uma aplicação pode incluir a sua descrição e as imagens; para pesquisar um vídeo, pode fornecer o texto da consulta e os fotogramas processados de acordo com a configuração escolhida.

Os prefixos de tarefa ajudam a orientar as representações de texto. Numa pesquisa assimétrica, a consulta e os documentos têm funções distintas: a consulta é preparada como uma pergunta de pesquisa e os elementos do corpus como documentos. Em tarefas simétricas, como agrupar textos ou medir a semelhança entre frases, aplica-se o mesmo tipo de instrução aos elementos comparados. Os prefixos são aplicados ao texto, não a imagens, áudio ou vídeo.

A configuração das entradas também influencia a quantidade de conteúdo que cabe no contexto. A ficha técnica estabelece um orçamento comum às modalidades; por isso, combinar texto, imagens, áudio e vídeo reduz a quantidade disponível para cada uma. No vídeo, a amostragem dos fotogramas e a respetiva frequência afetam a informação representada. No áudio, o formato indicado é mono a 16 kHz. Estes parâmetros descrevem o processamento, mas não garantem que todos os detalhes relevantes sejam recuperados.

Tamanho, contexto e configuração local

Os 740 milhões de parâmetros correspondem ao conjunto multimodal. De acordo com a ficha técnica, a configuração apenas de texto utiliza 270 milhões de parâmetros; texto e imagem, 440 milhões; texto e áudio, 570 milhões; e o modelo completo, 740 milhões. Estes valores descrevem as configurações de carregamento publicadas, não o consumo total de memória de uma aplicação em execução.

O tamanho dos pesos e o uso de memória dependem de fatores como a precisão numérica, a biblioteca, o hardware, o comprimento das entradas e a dimensão do lote. A Google recomenda bfloat16 quando o hardware o suporta e float32 nos restantes casos; adverte que float16 pode produzir valores inválidos ou embeddings degradados. Por isso, o número de parâmetros não é suficiente para estimar a memória necessária ou a latência de uma implementação concreta.

A redução Matryoshka permite escolher entre vetores de 768, 512, 256 e 128 dimensões. Nos resultados publicados pela Google, passar de 768 para 256 dimensões reduz o tamanho do vetor para um terço e altera várias pontuações de benchmark. Com 128 dimensões, algumas pontuações multimodais diminuem mais. Estes resultados correspondem aos testes e às métricas indicados pelo fornecedor; não determinam qual será a melhor dimensão para um corpus ou uma aplicação específicos.

Para utilizar os vetores truncados com similaridade do cosseno, é necessário normalizá-los depois do truncamento. O vetor de uma consulta e os vetores dos elementos indexados devem ter a mesma dimensão. Alterar a dimensão implica gerar novamente ou adaptar o índice de forma coerente; comparar diretamente um vetor de 768 dimensões com outro de 128 não é uma operação válida.

Como avaliar se a recuperação funciona

Uma comparação útil começa por uma tarefa concreta e por um critério de relevância definido antes de executar o teste. Um benchmark pode medir a recuperação num conjunto de dados específico, mas não garante o mesmo resultado noutro idioma, domínio ou tipo de conteúdo. A ficha técnica da Google publica pontuações para diferentes testes de texto, código, imagem, documentos visuais, vídeo e áudio; cada pontuação corresponde a uma métrica e a um conjunto de avaliação determinados.

Para avaliar uma pesquisa texto-imagem, prepare consultas reais e um conjunto de imagens com etiquetas de relevância. Para pesquisar áudio ou vídeo, defina o que conta como resultado pertinente: uma gravação completa, um segmento ou um fotograma. Se o sistema combinar modalidades, especifique como as entradas são preparadas e ponderadas antes de interpretar as métricas.

Compare o modelo com uma alternativa usando as mesmas consultas, o mesmo corpus, as mesmas instruções, a mesma dimensão vetorial e as mesmas regras de classificação. Meça separadamente a qualidade da recuperação, a latência e os recursos utilizados. Registe a precisão numérica, o hardware, o comprimento das entradas e a configuração das modalidades para que o resultado possa ser interpretado e repetido.

A avaliação deve incluir os idiomas e as condições de utilização previstas. A documentação do modelo indica que o desempenho pode variar entre idiomas e ser afetado por ambiguidades e nuances da linguagem. Uma pontuação agregada não substitui a verificação das consultas que a aplicação irá realmente receber.

O que mostram os resultados e quais são os seus limites

A Google apresenta resultados de avaliação em vários benchmarks e compara algumas tarefas de texto com o EmbeddingGemma, o modelo anterior. No MTEB multilingue, a pontuação publicada para o EmbeddingGemma 2 é 61,36, contra 61,15 para o modelo anterior; no teste de código MTEB, as pontuações publicadas são 78,68 e 68,76, respetivamente. Estas diferenças descrevem os resultados reportados para os testes indicados, não uma melhoria garantida em qualquer sistema de pesquisa.

A ficha também apresenta resultados para imagem, documentos visuais, vídeo e áudio. Esses valores vêm de benchmarks específicos e não provam que o modelo compreenda de forma geral uma cena, uma conversa ou um acontecimento. Uma pesquisa que coloca um vídeo relevante entre os primeiros resultados não demonstra que o sistema identifique todos os factos nele contidos, responda com exatidão a perguntas abertas ou explique por que motivo o vídeo é pertinente.

O modelo gera representações, não respostas conversacionais. Uma aplicação pode usar os resultados recuperados como contexto para outro componente generativo, mas a qualidade final também depende desse componente, do corpus e das regras da aplicação. A recuperação e a resposta produzida posteriormente devem ser avaliadas separadamente.

A Google indica que o EmbeddingGemma 2 é distribuído sob a licença Apache 2.0 e disponibiliza pesos abertos. A ficha técnica refere que os modelos de embeddings não recebem ajuste de segurança posterior nem moderação de saída, ao contrário dos modelos generativos; as salvaguardas da aplicação, como filtros de recuperação e testes de equidade, são da responsabilidade de quem a implementa. Uma licença aberta não transforma a pesquisa em verificação factual, nem elimina a necessidade de avaliar enviesamentos, privacidade e utilizações previstas.

Continue a explorar

Correções e transparência

Se encontrar informação incorreta ou desatualizada, envie-nos a página e a fonte que devemos rever.