Annonce de Milvus 3.0 : recherche vectorielle native du lake et moteur de récupération plus puissant

Aujourd’hui, nous publions Milvus 3.0, une étape architecturale majeure pour le projet. Cette version change à la fois l’endroit où Milvus peut construire et servir des index, et la quantité de travail de récupération pouvant être effectuée directement dans le moteur.

• Milvus 3.0 introduit un chemin natif du lake pour indexer les données vectorielles qui résident dans le stockage objet et les formats de tables ouverts, notamment Parquet, Lance, Iceberg et Vortex. Les équipes peuvent rendre consultables les données résidant dans le lake sans maintenir une autre copie dans une base de données vectorielle.
• Cette version étend également Milvus au-delà de la récupération initiale de candidats. Le tri côté serveur, l’agrégation, la recherche à facettes, StructArray pour les structures doc/chunk imbriquées et les vecteurs ColBERT, ainsi qu’un index sparse repensé déplacent davantage de classement, de regroupement et de traitement des résultats hors du code applicatif et dans le moteur de récupération.

Ensemble, ces avancées font de Milvus la fondation open source pour la récupération IA en production et pour les architectures Vector Lakebase qui combinent stockage natif du lake et récupération vectorielle haute performance.

Un aperçu rapide de l’ensemble des fonctionnalités de Milvus 3.0

Domaine	Fonctionnalités	Pourquoi c’est important
Récupération native du lake	External Collections sur Parquet, Lance, Iceberg et Vortex	Rechercher dans les données résidant dans le lake sans maintenir une deuxième copie de service
Stockage basé sur S3	Loon (Storage v3)	Réduire l’amplification des lectures ponctuelles pour les accès de type service et prendre en charge l’évolution du schéma
Workflows offline/batch et récupération	Snapshots, Spark DataSource V2 et évolution de schéma en ligne	Apporter des vues de collection stables aux pipelines d’évaluation, de déduplication, de clustering et de features
Moteur de récupération	ORDER BY, agrégation, facettes, StructArray et récupération sparse améliorée	Déplacer davantage de traitement des résultats et de scoring multi-vectoriel dans Milvus
Modèle de données & opérations	Vecteurs nullable, TEXT LOB, TTL, MinHash, Woodpecker et ForceMerge	Prendre en charge des modèles de données plus riches et des schémas d’exploitation en production

L’infrastructure native du lake : indexer et servir les données là où elles résident déjà

Le plus grand changement architectural de Milvus 3.0 concerne l’endroit où le système peut construire et servir des index. Les données vectorielles peuvent rester dans des formats ouverts sur du stockage objet tandis que Milvus fournit une indexation, une récupération et des API de niveau production.

1. External Collections : indexer directement les données résidant dans le lake

De nombreuses équipes stockent déjà des embeddings dans un data lake — tables Lance, tables Iceberg, fichiers Parquet ou autres jeux de données en formats ouverts sur S3, GCS ou Azure Blob Storage. Avant Milvus 3.0, il existait généralement deux options pour rechercher dans ces données.

• Copier les embeddings dans une base de données vectorielle. Cela fournit une recherche à faible latence, mais crée une deuxième copie et un pipeline ETL qui doit rester synchronisé.
• Interroger directement le lake. Cela évite la duplication, mais sans index ANN, la recherche vectorielle devient un balayage exhaustif qui ne peut pas respecter les latences de production.

External Collections introduit un troisième chemin. Vous définissez une collection Milvus sur des données qui restent dans le stockage objet, mappez les champs externes vers un schéma Milvus et utilisez les mêmes API de recherche et de requête qu’avec une collection native. Les fichiers source ne sont pas déplacés ; Milvus construit et sert des index vectoriels, inversés BM25, JSON et scalaires sur les données externes.

Les External Collections sont en lecture seule et zero-copy, ce qui les rend utiles lorsque la gouvernance, les frontières de propriété ou le coût opérationnel exigent que le jeu de données source reste dans le lake.

