Notas de lançamento
Descubra o que há de novo no Milvus! Esta página resume as novas funcionalidades, melhorias, problemas conhecidos e correcções de erros em cada versão. Sugerimos que visite regularmente esta página para saber mais sobre as actualizações.
v3.0-beta
Data de lançamento: 9 de maio de 2026
| Versão do Milvus | Versão do SDK do Python | Versão do SDK do Node.js |
|---|---|---|
| 3.0-beta | 3.0.0 | 3.0.0 |
O Milvus 3.0-beta amplia a base de dados vetorial Milvus com uma nova integração no ecossistema open lake: External Collection permite que o Milvus consulte tabelas de lagos externos sem cópia, e o Spark pode ler coleções do Milvus diretamente através do Snapshot. A versão também traz uma recuperação mais rica, um esquema mais expressivo, uma personalização mais profunda da pesquisa de texto, dados mais finos e controlos do ciclo de vida do modelo, e mais controlos do lado do operador. O Milvus 3.0 é o núcleo central do Zilliz Lakebase, alimentando seu serviço unificado, descoberta e lote.
Principais recursos
Coleta externa
Nos pipelines de dados de IA típicos, terabytes de embeddings e metadados já se encontram no armazenamento de objectos como tabelas Parquet, Lance ou Iceberg. Copiar esses dados para o Milvus duplica o custo de armazenamento, adiciona um pipeline ETL que tem de ser mantido em sincronia e afasta a governação dos dados do cliente.
A coleção externa elimina a cópia. Uma coleção Milvus pode fazer referência a ficheiros onde estes já se encontram, e o Milvus gere apenas o esquema, os índices e a execução de consultas. Uma atualização incremental mantém a coleção alinhada com os ficheiros subjacentes. Os clientes cujos dados não podem sair do lago, como as equipas de finanças e de cuidados de saúde, podem executar a recuperação de vectores em relação a esses dados onde eles se encontram. Um único conjunto de dados residente no lago também pode ser servido a partir de várias instâncias do Milvus ao mesmo tempo.
Para obter mais informações, consulte Criar uma coleção externa.
Instantâneo
O serviço e a descoberta em lote geralmente precisam da mesma coleção ao mesmo tempo. A avaliação do modelo A/B, a desduplicação em grande escala, a validação de backfill e a reversão de versão precisam de uma exibição estável da coleção enquanto as gravações ainda estão sendo feitas.
O Snapshot cria uma visualização pontual e somente leitura de uma coleção, referenciando segmentos existentes em vez de copiar dados, de modo que o custo marginal de armazenamento é próximo de zero. Os trabalhos em lote podem ler a partir do instantâneo sob isolamento no estilo MVCC enquanto a coleção ativa continua aceitando gravações.
Para obter mais informações, consulte Instantâneos, Gerenciar instantâneos e Casos de uso de instantâneos.
Consulta / Pesquisa Ordenar por
A Pesquisa e a Consulta agora aceitam a ordenação de vários campos, com a ordenação empurrada para o kernel do Milvus e ASC / DESC configurável por campo. Isso fecha uma lacuna comum na produção: O Top-K por distância, por si só, muitas vezes não corresponde às necessidades da empresa quando o item mais semelhante não é o mais barato, o mais recente ou o mais popular.
Os aplicativos não precisam mais buscar resultados em excesso e reordenar no cliente para expressar a classificação composta.
Para obter mais informações, consulte Ordenar resultados de pesquisa por campos escalares e Ordenar resultados de consulta.
Agregação de consultas
Produzir estatísticas de distribuição de locatários, contagens de campos completos ou progresso de lançamento de versão de uma Coleção Milvus costumava requerer puxar entidades correspondentes de volta para o cliente e agregá-las lá. O Milvus 3.0 coloca a agregação escalar no estilo SQL no kernel. Uma chamada de consulta aceita group_by_fields e expressões de agregação em output_fields, incluindo count(*), count(<field>), sum(<field>), avg(<field>), min(<field>), e max(<field>). A agregação é avaliada no lado do servidor após a filtragem.
Para obter mais informações, consulte Agregar resultados de consulta.
Vetor nulo
Os embeddings são muitas vezes produzidos de forma assíncrona, pelo que uma entidade pode chegar antes do seu vetor. Os dados multimodais também têm lacunas naturais, como um vídeo sem legendas ou um produto sem uma imagem. As versões anteriores não tinham uma boa resposta: as aplicações ou atrasavam a escrita até que o vetor estivesse pronto ou preenchiam um vetor de substituição, e ambas as escolhas prejudicavam a qualidade da recuperação.
O Milvus 3.0 suporta NULL em campos vetoriais em todos os seis tipos de vetores. A pesquisa ignora automaticamente os vetores NULL, a qualidade da recuperação não é afetada e os vetores NULL não ocupam efetivamente nenhum espaço de armazenamento. AddField também se estende a campos vetoriais sob esta mudança: com nullable=True, uma coleção existente pode crescer novos campos vetoriais on-line sem uma reconstrução.
Para obter mais informações, consulte Campos anuláveis.
Dicionário personalizado e dicionário de sinônimos
Os tokenizadores prontos para uso nem sempre atendem aos requisitos de qualidade de pesquisa de produção. Domínios verticais chineses, como medicina, direito e química, e corpora multilíngues podem se beneficiar substancialmente de dicionários personalizados e tabelas de sinônimos. Até agora, esses recursos viviam principalmente como reescritas de consultas do lado da aplicação.
O Milvus 3.0 adiciona um mecanismo FileResource para registar dicionários personalizados de tokenizadores, listas de sinónimos, listas de stop-word e regras de decomposição. Uma vez registado, um recurso pode ser referenciado a partir de qualquer tokenizador ou filtro e tem efeito no BM25, analisadores e Text Match. Os dicionários e sinónimos podem agora ser versionados e geridos centralmente em vez de estarem dispersos pelo código da aplicação.
Para obter mais informações, consulte Gerenciar recursos de arquivo.
TTL de entidade
A TTL a nível de coleção e a nível de partição são demasiado grosseiras para muitos cenários de ciclo de vida e de conformidade. Diferentes locatários dentro da mesma coleção geralmente têm regras de retenção diferentes, e entidades individuais podem precisar expirar em um cronograma que não corresponde ao resto da coleção.
Milvus 3.0 suporta TTL por entidade. Declare um campo TIMESTAMPTZ no esquema, marque-o como o campo TTL através de uma propriedade da coleção, e o Milvus recupera as entidades expiradas automaticamente. Isto abrange pedidos de direito a ser esquecido, dados de sessão expirados e histórico de conversação limitado sem limpeza do lado da aplicação.
Para obter mais informações, consulte Definir TTL no nível da entidade.
MinHash DIDO (Doc-in, Doc-out)
O Milvus 2.6 adicionou o índice MINHASH_LSH para deteção de quase-duplicatas baseada em conjuntos, mas os aplicativos ainda tinham que computar assinaturas MinHash antes de escrever dados no Milvus.
Milvus 3.0 adiciona uma função MinHash do lado do servidor. Declare um campo de entrada VARCHAR e um campo de saída BINARY_VECTOR no esquema, anexe uma função FunctionType.MINHASH e o Milvus calcula as assinaturas durante a inserção, inserção em massa e pesquisa. Juntamente com MINHASH_LSH, isto suporta fluxos de trabalho de deduplicação para grandes conjuntos de dados, impressões digitais e deteção de plágio dentro do Milvus.
Para mais informações, consulte a função MinHash.
EmbList + DISKANN
O pressuposto "uma entidade = um vetor" já não se adequa à recuperação moderna. Os documentos longos são divididos em muitos pedaços, os modelos de interação tardia, como o ColBERT, emitem um vetor por token e as entidades multimodais podem ter várias vistas.
EmbList armazena uma lista de vectores de comprimento variável por entidade, com DISKANN como índice em disco. O caminho do disco mantém a utilização da RAM sob controlo quando o corpus excede os orçamentos de memória. EmbList + DISKANN é a primeira variante da família StructList mais alargada neste RC. O resto da família, incluindo a filtragem StructList e a aceleração multi-vetorial Muvera / Lemur, está prevista para a versão oficial 3.0.
Para obter mais informações, consulte Pesquisar com listas de incorporação.
Forçar mesclagem
As cargas de trabalho de produção acumulam fragmentação de segmentos ao longo do tempo, o que causa jitter de latência de consulta e armazenamento inflacionado.
O Milvus 3.0 adiciona a capacidade de acionar explicitamente a compactação de segmentos durante janelas fora de pico, nos modos síncrono e assíncrono.
Para obter mais informações, consulte Forçar compactação de mesclagem.
Armazenamento V3
O Milvus 3.0 apresenta o Storage V3, um mecanismo de armazenamento colunar baseado em manifesto em que os dados e metadados residem no armazenamento de objetos compatível com S3. Cada versão de conjunto de dados é capturada como um instantâneo de manifesto imutável, um arquivo codificado em Avro que registra quais grupos de colunas, logs delta e estatísticas compõem o conjunto de dados.
Os manifestos são ficheiros Avro compactos e os registos delta registam as eliminações ao nível da entidade sem reescrever os ficheiros de dados. Isso mantém a sobrecarga de metadados pequena à medida que os conjuntos de dados crescem. O manifesto também desacopla o rastreamento de metadados do caminho da consulta, permitindo que uma coleção gerencie mais segmentos sem degradar o desempenho da consulta.
Como os estados são armazenados no armazenamento de objetos, o conjunto de dados é autodescritivo: qualquer leitor com acesso ao caminho de armazenamento pode descobri-lo e interpretá-lo sem um catálogo central. Essa propriedade sustenta a Coleção externa, o Instantâneo e as futuras integrações de lago.