Os modelos de IA mais poderosos são executados em instalações remotas na nuvem com acesso por meio de uma API web, o que significa que você precisa confiar no seu provedor de serviços de IA para segurança, disponibilidade do serviço e preços estáveis. Você não consegue alinhar facilmente demandas razoáveis de confiabilidade, privacidade, custos gerenciáveis e boa governança de dados com o uso de IA cada vez mais poderoso, sofisticado e intensivo em recursos.

Regulamentações governamentais, decisões judiciais e considerações comerciais feitas no interesse de terceiros recentemente resultaram na restrição do acesso a serviços específicos. E mesmo que você possa alternar para outros serviços, os modelos de IA não são componentes que podem simplesmente ser trocados sempre que você quiser. Aplicações que usam embeddings semânticos dependem de ter acesso aos mesmos modelos no momento da consulta e no momento da ingestão de dados. Perder o acesso ao seu modelo de embedding significa que seu sistema de busca para completamente.

Os modelos de precificação de IA agravam esse risco. Divulgações financeiras recentes de grandes fornecedores de IA dão aos clientes bons motivos para se preocuparem com potenciais aumentos de preços. A dependência de produtos com custos imprevisíveis adiciona mais risco a investimentos em IA que exigem uso intensivo de capital e podem não produzir retornos claros.

O Jina On-Prem é a resposta da Elastic para esses desafios.

Quem precisa de IA no local?

A hospedagem local e o controle direto sobre seus modelos de IA são compatíveis com uma variedade de demandas técnicas, requisitos do setor e interesses de negócios.

A instalação local reduz o que você paga aos seus provedores de serviços de IA, mas transfere o custo de hardware e de acesso confiável para a sua organização. Dependendo do seu volume de uso, pode simplesmente ser mais barato. Mas há outras razões urgentes para considerar a execução da sua própria IA. Se algum dos problemas descritos abaixo afetar a sua empresa, considere uma solução de IA local como o Jina On-Prem. Esta lista não é exaustiva.

Caso de uso

Por que no local

Exemplo

Air-gapped / alta segurança

Sem transmissão de dados de saída; isolamento completo de rede

Defesa, inteligência, pesquisas classificadas

Conformidade regulatória

Soberania de dados; sem transmissão transfronteiriça ou exposição a terceiros

Saúde (Health Insurance Portability and Accountability Act [HIPAA]), finanças, empresas da UE (Regulamento Geral de Proteção de Dados [GDPR])

Crítico para a latência

Zero dependência de rede; nenhuma tolerância a falhas de conexão

Robótica, computação de borda, veículos, navios

Previsibilidade de custo

Custo fixo de infraestrutura vs. preço por token com taxas futuras incertas

Cargas de trabalho de inferência contínua de alto volume

Redução de passivos

Sem exposição de dados a terceiros; mantém o privilégio legal e o dever de cuidado

Escritórios de advocacia, agências governamentais

Por que sistemas air-gapped e com firewall precisam de IA no local

Sistemas air-gapped e com firewall não podem usar APIs de IA externas. O Jina On-Prem é executado inteiramente em sua infraestrutura, sem conexões de saída.

Para organizações que gerenciam dados especialmente sensíveis, as considerações de segurança e privacidade são fundamentais. Pouco adianta investir na proteção dos seus dados sensíveis se você os entrega prontamente a terceiros remotos que podem ter segurança insuficiente ou estar sujeitos às exigências de um governo estrangeiro.

Funcionários de organizações que lidam com dados sensíveis costumam receber algum treinamento sobre o tratamento seguro de dados, mas isso não é muito eficaz quando todos eles têm navegadores web que podem estar abertos em qualquer página da internet enquanto lidam com esses dados. O isolamento é a medida de segurança mais eficaz disponível, seja por meio de air-gapping ou de firewalls muito restritivos, mas isso dificulta o uso de serviços externos de qualquer tipo.

IA no local para sistemas sensíveis à latência e de alta disponibilidade

O software como serviço e a computação em nuvem representam um meio-termo entre o custo de oferecer serviços altamente acessíveis e confiáveis em seus próprios computadores e a terceirização do problema para outra pessoa. Mas eles vêm acompanhados de latência variável, interrupções e uma perda total de controle quando algo dá errado. Os serviços de IA não são exceção. Se o seu sistema de busca ficar offline quando você não puder acessar seu modelo de embedding, isso pode não parecer mais um bom meio-termo.

Além disso, confiar em IA externa sempre envolverá riscos que você não pode prever ou gerenciar facilmente. O acesso à internet e a latência da rede podem se deteriorar sem aviso prévio, como resultado de eventos políticos, mau tempo ou navios arrastando suas âncoras sobre cabos de fibra óptica submarinos. Os governos podem, e recentemente o fizeram, usar proibições de exportação para bloquear de repente o acesso a modelos de IA. Às vezes, os provedores de serviços de IA descontinuam modelos para induzir você a mudar para outros mais recentes. A flexibilidade e os custos gerenciados dos serviços externos precisam ser ponderados em relação aos riscos de dependência.

IA no local para conformidade com o GDPR, a HIPAA e a soberania dos dados

Organizações que coletam dados pessoais estão sujeitas a regulamentações cada vez mais rigorosas, que geralmente diferem entre as jurisdições e podem ter requisitos contraditórios. Notavelmente, as regras da HIPAA impõem proteções de dados muito rigorosas aos provedores de saúde norte-americanos, e leis gerais de proteção de dados fortes no Canadá, na União Europeia e em muitas jurisdições asiáticas exigem que todas as empresas que lidam com informações pessoais o façam de forma segura e limitem a transmissão desses dados a outras partes ou outras jurisdições. Essas regras podem até impor obrigações a entidades estrangeiras se elas tiverem clientes nessas jurisdições. As instituições financeiras estão frequentemente sujeitas a regras ainda mais rigorosas e possuem a mesma responsabilidade direta pela segurança da informação que têm para se protegerem contra outras formas de atividade criminosa.

A conformidade regulatória pode ser incompatível com serviços de IA de terceiros, especialmente se usá-los envolver a transmissão transfronteiriça de dados.

Além disso, eventos recentes mostram que regras que restringem a localização física dos armazenamentos de dados podem não ser uma fonte confiável de proteção quando operadores internacionais de nuvem estão sujeitos à pressão de governos estrangeiros. Leis locais podem entrar em conflito entre jurisdições, exigindo o armazenamento e processamento local de dados e tornando impossível o uso de serviços de terceiros. Em alguns casos, a única solução é internalizar todas as partes dos seus processos, incluindo seus sistemas de IA.

Riscos de responsabilidade por IA na transmissão de dados de terceiros

Leis de proteção de dados e deveres de cuidado reconhecidos em relação a dados sensíveis rotineiramente têm implicações de responsabilidade, às vezes muito severas. Você pode ser responsabilizado pelo tratamento dos seus dados por provedores de serviços terceirizados. Embora os tribunais e procedimentos legais possam fornecer algumas proteções retrospectivas contra provedores de serviços inseguros, esses recursos não estão disponíveis nem são geralmente eficazes contra agentes de segurança nacional, autoridades policiais ou hackers criminosos.

Para os governos, já houve casos em que provedores de serviços em nuvem internacionais liberaram informações estatais sensíveis para agentes estrangeiros.

Mas mesmo que você não se preocupe com governos estrangeiros ou hackers, e mesmo que seus provedores de serviços de IA externos sejam seguros, o simples fato de serem externos pode criar responsabilidades.

Por exemplo, na maioria das jurisdições, as comunicações dos advogados com seus clientes contam com proteções jurídicas especiais, e os escritórios de advocacia têm responsabilidades rígidas ao gravar ou armazenar essas informações. Nos Estados Unidos, esse "sigilo advogado-cliente" é tão famoso que é central nos enredos de filmes e séries de TV. Mas uma das maneiras pelas quais esse privilégio pode ser perdido é ao comunicar informações a alguém que não seja protegido por ele, e desenvolvimentos recentes sugerem que provedores externos de serviços de IA podem se enquadrar nisso.

É possível, pelo menos nos Estados Unidos, que o simples uso de serviços de IA de terceiros por meio de uma API de internet, como modelos de incorporação que oferecem serviços de indexação, viole regras críticas de confidencialidade. Um escritório de advocacia pode ser processado, punido disciplinarmente ou ter o registro cassado só por usar software hospedado externamente, mesmo que nenhuma violação de segurança ocorra.

IA no local para sistemas offline, de borda e fisicamente isolados

Os sistemas de computador não são isolados apenas por motivos de segurança. Por exemplo, veículos em movimento não podem depender do acesso à internet para nenhuma função essencial. Navios e aeronaves têm sistemas de computador de bordo muito extensos que precisam funcionar sem conexões com a internet e, portanto, não podem usar serviços de IA externos. Plataformas offshore, instalações remotas em áreas selvagens, serviços de computador no Ártico, na Antártida e em pequenas ilhas sem conexões físicas adequadas com redes globais são todos exemplos de instalações que se beneficiam ao hospedar localmente todos os serviços de que precisam. À medida que o papel da IA na computação empresarial cresce, torna-se mais importante abordar essas limitações.

Aplicações emergentes de IA em sistemas físicos (robótica e outros casos de uso delimitados espacialmente ou focados no mundo externo, como sistemas de gestão de logística ou até mesmo caixas de supermercado) podem estar conectadas à internet global, mas não têm tolerância a falhas de conexão ou picos de latência. Se elas dependem de um sistema de IA para operar, esse sistema de IA precisa ser o mais local e confiável possível.

Quem não precisa de IA em ambiente local?

Serviços de software remotos e IA fora do local têm benefícios. Executar modelos de IA pode exigir processadores caros, de alto consumo de energia e com vida útil notoriamente curta. O acesso a hardware de alta qualidade é particularmente difícil no momento devido a fatores de mercado e choques econômicos externos. Diante das circunstâncias, pode fazer sentido pagar por token para usar uma API externa em vez de arcar com os altos custos de capital da IA local.

APIs externas fazem mais sentido para usuários intermitentes. Se você usa modelos de IA principalmente para processar dados em lote para análise, em vez de executar um sistema de busca que precise ficar online o tempo todo, faz pouco sentido investir em hardware de alto custo de capital e instalações locais.

Além disso, quando o seu processamento de dados já é baseado na nuvem, por exemplo, um website de e-commerce hospedado na nuvem por motivos de confiabilidade e acessibilidade, usar serviços de IA localizados na mesma infraestrutura de nuvem pode proporcionar um melhor custo-benefício do que introduzir a sua própria implantação de modelo de IA licenciado. Você já depende do seu provedor de serviços em nuvem, então depender dos serviços de IA dele não adiciona muito risco.

Se o seu caso de uso se encaixa nessa descrição, os modelos Jina AI estão disponíveis no EIS, no AWS Marketplace e no Google Cloud Platform especificamente para atender às suas necessidades.

A tabela abaixo resume os principais fatores. Sua resposta depende dos seus dados, da sua infraestrutura e do seu padrão de uso.

Fator

No local preferido

API da Nuvem Preferida

Padrão de uso

Inferência contínua ou de alto volume

Processamento intermitente ou em lote

Sensibilidade dos dados

Regulado, soberano ou confidencial

Sem restrições transfronteiriças ou de terceiros

Ambiente de rede

Air-gapped, com firewall ou instáveis

Internet estável, sempre ativa

Infraestrutura existente

Possuir ou poder adquirir hardware de GPU

Já hospedado na nuvem com IA colocalizada

Modelo de custo

Hardware fixo + licença; previsível em escala

Por token; menor custo inicial, variável a longo prazo

Tolerância a latência

Nenhum (robótica, edge, tempo real)

A variabilidade da rede é aceitável

Responsabilidade operacional

Sua equipe gerencia o hardware e a disponibilidade

O provedor gerencia o hardware e as atualizações; você gerencia a integração

Você precisa considerar os custos e benefícios à luz de suas circunstâncias específicas e casos de uso, levando em consideração os problemas destacados na seção anterior que se aplicam a você. A análise de custo-benefício sem dúvida mudará ao longo do tempo. Não podemos prever o futuro do setor de IA ou os preços de hardware, mesmo no curto prazo.

Apresentando Jina no Local

Para usuários que podem se beneficiar de serviços de IA locais, estamos apresentando o Jina On-Prem, um conjunto de instalação totalmente independente para os modelos de alto desempenho da Jina AI.

Os modelos do Jina AI correspondem à precisão de modelos de embedding muitas vezes maiores que eles, reduzindo custos computacionais, uso de memória e requisitos de hardware. Isso os torna uma escolha ideal para usuários que desejam ou precisam manter sua IA no local. Licenças comerciais estão disponíveis com solutions escaláveis e de preços proporcionais para casos de uso de todos os tamanhos.

A quais esquemas de API o Jina no local oferece suporte?

• Disponível como uma coleção completa de dependências para instalação local ou como um container do Docker que você pode instalar e executar em minutos.

• Instalações Jina no local não fazem chamadas para sistemas externos.

  • Nenhuma chamada ao Hugging Face Hub ou a qualquer registro de modelo (HF_HUB_OFFLINE=1 e TRANSFORMERS_OFFLINE=1 estão embutidos).

  • Não há servidor de licença.

  • Não há endpoints de telemetria ou logging.

• Oferece suporte a hardware de CPU e GPU, com detecção automática de GPU.

• Todos os 28 modelos Jina AI disponíveis, incluindo os mais recentes modelos de embedding multimodal jina-embeddings-v5-omni e o jina-reranker-v3.

• Acesso via esquemas padrão de API de IA: Jina API, OpenAI, Cohere, Voyage AI e Gemini. O Jina On-Prem é uma solução de substituição direta para aplicações construídas com base nesses esquemas.

• Substituição direta para modelos servidos pelo EIS. O Jina On-Prem se integra diretamente com implantações da Elastic em ambientes isolados.

Requisitos de hardware para modelos Jina AI no local

