Architecture de base de données stratégique pour l’IA : unifiée par rapport à divisée

Principaux points à retenir :

• Une architecture unifiée réduit considérablement la complexité du développement en éliminant les défis de synchronisation entre des bases de données vectorielles et opérationnelles distinctes.

• La cohérence des données est garantie par des transactions atomiques dans les systèmes unifiés, ce qui évite les « documents fantômes » et d’autres défaillances liées aux architectures divisées.

• Le coût total de possession est généralement plus faible avec des architectures unifiées en raison de l’infrastructure consolidée et de la réduction de la charge de la maintenance.

• La vitesse de développement augmente avec les approches unifiées, car les équipes peuvent se concentrer sur la création de fonctionnalités plutôt que sur le code d’intégration et la gestion des erreurs.

• MongoDB Atlas offre des avantages de pérennisation grâce à des fonctionnalités d’IA intégrées telles que la recherche vectorielle, la quantification automatique et bien plus encore.

L’IA exige davantage des bases de données, et les décisions architecturales que les entreprises prennent aujourd’hui affectent directement leurs délais de mise sur le marché et leur avantage concurrentiel. À l’ère de l’IA générative, votre base de données doit prendre en charge à la fois des recherches vectorielles de haute dimension et des charges de travail transactionnelles rapides pour suivre le rythme des évolutions rapides des entreprises et des technologies.

Dans cet article, nous examinons les considérations architecturales que les responsables technologiques et les architectes doivent prendre en compte lors de la gestion des diverses exigences en matière de données des applications d’IA, notamment les intégrations vectorielles de haute dimension pour la recherche sémantique aux côtés des données opérationnelles traditionnelles (profils d’utilisateurs, métadonnées de contenu, etc.). Cette dichotomie présente deux approches architecturales distinctes, divisée comparée à unifiée, chacune ayant des conséquences significatives sur les performances et la cohérence de l’application et l’expérience du développeur.

Remarque : pour les responsables techniques qui souhaitent fournir des détails concrets à leurs équipes, ou qui ont besoin de preuves solides pour convaincre les développeurs sceptiques, nous avons publié un guide de mise en œuvre complet. Bien que cet article se concentre sur les considérations stratégiques, le guide explore les réalités au niveau du code que votre équipe de développement appréciera.

Pourquoi l’architecture des données est-elle importante ?

La création de produits et de fonctionnalités d’IA performants implique de penser à l’avance à la vitesse et le coût de l’intelligence à grande échelle. Que vous mettiez en œuvre une recherche sémantique pour une base de connaissances ou que vous utilisiez un moteur de recommandation en temps réel, votre architecture de base de données sous-tend la rapidité et la fiabilité avec lesquelles vous pouvez commercialiser ces fonctionnalités.

À l’ère de l’IA, le succès ne dépend plus uniquement d’algorithmes innovants : il est fondamentalement déterminé par la précision et la pertinence des résultats. Il s’agit d’un changement profond : l’architecture des données, autrefois reléguée aux services informatiques, est devenue une préoccupation stratégique pour chacun. Elle influence directement la vitesse à laquelle vos développeurs peuvent innover (vélocité de développement), la rapidité avec laquelle vous pouvez introduire de nouvelles fonctionnalités sur le marché (délai de commercialisation), et la fiabilité de vos systèmes dans des conditions réelles (fiabilité opérationnelle).

Par essence, votre architecture de données est devenue le socle sur lequel repose la réussite ou l’échec de toute votre stratégie d’IA. Votre architecture de données est votre socle de données.

Contrairement aux applications traditionnelles qui traitaient principalement des données structurées et des requêtes CRUD simples, les applications d’IA génèrent et interrogent des représentations vectorielles de données non structurées (telles que le texte, les images et l’audio) pour trouver des éléments « similaires ». Ces vecteurs sont souvent stockés dans des bases de données vecrorielles dédiées ou dans des moteurs de recherche optimisés pour la recherche de similarité. Dans le même temps, les applications ont toujours besoin de requêtes traditionnelles (recherches exactes, agrégations, transactions sur les données commerciales). Cela soulève une question d’architecture fondamentale clé :

