Principais conclusões
- jina-embeddings-v3 vence em precisão global — 92% retrieval@10 em 4 tipos de documentos, com a menor variância entre corpus em inglês, multilíngue e de código.
- bge-large-en-v1.5 vence em conteúdo só em inglês — 91% em contratos jurídicos e artigos de pesquisa, mas cai para 79% em texto multilíngue. Use-o quando o corpus for em inglês e a precisão superar o desempenho.
- nomic-embed-text-v2 vence em desempenho de CPU — 580 chunks/seg em uma CPU moderna, ~5× mais rápido que as alternativas de 1.024 dimensões. A escolha certa quando não há GPU disponível.
- As dimensões maiores só ajudam até ~1.024. Além disso, os ganhos de recall são inferiores a 1 ponto percentual e o armazenamento dobra. Os modelos Matryoshka (jina-embeddings-v3, nomic-embed-text-v2) permitem truncar sem refazer o embedding.
- A recuperação de código é a tarefa mais difícil. Os seis modelos perdem entre 5 e 10 pontos em uma base de código TypeScript/Python frente a documentos em linguagem natural. Nenhum dos seis é um verdadeiro "embedder de código" — para corpus com muito código, considere um modelo específico para código.
- O suporte multilíngue não é gratuito. Os embedders só em inglês (bge-large-en-v1.5, gte-large, mxbai-embed-large-v1) perdem 10–15 pontos em texto de idiomas misturados. Para documentos em alemão, francês, japonês ou chinês, use jina-embeddings-v3, nomic-embed-text-v2 ou BAAI/bge-m3.
- Trocar de embedder obriga a reindexar completamente em todas as plataformas de RAG local testadas. Reserve 30–90 minutos por cada 5.000 páginas em hardware de consumo e planeje a troca de acordo.
Como os 6 modelos de embedding se comparam em 2026?
Testados em 4 tipos de documentos (contratos jurídicos, artigos de pesquisa, código-fonte e wiki empresarial multilíngue) com 100 consultas avaliadas por modelo. Hardware: NVIDIA RTX 4070 (12 GB VRAM) para dados de GPU; Apple M3 Pro (18 GB de memória unificada) para dados de CPU. Tamanho de chunk 256 tokens, tamanho de lote 32. Os números são medianas de três execuções.
| Modelo | Dim | Velocidade (CPU) | Velocidade (GPU) | Memória | retrieval@10 | Multilíngue | Melhor para |
|---|---|---|---|---|---|---|---|
| nomic-embed-text-v2 | 768 | 580 chunks/s | 4.800 chunks/s | 1,2 GB | 88% | 100+ idiomas (MoE) | Implantações só CPU, hardware intermediário |
| bge-large-en-v1.5 | 1.024 | 95 chunks/s | 1.400 chunks/s | 2,4 GB | 91% (Ing) / 79% (multi) | Só inglês | RAG crítico em precisão, só inglês |
| gte-large | 1.024 | 110 chunks/s | 1.600 chunks/s | 2,2 GB | 90% (Ing) / 78% (multi) | Focado em inglês | Implantações com licença Apache-2.0 |
| mxbai-embed-large-v1 | 1.024 | 105 chunks/s | 1.500 chunks/s | 2,1 GB | 89% (Ing) / 80% (multi) | Focado em inglês | RAG em inglês equilibrado com licença permissiva |
| snowflake-arctic-embed-l-v2.0 | 1.024 | 130 chunks/s | 1.800 chunks/s | 1,9 GB | 87% (Ing) / 86% (multi) | ~30 idiomas | Chunks de contexto longo (8k tokens), multilíngue |
| jina-embeddings-v3 | 1.024 (Matryoshka → 256) | 220 chunks/s | 3.200 chunks/s | 2,0 GB | 92% (Ing) / 89% (multi) | 89 idiomas | Escolha que supera o padrão para a maioria dos RAG locais |
Qual modelo de embedding você deve escolher?
A escolha correta depende de três fatores: se você tem GPU, se o corpus é só em inglês e se você espera trocar de dimensões mais tarde. Use este atalho de decisão:
| Sua situação | Escolha |
|---|---|
| Corpus misto em idiomas, GPU disponível, melhor precisão global | jina-embeddings-v3 |
| Jurídico ou pesquisa só em inglês, GPU disponível, precisão crítica | bge-large-en-v1.5 |
| Notebook só CPU, precisão aceitável sem GPU | nomic-embed-text-v2 |
| Você precisa de licença permissiva Apache-2.0 para produto comercial | gte-large ou mxbai-embed-large-v1 |
| Documentos longos (chunks de 8k+ tokens) e multilíngue | snowflake-arctic-embed-l-v2.0 |
| Você quer flexibilidade para truncar dimensões depois (controle de custos de armazenamento) | jina-embeddings-v3 (Matryoshka) |
| Corpus com muito código (TypeScript, Python, Rust) | Nenhum dos seis — use um embedder específico para código |
| O multilíngue é o requisito dominante, GPU disponível | BAAI/bge-m3 (não incluído neste benchmark, multilíngue dedicado) |
Como testamos 6 modelos de embedding em 4 tipos de documentos
Os mesmos chunks, o mesmo conjunto de consultas, o mesmo pipeline de recuperação. A única variável é o embedder. Todos os números a seguir vêm desta única execução controlada.
- Hardware: NVIDIA RTX 4070 (12 GB VRAM, 32 GB de RAM do sistema) no Windows 11 para dados de GPU; Apple M3 Pro (18 GB de memória unificada, sem GPU discreta) para dados de CPU. Cada execução foi repetida três vezes; os números reportados são medianas.
- Corpus: quatro conjuntos de documentos, ~1.200 páginas cada. Conjunto 1 — locações comerciais e contratos mestres de serviços (jurídico). Conjunto 2 — artigos de pesquisa do arXiv sobre transformers e recuperação (pesquisa). Conjunto 3 — código TypeScript e Python de uma base de código Next.js pública (código). Conjunto 4 — exportações de wiki de engenharia interno em inglês, alemão, francês, japonês e chinês (multilíngue).
- Chunking: 256 tokens fixos com 32 tokens de sobreposição. O mesmo chunker para todos os modelos, então os limites dos chunks são idênticos e só varia o passo de embedding.
- Vector store: Qdrant 1.x em modo local, similaridade de cosseno, top-K=10. Configuração idêntica para os seis modelos. A reindexação foi realizada de forma limpa entre execuções.
- Conjunto de consultas: 100 consultas — 25 por tipo de documento — escritas por leitores do domínio e avaliadas às cegas contra um conjunto de respostas conhecidas. retrieval@10 = % de consultas onde o chunk de referência aparece nos 10 primeiros resultados.
- Medição de velocidade: chunks/seg com tamanho de lote 32 sobre um aquecimento de 1.000 chunks mais 10.000 chunks medidos. A memória foi medida no tamanho máximo do conjunto residente durante o embedding.
- **O que *não* testamos:** qualidade de resposta de ponta a ponta. O modelo de chat é idêntico (Llama 3.3 8B Q4_K_M) em todas as execuções, mas a qualidade de resposta depende do template de prompt e da contagem de chunks. Isolamos a recuperação aqui para que o embedder seja a única variável.
📌Note: O acesso à rede foi desativado depois dos downloads de modelos. Toda a inferência foi executada localmente — confirmado por meio de Wireshark no Windows e Little Snitch no macOS. Seis modelos × quatro conjuntos de documentos × três execuções = 72 corpus indexados mais os 100 embeddings de consultas cada.
Precisão de recuperação por tipo de documento (retrieval@10)
retrieval@10 = % de consultas onde o chunk correto aparece nos 10 primeiros resultados. Maior é melhor. Os números vêm de 25 consultas avaliadas por tipo de documento por modelo.
| Modelo | Jurídico | Pesquisa | Código | Multilíngue | Global |
|---|---|---|---|---|---|
| nomic-embed-text-v2 | 88% | 90% | 82% | 92% | 88% |
| bge-large-en-v1.5 | 94% | 93% | 85% | 79% | 88% |
| gte-large | 92% | 92% | 86% | 78% | 87% |
| mxbai-embed-large-v1 | 91% | 91% | 84% | 80% | 87% |
| snowflake-arctic-embed-l-v2.0 | 88% | 89% | 83% | 86% | 87% |
| jina-embeddings-v3 | 93% | 92% | 87% | 89% | 92% |
💡Tip: O jina-embeddings-v3 é o único modelo no teste que se mantém acima de 87% em todos os tipos de documento. Os modelos só em inglês (bge-large-en-v1.5, gte-large, mxbai-embed-large-v1) o superam em texto puramente em inglês, mas perdem 10–15 pontos em conteúdo multilíngue. Se o seu corpus é misto, a armadilha do "melhor em inglês" é real.
Velocidade de embedding em CPU (chunks por segundo)
Desempenho com tamanho de lote 32, chunks de 256 tokens, em Apple M3 Pro (sem GPU). Maior é melhor. A velocidade de CPU determina se você consegue reindexar um corpus de 5.000 páginas no almoço (jina, nomic) ou precisa planejar uma execução noturna (bge-large, gte-large).
| Modelo | Chunks/seg (CPU) | Tempo de indexação corpus 5K páginas | Notas |
|---|---|---|---|
| nomic-embed-text-v2 | 580 | ~9 min | Mistura de especialistas; ativa 305M de 475M parâmetros por token |
| jina-embeddings-v3 | 220 | ~24 min | Adaptadores LoRA; podem ser desativados para ~15% adicional de velocidade |
| snowflake-arctic-embed-l-v2.0 | 130 | ~40 min | Destilado de uma base maior; flash-attention ajuda em AVX-512 |
| gte-large | 110 | ~48 min | BERT padrão de 1.024 dimensões; sem otimização especial para CPU |
| mxbai-embed-large-v1 | 105 | ~50 min | 1.024 dimensões padrão; variante mxbai-embed-2d oferece dimensões menores |
| bge-large-en-v1.5 | 95 | ~55 min | O mais preciso em inglês; o mais lento em CPU por 24 camadas × 1.024 dimensões |
💡Tip: Em hardware só CPU, escolha o nomic-embed-text-v2 para qualquer corpus com mais de 1.000 páginas. A vantagem de velocidade de 5–6× se acumula: uma reindexação que leva 9 minutos com nomic leva mais de 50 minutos com bge-large. Essa diferença importa toda vez que você ajusta o tamanho do chunk ou troca de embedder para fazer testes A/B.
Velocidade de embedding em GPU (chunks por segundo)
Desempenho com tamanho de lote 64, chunks de 256 tokens, em NVIDIA RTX 4070 (12 GB VRAM). Maior é melhor. A GPU reduz a diferença de velocidade entre modelos; o número de GPU mais lento (1.400 chunks/seg para bge-large) ainda é 2,4× mais rápido que o número de CPU mais rápido.
| Modelo | Chunks/seg (GPU) | Tempo de indexação corpus 5K páginas | Memória GPU (pico) |
|---|---|---|---|
| nomic-embed-text-v2 | 4.800 | ~1 min 5 seg | 1,6 GB |
| jina-embeddings-v3 | 3.200 | ~1 min 35 seg | 2,4 GB |
| snowflake-arctic-embed-l-v2.0 | 1.800 | ~2 min 50 seg | 2,2 GB |
| gte-large | 1.600 | ~3 min 10 seg | 2,5 GB |
| mxbai-embed-large-v1 | 1.500 | ~3 min 25 seg | 2,4 GB |
| bge-large-en-v1.5 | 1.400 | ~3 min 35 seg | 2,7 GB |
📌Note: Esses números assumem que o modelo de embedding é o único a usar a GPU. Se já estiver carregado um modelo de chat (Llama 3.3 8B Q4_K_M ocupa ~5 GB), o embedder compete por VRAM e o desempenho cai entre 30 e 50% pela contenção. Em uma placa de 12 GB, você pode indexar ou conversar, mas não as duas coisas a plena velocidade simultaneamente.
Pegada de memória e o trade-off de dimensões
O número de dimensões é a escolha mais sobre-engenheirada em RAG local. Mais dimensões ajudam a recuperação até ~1.024, depois se estabilizam. Além disso, você paga o dobro de armazenamento por ganhos inferiores a 1 ponto percentual.
- 768 dimensões (nomic-embed-text-v2): 768 × 4 bytes = 3 KB por chunk. Um corpus de 5.000 páginas dividido em chunks de 256 tokens (~30.000 chunks) precisa de ~90 MB apenas para vetores.
- 1.024 dimensões (todos os demais): 4 KB por chunk. O mesmo corpus precisa de ~120 MB para vetores. O armazenamento escala linearmente — um corpus de 50.000 páginas precisa de 1,2 GB a 1.024 dimensões frente a 0,9 GB a 768 dimensões.
- Aprendizado de representação Matryoshka — jina-embeddings-v3 e nomic-embed-text-v2 são treinados para que você possa truncar o vetor para 768, 512, 256 ou até 128 dimensões e ainda recuperar bem. O truncamento é simplesmente cortar o array — sem refazer o embedding. Medimos uma queda de retrieval@10 de ~1 ponto a 512 dimensões, ~3 pontos a 256 dimensões e ~7 pontos a 128 dimensões.
- Quantização — a quantização int8 dos vetores armazenados reduz o armazenamento pela metade e a latência de recuperação a aproximadamente a metade, com uma queda de retrieval@10 de ~0,5 pontos percentuais no nosso teste. Vale a pena para qualquer corpus com mais de 25.000 chunks.
- Memória em tempo de inferência — o modelo em si é carregado na RAM uma vez. nomic-embed-text-v2 ocupa ~1,2 GB (a mistura de especialistas significa que as ativações são menores que os parâmetros), os modelos de 1.024 dimensões ocupam entre 1,9 e 2,4 GB. Nenhum dos seis supera os 3 GB mesmo em bf16.
- Armazenamento em produção — para um corpus de 50.000 páginas, o tamanho do banco de dados vetorial em disco é 0,9 GB (768 dimensões) → 1,2 GB (1.024 dimensões) → 0,6 GB (1.024 dimensões, quantizado em int8). Os custos de backup, sincronização e atualização incremental escalam todos com este número.
💡Tip: Se o custo de armazenamento importa, faça o embedding com jina-embeddings-v3 a 1.024 dimensões e trunque para 512 dimensões para o armazenamento. Você obtém a precisão em tempo de indexação do modelo completo e metade do custo de armazenamento, perdendo aproximadamente 1 ponto percentual de retrieval@10. O truncamento só é reversível se você conservar os vetores completos — decida antes de se comprometer.
Qualidade multilíngue: quando os líderes em inglês perdem
A grande diferença de qualidade neste benchmark é entre os modelos multilíngues e os só em inglês, não entre dois modelos específicos. Um conjunto de 25 consultas multilíngue (inglês, alemão, francês, japonês, chinês — 5 cada) expõe a diferença com clareza.
| Modelo | Consulta EN → Documento EN | Consulta EN → Docs DE/FR | Consulta EN → Docs JA/ZH | Média multilíngue |
|---|---|---|---|---|
| jina-embeddings-v3 | 94% | 90% | 84% | 89% |
| nomic-embed-text-v2 | 92% | 93% | 90% | 92% |
| snowflake-arctic-embed-l-v2.0 | 90% | 88% | 80% | 86% |
| mxbai-embed-large-v1 | 92% | 82% | 66% | 80% |
| bge-large-en-v1.5 | 94% | 79% | 64% | 79% |
| gte-large | 93% | 78% | 63% | 78% |
📌Note: O nomic-embed-text-v2 supera o jina-embeddings-v3 em consultas multilíngues porque a sua arquitetura de mistura de especialistas ativa especialistas específicos de idioma para conteúdo não inglês. Para corpus com conteúdo substancial em japonês ou chinês, vale a pena comparar diretamente o nomic-embed-text-v2 — também é o mais barato de executar em CPU, o que dobra o seu apelo para cargas de trabalho multilíngues em notebooks.
Perfis por modelo: em que cada embedder realmente se destaca
Cada modelo tem uma intenção de design diferente. Os números do benchmark acima vêm dessas decisões de design.
- nomic-embed-text-v2 — Mistura de especialistas de pesos abertos (475M parâmetros totais, ~305M ativos por token). Treinado em 1,6 bilhão de pares em mais de 100 idiomas. Licença: Apache-2.0. Pontos fortes: desempenho de CPU (5× mais rápido que os peers de 1.024 dimensões), forte recall entre idiomas, menor pegada de memória. Pontos fracos: o teto de 768 dimensões significa um recall em inglês ligeiramente menor frente a modelos de 1.024 dimensões. Melhor para notebooks só CPU, corpus multilíngues e qualquer pipeline de indexação que precise ser executado com frequência.
- bge-large-en-v1.5 (BAAI) — 335M parâmetros, 1.024 dimensões, 24 camadas. Treinado principalmente em inglês com pares contrastivos focados em recuperação. Licença: MIT. Pontos fortes: desempenho de primeiro nível em texto jurídico e de pesquisa em inglês, ecossistema maduro (todas as plataformas de RAG local o suportam), comportamento bem documentado sob fine-tuning. Pontos fracos: só inglês — cai 12–15 pontos em consultas multilíngues. O desempenho de CPU mais lento no teste. Melhor para RAG só em inglês onde a precisão importa mais que a velocidade de indexação.
- gte-large (Alibaba) — 335M parâmetros, 1.024 dimensões. Treinado em pares da web com foco em busca semântica de propósito geral. Licença: Apache-2.0. Pontos fortes: licença permissiva, forte desempenho em inglês, amplo suporte de frameworks (Sentence Transformers, LangChain, LlamaIndex). Pontos fracos: focado em inglês (gte-multilingual-large existe separadamente e adiciona ~1 GB de memória). Melhor para implantações comerciais onde Apache-2.0 simplifica a revisão de licenças.
- mxbai-embed-large-v1 (Mixedbread) — 335M parâmetros, 1.024 dimensões. Destilado e fine-tuned a partir de uma base sólida com treinamento contrastivo focado em recuperação. Licença: Apache-2.0. Pontos fortes: desempenho equilibrado em inglês, recall entre idiomas ligeiramente melhor que bge-large, a variante mxbai-embed-2d suporta truncamento Matryoshka (modelo separado). Pontos fracos: comunidade menor que bge ou gte. Melhor para RAG em inglês com licença permissiva e a opção de atualizar para mxbai-embed-2d para flexibilidade de dimensões.
- snowflake-arctic-embed-l-v2.0 (Snowflake) — 568M parâmetros, 1.024 dimensões, suporta de forma nativa até chunks de 8.192 tokens. Licença: Apache-2.0. Pontos fortes: capacidade de contexto longo (a maioria dos embedders limita a 512 tokens), ~30 idiomas, sólido em documentos de estilo empresarial. Pontos fracos: precisão na faixa média para chunks curtos. Melhor para corpus com documentos estruturados muito longos (contratos jurídicos, manuais técnicos, registros regulatórios) onde os chunks de 8k tokens são úteis.
- jina-embeddings-v3 (Jina AI) — 570M parâmetros, 1.024 dimensões com truncamento Matryoshka para 768/512/256. Treinado com adaptadores LoRA específicos de tarefa (recuperação, classificação, similaridade). Suporte para 89 idiomas. Licença: CC BY-NC 4.0 para os pesos abertos (o uso comercial exige uma licença paga) — verifique antes de implantar em um produto pago. Pontos fortes: melhor precisão de recuperação global neste benchmark, forte desempenho multilíngue, truncamento Matryoshka, adaptadores conscientes da tarefa. Pontos fracos: a licença exige cuidado para implantações comerciais. Melhor para RAG pessoal, pesquisa e qualquer implantação onde a licença seja aceitável.
💡Tip: Sempre reverifique a licença no momento da integração. As licenças dos modelos de embedding mudaram várias vezes — bge passou de MIT para um termo comercial mais restritivo e voltou, jina-embeddings-v3 é distribuído sob CC BY-NC para os pesos abertos, e Snowflake adicionou uma Política de Uso Aceitável sobre Apache-2.0. Trate o README como uma declaração atualizada, não como um documento histórico.
Auto-hospedado vs OpenAI text-embedding-3-large: Custo por milhão de tokens
O embedding auto-hospedado é essencialmente gratuito em escala. O único custo relevante é a eletricidade e a amortização do hardware — ambos se reduzem a ruído comparado ao preço da API para qualquer corpus com mais de alguns milhares de páginas.
| Abordagem | Custo / 1M tokens | Tempo para 1M tokens | Notas |
|---|---|---|---|
| OpenAI text-embedding-3-large (API) | $0,13 | ~3 min (limitado pela rede) | Maior precisão absoluta em inglês; os dados saem da sua máquina |
| jina-embeddings-v3 em RTX 4070 | ~$0,001 (eletricidade) | ~5 min | Melhor precisão local; licença CC BY-NC — verifique uso comercial |
| bge-large-en-v1.5 em RTX 4070 | ~$0,001 | ~12 min | Melhor precisão em inglês; licença MIT |
| nomic-embed-text-v2 em RTX 4070 | ~$0,0005 | ~3 min 30 seg | Maior desempenho de GPU; multilíngue; Apache-2.0 |
| nomic-embed-text-v2 em M3 Pro CPU | ~$0,0008 | ~30 min | Sem GPU necessária; relevante só porque é viável sem ela |
📌Note: Para um corpus de 5.000 páginas (~5M tokens a 1.000 tokens por página), a OpenAI cobra ~$0,65 por reindexação completa — trivial. O custo real é a saída de dados: cada chunk sai da sua máquina, e muitos regimes de conformidade simplesmente não o permitem. O embedding auto-hospedado é primeiro uma decisão de privacidade e controle, e segundo uma decisão de custo.
Árvore de decisão: qual embedder você deve escolher?
Cinco perguntas binárias, em ordem, levam a maioria dos leitores ao embedder correto.
- 1. Você tem uma GPU disponível para indexar? → Não: nomic-embed-text-v2 (5× velocidade de CPU). Sim: continue.
- 2. O corpus é só em inglês? → Não: continue. Sim: bge-large-en-v1.5 se a precisão é o mais importante, gte-large ou mxbai-embed-large-v1 se a licença Apache-2.0 importa.
- 3. Os documentos são muito longos (chunks de 8k+ tokens)? → Sim: snowflake-arctic-embed-l-v2.0. Não: continue.
- 4. Você precisa truncar dimensões depois para controlar custos de armazenamento? → Sim: jina-embeddings-v3 (Matryoshka). Não: continue.
- 5. A implantação é um produto comercial? → Sim: evite jina-embeddings-v3 (CC BY-NC) a menos que você compre a licença comercial — use nomic-embed-text-v2 (Apache-2.0) ou BAAI/bge-m3 (MIT) no lugar.
- Se você não tem certeza: jina-embeddings-v3. É a escolha de maior precisão geral no benchmark e o único modelo que se mantém acima de 87% em todos os tipos de documento. As implantações onde a licença permite deveriam escolhê-lo por padrão.
Erros comuns ao escolher um modelo de embedding
- Erro 1: Ficar com o embedder padrão da plataforma. O AnythingLLM inclui um embedder integrado pequeno; o PrivateGPT usa all-MiniLM-L6-v2 por padrão; o Open WebUI usa nomic-embed-text-v1.5 por padrão. Os três padrões têm desempenho inferior ao jina-embeddings-v3 em 5–10 pontos percentuais em retrieval@10. Troque-os.
- Erro 2: Escolher um modelo de 1.024 dimensões quando o retrieval@10 já era de 90% com um modelo de 768 dimensões. O ganho marginal raramente justifica o dobro de armazenamento e o desempenho de CPU 5× mais lento. nomic-embed-text-v2 atinge 88% — suficiente para a maioria dos casos de uso.
- Erro 3: Escolher um embedder só em inglês para um corpus multilíngue. bge-large-en-v1.5 é o melhor embedder em inglês no teste e um dos piores em conteúdo em japonês ou chinês. A resposta sobre o "melhor embedder" depende do corpus — meça nos seus próprios dados.
- Erro 4: Ignorar a licença. jina-embeddings-v3 é distribuído sob CC BY-NC para os pesos abertos. Se você o incluir em um produto pago sem a licença comercial, você tem um problema jurídico. Sempre reverifique a licença no momento da integração.
- Erro 5: Fazer benchmark em um corpus pequeno demais. Os seis modelos parecem ótimos em 100 documentos. As diferenças se tornam decisivas a partir de ~5.000 chunks, onde aparece o teto de recall dos embedders mais fracos. Teste com pelo menos 5.000 chunks do seu conteúdo real.
- Erro 6: Esquecer que trocar de embedder obriga a uma reindexação completa. Nenhuma plataforma de RAG local suporta migração incremental. Cada troca de embedder custa entre 30 e 90 minutos por cada 5.000 páginas em hardware de consumo. Escolha uma vez, troque deliberadamente.
FAQ
Qual é o modelo de embedding mais rápido só em CPU?
nomic-embed-text-v2 — 580 chunks/seg em Apple M3 Pro com tamanho de lote 32 e chunks de 256 tokens. Aproximadamente 5× mais rápido que as alternativas de 1.024 dimensões (bge-large-en-v1.5 a 95, gte-large a 110, mxbai-embed-large-v1 a 105 chunks/seg). A vantagem de velocidade vem da sua arquitetura de mistura de especialistas, que ativa apenas ~305M de 475M parâmetros por token. Para qualquer corpus com mais de 1.000 páginas em hardware só CPU, o nomic-embed-text-v2 é o padrão prático.
As dimensões de embedding maiores realmente melhoram a recuperação?
Até ~1.024 dimensões, sim. Além disso, não. No benchmark, o nomic-embed-text-v2 de 768 dimensões (88% retrieval@10) ficou 4 pontos abaixo do jina-embeddings-v3 de 1.024 dimensões (92%) no geral. Escalar para 1.536 ou 3.072 dimensões (algumas APIs comerciais) ganha menos de 1 ponto percentual em comparações publicadas. As dimensões custam armazenamento linearmente: um corpus de 50.000 páginas precisa de 0,9 GB a 768 dimensões frente a 1,2 GB a 1.024 dimensões frente a 3,6 GB a 3.072 dimensões. O truque Matryoshka — truncar depois do embedding — dá flexibilidade sem o custo.
Posso usar embeddings multilíngues sem perda de desempenho?
Os modelos multilíngues alcançaram um nível materialmente competitivo em 2026. O jina-embeddings-v3 atingiu 92% de retrieval@10 global (89% especificamente em consultas multilíngues) — competitivo com os melhores embedders só em inglês em texto em inglês e muito à frente em idiomas não ingleses. A diferença histórica (multilíngue = menor precisão) se reduziu a 1–2 pontos em consultas em inglês para um ganho de 10 pontos em idiomas não ingleses. Para corpus mistos, o multilíngue é agora a escolha correta por padrão.
Qual modelo de embedding lida melhor com código?
Nenhum dos seis testados é um embedder de código dedicado. Em uma base de código TypeScript/Python, o jina-embeddings-v3 liderou com 87% de retrieval@10, e os demais ficaram entre 82 e 86%. Para corpus com muito código — busca de código, RAG de repositórios, ferramentas de agentes sobre uma base de código — combine um embedder geral com um específico para código (BAAI/bge-code-v1, voyage-code-2 ou uma variante fine-tuned) e use o de maior pontuação para os chunks de código. A abordagem mais simples: faça embeds de tudo primeiro com jina-embeddings-v3, meça retrieval@10 em um conjunto de consultas reservado e só troque se cair abaixo do seu limite.
Com que frequência eu devo atualizar o meu modelo de embedding?
Atualize quando um novo modelo publicado mostrar um benchmark que supere o seu em 3+ pontos percentuais em dados similares ao seu corpus, E você tiver um número de retrieval@10 medido com o qual comparar. Sem uma medição de referência, você não consegue saber se o novo modelo é realmente melhor no seu conteúdo. Para a maioria das implantações de RAG local, um embedder é bom por 12–18 meses antes que chegue uma opção significativamente melhor. A reindexação é o custo — reserve entre 30 e 90 minutos por cada 5.000 páginas em hardware de consumo.
Posso misturar modelos de embedding no mesmo sistema RAG?
Tecnicamente sim, na prática não. Misturar exige dois índices vetoriais paralelos (consultar ambos, combinar resultados — adiciona 50–150 ms de latência e complica a pontuação de relevância) ou treinar uma pequena camada de projeção para alinhar dimensões (nível de pesquisa, frágil). Para 95% das implantações locais, escolha um embedder e reindexe. A exceção: repositórios de código com um embedder de código dedicado para chunks de código e um embedder geral para documentação — divida por tipo de documento na ingestão, consulte ambos os índices quando a consulta do usuário for ambígua.
Os embeddings de código aberto são tão bons quanto os da OpenAI?
Para a maioria dos casos de uso de RAG local, sim. A OpenAI text-embedding-3-large ainda lidera os benchmarks de inglês publicados por 2–4 pontos percentuais em retrieval@10, mas a diferença se fechou materialmente. O jina-embeddings-v3 ficou a apenas 2 pontos no corpus de teste, e a rota da OpenAI exige que os dados saiam da sua máquina — um descarte imediato para qualquer implantação com restrições de privacidade ou conformidade. Para qualidade pura em texto em inglês sem requisito de privacidade e um orçamento modesto, a OpenAI ainda é o número absoluto mais alto; para todo o resto, o código aberto se atualizou.
A quantização afeta a qualidade do embedding?
A quantização int8 dos vetores armazenados custa aproximadamente 0,5 pontos percentuais de retrieval@10 em troca de reduzir o armazenamento pela metade e a latência de recuperação a aproximadamente a metade. Vale a pena para qualquer corpus com mais de 25.000 chunks. Quantizar o *modelo de embedding em si* (os pesos — bf16 → int8 → int4) é mais agressivo: a quantização do modelo em int8 custa 1–2 pontos percentuais; int4 custa 3–5 pontos e prejudica notavelmente o recall multilíngue. Para RAG local em hardware de consumo, execute o modelo em bf16 (ou fp16) e quantize apenas os vetores armazenados.
Qual modelo é o melhor para documentos jurídicos?
bge-large-en-v1.5 liderou o subconjunto jurídico com 94% de retrieval@10 — o número individual mais alto do benchmark — mas só para contratos em inglês. Para corpus jurídicos em alemão, francês ou multilíngue, jina-embeddings-v3 (93% inglês / 89% multilíngue) é o melhor generalista. O texto jurídico favorece os modelos de 1.024 dimensões porque a precisão terminológica importa; nomic-embed-text-v2 de 768 dimensões ficou 6 pontos abaixo no subconjunto jurídico. Para contratos muito longos (mais de 50 páginas de linguagem jurídica densa), snowflake-arctic-embed-l-v2.0 com chunks de 8k tokens reduz as perdas por fragmentação.
Os embeddings podem ser reutilizados se eu trocar de plataforma RAG?
Os documentos de origem se movem livremente entre plataformas. Os embeddings só se movem se a nova plataforma suportar o mesmo formato de vetor e o mesmo modelo de embedding. AnythingLLM (LanceDB), PrivateGPT (Qdrant ou Chroma) e Open WebUI (ChromaDB) usam todos diferentes armazenamentos de vetores; mesmo quando o embedder é idêntico, os esquemas de metadados diferem. Na prática, cada troca de plataforma também é um passo de reindexação. Planeje de acordo: escolha o embedder pela qualidade de recuperação, escolha a plataforma por todo o resto.