Notes de mise à jour
Découvrez les nouveautés de Milvus ! Cette page résume les nouvelles fonctionnalités, les améliorations, les problèmes connus et les corrections de bogues de chaque version. Nous vous conseillons de consulter régulièrement cette page pour vous tenir au courant des mises à jour.
v3.0-beta
Date de publication : 9 mai 2026
| Version de Milvus | Version SDK Python | Version SDK Node.js |
|---|---|---|
| 3.0-beta | 3.0.0 | 3.0.0 |
Milvus 3.0-beta étend la base de données vectorielle Milvus avec une nouvelle intégration dans l'écosystème open lake : External Collection permet à Milvus d'interroger des tables lacustres externes sans copie, et Spark peut lire les collections Milvus directement via Snapshot. La version apporte également une extraction plus riche, un schéma plus expressif, une personnalisation plus poussée de la recherche de texte, des contrôles plus fins du cycle de vie des données et des modèles, et davantage de contrôles côté opérateur. Milvus 3.0 est le noyau central de Zilliz Lakebase, alimentant son service unifié, sa découverte et son traitement par lots.
Cliquez ci-dessous pour rejoindre notre webinaire afin d'obtenir plus de détails sur Milvus 3.0 et AMA avec les mainteneurs du noyau :
Caractéristiques principales
Collecte externe
Dans les pipelines de données d'IA typiques, des téraoctets d'embeddings et de métadonnées se trouvent déjà sur le stockage d'objets sous forme de tables Parquet, Lance ou Iceberg. La copie de ces données dans Milvus double le coût de stockage, ajoute un pipeline ETL qui doit être synchronisé et déplace la gouvernance des données du client.
La collecte externe supprime la copie. Une collection Milvus peut référencer des fichiers là où ils se trouvent déjà, et Milvus ne gère que le schéma, les index et l'exécution des requêtes. Une actualisation incrémentielle permet de maintenir la collection alignée sur les fichiers sous-jacents. Les clients dont les données ne peuvent pas quitter le lac, tels que les équipes financières et de santé, peuvent exécuter une recherche vectorielle sur ces données là où elles se trouvent. Un ensemble de données unique résidant dans le lac peut également être servi à partir de plusieurs instances Milvus à la fois.
Pour plus d'informations, voir Créer une collection externe.
Instantané
Le service et la découverte par lots ont souvent besoin de la même collection en même temps. L'évaluation de modèles A/B, la déduplication à grande échelle, la validation du backfill et le rollback de version ont tous besoin d'une vue stable de la collection pendant que les écritures sont encore en cours.
Snapshot crée une vue ponctuelle et en lecture seule d'une collection en référençant les segments existants au lieu de copier les données, de sorte que le coût marginal de stockage est proche de zéro. Les travaux par lots peuvent lire les données de l'instantané avec une isolation de type MVCC, tandis que la collection active continue d'accepter des écritures.
Pour plus d'informations, reportez-vous aux sections Instantanés, Gérer les instantanés et Cas d'utilisation des instantanés.
Requête / Recherche - Ordre par
Les fonctions de recherche et d'interrogation acceptent désormais l'ordre sur plusieurs champs, le tri étant poussé vers le bas dans le noyau Milvus et ASC / DESC pouvant être paramétré par champ. Cela comble une lacune courante dans la production : Le Top-K par distance seul ne répond souvent pas aux besoins de l'entreprise lorsque l'élément le plus similaire n'est pas le moins cher, le plus récent ou le plus populaire.
Les applications n'ont plus besoin d'extraire trop de résultats et d'effectuer un nouveau tri sur le client pour exprimer un classement composite.
Pour plus d'informations, voir Trier les résultats de la recherche par champs scalaires et Trier les résultats de la requête.
Agrégation de requêtes
Pour produire des statistiques sur la répartition des locataires, des comptes d'exhaustivité des champs ou la progression du déploiement des versions à partir d'une collection Milvus, il fallait auparavant extraire les entités correspondantes vers le client et les y agréger. Milvus 3.0 introduit l'agrégation scalaire de style SQL dans le noyau. Un appel de requête accepte group_by_fields et les expressions d'agrégation dans output_fields, y compris count(*), count(<field>), sum(<field>), avg(<field>), min(<field>), et max(<field>). L'agrégation est évaluée côté serveur après le filtrage.
Pour plus d'informations, reportez-vous à la section Agrégation des résultats de la requête.
Vecteur nul
Les embeddings sont souvent produits de manière asynchrone, de sorte qu'une entité peut arriver avant son vecteur. Les données multimodales présentent également des lacunes naturelles, comme une vidéo sans légende ou un produit sans image. Les versions antérieures n'avaient pas de bonne réponse : les applications retardaient l'écriture jusqu'à ce que le vecteur soit prêt ou remplissaient un vecteur de remplacement, et les deux choix nuisaient à la qualité de la recherche.
Milvus 3.0 prend en charge NULL dans les champs vectoriels des six types de vecteurs. La recherche ignore automatiquement les vecteurs NULL, la qualité de la recherche n'est pas affectée et les vecteurs NULL ne prennent effectivement pas de place. AddField s'étend également aux champs vectoriels dans le cadre de cette modification : avec nullable=True, une collection existante peut développer de nouveaux champs vectoriels en ligne sans avoir à être reconstruite.
Pour plus d'informations, reportez-vous à la section Champs Nullables.
Dictionnaire personnalisé et dictionnaire des synonymes
Les tokenizers prêts à l'emploi ne répondent pas toujours aux exigences de qualité de la recherche de production. Le chinois, les domaines verticaux tels que la médecine, le droit et la chimie, ainsi que les corpus multilingues peuvent bénéficier de manière substantielle de dictionnaires personnalisés et de tables de synonymes. Jusqu'à présent, ces ressources existaient principalement sous la forme de réécritures de requêtes côté application.
Milvus 3.0 ajoute un mécanisme FileResource permettant d'enregistrer des dictionnaires de tokenizer, des listes de synonymes, des listes de mots vides et des règles de décompactage personnalisés. Une fois enregistrée, une ressource peut être référencée à partir de n'importe quel tokenizer ou filtre et prend effet sur BM25, les analyseurs et Text Match. Les dictionnaires et les synonymes peuvent désormais être versionnés et gérés de manière centralisée au lieu d'être dispersés dans le code de l'application.
Pour plus d'informations, reportez-vous à la section Gérer les ressources de fichiers.
TTL des entités
Les TTL au niveau de la collection et de la partition sont trop grossiers pour de nombreux scénarios de cycle de vie et de conformité. Les différents locataires d'une même collection ont souvent des règles de conservation différentes et les entités individuelles peuvent avoir besoin d'expirer selon un calendrier qui ne correspond pas au reste de la collection.
Milvus 3.0 prend en charge le TTL par entité. Déclarez un champ TIMESTAMPTZ dans le schéma, marquez-le comme champ TTL par le biais d'une propriété de collection et Milvus récupère automatiquement les entités expirées. Cela couvre les demandes de droit à l'oubli, les données de session qui expirent et l'historique de conversation limité sans nettoyage du côté de l'application.
Pour plus d'informations, voir Définir le TTL au niveau de l'entité.
MinHash DIDO (Doc-in, Doc-out)
Milvus 2.6 a ajouté l'index MINHASH_LSH pour la détection de quasi-doublons basée sur l'ensemble, mais les applications devaient toujours calculer les signatures MinHash avant d'écrire des données dans Milvus.
Milvus 3.0 ajoute une fonction MinHash côté serveur. Déclarez un champ d'entrée VARCHAR et un champ de sortie BINARY_VECTOR dans le schéma, attachez une fonction FunctionType.MINHASH et Milvus calcule les signatures pendant l'insertion, l'insertion en bloc et la recherche. Avec MINHASH_LSH, cette fonction prend en charge les flux de travail de déduplication pour les grands ensembles de données, l'empreinte digitale et la détection du plagiat dans Milvus.
Pour plus d'informations, voir la fonction MinHash.
EmbList + DISKANN
L'hypothèse "une entité = un vecteur" n'est plus adaptée à la recherche moderne. Les documents longs sont divisés en plusieurs morceaux, les modèles d'interaction tardive tels que ColBERT émettent un vecteur par jeton et les entités multimodales peuvent comporter plusieurs vues.
EmbList stocke une liste de vecteurs de longueur variable par entité, avec DISKANN comme index sur disque. Le chemin d'accès au disque permet de contrôler l'utilisation de la RAM lorsque le corpus dépasse les budgets de mémoire. EmbList + DISKANN est la première variante de la famille plus large StructList dans ce CR. Le reste de la famille, y compris le filtrage StructList et l'accélération multi-vecteur Muvera / Lemur, est prévu pour la version officielle 3.0.
Pour plus d'informations, reportez-vous à la section Recherche avec des listes intégrées.
Forcer la fusion
Les charges de travail de production accumulent la fragmentation des segments au fil du temps, ce qui entraîne une gigue au niveau de la latence des requêtes et une augmentation de l'espace de stockage.
Milvus 3.0 ajoute la possibilité de déclencher explicitement le compactage de segments pendant les fenêtres creuses, en modes synchrone et asynchrone.
Pour plus d'informations, reportez-vous à la section Forcer le compactage par fusion.
Stockage V3
Milvus 3.0 présente Storage V3, un moteur de stockage en colonnes basé sur des manifestes où les données et les métadonnées vivent sur un stockage objet compatible S3. Chaque version d'un ensemble de données est capturée sous la forme d'un instantané de manifeste immuable, un fichier codé en Avro qui enregistre les groupes de colonnes, les journaux delta et les statistiques qui composent l'ensemble de données.
Les manifestes sont des fichiers Avro compacts, et les delta logs enregistrent les suppressions au niveau de l'entité sans réécrire les fichiers de données. Cela permet de limiter la surcharge des métadonnées au fur et à mesure que les ensembles de données augmentent. Le manifeste découple également le suivi des métadonnées du chemin d'accès aux requêtes, ce qui permet à une collection de gérer davantage de segments sans dégrader les performances des requêtes.
Comme les états sont stockés sur un support objet, l'ensemble de données est auto-descriptif : tout lecteur ayant accès au chemin de stockage peut le découvrir et l'interpréter sans avoir recours à un catalogue central. Cette propriété est à la base des collections externes, des instantanés et des futures intégrations de lacs.