Lorsque le jeu de données externe change, Milvus lit son manifeste de stockage et indexe les fragments nouvellement ajoutés au lieu de reconstruire toute la collection.

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”)

Dans les environnements gouvernés, la récupération peut s’exécuter là où les données sont autorisées à résider. Pour les grands systèmes d’IA, un jeu de données résidant dans le lake peut prendre en charge plusieurs déploiements de récupération sans tâche de migration entre eux.

Les collections externes sont une capacité additive. Les collections Milvus natives restent la voie principale pour les services à forte écriture et faible latence, tandis que les External Collections sont conçues pour les jeux de données dont le système d’enregistrement reste en dehors de Milvus.

Pour plus de détails, consultez Créer une External Collection.

2. Loon (Storage v3) : lectures ponctuelles efficaces pour la récupération native du lake

Les External Collections soulèvent une question évidente : le stockage objet est conçu pour l’échelle et la durabilité, mais peut-il prendre en charge les lectures ponctuelles étroites qui suivent une recherche ANN ?

Le défi est l’amplification de lecture. La recherche vectorielle s’exécute couramment en deux étapes : un index ANN renvoie des ID candidats, puis le système récupère les champs sélectionnés pour ces candidats. Les formats optimisés pour les scans analytiques peuvent transformer une recherche logique étroite en une lecture physique beaucoup plus importante.

Milvus 3.0 résout ce problème avec Loon, également appelé Storage v3, un moteur de stockage colonnaire basé sur des manifestes pour le stockage objet compatible S3. Loon organise les champs en ColumnGroups avec des ID de lignes alignés, ce qui permet aux champs scalaires de privilégier le filtrage et les scans, tandis que les vecteurs et les champs très sollicités en lectures ponctuelles utilisent des dispositions conçues pour des recherches plus étroites.

Loon conserve les index vectoriels et inversés séparés du format de fichier plutôt que de les y intégrer. Chaque version de jeu de données est décrite par un manifeste immuable qui enregistre ses ColumnGroups, ce qui permet au même moteur d’indexation de fonctionner avec Lance, Parquet, Iceberg et Vortex.

La conception par manifeste rend également l’évolution du schéma moins disruptive. Ajouter ou supprimer un champ peut mettre à jour les métadonnées sans réécrire les colonnes existantes. Remplir un nouveau champ écrit un nouveau ColumnGroup tout en laissant les ColumnGroups existants inchangés.

Vortex est le format par défaut pour ce chemin. Il s’agit d’un format colonnaire ouvert, compatible Arrow, avec des dispositions flexibles et des encodages imbriqués qui correspondent mieux aux données IA fortement orientées requêtes ponctuelles. Dans un benchmark interne utilisant 3 millions de lignes, des vecteurs à 128 dimensions, S3 et 256 lecteurs concurrents, les E/S mesurées par lecture ponctuelle sont passées d’environ 9,4 Mo pour la référence Parquet à 0,07 Mo pour Vortex avec Loon, soit environ 135 fois moins.

Milvus 3.0 ne fait pas se comporter le stockage objet comme de la mémoire locale. Il réduit l’amplification de lecture qui rend autrement le stockage objet peu pratique pour les recherches ponctuelles de type service. Le pushdown de prédicats dans le format et une variante locale de Vortex sont les prochaines étapes de la feuille de route.

Pour plus de détails, consultez notre blog : Pourquoi nous avons construit Loon et le projet Vortex.

3. Snapshots : vue à un instant donné sans copie de données

Les tâches offline ont besoin d’une vue cohérente des données même lorsque les collections de production continuent de recevoir des écritures. Un snapshot Milvus est une vue en lecture seule à un instant donné qui enregistre des références aux fichiers de données, d’index et de métadonnées existants au lieu de copier l’ensemble du jeu de données.