Profitons de l’occasion pour aborder brièvement le concept de « base de données d’IA » apparu pour décrire un système qui prend en charge à la fois les charges de travail opérationnelles standard et les opérations spécifiques à l’IA telles que la recherche vectorielle. En bref, derrière les fonctionnalités de recherche par IA dans les applications d’IA modernes se cachent des techniques de recherche d’IA permises par des bases de données optimisées pour les charges de travail liées à l’IA.

Architecture divisée : intégration d’une base de données vectorielle séparée

Dans une architecture divisée, les opérations vectorielles et la gestion des données transactionnelles sont déléguées à des systèmes séparés et spécialisés. Une base de données polyvalente (p. ex., MongoDB, PostgreSQL) conserve les données opérationnelles, tandis qu’une base de données vectorielles dédiée (p. ex., Elasticsearch, Pinecone) gère les intégrations et les opérations de recherche de similarité. En apparence, cette approche « diviser pour régner » permet à chaque système de faire ce pour quoi il est le meilleur.

Le moteur de recherche ou la base de données vectorielles dédiée peut se spécialiser dans les requêtes de similarité vectorielle, tandis que la base de données opérationnelle gère les mises à jour et la persistance. Cela permet de tirer parti d’optimisations spécialisées dans chaque système, mais introduit des exigences de synchronisation entre les bases de données.

De nombreuses équipes d’IA ont mis en œuvre la recherche sémantique et d’autres fonctionnalités d’IA de cette manière, en utilisant un index vectoriel externe parallèlement à leur base de données d’application, les deux systèmes étant synchronisés par le biais d’un intergiciel personnalisé ou d’une logique au niveau de l’application.

Caractéristiques de l’architecture divisée :

• Systèmes spécialisés : chaque base de données est optimisée pour son rôle (par exemple, la base de données opérationnelle garantit des écritures rapides, des transactions ACID et des requêtes enrichies tandis que le moteur de recherche vectorielle fournit une recherche de similarité efficace à l’aide d’index comme HNSW pour la recherche approximative du plus proche voisin).

• Duplication des données : des intégrations vectorielles (et souvent certains identifiants ou métadonnées) sont dupliqués dans la base vectorielle. L’identifiant ou la clé principale existe dans les deux systèmes pour lier les résultats.

• Logique de synchronisation : l’application doit traiter la synchronisation. Pour chaque création/mise à jour/suppression d’un enregistrement, vous devez également mettre à jour ou supprimer l’entrée vectorielle correspondante dans l’index de recherche. Cela peut être effectué via des flux d’évènements, la captation de changements ou dans le code de l’application appelant deux systèmes.

• Interrogation de données : modèles de requête à plusieurs étapes nécessitant une coordination entre les systèmes

Pile exemple : un exemple consiste à utiliser MongoDB comme source d’information pour les documents produits, et Elasticsearch comme moteur de recherche vectorielle pour les intégrations de description de produits. L’application écrit dans MongoDB, puis indexe l’intégration dans Elasticsearch, et au moment de la requête, effectue une recherche vectorielle dans Elasticsearch, puis récupère le document complet depuis MongoDB par identifiant.

Ce modèle de système correspond à ce que nous dit un certain nombre d’équipes spécialisées dans l’IA qui exploitent MongoDB et... eh bien, à peu près tout ce qui promet d’accélérer le traitement des vecteurs.

C’est l’équivalent architectural du port simultané d’une ceinture et de bretelles : certes, votre pantalon ne tombera pas, mais vous déployez beaucoup d’efforts pour résoudre ce qui pourrait être un problème simple. Ces équipes finissent souvent par écrire plus de code de synchronisation que de fonctionnalités réelles, transformant ce qui devrait être une innovation en IA en un exercice de jonglage complexe de coordination de bases de données.

En laissant de côté les mesures de sécurité excessives, le point notable est que la division de l’architecture a un coût.

Vous disposez désormais de deux sources d’information qui doivent rester synchronisées. Chaque fois que vous ajoutez ou mettez à jour des données, vous devez indexer le vecteur dans le moteur de recherche. Chaque requête implique plusieurs allers-retours : un vers le service de recherche pour trouver les éléments pertinents, et un autre vers la base de données pour récupérer les informations complètes.

Cette complexité accrue peut ralentir le développement et introduire des points de défaillance potentiels. L’exploitation d’un système scindé introduit des défis, comme nous le verrons, concernant la cohérence (par ex. les « enregistrements fantômes » lorsque les deux systèmes ne sont plus synchronisés) et une complexité accrue dans le développement et la maintenance.

