Gemini Embedding 2 condensa cinco modalidades num único espaço vetorial

Um espaço de embedding em vez de cinco pipelines

A afirmação central deste lançamento é arquitetural, não incremental. O Gemini Embedding 2 mapeia texto, imagens, vídeo, áudio e documentos para o que a Google chama de um único espaço de embedding unificado. Isto é diferente de juntar encoders separados por modalidade e esperar que os seus vetores se alinhem.

Para as equipas que constroem sistemas de retrieval, o efeito prático é que uma consulta numa modalidade pode recuperar conteúdo noutra sem uma etapa de ligação. A Google apresenta isto como uma simplificação de pipelines complexos, e essa é a leitura honesta: menos modelos separados para hospedar, versionar e manter sincronizados.

O Gemini Embedding 2 mapeia texto, vídeos, áudio e documentos para um único espaço de embedding unificado, e capta a intenção semântica em mais de 100 línguas.Montana Labs

A cobertura de mais de 100 línguas é afirmada, mas não é quantificada além disso. Convém tratá-la como uma afirmação de capacidade a validar com o seu próprio corpus, e não como um resultado de benchmark.

Os limites de input definem o que se pode realmente construir

Os detalhes importam mais do que o título. O texto suporta até 8192 tokens. As imagens permitem até 6 por pedido, em PNG ou JPEG. O vídeo aceita até 120 segundos, em MP4 ou MOV. Os documentos podem ser PDFs de até 6 páginas. Estas são as fronteiras com que se desenha em torno.

Um limite de 120 segundos para vídeo e de 6 páginas para PDF significa que os media mais longos precisam de ser divididos antes de serem processados pelo embedding. Essa estratégia de divisão — como se corta um vídeo, como se janela um documento longo — torna-se numa decisão de engenharia que o modelo devolve à equipa.

O detalhe do áudio é o que mais altera os fluxos de trabalho. A Google afirma que o modelo ingere e processa áudio nativamente sem necessidade de transcrições de texto intermédias. Remover a etapa de conversão de fala para texto elimina uma fonte de erro e de latência que a maioria dos pipelines de pesquisa de áudio ainda carrega.

Input intercalado e dimensões Matryoshka

Além do processamento de modalidade única, o modelo aceita input intercalado — uma imagem mais texto num único pedido — o que lhe permite captar relações entre tipos de media em vez de processar cada um isoladamente. É a diferença entre indexar um diagrama e a sua legenda em separado, ou processá-los como uma única unidade de significado.

No que toca ao armazenamento, o Gemini Embedding 2 mantém o Matryoshka Representation Learning dos modelos de texto anteriores. O output por defeito tem 3072 dimensões, e os desenvolvedores podem reduzir para 1536 ou 768, sendo estes os três tamanhos que a Google recomenda para maior qualidade. Isto dá uma alavanca direta para equilibrar o custo de armazenamento de vetores com a qualidade do retrieval, sem necessidade de retreinar nada.

Disponível onde os stacks de retrieval já existem

O modelo está disponível em preview público através da Gemini API e do Vertex AI, com notebooks interativos do Colab para ambos. Mais relevante para a adoção é a lista de integrações: LangChain, LlamaIndex, Haystack, Weaviate, Qdrant, ChromaDB e Vector Search.

Estas são as frameworks e bases de dados vetoriais em que a maioria dos sistemas RAG já se baseia. Chegar às equipas através das ferramentas de orquestração e armazenamento que já utilizam reduz o custo de mudança ao testar um novo modelo de embedding face ao que já correm hoje.

O que o design de espaço único pede para se reconsiderar

A implicação concreta deste lançamento é que as equipas que mantêm pipelines de embedding separados por modalidade têm agora uma razão concreta para consolidar. Se áudio, imagens, vídeo e documentos podem partilhar um único espaço vetorial, o retrieval entre modalidades deixa de ser um projeto à medida e passa a ser apenas uma consulta.

O trabalho que resta é pouco glamoroso, mas real: validar a qualidade multimodal anunciada com os próprios dados, desenhar a divisão de conteúdo para o que excede os limites de 120 segundos e 6 páginas, e escolher uma dimensão MRL que se ajuste ao orçamento de armazenamento. Trata-se de um preview público, por isso estas decisões devem ser validadas antes de algo depender delas.