MongoDB AI est une extension IA de la plateforme de données MongoDB qui permet aux développeurs de créer des applications de recherche sémantique et RAG directement sur des bases de données de documents via les fonctions Atlas Vector Search et IA.

MongoDBAI

Paramètres et statistiques de base de MongoDB AI

Le support principal de MongoDB AI est Atlas Vector Search : les capacités d'indexation et de récupération vectorielles intégrées sont superposées au modèle de document natif de MongoDB, de sorte que la même base de données puisse gérer simultanément des requêtes structurées et des recherches sémantiques. Il ne s'agit pas d'une base de données purement vectorielle, mais existe sous la forme de « base de données documentaire universelle + extension IA ». Pour les équipes qui disposent déjà d'actifs MongoDB, cela signifie qu'il n'est pas nécessaire d'exploiter et de maintenir en plus une base de données vectorielles indépendante lors de l'introduction des fonctionnalités d'IA.

Projets	Informations publiques
Positionnement officiel	Plateforme de données d'application IA
Composants de base	Recherche de vecteurs Atlas, recherche Atlas, fonctions IA, traitement de flux Atlas
Modèle de données	Type de document (JSON/BSON) + intégration vectorielle (float32/binary/quantized)
Type d'index vectoriel	ANN basé sur HNSW (Hierarchical Navigable Small World)
Limite de dimension d'index	4096 dimensions (Recherche de vecteurs Atlas)
Prise en charge du modèle intégré	OpenAI intégré, Amazon Bedrock, Cohere et personnalisation via les fonctions AI
Formulaire de déploiement	Hébergement multi-cloud (Atlas) : AWS, Azure, Google Cloud ; Auto-hébergement (Enterprise Advanced)
Portail	Pilote MongoDB, API Atlas Data, pipeline d'agrégation, intégration LangChain/LlamaIndex
Société mère	MongoDB Inc. (NASDAQ : MDB)
Capitalisation boursière de l'entreprise	Environ 30 milliards de dollars (2024)

Positionnement de MongoDB dans la piste de récupération de vecteurs : MongoDB n'est pas la base de données vectorielle la plus rapide (par rapport au moteur dédié de Pinecone), ni la moins chère (par rapport à l'auto-hébergement open source Chroma/Qdrant), mais son principal différenciateur est « l'élimination du mouvement des données ». Les développeurs n'ont pas besoin de copier les données métier dans une bibliothèque de vecteurs distincte et peuvent effectuer des requêtes hybrides de « filtrage des conditions métier + correspondance sémantique vectorielle » dans MongoDB. La valeur de cette intégration est particulièrement importante dans les scénarios RAG transactionnels avec des exigences élevées en matière de cohérence des données (comme les recommandations en temps réel pour les commandes de commerce électronique et les bases de connaissances du service client).

Utilisateurs et reconnaissance du marché de MongoDB AI

En tant que l'une des plus grandes bases de données de documents installées au monde, la validation par le marché de MongoDB de son expansion en matière d'IA se reflète davantage dans le taux d'adoption des fonctions d'IA par les entreprises clientes existantes plutôt que dans le nombre d'utilisateurs indépendants de produits d'IA.

Base de clients entreprises : MongoDB Atlas compte plus de 45 000 entreprises clientes dans le monde (en 2024), couvrant des secteurs tels que les services financiers, le commerce électronique, les jeux et l'Internet des objets. Recherche de vecteurs Atlas Depuis juin 2023 GA, plus de 2 000 index de recherche de vecteurs de qualité production ont été créés. MongoDB a officiellement révélé que le taux d'adoption de Vector Search avait augmenté d'un trimestre à l'autre, mais n'a pas divulgué le taux de conversion précis des fonctions d'IA d'entreprise.

Attitude de la communauté des développeurs : dans l'enquête auprès des développeurs Stack Overflow 2024, MongoDB s'est classé parmi les "bases de données les plus couramment utilisées" (premier dans la catégorie des bases de données de documents), et les développeurs ont une grande acceptation de ses fonctions d'IA (Recherche de vecteurs + Fonctions d'IA), en particulier les équipes qui sont déjà familiarisées avec le pipeline d'agrégation - la courbe d'apprentissage a été considérablement réduite. Cependant, au sein de la communauté des développeurs dont l'IA est l'objectif principal, la recherche vectorielle de MongoDB est souvent considérée comme « les équipes qui disposent déjà de MongoDB devraient donner la priorité » plutôt que le premier choix.

Rapports et analyse comparative du secteur : Gartner classe MongoDB comme leader dans le Magic Quadrant 2024 pour les systèmes de gestion de bases de données cloud. En termes de scénarios d'IA, sa solution Vector Search a été jugée « différenciante dans l'intégration des transactions générales et des charges de travail d'IA » dans l'évaluation de la plateforme de données d'IA de Forrester. Cependant, dans les références de bases de données vectorielles professionnelles (telles que ANN-Benchmarks), le QPS et le rappel de MongoDB sont généralement inférieurs à ceux des moteurs spécialisés tels que Pinecone et Weaviate - il s'agit d'un compromis inhérent à la capacité des bases de données à usage général à superposer des vecteurs.

Avantages financiers de MongoDB AI

L'analyse des coûts de MongoDB AI doit faire la distinction entre deux niveaux : « les dépenses existantes pour la base de données » et les « dépenses supplémentaires pour les fonctions d'IA ». C’est la différence essentielle entre sa structure de coûts et celle d’une base de données vectorielles indépendante.

Développeurs côté C/individuels : Atlas fournit un niveau sandbox M0 gratuit en permanence (512 Mo de stockage, processeur partagé), qui peut être utilisé pour apprendre MongoDB et créer des prototypes. Cependant, Vector Search nécessite le niveau M10 et supérieur (à partir d’environ 57 $/mois), ce qui signifie que les développeurs individuels ne peuvent pas bénéficier de la fonction de recherche vectorielle dans le niveau gratuit. Pour la vérification du prototype d'apprentissage, il est recommandé d'exécuter MongoDB Enterprise localement (licence de développement gratuite) et de compléter le PoC avec le modèle d'intégration open source.