Dans les cas d’utilisation à très grande échelle ou à très faible latence (par exemple, plus d’1 milliard de vecteurs ou des SLA NN < 1 ms), un moteur vectoriel comme FAISS ou Milvus peut encore surpasser une base de données polyvalente en matière de débit de recherche de similarité brute. Cependant, les nœuds de recherche de MongoDB Atlas isolent les charges de travail de recherche vectorielle sur des instances distinctes et optimisées pour la mémoire, ce qui vous permet de répartir et de régler les performances de recherche indépendamment de vos nœuds de base de données, offrant ainsi souvent les garanties de faible latence requises par les applications d’IA modernes.

Architecture unifiée avec MongoDB Atlas : une seule plate-forme pour les données d'IA

Dans une architecture unifiée, une seule plate-forme de base de données gère à la fois les données opérationnelles et les fonctionnalités de recherche vectorielle. MongoDB Atlas Vector Search intègre l’indexation et la recherche vectorielles directement dans la base de données MongoDB.

Ce modèle architectural simplifie le modèle de données en stockant des intégrations aux côtés des données associées dans la même structure de document. Le système de base de données gère en interne l’indexation vectorielle (en utilisant des algorithmes comme HNSW) et offre des capacités de requête intégrées pour les modèles de données vectorielles et traditionnels.

En pratique, cela signifie que votre application peut exécuter une requête (vers MongoDB) qui filtre et trouve les données en fonction de la similitude vectorielle, sans avoir besoin d’un second système. Cela signifie que toutes les données (les documents de votre application et leurs représentations vectorielles) résident au même endroit, sous un même système transactionnel conforme ACID pour votre charge de travail d’IA.

Caractéristiques de l'architecture unifiée :

• Source unique d’information : les données brutes et les index vectoriels résident dans une seule base de données. Par exemple, MongoDB Atlas permet de stocker des champs vectoriels dans des documents et de les interroger avec des opérateurs de recherche vectorielle intégrés. Il n’est pas nécessaire de dupliquer ou de synchroniser les données entre différents systèmes.

• Opérations atomiques : les mises à jour d’un document et de son intégration vectorielle ont lieu en une seule transaction atomique ou une seule opération en écriture. Cela garantit une cohérence forte : votre index vectoriel ne peut pas s’écarter de vos données documentaires. Si une transaction échoue, aucune des modifications (ni du document ni de son intégration) n’est validée. Cela élimine les problèmes tels que les « documents fantômes » (définis ci-dessous), car il est impossible d’avoir une intégration sans le document correspondant dans la même base de données.

• Capacités de requête unifiées : le langage de requête (par ex. MQL de MongoDB) peut combiner des filtres traditionnels, la recherche en texte intégral et la recherche de similarité vectorielle en une seule requête. Cette capacité de recherche hybride signifie que vous pouvez, par exemple, trouver des documents où catégorie = « Tech » et où l’intégration est similaire à un vecteur de requête, le tout en une seule opération. Vous n’avez pas besoin d’effectuer deux requêtes dans des systèmes différents pour ensuite fusionner les résultats dans votre application.

• Simplicité opérationnelle : il n’y a qu’un seul système à gérer, sécuriser, dimensionner et surveiller. Dans une plate-forme cloud gérée comme MongoDB Atlas, vous obtenez un service entièrement géré qui prend en charge à la fois les charges de travail opérationnelles et vectorielles, souvent avec des fonctionnalités pour optimiser chacune d’entre elles (par exemple, des « nœuds de recherche » dédiés qui traitent l’indexation et les requêtes de recherche afin que les recherches vectorielles lourdes n’affectent pas les performances de la charge de travail transactionnelle).

MongoDB Atlas intègre un moteur de recherche vectorielle Atlas (basé sur Apache Lucene, la même technologie utilisée dans certains moteurs de recherche vectoriels dédiés) directement dans la base de données. Cela permet aux développeurs de stocker des vecteurs de haute dimension dans des documents et d’effectuer des recherches de similarité à l’aide d’index optimisés par des algorithmes tels que HNSW (graphiques Hierarchical Navigable Small World) pour la recherche approximative du plus proche voisin (ANN).

Des fonctionnalités supplémentaires telles que la quantification
vectorielle (pour compresser les vecteurs afin d’optimiser l’efficacité) et la recherche hybride (combinant recherche vectorielle et recherche textuelle) sont prises en charge nativement et construites avec le langage de requête MongoDB (MQL).

