Recherche vectorielle : MongoDB entend unifier sa pile technologique

Une base de données ET des modèles d’embeddings

Voyage 4 est une nouvelle famille de modèles d’embeddings de texte.

« Voyage 4-large est notre nouveau modèle phare pour la plus grande précision d’extraction », annonce Frank Liu, membre de l’équipe responsable produit chez MongoDB, lors d’un point presse. « Désormais, cette famille de modèles comprend également le modèle voyage 4, à usage général, qui permet d’équilibrer la précision de la recherche, le coût et la latence. Voyage 4 Lite pour une latence et des coûts optimisés. Et pour la première fois, nous lançons un modèle open weight, Voyage 4 nano, pour le développement et les tests locaux ou les applications sur l’appareil ».

Tous les modèles disposent d’une fenêtre de contexte de 32 000 tokens et peuvent créer des vecteurs de 256, 512, 1024 (par défaut) et 2048 dimensions. Voyage-4-large a la particularité de s’appuyer sur une architecture Mixture of Experts. Cela lui permet d’obtenir des résultats précis tout en étant 40 % moins cher à servir qu’un modèle dense de même taille, selon MongoDB.

L’un des grands intérêts de cette famille de modèle, c’est qu’ils partagent tous le même espace vectoriel. En clair, les embeddings générés par les plus grands modèles peuvent être recherchés par les plus petits et vice-versa. Selon MongoDB, face à Cohere Embed 4.0 et Gemini Embedding 001 de Google, voyage-4 et voyage-4-large affichent des performances supérieures en matière de qualité de recherche et de recherche asymétrique.

« Cela signifie donc des embeddings de meilleure qualité pour une grande variété de domaines et de tâches, un meilleur rappel sémantique dans vos pipelines de recherche et d’extraction, ainsi qu’une robustesse accrue lorsque vous avez affaire à des données bruyantes du monde réel », vante Frank Liu.

Comme son nom l’indique, voyage 3.5 multimodal est un modèle d’embedding capable d’encoder et de retrouver du texte, des documents, des images et des vidéos. « Comme voyage-multimodal-3, voyage-multimodal-3.5 adopte une architecture où les modalités visuelles et textuelles passent par un seul encodeur transformateur », explique Voyage IA, dans sa documentation. « Cette architecture unifiée préserve les relations contextuelles entre les informations visuelles et textuelles, ce qui permet une vectorisation efficace des contenus entrelacés tels que les captures d’écran de documents, les PDF complexes et les images annotées ».

Une approche qui ne serait pas permise par les modèles d’embedding de type CLIP (Contrastive Language Image Pre-training) qui sépare le texte des images.

Automatiser la vectorisation

MongoDB le sait. L’heure n’est plus à la démonstration.

« Au cours des derniers mois, nous avons passé du temps avec d’innombrables clients, fondateurs, cadres de grandes entreprises, équipes de plateforme, développeurs, non pas pour choisir, mais pour comprendre où les choses cassent lorsque l’IA passe du prototype à la production », explique Ben Cafelo, SVP Head of Core Products & Atlas Foundational Services chez MongoDB. « Ces conversations commencent rarement par des modèles d’IA », souligne-t-il. « Elles commencent par des questions très pratiques telles que : “comment préparer nos données ? Comment maintenir les performances à mesure que l’on passe à l’échelle supérieure ? Comment garantir l’exactitude des résultats ? Comment éviter de coller cinq systèmes ou extensions différents juste pour livrer quelque chose ? Quel sera le retour sur investissement ?” ».

Outre le renfort de la robustesse du SGBD NoSQL, de sa disponibilité, des capacités multimodèles (semi-structurées, structurées, données en temps réel, etc.), MongoDB continue de miser sur la simplification pour les développeurs. Beaucoup de ces apports sont dédiés à Atlas, sa DBaaS.