Os requisitos de hardware variam para diferentes modelos Jina. A tabela abaixo mostra as recomendações para os modelos mais recentes usando configurações de GPU. Você não precisa de nada mais potente do que uma GPU NVIDIA L4, embora uma A100 seja recomendada para os modelos de embedding v5. Nosso modelo de embedding mais recente exige atualmente no mínimo 8 GB de VRAM.

Modelo

VRAM mínima

GPU Recomendada

jina-embeddings-v5-text-nano

2 GB

T4 / L4

jina-embeddings-v5-text-small

3 GB

L4 / A10G

jina-embeddings-v5-omni-small

8 GB

L4 / A10G / A100

jina-reranker-v3

3 GB

L4

jina-clip-v2

4 GB

L4

jina-code-embeddings-1.5b

4 GB

L4

ReaderLM-v2

4 GB

L4

Se você usar mais de um modelo por vez, os requisitos de VRAM aumentarão. Consulte a página de dimensionamento e hardware para obter mais informações.

Como Instalar o Jina no Local com o Docker

A maneira mais rápida de começar é instalar o Docker (se você ainda não o fez) e seguir as instruções na página do Guia rápido do Jina no local.

Há containers do Docker pré-compostos para todos os 28 modelos Jina. Baixe um e transfira-o para o seu destino de instalação, e você poderá ter os modelos Jina AI em execução em menos de cinco minutos.

Para compilações multimodais ou personalizadas, ou para baixar o conjunto completo de dependências para instalação fora de um container, siga as etapas descritas no guia de empacotamento.

Sua instalação Jina no local oferece suporte a todas as funcionalidades da Jina API e do EIS e à geração de embeddings por meio das APIs da OpenAI, Cohere, Voyage AI e Gemini, de modo que ela pode ser integrada a aplicativos preexistentes usando interfaces padrão. Consulte a documentação da API para obter mais informações.

Os modelos Jina, incluindo os modelos instalados com o Jina no local, estão disponíveis sob vários termos de licenciamento, sendo que os modelos mais recentes são gratuitos para uso não comercial sob uma licença CC BY-NC 4.0. Para licenciar o Jina no local para uso comercial, entre em contato com as vendas da Elastic.

Agora você pode criar embeddings semânticos de alto desempenho para texto, imagens, vídeos e gravações de áudio, abrangendo quase 100 idiomas, e utilizá-los para classificação, clustering, medição de similaridade semântica e indexação para recuperação de informações. Se seus dados estão em PDFs, gravações e vídeos junto com texto, você não precisa mais de pipelines separados para cada um.

A família jina-embeddings-v5-omni é o modelo de embedding mais compacto atualmente no mercado, com suporte para imagens, fala, documentos impressos e vídeo. Ela oferece:

• jina-embeddings-v5-textEmbeddings de texto de última geração para aplicações de recuperação, análise e agentes de IA.

• Embeddings com o melhor desempenho da categoria em termos de tamanho para similaridade semântica visual, compreensão visual e recuperação de imagens. jina-embeddings-v5-omni-small tem o melhor desempenho em benchmarks de imagem de qualquer modelo nos parâmetros de 1 bilhão (10⁹) e é superior ao nosso próprio jina-clip-v2 anterior. Apenas alguns modelos com três a trinta vezes mais parâmetros conseguem superá-lo.

• Embeddings de última geração para compreensão e recuperação visual multilíngue, superando modelos até 20 vezes maiores.

• Os melhores embeddings de áudio da categoria de tamanho, com apenas modelos que têm o dobro ou mais de parâmetros apresentando melhor desempenho em benchmarks padrão.

• Suporte a vídeo, especialmente para localizar objetos e eventos em vídeos.

Isso tem aplicações em todas as áreas de recuperação de informações, processamento de documentos e análise de dados. O jina-embeddings-v5-omni abre o acesso a informações bloqueadas em diferentes silos de mídia e as torna acessíveis para recuperação, análise e uso por agentes de IA. As informações em gravações de áudio e vídeo, PDF, digitalizações de páginas impressas e infográficos estão em pé de igualdade com os textos digitalizados em seu ecossistema de dados.

Assim como jina-embeddings-v5-text, esses modelos vêm em dois tamanhos: small e nano. Ambos os modelos estendem suas versões em texto com módulos adicionais que suportam entrada de áudio e vídeo. Os usuários podem selecionar módulos no momento do carregamento. Além disso, extensões específicas de tarefa para similaridade semântica, classificação, agrupamento e recuperação de informações são implementadas como adaptadores compactos de baixo nível (LoRAs) e todas são carregadas, para que os usuários possam selecioná-las no momento da inferência.

Ambos os modelos são muito compactos. jina-embeddings-v5-omni-small pode ser executado em servidores convencionais com GPU, e jina-embeddings-v5-omni-nano é pequeno o suficiente para executar em hardware comum. Isso representa uma grande economia potencial nos custos de computação e possibilita a instalação local licenciada e o processamento na borda, reduzindo a latência e aumentando o controle de seus próprios dados.

A suíte v5-omni usa técnicas inovadoras de design de modelos e Machine Learning para compor novos modelos de embedding a partir de modelos previamente treinados, sem precisar treiná-los novamente. Usamos codificadores de modelos pré-treinados, alinhados linguisticamente e incorporados para mídia de áudio e vídeo como pré-processadores de entrada para nosso conjunto de modelos jina-embeddings-v5-text existente. Os modelos resultantes geram embeddings para imagens e gravações de som que são semanticamente compatíveis com as embeddings gerados para textos.

Os modelos v5-omni produzem embeddings de texto idênticas a jina-embeddings-v5-text (isto é, jina-embeddings-v5-omni-small com jina-embeddings-v5-text-small; e jina-embeddings-v5-omni-nano com jina-embeddings-v5-text-nano), para que você possa estender repositórios de recuperação de texto existentes para aplicativos multimídia sem reconstruir seus índices.

Os codificadores integrados são todos derivados de modelos de pesos abertos. Para imagens e vídeos, utilizamos codificadores dos modelos Qwen3.5:

• Para jina-embeddings-v5-omni-nano, o codificador SigLIP2 Base ajustado de Qwen3.5-0.8B.

• Para jina-embeddings-v5-omni-small, o codificador SigLIP2 So400m ajustado de Qwen3.5-2B.

• Para suporte de áudio, adicionamos o codificador do Whisper-large-v3, extraído do Qwen2.5-Omni-7B, às versões small e nano.

Conectamos esses codificadores específicos de mídia ao backbone de processamento de texto com projetores multimodais treinados. Esses projetores traduzem suas saídas nativas para embeddings de entrada compatíveis com jina-embeddings-v5-text. As únicas partes recém-treinadas dos modelos jina-embeddings-v5-omni são os pesos nesses projetores.

Essa arquitetura significa que só precisamos treinar os projetores entre modelos, cerca de 5,5 milhões de parâmetros para jina-embeddings-v5-omni-small e menos de 3,5 milhões para jina-embeddings-v5-omni-nano, para cada um dos quatro adaptadores de Low-Rank Adaptation (LoRA). Essa abordagem minimiza o treinamento adicional necessário para conectar diferentes modelos de embedding, aproveitando o treinamento especializado de cada um para produzir um conjunto modular de embedding extremamente compacto e de alto desempenho.

Propriedades selecionadas do modelo

Entrada/saída

Nome do modelo

Tamanho da janela de contexto de entrada

Tamanho do embedding

jina-embeddings-v5-omni-small

32.768 tokens*

1024 dimensões (mínimo: 32)

jina-embeddings-v5-omni-nano

8.192 tokens*

768 dimensões (mínimo: 32)

* Consulte Usando jina-embeddings-v5-omni abaixo para obter mais informações sobre como mídias não textuais são tokenizadas.

Tamanho

Nome do modelo

Tamanho total

jina-embeddings-v5-omni-small (modelo base apenas texto + 4 adaptadores LoRA)

700M params

Suporte a imagens/vídeos (codificador SigLIP2 So400m extraído do Qwen3.5-2B)

1.006B params

suporte a áudio (encoder Whisper-large-v3 extraído do Qwen2.5-Omni-7B)

1.354B params

ambos

1.660B params

adaptadores LoRA (cada)

20M

jina-embeddings-v5-omni-nano (modelo base apenas texto + 4 adaptadores LoRA)

266M params

Suporte a imagens/vídeos (codificador base SigLIP2 extraído de Qwen3.5-0,8B)

354M params

suporte a áudio (encoder Whisper-large-v3 extraído do Qwen2.5-Omni-7B)

916M params

ambos

1.004B params

adaptadores LoRA (cada)

7M

* Consulte Usando jina-embeddings-v5-omni abaixo para obter mais informações sobre como mídias não textuais são tokenizadas.

Treinamento específico para tarefas

A família jina-embeddings-v5-omni dá suporte aos mesmos adaptadores LoRA específicos para tarefas que jina-embeddings-v5-text:

Tarefa

Exemplos de uso

Recuperação

Recuperação de informações, isoladamente ou em conjunto com outras técnicas de recuperação e avaliação de resultados. Com os modelos v5-omni, você pode recuperar áudio, vídeo e imagens em uma única consulta de um único índice.

Clustering

Descoberta de tópicos e organização automática de conteúdos em todas as mídias.

Classificação

Categorização, análise de sentimento e tipos de tarefas relacionadas.

Similaridade semântica

Deduplicação de dados em diferentes mídias, sistemas de recomendação, mídias relacionadas, encontrar textos para corresponder à fala, identificar traduções e tarefas similares.

Os embeddings de saída dependem da categoria de tarefa selecionada. Por exemplo, você não deve usar embeddings orientados à recuperação para agrupamento nem embeddings de similaridade semântica para classificação.

Multimídia, multimodal, multilíngue, multifuncional

Para mostrar o que jina-embeddings-v5-omni é capaz, vamos pegar as famosas passagens iniciais de dois romances e medir sua semelhança semântica:

Um Conto de Duas Cidades (Charles Dickens)

Orgulho e Preconceito (Jane Austen)

Usando jina-embeddings-v5-omni-small, com seu adaptador de similaridade semântica, esses textos têm uma similaridade de 0,5329.

Esse número não significa muito sem algo para comparar, então vamos comparar esses dois textos com suas traduções francesas usando o mesmo modelo e adaptador:

Pontuações de similaridade semântica para textos entre línguas

Um Conto de Duas Cidades (inglês)

Orgulho e Preconceito (inglês)

Um Conto de Duas Cidades (francês)(Paris et Londres en 1783, trad. H. Loreau)

0,9095

0,5074

Orgulho e Preconceito (Francês) (Orgueil et Préjugés, tr. Leconte et Pressoir)

0,4826

0,8784

Os dois textos mostram muito mais similaridade com suas traduções do que com outros textos no mesmo idioma ou em outro idioma. Isso reflete os embeddings semânticos multilíngues de altíssimo desempenho de jina-embeddings-v5-text-small, incluídas inalteradas em jina-embeddings-v5-omni-small.

Adicionar suporte multimídia ao jina-embeddings-v5-omni significa que podemos estender este experimento para outros tipos de dados. Por exemplo, obtivemos digitalizações das primeiras páginas de ambos os romances em edições impressas antigas:

Figura 2: Um Conto de Duas Cidades, edição do século XIX sem data, e Orgulho e Preconceito, edição Macmillan de 1903.

Vamos comparar os dois textos com as digitalizações, usando novamente o adaptador de similaridade semântica:

Pontuações de similaridade semântica entre textos e imagens

Um Conto de Duas Cidades (digitalização)

Orgulho e Preconceito (digitalização)

Um Conto de Duas Cidades (texto)

0,7336

0,4891

Orgulho e Preconceito (texto)

0,4804

0,7213

Você vê que as pontuações de similaridade semântica favorecem fortemente textos que correspondem ao conteúdo das imagens.

Podemos também comparar os textos com uma captura de tela de uma postagem nas redes sociais e um meme que fazem referência a esses textos, usando a mesma estrutura:

Figura 3: Um tuíte de Elon Musk que faz referência a A Tale of Two Cities (Um Conto de Duas Cidades) e um meme que faz referência à famosa abertura de Pride and Prejudice (Orgulho e Preconceito).

Pontuações de similaridade semântica entre textos e imagens

Um Conto de Duas Cidades

Orgulho e Preconceito

Tweet de Musk (imagem)

0,7156

0,4912

Meme Keep Calm (imagem)

0,4555

0,6244

Podemos fazer o mesmo para a fala. Obtivemos gravações da leitura de ambos os textos, em inglês e francês:

• A Tale of Two Cities (áudio em inglês da Librivox).

• Um Conto de Duas Cidades (áudio em francês gerado pela OmniVoice AI).

• Orgulho e Preconceito (áudio em inglês da Librivox).

• Orgulho e Preconceito (áudio em francês gerado pela OmniVoice AI).

Pontuações de similaridade semântica entre textos e áudios entre línguas

Um Conto de Duas Cidades (áudio em inglês)

Um Conto de Duas Cidades (áudio em francês)

Orgulho e Preconceito (áudio em inglês)

Orgulho e Preconceito (áudio em francês)

Um Conto de Duas Cidades (texto em inglês)

0,3816

0,3106

0,1607

0,1774

Um Conto de Duas Cidades (texto em francês)

0,3528

0,3253

0,1598

0,1721

Orgulho e Preconceito (texto em inglês)

0,1910

0,1682

0,3511

0,3398

Orgulho e Preconceito (texto em francês)

0,1667

0,1474

0,3018

0,3702

Essa capacidade multilíngue e multimídia se estende à recuperação de informações.

Os adaptadores de recuperação para os modelos jina-embeddings-v5-omni implementam recuperação assimétrica. Isso significa que eles codificam consultas de maneira diferente da forma como incorporam documentos-alvo de recuperação, então as consultas multimodais estão sempre em alguma direção, com consultas em uma mídia e documentos em outra, dando pontuações diferentes de quando são invertidas.

As tabelas abaixo mostram as pontuações de recuperação para texto, áudio e imagens de digitalização de páginas de Um Conto de Duas Cidades e Orgulho e Preconceito, quando o texto de Um Conto de Duas Cidades (em inglês) é codificado como a consulta:

Texto para texto

Documento

Pontuação de recuperação

Um Conto de Duas Cidades (trecho de texto em francês)

0,7597

Orgulho e Preconceito (trecho do texto em inglês)

0,1482

Orgulho e Preconceito (trecho de texto em francês)

0,0523

Texto para imagem

Documento

Pontuação de recuperação

Um Conto de Duas Cidades (digitalização da página em inglês)

0,5517

Um Conto de Duas Cidades (digitalização da página em francês)

0,3576

Orgulho e Preconceito (digitalização da página em inglês)

0,1917

Texto para áudio

Documento

Pontuação de recuperação

Um Conto de Duas Cidades (áudio em inglês)

0,3277

Um Conto de Duas Cidades (áudio em francês)

0,1980

Orgulho e Preconceito (áudio em inglês)

0,1419

Orgulho e Preconceito (áudio em francês)

0,1759

Os usuários também podem executar a consulta no sentido oposto, realizando recuperação de áudio-texto e imagem-texto.

Abaixo estão as pontuações usando o áudio em inglês de Um Conto de Duas Cidades como consulta e vários textos como documentos:

Imagem para texto

Documento

Pontuação de recuperação

Um Conto de Duas Cidades (trecho do texto em inglês)

0,3352

Um Conto de Duas Cidades (trecho de texto em francês)

0,2650

Orgulho e Preconceito (trecho do texto em inglês)

0,1626

Orgulho e Preconceito (trecho de texto em francês)

0,1385

E as pontuações usando uma digitalização da primeira página de Um Conto de Duas Cidades (em inglês) como consulta:

Áudio para texto

Documento

Pontuação de recuperação

Um Conto de Duas Cidades (trecho do texto em inglês)

0,5304

Um Conto de Duas Cidades (trecho de texto em francês)

0,4845

Orgulho e Preconceito (trecho do texto em inglês)

0,1467

Orgulho e Preconceito (trecho de texto em francês)

0,0761

Busca de vídeo

As capacidades do jina-embeddings-v5-omni para indexação de vídeo e busca trazem novas capacidades aos bancos de dados Elasticsearch, mas estão sujeitas a muitos dos mesmos avisos que se aplicam aos textos. Gerar um único embedding para um filme longo é como incorporar um romance muito longo: informações detalhadas serão diluídas, e o embedding resultante será uma boa correspondência para muitas consultas muito espúrias.

Se você incorporar o texto completo de O Senhor dos Anéis (aproximadamente 500.000 palavras), é provável que ele corresponda à maioria das consultas, independentemente do que você esteja procurando. Da mesma forma, se você indexar um filme de Hollywood de duas horas, obterá muitas correspondências espúrias e detalhes totalmente perdidos. jina-embeddings-v5-omni é ideal com clipes curtos.

Para este exemplo, baixamos o trailer do filme Bonequinha de Luxo, de 1961, que tem apenas 158 segundos de duração e está em domínio público. Você pode assistir ao trailer no Internet Archive.

Figura 4: O pôster teatral de Bonequinha de Luxo.

Nós usamos PySceneDetect para dividir o trailer em 28 cenas individuais, com durações variando de 1,877 segundos (45 quadros) a 18,393 segundos (441 quadros). A detecção de cena é imperfeita, mas fornece um mecanismo adequado para dividir o vídeo em trechos menores para recuperação. Então, geramos embeddings de documentos para cada um dos 28 segmentos, usando jina-embeddings-v5-omni-small, para que pudéssemos testar a eficácia das consultas de texto na localização de elementos específicos no vídeo.

Por exemplo, a consulta por “cat” retornou os seguintes trechos como os três principais resultados. A única cena com um gato está no topo, com uma pontuação de 0,1634:

Assista ao primeiro vídeo.

A próxima melhor correspondência, com uma pontuação de 0,1237, é muito menor:

Assista ao clipe 2.

Você também pode buscar ações. Se você pesquisar por "beijo", as quatro melhores correspondências mostram beijos:

Assista ao clipe 3. Sua pontuação é 0,2864.

Pontuações: Para a segunda correspondência (0,2494), terceira correspondência (0,2099) e quarta correspondência (0,2068), respectivamente.

E você pode buscar textos exibidos em vídeos, como "Buddy Ebsen", que só aparece uma vez. jina-embeddings-v5-omni-small identifica-o prontamente como o melhor resultado com uma pontuação de 0,3885, consideravelmente maior do que o próximo melhor resultado:

Clipe do Buddy Ebsen.

Recuperação visual de documentos

Os modelos multimodais de embedding da Jina AI estão entre os melhores em processamento de documentos visuais e são de última geração em processamento visual multilíngue de documentos. Isso significa lidar com dados de imagens que contenham texto, figuras e informações estruturadas. Os dados importantes geralmente estão na forma de digitalizações impressas, arquivos PDF, diagramas, desenhos técnicos, capturas de tela, imagens, infográficos e similares. Esses tipos de imagens geralmente são compostos mecanicamente ou gerados por computador. Eles geralmente não podem ser reduzidos a texto sem perda de significado e são pouco adequados para modelos de visão computacional projetados para fotografar cenas naturais.

jina-embeddings-v5-omniOs embeddings abrangem informações sobre os objetos na imagem, o texto impresso neles e as relações entre eles. A recuperação visual de documentos possibilita indexar imagens ricas em informações que contêm tanto elementos quanto texto relevante, inclusive em diferentes idiomas.

Como exemplo, vamos usar quatro imagens de produtos de vários sites de comércio eletrônico:

Agora, vamos ver como jina-embeddings-v5-omni-small avalia essas quatro imagens para a consulta "miocarrão ramen":

Campbell’s Frango com Macarrão Grosso (embalagem canadense)

Kraft Dinner (embalagem canadense)

Ramen fresco sabor Maruchan Miso (embalagem japonesa)

Birkel Spaghetti (embalagem alemã)

0,0872

0,0711

0,1123

0,0886

Ele encontra facilmente a correspondência japonesa.

Agora, vamos tentar uma consulta para "マカロニチーズ" (japonês para macarrão com queijo):

Campbell’s Frango com Macarrão Grosso (embalagem canadense)

Kraft Dinner (embalagem canadense)

Ramen fresco sabor Maruchan Miso (embalagem japonesa)

Birkel Spaghetti (embalagem alemã)

0,2207

0,3487

0,2760

0,2674

Ele encontra a correspondência correta com a mesma facilidade que uma consulta em inglês.

jina-embeddings-v5-omni também se destaca na interpretação de imagens ricas em informações, como gráficos. Para ver isso em ação, veja estes dois gráficos de barras:

Dois gráficos, Gráfico 1 à esquerda, sobre a carga global de doenças, e Gráfico 2 à direita, sobre a longevidade das raças de cães.

Vamos ver como eles correspondem a duas questões de texto potenciais, cada uma relevante para um, mas não para ambos os gráficos, usando jina-embeddings-v5-omni-small para recuperação:

Pergunta de texto

Gráfico 1

Gráfico 2

“Quais são alguns problemas médicos comuns para idosos?”

0,2787

0,1099

"Quanto tempo os cachorros vivem?"

0,1350

0,3564

Você também pode reverter a busca, usando imagens como consultas para encontrar textos. A tabela abaixo mostra documentos-alvo extraídos dos resumos de artigos científicos relacionados ao tópico e suas pontuações de recuperação, usando as imagens do gráfico como consultas:

Texto 1

Texto 2

A saúde das populações que vivem em extrema pobreza tem sido um foco de longa data dos esforços de desenvolvimento global e continua sendo uma prioridade durante a era dos Objetivos de Desenvolvimento Sustentável. No entanto, não houve uma tentativa sistemática de quantificar a magnitude e as causas da carga nessa população específica por quase duas décadas. Estimamos as taxas de doenças por causa para o bilhão mais pobre do mundo e comparamos essas taxas com as de populações de alta renda.

O cão de companhia é uma das espécies mais fenotipicamente diversas. A variabilidade entre raças se estende não apenas à morfologia e aspectos do comportamento, mas também à longevidade. Apesar desse fato, poucas pesquisas têm sido dedicadas à avaliação da variação na expectativa de vida entre raças ou à avaliação do potencial para caracterização filogenética da longevidade.

Gráfico 1

0,2377

0,1357

Gráfico 2

0,0673

0,3576

Recursos

Embeddings truncáveis

Treinamos os modelos de base jina-embeddings-v5-text que sustentam jina-embeddings-v5-omni com Aprendizado de Representação Matryoshka, para que você possa truncar embeddings de texto e multimídia desses modelos.

Por padrão, jina-embeddings-v5-omni-small gera embeddings com 1.024 dimensões, consumindo 2KB para armazenar com precisão de 16 bits. Os embeddings do jina-embeddings-v5-omni-nano têm 768 dimensões, ocupando cerca de 1,5KB. Você pode reduzir o tamanho desses embeddings para 32 dimensões (64 bytes) a algum custo para a precisão, mas com grande ganho na velocidade de processamento e redução dos custos de recursos. Em geral, reduzir o tamanho dos embeddings pela metade diminui a precisão em cerca de 2%, até 128 dimensões, abaixo das quais a precisão cai muito mais rápido.

Embeddings truncáveis permitem que os usuários decidam o melhor compromisso entre precisão, velocidade e custo, de acordo com seus casos de uso.

Quantização

A família jina-embeddings-v5-omni também herda desempenho robusto com quantização de sua estrutura principal jina-embeddings-v5-text. Isso aumenta ainda mais a velocidade e reduz os custos de computação e armazenamento ao armazenar números menos precisos. Nós os treinamos para funcionar com Elasticsearche sua Quantização Binária Aprimorada (BBQ), para fornecer desempenho quase idêntico ao de embeddings não quantizados. No conjunto de benchmarks de recuperação Massive Text Embedding Benchmark (MTEB), a binarização reduz o desempenho em menos de 3% em comparação com valores completos de 16 bits, enquanto economiza 93% do espaço e aumenta drasticamente as velocidades de processamento e recuperação.

Desempenho multilíngue

jina-embeddings-v5-textO extenso treinamento multilíngue também está presente em jina-embeddings-v5-omni, com quase 100 idiomas na pré-formação de jina-embeddings-v5-text-small e 15 principais línguas globais em jina-embeddings-v5-text-nano. Para mídia de áudio, o modelo Whisper-large-v3 possui aproximadamente 100 idiomas em seu treinamento, e os modelos de visão SigLip2 modificados por Qwen, integrados em jina-embeddings-v5-omni-small e -nano, foram treinados com dados de 201 idiomas e dialetos distintos.

Desempenho em benchmarks

Texto

jina-embeddings-v5-omni Os modelos são idênticos aos modelos jina-embeddings-v5-text quando usados apenas para texto. São os modelos com melhor desempenho no conjunto de benchmarks MMTEB em suas respectivas categorias de tamanho para embeddings semânticos de texto.

Figura 5: Tamanho e desempenho de jina-embeddings-v5-omniem benchmarks de texto, em comparação com modelos concorrentes. O tamanho citado é sem carregar extensões para outras mídias.

Similaridade semântica visual

Nos benchmarks padrão de similaridade semântica visual, jina-embeddings-v5-omni apresenta as melhores pontuações de qualquer modelo próximo ao seu tamanho. jina-embeddings-v5-omni modelos apresentam, de longe, o melhor desempenho entre os modelos públicos de pesos abertos de tamanho comparável. jina-embeddings-v5-omni-small só é superado por um modelo três vezes maior em tarefas de similaridade semântica visual, e jina-embeddings-v5-omni-nano é superado apenas por jina-embeddings-v5-omni-small e por modelos 10 a 25 vezes maiores.

Figura 6: Benchmark de pontuação média de similaridade semântica visual para os modelos jina-embeddings-v5-omni-small, jina-embeddings-v5-omni-nano e comparáveis, além de seus tamanhos, incluindo extensões de visão.

Recuperação visual de documentos

jina-embeddings-v5-omni-small é competitivo com modelos de três e sete bilhões de parâmetros, permanecendo abaixo de um bilhão de parâmetros. jina-embeddings-v5-omni-nano também se destaca pelo tamanho, superando modelos de dez a sessenta vezes maiores.

Figura 7: Pontuações médias de recuperação visual de documentos do ViDoRe em seis benchmarks: DocVQA, InfoVQA, ShiftProj, SynAI, Tabfquad e TatDQA.

Recuperação de áudio

Nos benchmarks padrão de recuperação de áudio MAEB (Massive Audio Embedding Benchmark), tanto jina-embeddings-v5-omni-small quanto jina-embeddings-v5-omni-nano estão entre os melhores desempenhos. Apenas modelos muito grandes — mais de três vezes maiores que jina-embeddings-v5-omni-small — superam sua pontuação.

Figura 8: Pontuação média para vários modelos nos benchmarks de recuperação de áudio MAEB.

Embora o modelo larger_clap_general da LAION melhore a pontuação do jina-embeddings-v5-omni-nano ao ter menos parâmetros, é um modelo apenas de áudio, sem nenhum dos recursos multimodais adicionais do conjunto v5-omni.

Vídeo

No vídeo, jina-embeddings-v5-omni-small se destaca em encontrar o lugar em um vídeo que corresponde a uma consulta de texto. Os testes Charades-STA e MomentSeeker são os benchmarks padrão para essa tarefa, e você pode ver nos gráficos abaixo que jina-embeddings-v5-omni-small é o modelo com melhor pontuação entre modelos de pesos abertos comparáveis, apesar de seu tamanho muito menor.

Figura 9: Pontuações Charades-STA para vários modelos, junto com seus tamanhos.

Figura 10: Pontuações do MomentSeeker para vários modelos, junto com seus tamanhos.

Também comparamos jina-embeddings-v5-omni-small com o Seed 1.6 da ByteDance, um modelo de peso fechado com contagem de parâmetros não divulgada. Nosso modelo supera o Seed 1.6 por uma grande margem no benchmark Charades-STA e quase iguala no MomentSeeker.

Modelo

Pontuação Charades-STA