Tout cela se produit sous l’égide du moteur de transaction et de l’architecture de sécurité de la base de données MongoDB Atlas. En bref, l’approche unifiée vise à offrir le meilleur des deux mondes : la richesse fonctionnelle d’une base vectorielle spécialisée et la fiabilité/cohérence d’une banque de données opérationnelle unique.

Un enjeu stratégique pour les décideurs

Pour les responsables techniques qui gèrent à la fois l’innovation et les budgets, l’approche unifiée présente un argument financier convaincant parallèlement à ses mérites techniques.

Si votre entreprise utilise déjà MongoDB comme base de données opérationnelle, comme le font des milliers d’entreprises dans le monde, le chemin vers l’activation de l’IA devient remarquablement fluide. Plutôt que d’allouer un budget à un tout nouveau système de base de données vectorielle, avec tous les coûts associés de licence, d’infrastructure et de personnel, vous pouvez étendre votre investissement MongoDB existant pour traiter les charges de travail vectorielles.

Vos équipes comprennent déjà l’architecture, le modèle de sécurité et les caractéristiques opérationnelles de MongoDB. L’ajout de capacités vectorielles devient une acquisition de compétences progressive plutôt qu’une courbe d’apprentissage abrupte pour un système entièrement nouveau. Pour les projets déjà en cours, la migration de données vectorielles ou la génération de nouvelles intégrations au sein de votre infrastructure MongoDB existante peut être réalisée sans perturber les opérations en cours.

Aperçu technique de l’architecture divisée par rapport à l’architecture unifiée

Pour illustrer les implications pratiques de chaque architecture, observons les considérations opérationnelles et de mise en œuvre de haut niveau pour une application de réponse aux questions basée sur une base de connaissances. Les deux approches permettent la recherche de similarité vectorielle, mais présentent des différences notables en termes de complexité de mise en œuvre et de garanties de cohérence.

Dans une architecture divisée (par exemple, en utilisant MongoDB + Elasticsearch) : nous stockons le contenu de l’article et ses métadonnées dans MongoDB, et nous conservons les vecteurs d’intégration dans un index Elasticsearch. Au moment de la requête, nous interrogerons l’index Elasticsearch par similarité vectorielle pour obtenir une liste des meilleurs identifiants d’article, puis nous récupérerons ces articles à partir de MongoDB par leurs identifiants.

Il existe plusieurs opérations clés dans une architecture à deux bases de données :

• Création : lors de la création de documents, l’application doit coordonner les insertions entre les deux systèmes. Tout d’abord, le document est conservée dans MongoDB, puis son intégration vectorielle est générée et conservée dans Elasticsearch. Si l’une ou l’autre opération échoue, une logique de restauration manuelle est nécessaire pour maintenir la cohérence. Par exemple, si l’insertion dans MongoDB réussit mais que l’indexation dans Elasticsearch échoue, les développeurs doivent mettre en oeuvre un code de nettoyage personnalisé pour supprimer le document MongoDB orphelin.

• Lecture : la recherche vectorielle devient un processus en plusieurs étapes dans une architecture divisée. L’application interroge d’abord Elasticsearch pour trouver des vecteurs similaires, récupère uniquement les identifiants des documents, puis effectue un deuxième aller-retour vers MongoDB pour récupérer les documents complets correspondant à ces identifiants. Cela introduit une latence réseau supplémentaire et nécessite une gestion des erreurs pour les cas où des documents existent dans un système mais pas dans l’autre.

• Mise à jour : La mise à jour de contenu présente des défis de synchronisation importants. Après avoir mis à jour un document dans MongoDB, l'application doit également mettre à jour le vecteur correspondant dans Elasticsearch. Si la mise à jour d'Elasticsearch échoue après la réussite de la mise à jour de MongoDB, les systèmes sont désynchronisés et la recherche vectorielle renvoie des résultats obsolètes ou incorrects. Il n'y a pas de transaction atomique couvrant les deux systèmes, ce qui nécessite des mécanismes de récupération complexes.

