RAG et IA agentique : MongoDB automatise la vectorisation des documents

Une approche simple, moins adaptée à certains documents

Présentée pour la première fois en janvier dernier, cette automatisation ne s’applique pas seulement à la première ingestion de documents. Selon les porte-parole de MongoDB, l’index est automatiquement rafraîchi quand un document change. Ici, le pipeline d’agrégation automatique inclut deux étapes et sept paramètres.

« Lorsqu’un document est modifié, MongoDB Atlas ne réintègre les données que si un champ indexé a effectivement changé », expliquent-ils, dans un billet de blog. « La synchronisation s’effectue en temps quasi réel. Il n’y a pas de procédure de réindexation manuelle, car il n’y a pas d’index manuel à gérer », poursuivent-ils. « Cette même propriété s’étend à la recherche sur les vues. Si votre source d’intégration est une chaîne de titres, de distributions et d’années, une mise à jour de l’un de ces champs sous-jacents se propage automatiquement via la vue vers l’index ».

Précisons que les documents peuvent être automatiquement indexés en lot en fonction de la taille des documents et de leurs « formes ». Toutefois, il faut noter que MongoDB utilise la technique dite du 1 pour 1.

En clair, un vecteur correspond à un document. Les deux éléments portent les mêmes identifiants et la collection d’embeddings conserve les champs nécessaires à l’identification et le filtrage des documents. L’éditeur évite ainsi de découper les fichiers texte, audio ou vidéo en chunks (en morceau de 250 ou 500 tokens, par exemple). Il préfère combiner des techniques de recherche par vecteur et par filtre.

Cette approche présente toutefois des limites. Le vecteur représentant l’ensemble du document peut diluer la pertinence sémantique pour des requêtes ciblées. Le découpage en chunks est la solution privilégiée pour contourner cette limite.

La méthode semble plus indiquée pour les objets habituellement stockés dans MongoDB comme des fiches produit ou des images partiellement labélisées.

Un bras de fer avec Elastic

Techniquement, MongoDB isole l’indexation de l’interrogation. L’indexation est exécutée par un Tier de calcul multitenant nommé Atlas Flex. Par défaut, il permet de stocker 5 Go de données et réalise 100 opérations par seconde, mais une option de mise à l’échelle dynamique permet d’effectuer jusqu’à 500 opérations par seconde. Les requêtes de recherche, elles sont optimisées pour la latence et s’exécutent sur le cluster dédié du client.

Cette instance Flex est facturée à l’heure, mais elle coûte au maximum 30 dollars par mois pour 5 Go de données et 500 opérations par seconde. Il faut ajouter à cela le prix de la création des embeddings, elle aussi dépendante d’instances multitenant. Les modèles Voyage 4 lite, Voyage 4 et 4 Large sont respectivement facturé 0,02, 0,06 et 0,12 dollar pour un million de tokens, tandis que voyage code 3 coûte 0,18 dollar pour le même volume de tokens.

En outre, MongoDB laisse les clients choisir la méthode de quantisation (de compression) des embeddings. La méthode peut être scalaire ou binaire. La quantisation scalaire, par défaut, réduit chaque dimension d’un vecteur de 32 à 8 bits, tandis que la quantisation binaire permet de le réduire à un seul bit. « Pour les charges de travail où le corpus est suffisamment volumineux, le compromis en matière de rappel est largement compensé », affirment les porte-parole de MongoDB.

Son concurrent, Elastic, a également lancé le 11 mai 2026 des modèles d’embedding cette semaine consacré à la multimodalité (audio, vidéo, image, texte) et à 100 langues. L’éditeur s’est appuyé sur les encodeurs de Qwen 3.5 pour créer Jina v5 Omni, une collection comprenant deux modèles, small et nano.

À la différence de ceux de MongoDB, les poids sont ouverts tant que l’usage n’est pas commercial. Et d’affirmer que ces deux modèles s’en sortent mieux que Voyage 4 nano (lite), mais il ne le compare pas à Voyage 4 Large. S’il est possible d’autohéberger les modèles Jina v5 omni, Elastic facture non pas un modèle en particulier, mais l’accès à ses API normales et premium. Il facture un volume de tokens (à partir de 1 milliard de tokens ou 11 milliards de tokens) au prix de 50 ou de 500 dollars par mois (0,05 ou 0,045 pour 1 million de tokens).

Elastic mise sur sa propre approche de quantisation, BBQ, ainsi que sur la création de LoRa (low-rank adapters). Cette technique permet d’affiner un petit nombre de paramètres des modèles d’embedding sur des images, des sons ou des éléments de texte spécifiques. Lui aussi mise sur la recherche hybride, mais s’appuie sur les attributs de Lucene, à savoir les algorithmes de type BM25 et les index KNN.