Cela rend les snapshots suffisamment peu coûteux pour être créés avant des opérations risquées telles qu’un changement de modèle, une tâche de ré-embedding ou une migration de schéma. Restaurer un snapshot peut réutiliser les fichiers de données et d’index existants via une copie côté serveur dans le stockage objet plutôt que de réimporter chaque ligne et reconstruire chaque index. Cette fonctionnalité est particulièrement utile pour les workloads à évolution rapide comme les agents IA, où les données changent constamment et où l’on souhaite des points de récupération fréquents et peu coûteux plutôt que des sauvegardes lourdes occasionnelles.

La même vue figée peut prendre en charge l’évaluation, la déduplication, la validation de backfill et les tests isolés pendant que la collection active continue d’accepter des écritures. Le snapshot stabilise l’entrée logique, même si les workloads peuvent toujours partager une infrastructure telle que le stockage objet et la bande passante réseau.

Les snapshots ne remplacent pas les sauvegardes. Un snapshot référence des fichiers appartenant à la collection active et convient surtout à la récupération logique, au clonage et aux vues stables de courte durée. Une sauvegarde crée une copie indépendante pour la conservation à long terme et la reprise après sinistre.

Pour plus d’informations, consultez Snapshots, Gérer les snapshots et Cas d’utilisation des snapshots.

4. Connecteur Spark : connecter Milvus aux workflows batch

Un snapshot stable n’est utile que si les moteurs batch peuvent le lire. Milvus 3.0 expose Milvus comme une Spark DataSource V2, permettant aux tâches Spark, Databricks et EMR de lire depuis Milvus et d’y écrire dans le cadre de pipelines batch standard.

Cette fonctionnalité est importante parce que les workflows de données IA sont itératifs : la déduplication alimente le ré-embedding, le clustering alimente l’évaluation, et l’évaluation produit des ensembles sélectionnés pour l’entraînement ou le service. Un snapshot stable fournit à ces tâches une entrée cohérente, tandis que la collection active continue de servir. Avec le connecteur Spark, la sortie d’une tâche devient la source de la suivante, sans exporter une collection complète hors de Milvus à chaque fois.

Milvus 3.0 introduit également des opérateurs batch natifs des vecteurs pour des tâches telles que la déduplication, la détection d’anomalies et le clustering, en gardant les travaux gourmands en calcul hors du chemin de requête en ligne tout en opérant directement sur les données vectorielles.

5. Modifications de schéma en ligne et backfill

Un schéma reste rarement statique en production — les équipes ajoutent au fil du temps de nouveaux modèles d’embedding, des vecteurs sparse, des labels, des champs de métadonnées et des politiques de rétention. Milvus 3.0 leur permet d’ajouter, de remplir et de supprimer des colonnes pendant que le service continue, au lieu des reconstructions disruptives que cela exigeait auparavant.

Ajouter ou supprimer une colonne ne nécessite pas de réécrire les données existantes. client.add_collection_field(...) ajoute une nouvelle colonne nullable sans mettre la collection hors ligne, et client.drop_collection_field(...) supprime un champ obsolète ou expérimental à l’exécution. Ni l’un ni l’autre ne réécrit les données existantes — chacun est une modification du manifeste de la collection plutôt que des fichiers de données, ce qui explique pourquoi il n’y a pas de reconstruction.

Milvus 3.0 prend en charge deux chemins de backfill :

• Le backfill interne (dans 3.0) est destiné aux valeurs dérivées de champs existants. Milvus peut générer un vecteur sparse BM25 à partir d’une colonne de texte au sein du noyau, éliminant le besoin d’un encodeur côté client lors de la construction d’une récupération hybride dense-plus-sparse.
• Le backfill externe(sur la feuille de route) sera destiné aux valeurs calculées en dehors de Milvus : prendre un snapshot, exécuter Spark sur la vue cohérente, calculer une nouvelle colonne, réécrire les valeurs et laisser Milvus mettre à jour l’index de manière incrémentale. C’est le chemin prévu pour les grandes tâches de ré-embedding — par exemple, ajouter une nouvelle colonne d’embedding sur des centaines de millions de lignes pendant que les écritures continuent.