• Suppression : les opérations de suppression font face à des problèmes de synchronisation similaires. Lorsqu’un document est supprimé de MongoDB mais que la suppression correspondante dans Elasticsearch échoue, des « documents fantômes » apparaissent dans les résultats de recherche (des vecteurs pointant vers des documents qui n’existent plus). Les utilisateurs reçoivent des résultats de recherche auxquels ils ne peuvent pas accéder, ce qui crée une expérience déroutante et des problèmes de sécurité potentiels si des informations sensibles restent indirectement accessibles via le contenu de prévisualisation conservé dans Elasticsearch.

Chacune de ces opérations nécessite une gestion rigoureuse des erreurs, des mécanismes de nouvelle tentative, des systèmes de surveillance et des processus de rapprochement en arrière-plan afin de maintenir la cohérence entre les deux bases de données. Et surtout, la complexité s'accroît avec le temps, les problèmes de synchronisation devenant plus difficiles à détecter et à résoudre à mesure que le volume de données augmente, ce qui finit par affecter la productivité des développeurs et l'expérience des utilisateurs.

Dans une architecture unifiée (utilisant MongoDB Atlas Vector Search) : nous stockons à la fois les données de l’article et son vecteur d’intégration dans un seul document MongoDB. Un index Atlas Vector Search sur le champ d’intégration nous permet d’effectuer une recherche de similarité directement dans MongoDB à l’aide d’une seule requête. La base de données utilisera en interne l’index vectoriel pour trouver les voisins les plus proches et renvoyer les documents.

Voyons comment les mêmes opérations sont considérablement simplifiées dans une architecture unifiée :

• Création : la création d’un document devient une opération atomique. L’application stocke à la fois le document et son intégration de vecteur dans un seul document MongoDB grâce à une opération d’insertion. Soit le document entier (avec son intégration) est bien stocké, soit rien n’est stocké du tout. Il n’y a pas besoin de logique de restauration personnalisée ou de code de nettoyage puisque les garanties transactionnelles de MongoDB assurent l’intégrité des données sans code d’application supplémentaire.

• Lecture : la recherche vectorielle est simplifiée en une seule étape. En utilisant le pipeline d’agrégation de MongoDB avec Atlas Vector Search, l’application interroge des vecteurs similaires et récupère les documents complets en un seul aller-retour. Il n’est pas nécessaire de coordonner des systèmes distincts ou de traiter les incohérences, car la recherche vectorielle est directement intégrée à la récupération des documents, ce qui réduit considérablement la latence et la complexité du code.

• Mise à jour : les mises à jour de documents maintiennent une cohérence parfaite. Lors de la mise à jour du contenu d’un document, l’application peut mettre à jour de manière atomique à la fois le document et son intégration vectorielle en une seule opération. Les garanties transactionnelles de MongoDB assurent que les deux sont mis à jour ou qu’aucun ne l’est, éliminant ainsi la possibilité de représentations de données désynchronisées. Les développeurs n’ont plus besoin de mettre en oeuvre des mécanismes de récupération complexes en cas de défaillances partielles.

• Suppression : le problème des documents fantômes disparaît complètement. Lorsqu’un document est supprimé, son intégration vectorielle est automatiquement supprimée, car ils existent dans le même document. Il n’y a aucune possibilité de vecteurs orphelins ou de résultats de recherche incohérents. Cela garantit que les résultats de la recherche reflètent toujours l’état actuel de la base de données, améliorant ainsi la fiabilité et la sécurité.

Cette approche unifiée élimine toute la catégorie des défis de synchronisation inhérents aux architectures divisées. Les développeurs peuvent se concentrer sur la création de fonctionnalités plutôt que sur les mécanismes de synchronisation, les outils de surveillance et les processus de récupération. Le système s'adapte naturellement sans augmenter la complexité, en maintenant des performances et une fiabilité constantes, même à mesure que les volumes de données augmentent. Au-delà des avantages techniques, cela se traduit par des cycles de développement plus rapides, des applications plus fiables et, en fin de compte, une meilleure expérience pour les utilisateurs finaux qui obtiennent des résultats de recherche toujours précis.

La recherche vectorielle et la récupération de documents s'effectuent en un seul aller-retour vers la base de données, ce qui transforme fondamentalement les caractéristiques de performance et la simplicité opérationnelle des applications basées sur l'IA.

Synchronisation des données : défis et « documents fantômes »

