Anunciando o Milvus 3.0: Busca Vetorial Nativa de Lake e um Mecanismo de Recuperação Mais Poderoso

Hoje, estamos lançando o Milvus 3.0, um grande marco arquitetural para o projeto. Ele muda tanto onde o Milvus pode criar e servir índices quanto a quantidade de trabalho de recuperação que pode ser feita diretamente dentro do mecanismo.

• O Milvus 3.0 introduz um caminho nativo de lake para indexar dados vetoriais que residem em armazenamento de objetos e formatos de tabela abertos, incluindo Parquet, Lance, Iceberg e Vortex. As equipes podem tornar dados residentes no lake pesquisáveis sem manter outra cópia em um banco de dados vetorial.
• Esta versão também expande o Milvus para além da recuperação inicial de candidatos. Ordenação no lado do servidor, agregação, busca facetada, StructArray para estrutura aninhada de documento/chunk e vetores ColBERT, além de um índice esparso redesenhado, movem mais tarefas de ranqueamento, agrupamento e processamento de resultados para fora do código da aplicação e para dentro do mecanismo de recuperação.

Juntos, esses avanços tornam o Milvus a base open source para recuperação de IA em produção e para arquiteturas Vector Lakebase que combinam armazenamento nativo de lake com recuperação vetorial de alto desempenho.

Uma visão rápida do conjunto de recursos do Milvus 3.0

Área	Recursos	Por que isso importa
Recuperação nativa de lake	External Collections sobre Parquet, Lance, Iceberg e Vortex	Pesquise dados residentes no lake sem manter uma segunda cópia para servir consultas
Armazenamento baseado em S3	Loon (Storage v3)	Reduza a amplificação de leituras pontuais para acesso no estilo de serving e ofereça suporte à evolução de esquema
Fluxos de trabalho offline/em lote e recuperação	Snapshots, Spark DataSource V2 e evolução de esquema online	Leve visões estáveis de coleções para avaliação, desduplicação, clustering e pipelines de features
Mecanismo de recuperação	ORDER BY, agregação, facets, StructArray e recuperação esparsa aprimorada	Mova mais processamento de resultados e pontuação multivetorial para o Milvus
Modelo de dados e operações	Vetores anuláveis, TEXT LOB, TTL, MinHash, Woodpecker e ForceMerge	Ofereça suporte a modelos de dados mais ricos e padrões operacionais de produção

A infraestrutura nativa de lake: indexe e sirva dados onde eles já residem

A maior mudança arquitetural no Milvus 3.0 é onde o sistema pode criar e servir índices. Dados vetoriais podem permanecer em formatos abertos no armazenamento de objetos enquanto o Milvus fornece indexação, recuperação e APIs em nível de produção.

1. External Collections: indexação diretamente em dados residentes no lake

Muitas equipes já armazenam embeddings em um data lake — tabelas Lance, tabelas Iceberg, arquivos Parquet ou outros conjuntos de dados em formato aberto no S3, GCS ou Azure Blob Storage. Antes do Milvus 3.0, geralmente havia duas opções para pesquisar esses dados.

• Copiar os embeddings para um banco de dados vetorial. Isso oferece busca de baixa latência, mas cria uma segunda cópia e um pipeline de ETL que deve permanecer sincronizado.
• Consultar o lake diretamente. Isso evita duplicação, mas, sem índices ANN, a busca vetorial se torna uma varredura por força bruta que não consegue atender à latência de produção.

External Collections introduzem um terceiro caminho. Você define uma coleção Milvus sobre dados que permanecem no armazenamento de objetos, mapeia campos externos para um esquema Milvus e usa as mesmas APIs de busca e consulta de uma coleção nativa. Os arquivos de origem não se movem; o Milvus cria e serve índices vetoriais, invertidos BM25, JSON e escalares sobre os dados externos.

External Collections são somente leitura e zero-copy, o que as torna úteis quando governança, limites de propriedade ou custo operacional exigem que o conjunto de dados de origem permaneça no lake.

Quando o conjunto de dados externo muda, o Milvus lê seu manifesto de armazenamento e indexa os fragmentos recém-adicionados em vez de reconstruir toda a coleção.