Ensemble, les modifications de schéma en ligne et le backfill facilitent l’évolution des pipelines de récupération sans reconstruire une collection entière chaque fois que le modèle de données change.

Un moteur plus puissant pour la récupération de bout en bout

Milvus prend depuis longtemps en charge davantage que la recherche ANN dense, notamment la récupération sparse basée sur BM25 et la recherche hybride. Milvus 3.0 étend le moteur selon un autre axe : il intègre davantage du pipeline de récupération multi-étapes dans Milvus lui-même, réduisant la sur-récupération, la logique applicative dupliquée et la dépendance à des services de post-traitement séparés.

1. ORDER BY côté serveur : trier dans le moteur, par segment

Auparavant, le tri obligeait les applications à sur-récupérer des candidats, à les déplacer vers le client et à les y trier. Cela consommait de la bande passante et rendait le résultat final dépendant de l’endroit où la troncature côté client avait lieu.

Milvus 3.0 ajoute ORDER BY côté serveur, ce qui permet aux workloads de requête de trier les lignes filtrées selon des champs scalaires tels que la note, le prix, la fraîcheur, le stock ou l’horodatage.

• Sur le chemin de requête, chaque segment trie son ensemble de résultats filtrés, les nœuds de requête fusionnent ces flux, et le proxy renvoie la tranche demandée.
• Sur le chemin de recherche, ORDER BY trie l’ensemble de candidats ANN dans Milvus, réduisant la sur-récupération côté client et le post-traitement dupliqué. Cela ne modifie pas la frontière de rappel établie par les candidats ANN.

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

C’est particulièrement utile pour les recherches qui combinent la pertinence avec des contraintes métier ou orientées utilisateur telles que la note, le prix, la fraîcheur, le stock ou l’horodatage.

Pour plus d’informations, consultez Trier les résultats de recherche par champs scalaires et Trier les résultats de requête.

2. Agrégation et recherche à facettes

Milvus 3.0 ajoute l’agrégation côté requête avec des opérations telles que count, sum, average, minimum et maximum, groupées par un ou plusieurs champs scalaires. Cela supprime un schéma courant dans lequel les équipes extraient des lignes filtrées dans le code client uniquement pour compter, regrouper ou calculer des statistiques simples.

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

Milvus 3.0 ajoute également l’agrégation de recherche pour la recherche à facettes. Après une recherche ANN, Milvus regroupe les résultats récupérés par champ et renvoie les comptes par bucket, des statistiques agrégées et les top-N exemples de résultats par bucket — le schéma derrière le regroupement par marque, tranche de prix, couleur, tenant ou type de document. Une mise en garde : l’agrégation de recherche opère sur l’ensemble de résultats récupéré par ANN, et non sur toute la collection, de sorte que les comptes de facettes sont approximatifs. Lorsque vous avez besoin de comptes exacts, utilisez l’agrégation côté requête.

Pour plus d’informations, consultez Agréger les résultats de requête.

3. StructArray pour les vecteurs imbriqués et les modèles à interaction tardive

De nombreuses entités sont naturellement représentées par plusieurs vecteurs. Un long document est une série de chunks ; une vidéo est une séquence d’images que vous préférez conserver ensemble dans une seule ligne plutôt que disperser sur plusieurs ; un produit possède plusieurs images ou angles. Les modèles à interaction tardive poussent cela encore plus loin — ColBERT émet un vecteur par token, ColPali un par patch visuel. Dans chaque cas, l’unité que vous voulez réellement stocker et rechercher est l’entité entière, et non chaque fragment isolément.

StructArray permet à une ligne Milvus de contenir un tableau de longueur variable d’éléments structurés, incluant plusieurs vecteurs, tout en préservant un identifiant d’entité unique et un ensemble unique de métadonnées. Cela évite de diviser un document en plusieurs lignes et de dupliquer les labels, permissions ou autres champs entre fragments.