L’un des plus grands défis de l’architecture divisée est la synchronisation des données. Comme il existe deux sources d’information (la base de données opérationnelle et l’index vectoriel), toute modification des données doit être répercutée aux deux. En pratique, une synchronisation parfaite est difficile : des problèmes de réseau, des bogues ou des défaillances de traitement peuvent entraîner la mise à jour d’une base et pas de l’autre. Cela peut entraîner des incohérences difficiles à détecter et à résoudre.

Un exemple courant dans une configuration divisée est le scénario du « document fantôme ». Un document fantôme fait référence à une situation où la recherche vectorielle renvoie une référence à un document qui n’existe plus (ou ne répond plus aux critères) dans la base de données principale.

Par exemple, supposons qu’un article ait été supprimé ou marqué comme privé dans MongoDB, mais que son intégration n’ait pas été supprimée d’Elasticsearch. Une recherche vectorielle pourrait toujours récupérer son identifiant comme résultat principal, ce qui amènerait votre application à tenter de récupérer un document qui n’est pas présent ou qui ne devrait pas être affiché. Du point de vue de l’utilisateur, cela pourrait faire apparaître un résultat corrompu ou obsolète.

Revenons à notre scénario pratique précédent : imaginez un système de base de connaissances pour l’assistance client où les articles sont constamment mis à jour et parfois supprimés lorsqu’ils deviennent obsolètes. Quand un agent d’assistance supprime un article concernant un produit arrêté, la suppression s’effectue bien dans MongoDB, mais à cause d’un délai d’attente du réseau, la suppression correspondante du vecteur dans Elasticsearch échoue. Oui, cela arrive, surtout avec des applications traitant quotidiennement des millions de requêtes.

Par la suite, lorsqu’un client recherche des solutions liées à ce produit arrêté, la recherche vectorielle dans Elasticsearch identifie l’article supprimé comme étant très pertinent et renvoie son identifiant. Lorsque l’application tente d’extraire le contenu complet de MongoDB à l’aide de cet identifiant, elle découvre que le document n’existe plus.

Le client voit un lien rompu ou un message d'erreur au lieu d'un contenu utile, ce qui crée une expérience déroutante et frustrante.

Ce qui est particulièrement insidieux dans ce problème, c’est qu’il peut se manifester de diverses manières dans l’ensemble de l’application. Au-delà des problèmes de suppression complète des documents, vous pouvez rencontrer les problèmes suivants :

• Intégrations obsolètes : un document est mis à jour dans MongoDB avec un nouveau contenu, mais le vecteur dans Elasticsearch représente toujours l’ancienne version, ce qui entraîne des résultats de recherche qui ne correspondent pas au contenu réel.

• Incohérences des autorisations : les autorisations d’accès d’un document sont modifiées dans MongoDB (par exemple, de public à privé), mais il apparaît toujours dans les résultats de recherche vectorielle pour les utilisateurs qui ne devraient pas y accéder.

• Mises à jour partielles : seuls certains champs sont mis à jour dans les systèmes, ce qui entraîne une inadéquation des métadonnées entre ce qui est affiché dans les aperçus de recherche et le document réel.

Dans les environnements de production, les équipes de développement ont souvent recours à la mise en œuvre de solutions de contournement complexes pour atténuer ces problèmes de synchronisation :

1. Travaux de rapprochement en arrière-plan qui comparent périodiquement les documents entre les deux systèmes et réparent les incohérences

2. Modèles de boîte d’envoi dans lesquels les opérations sont enregistrées dans un stockage séparé et renouvelées jusqu'à ce qu’elles soient réussies.

3. Systèmes de surveillance personnalisés spécifiquement conçus pour détecter et signaler les incohérences entre les bases de données

4. Processus d’intervention manuelle pour les équipes d’assistance afin de traiter les écarts signalés par les utilisateurs

Tous ces mécanismes représentent un effort de développement important qui pourrait autrement être consacré à la création de fonctionnalités apportant une réelle valeur ajoutée à l'entreprise. Ils introduisent également des points de défaillance supplémentaires et une complexité opérationnelle.

Plus important encore, une architecture unifiée évite entièrement ce type de problème. Comme il n’y a qu’une seule base de données, un document supprimé est automatiquement retiré de tous les index associés au sein de la même transaction. Un modèle de données unifié rend relativement impossible l’existence d’un vecteur sans son document, car ils ne font qu'un et sont conservés dans le même document. En conséquence, les problèmes tels que les documents fantômes, les références vectorielles obsolètes ou la nécessité de mettre à jour deux banques de données disparaissent tout simplement.