import json
import os
import time
from pymilvus import DataType, MilvusClient
client = MilvusClient(uri=“”)
# Register an Iceberg table as a zero-copy collection.
schema = client.create_schema(
external_source=“s3://lake/docs/metadata/v1.metadata.json”,
external_spec=json.dumps(
{
“format”: “iceberg-table”,
“snapshot_id”: 123456789,
“extfs”: {
“cloud_provider”: “aws”,
“region”: “us-east-1”,
“access_key_id”: os.environ[“AWS_ACCESS_KEY_ID”],
“access_key_value”: os.environ[“AWS_SECRET_ACCESS_KEY”],
},
}
),
)
schema.add_field(field_name=“id”, datatype=DataType.INT64, external_field=“doc_id”)
schema.add_field(field_name=“emb”, datatype=DataType.FLOAT_VECTOR, dim=1024, external_field=“embedding”)
schema.add_field(field_name=“title”, datatype=DataType.VARCHAR, max_length=1024, external_field=“title”)
client.create_collection(collection_name=“docs”, schema=schema)
# Import the external table snapshot.
job_id = client.refresh_external_collection(collection_name=“docs”)
while True:
progress = client.get_refresh_external_collection_progress(job_id=job_id)
if progress.state == “RefreshCompleted”:
break
if progress.state == “RefreshFailed”:
raise RuntimeError(progress.reason)
time.sleep(1)
index_params = client.prepare_index_params()
index_params.add_index(field_name=“emb”, index_type=“HNSW”, metric_type=“COSINE”)
client.create_index(collection_name=“docs”, index_params=index_params)
client.load_collection(collection_name=“docs”)

Em ambientes governados, a recuperação pode ser executada onde os dados têm permissão para residir. Para grandes sistemas de IA, um conjunto de dados residente no lake pode oferecer suporte a várias implantações de recuperação sem um job de migração entre elas.

External Collections são um recurso adicional. Coleções nativas do Milvus continuam sendo o caminho principal para serving com muitas gravações e baixa latência, enquanto External Collections são projetadas para conjuntos de dados cujo sistema de registro permanece fora do Milvus.

Para mais detalhes, consulte Criar uma External Collection.

2. Loon (Storage v3): leituras pontuais eficientes para recuperação nativa de lake

External Collections levantam uma pergunta óbvia: o armazenamento de objetos é projetado para escala e durabilidade, mas consegue dar suporte às leituras pontuais estreitas que seguem uma busca ANN?

O desafio é a amplificação de leitura. A busca vetorial costuma ser executada em duas etapas: um índice ANN retorna IDs candidatos, e o sistema busca campos selecionados para esses candidatos. Formatos otimizados para varreduras analíticas podem transformar uma consulta lógica estreita em uma leitura física muito maior.

O Milvus 3.0 resolve esse problema com o Loon, também conhecido como Storage v3, um mecanismo de armazenamento colunar baseado em manifestos para armazenamento de objetos compatível com S3. O Loon organiza campos em ColumnGroups com IDs de linha alinhados, permitindo que campos escalares favoreçam filtragem e varreduras, enquanto vetores e campos intensivos em leituras pontuais usam layouts projetados para consultas mais estreitas.

O Loon mantém índices vetoriais e invertidos separados do formato de arquivo em vez de incorporá-los nele. Cada versão do conjunto de dados é descrita por um manifesto imutável que registra seus ColumnGroups, permitindo que o mesmo mecanismo de indexação funcione em Lance, Parquet, Iceberg e Vortex.

O design baseado em manifesto também torna a evolução de esquema menos disruptiva. Adicionar ou remover um campo pode atualizar metadados sem reescrever colunas existentes. Preencher um novo campo grava um novo ColumnGroup enquanto mantém os ColumnGroups existentes inalterados.

Vortex é o formato padrão para esse caminho. É um formato colunar aberto, compatível com Arrow, com layouts flexíveis e codificações aninhadas que correspondem melhor a dados de IA intensivos em consultas pontuais. Em um benchmark interno usando 3 milhões de linhas, vetores de 128 dimensões, S3 e 256 leitores concorrentes, a E/S medida por leitura pontual caiu de cerca de 9,4 MB para a linha de base Parquet para 0,07 MB para Vortex com Loon, aproximadamente 135 vezes menos.

