Milvus: a base vetorial dos grandes volumes

#O que Milvus visa

A maioria dos bancos de dados vetoriais é voltada para projetos de equipe. Milvus é voltado para a escala industrial: separação entre armazenamento e processamento, escalabilidade horizontal nativa no Kubernetes e um catálogo de índices que permite equilibrar com precisão os compromissos entre precisão, memória e velocidade. O projeto afirma ter capacidade para processar dezenas de milhares de consultas em bilhões de vetores, mantendo os dados atualizados por meio de atualizações em streaming em tempo real. É uma escolha de arquitetura, não apenas um conjunto de funções.

Essa ambição tem uma desvantagem direta: em um corpus de cinquenta mil passagens, essa potência não se percebe, mas a complexidade aparece imediatamente. Portanto, a pergunta a fazer não é “esta é a melhor base vetorial?”, mas “meu corpus atingirá o tamanho em que essas escolhas fazem diferença?”.

O projeto se apresenta como a base em que desenvolvedores de IA confiam para construir aplicações de busca de texto e imagem, geração aumentada por recuperação e sistemas de recomendação, e afirma atender muitas empresas em usos considerados críticos. Esse posicionamento esclarece o público-alvo: equipes que constroem um produto destinado a crescer, e não um script pessoal de pesquisa documental em algumas centenas de arquivos PDF.

#Uma arquitetura baseada em componentes

Em uma implantação completa, o Milvus não é um processo, mas um conjunto: nós de consulta, nós de dados, um serviço de coordenação, armazenamento de objetos e um registro de mensagens. Cada componente é dimensionado independentemente — o projeto destaca a possibilidade de aumentar separadamente os nós de consulta para uma carga intensa de leitura e os nós de dados para uma carga intensa de escrita —, o que é exatamente o que se deseja em grande escala e exatamente o que se dispensa em uma estação de trabalho. Os microsserviços sem estado no Kubernetes também permitem uma recuperação rápida após incidentes, e o suporte a réplicas melhora ainda mais a tolerância a falhas ao carregar os segmentos de dados em vários nós de consulta. Essa separação entre processamento e armazenamento é precisamente o que distingue um banco de dados pensado para a escala industrial de um banco de dados pensado para um único serviço: ela tem um custo operacional permanente, mesmo quando o tráfego permanece baixo, algo que poucos comparativos mencionam antes da implantação.

#Mínimo em Python, com Milvus Lite

1. 01
   Conectar-se

   from pymilvus import MilvusClient seguido de client = MilvusClient("milvus_demo.db") abre um banco de dados local em um arquivo; substituir o argumento por uma URI de servidor passa a usar uma implantação completa sem alterar o restante do código.
2. 02
   Criar uma coleção

   client.create_collection(collection_name="demo_collection", dimension=1024) — a dimensão deve corresponder exatamente à do seu modelo de embedding.
3. 03
   Inserir os dados

   res = client.insert(collection_name="demo_collection", data=data) onde data é uma lista de dicionários, cada um contendo um vetor e seus metadados.
4. 04
   Buscar

   res = client.search(collection_name="demo_collection", data=vecteurs_requete, limit=5, output_fields=["text"]) retorna os cinco trechos mais próximos com os campos solicitados.

O projeto destaca sua integração com ferramentas de IA comuns — LangChain, LlamaIndex, OpenAI, Hugging Face — o que, segundo seus autores, torna o Milvus um repositório vetorial adequado para geração aumentada por recuperação. O Milvus funciona com modelos de embedding, tanto open source quanto fornecidos por serviços de embedding, em texto, imagem e vídeo, e oferece um utilitário (pymilvus[model]) para transformar dados não estruturados em vetores sem precisar escrever o código de chamada ao modelo nem gerenciar separadamente a biblioteca cliente de cada fornecedor.

#Os índices, e qual escolher?

Para um corpus documental local, lembrar de um único número basta na maioria das vezes: abaixo de um milhão de vetores, a diferença entre as seis famílias de índices é medida em milissegundos, não em minutos, e o esforço dedicado a escolher a configuração certa quase sempre seria mais bem investido em outra parte do projeto.