Pontuação do MomentSeeker

seed-1.6-embedding

29,30

59,30

jina-embeddings-v5-omni-small

55,57

58,93

Pontos fortes e limitações

jina-embeddings-v5-omni Os modelos ampliam a capacidade dos usuários de indexar, buscar e analisar informações digitalizadas de várias maneiras, particularmente:

• Recuperação de fala multilíngue a partir de consultas de texto.

• PDF, digitalizações e busca visual de documentos.

• Localização temporal em vídeos, ou seja, identificar trechos dos vídeos que correspondem a descrições em linguagem natural.

• Classificação de gêneros de áudio, incluindo gêneros musicais.

• Classificação de imagem baseada em informações da cena e identificação de objetos.

O desempenho é mais limitado em outras áreas. Pode ser possível usar jina-embeddings-v5-omni para realizar essas tarefas, mas não treinamos para elas e os resultados podem ser ruins.

Estamos trabalhando ativamente para aprimorar nossa tecnologia nestas áreas:

• Encontrar vídeos específicos a partir de descrições em linguagem natural.

• Similaridade semântica e recuperação de imagens (imagem para imagem).

• Classificação de intenção na fala, como reconhecer comandos verbais.

• Processamento de entradas multimídia, ou seja, imagens e textos acompanhantes, ou áudio, imagens e textos combinados.

Usando jina-embeddings-v5-omni

Este conjunto de modelos permite entrada por meio de três pontos de entrada: texto, áudio, imagens e vídeo juntos. jina-embeddings-v5-omni é executado em um framework que converte uma ampla variedade de formatos padronizados e realiza outros pré-processamentos.

Processamos as imagens usando a mesma abordagem NaFlex fornecida na versão inicial do SigLip2: se a entrada for menor que 262.144 pixels (equivalente a 512x512), ela é ampliada até ficar maior que esse mínimo; e se for maior que 3.072.000 pixels, ela é reduzida até ficar menor que esse máximo. O processo de conversão garante que a altura e a largura da imagem sejam múltiplas de 14 pixels, com a menor distorção possível na proporção para atingir esse objetivo. O resultado é dividido em patches de 28x28 pixels, então o número total de patches é quantos quadrados de 28x28 forem necessários para cobrir a imagem. Cada patch é tratado como um único token no momento da inferência, e cada entrada de imagem é acompanhada por tokens especiais de início e fim para delimitar uma única imagem.

Os modelos jina-embeddings-v5-omni modificam a resolução do vídeo da mesma forma que as imagens são modificadas (veja acima), e extraímos até 32 quadros do vídeo. Se o vídeo tiver mais de 32 quadros (o que é provável, já que os formatos padrão geralmente têm pelo menos 24 quadros por segundo), espaçaremos uniformemente os quadros que extraímos. Então, para cada dois quadros, o pré-processador de vídeo gera um conjunto de tokens igual ao número de quadrados 28x28 necessários para cobrir o vídeo.

Figura 11: jina-embeddings-v5-omni extrai 32 quadros igualmente espaçados do vídeo. Se você tiver um vídeo longo, isso significa que muita coisa será perdida.

Para mais detalhes sobre pré-processamento de vídeo, veja a documentação técnica do SigLip2.

A tokenização de áudio segue a abordagem incorporada ao Qwen-2.5-Omni: Os arquivos de som são cortados em segmentos de 30 segundos; se tiverem mais de 30 segundos, serão reamostrados para 16 kHz e transformados em um mel espectrograma de 128 canais Cada 40 ms é tratado como um único token, portanto, cada segmento de 30 segundos é tratado como 750 tokens, um token por 40 ms de áudio, além de tokens especiais de início e fim para delimitar uma única amostra.

Para mais detalhes sobre pré-processamento de áudio, veja o Relatório Técnico Qwen-2.5-Omni.

Disponibilidade

Tanto jina-embeddings-v5-omni-small quanto jina-embeddings-v5-omni-nano estão disponíveis no Elastic Inference Service (EIS), por meio da API Jina, e para instalação local por download (small e nano). Os pesos dos modelos são distribuídos gratuitamente para teste em uma licença não comercial. Entre em contato com as vendas da Elastic para uso comercial.

Para começar

Para usar jina-embeddings-v5-omni para texto, você pode integrar usando o campo semantic_text assim como com jina-embeddings-v5-text. Basta definir o inference_id para .jina-embeddings-v5-omni-small ou .jina-embeddings-v5-omni-nano. Consulte o Guia de Referência para obter instruções.

Para incorporar outras mídias com jina-embeddings-v5-omni, você precisa usar a API de inferência. Por exemplo:

Para jina-embeddings-v5-omni-nano, mude o URI POST para _inference/embedding/.jina-embeddings-v5-omni-nano.

Para codificar documentos em outras mídias ou gerar embeddings para classificação ou clustering, você precisa criar um endpoint de inferência com o serviço jinaai.

Para consultas, use o construtor de consultas como no exemplo abaixo. Troque o valor inference_id por .jina-embeddings-v5-omni-nano para usar o modelo nano em vez de small.

Saiba mais na documentação do construtor de consultas.

Para usar BBQ com jina-embeddings-v5-omni, siga as instruções para indexação BBQ.

Mais informações

Para mais informações sobre jina-embeddings-v5-omni, consulte o relatório técnico e a página do modelo no website da Jina AI. A página da coleção jina-embeddings-v5-omni no Hugging Face também contém informações técnicas e instruções para baixar e executar esses modelos localmente. Os modelos jina-embeddings-v5-omni podem ser baixados sob uma licença CC-BY-NC-4.0, portanto, você pode experimentá-los livremente, mas para uso comercial, por favor, entre em contato com a equipe de vendas da Elastic.

Com essa integração, os usuários do Elasticsearch ganham uma nova opção de implantação que mantém os dados dentro do perímetro de segurança, entrega custos de infraestrutura previsíveis e roda de forma nativa no Google Cloud. Ao mesmo tempo, o ecossistema mais amplo do Google Cloud ganha acesso aos modelos de busca e recuperação de última geração desenvolvidos especificamente pelo Jina.

Esta é a primeira etapa de uma implementação mais ampla. Junto com os modelos que virão a seguir, a linha formará uma pilha completa de recuperação: incorpore seus dados, incorpore consultas, recupere e reclassifique candidatos, e estenda a busca para imagens com embeddings multimodais, tudo na infraestrutura que você controla. Você pode começar hoje com jina-embeddings-v3, o modelo que já alimenta pipelines de busca em produção em todo o ecossistema Elasticsearch via Elastic Inference Service (EIS).

Modelo

Tipo

Parâmetros

Principal recurso

Status do Model Garden

`jina-embeddings-v3`

Embedding de texto

572 milhões

Ferramenta multilíngue comprovada, contexto 8K, saída de 1024 dimensões, truncável para 32

Disponível agora

`jina-embeddings-v5-text-small`

Embedding de texto

677M

Multilíngue sub-1B de última geração, contexto de 32K, saída de 1024 dimensões, truncável para 32

Em breve

`jina-embeddings-v5-text-nano`

Embedding de texto

239 milhões

O melhor da categoria com menos de 500 milhões de parâmetros, contexto de 8K, saída de 768 dimensões, truncável até 32

Em breve

`jina-reranker-v3`

Reclassificador

600 milhões

Reclassificador listwise, contexto de 131 mil, até 64 documentos

Em breve

`jina-clip-v2`

Embedding multimodal

900M

Texto e imagem em espaço compartilhado, 89 idiomas e contexto de texto de 8K, imagens 512 × 512

Em breve

Cada modelo roda em uma única placa NVIDIA L4 (24 GB), a camada de GPU mais econômica do Google Cloud. A maioria dos outros modelos de incorporação no Google Cloud Model Garden exige um A100 de 80 GB ou H100, aproximadamente três vezes o custo da instância por hora antes mesmo de você começar a contar os tokens.

Não é necessária licença comercial adicional quando implantada via Vertex AI.

Por que o Model Garden?

Por que implantar pelo Model Garden em vez de usar uma API? Tudo se resume a três coisas: controle, custo e contexto.

Seus dados nunca saem do ambiente seguro

O principal atrativo para a maioria dos desenvolvedores é a arquitetura de autoimplantação. Quando você implanta um modelo Jina pelo Model Garden, os pesos são executados em instâncias de GPU dentro do seu próprio projeto Google Cloud e da sua própria VPC. Isso é um divisor de águas para qualquer pessoa que trabalhe em setores com preocupações com segurança de dados, como finanças ou saúde. Como não há chamadas externas de API, seus dados sensíveis permanecem dentro do seu perímetro de segurança.

Redimensionamento com previsão

Em vez de pagar toda vez que você incorpora uma frase ou reclassifica um documento, você paga um custo fixo por hora de instância. E como todo modelo Jina pode rodar em uma única NVIDIA L4, a camada de GPU mais acessível do Google Cloud, a barreira de entrada é baixa. Seja processando mil solicitações ou um bilhão, sua conta de infraestrutura permanece previsível. Essa é uma configuração que realmente recompensa você por aumentar seu tráfego, em vez de te taxar por isso.

Tudo sob o mesmo teto

Se seus dados já estão no Elasticsearch na Google Cloud, BigQuery ou Cloud Storage, faz sentido manter seus mecanismos de inferência próximos. Ao serem implementados por meio do Model Garden, os modelos da base de pesquisa Jina herdam todos os recursos corporativos que você já utiliza: gerenciamento de identidade e acesso (IAM) para controle de acesso, faturamento unificado na fatura existente do Google Cloud e a capacidade de integração com o Vertex AI Pipelines para fluxos de trabalho de operações de aprendizado de máquina (MLOps).

Embora a API Jina AI Cloud e o Elastic Cloud ofereçam o caminho mais rápido para picos de tráfego ou fluxos de trabalho de busca existentes, o Model Garden é ideal para aplicações corporativas que exigem segurança de dados rigorosa e custos previsíveis em grande escala. A Elastic quer encontrar você onde você estiver.

Modelos Jina AI

jina-embeddings-v3

Nosso modelo comprovado de embedding multilíngue com 572 milhões de parâmetros e contexto de token 8K. Pontuação 65,5 no Massive Text Embedding Benchmark (MTEB) em inglês. Compatível com cinco adaptadores LoRA (Low-Rank Adaptation) específicos para tarefas (consulta/passagem de recuperação, correspondência de texto, classificação, agrupamento) e truncamento Matryoshka de 1024 para 64 dimensões. Já amplamente adotado em todo o ecossistema Elasticsearch via EIS.

Estamos priorizando a v3 porque muitos sistemas de produção já dependem dela. Se você está migrando um pipeline baseado em v3 para o Google Cloud, agora pode executar o mesmo modelo de forma nativa sem alterar as dimensões de embedding nem reindexar.

jina-embeddings-v5-text (pequeno e nano)

Nossos modelos de incorporação de texto de quinta geração, lançados em fevereiro de 2026, alcançam desempenho de alto nível, competindo com modelos muitas vezes maiores.

v5-text-small (677 milhões) pontua 67,0 no conjunto de benchmarks Multilingual MTEB (MMTEB), abrangendo 131 tarefas de nove tipos, e 71,7 no benchmark MTEB em inglês. É o modelo de incorporação multilíngue sub-1B mais forte no MTEB Leaderboard.

v5-text-nano (239 milhões) tem 65,5 pontos no MMTEB. Nenhum outro modelo com menos de 500 milhões de parâmetros atinge esse nível. Com menos da metade do tamanho da maioria dos modelos comparáveis, é a escolha natural para implantações sensíveis à latência.

Ambos os modelos oferecem suporte:

• Quatro adaptadores LoRA específicos para tarefas: recuperação, correspondência de texto, classificação e clustering. Selecionar um adaptador apropriado por meio do parâmetro task no momento da inferência.

• Truncamento da dimensão matrioshka: reduza as dimensões de embedding de 1024 (ou 768 para nano) para 32. A perda de qualidade é mínima em truncamento moderado (por exemplo, 256 dimensões). Ao reduzir as dimensões pela metade, você reduz o armazenamento pela metade.

• Quantização binária: comprima embeddings de 1024 dimensões de 2KB para 128 bytes com binarização. O treinamento especial faz com que esta compressão tenha perdas mínimas.

• Multilíngue: 119 idiomas (pequeno) e 93 (nano).

jina-reranker-v3

Um reclassificador de listas multilíngue com 0,6 bilhões de parâmetros, construído usando uma arquitetura de interação última, mas não tardia. A consulta e até 64 correspondências de candidatos são inseridas em uma única janela de contexto de 131 mil tokens, e o modelo realiza uma comparação cruzada de documentos antes da pontuação. O Jina Reranker v3 alcança 61,94 nDCG@10 no BEIR, superando o modelo por ser 6× menor em tamanho. Isso é fundamentalmente diferente dos reclassificadores pontuais, que pontuam cada documento isoladamente, produzindo melhores resultados, especialmente para recuperação de trechos a partir de documentos isolados.

jina-clip-v2

Um modelo de incorporação multimodal e multilíngue de 0,9B que mapeia texto e imagens em um espaço compartilhado de 1024 dimensões. Ele é compatível com:

• 89 idiomas para recuperação de texto-imagem.

• Resolução de imagem 512×512.

• Entrada de texto com token de 8 mil.

• Truncamento de Matryoshka de 1024 para 64 dimensões para ambas as modalidades.

Altamente competitivo em benchmarks de imagem para texto, incluindo tarefas multilíngues.

Para começar

Jina Embeddings v3 está disponível no Model Garden hoje. Veja como fazê-lo funcionar.

Você precisa de um projeto do Google Cloud com a API Vertex AI habilitada e cota de GPU suficiente para pelo menos uma instância g2-standard-8 (NVIDIA L4). Se você é novo no Google Cloud, comece pelo guia de configuração.

A página Model Garden para Jina Embeddings v3 guia você pelo fluxo completo: faça upload do modelo, crie um endpoint, escolha o tipo de máquina e implante. Abra-o em seu próprio projeto e siga as etapas guiadas. Máquinas A100 e H100 também estão disponíveis onde a região e a cota permitem, mas L4 é tudo que você precisa para começar.