O Milvus 3.0 não faz o armazenamento de objetos se comportar como memória local. Ele reduz a amplificação de leitura que, de outra forma, torna o armazenamento de objetos impraticável para consultas pontuais no estilo de serving. Predicate pushdown para dentro do formato e uma variante local do Vortex são os próximos itens no roadmap.

Para mais detalhes, consulte nosso blog: Por que criamos o Loon e o projeto Vortex.

3. Snapshots: visão em um ponto no tempo sem cópia de dados

Jobs offline precisam de uma visão consistente dos dados mesmo enquanto coleções de produção continuam recebendo gravações. Um snapshot do Milvus é uma visão somente leitura em um ponto no tempo que registra referências a arquivos de dados, índices e metadados existentes em vez de copiar todo o conjunto de dados.

Isso torna os snapshots baratos o suficiente para serem criados antes de operações arriscadas, como troca de modelo, job de re-embedding ou migração de esquema. Restaurar um snapshot pode reutilizar arquivos de dados e índices existentes por meio de cópia no lado do servidor no armazenamento de objetos, em vez de reimportar cada linha e reconstruir cada índice. Esse recurso é particularmente útil para cargas de trabalho de rápida evolução, como agentes de IA, nas quais os dados mudam constantemente e você deseja pontos de recuperação frequentes e baratos em vez de backups pesados ocasionais.

A mesma visão congelada pode dar suporte a avaliação, desduplicação, validação de backfill e testes isolados enquanto a coleção ativa continua aceitando gravações. O snapshot estabiliza a entrada lógica, embora as cargas de trabalho ainda possam compartilhar infraestrutura, como armazenamento de objetos e largura de banda de rede.

Snapshots não substituem backups. Um snapshot referencia arquivos pertencentes à coleção ativa e é mais adequado para recuperação lógica, clonagem e visões estáveis de curta duração. Um backup cria uma cópia independente para retenção de longo prazo e recuperação de desastres.

Para mais informações, consulte Snapshots, Gerenciar snapshots e Casos de uso de snapshots.

4. Conector Spark: conecte o Milvus a fluxos de trabalho em lote

Um snapshot estável só é útil se mecanismos de processamento em lote puderem lê-lo. O Milvus 3.0 expõe o Milvus como uma Spark DataSource V2, permitindo que jobs Spark, Databricks e EMR leiam e gravem no Milvus como parte de pipelines em lote padrão.

Esse recurso é importante porque fluxos de trabalho de dados de IA são iterativos: a desduplicação alimenta o re-embedding, o clustering alimenta a avaliação, e a avaliação produz conjuntos curados para treinamento ou serving. Um snapshot estável fornece a esses jobs uma entrada consistente, enquanto a coleção ativa continua servindo. Com o conector Spark, o destino de um job se torna a origem do próximo, sem exportar uma coleção completa para fora do Milvus a cada vez.

O Milvus 3.0 também introduz operadores em lote nativos de vetores para tarefas como desduplicação, detecção de anomalias e clustering, mantendo o trabalho computacionalmente pesado fora do caminho de consulta online enquanto opera diretamente sobre dados vetoriais.

5. Alterações de esquema online e backfill

Um esquema raramente permanece estático em produção — as equipes adicionam novos modelos de embedding, vetores esparsos, rótulos, campos de metadados e políticas de retenção ao longo do tempo. O Milvus 3.0 permite adicionar, preencher e remover colunas enquanto o serving continua, em vez das reconstruções disruptivas que isso costumava exigir.

Adicionar ou remover uma coluna não exige reescrever os dados existentes. client.add_collection_field(...) cria uma nova coluna anulável sem tirar a coleção do ar, e client.drop_collection_field(...) remove um campo obsoleto ou experimental em tempo de execução. Nenhuma dessas operações reescreve os dados existentes — cada uma é uma alteração no manifesto da coleção, e não nos arquivos de dados, motivo pelo qual não há reconstrução.