O conselho que mais economiza tempo continua sendo o mesmo em qualquer lugar: começar pela busca exata. Os índices aproximados resolvem um problema de escala, e adotá-los antes de ter esse problema significa assumir parâmetros para ajustar e um recall para medir, em troca de milissegundos que ninguém percebeu. O Milvus documenta explicitamente essas seis famílias — HNSW, IVF, FLAT, SCANN, DiskANN e variantes quantizadas — como otimizadas, cada uma, para um cenário diferente, com suporte a GPU via CAGRA da NVIDIA para a indexação de volumes muito grandes. O projeto acrescenta a esses índices filtragem por metadados e busca por intervalo, ambas otimizadas no mesmo nível que a própria busca vetorial, em vez de implementadas como uma camada separada que tornaria o resultado final mais lento.

#O que diferencia o Milvus em grande escala

Além dos índices, várias funcionalidades explicam por que grandes organizações escolhem Milvus em vez de uma alternativa mais simples. A configuração multi-tenant oferece quatro níveis possíveis de isolamento — banco de dados, coleção, partição ou chave de partição —, permitindo que um único cluster atenda de algumas dezenas a milhões de locatários sem perder desempenho nas buscas nem granularidade no controle de acesso. O armazenamento quente e frio mantém os dados frequentemente consultados na memória ou em SSD e transfere os dados raramente consultados para um armazenamento mais lento e menos caro, reduzindo o custo sem sacrificar o desempenho das tarefas críticas.

Quanto à busca, o Milvus oferece suporte nativo à busca de texto completo com BM25 e a embeddings esparsos aprendidos, como SPLADE e BGE-M3, além da busca semântica por vetores densos. Vetores esparsos e densos podem coexistir em uma mesma coleção, com funções de reordenação (reranking) para combinar os resultados de várias consultas — uma busca híbrida semelhante em sua concepção à oferecida pelo Qdrant, mas construída aqui em torno do BM25, em vez de uma fusão genérica de pontuações. Quanto à segurança, o projeto destaca a autenticação obrigatória, a criptografia TLS nas comunicações e o controle de acesso baseado em funções (RBAC), três elementos esperados quando um banco de dados atende a várias aplicações ou equipes, e muito menos críticos para uma instância que escuta apenas em localhost.

#Localmente: o que isso implica

Recursos

A implantação completa exige vários contêineres e vários gigabytes de memória RAM, antes mesmo de incluir seu modelo de linguagem: o serviço de coordenação, os nós de consulta, os nós de dados, o armazenamento de objetos e o log de mensagens funcionam separadamente.

Memória de vetores

Aproximadamente 4 kB por vetor de 1.024 dimensões em precisão plena, sem incluir o índice. É essa aritmética que define a arquitetura, não as funcionalidades — e ela permanece verdadeira, independentemente de você usar Milvus, Qdrant ou pgvector.

Operação

Backups, atualizações de versão, monitoramento: um verdadeiro banco de dados distribuído exige alguém realmente responsável por sua operação. O ecossistema Milvus inclui o Attu, uma interface gráfica de administração, e o Birdwatcher para depuração do sistema, duas ferramentas que, mesmo assim, exigem conhecimento da arquitetura subjacente.

A GPU continua dedicada ao modelo

A codificação dos documentos e a inferência já disputam a placa; a busca vetorial, por sua vez, depende principalmente do processador e da memória, exceto quando a construção de índices na GPU é explicitamente ativada via CAGRA para volumes muito grandes.

#Quando Milvus é a escolha certa

A pergunta certa nunca é 'qual base tem mais funcionalidades', mas 'quais dessas funcionalidades meu projeto realmente vai utilizar'. O multi-tenant em quatro níveis, o armazenamento quente e frio, o RBAC e a pesquisa híbrida BM25 existem para organizações que atendem milhares de usuários com exigências de conformidade; em um computador pessoal ou para ferramentas internas de uma pequena equipe, esses mecanismos permanecem inativos, enquanto sua complexidade de configuração continua presente. O Milvus se justifica quando a trajetória do projeto — e não seu estado atual — aponta para essas necessidades em um horizonte razoável.

• Qdrant: o serviço dedicado mais simples de operar
• pgvector: permanecer no PostgreSQL
• FAISS: a biblioteca, não o serviço
• Cadeia RAG completa em Python
• O kit RAG local QuelLLM
• Fonte: repositório oficial Milvus no GitHub
• Fonte: documentação oficial do Milvus Lite
• Fonte: visão geral da arquitetura distribuída do Milvus

#FAQ