Desde o clique até a primeira incorporação, todo o processo leva alguns minutos.

O que vem depois

Jina Embeddings v3 é o ponto de partida. Nas próximas semanas, traremos o restante do stack de recuperação Jina para o Model Garden: embeddings de texto v5 (pequeno e nano), jina-reranker-v3 e jina-clip-v2 para busca multimodal. Tudo será executado em uma única GPU L4 com o mesmo modelo de autoimplantação.

As organizações acumulam grandes coleções de documentos, como chamados de suporte, processos judiciais, notícias, artigos de pesquisa, e precisam entender o que eles contêm antes de poderem fazer as perguntas certas. Sem rótulos nem dados de treinamento, revisar manualmente milhares de documentos é impraticável. A busca tradicional não ajuda quando você não sabe o que procurar.

Esta publicação tem uma abordagem nativa do Elasticsearch para clustering de documentos não supervisionados e rastreamento de histórias temporais que lida com esse problema de descoberta. Ao final, você poderá acompanhar arcos narrativos como este ao longo de vários dias:

O que você vai descobrir:

• Por que embeddings de clustering (e não embeddings de recuperação) são importantes quando se deseja descobrir tópicos sem uma consulta?

• Como a classificação de centroides sondada por densidade agrupa documentos por tópico usando Elasticsearch k-nearest neighbor (kNN) e processamento em lote msearch.

• Como significant_text pode automaticamente rotular clusters para que os temas sejam legíveis sem precisar treinar um modelo?

• Como as cadeias temporais de histórias conectam clusters diários para mostrar como os temas evoluem dia após dia.

O pipeline utiliza ~8.500 artigos de fevereiro de 2025 da BBC News e do The Guardian como um corpus de teste. As notícias são convenientes porque apresentam um comportamento temporal claro, mas esse padrão se aplica a qualquer situação em que a descoberta de documentos seja importante: revisão jurídica, monitoramento de conformidade, síntese de pesquisas, triagem de suporte ao cliente.

Stack:

• Jina v5 clustering embeddings: adaptadores LoRA (Low-Rank Adaptation) específicos para tarefas no agrupamento de tópicos. Jina ingressou na Elastic e os modelos estão disponíveis nativamente por meio do Elastic Inference Service (EIS).

• Elasticsearch: kNN escalável, rotulagem significant_text e armazenamento de vetores.

• DiskBBQ: um formato de índice vetorial baseado em disco que combina quantização binária aprimorada (BBQ) com particionamento hierárquico k-means para aceleração aproximada de vizinhos mais próximos (ANN). Essa partição de índice é interna à busca vetorial e separada do algoritmo de clustering baseado em densidade usado nesta postagem. bbq_disk armazena vetores quantizados em disco e mantém apenas metadados de partição no heap, reduzindo os requisitos de recursos, em comparação com bbq_hnsw, mantendo alta recuperação.

• Clustering global + vinculação temporal diária: descoberta e evolução da narrativa.

O que você precisará:

• Uma implementação do Elasticsearch (Elastic Cloud, Elasticsearch Serverless ou Elastic Self-Managed 8.18+/9.0+): bbq_disk requer a versão 8.18 ou posterior. A seção opcional do diversificador retriever exige 9.3+ ou serverless.

• Uma chave de API Jina: o nível gratuito inclui 10 milhões de tokens, o que cobre o pipeline principal de clusterização (aproximadamente 4,25 milhões de tokens). A comparação opcional entre recuperação e clustering usa uma segunda passagem de incorporação.

• Uma chave de API do Guardian (gratuita).

Configuração

Instale os pacotes necessários:

Opcional (somente se você executar ferramentas de scraping deste repositório):

Depois, configure chaves de API em um arquivo .env na raiz do projeto:

Este notebook chama load_dotenv(override=True), portanto os valores locais .env têm precedência.

Parte 1: clustering de descoberta – Por que fazer clustering de embeddings?

A maioria das buscas vetoriais utiliza embeddings de recuperação treinados para associar uma consulta a documentos relevantes. Isso é perfeito para buscas, mas não para descobertas. Quando você quer descobrir quais tópicos existem em um corpus sem qualquer consulta, precisa de embeddings que agrupem documentos semelhantes.

O Jina v5 resolve isso com adaptadores Low-Rank Adaptation (LoRA) específicos para cada tarefa. O LoRa adiciona pequenas atualizações de baixa classificação às camadas internas específicas, mantendo a maioria dos pesos do modelo base congelados, de modo que o comportamento do modelo se adapta a uma tarefa específica sem a necessidade de um novo treinamento completo. O mesmo modelo base produz embeddings diferentes dependendo do parâmetro task:

Tarefa

Preparado para

Caso de uso

retrieval.passage

Correspondência entre consulta e documento

Busca, retrieval augmented generation (RAG)

clustering

Agrupamento de tópicos (otimizado para clusters compactos)

Descoberta, categorização

O adaptador de clustering é treinado para aproximar documentos sobre o mesmo tópico no espaço de incorporação e distanciar documentos sobre tópicos diferentes. A comparação visual abaixo torna a diferença concreta.

Recuperação vs. clustering: uma comparação visual

Para ver a diferença, uma amostra de documentos recebe embedding de ambos os tipos de tarefa. O clustering é realizado no espaço de incorporação original de 1024 dimensões; a aproximação e projeção uniforme de variedades (UMAP) é usada apenas para projetar essas incorporações em 2D para visualização. A UMAP preserva a estrutura local de vizinhança, tornando-a útil para comparar a separação de clusters.

Abaixo, o mesmo exemplo de 480 documentos é incorporado com ambos os tipos de tarefas e projetado para 2D com UMAP. Procure grupos de cores mais fechados e separados no painel de clustering.

Os embeddings de recuperação (à esquerda) espalham amplamente os tópicos; os embeddings de clustering (à direita) produzem grupos mais coesos e separados a partir dos mesmos documentos.

Os embeddings de clustering produzem grupos mais compactos e visualmente distintos. Os embeddings de recuperação distribuem os tópicos de maneira mais uniforme, ideais para busca (similaridade refinada); mas, para descoberta, o que importa são os clusters temáticos compactos.

É por isso que o task="clustering" é usado no restante deste guia.

Carregando o conjunto de dados

O corpus combina duas fontes de notícias para fevereiro de 2025:

• BBC News através do conjunto de dados RealTimeData/bbc_news_alltime HuggingFace.

• The Guardian através da API da Guardian Open Platform.

Ter múltiplas fontes ajuda a validar se o clustering encontra tópicos em vez de estilos específicos de cada fonte.

Embedding com a tarefa de clustering

A API Jina v5 é chamada com task="clustering" para todos os documentos. Os embeddings são armazenados em cache no disco, portanto, as execuções subsequentes ignoram a API completamente.

A chamada da API é direta. O parâmetro task é a principal diferença em relação ao uso típico de embeddings:

O tempo abaixo reflete uma taxa de acerto do cache. A primeira execução contra a API demora mais, dependendo do tamanho do corpus.

Indexação em um único índice do Elasticsearch

Para clustering de descoberta, o mês inteiro é dedicado a um índice (docs-clustering-all). A partição diária vem depois para a ligação temporal da história.

O mapeamento do índice usa bbq_disk para o campo vetorial:

Um vetor float32 de dimensão 1024 tem 4 KB. bbq_disk utiliza k-means hierárquicos para particionar vetores em pequenos clusters, quantificá-los de forma binária e armazenar os vetores de precisão total no disco para repontuação. Apenas os metadados de partição permanecem no heap, então os requisitos de memória permanecem baixos mesmo para corpora grandes. Para cargas de trabalho que podem suportar mais heap, bbq_hnsw constrói um gráfico Hierarchical Navigable Small World (HNSW) para consultas mais rápidas com mais custo de recursos.

O tipo de campo dense_vector suporta múltiplas estratégias de quantização: bbq_disk e bbq_hnsw são os melhores ajustes para embeddings de alta dimensão como os vetores de dimensão 1024 usados aqui.

Clusteringo: classificação de centroides baseada em densidade

Algoritmos de clustering tradicionais, como o HDBSCAN, pressupõem que você possa manter a matriz vetorial completa de N×d na memória e executar atualizações de passagem completa repetidas. Para 8.495 documentos em 1024 dimensões, isso é administrável (aproximadamente 35 MB), mas a abordagem não é escalável para milhões de documentos sem infraestrutura adicional.

Este algoritmo é conceitualmente semelhante à inicialização do KMeans++ com atribuição de Voronoi e um nível de ruído, mas utiliza a busca kNN do Elasticsearch como primitiva de computação, mantendo quase todo o trabalho no lado do servidor:

1. Amostra de 5% de documentos como sondas de densidade (amostra aleatória, mínimo de 50).

2. Densidade da sonda por meio de lote msearch kNN. Cada sonda dispara uma consulta kNN e registra a semelhança média dos vizinhos. Alta similaridade média = região densa do espaço de embedding. msearch envia várias solicitações de pesquisa em uma única chamada HTTP, o que é fundamental aqui: a sondagem de densidade gera centenas de consultas kNN e processá-las em lote evita a sobrecarga por solicitação.

3. Selecione sementes de alta densidade com diversificação: os candidatos acima da densidade média são classificados por densidade decrescente e aceitos avidamente somente quando a semelhança de cosseno com cada semente existente estiver abaixo de um limite de separação. Este é o único processamento do lado do cliente (~0,01s para 8k documentos).

4. Classificar todos os documentos em relação aos centroides via msearch kNN: cada semente atua como um centroide; uma pesquisa kNN recupera documentos próximos acima de um limite de similaridade. Cada documento é atribuído ao centroide que o retornou com a maior pontuação. Pequenos clusters são dissolvidos em ruído.

O Elasticsearch cuida do trabalho pesado: msearch para sondas de densidade, msearch para classificação e significant_text para rotulagem. Para esse corpus (8.495 documentos), a amostra de sonda de densidade de 5% executa consultas de sonda de 425 kNN, que msearch agrupam lotes em nove chamadas HTTP (no tamanho de lote 50), evitando a sobrecarga de uma solicitação por sonda. Combinado com bbq_disk busca ANN, isso mantém a etapa de clustering rápida e escalável. As consultas kNN usam um valor mínimo de num_candidates para velocidade durante a passagem de clustering; consultas de busca em produção devem usar valores de num_candidates mais altos para melhorar a recordação, mas isso custa latência.

Clusters têm tamanhos naturais determinados pela densidade do espaço de embedding ao redor de cada centroide, não por um limite de k rígido. Regiões temáticas densas produzem clusters maiores; tópicos de nicho produzem agrupamentos menores.

Por que escolher KMeans ou HDBSCAN?

O algoritmo KMeans pressupõe clusters esféricos e requer a matriz completa N×d na memória. Para corpora que cabem na memória, HDBSCAN é uma excelente alternativa. Ele lida com formatos de cluster arbitrários e possui semântica de densidade bem compreendida.

A abordagem de centroide sondado por densidade mira em um nicho diferente: corpora onde você quer armazenamento, recuperação e clustering em um único sistema, ou onde a escala torna as operações matriciais do lado do cliente impraticáveis. Ele usa o Elasticsearch kNN como primitiva de computação, lida com tamanhos arbitrários de cluster e mantém quase toda a computação no lado do servidor.

Entendendo a taxa de ruído

A taxa de ruído de ~28% é intencional, não uma falha. Documentos que não cabem em nenhum cluster denso na similarity_threshold configurada ficam sem atribuição, em vez de serem forçados a uma correspondência ruim. Isso funciona como um filtro de qualidade: colunas de opinião, artigos curtos e reportagens isoladas naturalmente resistem ao clustering porque falta a densidade temática que define um grupo coerente.

O limiar é ajustável: reduzir similarity_threshold produz clusters mais abrangentes (mais documentos atribuídos, mas clusters menos coesos), enquanto aumentá-lo torna os clusters mais compactos e aumenta a fração de ruído. Para este corpus de conteúdo de notícias misto, ~30% de ruído é um ponto de operação razoável. Implantações em produção devem ajustar o limiar com base em critérios de qualidade específicos do domínio.

Rótulos automáticos com significant_text

Agora, cada cluster precisa de um rótulo de fácil compreensão. A agregação significant_text do Elasticsearch encontra termos que aparecem com frequência incomum em um conjunto em primeiro plano (o cluster) em comparação com um conjunto em segundo plano (o corpus completo).

Nos bastidores, ele usa uma heurística estatística (pontuação JLH por padrão) que equilibra mudanças de frequência absolutas e relativas, sem machine learning, sem chamadas de grandes modelo de linguagem (LLM). Um cluster sobre política do Reino Unido pode apresentar termos como starmer, labour, downing porque esses termos são desproporcionalmente comuns nesse cluster em comparação ao conjunto geral de notícias.

Para essa passagem global, os rótulos são calculados diretamente contra docs-clustering-all, então tanto o plano de frente quanto o plano de fundo são extraídos do mês inteiro. Na parte 2, a rotulagem utiliza o padrão de indexação diário (docs-clustering-*), um caractere curinga que permite que consultas abranjam todos os índices correspondentes simultaneamente, para dar significant_text um plano de fundo mais amplo e melhor contraste.

Um formato de consulta mínimo tem a seguinte aparência:

significant_text serve também como um filtro de qualidade: clusters que não produzem termos significativos não possuem vocabulário distintivo. São agrupamentos incoerentes que devem ser dissolvidos e reduzidos a ruído, em vez de receberem um rótulo enganoso.

Uma etapa de limpeza determinística e leve remove termos de rótulos irrelevantes (tokens numéricos, palavras genéricas) e recorre a um título representativo quando necessário. Isso mantém os rótulos nativos do Elasticsearch enquanto melhora a legibilidade.

Visualizando os clusters

As visualizações abaixo mostram o que a análise de clustering global descobriu: uma análise por data de documentos agrupados versus documentos de ruído, uma projeção UMAP para o mês inteiro e um gráfico de composição de fontes confirmando que os agrupamentos refletem tópicos em vez de fontes.