Cela passe par exemple par l’intégration d’API depuis la plateforme pour accéder aux modèles d’embedding et de reranking de Voyage AI. Cette fonction en préversion publique doit permettre de ramener ces éléments sous le control plane de MongoDB, de faciliter la gestion de la facturation. Des API qui peuvent également servir d’autres systèmes.

En préversion publique également dans le module Vector Search de l’édition communautaire de la base, une fonction de génération automatique des vecteurs doit simplifier les pipelines RAG. « Le système génère automatiquement des embeddings vectoriels pour les données textuelles lors de la synchronisation initiale des données, lors de la création d’index, lors de l’insertion et de la mise à jour de documents, et lors du traitement des requêtes », indique MongoDB. « Les vecteurs restent synchronisés lorsque les données sous-jacentes changent, ce qui élimine le risque d’embeddings périmés ou inadaptés », promet-il.  

Compatible avec Python, JavaScript, Java, C# et Golang ainsi qu’avec les frameworks LangChain, LangGraph et le serveur MCP de MongoDB, la fonction devrait être « prochainement » disponible dans Atlas et l’édition entreprise.

Abaisser (encore) le coût de la recherche vectorielle

MongoDB a également présenté la disponibilité dans le module Vector Search de MongoDB Atlas des « préfiltres lexicaux ». Ils doivent permettre d’ajouter des filtres analytiques sur des données textuelles et géospatiales sur les résultats de la recherche vectorielle. « Cela veut dire que nous prenons en charge des champs vectoriels dans les index de recherche Lucene. Vous pouvez donc indexer différents types de champs et les classer par pertinence des vecteurs », explique un employé de l’éditeur dans une courte vidéo.

Ces préfiltres (fuzzy ou recherche floue, recherche de phrases, wildcard – en utilisant par exemple la première syllabe d’un mot ou une première série de chiffres –, ou QueryString, avec des opérateurs logiques) sont appliqués avant le calcul de recherche vectorielle. L’objectif est d’abaisser le coût de calcul en réduisant le nombre de vecteurs à remonter. Jusqu’alors, ces préfiltres pouvaient être appliqués après la phase de recherche et de reranking. Les résultats seraient également plus précis, argumente l’éditeur. Cela nécessite toutefois d’utiliser un nouvel index, compatible avec la fonctionnalité.

L’unification des charges de travail joue en la faveur de MongoDB

MongoDB est loin d’être le seul à avoir de la recherche vectorielle sa priorité. Les éditeurs de base de données SQL, dont Oracle et Microsoft, les spécialistes du NoSQL (Redis, Elastic, Couchbase, etc.) ou encore les acteurs spécialisés comme Pinecone, Qdrant ou Weaviate tentent de se différencier. Sans oublier les éditeurs de « lakehouse ». Le 6 janvier, Databricks a présenté Instructed Retriever, une manière d’accompagner la requête de l’utilisateur pour en faire un pipeline agentique. Un LLM décompose son plan de recherche et convertit les instructions en langage naturel en indications pour le reranker et en filtres de recherche.

Selon Stephen Catanzano, analyse chez Omdia, une division d’Informa TechTarget [également propriétaire du MagIT], « MongoDB réduit la latence et la complexité par rapport aux solutions fragmentées proposées par les concurrents ». « Nous avons constaté une forte pression de la part des entreprises pour utiliser des plateformes de données dotées de toutes les capacités d’IA dont elles ont besoin », note-t-il auprès de searchDataManagement, une publication sœur du MagIT. « MongoDB offre de nombreuses capacités ainsi qu’un solide écosystème pour combler les lacunes ».

William McKnight, analyste et fondateur de McKnight Consulting, lui, estime que MongoDB doit d’abord améliorer les performances d’ingestion et d’interrogations JSON, « à la traîne par rapport aux moteurs unifiés modernes » dans les cas d’usage à très large échelle. Et de suggérer davantage de partenariats, d’intégration avec des frameworks tiers et de conseils pour faciliter la mise en place de ces piles technologiques consacrées à l’IA.