Um guia para desenvolvedores para explorar os recursos do Milvus 2.6 na Zilliz Cloud
Milvus começou como um banco de dados vetorial open-source de alto desempenho criado para escala, com capacidades de busca vetorial ANN de última geração. À medida que a comunidade de desenvolvedores cresceu, as solicitações de recursos se expandiram para incluir busca de texto completo, boosting e suporte a tipos de dados semiestruturados (JSON, struct, etc.). Essas solicitações refletem uma tendência mais ampla em direção à convergência das capacidades de bancos de dados, impulsionada pela necessidade de recursos mais avançados (além da busca por similaridade) que ajudam a acelerar o desenvolvimento de aplicações de IA.
A convergência não aparece apenas nas solicitações de recursos — agora ela aparece no próprio banco de dados. Com o Milvus 2.6, muitas capacidades que os desenvolvedores anteriormente precisavam montar fora do banco de dados, como ranqueamento baseado em decaimento, boosting em nível de campo e filtragem híbrida entre dados estruturados e não estruturados, agora são primitivas de primeira classe.
Em outras palavras, o Milvus 2.6 marca uma mudança de "busca vetorial + código de cola" para um mecanismo de recuperação mais avançado, e agora está Geralmente Disponível (GA) no Zilliz Cloud (um serviço Milvus gerenciado).
Neste artigo, vou apresentar alguns dos recursos interessantes do Milvus v2.6, quando usá-los e como usá-los. Vamos começar!
A Função de Embedding (também conhecida como Data In, Data Out)
Já se perguntou se o banco de dados pode lidar com a geração de embeddings em seu nome? Com Embedding Functions (também conhecidas como "Data in, data out"), o Milvus pode transformar texto bruto em vetores chamando serviços externos de embedding de terceiros, como OpenAI, VoyageAI e Cohere.
Embedding Functions foi lançado pela primeira vez no Milvus v2.6.0, e eu o apresentei na demo kafka-milvus-no-code-pipelines. Agora, Embedding Functions estão disponíveis no Zilliz Cloud, o serviço totalmente gerenciado do banco de dados vetorial Milvus.
Como a embedding function funciona?
Digamos que você insira "The quick brown fox jumps over the lazy dog" no Milvus com uma embedding function configurada. O Milvus a intercepta na camada de proxy, a encaminha por um pipeline de embedding específico do provedor e armazena o vetor produzido pelo seu modelo. A mesma transformação acontece em sentido inverso durante a busca. O texto da sua consulta é convertido em um vetor antes de chegar ao índice.
Esse recurso é particularmente útil para equipes que buscam descarregar para o banco de dados a responsabilidade de gerenciar fluxos de trabalho de embedding. Ao permitir que o banco de dados gere embeddings de forma transparente no momento da ingestão (por meio de um provedor de modelo de terceiros), o Zilliz Cloud cuida da integração de API, batching, retentativas, limites de taxa e tratamento de falhas.
Para começar com Embedding Functions no Zilliz Cloud, você precisa:
- Configurar a Model Provider Integration para o provedor de serviço de embedding de sua escolha
- Criar uma coleção com Embedding Function definida
- Inserir seus dados.
Você deve conseguir ver a embedding function no console do Zilliz Cloud na página de schema da sua coleção se a tiver configurado corretamente.
Agora você só precisa inserir o texto bruto, e os embeddings serão gerados automaticamente e armazenados no campo de vetor denso especificado. Com embedding functions definidas, você não precisa mais gerar embeddings, nem mesmo para sua consulta de busca.
Um possível problema que você pode enfrentar será o limite de tamanho de batch que o Milvus impõe ao usar embedding function.
2026-01-21 14:03:12,902 [ERROR][handler]: RPC error: [insert_rows], <MilvusException: (code=65535, message=numRows [1000] > function [openai]'s max batch [640])>, <Time:{'RPC start': '2026-01-21 14:03:12.722589', 'RPC error': '2026-01-21 14:03:12.902013'}>
Melhores práticas e dicas
- Mantenha-se dentro do limite de tamanho de lote (mostrado na mensagem de erro). Este é um mecanismo de segurança para evitar atingir o limite de tokens do provedor do modelo por chamada de API. Por exemplo, a OpenAI tem uma limitação de no máximo 300.000 tokens por chamada de API.
- Para textos longos ou casos de uso com documentos grandes, você deve dividir em chunks antes de inserir. Por exemplo, a OpenAI tem um limite de 8192 tokens por texto de entrada para todos os modelos de embedding.
- Embora provedores como VoyageAI e Cohere trunquem automaticamente textos longos por padrão, depender disso pode resultar na perda silenciosa de conteúdo no final do seu documento.
Destaque Lexical
O destaque lexical é útil para mostrar aos usuários por que um resultado correspondeu à consulta deles, marcando visualmente os termos ou frases exatos que acionaram a correspondência. Isso melhora a transparência, a interpretabilidade e a confiança do usuário nos resultados de pesquisa.
Aqui estão alguns cenários principais:
Exibição de resultados de pesquisa em UIs. Ao criar interfaces de pesquisa, o destaque ajuda os usuários a entender rapidamente a relevância de um resultado sem abrir o documento completo. Ele reduz a carga cognitiva e melhora a taxa de cliques ao tornar a correspondência explícita.
Pesquisa de documentos / conteúdo. Em documentos grandes (por exemplo, bases de conhecimento, PDFs, políticas), o destaque lexical permite que os usuários localizem imediatamente palavras-chave correspondentes dentro do contexto ao redor, acelerando a descoberta de informações.
Análise de logs / eventos. O destaque em logs operacionais ou dados de eventos facilita identificar padrões correspondentes, códigos de erro ou palavras-chave em textos densos e não estruturados, especialmente durante a solução de problemas ou a resposta a incidentes.
Depuração de RAG (Retrieval-Augmented Generation). Em pipelines de RAG, o destaque lexical ajuda os profissionais a inspecionar quais partes dos chunks recuperados corresponderam à consulta original. Isso é útil para:
- Verificar a correção da recuperação
- Diagnosticar falsos positivos ou correspondências fracas
- Entender por que um determinado contexto foi selecionado para geração
Para implementar o destaque lexical no lado do servidor com o Zilliz Cloud, primeiro você instancia um LexicalHighlighter (com o texto da consulta a destacar e tags ao redor para indicar como o texto destacado aparece) e o fornece como parâmetro à sua solicitação de pesquisa de texto completo.
Então, o Milvus executará a pesquisa e rodará a lógica lexical para encontrar correspondências exatas e retornar informações posicionais sobre quais substrings destacar.
Melhores práticas e dicas
- LexicalHighlighter funciona apenas com pesquisa de texto completo BM25. Ele não funcionará para pesquisa vetorial densa.
- Você pode definir
pre_tagsepost_tagspara envolver termos correspondentes com tags HTML (por exemplo, classe CSS personalizada, negrito, itálico etc.) que são renderizadas diretamente em uma página web.
Índice N-gram
Índices N-gram são técnicas poderosas de indexação de mecanismos de busca que dividem strings em sequências menores e sobrepostas de caracteres (por exemplo, "coffee" em 3-grams -> "cof", "off", "ffe", "fee") para permitir correspondência parcial, flexível e no estilo curinga.
Aqui estão alguns cenários em que você achará os índices n-gram úteis:
- Melhorar o desempenho de pesquisas de substring (por exemplo,
LIKE %deep%) - Search-as-you-type / autocompletar
- Pesquisa difusa
- Pesquisa de nomes de domínio e identificadores (por exemplo,
example.com,facebook.com)
Como funciona?
Documentos que contêm um n-grama especificado podem ser localizados com eficiência usando um índice, muitas vezes chamado de índice invertido, que mapeia cada n-grama para uma lista de identificadores dos documentos que contêm esse n-grama. A lista é mantida ordenada para permitir tanto compressão eficiente quanto execução eficiente de consultas. No caso do Milvus, o índice ngram é construído sobre o Tantivy, que por sua vez usa técnicas de compressão como codificação delta, bitpacking e skip lists para comprimir e reduzir o tamanho da lista invertida, tornando o índice leve.
Em vez de uma varredura completa no seu campo de texto, o Milvus primeiro extrai o predicado, por exemplo, deep, decompõe-no em n-gramas com base nos tamanhos de gram configurados, realiza buscas no índice invertido e intersecta os resultados para identificar candidatos que contêm todos os gramas e, então, verifica correspondências exatas em relação ao padrão LIKE original.
O Milvus permite que você especifique o min_gram e o max_gram, que representam, respectivamente, o comprimento mínimo e máximo dos n-gramas que serão gerados. Para mais detalhes sobre como criar e usar o índice ngram, consulte o documento do Índice NGRAM.
Aqui está uma breve demonstração de autocompletar implementado usando o recurso de índice ngram do Milvus.
Melhores práticas e dicas
- Faça benchmark com consultas representativas: Teste com padrões de consulta realistas antes de implantar em produção para validar se as configurações de
min_gramemax_gramestão alinhadas com o comportamento real dos usuários. - Combine estrategicamente com busca vetorial: Use a filtragem acelerada por NGRAM como um pré-filtro para reduzir o conjunto de candidatos antes da computação de similaridade vetorial, melhorando a latência geral da consulta.
- Evite indexação excessiva: Nem todo campo VARCHAR se beneficia de um índice NGRAM. Priorize campos usados com frequência em consultas
LIKEcom padrões curinga. - Observe que o índice n-grama é sensível a maiúsculas e minúsculas. Isso significa que os tokens são indexados exatamente como aparecem no texto original, preservando distinções entre maiúsculas e minúsculas. As consultas devem corresponder exatamente ao uso de maiúsculas e minúsculas do conteúdo indexado.
Decay Ranker
Imagine que você está criando um mecanismo de busca semântica para artigos de pesquisa, no qual você favorece artigos publicados nos últimos 10 anos em relação àqueles publicados há mais de 10 anos.
Sem o decay ranker do Milvus, você provavelmente teria que reclassificar os resultados da busca fora do banco de dados vetorial com base no campo do ano de publicação. Isso exigirá processamento no servidor da aplicação / lado do cliente, o que adicionará complexidade e latência, podendo impactar negativamente a experiência do usuário.
No centro do decay ranker do Milvus está a Decay Function. Decay Functions ajustam pontuações de relevância com base em campos numéricos (como timestamps). A pontuação final é calculada como:
final_score = normalized_similarity_score x decay_score
Atualmente, há três funções de decaimento diferentes, a saber: Linear, Exponential e Gaussian. Cada função de decaimento é útil para cenários diferentes. Por exemplo, a Linear Function deve ser usada quando você precisa excluir entidades além de um determinado ponto (por exemplo, anos, distância etc.). A Exponential Function pode ser usada quando você deseja que itens mais recentes dominem os resultados, mas ainda permitindo que resultados mais antigos sejam descobertos. A Gaussian Function é útil para buscas baseadas em localização, ou seja, itens mais próximos da localização atual serão classificados mais alto.
As funções de decaimento são altamente personalizáveis, e você pode controlar sua forma usando vários parâmetros ao inicializá-las:
- origin: Ponto de referência (por exemplo, timestamp atual)
- offset: Cria uma "zona sem decaimento" onde os itens mantêm pontuações completas (decay = 1.0). Útil para garantir que itens muito recentes ou muito próximos não sejam penalizados de forma alguma.
- scale: Valores maiores produzem uma queda gradual na relevância; valores menores produzem uma queda mais acentuada.
- decay: Controla a inclinação da curva. Valores mais baixos (por exemplo, 0.3) criam uma queda mais acentuada; valores mais altos (por exemplo, 0.7) criam uma queda mais gradual. O padrão é 0.5.
Aqui está um exemplo de como descobrir como definir os parâmetros da função de decaimento:
- Para usar o ano atual como a origem:
origin=2026 - Artigos de pesquisa de 2021 a 2026 são igualmente relevantes, sem decaimento aplicado:
offset=6 - O multiplicador de pontuação na distância de escala:
decay=0.5 - Artigos de 2010 devem ter uma pontuação de decaimento (especificada anteriormente) 0.5:
scale=16(pois 2026 - 2010 = 16)
Práticas recomendadas e dicas
- Faça testes A/B de configurações de decaimento. Pequenas alterações nos parâmetros
scaleedecaypodem impactar significativamente a experiência do usuário. - Certifique-se de que todos os parâmetros baseados em tempo (
origin,scale,offset) usem a mesma unidade dos dados da sua coleção. - FunctionScore aceita apenas uma única DecayFunction por consulta. Encadear ou compor várias DecayFunctions atualmente não é suportado.
- Cada ranker de decaimento suporta apenas um campo numérico. Você não pode combinar vários fatores de decaimento em um único ranker.
- Evite decaimento em campos esparsos ou enviesados. Se seu campo de decaimento tiver muitos valores nulos, outliers ou distribuições altamente enviesadas, o ranqueamento por decaimento pode produzir resultados pouco intuitivos.
Boosting
Boosting é um mecanismo prático para incorporar sinais de domínio ao ranqueamento de busca vetorial. Embora a busca semântica capture sobre o que é sua consulta, ela frequentemente ignora o que importa mais em um determinado domínio. Boosting permite que você reordene os resultados usando um campo de metadados arbitrário, codificando efetivamente a intuição de negócios ou de domínio na camada de recuperação.
Por exemplo, em um fluxo de trabalho de busca de artigos de pesquisa, dois artigos podem ser relevantes para "deep learning", mas não igualmente importantes. Um artigo altamente citado pode merecer aparecer acima de um menos citado, mesmo que sua pontuação de similaridade seja ligeiramente menor. Com boosting, um artigo com uma pontuação de similaridade de 0.79, mas 1.200 citações, pode ser ranqueado acima de um artigo com pontuação 0.81 e apenas 10 citações.
O acima pode ser implementado aplicando boosting aos artigos com base na contagem de citações. Uma implementação simples é a seguinte:
Mas e se quisermos aplicar boosting a artigos de pesquisa com contagens de citações entre 100 e 1000 e ainda incluir uma função de decaimento para favorecer artigos mais recentes. Acontece que podemos encadear uma função de decaimento com vários boost rankers em uma única solicitação de busca usando a classe FunctionScore.
Práticas recomendadas e dicas
- FunctionScore atualmente é suportado apenas para busca vetorial densa. A busca híbrida não suporta FunctionScore; use um único ranker em vez disso.
- Para boosting baseado em campos com valores contínuos, considere colocar os valores em buckets discretos e atribuir pesos de boost distintos a cada bucket.
Conclusão
Milvus 2.6 representa um avanço significativo no que um banco de dados vetorial pode fazer pronto para uso. Os recursos e capacidades acima que discuti não são apenas conveniências, eles eliminam o código de integração que os desenvolvedores anteriormente precisavam construir e manter fora do banco de dados.
Em vez de costurar pipelines externos de embedding, lógica personalizada de reranking e soluções alternativas de busca por substring, agora você pode expressar isso diretamente em suas consultas Milvus. O resultado é um código de aplicação mais limpo, menor latência e menos partes móveis para depurar quando algo dá errado.
Se você tem tratado o Milvus como "apenas" um armazenamento de vetores, talvez seja hora de revisitar o que é possível. Todos esses recursos agora estão GA na Zilliz Cloud, então você pode começar a experimentar hoje.
Recursos
- Doc: Integrate with Model Providers
- Doc: Model-based Embedding Functions
- Blog: Introducing the Embedding Function: How Milvus 2.6 Streamlines Vectorization and Semantic Search
- Doc: Lexical Highlighter in Zilliz Cloud
- Blog: How We Built a Semantic Highlighting Model for RAG Context Pruning and Token Saving
- Doc: NGRAM Index
- Doc: Decay Ranker Overview
- Doc: Boost Ranker
Continue lendo
Zilliz Cloud Audit Logs Goes GA: Security, Compliance, and Transparency at Scale
Zilliz Cloud Audit Logs are now GA, giving enterprises real-time visibility, compliance-ready trails, and stronger security across AWS, GCP, and Azure.
Proactive Monitoring for Vector Database: Zilliz Cloud Integrates with Datadog
we're excited to announce Zilliz Cloud's integration with Datadog, enabling comprehensive monitoring and observability for your vectorDB deployments.
Why Deepseek is Waking up AI Giants Like OpenAI And Why You Should Care
Discover how DeepSeek R1's open-source AI model with superior reasoning capabilities and lower costs is disrupting the AI landscape and challenging tech giants like OpenAI.