O Milvus 3.0 oferece suporte a dois caminhos de backfill:

• Backfill interno (na 3.0) é para valores derivados de campos existentes. O Milvus pode gerar um vetor esparso BM25 a partir de uma coluna de texto dentro do kernel, eliminando a necessidade de um encoder no lado do cliente ao criar recuperação híbrida densa-mais-esparsa.
• Backfill externo(no roadmap) será para valores computados fora do Milvus: criar um snapshot, executar Spark sobre a visão consistente, computar uma nova coluna, gravar os valores de volta e deixar o Milvus atualizar o índice incrementalmente. Esse é o caminho previsto para grandes jobs de re-embedding — por exemplo, adicionar uma nova coluna de embedding em centenas de milhões de linhas enquanto as gravações continuam.

Juntas, alterações de esquema online e backfill facilitam a evolução de pipelines de recuperação sem reconstruir uma coleção inteira toda vez que o modelo de dados muda.

Um mecanismo mais poderoso para recuperação de ponta a ponta

O Milvus há muito oferece suporte a mais do que busca ANN densa, incluindo recuperação esparsa baseada em BM25 e busca híbrida. O Milvus 3.0 estende o mecanismo ao longo de um eixo diferente: ele traz mais do pipeline de recuperação em múltiplas etapas para dentro do próprio Milvus, reduzindo over-fetching, lógica de aplicação duplicada e dependência de serviços separados de pós-processamento.

1. ORDER BY no lado do servidor: ordenação dentro do mecanismo, por segmento

Anteriormente, ordenar exigia que as aplicações buscassem candidatos em excesso, os movessem para o cliente e os ordenassem ali. Isso consumia largura de banda e fazia o resultado final depender de onde ocorria o truncamento no lado do cliente.

O Milvus 3.0 adiciona ORDER BY no lado do servidor, permitindo que cargas de trabalho de consulta ordenem linhas filtradas por campos escalares como avaliação, preço, atualização, estoque ou timestamp.

• No caminho de consulta, cada segmento ordena seu conjunto de resultados filtrado, os nós de consulta mesclam esses fluxos, e o proxy retorna o recorte solicitado.
• No caminho de busca, ORDER BY ordena o conjunto de candidatos ANN dentro do Milvus, reduzindo over-fetching e pós-processamento duplicado no lado do cliente. Ele não altera o limite de recall estabelecido pelos candidatos ANN.

client.query(
    collection_name="products",
    filter="category == 'shoes'",
    output_fields=["price", "rating"],
    limit=10,
    order_by=["rating:desc", "price:asc"],
)

Isso é especialmente útil para buscas que combinam relevância com restrições comerciais ou voltadas ao usuário, como avaliação, preço, atualização, estoque ou timestamp.

Para mais informações, consulte Ordenar resultados de busca por campos escalares e Ordenar resultados de consulta.

2. Agregação e busca facetada

O Milvus 3.0 adiciona agregação no lado da consulta com operações como contagem, soma, média, mínimo e máximo, agrupadas por um ou mais campos escalares. Isso remove um padrão comum em que equipes puxam linhas filtradas para o código do cliente apenas para contar, agrupar ou calcular estatísticas simples.

client.query(
    collection_name="orders",
    filter="in_stock == true",
    group_by_fields=["category"],
    output_fields=["category", "count(*)", "avg(price)", "max(rating)"],
)

O Milvus 3.0 também adiciona agregação de busca para busca facetada. Após uma busca ANN, o Milvus agrupa os hits recuperados por um campo e retorna contagens de buckets, estatísticas agregadas e hits de amostra top-N por bucket — o padrão por trás do agrupamento por marca, faixa de preço, cor, tenant ou tipo de documento. Uma ressalva: a agregação de busca opera sobre o conjunto de resultados recuperado por ANN, não sobre a coleção inteira, portanto as contagens de facets são aproximadas. Quando precisar de contagens exatas, use agregação no lado da consulta.

Para mais informações, consulte Agregar resultados de consulta.

3. StructArray para vetores aninhados e modelo de late interaction