Milvus prend en charge deux granularités de recherche.

• La recherche au niveau élément fait correspondre un vecteur de requête à chaque élément de la liste et renvoie l’élément correspondant spécifique avec son offset. C’est utile lorsque vous voulez savoir quel chunk, token, patch ou image a correspondu. Une ligne peut apparaître plusieurs fois si plusieurs éléments correspondent.
• La recherche au niveau entité compare la liste complète de vecteurs d’une requête à la liste de vecteurs de la ligne en utilisant MAX_SIM, avec la métrique MAX_SIM_COSINE. Chaque token de requête prend sa meilleure correspondance dans le document, et ces meilleurs scores sont additionnés. Cela donne à Milvus une prise en charge native des schémas de récupération à interaction tardive tels que ColBERT et ColPali tout en conservant une ligne par document.

Indexer chaque vecteur de token peut être coûteux ; Milvus 3.0 ajoute donc plusieurs chemins d’accélération, notamment TokenANN, Muvera et Lemur, qui arbitrent entre taille de l’index, coût d’entraînement et rappel.

Stratégie	Représentation de première étape	Profil de coût	Idéal pour
TokenANN	Chaque vecteur de token est indexé.	Le plus élevé, exact	Modèles à forte discrimination et documents courts
Muvera	Un vecteur par document utilisant FDE par projection aléatoire.	Moyen, sans entraînement	Documents longs
Lemur	Un vecteur par document utilisant une compression MLP apprise	Le plus faible, nécessite un entraînement	Modèles à faible discrimination et vecteurs visuels ou de patch

Dans nos benchmarks, Lemur égale ou dépasse le rappel de TokenANN sur la plupart des jeux de données tout en réduisant chaque document à un seul vecteur ; l’exception concerne les corpus à forte variance de longueur, où TokenANN ou une autre stratégie est plus sûre.

Pour les corpus plus grands que la mémoire, Milvus prend également en charge un index DISKANN qui conserve les listes d’embeddings sur disque afin de réduire la pression sur la RAM.

La recherche au niveau élément est déjà arrivée dans Milvus 2.6. Le filtrage pour Muvera, Lemur et StructList est nouveau dans 3.0.

4. Compression d’index BM25 et SINDI

Milvus prenait déjà en charge la recherche vectorielle sparse dans les versions précédentes. Milvus 3.0 réduit l’empreinte de l’index sparse grâce à des postings compressés par blocs (algorithmes liés à VByte plus décodage SIMD) et à la quantification (fp16 pour les produits internes, u16 pour BM25).

Sur un ensemble de benchmarks BM25 internes, la nouvelle implémentation était environ 3 fois plus petite que l’index sparse de Milvus 2.6 à rappel comparable. Un index plus petit réduit la pression sur la mémoire et la bande passante et peut améliorer la vitesse dans les workloads limités par le déplacement de données.

Milvus 3.0 introduit également SINDI, un nouvel algorithme de récupération sparse optimisé pour les embeddings sparse appris tels que SPLADE. Comme ces embeddings produisent des listes de postings plus denses que BM25, les algorithmes de recherche fortement basés sur l’élagage peuvent consacrer beaucoup de temps CPU à décider quoi ignorer. SINDI organise plutôt les postings en fenêtres compactes et utilise une accumulation de scores compatible SIMD pour les traiter efficacement, tout en préservant la précision de récupération grâce à un élagage sans perte.

Nous avons également étendu SINDI au-delà de sa conception originale pour inclure la prise en charge native de BM25, permettant à Milvus d’utiliser le même chemin de récupération sparse optimisé pour les embeddings sparse appris comme pour la recherche plein texte traditionnelle.

Dans nos benchmarks sur 4 jeux de données de vecteurs sparse SPLADE, SINDI atteint jusqu’à environ 10x le QPS de MaxScore sur des vecteurs learned-sparse, avec un pire cas autour de 5x.