Distribuição diária de documentos agrupados versus ruídos ao longo de fevereiro de 2025.

Cada ilha colorida no UMAP representa um cluster: um grupo de artigos sobre o mesmo tema descobertos puramente por similaridade de incorporação. Os pontos de ruído cinza são artigos que não se encaixavam perfeitamente em nenhum cluster (artigos curtos, artigos de opinião ou histórias isoladas).

O gráfico de detalhamento da fonte confirma que os clusters contêm artigos de ambos BBC News e The Guardian. O clustering está encontrando tópicos, não fontes, exatamente o que a descoberta não supervisionada deve produzir.

Explorando a amplitude do cluster com o diversificador

O algoritmo kNN simples retorna os documentos mais semelhantes ao centroide de um cluster (o núcleo denso). Mas clusters reais abrangem subtópicos. O recuperador de diversificação usa a relevância marginal máxima (MMR) para destacar documentos que são relevantes para o centroide, mas também diferentes entre si.

O parâmetro chave é λ (lambda):

• λ = 1,0 → relevância pura (o mesmo que kNN simples).

• λ = 0,0 → diversidade pura (resultados de distribuição máxima).

• λ = 0,5 → equilibrado: relevante para o tópico, mas abordando diferentes perspectivas.

Uma forma mínima de solicitação de recuperador é assim:

Os parâmetros type, field, e query_vector são necessários no nível de diversificação: field informa à MMR qual campo dense_vector usar para similaridade entre resultados, e query_vector fornece o ponto de referência para a pontuação de relevância.

Isso permite que você responda: "O que esse cluster cobre de fato?" em vez de apenas "Qual é o ponto central?"

Os resultados simples kNN se agrupam em torno de um ângulo do tema: os documentos mais semelhantes ao centroide e entre si. O recurso de recuperação de diversidade revela diferentes facetas do mesmo cluster: subtópicos, fontes diversas e perspectivas variadas.

A métrica de diversidade confirma isso quantitativamente: a similaridade média entre pares é menor para os resultados do recuperador diversificado, o que significa que os documentos retornados abrangem um espectro mais amplo.

Isso é útil para você:

• Entender o que um cluster cobre, não apenas o centro, mas também as bordas.

• Geração de resumos. Documentos representativos diversos oferecem um material melhor para um LLM.

• Encontrar exemplos representativos para análise humana ou rotulagem posterior.

• Verificações de qualidade. Se os resultados diversos parecerem incoerentes, o cluster pode precisar ser dividido.

Parte 2: Cadeias de histórias temporais

Acompanhando histórias ao longo dos dias

A parte 1 fez o clustering de todo o mês global para descoberta de tópicos. Para o fluxo temporal, a mesma classificação de centroides sondados por densidade é executada independentemente por dia em índices diários, e depois os clusters são vinculados ao longo de dias consecutivos. Observe que os clusters diários são independentes dos clusters globais da parte 1; cada dia produz as próprias atribuições de agrupamento e rótulos ajustados ao conteúdo daquele dia.

A abordagem de vinculação: amostragem e consulta

Para cada cluster no dia A:

1. Você pode ver uma amostra de alguns documentos representativos.

2. Executar kNN contra o índice do dia B.

3. Conte quantos acessos caem em cada cluster B do dia.

4. Se a fração de acerto ultrapassar um limite (fração de kNN ≥ 0,4), registre um link.

Isso é rápido (apenas alguns documentos por cluster são consultados, nem todos) e usa o kNN nativo do Elasticsearch, sem necessidade de ferramentas externas.

Uma fração de kNN de 100% significa que todos os documentos mostrados do cluster de origem foram atribuídos ao mesmo cluster de destino, o vínculo mais forte possível entre os dias. A maioria dos links acima está relacionada ao futebol, o que faz sentido: a cobertura da Premier League é feita diariamente com alta consistência de tópicos.

O link score | operator | gedling → league | striker | season é um exemplo de um cluster de futebol local de nicho (Gedling é um clube fora da liga) sendo absorvido pelo cluster mais amplo da Premier League no dia seguinte, um efeito natural do clustering diário em diferentes granularidades.

Criar cadeias de histórias

Uma cadeia de histórias é uma sequência de clusters ligados ao longo de dias consecutivos.

Ligações pareadas individuais indicam que o cluster "política do Reino Unido" de segunda-feira está conectado ao de terça-feira. As cadeias revelam o arco completo: uma história que começa na segunda-feira, evolui durante a semana e encerra na sexta-feira.

As cadeias são construídas de forma ávida a partir de links com uma fração kNN ≥ 0,4, o que significa que pelo menos 40% dos documentos mostrados do cluster de origem chegaram a um único cluster de destino. A partir do cluster mais antigo, o algoritmo sempre segue o link de saída mais forte.

A rede mais longa acompanha a cobertura Ucrânia–Rússia por 19 dias consecutivos, o que não surpreende dada a intensidade geopolítica em fevereiro de 2025. O segundo mais longo acompanha o futebol da Premier League ao longo de 19 dias do mês. Cadeias mais curtas captam a temporada de premiações (filme/prêmios, seis dias), o rúgbi Six Nations (10 dias) e a cobertura da liderança política do Reino Unido (sete dias). Cada cadeia representa um arco narrativo que o algoritmo descobriu ao incorporar similaridade entre índices diários.

Sankey: Visualizando o fluxo da história

Um diagrama de Sankey é uma visualização de fluxo onde a largura da ligação representa a força da conexão. Aqui, cada faixa vertical representa um dia, cada nó é um cluster diário (dimensionado pela contagem de documentos), e cada caminho colorido traça uma cadeia de histórias ao longo do tempo. A largura do link codifica a força de sobreposição kNN: links mais espessos indicam que mais documentos mostrados caíram no cluster alvo. As cores são consistentes por cadeia, então um único caminho colorido da esquerda para a direita representa o progresso de uma história.

Por exemplo, a cadeia Ucrânia-Rússia (visível como um dos caminhos mais longos) flui continuamente desde o início de fevereiro até a terceira semana, com elos consistentemente espessos indicando forte continuidade temática ao longo dos dias.

Cadeias temporais de histórias que fluem ao longo de fevereiro de 2025. Cada caminho colorido representa uma história que persiste ao longo dos dias; com a largura indicando a força de sobreposição do kNN.

O que essa abordagem oferece

Esta análise abordou um pipeline completo de clustering de documentos não supervisionado construído no Elasticsearch:

1. Embeddings de clustering: os adaptadores específicos de tarefa do Jina v5 produzem embeddings otimizadas para agrupamento de tópicos, e não apenas para correspondência de consulta-documento.

2. Clustering de descoberta global: clustering o mês inteiro em um único índice maximiza a descoberta de tópicos ao longo dos dias.

3. Classificação de centroides com base na densidade: amostra 5%, sondar a densidade via msearch kNN, selecionar sementes diversas de alta densidade, classificar todos os documentos em relação aos centroides. O Elasticsearch cuida do processamento pesado; apenas a seleção de sementes executa do lado do cliente (~0,01s).

4. significant_text rotulagem: o teste de significância produz rótulos de cluster significativos sem qualquer modelo de ML ou anotação manual. Clusters que não produzem termos significativos são incoerentes e são rebaixados a ruído, uma porta de qualidade integrada.

5. Vinculação temporal de histórias: índices diários e kNN de índice cruzado entre amostra e consulta rastreiam como as histórias evoluem ao longo do tempo.

Principais conclusões:

• O tipo de tarefa de incorporação importa: embeddings de clustering produzem grupos tópicos mensuravelmente mais compactos.

• O Elasticsearch pode atuar tanto como camada de armazenamento quanto como motor de clustering por meio da busca kNN.

• A classificação de centroides baseada em densidade mantém quase toda a computação no lado do servidor e produz clusters com tamanhos naturais determinados pela densidade do espaço de incorporação.

• significant_text é rápido, compreensível e eficaz tanto para autorrotulagem quanto para controle de qualidade.

Quando essa abordagem é útil:

• Você tem texto com carimbo de data e hora e quer descobrir tópicos sem dados de treinamento rotulados.

• Você precisa de uma plataforma para armazenamento, busca vetorial, rotulagem e ligação temporal.

Extensões para explorar:

• Clustering por múltiplos períodos (semanal, pacotes mensais).

• Ingestão em tempo real com atribuição incremental de cluster.

• Resumos de cluster gerados pelo LLM usando os termos significant_text como sementes.

• Em escala maior, centroides KMeans mostrados podem servir como sementes de aquecimento para clustering baseado em densidade, reduzindo o custo da fase da sonda.

Experimente você mesmo

Troque seu próprio corpus de documentos com carimbo de data; qualquer coleção de texto com datas funciona com esse pipeline. O notebook completo e o código de suporte estão disponíveis no repositório complementar.

• Inicie uma avaliação gratuita do Elastic Cloud: instale um cluster gerenciado com suporte bbq_disk em questão de minutos.

• Experimente o Elasticsearch Serverless: sem gerenciamento de cluster, escala automática e com suporte.

A família inclui dois modelos:

• jina-embeddings-v5-text-small

• jina-embeddings-v5-text-nano

Esses modelos são o resultado bem-sucedido de uma nova receita inovadora de treinamento para incorporação de modelos. Ambos superam modelos muitas vezes maiores que eles, gerando economia de memória e recursos computacionais e respondendo mais rápido a solicitações.

O modelo jina-embeddings-v5-text-small possui 677 milhões de parâmetros, é compatível com uma janela de contexto de entrada de 32.768 tokens e gera embeddings de 1.024 dimensões por padrão.

jina-embeddings-v5-text-nano Pesa cerca de um terço do tamanho da nova versão, com 239 milhões de parâmetros e uma janela de contexto de entrada de 8.192 tokens, resultando em embeddings de dimensão 768 compactos.

Nome do modelo

Tamanho total

Tamanho da janela de contexto de entrada

Tamanho do embedding

jina-v5-text-small

677M params

32.768 tokens

1.024 dims

jina-v5-text-nano

239M params

8.192 tokens

768 dimensões

Esses dois modelos são os melhores da categoria para o desempenho geral do benchmark MMTEB (Multilingual MTEB). Entre os modelos com menos de 500M, jina-embeddings-v5-text-nano é o de melhor desempenho, apesar de ter menos de 250M, e o modelo jina-embeddings-v5-text-small é o líder entre os modelos de embedding multilíngue com menos de 750M.

Esses modelos estão disponíveis por meio do Elastic Inference Service (EIS), de uma API online e para hospedagem local. Para instruções sobre como acessar os modelos jina-embeddings-v5-text, veja a seção "Começar" abaixo.

Modelos de incorporação e indexação semântica aumentam muito a precisão dos algoritmos de busca, mas também têm uma variedade de outros usos para tarefas envolvendo similaridade semântica e extração de significado, por exemplo:

• Encontrando textos duplicados.

• Reconhecendo paráfrases e traduções.

• Descoberta de tópicos.

• Mecanismos de recomendação.

• Análise de sentimentos e intenções.

• Filtragem de spam.

• E muitos outros.

Recursos

Essa nova família de modelos possui uma série de recursos projetados para aumentar a relevância e reduzir custos.

Otimização de tarefas

Otimizamos os modelos jina-embeddings-v5-text para quatro tipos amplos de tarefas:

Tarefa

Exemplos de casos de uso

Recuperação

Busca com consultas em linguagem natural e recuperação das correspondências mais relevantes em um conjunto de documentos.

Correspondência de texto

Similaridade semântica, desduplicação, alinhamento de paráfrases e traduções, e muito mais.

Clustering

Descoberta de tópicos, organização automática de coleções de documentos.

Classificação

Categorização de documentos, detecção de sentimentos e intenções, tarefas similares.

Otimizar para uma tarefa geralmente significa ter que ceder em outra, então a maioria dos modelos de embedding só tem desempenho competitivo para um tipo de tarefa. Mas os modelos jina-embeddings-v5-text são capazes de se especializar em todas as quatro áreas sem comprometer o desempenho, treinando adaptadores compactos de Low-Rank Adaptation (LoRA) específicos para cada tarefa.

Adaptadores LoRA são uma espécie de plugin para um modelo de IA que muda o comportamento, aumentando ligeiramente o tamanho total. Em vez de ter um modelo inteiro para cada tarefa, cada um com centenas de milhões de parâmetros, a família de modelos jina-embeddings-v5-text permite que você use um modelo com um adaptador compacto LoRA para cada tarefa. Isso economiza memória, espaço de armazenamento e custos de inferência.

Truncando embeddings

Treinamos os modelos jina-embeddings-v5-text usando o Aprendizado de representação Matryoshka, que permite reduzir seus embeddings para tamanhos menores com um custo mínimo para a qualidade deles.

Por padrão, jina-embeddings-v5-text-small gera vetores de embedding de 1024 dimensões, cada um representado por um número de 16 bits, fazendo com que cada embedding tenha 2KB de tamanho. Para um grande conjunto de documentos, isso pode representar uma grande quantidade de dados para armazenar, e a busca em um banco de dados vetorial repleto de embeddings é proporcional tanto ao tamanho do banco de dados quanto ao número de dimensões que cada vetor armazenado possui.

Mas você pode reduzir pela metade o tamanho dos embeddings (descartar 512 das 1024 dimensões) e ocupar metade do espaço enquanto dobra a velocidade das buscas. Isso tem um impacto no desempenho. Descartar informações reduz a precisão. Mas, como mostra o gráfico abaixo, mesmo ao eliminar metade do embedding, a redução de desempenho é mínima:

Desde que suas embeddings tenham pelo menos 256 dimensões, a perda de precisão deve permanecer relativamente pequena. Abaixo desse nível, porém, a relevância e a precisão se deterioram rapidamente.

Truncar embeddings como esse permite aos usuários gerenciar as próprias trocas entre precisão e custos computacionais. Ela oferece ferramentas para ter grandes ganhos de eficiência e grandes economias de custos com a IA de busca.

Quantização robusta