Compromis et points à prendre en compte

Il existe plusieurs compromis clés que vous devez évaluer lorsque vous comparez les architectures divisées et unifiées pour les données d’IA. Comme nous l’avons déjà mentionné, votre choix affectera la complexité du système, les caractéristiques de performance, l’évolutivité, le coût et l’agilité de développement. Pour les responsables de projets d’IA et les dirigeants d’entreprises d’IA, il est essentiel de comprendre ces aspects. En voici quelques-uns :

Complexité du système par rapport à la cohérence des données : le maintien de la cohérence dans une configuration divisée nécessite une logique supplémentaire et accroît la complexité du système. Chaque élément de données est effectivement traité deux fois, ce qui introduit des risques d’incohérence et des modes de défaillance complexes. Dans une architecture unifiée, les transactions ACID garantissent que les mises à jour des données et de leur vecteur d’intégration se produisent ensemble ou pas du tout, simplifiant ainsi la conception et réduisant le code de traitement des erreurs personnalisé.

Coûts opérationnels comparés à la performance : une architecture divisée peut tirer parti de moteurs spécialisés optimisés pour les requêtes de similitude, mais introduit une latence de réseau avec plusieurs allers-retours et augmente les coûts opérationnels avec deux systèmes à surveiller. Les architectures unifiées éliminent les sauts réseau supplémentaires, ce qui peut réduire la latence des requêtes. MongoDB Atlas propose des optimisations comme la quantification vectorielle et des nœuds de traitement de recherche dédiés qui peuvent égaler ou dépasser les performances de moteurs de recherche distincts.

Évolutivité comparée à la rentabilité : les architectures divisées permettent une mise à l’échelle indépendante des composants, mais entraînent une duplication des coûts d’infrastructure et une redondance des données. Une architecture unifiée consolide les ressources tout en permettant l’isolation des charges de travail grâce à des fonctionnalités telles que les noeuds de recherche Atlas. Cela simplifie la planification des capacités et permet d’éviter la création redondante de plusieurs systèmes.

Charge de la maintenance comparée à productivité des développeurs : les architectures divisées nécessitent un « code de liaison » substantiel pour l’intégration, les doubles écritures et la synchronisation, ce qui ralentit le développement et complique les modifications de schéma. Les architectures unifiées permettent aux développeurs de se concentrer sur la logique applicative avec moins d’éléments mobiles et un langage de requête unique, ce qui peut accélérer la mise sur le marché des fonctionnalités d’IA.

Pérennisation : des architectures unifiées simples facilitent et accélèrent l’adoption de nouvelles capacités à mesure que la technologie d’IA évolue. Les systèmes divisés accumulent de la dette technique à chaque mise à niveau de composant, tandis que les plate-formes unifiées peuvent intégrer de nouvelles fonctionnalités de manière transparente sans avoir à reconcevoir les points d’intégration.

Bien que certaines entreprises puissent choisir au départ une approche divisée en raison de systèmes existants ou d’exigences spécialisées, l’architecture unifiée de MongoDB avec Atlas Vector Search répond désormais à bon nombre des raisons historiques qui justifiaient l’utilisation de moteurs de recherche distincts, en proposant des capacités de recherche hybride, des options de précision et des outils d’optimisation dans un environnement de base de données unique.

Choisir la bonne architecture pour les charges de travail d'IA

Quand devriez-vous opter pour une architecture divisée et quand une architecture unifiée est-elle plus judicieuse ? La réponse dépend en définitive de vos exigences et contraintes spécifiques.

Envisagez une architecture divisée si vous disposez déjà d’une infrastructure importante construite autour d’une base de données de recherche ou vectorielle spécialisée et qu’elle répond à vos besoins. Dans certains cas, les applications de recherche à très grande échelle peuvent être profondément optimisées sur un moteur distinct, ou les exigences réglementaires peuvent imposer des bases séparées pour les données.

Une approche divisée peut également être judicieuse si un type de charge de travail dépasse largement l’autre (par exemple, vous effectuez des recherches vectorielles sur des milliards d’éléments, mais vous avez des opérations transactionnelles relativement légères, bien que, même dans ce cas, une solution unifiée avec la bonne indexation puisse gérer une échelle surprenante).