Muitas entidades são naturalmente representadas por múltiplos vetores. Um documento longo é uma série de chunks; um vídeo é uma sequência de frames que você preferiria manter juntos em uma única linha em vez de espalhar por muitas; um produto tem várias imagens ou ângulos. Modelos de late interaction levam isso ainda mais longe — ColBERT emite um vetor por token, ColPali um por patch visual. Em todos os casos, a unidade que você realmente quer armazenar e pesquisar é a entidade inteira, não cada fragmento isoladamente.

StructArray permite que uma linha do Milvus contenha um array de comprimento variável de elementos estruturados, incluindo múltiplos vetores, preservando um único ID de entidade e um único conjunto de metadados. Isso evita dividir um documento em várias linhas e duplicar rótulos, permissões ou outros campos entre fragmentos.

O Milvus oferece suporte a duas granularidades de busca.

• Busca em nível de elemento compara um vetor de consulta a cada elemento da lista e retorna o elemento correspondente específico com seu deslocamento. Isso é útil quando você quer saber qual chunk, token, patch ou imagem correspondeu. Uma linha pode aparecer mais de uma vez se múltiplos elementos corresponderem.
• Busca em nível de entidade compara a lista completa de vetores de uma consulta com a lista de vetores da linha usando MAX_SIM, com a métrica MAX_SIM_COSINE. Cada token da consulta pega sua melhor correspondência no documento, e essas melhores pontuações são somadas. Isso dá ao Milvus suporte nativo a padrões de recuperação de late interaction, como ColBERT e ColPali, mantendo uma linha por documento.

Indexar cada vetor de token pode ser caro; por isso, o Milvus 3.0 adiciona vários caminhos de aceleração, incluindo TokenANN, Muvera e Lemur, que equilibram tamanho de índice, custo de treinamento e recall.

Estratégia	Representação da primeira etapa	Perfil de custo	Melhor para
TokenANN	Cada vetor de token é indexado.	Mais alto, exato	Modelos de alta discriminação e documentos curtos
Muvera	Um vetor por documento usando FDE de projeção aleatória.	Médio, sem treinamento	Documentos longos
Lemur	Um vetor por documento usando compressão MLP aprendida	Mais baixo, requer treinamento	Modelos de baixa discriminação e vetores visuais ou de patches

Em nossos benchmarks, o Lemur iguala ou supera o recall do TokenANN na maioria dos conjuntos de dados, ao mesmo tempo que reduz cada documento a um único vetor; a exceção são corpora com alta variação de comprimento, nos quais TokenANN ou outra estratégia é mais segura.

Para corpora maiores que a memória, o Milvus também oferece suporte a um índice DISKANN que mantém listas de embeddings em disco para reduzir a pressão sobre a RAM.

A busca em nível de elemento já chegou no Milvus 2.6. A filtragem para Muvera, Lemur e StructList é nova na 3.0.

4. Compressão de índice BM25 e SINDI

O Milvus já oferecia suporte à busca vetorial esparsa em versões anteriores. O Milvus 3.0 reduz o footprint do índice esparso por meio de postings compactados em blocos (algoritmos relacionados a VByte mais decodificação SIMD) e quantização (fp16 para produtos internos, u16 para BM25).

Em um conjunto de benchmarks internos de BM25, a nova implementação foi aproximadamente 3 vezes menor que o índice esparso do Milvus 2.6 com recall comparável. Um índice menor reduz a pressão sobre memória e largura de banda e pode melhorar a velocidade em cargas de trabalho limitadas por movimentação de dados.

O Milvus 3.0 também introduz SINDI, um novo algoritmo de recuperação esparsa otimizado para embeddings esparsos aprendidos, como SPLADE. Como esses embeddings produzem listas de postings mais densas que BM25, algoritmos de busca intensivos em pruning podem gastar tempo substancial de CPU decidindo o que pular. Em vez disso, o SINDI organiza postings em janelas compactas e usa acumulação de pontuação amigável a SIMD para processá-los de forma eficiente, preservando a precisão da recuperação por meio de pruning sem perdas.

