Blog
Guide du développeur pour explorer les fonctionnalités de Milvus 2.6 sur Zilliz Cloud

Guide du développeur pour explorer les fonctionnalités de Milvus 2.6 sur Zilliz Cloud

Feb 11, 202610 min read

Milvus a commencé comme une base de données vectorielle open source haute performance conçue pour le passage à l’échelle, avec des capacités de recherche vectorielle ANN à l’état de l’art. À mesure que la communauté de développeurs grandissait, les demandes de fonctionnalités se sont élargies pour inclure la recherche plein texte, le boosting et la prise en charge de types de données semi-structurées (JSON, struct, etc.). Ces demandes reflètent une tendance plus large vers la convergence des capacités des bases de données, portée par le besoin de fonctionnalités plus avancées (autres que la recherche par similarité) qui aident à accélérer le développement d’applications d’IA.

La convergence ne se manifeste pas seulement dans les demandes de fonctionnalités — elle se manifeste désormais dans la base de données elle-même. Avec Milvus 2.6, de nombreuses capacités que les développeurs devaient auparavant assembler en dehors de la base de données, comme le classement basé sur la décroissance, le boosting au niveau des champs et le filtrage hybride sur des données structurées et non structurées, sont désormais des primitives de premier ordre.

En d’autres termes, Milvus 2.6 marque le passage de "recherche vectorielle + code de liaison" à un moteur de récupération plus avancé, et il est désormais Generally Available (GA) on Zilliz Cloud (un service Milvus managé).

Dans cet article, je vais passer en revue certaines des fonctionnalités intéressantes de Milvus v2.6, quand les utiliser et comment les utiliser. Commençons !

The Embedding Function (également connue sous le nom de Data In, Data Out)

Vous êtes-vous déjà demandé si la base de données pouvait gérer la génération des embeddings pour vous ? Avec les Embedding Functions (également connues sous le nom de "Data in, data out"), Milvus peut transformer du texte brut en vecteurs en appelant des services d’embedding tiers externes tels qu’OpenAI, VoyageAI et Cohere.

Embedding Functions a été publié pour la première fois dans Milvus v2.6.0, et je l’ai présenté dans la démo kafka-milvus-no-code-pipelines. Désormais, les Embedding Functions sont disponibles sur Zilliz Cloud, le service entièrement managé de la base de données vectorielle Milvus.

Comment fonctionne l’embedding function ?

Supposons que vous insériez "The quick brown fox jumps over the lazy dog" dans Milvus avec une embedding function configurée. Milvus l’intercepte au niveau de la couche proxy, l’achemine via un pipeline d’embedding propre au fournisseur et stocke le vecteur produit par votre modèle. La même transformation se produit en sens inverse lors de la recherche. Le texte de votre requête est converti en vecteur avant d’atteindre l’index.

Cette fonctionnalité est particulièrement utile pour les équipes qui souhaitent confier à la base de données la responsabilité de gérer les workflows d’embedding. En laissant la base de données générer les embeddings de manière transparente au moment de l’ingestion (via un fournisseur de modèle tiers), Zilliz Cloud prend en charge l’intégration d’API, le traitement par lots, les nouvelles tentatives, les limites de débit et la gestion des échecs.

Pour commencer avec les Embedding Functions sur Zilliz Cloud, vous devez :

Configurer Model Provider Integration pour le fournisseur de service d’embedding de votre choix
Créer une collection avec Embedding Function définie
Insérer vos données.

Vous devriez pouvoir voir l’embedding function dans la console Zilliz Cloud sur la page du schéma de votre collection si vous l’avez correctement configurée.

Il ne vous reste maintenant qu’à insérer le texte brut, et les embeddings seront générés automatiquement et stockés dans votre champ de vecteur dense spécifié. Avec les embedding functions définies, vous n’avez plus besoin de générer des embeddings, même pour votre requête de recherche.

Un problème possible auquel vous pourriez être confronté sera la limite de taille de lot imposée par Milvus lors de l’utilisation de l’embedding function.