SINDI est l’option par défaut pour la recherche sparse par produit interne dans Milvus 3.0.

Autres améliorations

• TEXT LOB : Stocke le long texte source à côté des vecteurs. Le texte de moins de 64 Ko reste inline ; les valeurs plus grandes utilisent une référence Vortex LOB.
• Prise en charge étendue des index denses : Ajoute davantage de choix d’index au sein de la famille Faiss, notamment SVS, Panorama, PQ, IVFPQ et ScaNN, pour différents besoins d’échelle, de mémoire et de rappel.
• MinHash et recherche de quasi-doublons : Génère des signatures MinHash côté serveur et récupère des candidats quasi dupliqués avec MINHASH_LSH.
• Vecteurs nullable et nouveaux types : Permet aux champs vectoriels d’être NULL et ajoute TIMESTAMPTZ pour le filtrage sensible au temps et les politiques de rétention.
• Dictionnaires plein texte personnalisés : Enregistre des dictionnaires, synonymes et ressources de mots vides sur le cluster pour la tokenisation multilingue et spécifique à un domaine.
• Woodpecker standalone : Exécute le journal write-ahead de Milvus comme un service évolutif et observable de manière indépendante.
• Entité TTL**** : Fait expirer les enregistrements individuels via un champ TIMESTAMPTZ, avec un filtrage MVCC suivi d’un garbage collection pendant la compaction.
• ForceMerge : Compacte les petits segments jusqu’à une taille cible et reconstruit les index afin de réduire l’amplification de lecture avant un service durablement intensif en lectures.
• Et plus encore

Démarrer avec Milvus 3.0

Milvus 3.0 est disponible dès aujourd’hui sous licence Apache 2.0 et reste un projet LF AI & Data. Pour démarrer :

• Lisez les notes de version et le quickstart, et récupérez le code source sur github.com/milvus-io/milvus.
• Rejoignez la communauté Discord Milvus ou réservez une session Milvus Office Hours pour discuter de votre cas d’utilisation avec les mainteneurs.

Milvus 3.0 et Zilliz Vector Lakebase

Milvus 3.0 pose la fondation open source pour la récupération IA en production et l’architecture émergente Vector Lakebase, qui combine stockage natif du lake et récupération vectorielle haute performance sur une source de vérité unique, chacun au coût approprié.

Zilliz Cloud est un Vector Lakebase entièrement managé construit par l’équipe derrière Milvus. Il partage la même architecture distribuée et native du lake que Milvus et est entièrement compatible avec l’API Milvus. Propulsé par son moteur d’indexation propriétaire Cardinal, Zilliz Cloud offre jusqu’à 10× de meilleur rapport prix-performance que les approches d’indexation open source standard tout en éliminant la complexité opérationnelle de la gestion de l’infrastructure. Les capacités d’entreprise incluent le compute scale-to-zero, la reprise après sinistre inter-régions, le déploiement BYOC, la sécurité et la conformité de niveau entreprise (SOC 2, HIPAA, ISO 27001 et GDPR), ainsi qu’un SLA pouvant atteindre 99,99 %.

Les développeurs peuvent déployer Milvus comme base de données vectorielle open source ou utiliser Zilliz Cloud pour une plateforme managée couvrant plusieurs workloads tout au long du cycle de vie des données IA.

La suite

La feuille de route Milvus s’appuie sur l’architecture 3.0 avec le pushdown de prédicats pour les External Collections, le backfill externe, des opérateurs Spark supplémentaires et la prise en charge de davantage de formats de tables, notamment Delta Lake et Apache Paimon.

La direction générale est claire : les systèmes de données IA ont besoin d’une boucle plus étroite entre la récupération en ligne et l’amélioration offline des données. Les données vectorielles ne devraient pas devoir être copiées dans des systèmes séparés chaque fois que les équipes veulent les rechercher, les analyser, les améliorer ou les servir.