Comment Zilliz a vu l’avenir des bases de données vectorielles — et les a conçues pour la production
Cet article est un récapitulatif du podcast avec Innovator Coffee et James Luan, VP of Engineering chez Zilliz.
Avant que l’IA générative ne devienne grand public, les bases de données vectorielles étaient rarement abordées en tant que telles. L’attention se portait encore principalement sur les bases de données relationnelles, les moteurs de recherche ou les frameworks big data. La recherche vectorielle, lorsqu’elle était mentionnée, se trouvait généralement dans des articles de recherche ou au sein de bibliothèques d’algorithmes — pas dans les discussions sur les systèmes de production.
Mais les bases de données vectorielles ne sont pas apparues de nulle part. Elles sont nées d’un changement plus profond dans la manière dont les données sont créées et utilisées. Vers 2017–2018, les équipes de Zilliz ont commencé à constater l’apparition du même problème : les entreprises voulaient exploiter beaucoup plus de données non structurées — texte, images, audio, journaux, comportement des utilisateurs — mais leurs outils existants n’étaient pas conçus pour cela. Les bases de données traditionnelles et la recherche par mots-clés pouvaient stocker ces données, mais elles n’étaient pas efficaces pour les comprendre. Elles géraient bien les correspondances exactes. Le sens et la similarité étaient une autre histoire.
Les vecteurs offraient un moyen pratique de combler cet écart. En transformant le texte, les images et d’autres contenus en embeddings, la similarité devenait quelque chose que les systèmes pouvaient calculer directement. Une fois les données représentées de cette manière, les bases de données ne se contentaient plus de stocker des enregistrements. Elles pouvaient récupérer des informations en fonction du sens, et pas seulement des mots-clés.
Par conséquent, les bases de données vectorielles se situent entre des modèles puissants et des données réelles désordonnées, rendant les informations non structurées recherchables, comparables et utilisables à grande échelle.
Alors, comment la recherche vectorielle est-elle passée de la recherche à la production — et vers où se dirigent les bases de données vectorielles ensuite ? Dans un épisode récent du podcast anglophone Innovator Coffee, James Luan, VP of Engineering chez Zilliz, a partagé son point de vue, en s’appuyant sur l’histoire fondatrice de l’entreprise, la réflexion derrière Milvus, la base de données vectorielle open source de Zilliz, et les principes de conception qui ont façonné le système.
Des algorithmes à la production : l’évolution des bases de données vectorielles
En repensant aux débuts, avant que la recherche vectorielle ne soit prête pour la production, James Luan note que la plupart des premiers progrès ont eu lieu au sein de grandes entreprises technologiques. Des projets comme FAISS de Meta ont posé les bases techniques, mais il s’agissait de bibliothèques — pas de bases de données. Des systèmes de recherche vectorielle similaires existaient dans des entreprises telles que Microsoft et Spotify, généralement conçus pour un usage interne et adaptés à des charges de travail spécifiques. Ces outils étaient efficaces, mais ils n’ont jamais été conçus pour fonctionner comme des systèmes généralistes et durables.
Le tournant est survenu lorsque la recherche vectorielle est passée de la recherche à de véritables produits. Dès que les équipes ont tenté de la déployer en production, les défis au niveau système sont devenus impossibles à ignorer. L’évolutivité, la fiabilité et les opérations quotidiennes comptaient autant que la qualité de la recherche. Différentes voies ont émergé. Certaines équipes ont construit des services managés optimisés pour l’inférence en ligne et l’intégration étroite avec les grands modèles de langage. D’autres ont adopté une approche d’infrastructure plus large, intégrant la recherche vectorielle aux data lakes et aux bases de données traditionnelles pour prendre en charge des cas d’utilisation à l’échelle de l’entreprise. Selon James, cette divergence est une étape naturelle dans l’émergence de toute nouvelle couche d’infrastructure.
À mesure que les grands modèles de langage ont mûri et que les applications ont atteint la production, le rôle des bases de données vectorielles s’est rapidement élargi. Les premiers cas d’utilisation se concentraient sur la récupération fondée sur la similarité — systèmes de recommandation, recherche d’images et mise en correspondance de contenus. Au cours des deux à trois dernières années, la Retrieval-Augmented Generation (RAG) est devenue le modèle dominant. Dans les systèmes RAG, les bases de données vectorielles fournissent aux modèles un contexte pertinent et ancré, permettant la récupération de faits et contribuant à réduire les hallucinations.
Ce rôle devient encore plus important dans les systèmes basés sur des agents. Ici, les bases de données vectorielles agissent comme une mémoire à long terme ou quasi en ligne, prenant en charge le raisonnement en plusieurs étapes, la compression du contexte et la recherche multimodale. James résume cette évolution par un principe simple : moins de structure, plus d’intelligence. À mesure que les capacités des modèles s’améliorent, les pipelines rigides et l’étiquetage initial lourd peuvent freiner les systèmes. Les agents sont plus performants lorsqu’ils opèrent dans un espace sémantique flexible et décident dynamiquement comment récupérer et combiner les informations.
Dans le même temps, James souligne que les bases de données vectorielles ne sont pas magiques. La qualité de la recherche dépend autant de la gouvernance des données que des algorithmes. Des données bien organisées et pertinentes pour le domaine — ainsi qu’une évaluation continue — sont essentielles. Les modèles d’embedding, les rerankers et les stratégies de recherche évoluent rapidement, et les équipes qui attendent trop longtemps avant de réévaluer leur pile technologique prennent souvent du retard.
Au-delà de l’inférence, James voit les bases de données vectorielles jouer un rôle croissant dans l’entraînement et la préparation des données. À mesure que les modèles multimodaux deviennent plus courants, la recherche vectorielle est de plus en plus utilisée pour nettoyer, dédupliquer et organiser de grands jeux de données couvrant texte, images, vidéo et PDF. Avec le temps, cela pourrait converger avec les data lakes vers une architecture de « vector lake », reliant le traitement de données par lots à l’inférence en ligne.
Dans cette perspective à plus long terme, les bases de données vectorielles ne sont plus de simples moteurs de recherche. Elles deviennent une couche sémantique couvrant l’entraînement, l’inférence et la gouvernance des données à long terme — prenant en charge l’ensemble du cycle de vie des systèmes d’IA.
Comment Zilliz a trouvé sa voie avant que les bases de données vectorielles ne se généralisent
James décrit les débuts de Zilliz comme une période d’exploration plutôt que de clarté immédiate. Lui comme le CEO de l’entreprise venaient d’univers de bases de données traditionnelles, ayant passé des années à construire des systèmes transactionnels chez Oracle. Dès le départ, ils savaient qu’ils ne voulaient pas créer une autre base de données conventionnelle — mais la nature de cette alternative restait une question ouverte.
Leur première tentative fut une base de données accélérée par GPU visant à accélérer le traitement de données à grande échelle grâce à du matériel spécialisé. Techniquement, cela fonctionnait. Commercialement, non. Les GPU offraient de solides performances, mais ils étaient coûteux, et pour la plupart des charges de travail réelles, le compromis coût–performance était difficile à justifier. Dans le même temps, des systèmes basés sur CPU comme ClickHouse s’amélioraient rapidement, comblant une grande partie de l’écart de performance pour une fraction du coût.
Cette expérience a imposé une remise en question plus profonde. Au lieu de se demander comment rendre les bases de données plus rapides, l’équipe a commencé à poser une autre question : quels types de données étaient encore mal pris en charge ? Les charges de travail analytiques et transactionnelles traditionnelles disposaient déjà de solutions matures. Ce qui ressortait, c’était les données non structurées — texte, images et autres contenus que les utilisateurs voulaient de plus en plus rechercher et comprendre, pas seulement stocker.
Le tournant est venu grâce aux retours des utilisateurs. Certains premiers utilisateurs ont demandé si le système pouvait être utilisé pour accélérer la recherche d’images. Cette question pointait vers une opportunité plus large : la similarité sémantique à grande échelle, rendue possible par les représentations vectorielles. L’équipe a compris que les vecteurs — et non les GPU — constituaient l’abstraction la plus fondamentale. De cette intuition est né Milvus, en tant que projet open source axé sur la recherche vectorielle à grande échelle.
James souligne que ce pivot n’était pas motivé par l’engouement. À l’époque, les « bases de données vectorielles » n’étaient pas une catégorie reconnue, et le terme lui-même n’avait même pas de définition claire. Ce qui a guidé la décision, c’était une conviction ancrée dans les fondamentaux des bases de données : si la recherche sémantique devait devenir importante, elle aurait tôt ou tard besoin des mêmes qualités que tout système de données critique — évolutivité, stabilité et fiabilité.
Ce choix a défini la direction de tout ce qui a suivi. En s’engageant tôt en faveur des vecteurs comme données de première classe et des bases de données comme systèmes durables, Zilliz s’est positionnée en avance sur le virage de l’industrie vers les applications pilotées par l’IA — bien avant que ce virage ne devienne largement visible.
À mesure que les modèles sont ensuite passés de la recherche à la production, les bases de données vectorielles sont devenues un élément central des architectures d’IA d’entreprise, prenant en charge les pipelines RAG, les systèmes d’agents, la recherche multimodale et la déduplication des données d’entraînement à grande échelle. Avec cette expansion sont apparues de nouvelles attentes. La vitesse seule ne suffisait plus. La précision, la scalabilité, l’efficacité des coûts, la gouvernance des données et la sécurité sont toutes devenues des préoccupations de premier ordre.
La conclusion de James est que construire des systèmes qui équilibrent ces exigences n’est pas un problème d’optimisation à court terme. Cela exige de la patience, un investissement d’ingénierie soutenu et un engagement à long terme envers les fondamentaux de l’infrastructure — bien au-delà de l’enthousiasme initial suscité par une nouvelle catégorie.
Défis techniques et solutions : exécuter des bases de données vectorielles en production
À mesure que les bases de données vectorielles ont été intégrées à de véritables systèmes d’IA en production, James affirme que la réussite ne dépendait plus de la performance brute. Lors des premiers déploiements, la vitesse comptait plus que tout. Mais lorsque les grands modèles de langage sont entrés en scène, le véritable défi est devenu la construction de systèmes capables de passer à l’échelle de manière durable — en équilibrant simultanément coût, précision, fiabilité et exigences d’entreprise.
Coût : aller au-delà de la recherche uniquement en mémoire
James souligne que les premiers systèmes de recherche vectorielle reposaient fortement sur des index en mémoire. Cette approche fonctionnait lorsque les ensembles de données étaient petits, mais elle est devenue économiquement intenable à mesure que les applications pilotées par les LLM ont poussé les volumes de données beaucoup plus haut. À cette échelle, réduire la latence de quelques millisecondes compte bien moins que maîtriser les coûts de stockage.
La solution est une approche par niveaux du stockage et de l’indexation. En combinant des index en mémoire, sur disque et sur stockage objet, les bases de données vectorielles peuvent réduire les coûts de stockage jusqu’à 100x. Ce changement ne se contente pas d’optimiser les charges de travail existantes — il rend avant tout la recherche à grande échelle praticable.
Scalabilité et stabilité à l’échelle du monde réel
Les pressions sur les coûts révèlent rapidement les limites de scalabilité. James note que de nombreuses équipes commencent avec des configurations simples, à nœud unique, parce qu’elles sont faciles à déployer. Les problèmes apparaissent plus tard, lorsque les données augmentent de 10x, 50x, voire 100x en peu de temps.
Cette réalité a conduit Zilliz à reconstruire Milvus comme un système distribué, cloud-native. Pour James, la scalabilité est indissociable de la stabilité. Un système capable de passer à l’échelle mais qui échoue de manière imprévisible sous de vraies charges de travail n’est pas une infrastructure utilisable.
Il souligne que la stabilité est souvent la partie la plus difficile de la transformation de la recherche vectorielle en système de production. Avec les outils open source existants, de nombreuses équipes peuvent construire un prototype fonctionnel en six à douze mois. Ce qui est difficile, c’est de faire en sorte que ce système se comporte de manière fiable sur de longues périodes, à mesure que le volume de données, les schémas de requêtes et la complexité opérationnelle évoluent.
Contrairement à l’optimisation des performances, la stabilité ne provient pas d’une percée unique. Les gains de performance sont visibles — les benchmarks peuvent montrer une amélioration de 20 % ou 30 % en quelques mois. La stabilité se construit différemment. Chaque correction peut améliorer le SLA de seulement une fraction de pourcent, à peine perceptible en soi. Mais grâce à des centaines de petites améliorations cumulatives, un système devient progressivement suffisamment fiable pour fonctionner comme infrastructure à long terme.
Précision : la recherche fixe le plafond
Dans les systèmes RAG et d’agents, la qualité de la recherche détermine directement la performance du modèle. Si le système ne parvient pas à retrouver les bonnes informations, le modèle n’a aucun moyen de compenser.
James insiste sur le fait que la précision n’est pas seulement une préoccupation liée à la base de données. Elle dépend de l’ensemble de la pile de recherche, y compris les modèles d’embedding, les stratégies de reranking et la qualité des données. Comme ces composants évoluent rapidement, les équipes doivent réévaluer fréquemment leurs configurations — souvent tous les quelques mois — afin de maintenir la précision dans le temps.
Comment Zilliz équilibre open source et activité commerciale
Au cours de l’année ou des deux dernières années, James a passé beaucoup de temps à réfléchir à un défi qui se présente régulièrement aux entreprises open source : comment construire et maintenir une communauté open source active tout en dirigeant une entreprise en croissance.
Les objectifs de l’open source et les objectifs commerciaux ne s’alignent pas toujours parfaitement. Les projets open source dépendent de l’ouverture, de la participation à long terme et de la confiance de la communauté, tandis qu’une entreprise doit gérer des objectifs de chiffre d’affaires et des contraintes de croissance. Ces dernières années, ce décalage est devenu plus visible dans l’ensemble du secteur. James a vu plusieurs équipes faire passer leurs projets open source en mode maintenance — non pas parce que la technologie ne fonctionnait plus, mais parce que le modèle open source devenait difficile à soutenir à mesure que l’entreprise se développait.
Mais pour Zilliz, l’open source n’est pas seulement un choix technique — c’est aussi une décision de mise sur le marché. En pratique, il fonctionne un peu comme un essai gratuit très technique — un moyen pour les développeurs de découvrir, d’évaluer et de prendre confiance dans un produit grâce à une utilisation réelle. C’est particulièrement important pour les startups, où l’acquisition des premiers utilisateurs est difficile. Pour une équipe pilotée par l’ingénierie comme Zilliz, cela s’est révélé bien plus efficace que les approches traditionnelles de marketing ou de vente.
En rendant Milvus open source, l’équipe a fait de GitHub le principal point d’entrée. Les développeurs ont utilisé Milvus dans des charges de travail réelles, partagé leurs retours et contribué des améliorations au projet. Au fil du temps, cela a créé une boucle de rétroaction étroite entre les utilisateurs, la communauté et le développement produit.
Les résultats ont été tangibles. James note qu’environ 80 % des clients de Zilliz Cloud ont commencé comme utilisateurs du projet open source Milvus. L’open source a également servi de puissant mécanisme de confiance — les équipes qui avaient exploité Milvus elles-mêmes étaient bien plus à l’aise pour adopter ensuite une offre commerciale.
Cette transition, toutefois, n’a jamais été automatique. James est clair : l’open source seul ne crée pas une entreprise. Un produit commercial doit faire plus que conditionner de l’open source — il doit résoudre des problèmes que la version open source ne résout pas. Pour Zilliz, cette valeur réside dans l’exploitation fiable de Milvus à grande échelle — gérer les mises à niveau, traiter les défaillances et optimiser en continu les performances et les coûts.
Un résultat important de cette approche est que de nombreux utilisateurs constatent une baisse de leurs coûts globaux après être passés à l’offre managée. Les bases de données vectorielles évoluent rapidement, sous l’effet des progrès en matière d’indexation, de quantification et de stockage. Avec Zilliz Cloud, les utilisateurs bénéficient en continu de ces améliorations, sans avoir à assumer eux-mêmes le fardeau des mises à niveau ou de la gestion de l’infrastructure.
Du point de vue de James, cet équilibre est ce qui rend le modèle durable. L’open source crée l’accès et la confiance. L’offre commerciale transforme les progrès à long terme de l’infrastructure en valeur pratique — sans compromettre l’ouverture qui a attiré les utilisateurs au départ.
Comment Zilliz se démarque sur un marché encombré
Lorsqu’on l’interroge sur l’état actuel du marché des bases de données vectorielles, James reconnaît que l’adoption rapide de l’IA a vite saturé l’espace. Il comprend désormais des services managés, des plugins légers et un nombre croissant de nouveaux entrants proposant des capacités de recherche vectorielle. En surface, beaucoup de ces solutions semblent similaires.
Selon James, la véritable distinction ne se définit pas par des listes de fonctionnalités, mais par la profondeur et la maturité des systèmes sous-jacents. Construire une fonction de recherche vectorielle basique est relativement simple. Construire un système capable de fonctionner de manière fiable à grande échelle, sur de longues périodes, ne l’est pas.
Maturité des systèmes
L’avantage de Zilliz commence par la maturité des systèmes — en particulier l’évolutivité, la stabilité et le contrôle des coûts. Dès le départ, Milvus a été conçu comme une base de données distribuée, native Kubernetes, construite pour rester stable à mesure que les volumes de données augmentent de plusieurs dizaines de fois. C’est important, car les charges de travail vectorielles évoluent rarement de manière fluide. Les systèmes qui fonctionnent bien à petite échelle rencontrent souvent des difficultés dès que l’utilisation devient soutenue, irrégulière et imprévisible.
Le coût fait également partie de cette maturité. Zilliz a investi tôt dans l’indexation multi-niveaux, combinant mémoire, disque et stockage objet. Cela offre aux utilisateurs une flexibilité pratique pour équilibrer performance et coût à mesure que les charges de travail évoluent, plutôt que de les enfermer dans un mode d’exploitation unique et coûteux.
Préparation à l’entreprise
La préparation à l’entreprise est un autre facteur clé de différenciation. James compare Zilliz à des équipes issues principalement d’univers centrés sur les modèles ou l’IA. Les racines de Zilliz dans l’ingénierie traditionnelle des bases de données ont conduit à investir très tôt dans des capacités telles que le contrôle d’accès, l’isolation des données, les déploiements BYOC, le chiffrement et la conformité.
Ces fonctionnalités ne sont pas facultatives à l’échelle de l’entreprise. Ce sont elles qui permettent aux bases de données vectorielles de dépasser l’expérimentation par les développeurs et d’entrer dans des environnements réglementés tels que la finance, la santé et les grandes organisations soumises à des exigences strictes en matière de sécurité et de gouvernance.
Fiabilité opérationnelle
James note que de nombreuses équipes sous-estiment la complexité opérationnelle à long terme des bases de données vectorielles. Les premiers systèmes peuvent bien fonctionner dans des configurations contrôlées, mais les véritables défis apparaissent lorsque les données croissent rapidement, que la concurrence augmente et que les applications d’IA passent en production continue.
La plupart des entreprises ne veulent pas consacrer leur temps et leurs ressources à l’exploitation d’infrastructures complexes, en particulier dans des domaines très spécialisés comme la recherche vectorielle. C’est là que James voit le rôle de Zilliz : prendre en charge la charge opérationnelle liée à l’exécution de bases de données vectorielles à grande échelle, afin que les équipes puissent se concentrer sur la création d’applications plutôt que sur la maintenance de l’infrastructure. À mesure que le marché mûrit, cette division du travail devient de plus en plus importante.
Perspectives : la prochaine phase des bases de données vectorielles
En se projetant à trois à cinq ans, James adopte une vision pragmatique de la direction que prend le secteur. La croissance se poursuivra, mais la question clé ne sera plus de savoir si des systèmes de bases de données vectorielles peuvent être construits : elle sera de savoir s’ils peuvent être exploités de manière durable. À mesure que les modèles deviennent plus grands et que les applications d’IA s’enfoncent davantage dans la production, les volumes de données augmenteront rapidement, élevant les exigences en matière de maîtrise des coûts, de fiabilité, de précision et de sécurité.
Dans cet environnement, la capacité à réduire les coûts d’un ordre de grandeur sans compromettre la qualité de la récupération devient un critère de référence déterminant. James estime que c’est là que se forment les avantages durables. Les leaders à long terme dans le domaine des bases de données vectorielles ne seront pas déterminés par les fonctionnalités ou l’effet de mode, mais par la discipline d’infrastructure — la capacité à exploiter des systèmes à grande échelle de manière efficace, fiable et dans la durée.
Pour écouter la discussion complète, vous pouvez retrouver l’épisode sur Spotify, Apple Podcasts et YouTube.
Continuer à lire
Introducing Loon: A New Storage Engine for Vector Data That Never Stops Changing
Loon is a new storage engine for Milvus 3.0 and Zilliz Vector Lakebase, built to manage evolving vector datasets with ColumnGroups, row ID alignment, and Manifests.
3 Easiest Ways to Use Claude Code on Your Mobile Phone
Run Claude Code from your phone with Remote Control, Happy Coder, or SSH + Tailscale. Comparison table, setup steps, and tools for typing, memory, and parallel tasks.
Bringing AI to Legal Tech: The Role of Vector Databases in Enhancing LLM Guardrails
Discover how vector databases enhance AI reliability in legal tech, ensuring accurate, compliant, and trustworthy AI-powered legal solutions.