Préparez-vous simplement à investir dans les outils et les efforts d’ingénierie nécessaires pour maintenir l’harmonie entre les deux systèmes. Si vous choisissez cette voie, concevez soigneusement vos processus de synchronisation et envisagez d’utiliser des flux de modification ou des bus d’évènements pour propager les modifications de manière fiable. Évaluez également le coût opérationnel : maintenir une expertise sur deux plate-formes et assurer l’intégration entre elles n’est pas une mince affaire.

Envisagez une architecture unifiée si vous développez une nouvelle application alimentée par l'IA ou modernisez une application existante, et que vous souhaitez simplicité, cohérence et rapidité de développement. Si éviter les écueils de la synchronisation des données et réduire la complexité opérationnelle sont des priorités, l'architecture unifiée est un excellent choix.

Une plate-forme unifiée excelle lorsque votre application nécessite une intégration étroite entre les données opérationnelles et vectorielles, par exemple pour effectuer une recherche sémantique avec des filtres d’exécution sur les métadonnées, ou pour mettre à jour du contenu et le refléter immédiatement dans les résultats de recherche.

Avec une solution comme la plate-forme de données moderne de MongoDB, vous bénéficiez d’une base de données entièrement gérée et prête pour le cloud qui permet de traiter à la fois vos besoins en applications en ligne et vos besoins en recherche par IA au sein d’un seul et même système. Cela permet des cycles de développement plus rapides (car votre équipe peut travailler avec un seul système et un seul langage de requête) et une plus grande certitude que vos résultats de recherche reflètent l’état actuel de vos données à tout moment.

En se tournant vers l’avenir, une architecture unifiée constitue sans doute l’approche la plus pérenne. Les capacités d’IA évoluent à un rythme accéléré,ainsi, centraliser vos données vous permet de tirer parti immédiatement des nouvelles fonctionnalités.

Nous travaillons avec des clients spécialisés dans l’IA qui créent des applications d’IA sophistiquées, et une observation clé est l’exigence de rationaliser les opérations de traitement des données au sein des applications d’IA qui exploitent des pipelines de génération augmentée de récupération ou l’IA agentique. Les opérations critiques comprennent la segmentation, la génération d’intégrations, l’opération de recherche vectorielle et le reclassement.

Nous avons également intégré les modèles d’intégration et de reclassement de pointe de Voyage AI à MongoDB. Bientôt, ces modèles seront hébergés au sein de MongoDB Atlas pour permettre la conversion d’objets de données en intégrations, ainsi que l’application d’une couche supplémentaire de gestion des données dans les pipelines de recherche, le tout au sein de MongoDB Atlas. Cette étape constitue l’un des moyens clés par lesquels MongoDB continue d’apporter de l’intelligence à la couche de données et de créer un socle de données véritablement intelligent pour les applications d’IA.

La plate-forme Atlas de MongoDB continue d’élargir ses fonctionnalités axées sur l’IA, des améliorations de la recherche vectorielle à l’intégration aux flux de données et aux analyses en temps réel, tout en garantissant que les garanties de la base de données centrale (comme les transactions ACID et la haute disponibilité) restent solides. Cela signifie que vous n’avez pas besoin de restructurer votre couche de données pour adopter la prochaine grande avancée de l’IA : votre plate-forme existante se développe pour la prendre en charge.

Il est compréhensible que le débat entre architecture divisée et unifiée soit un exemple classique d’équilibre entre spécialisation et simplicité. Les systèmes divisés peuvent offrir les meilleurs composants pour chaque tâche, mais au prix d’une complexité et d’une incohérence potentielle. Les systèmes unifiés offrent élégance et facilité, regroupant les fonctionnalités en un seul endroit, et ont rapidement comblé l’écart en termes de fonctionnalités et de performances.

Terminons sur ce point : MongoDB a été conçu pour le changement, et c’est exactement ce dont les entreprises ont besoin pour surnager dans le bouleversement causé par l’intelligence artificielle. En consolidant votre infrastructure de données et en adoptant des technologies qui unifient les capacités, vous pouvez offrir à vos équipes la liberté d’expérimenter et la confiance nécessaire pour exécuter les projets. L’avenir pourrait appartenir à ceux qui sauront exploiter conjointement l’IA et les données de manière fluide. Il est temps d’évaluer votre propre architecture et de vous assurer qu’elle vous permet de gérer les bouleversements causés par l’IA, sans être emporté par celle-ci.