Podem coexistir vários modelos de embeddings num único sistema de pesquisa privado?

Eva Wong é a Redatora Técnica e e entusiasta residente na ZimaSpace. Uma geek de longa data com paixão por homelabs e software de código aberto, ela é especialista em traduzir conceitos técnicos complexos em guias acessíveis e práticos . Eva acredita que o auto-hospedagem deve ser divertida, não intimidante. Através dos seus tutoriais, ela capacita a comunidade adesmistificar configurações de hardware , desde a construção do seu primeiro NAS até dominar os contêineres Docker., from building their first NAS to mastering Docker containers.

Sim. Um único sistema privado de pesquisa pode armazenar e consultar incorporações de vários modelos ao mesmo tempo. A abordagem segura consiste em tratar cada modelo de incorporação como o seu próprio espaço vetorial, com dimensões, métrica de distância, versão e configuração do índice explícitas. Não misture vetores incompatíveis numa única coluna anónima, presumindo que são comparáveis.

Vários modelos são úteis para migrações, pesquisa multilingue, recuperação combinada de imagens e texto, incorporações específicas de um domínio ou testes A/B. A complexidade surge quando é necessário combinar resultados entre esses espaços.

Por que manteria mais do que um modelo de incorporação?

Motivo Exemplo
Migração do modelo O codificador antigo permanece ativo enquanto os novos vetores são preenchidos retroativamente
Pesquisa multilingue Modelo geral de inglês + modelo multilingue
Modalidades diferentes Incorporações de texto + incorporações de imagens
Especialização por domínio Documentos gerais + incorporações de código
Testes de qualidade Recuperação A/B antes de substituir o modelo de produção
Interação tardia Recuperador denso + reordenação ao estilo ColBERT

Uma base de conhecimento privada evolui. Fixar permanentemente todos os documentos ao primeiro modelo de incorporação escolhido torna as atualizações desnecessariamente perturbadoras.

Modelos diferentes produzem espaços vetoriais diferentes

Dois modelos podem ambos gerar vetores com 768 dimensões e, ainda assim, serem incompatíveis. As coordenadas só têm significado relativamente ao modelo que as produziu.

Documento A
  |
  +-- Modelo v1 -> vector_v1 [768]
  |
  +-- Modelo v2 -> vector_v2 [1024]
  |
  +-- modelo de imagem -> vector_image [512]

Uma consulta gerada com o Modelo v2 deve pesquisar o espaço v2. Compará-la diretamente com vetores do Modelo v1 não tem significado, mesmo que uma API aceite as dimensões.

A documentação atual do Qdrant sobre vetores nomeados suporta explicitamente vários vetores de diferentes tamanhos e tipos no mesmo ponto, cada um num espaço de vetores nomeado separado.

Utilize um registo de modelos, não apenas um nome de vetor

Registe metadados suficientes para reproduzir cada incorporação:

espaço_de_incorporação: text_v2
id_do_modelo:        exemplo/nome-do-modelo
revisão_do_modelo:  sha-ou-versão
dimensão_do_vetor:      1024
métrica:          cosseno
normalizado:      verdadeiro
política_de_segmentação: semântica-v3
criado_em:      2026-09-03

A divisão em segmentos também deve fazer parte do registo. Se alterar tanto o modelo de embeddings como a forma de dividir os documentos, a recuperação muda por dois motivos. Manter explícita a versão do pipeline permite comparar e reverter alterações.

-15% OFF

Uma coleção com vetores nomeados ou coleções separadas?

Ambos os designs podem estar corretos.

Design Mais indicado quando Compromisso
Vetores nomeados no mesmo objeto Os mesmos documentos/dados em todos os modelos Maior dimensão dos objetos/índices
Coleções separadas Esquemas, ciclo de vida, escala ou permissões diferentes Mais trabalho de sincronização
Uma tabela PostgreSQL + model_id Stack centrado em SQL Os índices têm de ser devidamente delimitados

A documentação de coleções do Weaviate também permite vários espaços vetoriais nomeados por objeto, cada um com a sua própria configuração de vetorizador e índice.

Se as permissões forem diferentes — por exemplo, documentos pessoais em comparação com documentos profissionais —, coleções separadas podem continuar a ser mais simples do que colocar cada representação num único objeto.

O pgvector pode armazenar diferentes dimensões?

Sim. A documentação do pgvector mostra uma coluna vector genérica com um model_id e utiliza depois índices de expressão e parciais para linhas com uma dimensionalidade específica.

O princípio é o mesmo: mantenha a identidade do modelo no modelo de dados e crie o índice ANN apenas sobre linhas compatíveis.

Não compare pontuações de similaridade brutas entre modelos

Esta é a falha mais subtil. Uma similaridade de cosseno de 0,78 do Modelo A não significa necessariamente a mesma qualidade que 0,78 do Modelo B. As distribuições das pontuações dependem do treino do modelo, da normalização, da métrica, do domínio e do comportamento do índice.

Se quiser uma única lista de resultados a partir de dois modelos de embeddings, faça primeiro a recuperação separadamente:

Consulta
  |
  +-- Modelo A -> 20 melhores resultados + classificações
  |
  +-- Modelo B -> 20 melhores resultados + classificações
                      |
                      v
               fusão / reranker
                      |
                      v
                  10 melhores resultados finais

Os métodos de combinação mais seguros incluem a fusão de rankings, a normalização de pontuações específica do modelo e calibrada com os seus dados, ou um cross-encoder/reranker que avalie o texto candidato após a recuperação.