Là où MongoDB dit chercher à simplifier le travail des développeurs, Elastic se présente comme « le moteur de recherche », très flexible, puissant en matière de traitement de données plein texte, mais aussi plus complexe. Sans oublier les acteurs plus spécialisés encore comme Pinecone, Qdrant, Milvus, Weaviate et les géants du cloud.

MongoDB fait de LangGraph sa mémoire à long terme pour les agents IA

Au-delà de la vectorisation, MongoDB mise sur l’intégration avec les frameworks agentiques. Le mécanisme de vectorisation automatisée des documents chez MongoDB peut être connecté à Memory Store, une mémoire à long terme pour les agents IA. Cette fonctionnalité en disponibilité générale s’appuie sur LangGraph.js. Le framework distingue une mémoire à court (par session utilisateur) et à long terme (intersession ou au niveau d’une application).

Dans le cas de la mémoire à court terme, il s’agit de stocker les historiques de conversation à l’aide de « checkpointer ». Ce sont des états du graphe à un instant T contenant les étapes des conversations, organisés en threads. Les threads eux-mêmes sont considérés comme des « collections de checkpoints ». La mémoire à long terme implique un mécanisme nommé Store permettant de sauvegarder des « informations arbitraires » à travers les threads.

Comme le thread est associé à un identifiant et à un utilisateur, le checkpointer utilise le thread id pour sauvegarder l’état de la conversation. Store s’appuie sur le user id pour organiser persister des données accessibles à travers différents threads. Tout cela s’appuie sur un mécanisme de paire clé-valeur, particulièrement compatible avec MongoDB qui stocke les conversations et les actions au format JSON.

« Alors que les concurrents spécialisés se distinguent par leur latence vectorielle brute, MongoDB offre une simplicité d’utilisation et une gestion de la mémoire à long terme en éliminant la nécessité de synchroniser les données entre des systèmes disparates », considère William McKnight, président du cabinet d’analystes McKnight Consulting, auprès de SearchDataManagement, une publication sœur du MagIT. « Il dispose également de fonctionnalités de pointe pour les données au format JSON. En fin de compte, c’est un choix pragmatique qui allie une fiabilité de niveau entreprise et un stockage JSON hautement performant à une orchestration IA intégrée ».

Reste, selon lui, « à combler l’écart » avec les acteurs du full search, en complétant ses algorithmes « fuzzy search » avec des fonctions de recommandations de documents en temps réel et de correction orthographique.

Mickael Leone, analyste chez Moor Insights & Strategy, retient l’apport de l’automatisation des pipelines d’embeddings. Il considère que le mécanisme d’actualisation de l’index comme un moyen de gagner en confiance dans les réponses des agents IA. À voir si ces systèmes seront capables d’interpréter les documents les plus longs. Les éditeurs comme ServiceNow découpent leur documentation en petits segments pour la rendre lisible et actualisable par des agents IA.

MongoDB 8.3, toujours plus performante

Voilà pour les nouveautés qui animent les acteurs du marché. Mais MongoDB n’oublie pas le machine learning plus traditionnel en rendant accessible une intégration avec le feature store Feast. Il s’agit de conserver les paramètres et les hyperparamètres des modèles déployés ou non en production. Ce mécanisme permet de réaliser des tests A/B ou de diminuer les effets des dérives. L’intégration vise les ingénieurs ML et les data scientists qui gèrent des données opérationnelles ou applicatives dans MongoDB. Elle intéressera probablement les acteurs du e-commerce et les institutions financières, entre autres.

De même, l’éditeur ajoute à nouveau des expressions d’agrégation de données en direction des développeurs (conversion de chaînes de caractères, de base numérique binaire, hexadécimale, etc., analyse native de JSON vers BSON et prise en charge des expressions régulières pour la manipulation de chaînes de caractères). Il s’agit de « éliminer le besoin de traitement côté client ou de solutions de contournement JavaScript dans les requêtes de base de données ».

Il vient également de lancer en disponibilité générale une connectivité interrégion pour les clusters de sa DbaaS Atlas déployée sur AWS. Le système s’appuie sur AWS PrivateLink.  

Quant à MongoDB 8.3, outre les nouvelles expressions d’agrégation, la majorité des fonctionnalités de cette mise à jour mineure porte sur des améliorations de performance. Par rapport à MongoDB 8.0, la version 8.3 permettrait de lire 45 % plus de données, d’en écrire 35 % de plus, de gérer 15 % de transactions ACID supplémentaires. Des performances à vérifier dans le monde réel. L’éditeur ne fait que tirer le fil des découvertes qui ont conduit aux optimisations de la version 8.0. La 8.3 corrige également trois CVE, dont une de sévérité High qui impliquait la possibilité de surcharger des instances combinant le traitement des séries chronologiques et les fichiers BSON.