2026-01-21 14:03:12,902 [ERROR][handler]: RPC error: [insert_rows], <MilvusException: (code=65535, message=numRows [1000] > function [openai]'s max batch [640])>, <Time:{'RPC start': '2026-01-21 14:03:12.722589', 'RPC error': '2026-01-21 14:03:12.902013'}>

Bonnes pratiques et conseils

Restez dans la limite de taille de lot (indiquée dans le message d’erreur). Il s’agit d’un mécanisme de sécurité visant à éviter d’atteindre la limite de tokens du fournisseur de modèle par appel d’API. Par exemple, OpenAI a une limite maximale de 300 000 tokens par appel d’API.
Pour les textes longs ou les cas d’utilisation impliquant de grands documents, vous devez les découper avant l’insertion. Par exemple, OpenAI impose une limite de 8192 tokens par texte d’entrée pour tous les modèles d’embedding.
Bien que des fournisseurs comme VoyageAI et Cohere tronquent automatiquement les textes longs par défaut, s’appuyer sur ce comportement peut entraîner une perte silencieuse de contenu à la fin de votre document.

Mise en évidence lexicale

La mise en évidence lexicale est utile pour montrer aux utilisateurs pourquoi un résultat correspond à leur requête, en marquant visuellement les termes ou expressions exacts qui ont déclenché la correspondance. Cela améliore la transparence, l’interprétabilité et la confiance des utilisateurs dans les résultats de recherche.

Voici quelques scénarios clés :

Affichage des résultats de recherche dans les interfaces utilisateur. Lors de la création d’interfaces de recherche, la mise en évidence aide les utilisateurs à comprendre rapidement la pertinence d’un résultat sans ouvrir le document complet. Elle réduit la charge cognitive et améliore le taux de clics en rendant la correspondance explicite.

Recherche dans des documents / du contenu. Dans les documents volumineux (par exemple, bases de connaissances, PDF, politiques), la mise en évidence lexicale permet aux utilisateurs de localiser immédiatement les mots-clés correspondants dans le contexte environnant, accélérant ainsi la découverte d’informations.

Analyse des journaux / événements. La mise en évidence dans les journaux opérationnels ou les données d’événements facilite le repérage de motifs correspondants, de codes d’erreur ou de mots-clés dans un texte dense et non structuré, en particulier lors du dépannage ou de la réponse à un incident.

Débogage RAG (Retrieval-Augmented Generation). Dans les pipelines RAG, la mise en évidence lexicale aide les praticiens à examiner quelles parties des fragments récupérés correspondent à la requête d’origine. C’est utile pour :

Vérifier la justesse de la récupération
Diagnostiquer les faux positifs ou les correspondances faibles
Comprendre pourquoi un certain contexte a été sélectionné pour la génération

Pour implémenter la mise en évidence lexicale côté serveur avec Zilliz Cloud, vous devez d’abord instancier un LexicalHighlighter (avec le texte de requête à mettre en évidence et les balises environnantes indiquant l’apparence du texte mis en évidence) et le fournir comme paramètre à votre requête de recherche en texte intégral.

Ensuite, Milvus effectuera la recherche et exécutera la logique lexicale pour trouver les correspondances exactes et renvoyer les informations de position sur les sous-chaînes à mettre en évidence.

Bonnes pratiques et conseils

LexicalHighlighter ne fonctionne qu’avec la recherche en texte intégral BM25. Il ne fonctionnera pas pour la recherche vectorielle dense.
Vous pouvez définir pre_tags et post_tags pour envelopper les termes correspondants avec des balises HTML (par exemple, classe CSS personnalisée, gras, italique, etc.) qui s’affichent directement sur une page web.

Index N-gram

Les index N-gram sont de puissantes techniques d’indexation de moteurs de recherche qui décomposent les chaînes en séquences de caractères plus petites et se chevauchant (par exemple, "coffee" en 3-grams -> "cof", "off", "ffe", "fee") afin de permettre des correspondances partielles, flexibles et de type joker.

Voici quelques scénarios dans lesquels les index n-gram vous seront utiles :

Améliorer les performances des recherches de sous-chaînes (par exemple, LIKE %deep%)
Search-as-you-type / autocomplétion
Recherche approximative
Recherche de noms de domaine et d’identifiants (par exemple example.com, facebook.com)

Comment cela fonctionne-t-il ?

Les documents qui contiennent un n-gramme spécifié peuvent être localisés efficacement à l’aide d’un index, souvent appelé index inversé, qui associe chaque n-gramme à une liste d’identifiants des documents qui contiennent ce n-gramme. La liste est conservée triée afin de permettre à la fois une compression efficace et une exécution efficace des requêtes. Dans le cas de Milvus, l’index ngram est construit par-dessus Tantivy, qui utilise à son tour des techniques de compression comme l’encodage delta, le bitpacking et les skip lists pour compresser et réduire la taille de la liste inversée, rendant l’index léger.

Au lieu d’effectuer un scan complet de votre champ texte, Milvus extrait d’abord le prédicat, par exemple deep, le décompose en n-grammes selon les tailles de gram configurées, effectue des recherches dans l’index inversé et intersecte les résultats pour identifier les candidats contenant tous les grams, puis vérifie les correspondances exactes par rapport au motif LIKE d’origine.

Milvus vous permet de spécifier min_gram et max_gram, qui représentent respectivement la longueur minimale et maximale des n-grammes qui seront générés. Pour plus de détails sur la création et l’utilisation de l’index ngram, consultez le document NGRAM Index.

Voici une courte démo de l’autocomplétion implémentée à l’aide de la fonctionnalité d’index ngram de Milvus.

Bonnes pratiques et conseils

Effectuez des benchmarks avec des requêtes représentatives : Testez avec des modèles de requêtes réalistes avant de déployer en production afin de valider que les paramètres min_gram et max_gram correspondent au comportement réel des utilisateurs.
Combinez stratégiquement avec la recherche vectorielle : Utilisez le filtrage accéléré par NGRAM comme préfiltre afin de réduire l’ensemble de candidats avant le calcul de similarité vectorielle, améliorant ainsi la latence globale des requêtes.
Évitez le sur-indexage : Tous les champs VARCHAR ne bénéficient pas d’un index NGRAM. Priorisez les champs fréquemment utilisés dans des requêtes LIKE avec des motifs comportant des jokers.
Notez que l’index n-gramme est sensible à la casse. Cela signifie que les tokens sont indexés exactement tels qu’ils apparaissent dans le texte d’origine, en préservant les distinctions entre majuscules et minuscules. Les requêtes doivent correspondre exactement à la casse utilisée dans le contenu indexé.

Decay Ranker

Imaginez que vous construisez un moteur de recherche sémantique pour des articles de recherche, où vous favorisez les articles publiés au cours des 10 dernières années par rapport à ceux publiés il y a plus de 10 ans.

Sans le decay ranker de Milvus, vous devrez probablement reranker les résultats de recherche en dehors de la base de données vectorielle, en fonction du champ année de publication. Cela nécessitera un traitement côté serveur applicatif / client, ce qui ajoutera à la fois de la complexité et de la latence, pouvant avoir un impact négatif sur l’expérience utilisateur.

Au cœur du decay ranker de Milvus se trouve la Decay Function. Les Decay Functions ajustent les scores de pertinence en fonction de champs numériques (comme les timestamps). Le score final est calculé comme suit :

final_score = normalized_similarity_score x decay_score

Actuellement, il existe trois fonctions de décroissance différentes, à savoir : Linear, Exponential et Gaussian. Chaque fonction de décroissance est utile dans différents scénarios. Par exemple, la Linear Function doit être utilisée lorsque vous devez exclure des entités au-delà d’un certain point (par ex. années, distance, etc.). L’Exponential Function peut être utilisée lorsque vous souhaitez que les éléments plus récents dominent les résultats tout en permettant aux résultats plus anciens d’être découvrables. La Gaussian Function est utile pour les recherches basées sur la localisation, c.-à-d. que les éléments plus proches de l’emplacement actuel seront mieux classés.

Les fonctions de décroissance sont hautement personnalisables, et vous pouvez contrôler leur forme à l’aide de plusieurs paramètres lors de leur initialisation :

origin : Point de référence (p. ex., horodatage actuel)
offset : Crée une « zone sans décroissance » où les éléments conservent des scores complets (decay = 1.0). Utile pour garantir que les éléments très récents ou très proches ne sont pas du tout pénalisés.
scale : Des valeurs plus grandes produisent une baisse progressive de la pertinence ; des valeurs plus petites produisent une baisse plus abrupte.
decay : Contrôle la raideur de la courbe. Des valeurs plus faibles (p. ex., 0.3) créent une baisse plus abrupte ; des valeurs plus élevées (p. ex., 0.7) créent une baisse plus progressive. La valeur par défaut est 0.5.

Voici un exemple pour déterminer comment définir les paramètres de la fonction de décroissance :

Pour utiliser l’année en cours comme origine : origin=2026
Les articles de recherche de 2021 à 2026 sont également pertinents sans décroissance appliquée : offset=6
Le multiplicateur de score à la distance d’échelle : decay=0.5
Les articles de 2010 devraient avoir un score de décroissance (spécifié précédemment) de 0.5 : scale=16 (puisque 2026 - 2010 = 16)

Bonnes pratiques et conseils

Testez en A/B les configurations de décroissance. De petits changements dans les paramètres scale et decay peuvent avoir un impact significatif sur l’expérience utilisateur.
Assurez-vous que tous les paramètres basés sur le temps (origin, scale, offset) utilisent la même unité que les données de votre collection.
FunctionScore n’accepte qu’une seule DecayFunction par requête. Le chaînage ou la composition de plusieurs DecayFunctions n’est actuellement pas pris en charge.
Chaque classeur par décroissance ne prend en charge qu’un seul champ numérique. Vous ne pouvez pas combiner plusieurs facteurs de décroissance dans un seul classeur.
Évitez la décroissance sur des champs clairsemés ou asymétriques. Si votre champ de décroissance comporte de nombreuses valeurs nulles, des valeurs aberrantes ou des distributions fortement asymétriques, le classement par décroissance peut produire des résultats peu intuitifs.

Boosting

Le boosting est un mécanisme pratique pour intégrer des signaux de domaine dans le classement de recherche vectorielle. Alors que la recherche sémantique capture le sujet de votre requête, elle ignore souvent ce qui compte davantage dans un domaine donné. Le boosting vous permet de reclasser les résultats à l’aide d’un champ de métadonnées arbitraire, encodant ainsi efficacement l’intuition métier ou de domaine dans la couche de récupération.

Par exemple, dans un workflow de recherche d’articles scientifiques, deux articles peuvent tous deux être pertinents pour « deep learning », mais ne pas être aussi importants. Un article très cité peut mériter d’apparaître au-dessus d’un article moins cité, même si son score de similarité est légèrement inférieur. Avec le boosting, un article ayant un score de similarité de 0.79 mais 1 200 citations peut être classé plus haut qu’un article obtenant 0.81 avec seulement 10 citations.

Ce qui précède peut être implémenté en boostant les articles en fonction du nombre de citations. Une implémentation simple est la suivante :

Mais que se passe-t-il si nous voulons booster les articles de recherche dont le nombre de citations est compris entre 100 et 1000, et même inclure une fonction de décroissance pour favoriser les articles plus récents ? Il s’avère que nous pouvons chaîner une fonction de décroissance avec plusieurs classeurs de boosting dans une seule requête de recherche en utilisant la classe FunctionScore.

Bonnes pratiques et conseils

FunctionScore n’est actuellement pris en charge que pour la recherche vectorielle dense. La recherche hybride ne prend pas en charge FunctionScore ; utilisez plutôt un seul classeur.
Pour le boosting basé sur des champs à valeurs continues, envisagez de placer les valeurs dans des buckets discrets et d’attribuer des poids de boost distincts à chaque bucket.

Conclusion

Milvus 2.6 représente une avancée significative dans ce qu’une base de données vectorielle peut faire directement. Les fonctionnalités et capacités ci-dessus dont j’ai discuté ne sont pas simplement des plus agréables à avoir : elles éliminent le code de liaison que les développeurs devaient auparavant créer et maintenir en dehors de la base de données.

Au lieu d’assembler des pipelines d’embedding externes, une logique de reclassement personnalisée et des solutions de contournement pour la recherche de sous-chaînes, vous pouvez désormais les exprimer directement dans vos requêtes Milvus. Le résultat est un code applicatif plus propre, une latence plus faible et moins de composants à déboguer lorsque les choses tournent mal.

Si vous considérez Milvus comme « simplement » une base vectorielle, il est peut-être temps de réexaminer ce qui est possible. Toutes ces fonctionnalités sont désormais en disponibilité générale sur Zilliz Cloud, vous pouvez donc commencer à expérimenter dès aujourd’hui.

Ressources

Mis à jour le Jul 28, 2026

Ivan Tang
Solutions Architect

Continuer à lire

Why and How to Migrate from Self-Hosted Milvus to Zilliz Cloud

A simple, step-by-step guide to migrating from Milvus to Zilliz Cloud. Learn both endpoint and backup methods for a smooth, scalable vector database migration.

The Real Bottlenecks in Autonomous Driving — And How AI Infrastructure Can Solve Them

Autonomous driving faces a data bottleneck. Learn how AI-native vector databases like Zilliz solve scale, cost, and insight challenges across AV pipelines.

Why Not All VectorDBs Are Agent-Ready

Explore why choosing the right vector database is critical for scaling AI agents, and why traditional solutions fall short in production.