Também estendemos o SINDI além de seu design original para incluir suporte nativo a BM25, permitindo que o Milvus use o mesmo caminho otimizado de recuperação esparsa tanto para embeddings esparsos aprendidos quanto para busca full-text tradicional.

Em nossos benchmarks com 4 conjuntos de dados de vetores esparsos SPLADE, o SINDI atinge até cerca de 10x o QPS do MaxScore em vetores esparsos aprendidos, com um pior caso em torno de 5x.

SINDI é o padrão para busca esparsa por produto interno no Milvus 3.0.

Outras melhorias

• TEXT LOB: Armazena texto-fonte longo junto aos vetores. Textos abaixo de 64 KB permanecem inline; valores maiores usam uma referência Vortex LOB.
• Suporte expandido a índices densos: Adiciona mais opções de índice dentro da família Faiss, incluindo SVS, Panorama, PQ, IVFPQ e ScaNN, para diferentes requisitos de escala, memória e recall.
• MinHash e busca de quase duplicatas: Gera assinaturas MinHash no lado do servidor e recupera candidatos quase duplicados usando MINHASH_LSH.
• Vetores anuláveis e novos tipos: Permite que campos vetoriais sejam NULL e adiciona TIMESTAMPTZ para filtragem sensível ao tempo e políticas de retenção.
• Dicionários full-text personalizados: Registra dicionários, sinônimos e recursos de stop words no cluster para tokenização multilíngue e específica de domínio.
• Woodpecker independente: Executa o log write-ahead do Milvus como um serviço independentemente escalável e observável.
• TTL de entidade ****: Expira registros individuais por meio de um campo TIMESTAMPTZ, com filtragem MVCC seguida de coleta de lixo durante a compactação.
• ForceMerge: Compacta pequenos segmentos até um tamanho alvo e reconstrói índices para reduzir a amplificação de leitura antes de um serviço sustentado com muitas leituras.
• E mais

Comece a usar o Milvus 3.0

O Milvus 3.0 está disponível hoje sob a licença Apache 2.0 e continua sendo um projeto LF AI & Data. Para começar:

• Leia as notas da versão e o guia de início rápido, e obtenha o código-fonte em github.com/milvus-io/milvus.
• Entre na comunidade Milvus no Discord ou agende uma sessão de Milvus Office Hours para conversar sobre seu caso de uso com os mantenedores.

Milvus 3.0 e Zilliz Vector Lakebase

O Milvus 3.0 estabelece a base open source para recuperação de IA em produção e para a arquitetura emergente Vector Lakebase, que combina armazenamento nativo de lake com recuperação vetorial de alto desempenho sobre uma única fonte da verdade, cada uma com o custo adequado.

Zilliz Cloud é um Vector Lakebase totalmente gerenciado criado pela equipe por trás do Milvus. Ele compartilha a mesma arquitetura distribuída e nativa de lake do Milvus e é totalmente compatível com a API do Milvus. Impulsionado por seu mecanismo de indexação proprietário Cardinal, o Zilliz Cloud entrega até 10× melhor custo-benefício do que abordagens padrão de indexação open source, ao mesmo tempo que elimina a complexidade operacional de gerenciar infraestrutura. Recursos empresariais incluem computação scale-to-zero, recuperação de desastres entre regiões, implantação BYOC, segurança e conformidade de nível empresarial (SOC 2, HIPAA, ISO 27001 e GDPR) e SLA de até 99,99%.

Desenvolvedores podem implantar o Milvus como um banco de dados vetorial open source ou usar o Zilliz Cloud para uma plataforma gerenciada em várias cargas de trabalho ao longo do ciclo de vida dos dados de IA.

O que vem a seguir

O roadmap do Milvus se baseia na arquitetura 3.0 com predicate pushdown para External Collections, backfill externo, operadores Spark adicionais e suporte a mais formatos de tabela, incluindo Delta Lake e Apache Paimon.

A direção mais ampla é clara: sistemas de dados de IA precisam de um ciclo mais estreito entre recuperação online e melhoria de dados offline. Dados vetoriais não deveriam precisar ser copiados para sistemas separados toda vez que as equipes quiserem pesquisá-los, analisá-los, melhorá-los ou servi-los.