Quantização é outra forma de reduzir o tamanho das embeddings. Em vez de descartar parte de cada incorporação, a quantização reduz a precisão dos números na embedding. Os modelos jina-embeddings-v5-text geram embeddings com números de 16 bits, mas podemos arredondar esses números, reduzindo a precisão e o número de bits necessários para armazená-los. No caso mais extremo, podemos reduzir cada número a um bit (0 ou 1), comprimindo as embeddings padrão de 1024 dimensões de jina-embeddings-v5-textde 2 kilobytes para 128 bytes, uma redução de 94% apenas com a quantização binária. Assim como para a truncagem, isso produz grandes economias em memória e custos computacionais. No entanto, assim como a truncagem, a quantização torna as embeddings menos precisas.

Treinamos os modelos jina-embeddings-v5-text para funcionar com a Better Binary Quantization (BBQ) do Elasticsearch, minimizando a perda de precisão. Os testes de benchmark de embeddings binarizados desses modelos mostram desempenho quase igual aos equivalentes não binarizados. Consulte o relatório técnico para estudos detalhados de ablação sobre o desempenho da binarização.

Desempenho multilíngue

Muitos modelos de embedding são multilíngues porque foram treinados com materiais que incluem um grande número de linguagens. Mas isso não significa que todos tenham o mesmo desempenho em todas as linguagens disponíveis.

Identificamos 211 linguagens no benchmark multilíngue MMTEB e os separamos para que pudéssemos comparar nossos modelos com modelos semelhantes linguagem por linguagem. A imagem abaixo resume nossos resultados como um mapa de calor. Cada patch é uma linguagem (identificada pelo código ISO-639), e quanto mais verde ela é, melhor o modelo teve desempenho em comparação com a média de modelos similares:

Embora a precisão varie entre as linguagens, os modelos jina-embeddings-v5-text são de ponta ou quase isso na maioria das linguagens do mundo.

Para saber detalhes sobre o desempenho multilíngue, consulte o jina-embeddings-v5-text relatório técnico.

Jina no Elastic: IA nativa de última geração para busca

Com jina-embeddings-v5-text modelos no EIS, você pode executar modelos de embedding multilíngue de alto desempenho de forma nativa no Elasticsearch, com inferência totalmente gerenciada e acelerada por GPU, sem infraestrutura para provisão ou redimensionamento. jina-embeddings-v5-text modelos ampliam o catálogo cada vez maior de modelos EIS com modelos compactos e multilíngues, impulsionados pelos mais recentes avanços em IA. Esses modelos têm desempenho de ponta em recuperação de informações e benchmarks padrão de análise de dados, além de oferecer suporte multilíngue incomparável e global.

Com dois modelos de tamanhos muito diferentes, os usuários podem definir qual é o mais adequado para as aplicações e orçamentos. Além disso, com embeddings robustas que mantêm o desempenho quando truncadas para tamanhos menores ou quantizadas com menor precisão, jina-embeddings-v5-text modelos oferecem oportunidades para economias concretas adicionais em custos de armazenamento e computação, bem como na latência de processamento.

Com a família jina-embeddings-v5-text , Jina Reranker e a busca vetorial rápida e BM25 da Elastic, os usuários agora têm acesso à busca híbrida de ponta a ponta e de última geração da Elastic. Quando você precisa dos resultados mais relevantes, seja para pipelines de Retrieval-Augmented Generation (RAG), aplicações de busca ou análise de dados, a Elastic com modelos de IA de busca Jina oferece qualidade sólida e econômica.

Para começar

Os modelos jina-embeddings-v5-text estão totalmente integrados ao EIS e você pode usá-los definindo o typecampo parasemantic_text ao criar seu índice e especificar o modelo (jina-embeddings-v5-text-small ou jina-embeddings-v5-text-nano) no inference_idcampo, como neste exemplo:

O Elasticsearch seleciona automaticamente o adaptador LoRA apropriado durante a indexação e a recuperação. As dimensões de embedding (veja a seção "Truncando embeddings ", acima) podem ser definidas ao criar um endpoint de inferência personalizado.

Consulte a documentação do Elasticsearch para saber mais informações sobre como usar os modelos jina-embeddings-v5-text .

Mais informações

Para saber mais sobre os modelos jina-embeddings-v5-text , leia as notas de lançamento no blog da Jina AI e o relatório técnico, que contém informações técnicas mais detalhadas sobre o desempenho e o novo procedimento de treinamento inovador da Jina AI. Para saber informações sobre como fazer download e executar esses modelos de forma local, acesse a página da coleção jina-embeddings-v5-textna Hugging Face.

Os modelos de Jina AI estão disponíveis sob a licença CC-BY-NC-4.0, portanto, você pode baixá-los e experimentá-los de forma livre, mas para uso comercial, entre em contato com a equipe de vendas da Elastic.

Os modelos Jina se enquadram em três grandes categorias, projetadas para dar suporte ao processamento, à organização e à recuperação de informações:

• Modelos de embedding semântico

• Modelos de reclassificação

• Modelos de linguagem generativos de pequeno porte

Modelos de embedding semântico

A ideia por trás dos embeddings semânticos é que um modelo de IA pode aprender a representar aspectos do significado de suas entradas em termos da geometria de espaços de alta dimensionalidade.

É possível pensar em um embedding semântico como um ponto (tecnicamente, um vetor) em um espaço de alta dimensionalidade. Um modelo de embedding é uma rede neural que recebe algum tipo de dado digital como entrada, potencialmente qualquer tipo, mas mais comumente texto ou imagem, e produz a localização de um ponto correspondente em um espaço de alta dimensionalidade, representada por um conjunto de coordenadas numéricas. Quando o modelo executa bem sua função, a distância entre dois embeddings semânticos é proporcional ao quanto os objetos digitais correspondentes compartilham o mesmo significado.

Para entender por que isso é importante para aplicações de busca, imagine um embedding para a palavra “cão” e outro para a palavra “gato” como pontos em um espaço.

Um bom modelo de embedding deve gerar um embedding para a palavra “felino” muito mais próximo de “gato” do que de “cão”, e “canino” deve ter um embedding muito mais próximo de “cão” do que de “gato”, porque essas palavras têm praticamente o mesmo significado.

Se um modelo for multilíngue, espera-se o mesmo comportamento para traduções de “gato” e “cão” em outros idiomas.

Modelos de embedding traduzem similaridade ou dissimilaridade de significado entre elementos em relações espaciais entre embeddings. As imagens acima têm apenas duas dimensões para que seja possível visualizá-las na tela, mas modelos de embedding produzem vetores com dezenas a milhares de dimensões. Isso permite codificar sutilezas de significado para textos inteiros, atribuindo um ponto em um espaço com centenas ou milhares de dimensões a documentos com milhares de palavras ou mais.

Embeddings multimodais

Modelos multimodais estendem o conceito de embeddings semânticos para além de textos, especialmente para imagens. Espera-se que o embedding de uma imagem fique próximo ao embedding de uma descrição fiel dessa imagem.

Embeddings semânticos têm muitos usos. Entre outras aplicações, é possível usá-los para criar classificadores eficientes, realizar clustering de dados e executar diversas tarefas, como deduplicação de dados e investigação da diversidade dos dados, ambas importantes para aplicações de big data que lidam com volumes de informação grandes demais para serem gerenciados manualmente.

O principal uso direto de embeddings está na recuperação de informações. O Elasticsearch pode armazenar objetos de recuperação com embeddings como chaves. As consultas são convertidas em vetores de embedding, e a busca retorna os objetos armazenados cujas chaves estão mais próximas do embedding da consulta.

Enquanto a recuperação tradicional baseada em vetores (às vezes chamada de recuperação por vetores esparsos) usa vetores baseados em palavras ou metadados presentes em documentos e consultas, a recuperação baseada em embeddings (também conhecida como recuperação por vetores densos) usa significados avaliados por IA em vez de palavras. Isso a torna, em geral, muito mais flexível e mais precisa do que métodos tradicionais de busca.

Aprendizado de representação Matryoshka

O número de dimensões de um embedding, assim como a precisão dos valores numéricos que o compõem, tem impactos significativos na performance. Espaços de dimensionalidade muito alta e números de precisão extremamente elevada podem representar informações altamente detalhadas e complexas, mas exigem modelos de IA maiores, mais caros para treinar e para executar. Os vetores que esses modelos geram requerem mais espaço de armazenamento, e são necessários mais ciclos de computação para calcular as distâncias entre eles. Usar modelos de embedding semântico envolve fazer concessões importantes entre precisão e consumo de recursos.

Para maximizar a flexibilidade para os usuários, os modelos Jina são treinados com uma técnica chamada Aprendizado de Representação Matryoshka. Essa abordagem faz com que os modelos concentrem as distinções semânticas mais importantes nas primeiras dimensões do vetor de embedding, de modo que seja possível descartar as dimensões mais altas e ainda assim obter bom desempenho.

Na prática, isso significa que usuários dos modelos Jina podem escolher quantas dimensões desejam que seus embeddings tenham. Escolher menos dimensões reduz a precisão, mas a degradação de performance é pequena. Na maioria das tarefas, as métricas de performance dos modelos Jina caem entre 1% e 2% sempre que o tamanho do embedding é reduzido em 50%, até uma redução total de cerca de 95% no tamanho.

Recuperação assimétrica

A similaridade semântica geralmente é medida de forma simétrica. O valor obtido ao comparar “gato” com “cão” é o mesmo que ao comparar “cão” com “gato”. No entanto, quando embeddings são usados para recuperação de informações, o desempenho melhora quando essa simetria é quebrada e as consultas são codificadas de forma diferente dos objetos de recuperação.

Isso ocorre por causa da forma como treinamos modelos de embedding. Os dados de treinamento contêm ocorrências dos mesmos elementos, como palavras, em muitos contextos diferentes, e os modelos aprendem semântica comparando similaridades e diferenças contextuais entre esses elementos.

Assim, por exemplo, pode acontecer de a palavra “animal” não aparecer em muitos dos mesmos contextos que “gato” ou “cão”, e, portanto, o embedding de “animal” não ficar particularmente próximo de “gato” ou “cão”.

Isso torna menos provável que uma consulta por “animal” recupere documentos sobre gatos e cães — justamente o oposto do nosso objetivo. Por isso, em vez disso, codificamos “animal” de forma diferente quando ele aparece como consulta do que quando é um alvo de recuperação.

Recuperação assimétrica significa usar um modelo diferente para consultas ou treinar especificamente um modelo de embedding para codificar os dados de uma forma quando são armazenados para recuperação e de outra forma quando são usados como consultas.

Embeddings multivetoriais

Embeddings únicos funcionam bem para recuperação de informações porque se encaixam no modelo básico de um banco de dados indexado: armazenamos objetos para recuperação usando um único vetor de embedding como chave de recuperação. Quando usuários consultam o repositório de documentos, suas consultas são traduzidas em vetores de embedding, e os documentos cujas chaves estão mais próximas do embedding da consulta, no espaço de embeddings de alta dimensionalidade, são recuperados como candidatos.

Embeddings multivetoriais funcionam de forma um pouco diferente. Em vez de gerar um vetor de comprimento fixo para representar uma consulta e um objeto armazenado inteiro, eles produzem uma sequência de embeddings que representam partes menores desses elementos. Essas partes geralmente são tokens ou palavras no caso de textos, e blocos de imagem no caso de dados visuais. Esses embeddings refletem o significado de cada parte dentro de seu contexto.

Por exemplo, considere estas frases:

• Ela tinha um coração de ouro.

• Ela fez das tripas coração.

• Ela teve um ataque do coração.

Superficialmente, essas frases parecem muito semelhantes, mas um modelo multivetorial provavelmente geraria embeddings bem diferentes para cada ocorrência de “coração”, representando como cada uma assume um significado distinto no contexto da frase como um todo.

Comparar dois objetos por meio de seus embeddings multivetoriais geralmente envolve medir a distância de Chamfer: comparar cada parte de um embedding multivetorial com cada parte de outro e somar as menores distâncias entre elas. Outros sistemas, incluindo os reclassificadores Jina descritos abaixo, usam esses embeddings como entrada para um modelo de IA treinado especificamente para avaliar sua similaridade. Ambas as abordagens normalmente apresentam maior precisão do que a simples comparação de embeddings de vetor único, porque embeddings multivetoriais contêm informações muito mais detalhadas do que embeddings de vetor único.

No entanto, embeddings multivetoriais não são adequados para indexação. Eles costumam ser usados em tarefas de reclassificação, conforme descrito para o modelo jina-colbert-v2 na próxima seção.

Modelos de embedding Jina

Jina embeddings v4

jina-embeddings-v4 é um modelo de embedding multilíngue e multimodal, com 3,8 bilhões (3,8 × 10⁹) de parâmetros, que oferece suporte a imagens e textos em diversos idiomas amplamente utilizados. Ele utiliza uma arquitetura inédita para aproveitar conhecimento visual e conhecimento linguístico, melhorando o desempenho em ambas as tarefas e permitindo que o modelo se destaque na recuperação de imagens e, especialmente, na recuperação de documentos visuais. Isso significa que ele lida bem com imagens como gráficos, slides, mapas, capturas de tela, digitalizações de páginas e diagramas — tipos comuns de imagens que muitas vezes contêm texto incorporado importante e que ficam fora do escopo de modelos de visão computacional treinados apenas com imagens de cenas do mundo real.

Otimizamos esse modelo para diversas tarefas diferentes usando adaptadores compactos de Low-Rank Adaptation (LoRA). Isso nos permite treinar um único modelo para se especializar em múltiplas tarefas, sem comprometer o desempenho em nenhuma delas, com um custo adicional mínimo de memória ou processamento.

Os principais recursos incluem:

• Desempenho de ponta na recuperação de documentos visuais, além de suporte a texto multilíngue e imagens comuns com resultados que superam significativamente modelos muito maiores.

• Suporte a grandes tamanhos de contexto de entrada: 32.768 tokens equivalem aproximadamente a 80 páginas de texto em inglês com espaçamento duplo, e 20 megapixels equivalem a uma imagem de 4.500 × 4.500 pixels.