Perspective API/développeur : Atlas est facturé en fonction des ressources du cluster. Les dimensions de facturation comprennent :

• Calcul : basé sur les spécifications de l'instance (M10/M20/M30/M40, etc.) et la durée d'exécution (facturée à l'heure).
• Stockage : en fonction du volume de données réel (Go/mois), les index vectoriels occupent un stockage supplémentaire (taille du vecteur intégré × 1,5 à 2 fois le facteur d'expansion de l'index).
• Transmission de données : Atlas facture le trafic sortant entre les régions et le trafic entrant au sein de la même région est gratuit.
• Fonctions IA : l'appel du modèle intégré intégré est facturé en fonction du nombre d'appels et du montant du jeton (transféré via l'infrastructure AWS/Azure).

Prenons l'exemple d'une application RAG de taille moyenne typique : le niveau M30 (2 processeurs virtuels, 8 Go de RAM, ~ 370 $/mois) peut héberger la récupération vectorielle d'un million d'enregistrements de documents (dimension intégrée 1 536, float32), avec un coût de stockage mensuel d'environ 100 à 200 $. Par rapport au coût de Pinecone d'environ 500 à 700 $/mois pour une échelle similaire, Atlas présente un avantage en termes de coût dans le scénario groupé « base de données + récupération de vecteurs » ; mais si vous n'avez besoin que de la fonction de récupération de vecteurs, Qdrant ou Chroma open source auto-hébergé peut fonctionner sur un VPS pour 50 à 100 $/mois.

Entreprise/Privé (Enterprise Advanced) : Payé par abonnement annuel, autorisé pour le nombre de nœuds, y compris la fonction principale de MongoDB Atlas Search et les fonctions de sécurité complètes. Les contrats au niveau de l'entreprise incluent généralement des garanties SLA d'assistance 24h/24 et 7j/7 et des gestionnaires de réussite client dédiés. La recherche de vecteurs est incluse dans Enterprise Advanced à partir de MongoDB 6.0 sans frais de licence supplémentaires. Les coûts cachés du déploiement privé comprennent : la main-d'œuvre d'exploitation et de maintenance des DBA (l'exploitation et la maintenance du cluster MongoDB sont plus complexes que les bases de données relationnelles), les ressources matérielles (la consommation de RAM des index vectoriels peut atteindre 2 à 3 fois la quantité de données) et les tests de compatibilité pour les mises à niveau de version.

Dimensions des coûts	Atlas sans serveur	Atlas dédié (M30)	Enterprise Advanced (auto-hébergé)
Échelle applicable	Développement/faible charge	Charge de production moyenne	Grande échelle/sensible à la conformité
Fourchette de frais mensuels	Paiement à l'utilisation, environ 0,10 à 0,30 $/heure	Environ 370$/mois	Contrat annuel, devis en fonction du nombre de nœuds
Recherche de vecteurs	Support (nécessite le niveau M10+)	Assistance	Prise en charge (6.0+)
Charge d'exploitation et de maintenance	Zéro opération et maintenance (entièrement géré)	Zéro opération et maintenance (entièrement géré)	Équipe DBA requise
Coûts cachés	Aucun	Aucun	Main d'œuvre d'exploitation et de maintenance + matériel + tests de mise à niveau

Principales fonctionnalités de MongoDB AI

MongoDB AI n'est pas une fonction unique, mais un ensemble de fonctionnalités qui fonctionnent ensemble à différents niveaux. L'idée principale est que ces fonctions constituent à elles seules des fonctionnalités standard de la base de données, mais lorsqu'elles sont combinées dans le pipeline d'agrégation, elles forment un concept de flux de travail qui « peut compléter l'inférence de l'IA sans quitter la base de données ».

• Atlas Vector Search : créez des index vectoriels (algorithme HNSW) sur les collections MongoDB standard, prenant en charge deux modes de recherche : KNN (k voisin le plus proche exact) et ANN (voisin le plus proche approximatif). Lien caché : peut être combiné avec des filtres de requête ordinaires ("$match,$geoNear`, etc.) dans la même étape du Pipeline pour obtenir une récupération mixte de "similitude sémantique + conditions commerciales" - par exemple, "trouver des magasins à moins de 5 kilomètres de l'utilisateur, avec des notes > 4,0 et une sémantique de description la plus proche de 'Quiet Cafe'". Cela élimine le problème de JOIN entre systèmes dans l'architecture traditionnelle de « les données commerciales sont dans MySQL, les vecteurs sont dans Pinecone et les résultats doivent être liés manuellement ».

• Fonctions IA ($$vectorize, etc.) : appelez des modèles intégrés directement dans le pipeline d'agrégation sans quitter la base de données ni écrire de code externe. $vectorize prend une valeur de champ ou une entrée utilisateur, appelle automatiquement le service d'intégration configuré (OpenAI text-embedding-3-*, Amazon Bedrock Titan Embeddings ou Cohere Embed) et renvoie un vecteur. Lien caché : Travailler avec $vectorSearch peut obtenir "une vectorisation automatique pendant l'écriture + une correspondance sémantique de bout en bout pendant l'interrogation". L'ensemble du processus est terminé dans un seul pipeline - lors de l'insertion, $vectorize convertit le texte en vecteurs et les stocke, et pendant l'interrogation, $vectorSearch effectue la récupération ANN sur l'index vectoriel. Ceci est très critique pour les scénarios qui nécessitent une indexation en temps réel de nouveaux contenus (tels que les enregistrements de conversations du service client, les lancements de produits).

• Atlas Search (recherche en texte intégral) : un moteur de recherche en texte intégral basé sur Apache Lucene qui prend en charge la segmentation des mots, la correspondance floue, l'expansion des synonymes et la notation personnalisée. Lien caché : combinaison de recherche hybride avec recherche vectorielle - utilisez d'abord $search (correspondance de texte intégral BM25) pour rappeler l'ensemble candidat, puis utilisez $vectorSearch pour effectuer un affinement sémantique dans l'ensemble candidat, ou vice versa. Cela résout le problème de précision insuffisante dans la récupération vectorielle pure sur des mots à haute fréquence (tels que les numéros de modèle et les noms).

• Atlas Stream Processing : traite les flux de données en temps réel à partir de Kafka ou MongoDB Change Streams, et peut effectuer une vectorisation et une récupération vectorielle sur les données du flux. Mises à jour en temps réel adaptées aux scénarios RAG en ligne : lorsque de nouveaux documents sont écrits dans la source de données, la vectorisation est automatiquement déclenchée et l'index est mis à jour sans qu'il soit nécessaire de recourir à des tâches de traitement par lots.

• Intégration LangChain / LlamaIndex : utilisez MongoDB comme backend de stockage vectoriel et de stockage de documents pour les applications LLM via les packages d'intégration officiels langchain-mongodb et llama-index-storage-mongodb. Les développeurs peuvent connecter MongoDB à la chaîne de recherche des frameworks RAG traditionnels avec seulement quelques lignes de code. Lien caché : Store (document + vecteur) et Retriever (récupération de vecteurs) utilisent le même cluster MongoDB pour éviter la synchronisation redondante des données.

• Graphiques Atlas et visualisation IA : grâce à la fonction de requête en langage naturel, les utilisateurs peuvent interroger et visualiser les données MongoDB en langage naturel, en s'appuyant sur les fonctions IA pour convertir le langage naturel en pipeline d'agrégation.

Modèle d'IA MongoDB et évolution des versions

L'évolution des capacités de MongoDB AI est profondément liée à l'itération des versions de la base de données MongoDB. Il n'y a pas de « numéro de version du modèle IA » indépendant, mais les fonctions IA sont progressivement intégrées avec la sortie des versions de MongoDB.

2023 : période fondamentale pour les capacités de l'IA

• MongoDB 6.0 (publié fin 2022, largement adopté en 2023) : introduction du chiffrement de la collection Time Series et des optimisations des flux de modifications. Cette version n'inclut pas encore la recherche vectorielle, mais elle ouvre la voie au cadre de stockage et d'indexation sous-jacent pour les fonctionnalités d'IA ultérieures.
• Aperçu public d'Atlas Vector Search (janvier 2023) : MongoDB publie son premier aperçu de Vector Search aux utilisateurs invités.
• Disponibilité générale d'Atlas Vector Search (juin 2023) : la recherche de vecteurs est officiellement GA, prenant en charge l'index HNSW, l'étape d'agrégation $vectorSearch et la récupération hybride $search.
• MongoDB 7.0 (août 2023) : introduit le cryptage interrogeable, améliore la stabilité du cluster fragmenté et intègre officiellement la gestion des index de recherche vectorielle dans la commande createSearchIndexes.

2024 : Fonctions d'IA et intégration approfondie

• MongoDB 7.1 (février 2024) : introduction d'une version expérimentale de AI Functions ("$vectorize`) qui permet d'appeler des modèles intégrés en externe dans les pipelines.
• MongoDB 7.2 (juin 2024) : AI Functions est officiellement GA, prenant en charge les services intégrés OpenAI, Amazon Bedrock et Cohere. Lancement également de l'intégration officielle de langchain-mongodb v1.0 et de LlamaIndex.
• Atlas Stream Processing GA (mai 2024) : prise en charge des workflows d'IA en temps réel.
• MongoDB 7.3 (novembre 2024) : optimise les performances de construction d'index vectoriels, prend en charge la quantification binaire (Binary Quantization) et réduit l'empreinte de stockage des index vectoriels d'environ 80 %.

2025-2026 : Platformisation de l'IA

• MongoDB 8.0 (publié mi-2025) : introduction de la prise en charge d'index multi-vecteurs pour les fonctions d'IA s'étendant à l'intégration d'images et aux points de terminaison d'intégration personnalisés. Atlas Search ajoute une étape de reclassement de recherche hybride (score hybride de « $searchMeta »).
• Atlas Connector for AI (fin 2025) : fournit des connecteurs prédéfinis aux principaux frameworks d'agents d'IA (LangGraph, CrewAI, AutoGen), et MongoDB peut être utilisé comme couche de mémoire de persistance et backend d'appel d'outils de l'agent d'IA.
• MongoDB AI Kubernetes Operator (début 2026) : fournit une mise à l'échelle automatique et un réchauffement d'index vectoriel pour les charges de travail d'IA sur Kubernetes.

Temps	Version MongoDB	Capacités liées à l'IA	Impact sur les développeurs
2023-06	Recherche de vecteurs Atlas GA	Index HNSW, $vectorSearch, recherche hybride	Aucune bibliothèque de vecteurs indépendante requise
2024-02 → 2024-06	7.1 (Exp) → 7.2 (GA)	Fonctions IA ($$vectorize)	Appelez directement le modèle intégré dans Pipeline
2024-11	7.3	Vecteurs quantifiés binaires	Réduction de 80 % du stockage de vecteurs
2025	8.0	Index multivecteur Rerank, connecteur Agent	Prise en charge des scénarios vectoriels composites
2026	Opérateur K8s	Expansion et contraction automatiques, échauffement de l'index	Déploiement de l'IA de production

Notes de version : Les dates de version et les fonctionnalités ci-dessus sont soumises à l'annonce de version officielle et aux notes de version de MongoDB. Le rythme de sortie de MongoDB est de 2 à 3 versions majeures par an (les versions impaires sont de nouvelles fonctionnalités, les versions paires sont LTS), et les fonctionnalités d'IA sont généralement introduites pour la première fois avec des versions impaires.

Avantages techniques de MongoDB AI

Les avantages techniques de MongoDB AI reposent sur l'architecture à trois couches « modèle de document + recherche vectorielle + pipeline unifié », plutôt que sur une avancée technologique unique.

Affinité naturelle du modèle de document et des vecteurs : le modèle de document de MongoDB permet de stocker les intégrations vectorielles directement dans les champs du document (tels que incorporation : [0.001, 0.005, ...]), dans le même document que les champs métier (product_name, price, category). Cela signifie que l'association de vecteurs avec des conditions scalaires est native et ne nécessite pas de tables d'association ou de mappages de clés supplémentaires. Par rapport à la solution « stockage de lignes + stockage de colonnes vectorielles » dans les bases de données relationnelles, la structure imbriquée du modèle de document peut réduire la quantité de code de requête associé de 30 à 50 %.

Moteur d'exécution de pipeline d'agrégation unifié : le pipeline d'agrégation de MongoDB est le véritable cadre d'exécution pour les fonctions d'IA. $vectorize (vectorisation), $vectorSearch (récupération de vecteurs), $search (recherche en texte intégral), $match (filtrage conditionnel) sont exécutés séquentiellement dans le même pipeline et le chemin d'exécution est planifié uniformément par l'optimiseur de requêtes MongoDB. Les bases de données vectorielles indépendantes telles que Pinecone nécessitent que les développeurs orchestrent manuellement le processus en trois étapes « récupération de vecteurs → obtention d'un identifiant → vérification de la base de données commerciale » au niveau de la couche d'application, tandis que MongoDB effectue toutes les opérations dans un pipeline. Les avantages de cette architecture intégrée sont plus évidents dans les scénarios sensibles aux délais (tels que les recommandations en temps réel, le service client en ligne) - éliminant 2 à 3 RTT inter-réseaux.

Détails de mise en œuvre de l'index HNSW : l'index vectoriel de MongoDB utilise une structure graphique hiérarchique navigable Small World, similaire à l'algorithme utilisé par d'autres bibliothèques vectorielles traditionnelles (Pinecone, Weaviate, Qdrant). MongoDB se différencie en intégrant l'index HNSW directement dans le sous-système d'index du moteur de stockage WiredTiger, plutôt que de maintenir un service d'index vectoriel distinct. Cela signifie que les écritures et les mises à jour de l'index vectoriel suivent les mécanismes de transaction et de réplication de MongoDB : les écritures dans l'index vectoriel sont automatiquement synchronisées avec les nœuds du jeu de réplicas sans configuration supplémentaire. Le prix est que la vitesse de construction des index vectoriels est généralement plus lente que celle des bibliothèques vectorielles indépendantes (car elle doit passer par la couche de transaction du moteur de stockage), et pour les scénarios d'écriture à haute fréquence, la surcharge de mise à jour de l'index peut affecter le débit d'écriture.

Quantification binaire : la technologie de quantification binaire introduite dans MongoDB 7.3 compresse le vecteur float32 (4 octets par dimension) en une représentation binaire (1 bit par dimension), réduisant ainsi l'empreinte de stockage à 1/32 de l'original. Pour une intégration OpenAI à 1 536 dimensions, le stockage d'origine est de 6 Ko/élément, et après quantification, il n'est que d'environ 190 octets/élément. La perte de précision est inférieure à 3 % dans les scénarios RAG typiques (Recall@10 diminue d'environ 1 à 3 %), mais le débit de récupération est amélioré de 4 à 6 fois. Pour la récupération vectorielle de très grandes collections (des dizaines de millions de documents), la quantification binaire est actuellement la technologie de base pour atteindre un coût abordable sur MongoDB.

Mécanisme de reclassement pour la recherche hybride : l'étape de reclassement de la recherche hybride introduite dans MongoDB 8.0 normalise et pondère les scores de récupération vectorielle (sémantique) et de recherche en texte intégral (mots clés). Grâce à l'algorithme Reciprocal Rank Fusion (RRF), un classement conjoint est possible sans s'appuyer sur les données d'entraînement. Dans la pratique, l'effet de recommandation de la recherche hybride est généralement 5 à 15 % meilleur que celui d'une méthode de recherche unique (mesurée par NDCG@10), en particulier dans les scénarios où le titre du document contient des termes professionnels précis (tels que le codage du diagnostic médical, le numéro de la clause légale), l'effet est considérablement amélioré.

Comment utiliser l'IA MongoDB

L'entrée d'utilisation de MongoDB AI couvre plusieurs niveaux, depuis les opérations visuelles de l'interface utilisateur Atlas jusqu'à la programmation du pipeline d'agrégation. Les développeurs peuvent choisir la méthode d'accès la plus adaptée en fonction de leurs propres scénarios.

Méthodes de saisie et d'intégration

Comment utiliser	Convient à la foule	Chemin d'accès	Étapes principales
Interface utilisateur de l'Atlas	Aucun codage requis	Connectez-vous à cloud.mongodb.com	Créer un cluster → Définir un index vectoriel → Appeler $vectorSearch dans Pipeline
Shell MongoDB/Pilotes	Développeur	mongosh ou pilote de langue	Créez des index à l'aide de la commande createSearchIndexes → Write Aggregation Pipeline
LangChain / LlamaIndex	Développeur d'applications IA	Package d'intégration Python	Connexion de configuration de la classe MongoDBAtlasVectorSearch → Se connecter à la chaîne en tant que Retriever
REST (API de données Atlas)	Front-end/mobile	Requête HTTPS	Appelez le point de terminaison de l'API de données et transmettez-le dans Pipeline JSON
Opérateur Kubernetes	DevOps	Graphique de barre / YAML	Déployer l'opérateur MongoDB AI → Configurer la mise à l'échelle automatique de la charge de travail AI

Démarrage rapide : implémentation de RAG à l'aide de LangChain

L'exemple suivant montre comment utiliser MongoDB Atlas comme backend de stockage vectoriel pour une application RAG via LangChain :

à partir de langchain_mongodb importer MongoDBAtlasVectorSearch
à partir de langchain_openai importer OpenAIEmbeddings
à partir de pymongo importer MongoClient

# 1. Connectez-vous au cluster Atlas
client = MongoClient("<ATLAS_CONNECTION_STRING>")
collection = client["demo_db"]["produits"]

# 2. Initialiser le modèle d'intégration et le stockage vectoriel
intégrations = OpenAIEmbeddings(model="text-embedding-3-small")
vector_store = MongoDBAtlasVectorSearch(
    collection=collection,
    intégration = intégrations,
    index_name="vecteur_index",
    text_key="description",
    embedding_key="intégration"
)

# 3. Récupération sémantique
résultats = vector_store.similarity_search(
    query="Sac à dos étanche adapté à une utilisation en extérieur",
    k=5,
    pre_filter={"price": {"$lte": 500}} # Combiné avec un filtrage scalaire
)

pour la doc dans les résultats :
    print(f"{doc.metadata['name']} : {doc.page_content[:100]}")

Description du paramètre clé : pre_filter consiste à filtrer conditionnellement les documents avant la récupération vectorielle. MongoDB prend en charge tous les opérateurs de requête standard (« $gte », « $lte », « $in », « $geoNear », etc.), ce qui constitue une capacité de différenciation clé par rapport aux bases de données vectorielles indépendantes.

Création et gestion d'index vectoriels

Les index vectoriels peuvent être créés dynamiquement via l'interface utilisateur d'Atlas ou la ligne de commande, éliminant ainsi le besoin de temps d'arrêt pour la reconstruction :

// Exemple de commande $createSearchIndexes (mongosh)
{
  "createSearchIndexes": "produits",
  "index": [{
    "name": "vecteur_index",
    "type": "vecteurRecherche",
    "définition": {
      "champs": [{
        "type": "vecteur",
        "path": "intégration",
        "numDimensions": 1536,
        "similarité": "cosinus",
        "quantization": "binary" // 7.3+ prend en charge la quantification binaire
      }]
    }
  }]
}

Limites et précautions des données (projet spécial RAG Data Center)

• Capacités de traitement de données non structurées : les capacités natives de MongoDB AI concernent les données texte structurées (chaînes de texte dans les champs de document JSON). Pour les données non structurées telles que les PDF numérisés, les tableaux en images et les documents manuscrits, MongoDB ne fournit pas de fonctionnalités OCR ou d'analyse de documents intégrées. Vous devez utiliser des services externes (tels que Azure AI Document Intelligence, AWS Textract) pour convertir le contenu non structuré en texte, puis l'écrire dans MongoDB et le vectoriser. Il s'agit d'un malentendu courant en matière de conception architecturale : les développeurs novices ont tendance à penser que MongoDB AI possède des capacités intégrées de compréhension des documents. En fait, il est uniquement responsable du stockage et de la récupération du « contenu vectorisé ».
• Traitement de documents longs : la taille d'un document unique MongoDB est limitée à 16 Mo. Pour les documents ultra longs (tels que les contrats juridiques, le texte intégral des articles de recherche scientifique), ils doivent être divisés en plusieurs documents et vectorisés séparément. « RecursiveCharacterTextSplitter » de LangChain est un outil de fractionnement couramment utilisé, mais la stratégie de fractionnement (taille des morceaux, chevauchement) affecte directement le taux de rappel de récupération.
• Rappel des points douloureux dans les scénarios mixtes multilingues : la recherche de texte de MongoDB ($search) est basée sur Lucene, et sa prise en charge de la segmentation des mots chinois repose sur l'analyseur lucene.standard. L'effet de segmentation fine des termes de domaine n'est pas aussi bon que celui du segmenteur de mots IK d'Elasticsearch. Dans les documents multilingues mixtes, il est recommandé de combiner la recherche vectorielle (sémantiquement indépendante de la langue) et la recherche en texte intégral (correspondance exacte à une langue spécifique). Pour les documents comportant des termes professionnels denses (tels que les rapports médicaux, les dispositions légales), le taux de rappel de la récupération vectorielle pure peut chuter de 10 à 20 %. Les solutions d'optimisation incluent : l'utilisation de la recherche hybride (pondération RRF), l'introduction d'un dictionnaire personnalisé ou le passage à un modèle d'intégration spécifique à un domaine (tel que BioBERT, Legal-BERT).
• Cohérence de l'index lorsque les documents sont fréquemment mis à jour : les plongements vectoriels correspondants ne sont pas automatiquement recalculés lorsque le document source est mis à jour. Les développeurs doivent concevoir un mécanisme de capture des données modifiées (CDC) - surveiller les modifications du document via Change Streams et déclencher « $vectorize » pour régénérer le fichier intégré.

Saisissez et mettez à jour l'index vectoriel. Dans les scénarios où CDC n'est pas implémenté, les intégrations vectorielles expirées empêcheront les résultats de récupération de correspondre au contenu réel du document, ce qui constitue le problème de fraîcheur des données le plus facilement négligé dans le système RAG.

• Conformité à la sécurité : MongoDB Atlas prend en charge le chiffrement au niveau du champ (Queryable Encryption), le journal d'audit RBAC (contrôle d'accès basé sur les rôles) et peut définir l'isolation des autorisations au niveau du document pour différentes équipes. Enterprise Advanced prend en charge le déploiement privé et répond aux exigences de souveraineté des données. Les contrats d'entreprise de MongoDB incluent souvent des clauses interdisant d'utiliser les données client pour la formation des modèles (confirmation écrite avant l'achat recommandée). En termes de certification de conformité, Atlas a satisfait aux normes SOC 2 Type II, ISO 27001, HIPAA et GDPR. La liste détaillée des certifications peut être trouvée sur la page de conformité officielle de MongoDB.

Prix des produits pour MongoDB AI

Le prix de MongoDB AI est facturé uniformément via la plateforme Atlas. La fonction IA elle-même n'est pas facturée séparément, mais sert d'extension aux capacités du cluster Atlas.

Niveau gratuit (M0) : 512 Mo de stockage, processeur virtuel partagé, adapté à l'apprentissage et au prototypage. Remarque : La recherche vectorielle et la recherche Atlas ne sont pas prises en charge au niveau M0 ; ces fonctionnalités nécessitent au moins le niveau M10.

Instance sans serveur : facturée en fonction de l'utilisation du calcul et du stockage, adaptée aux scénarios avec de fortes fluctuations de trafic. Le calcul est facturé en unités Atlas Compute (ACU) et le stockage est facturé en Go/mois. Le sans serveur ne prend pas en charge toutes les fonctions d'IA (telles que certains points de terminaison intégrés des fonctions d'IA). Il est recommandé de se référer à la documentation officielle de compatibilité.

Clusters dédiés : facturation fixe basée sur le niveau de l'instance (M10-M500), offrant une isolation des ressources et une stabilité des performances. Le surcoût des capacités IA correspond uniquement à l'espace de stockage occupé par l'index vectoriel (facturé en Go/mois). Voici les prix de référence pour les niveaux typiques :

Niveau	Processeur virtuel	RAM	Stockage (de base)	Frais mensuels (environ)	Scénarios d'IA applicables
M10	2	2 Go	10 Go	57 $	Petit PoC, récupération de vecteurs à faible concurrence
M30	2	8 Go	40 Go	370 $	Applications RAG de taille moyenne
M60	8	32 Go	400 Go	2 400 $	Applications d'IA de niveau production, haute simultanéité
M200	32	128 Go	1,5 To	9 600 $	Récupération de vecteurs à grande échelle + transactions à haut débit

Enterprise Advanced (cloud auto-hébergé/privé) : licence annuelle par nœud. Les tarifs sont disponibles auprès de l'équipe commerciale de MongoDB et sont basés sur le nombre de nœuds, l'architecture de déploiement (ensemble de réplicas/cluster partitionné) et le niveau de support. Les frais de licence annuels typiques pour les déploiements de taille moyenne à grande varient entre 50 000 $ et 500 000 $. Le coût explicite du modèle auto-hébergé est inférieur à celui d'un cluster Atlas de même spécification, mais les coûts implicites (exploitation et maintenance, matériel, tests de mise à niveau) doivent être inclus dans le calcul du TCO.

Cas de coût réel : Le catalogue de produits d'une application RAG de commerce électronique contient 500 000 articles. Chaque élément utilise un vecteur float32 de 1 536 dimensions (environ 6 Ko/élément) et le stockage de l'index vectoriel occupe environ 15 à 20 Go (y compris l'extension de l'index). Fonctionnant sur le niveau M30 (le niveau recommandé le plus bas compatible avec la récupération vectorielle), les frais mensuels sont d'environ 370 $ + stockage (base 40 Go + index vectoriel 20 Go ≈ 10 $ supplémentaires/mois), pour un total d'environ 380 $/mois. Par rapport à l'utilisation du p1 de Pinecone.

Scénarios d'application MongoDB AI

RAG de niveau entreprise : transformez les bases de connaissances internes en systèmes de questions-réponses IA

Stockez les documents de connaissances internes de l'entreprise (manuels de produits, spécifications techniques, documents de processus) dans MongoDB, mettez en œuvre la récupération sémantique via Atlas Vector Search et coopérez avec LLM pour générer des réponses précises. Différences par rapport à l'architecture RAG traditionnelle : MongoDB est à la fois un « stockage de documents » et un « stockage vectoriel ». La vectorisation est automatiquement déclenchée après la mise à jour des documents commerciaux et il n'y a aucun problème d'incohérence des données entre les deux bases de données. Conseil de mise en œuvre : les bases de connaissances internes de l'entreprise contiennent généralement un grand nombre de documents PDF et Office, qui nécessitent une analyse des documents et une extraction de texte via des services externes (tels que Unstructured.io ou Azure Document Intelligence) avant l'écriture. MongoDB lui-même ne fournit pas de fonctionnalités d'analyse de documents, ce qui est souvent négligé dans la conception architecturale. Il est recommandé de concevoir l'analyse, le déblocage, la vectorisation et l'écriture comme un pipeline ETL complet plutôt que comme une simple écriture en une seule étape.

Recherche sémantique et recommandation e-commerce

Créez un index vectoriel sur la collection de produits pour prendre en charge les recherches en langage naturel telles que « lampes de bureau aux couleurs douces et adaptées à un usage de bureau » et « chaussures de randonnée légères et résistantes à l'usure », en remplaçant la correspondance de mots clés traditionnelle. Avantage unique de MongoDB : les conditions scalaires telles que le prix du produit, l'inventaire et la zone de livraison se trouvent dans le même document que les vecteurs sémantiques. Une récupération mixte de « similarité sémantique + filtrage conditionnel + plage géographique » peut être effectuée en une seule requête sans avoir besoin d'appels inter-systèmes. Conseils de mise en œuvre : Les descriptions de produits des données e-commerce sont généralement des textes courts structurés (titre + attributs). Il est recommandé de fusionner le titre, la marque, la catégorie et les balises en « texte de récupération », puis de le vectoriser, au lieu de simplement opérer sur le champ de description. Les produits multilingues (par exemple, couvrant à la fois les descriptions en chinois et en anglais) doivent garantir que le modèle d'intégration prend en charge plusieurs langues, sinon le taux de rappel diminuera considérablement.

Couche mémoire de l'agent en temps réel

Les agents IA (construits via des frameworks tels que LangGraph et CrewAI) doivent conserver l'historique des conversations, les résultats intermédiaires et les préférences de l'utilisateur lors de l'exécution de tâches en plusieurs étapes. Grâce à son schéma flexible et à ses capacités de notification en temps réel des flux de modifications, MongoDB peut servir de « couche de mémoire à long terme » de l'agent : chaque étape de l'agent écrit l'état dans MongoDB, et les étapes suivantes obtiennent le contexte le plus récent via des flux de modifications ou des requêtes. Solution problématique : le stockage de session basé sur Redis peut facilement atteindre des goulots d'étranglement de conception clé-valeur lorsque les états d'agent sont complexes, tandis que le modèle de document de MongoDB peut naturellement exprimer des arborescences d'état d'agent imbriquées. Conseil de mise en œuvre : La fréquence d'écriture de la session de l'agent peut être très élevée (une écriture par étape), et le débit d'écriture et la surcharge de mise à jour de l'index vectoriel doivent être évalués. Pour les flux de travail d'agent à haute fréquence, il est recommandé d'utiliser des collections d'écriture indépendantes (sans index vectoriels) pour stocker l'état pur, et d'activer uniquement les index vectoriels sur les collections qui nécessitent une récupération sémantique.

Recommandations personnalisées en temps réel

Les données de comportement des utilisateurs (enregistrements de navigation, clics, achats) sont stockées dans MongoDB, et combinées à la similarité vectorielle (similarité entre « vecteur de séquence de comportement de l'utilisateur » et « vecteur de description du produit ») et aux règles de filtrage standards (préférence de catégorie, fourchette de prix), les résultats des recommandations sont générés en temps réel. La différence avec les systèmes de recommandation traditionnels est que MongoDB AI permet d'effectuer « la correspondance des vecteurs de caractéristiques comportementales + le filtrage des règles métier + la vérification de l'inventaire en temps réel » dans la même requête pour éviter de recommander des produits épuisés ou dont l'utilisateur ne veut pas.

Points clés de la vérification de la scène :

• Base de connaissances RAG : Comment les documents sont-ils traités ? (OCR/analyse externe → extraction de texte → chunking → vectorisation) ; Quelle est la précision de la récupération des termes chinois/professionnels ? (Il est recommandé d'activer la recherche hybride et d'ajuster le poids RRF).
• Recherche e-commerce : quel est l'effet de l'intégration de vecteurs lorsque les produits sont mélangés dans plusieurs langues ? (Assurez-vous que le modèle d'intégration couvre la langue cible) ; À quelle fréquence les produits sont-ils mis à jour ? (Envisagez la mise à l'échelle automatique des instances sans serveur dans les scénarios de mise à jour à haute fréquence).
• Couche mémoire de l'agent : la fréquence d'écriture de la session de l'agent et la fréquence de mise à jour de l'index vectoriel correspondent-elles ? (Envisagez un stockage séparé pour l'écriture d'état haute fréquence).
• Recommandation en temps réel : Comment gérer un problème de démarrage à froid ? (Lorsqu'il n'y a pas de données comportementales pour les nouveaux utilisateurs/nouveaux produits, elles peuvent être combinées avec une politique basée sur des règles ou une initialisation d'intégration de contenu).

Groupes applicables de MongoDB AI

• Équipe de développeurs MongoDB existante : il s'agit du groupe cible le plus naturel pour MongoDB AI. Les équipes utilisant déjà MongoDB peuvent ajouter des index vectoriels directement sur les collections existantes sans introduire de nouvelle base de données ou de nouveaux outils opérationnels. Valeur fondamentale : Zéro migration de données + zéro coût d'apprentissage (si l'équipe est déjà familiarisée avec le pipeline d'agrégation). Ne convient pas aux limites : si l'équipe n'a pas encore utilisé MongoDB, il n'est pas recommandé d'introduire MongoDB pour "AI" - le coût initial de l'apprentissage de MongoDB à partir de zéro et de la configuration d'un cluster (courbe d'apprentissage + configuration d'exploitation et de maintenance) peut être plus élevé que l'utilisation directe de Pinecone ou d'autres bibliothèques vectorielles dédiées.

• Ingénieur IA Full Stack et développeur d'applications RAG : ingénieurs back-end d'applications IA qui doivent gérer à la fois les données structurées et la récupération de vecteurs. MongoDB AI offre une expérience de développement « moins de commutation et moins de maintenance » : une base de données complète tout le travail de la couche de données. Valeur fondamentale : amélioration de l'efficacité du développement (réduire l'intégration et le débogage de 2-3 services externes). Limite inappropriée : dans les scénarios qui ont des exigences extrêmes en matière de latence de récupération de vecteurs (p99 < 10 ms) ou nécessitent des dizaines de milliers de QPS par seconde, les bases de données de vecteurs dédiées (Pinecone, Milvus) ont toujours un avantage de 3 à 10 fois en termes de débit de récupération de vecteurs purs.

• Entreprises d'applications d'IA qui exigent la conformité des données (finances, médecine, affaires gouvernementales) : MongoDB Enterprise Advanced prend en charge le déploiement privatisé et l'isolation intranet VPC. Combinée à l'appel de service intégré des fonctions IA, l'inférence IA peut être réalisée sans transmettre de données hors du réseau de l'entreprise. Valeur fondamentale : les données ne quittent pas le domaine + une plate-forme de données unique réduit la complexité de l'audit. Ne convient pas à la frontière : pour les entreprises qui utilisent déjà beaucoup de bases de données relationnelles et disposent de données hautement standardisées, l'introduction de MongoDB signifie augmenter la diversité de la pile technologique, ce qui n'est pas propice à la simplification de l'infrastructure.

• Équipe de prototypage rapide (Startup Hackathon) : les capacités de déploiement rapide d'Atlas (créer un cluster en 5 minutes) + l'intégration prête à l'emploi de LangChain font de MongoDB l'une des options de base de données les plus rapides pour le prototypage d'applications d'IA. Valeur fondamentale : le délai entre l'idée et la démo testable peut être compressé à 1 à 2 jours. Prérequis : Au moins une personne de l'équipe connaît les concepts de base de MongoDB (collections, documents, index), sinon le coût d'apprentissage initial engloutira l'avantage de vitesse du prototype.

Résumé et Outlook

Sous la forme d'une « base de données documentaire universelle + extension de recherche vectorielle », MongoDB AI offre aux utilisateurs MongoDB existants un moyen d'introduire des fonctionnalités d'IA à un coût de migration nul. Sa valeur fondamentale ne réside pas dans la seule performance de récupération de vecteurs (plus faible que les moteurs dédiés dans cette dimension), mais dans "l'élimination du mouvement des données" - l'intégration complète des données commerciales, l'intégration de vecteurs, la récupération sémantique et les appels LLM dans la même plateforme de données.

Principaux avantages actuels : L'affinité naturelle entre le modèle de document et l'intégration vectorielle, la récupération unifiée du mécanisme d'exécution unifié du pipeline d'agrégation, la recherche hybride (vecteur + texte intégral) et la quantification binaire réduisent considérablement les coûts d'indexation vectorielle. La clientèle des entreprises est énorme (plus de 45 000) et l’écosystème existant des administrateurs de bases de données et des développeurs peut être réutilisé.

Limitations actuelles majeures :

• Plafond de performances : Le QPS et la latence de récupération des vecteurs sont plus faibles que les bases de données vectorielles dédiées (Pinecone, Milvus). Pour les scénarios de récupération de vecteurs purs à haut débit et à faible latence (tels que la récupération d'images similaires à grande échelle), MongoDB n'est pas la solution optimale.
• Points aveugles du traitement des données non structurées : il ne fournit pas de capacités intégrées d'OCR et d'analyse de documents. Les données non structurées telles que les PDF et les images nécessitent un prétraitement de service externe, ce qui augmente la complexité de l'architecture.
• Précision de la segmentation des mots chinois : la segmentation des mots standard Lucene n'est pas efficace pour les termes de domaine, et les scénarios RAG chinois peuvent nécessiter une optimisation supplémentaire (dictionnaire personnalisé ou changement de modèle d'intégration).
• Limitation du niveau gratuit : Vector Search nécessite un niveau payant (M10+), et les développeurs individuels ne peuvent pas bénéficier des fonctions d'IA dans le niveau gratuit.

Points d'observation de suivi :

• Si MongoDB introduira des fonctionnalités intégrées d'analyse de documents (OCR/PDF) dans les futures versions pour réduire la dépendance à l'égard des services tiers.
• Si les performances des index vectoriels peuvent réduire l'écart avec les bibliothèques vectorielles dédiées dans les versions ultérieures (MongoDB 8.x/9.0) grâce à de nouveaux algorithmes d'index ou à une accélération matérielle.
• Si les fonctions d'IA seront étendues pour prendre en charge davantage de fournisseurs de modèles intégrés et de points de terminaison de modèles personnalisés, réduisant ainsi la dépendance à l'égard de fournisseurs de cloud spécifiques. -Si le niveau Atlas Serverless est entièrement compatible avec Vector Search, offrant des options de facturation flexibles et plus économiques pour les applications d'IA à trafic faible et moyen.

Évaluation des risques en matière d'approvisionnement et d'adoption :

• Pour les équipes disposant d'actifs MongoDB existants : l'adoption de MongoDB AI (avec la recherche vectorielle + les fonctions AI activées) présente un risque extrêmement faible : il s'agit simplement d'une extension de type index sur un cluster existant et n'implique pas de migration de données ni de modification de schéma. Il est recommandé d'effectuer d'abord une PoC sur les fonctions non essentielles (telles que la recherche assistée par la base de connaissances, la génération de candidats à la recommandation de produits), de vérifier que la précision de la récupération répond aux besoins de l'entreprise, puis de la promouvoir dans les processus principaux.
• Pour les équipes n'utilisant pas MongoDB : Il n'est pas recommandé d'introduire MongoDB pour la fonctionnalité « IA » comme premier facteur de décision. Vous devez d'abord évaluer si MongoDB, en tant que base de données à usage général, répond aux besoins structurels et transactionnels de l'entreprise, et si les capacités d'IA sont un plus plutôt que la principale raison d'achat. Si l'exigence principale de votre entreprise est la récupération de vecteurs, Pinecone, Qdrant ou Milvus peuvent présenter plus d'avantages en termes de coût total de possession et de performances.
• Dans tous les scénarios d'utilisation, les entreprises doivent se concentrer sur la vérification avant l'achat : si le SLA du contrat couvre les indicateurs de disponibilité et de latence de la récupération de vecteurs ; les données ne seront pas utilisées pour la formation secondaire de MongoDB ou de modèles tiers (les contrats d'entreprise MongoDB contiennent généralement des clauses de non-formation, et il est recommandé de confirmer par écrit avant d'acheter) ; la garantie de compatibilité de l'index vectoriel lors des mises à niveau de version (de MongoDB 7.0 à 7.3, la quantification binaire est rétrocompatible, mais il est recommandé de conserver au moins une fenêtre de test de compatibilité au sein d'une version majeure).

Informations de version

• MongoDB 8.0 ：Il n’y a pas encore de date officielle précise. （2026-06）
• MongoDB 7.3 ：Il n’y a pas encore de date officielle précise. （2025-12）