A documentação da Weaviate sobre pesquisa multi-alvo apresenta estratégias de combinação, incluindo combinações normalizadas/ponderadas, ilustrando por que motivo a fusão entre espaços requer uma estratégia explícita em vez de uma ordenação ingénua por pontuações brutas.

Como migrar para um novo modelo de embeddings sem indisponibilidade?

Não elimine primeiro os embeddings antigos. Utilize uma migração paralela:

  1. registe o novo modelo e o espaço vetorial;
  2. gere novos embeddings para os documentos recentemente ingeridos;
  3. preencha os documentos antigos em lotes;
  4. execute pesquisas sombra em ambos os espaços;
  5. compare a recuperação e o sucesso das tarefas em perguntas reais;
  6. altere o espaço de consulta predefinido;
  7. mantenha os vetores antigos durante uma janela de reversão;
  8. remova-os apenas quando tiver um elevado grau de confiança.

A Weaviate observa que adicionar um novo vetor nomeado não volta automaticamente a criar vetores para os objetos existentes. É útil recordar este comportamento, porque «o esquema suporta o novo modelo» e «todos os dados antigos têm novos vetores» são marcos distintos.

Vários embeddings aumentam o armazenamento mais rapidamente do que muitos utilizadores esperam

Cada representação vetorial adicional pode acrescentar outro vetor denso e outro índice ANN. Assim, um segundo modelo de embeddings pode aproximadamente multiplicar a parte da base de dados correspondente aos vetores/índices, embora os documentos originais sejam armazenados apenas uma vez.

Estimativa:

bytes dos vetores ~= 
  blocos de documentos
  x dimensões
  x bytes por elemento
  x número de espaços de embeddings

+ sobrecarga do índice ANN
+ índices de metadados/payload

Os índices quantizados ou de meia precisão podem reduzir o espaço ocupado, mas teste a qualidade da recuperação antes de aplicar a compressão a todos os modelos.

Isto remete para a questão da arquitetura de bases de conhecimento locais: os embeddings são dados derivados substituíveis, enquanto os documentos de origem e os metadados são ativos duradouros que permitem reconstruí-los.

Utilize modelos diferentes para diferentes rotas de consulta

Não tem de pesquisar em todos os espaços vetoriais para cada pergunta. Encaminhe a pesquisa conforme a necessidade:

Consulta Espaço de embeddings
Manuais domésticos em inglês general_text_v2
Notas em chinês + inglês multilingual_v1
Pergunta sobre código-fonte code_v1
Encontrar uma fotografia semelhante image_v1
Pesquisa desconhecida/ampla dois espaços + fusão de classificações

Um pequeno classificador de consultas pode selecionar o espaço adequado, enquanto as pesquisas ambíguas podem ser executadas em duas representações e os resultados podem ser fundidos.

As permissões têm de ser aplicadas antes da fusão

Não recupere candidatos não autorizados de todos os espaços vetoriais, esperando que o reranqueador final os oculte. Aplique as permissões do utilizador/documento em cada etapa da recuperação, para que os fragmentos sensíveis não entrem no conjunto de candidatos, nos registos ou no prompt do reranqueador.

Na pesquisa privada num NAS, a mesma regra de controlo de acesso tem de ser mantida durante as migrações de modelos. Um novo índice deve herdar os metadados de permissões do documento, em vez de se tornar numa cópia temporária sem proteção.

O guia sobre assistentes de IA privados fornece o contexto mais amplo: a pesquisa vetorial só é útil quando respeita os mesmos limites de dados privados que o armazenamento de ficheiros.

Lista de verificação de QA para múltiplos embeddings

  • Atribua a cada espaço de embeddings um ID exclusivo de modelo/versão.
  • Registe as dimensões, a normalização e a métrica de distância.
  • Crie versões para a segmentação e o pré-processamento.
  • Nunca consulte o vetor de um modelo no índice de outro modelo.
  • Não compare diretamente pontuações brutas entre espaços sem calibração.
  • Aplique as permissões em cada percurso de recuperação.
  • Preencha os novos vetores antes de alterar o padrão.
  • Avalie com perguntas reais e documentos relevantes conhecidos.
  • Mantenha o índice anterior durante uma janela de reversão.
  • Inclua vetores e índices adicionais no planeamento da capacidade de disco/RAM.

Perguntas frequentes

Dois modelos de embeddings podem usar dimensões diferentes na mesma base de dados?

Sim, se a base de dados suportar espaços vetoriais, coleções ou índices nomeados separados para cada dimensão compatível. O Qdrant, o Weaviate e o pgvector fornecem padrões para isso.

Posso mudar de modelo de embeddings sem voltar a criar embeddings para os documentos antigos?

Não, se quiser que os documentos antigos possam ser pesquisados no espaço vetorial do novo modelo. Um novo vetor de consulta não é compatível com embeddings produzidos por outro modelo.

Devo manter os embeddings antigos para sempre?

Não. Mantenha-os durante a avaliação e a reversão. Depois de o novo modelo ser validado e a migração estar concluída, remover os vetores obsoletos pode recuperar uma quantidade significativa de armazenamento e memória do índice.

Veredicto final

Vários modelos de embeddings podem coexistir de forma organizada num único sistema de pesquisa privado quando os seus espaços vetoriais permanecem explícitos. Armazene os metadados do modelo e do pipeline, consulte cada espaço com o codificador correspondente, combine os resultados de forma deliberada e faça a migração preenchendo os vetores em paralelo. O design perigoso não é ter «mais do que um modelo». É perder o controlo sobre qual modelo produziu cada vetor e fingir que todas as pontuações de similaridade significam o mesmo.

Centro de Tecnologia e IA

Mais para Ler

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.