• Tamanhos de embedding selecionáveis pelo usuário, de um máximo de 2.048 dimensões até 128 dimensões. Constatamos empiricamente que o desempenho se degrada de forma acentuada abaixo desse limite.

• Suporte tanto a embeddings únicos quanto a embeddings multivetoriais. Para textos, a saída multivetorial consiste em um embedding de 128 dimensões para cada token de entrada. Para imagens, é gerado um embedding de 128 dimensões para cada bloco de 28 × 28 pixels necessário para cobrir a imagem.

• Otimização para recuperação assimétrica por meio de um par de adaptadores LoRA treinados especificamente para esse propósito.

• Um adaptador LoRA otimizado para cálculo de similaridade semântica.

• Suporte especial a linguagens de programação e estruturas de TI, também por meio de um adaptador LoRA.

Desenvolvemos jina-embeddings-v4 para atuar como uma ferramenta geral e multifuncional para uma ampla gama de tarefas comuns de busca, compreensão de linguagem natural e análise com IA. Apesar de ser relativamente pequeno considerando suas capacidades, ainda exige recursos significativos para implantação e é mais adequado para uso por meio de uma API em nuvem ou em ambientes de alto volume.

Jina embeddings v3

jina-embeddings-V3 é um modelo de embedding compacto, multilíngue, somente para texto, com alto desempenho e menos de 600 milhões de parâmetros. Ele oferece suporte a até 8.192 tokens de texto de entrada e gera embeddings de vetor único com tamanhos escolhidos pelo usuário, desde o padrão de 1.024 dimensões até 64.

Treinamos jina-embeddings-v3 para uma variedade de tarefas de texto — não apenas recuperação de informações e similaridade semântica, mas também tarefas de classificação, como análise de sentimento e moderação de conteúdo, além de tarefas de clusterização, como agregação de notícias e recomendação. Assim como jina-embeddings-v4, esse modelo oferece adaptadores LoRA especializados para as seguintes categorias de uso:

• Recuperação assimétrica

• Similaridade semântica

• Classificação

• Clustering

jina-embeddings-v3 é um modelo muito menor do que jina-embeddings-v4 com um tamanho de contexto de entrada significativamente reduzido, mas com custo operacional mais baixo. Ainda assim, apresenta desempenho bastante competitivo, embora apenas para textos, e é uma escolha melhor para muitos casos de uso.

Incorporações de código Jina

Os modelos especializados de embedding de código da Jina — jina-code-embeddings (0.5b e 1.5b) — oferecem suporte a 15 esquemas de programação e estruturas, além de textos em inglês relacionados a computação e tecnologia da informação. São modelos compactos, com meio bilhão (0,5 × 10⁹) e um bilhão e meio (1,5 × 10⁹) de parâmetros, respectivamente. Ambos oferecem suporte a tamanhos de contexto de entrada de até 32.768 tokens e permitem que os usuários escolham os tamanhos dos embeddings de saída, de 896 a 64 dimensões no modelo menor e de 1.536 a 128 no modelo maior.

Esses modelos oferecem suporte a recuperação assimétrica para cinco especializações específicas de tarefa, usando ajuste de prefixo em vez de adaptadores LoRA:

• Código para código. Recuperar código semelhante entre diferentes linguagens de programação. Isso é usado para alinhamento de código, deduplicação de código e suporte a portabilidade e refatoração.

• Linguagem natural para código. Recuperar código que corresponda a consultas em linguagem natural, comentários, descrições e documentação.

• Código para linguagem natural. Associar código a documentação ou a outros textos em linguagem natural.

• Conclusão de código para código. Sugerir código relevante para completar ou aprimorar código existente.

• Perguntas e respostas técnicas. Identificar respostas em linguagem natural para perguntas sobre tecnologias da informação, sendo ideal para casos de uso de suporte técnico.

Esses modelos oferecem performance superior em tarefas que envolvem documentação técnica e materiais de programação, com um custo computacional relativamente baixo. Eles são bem adequados para integração em ambientes de desenvolvimento e assistentes de código.

Jina ColBERT v2

jina-colbert-v2 é um modelo de embedding de texto multivetorial com 560 milhões de parâmetros. Ele é multilíngue, treinado com materiais em 89 idiomas, e oferece suporte a tamanhos variáveis de embedding e recuperação assimétrica.

Como observado anteriormente, embeddings multivetoriais não são adequados para indexação, mas são muito úteis para aumentar a precisão dos resultados de outras estratégias de busca. Com jina-colbert-v2, é possível calcular embeddings multivetoriais antecipadamente e usá-los para reclassificar candidatos à recuperação no momento da consulta. Essa abordagem é menos precisa do que usar um dos modelos de reclassificação descritos na próxima seção, mas é muito mais eficiente, pois envolve apenas a comparação de embeddings multivetoriais armazenados, em vez de invocar todo o modelo de IA para cada consulta e cada correspondência candidata. Ela é especialmente adequada para casos de uso em que a latência e a sobrecarga computacional dos modelos de reclassificação são excessivas ou em que o número de candidatos a comparar é grande demais para esse tipo de modelo.

Esse modelo gera uma sequência de embeddings, um por token de entrada, e os usuários podem selecionar embeddings de tokens com 128, 96 ou 64 dimensões. As correspondências de texto candidatas são limitadas a 8.192 tokens. As consultas são codificadas de forma assimétrica, portanto é necessário especificar se um texto é uma consulta ou uma correspondência candidata, além de limitar consultas a 32 tokens.

Jina CLIP v2

jina-clip-v2 é um modelo de embedding multimodal com 900 milhões de parâmetros, treinado para que textos e imagens gerem embeddings próximos entre si quando o texto descreve o conteúdo da imagem. Seu uso principal é a recuperação de imagens com base em consultas textuais, mas ele também é um modelo somente de texto com alto desempenho, reduzindo custos para os usuários, já que não é necessário manter modelos separados para recuperação de texto para texto e de texto para imagem.

Esse modelo oferece suporte a um contexto de entrada de texto de 8.192 tokens, e as imagens são redimensionadas para 512 × 512 pixels antes da geração dos embeddings.

Arquiteturas de pré-treinamento contrastivo de linguagem e imagem (CLIP) são fáceis de treinar e operar e podem gerar modelos muito compactos, mas apresentam algumas limitações fundamentais. Eles não conseguem usar conhecimento de um meio para melhorar seu desempenho em outro. Ou seja, não conseguem aproveitar informações de um meio para aprimorar o desempenho em outro. Assim, embora um modelo possa saber que as palavras “cão” e “gato” são mais próximas em significado entre si do que qualquer uma delas em relação a “carro”, ele não necessariamente saberá que a imagem de um cão e a imagem de um gato são mais relacionadas entre si do que qualquer uma delas em relação à imagem de um carro.

Esses modelos também sofrem do que se chama de lacuna de modalidade: um embedding de um texto sobre cães tende a ficar mais próximo de um embedding de um texto sobre gatos do que de um embedding de uma imagem de cães. Por causa dessa limitação, recomendamos usar CLIP como um modelo de recuperação de texto para imagem ou como um modelo somente de texto, mas não misturar os dois em uma única consulta.

Modelos de reclassificação

Modelos de reclassificação recebem como entrada uma consulta e uma ou mais correspondências candidatas e as comparam diretamente, produzindo correspondências com precisão muito maior.

Em princípio, seria possível usar um reclassificador diretamente para recuperação de informações, comparando cada consulta com cada documento armazenado, mas isso seria computacionalmente muito caro e impraticável para qualquer coleção que não seja muito pequena. Por isso, reclassificadores tendem a ser usados para avaliar listas relativamente curtas de correspondências candidatas encontradas por outros meios, como busca baseada em embeddings ou outros algoritmos de recuperação. Modelos de reclassificação são ideais para esquemas de busca híbrida e federada, nos quais executar uma busca pode significar enviar consultas a sistemas de busca separados, com conjuntos de dados distintos, cada um retornando resultados diferentes. Eles funcionam muito bem para combinar resultados diversos em um único resultado de alta qualidade.

A busca baseada em embeddings pode exigir um grande investimento, envolvendo a reindexação de todos os dados armazenados e a mudança das expectativas dos usuários em relação aos resultados. Adicionar um reclassificador a um esquema de busca existente pode trazer muitos dos benefícios da IA sem a necessidade de reestruturar toda a solução de busca.

Modelos de reclassificação Jina

Jina Reranker m0

jina-reranker-m0 é um reclassificador multimodal com 2,4 bilhões (2,4 × 10⁹) de parâmetros, que oferece suporte a consultas textuais e a correspondências candidatas compostas por textos e/ou imagens. Ele é o principal modelo para recuperação de documentos visuais, o que o torna uma solução ideal para repositórios de PDFs, digitalizações de texto, capturas de tela e outras imagens geradas ou modificadas por computador que contêm texto ou outras informações semiestruturadas, bem como para dados mistos compostos por documentos de texto e imagens.

Esse modelo recebe uma única consulta e uma correspondência candidata e retorna uma pontuação. Quando a mesma consulta é usada com diferentes candidatos, as pontuações são comparáveis e podem ser usadas para ranqueá-los. Ele oferece suporte a um tamanho total de entrada de até 10.240 tokens, incluindo o texto da consulta e o texto ou imagem candidata. Cada bloco de 28 × 28 pixels necessário para cobrir uma imagem conta como um token no cálculo do tamanho de entrada.

Jina Reranker v3

jina-reranker-v3 é um reclassificador de texto com 600 milhões de parâmetros, com desempenho de ponta entre modelos de tamanho comparável. Ao contrário de jina-reranker-m0, ele recebe uma única consulta e uma lista de até 64 correspondências candidatas e retorna a ordem de ranqueamento. Ele tem um contexto de entrada de 131.000 tokens, incluindo a consulta e todos os candidatos de texto.

Jina Reranker v2

jina-reranker-v2-base-multilingual é um reclassificador multifuncional, de uso geral, muito compacto, com recursos adicionais projetados para oferecer suporte a chamadas de função e consultas SQL. Com menos de 300 milhões de parâmetros, ele fornece reclassificação de texto multilíngue rápida, eficiente e precisa, com suporte adicional para selecionar tabelas SQL e funções externas que correspondam a consultas de texto, o que o torna adequado para casos de uso com IA agêntica.

Modelos de linguagem generativos de pequeno porte

Modelos de linguagem generativos são modelos como o ChatGPT da OpenAI, o Google Gemini e o Claude, da Anthropic, que recebem entradas em texto ou multimídia e respondem com saídas em texto. Não existe um limite bem definido que separe modelos de linguagem grandes (LLMs) de modelos de linguagem pequenos (SLMs), mas os desafios práticos de desenvolver, operar e usar LLMs de ponta são bem conhecidos. Os modelos mais conhecidos não são distribuídos publicamente, portanto só é possível estimar seu tamanho, mas espera-se que ChatGPT, Gemini e Claude estejam na faixa de 1 a 3 trilhões (1–3 × 10¹²) de parâmetros.

Executar esses modelos, mesmo quando estão disponíveis publicamente, está muito além do alcance de hardware convencional, exigindo os chips mais avançados organizados em grandes arranjos paralelos. É possível acessar LLMs por meio de APIs pagas, mas isso envolve custos significativos, alta latência e dificuldades para atender a exigências de proteção de dados, soberania digital e repatriação de nuvem. Além disso, os custos relacionados ao treinamento e à personalização de modelos desse porte podem ser consideráveis.

Consequentemente, uma grande quantidade de pesquisa tem se concentrado no desenvolvimento de modelos menores que, embora não tenham todas as capacidades dos maiores LLMs, conseguem executar tipos específicos de tarefas com a mesma qualidade, a um custo reduzido. Empresas normalmente implantam software para resolver problemas específicos, e com software de IA não é diferente; por isso, soluções baseadas em SLMs costumam ser preferíveis às baseadas em LLMs. Elas geralmente podem ser executadas em hardware comum, são mais rápidas, consomem menos energia e são muito mais fáceis de personalizar.

As ofertas de SLM da Jina estão crescendo à medida que nos concentramos em como levar IA da melhor forma possível a soluções práticas de busca.

Jina SLMs

ReaderLM v2

ReaderLM-v2 é um modelo de linguagem generativo que converte HTML em Markdown ou em JSON, de acordo com esquemas JSON fornecidos pelo usuário e instruções em linguagem natural.

O pré-processamento e a normalização de dados são uma parte essencial do desenvolvimento de boas soluções de busca para dados digitais, mas dados do mundo real, especialmente informações derivadas da web, costumam ser caóticos, e estratégias simples de conversão frequentemente se mostram frágeis. Em vez disso, ReaderLM-v2 oferece uma solução inteligente baseada em modelo de IA, capaz de entender o caos de um dump de árvore DOM de uma página da web e identificar, de forma robusta, elementos úteis.

Com 1,5 bilhão (1,5 × 10⁹) de parâmetros, esse modelo é três ordens de magnitude mais compacto do que LLMs de última geração, mas apresenta desempenho equivalente a eles nessa tarefa específica e bastante restrita.

Jina VLM

jina-VLC é um modelo de linguagem generativo com 2,4 bilhões (2,4 × 10⁹) de parâmetros, treinado para responder a perguntas em linguagem natural sobre imagens. Ele oferece suporte muito robusto a análise de documentos visuais, isto é, responder a perguntas sobre digitalizações, capturas de tela, slides, diagramas e dados de imagem semelhantes que não são naturais.

Por exemplo:

Ele também é muito eficiente na leitura de texto em imagens:

Mas é na compreensão do conteúdo de imagens informativas e produzidas pelo ser humano que jina-vlm realmente se destaca:

Ou:

jina-vlm é especialmente adequado para geração automática de legendas, descrições de produtos, texto alternativo de imagens e aplicações de acessibilidade para pessoas com deficiência visual. Além disso, cria novas possibilidades para sistemas de geração aumentada por recuperação (RAG) utilizarem informações visuais e para agentes de IA processarem imagens sem assistência humana.