La pile RAG que les développeurs utilisent réellement

Les systèmes RAG semblent magiques jusqu'à ce qu'ils répondent avec confiance à la mauvaise question. La plupart des échecs peuvent être attribués à un seul coupable : la recherche sémantique pure. Vous intégrez vos documents, exécutez une requête de similarité vectorielle et espérez que le fragment le plus proche contienne le fait exact dont vous avez besoin. Trop souvent, ce n'est pas le cas.

Les modèles d'incorporation excellent dans la signification floue, pas dans la précision chirurgicale. Ils compressent des paragraphes en vecteurs de 768 ou 1 536 dimensions qui mettent en avant des concepts de haut niveau plutôt que des tokens exacts. Ce compromis signifie qu'ils floutent régulièrement des détails comme les numéros de pièce, les dates, les citations juridiques et les noms de fonctions dans des "quartiers suffisamment similaires".

Demandez à une pile RAG typique : « Quel était notre revenu en 2025 ? » et regardez-la halluciner avec confiance. L'encodage de cette question se situe très près de fragments discutant de « revenu en 2023 » ou « revenu projeté sur les trois prochaines années ». La similarité sémantique indique que ces informations sont quasiment identiques ; votre système retourne avec enthousiasme les chiffres de 2023 comme s'ils provenaient de 2025.

Ce comportement n'est pas un bug dans les embeddings ; c'est la conception. Les modèles entraînés sur du texte général s'optimisent pour l'alignement conceptuel : « croissance des revenus en 2023 » et « prévision des revenus pour 2025 » partagent la plupart de leurs signaux. Le modèle considère l'année comme un détail mineur, même si pour la finance, le droit ou l'ingénierie, l'année est souvent la réponse.

Le même mode de défaillance touche d'autres requêtes à haute précision. Demandez : - « Section 3.2.1 du contrat » - « Code d'erreur 0x80070005 » - « fonction init_user_session dans auth.py »

Une recherche sémantique pure fait souvent ressortir des concepts voisins—« clause de résiliation », « erreurs d'accès refusé sous Windows », « initialisation de session utilisateur »—au lieu de la clause exacte, du code d'erreur ou de la définition de fonction dont vous avez réellement besoin.

Les équipes d'entreprise ressentent cela de manière aiguë. Les outils de conformité doivent distinguer le §230 du §320. Les copilotes de support doivent différencier le SKU-AX12B du SKU-AX21B. Les bots d'ingénierie internes ne doivent pas mélanger les notes de version v1.2.3 et v1.3.2. Un seul chiffre échangé peut signifier un produit, un statut ou une API différent.

Problème central : les systèmes RAG poursuivent la compréhension conceptuelle tout en sous-investissant dans la précision. Sans mécanismes respectant les chaînes exactes, les nombres et les identifiants, votre « assistant de connaissances » agit davantage comme un correcteur de texte subjectif que comme un système de récupération fiable.

La recherche hybride corrige discrètement la plupart des problèmes de la RAG naïve. Au lieu de parier tout sur des embeddings flous ou de s'accrocher à des filtres Microsoft Word fragiles, elle exécute une recherche sémantique et une recherche par mots clés Microsoft Word ensemble sur chaque requête, puis fusionne les résultats. Vous obtenez une compréhension conceptuelle et une correspondance littérale des chaînes en un seul passage.

La recherche sémantique excelle à « trouvez-moi des choses comme ça », même si la formulation dans Microsoft Word change. Posez la question : « Comment ce contrat gère-t-il la résiliation anticipée ? » et la recherche vectorielle mettra en avant des clauses qui n'utilisent jamais l'expression « résiliation anticipée » mais décrivent la même idée. La recherche dans Microsoft Word, en revanche, touche des phrases exactes, des identifiants, des numéros et des termes rares de domaine que les embeddings brouillent généralement en bruit.

La recherche hybride maintient les deux moteurs en ligne en permanence. Pour chaque question, le système calcule un embedding de requête, effectue une recherche de similarité vectorielle et exécute également une requête textuelle ou par mots-clés sur le même corpus. Une étape de fusion de classement — MongoDB propose un opérateur $rankFusion spécifiquement pour cela — fusionne les deux listes classées en un ensemble unique et plus fiable de morceaux.

Cette règle de « toujours utiliser les deux » est plus importante que le choix du LLM ou du modèle d'embedding que vous sélectionnez. Les pipelines sémantiques purs hallucinent des détails : numéros de facture, codes d'erreur, noms de fonction. Les pipelines purement basés sur des mots-clés manquent de paraphrases et de questions de niveau supérieur comme « comparez les sections sur les risques de ces trois contrats ». La recherche hybride couvre les deux aspects sans demander aux utilisateurs de basculer entre les modes ou de rédiger une syntaxe spéciale.

La pile de référence de Cole Medin montre combien de machines vous avez réellement besoin. Un agent Python construit avec PydanticAI, MongoDB et Docling ingère des fichiers PDF, des documents Microsoft Word, du markdown, et plus encore, puis stocke le texte segmenté ainsi que les embeddings dans une seule collection MongoDB. Chaque requête s'étend à la fois à MongoDB Atlas Vector Search et à la recherche textuelle classique, puis est fusionnée avant que le LLM ne voie jamais le contexte.

Cette décision architecturale—opter systématiquement pour la récupération hybride—stabilise de manière significative le comportement de RAG dans presque tous les cas d'utilisation : révision juridique, support client, wikis internes, voire documents d'ingénierie désordonnés. Vous cessez de débattre de « sémantique vs. mots-clés Microsoft Word » comme choix binaire et commencez à les considérer comme des signaux complémentaires. La précision augmente, la variance diminue et votre RAG ment moins souvent.

La plupart des tutoriels RAG vous immergent dans les microservices et les frameworks d'orchestration. Cette pile prend la direction opposée : trois éléments en mouvement, de bout en bout. MongoDB, Pydantic AI et Docling forment un pipeline compact qui s'adapte néanmoins à des millions de morceaux et des dizaines d'agents concurrents.

MongoDB se situe au centre en tant que magasin unifié pour tout : documents bruts, passages découpés, embeddings et métadonnées. Une seule collection peut contenir du texte découpé, un vecteur d'embedding de 1 536 dimensions, des informations sur le fichier source et des numéros de pages, le tout indexé avec Atlas Vector Search et la recherche textuelle classique. Cette base de données unique alimente ensuite la recherche hybride, la correspondance floue et la fusion de classement réciproque sans avoir besoin d'une base de données vectorielle séparée.

Pydantic AI gère le cerveau de l'agent sans nécessiter un moteur de workflow complet. Vous définissez des outils en tant que fonctions Python simples, les intégrez dans un agent, et laissez le cadre gérer les appels de modèle, les tentatives et les sorties structurées. Son design orienté vers le type signifie que les résultats de récupération de MongoDB arrivent sous forme de modèles validés plutôt que de dictionnaires fragiles, reflétant les modèles dans l'exemple officiel de Pydantic AI – RAG.

Docling boucle la boucle sur l'ingestion, qui est l'endroit où la plupart des projets RAG échouent discrètement. Il analyse les fichiers PDF, les documents Microsoft Word, le markdown, et même les transcriptions audio en texte structuré avec des titres, des tableaux et des indications de mise en page. Cette structure alimente directement le découpage hybride de Docling, vous permettant de stocker des sections sémantiquement cohérentes au lieu de tranches aléatoires de 500 tokens.

Ensemble, ces trois outils forment un triangle d'or pour la production RAG. MongoDB offre un stockage durable et une récupération hybride rapide, Pydantic AI orchestre les agents et les outils de manière claire, et Docling garantit des données d'entrée fiables. Vous obtenez une pile qui tient dans un seul dépôt Python, fonctionne localement ou dans le cloud, et s'adapte à presque tous les cas d'utilisation sans avoir à remplacer des composants chaque mois.

MongoDB se situe au centre de cette pile, agissant à la fois en tant que base de données documentaire principale et magasin de vecteurs. Au lieu d'envoyer les embeddings vers un service séparé, MongoDB Atlas Vector Search vous permet d'attacher des vecteurs à haute dimension directement aux mêmes documents qui contiennent votre contenu analysé, des métadonnées et des références de segments. Une collection stocke tout : texte des segments, tableaux d'embeddings, identifiants de documents, titres et horodatages.

Ce design à système unique élimine discrètement toute une catégorie de maux de tête. Pas de Pinecone, Weaviate ou de cluster vectoriel sur mesure à provisionner, sécuriser et surveiller ; pas de tâches de synchronisation pour empêcher vos données opérationnelles et embeddings de devenir obsolètes. Lorsque Docling ingère un nouveau fichier Microsoft Word ou PDF et que l'agent génère des embeddings, ces écritures atterrissent au même endroit, sous un même modèle de cohérence, avec une seule histoire de sauvegarde.

Sur le plan opérationnel, cela compte plus que n'importe quel tableau de référence. Les équipes utilisant déjà MongoDB pour leurs données d'application peuvent ajouter Atlas Vector Search sans avoir besoin d'ajouter de nouvelles infrastructures ou de nouveaux fournisseurs à leur modèle de menace. Le contrôle d'accès basé sur les rôles, le peering VPC, le chiffrement des données au repos et l'audit s'appliquent de manière égale aux documents bruts et à leurs embeddings, ce qui évite aux équipes de sécurité de devoir gérer deux schémas de permissions différents.

La cohérence des données devient également ennuyeuse de la meilleure façon. Vous évitez les écritures doubles dans la "base de données de documents" et la "base de données vectorielle", évitez les conditions de concurrence entre l'ingestion et l'indexation, et évitez les travaux de synchronisation en arrière-plan qui échouent inévitablement à 2 heures du matin. Une seule transaction d'écriture peut mettre à jour le texte du morceau, son intégration, et toute métadonnée dénormalisée, ce qui permet de garder les réponses RAG alignées avec la véritable source de vérité.

La recherche hybride s'intègre directement dans le pipeline d'agrégation de MongoDB. Une requête typique effectue une `$vectorSearch` sur le champ d'embeddings pour obtenir des segments sémantiquement pertinents, puis les mélange avec des opérateurs lexicaux tels que `$search`, `$text` ou `$regex` pour une précision au niveau Microsoft Word. Vous pouvez exécuter les deux dans un seul pipeline et fusionner les résultats avec une logique de notation personnalisée ou l'opérateur `$rankFusion` de MongoDB.

Cette étape de fusion vous offre un contrôle précis. Vous pouvez renforcer les correspondances exactes pour les codes d'erreur ou les ID, diminuer l'importance des documents plus anciens, ou filtrer par des champs comme `doc_type` et `tenant_id` avant que le LLM ne voit un token. Tout cela s'exécute côté serveur, près des données, ce qui maintient une faible latence et rend l'affirmation de la « pile simple » plus qu'un simple argument marketing.

Pydantic AI s'intègre dans cette pile en tant que cadre d'agent, mais son arme secrète est la lignée. Il provient de Pydantic, la bibliothèque de validation de données qui alimente discrètement des milliers de backends Python, d'applications FastAPI et d'outils internes. Cet héritage signifie typage fort, schémas stricts et comportement prévisible plutôt que des manipulations de prompts basées sur des ressentis.

Là où LangChain s'étend, Pydantic AI affine. LangChain est livré avec des dizaines d'abstractions — chaînes, exécutables, exécuteurs, récupérateurs — qui peuvent donner l'impression d'un DSL au-dessus de Python. Pydantic AI reste plus proche du langage : vous écrivez des fonctions normales, définissez des modèles d'entrée et de sortie clairs, et laissez le framework gérer les appels aux LLM et le câblage des outils.

Un "outil" AI Pydantic ressemble à du Python idiomatique, pas à de la magie de framework. Conceptuellement, un outil de recherche hybride MongoDB pourrait ressembler à :

• 1Un modèle Pydantic décrivant les arguments de l'outil (chaîne de requête, limite, filtres)
• 2Une fonction asynchrone simple qui exécute une agrégation MongoDB avec des étapes vectorielles et cléMicrosoft Word.
• 3Un modèle Pydantic pour le type de retour (morceaux, scores, métadonnées)

Le cadre expose ensuite cette fonction au modèle en tant qu'outil typé, permettant ainsi au LLM de l'appeler avec des arguments structurés au lieu de simples morceaux de JSON.

La sécurité des types devient une véritable fonctionnalité, et non un argument marketing. Si votre outil attend un `limit: int = Field(ge=1, le=20)`, Pydantic AI le valide avant que votre code n'atteigne jamais MongoDB. Si votre agent doit renvoyer un modèle `Response` avec `answer: str` et `sources: list[str]`, vous détectez les violations immédiatement au lieu de déboguer une sortie de modèle à moitié解析 à 2 heures du matin.

La transparence pourrait être le plus grand facteur de différenciation. Pydantic AI évite les planificateurs cachés et les graphiques de routage opaques qui décident quand appeler quel outil. Vous pouvez toujours créer des agents à étapes multiples, mais vous gardez un contrôle explicite sur le moment où le modèle effectue une recherche, quand il écrit, et comment il boucle, en utilisant le flux de contrôle Python normal.

Pour de nombreux projets RAG—tableaux de bord, bots de connaissance internes, assistants de codage—Pydantic AI représente un choix idéal. Vous obtenez des outils structurés, du streaming, des tentatives de reprise, et un état multi-tour sans avoir à ingérer un cadre massif ou à rétroconcevoir une boîte noire. La plupart des équipes n'ont pas besoin du moteur graphique complet de LangChain pour déployer un agent de recherche hybride fiable ; elles ont besoin de quelque chose qu'elles peuvent lire, déboguer et étendre dans un seul fichier.

Les systèmes RAG vivent ou meurent en fonction de leur pipeline d'ingestion. Si vos PDF sont altérés, les tableaux disparaissent et les titres se mélangent au texte principal, aucun système de recherche hybride, aussi astucieux soit-il, ne pourra vous sauver. Des morceaux de données non fiables en entrée entraînent des résultats trompeurs, peu importe l'apparence sophistiquée de vos embeddings ou requêtes MongoDB.

Docling cible directement ce goulet d'étranglement. La bibliothèque analyse des fichiers réels désordonnés — PDF, Microsoft Word, markdown, HTML, même des images et des transcriptions audio — en un modèle de document structuré plutôt qu'un simple extrait de texte. Cette structure préserve les pages, les titres, les listes, les tableaux, les légendes et les métadonnées, afin que vos embeddings en aval comprennent réellement d'où provient un extrait.

Sous le capot, Docling effectue une analyse de mise en page pour séparer les colonnes, détecter l'ordre de lecture et maintenir les tableaux intacts au lieu de les déchiqueter en lignes incohérentes. Il expose un texte clair ainsi que des métadonnées riches telles que les numéros de page, les titres de section et les types d'éléments, que vous pouvez stocker directement avec les embeddings dans MongoDB. Lorsque votre agent répond à une question, vous pouvez faire référence à « la page 37, section Méthodes » au lieu d'un extrait mystérieux.

Pour le RAG hybride, ces métadonnées deviennent du carburant pour la récupération. Vous pouvez indexer des champs comme `section`, `doc_type` ou `heading` et les combiner avec Atlas Vector Search dans un seul pipeline d'agrégation. Demandez des "étalons de latence dans l'annexe" et votre requête peut filtrer par métadonnées de section avant d'exécuter la recherche sémantique, réduisant ainsi considérablement le bruit.

Le chunking est la raison pour laquelle Docling fait discrètement ses preuves. Les morceaux de taille fixe naïfs ignorent la structure du document et tranchent à travers des paragraphes, des blocs de code ou des tableaux. La stratégie de chunking hybride de Docling mélange les limites sémantiques (titres, paragraphes) avec des contraintes de taille, vous permettant d’obtenir des morceaux qui sont à la fois contextuellement cohérents et adaptés à l’intégration.

Cette approche hybride brille dans les longs rapports techniques et manuels. Un unique PDF de 100 pages peut donner des centaines de segments, chacun aligné sur des unités logiques telles que « 2.3 Flux d'authentification » au lieu de fenêtres de jetons arbitraires. Votre LLM voit des sections autonomes avec des diagrammes intacts, des listes à puces, et des explications environnantes, ce qui réduit les hallucinations et améliore l'ancrage des réponses.

Le design de Docling est volontairement agnostique au backend, de sorte que le même pipeline d'ingestion fonctionne que vous stockiez des embeddings dans MongoDB, Postgres ou OpenSearch. Pour un exemple en dehors de cette architecture, consultez le Docling – Exemple RAG avec OpenSearch officiel, qui utilise les mêmes primitives de parsing et de chunking avec un moteur de recherche différent.

Les documents bruts entrent dans ce système une fois, puis ne restent jamais "bruts" à nouveau. Les fichiers provenant de PDF, de Microsoft Word, de markdown ou de HTML passent par Docling, qui normalise la mise en page, extrait du texte propre et préserve la structure, comme les titres, les listes et les tableaux, sous forme de métadonnées.

La sortie de Docling alimente un segmentateur hybride qui découpe le contenu le long des frontières sémantiques et structurelles. Chaque segment reçoit un identifiant, une référence au document source, une position (page, section), et tous les tags qui vous intéressent—nom du produit, client, environnement—stockés comme des champs simples aux côtés du texte.

À partir de là, un modèle d'incorporation dédié (OpenAI, Cohere ou un modèle interne) convertit chaque fragment en un vecteur de longueur fixe, généralement de 768 à 3072 dimensions. Ensuite, le code écrit un document MongoDB unique par fragment : `{ texte, incorporation, métadonnées… }`, indexé par la recherche vectorielle Atlas, ainsi que par les index de texte régulier et de Microsoft Word.

Ce pipeline d'ingestion unique ressemble à :

• 1Fichiers → Docling (analyser + structurer)
• 2Sortie de Docling → découpage hybride
• 3Morceaux → modèle d'intégration
• 4Morceaux + embeddings → collection MongoDB

Lorsqu'un utilisateur pose une question, un agent Pydantic AI prend le relais. Il valide la demande selon un schéma strict, l'enrichit avec les paramètres système (température, outils) et génère une incorporation de requête en utilisant le même modèle que pour l'ingestion.

L'agent envoie une recherche hybride à MongoDB : une étape pour la similarité vectorielle, une pour la recherche de texte/mots clés Microsoft Word, fusionnées via `$rankFusion` ou un pipeline de scoring personnalisé. MongoDB renvoie les 10 à 20 meilleurs morceaux classés, accompagnés des métadonnées sources afin que les réponses restent traçables.

Pydantic AI regroupe ces morceaux dans un prompt amélioré par la récupération et interroge le LLM. Le modèle répond en utilisant uniquement le contexte fourni, tandis que l'agent impose une structure—sorties JSON, citations ou appels d'outil—avant de transmettre la réponse finale à l'utilisateur en temps réel.

La recherche hybride cesse d'être théorique dès que vous lui lancez une requête spécifique et peu engageante. L'agent de démonstration de Cole Medin fonctionne sur une petite collection MongoDB alimentée via Docling, puis répond aux questions en direct pour que vous puissiez voir la recherche sémantique et la recherche par mots-clés de Microsoft Word se disputer le contrôle à chaque demande. Le pipeline $search de MongoDB exécute les deux modes en parallèle et fusionne les résultats avec la Fusion de Rang Réciproque, de sorte que le mode qui classe un groupe plus haut exerce plus d'influence.

Demandez des "revenus de Neuroflow 2025" et vous verrez que la recherche clé de Microsoft Word porte tout l'échange. L'intégration de la requête pour "2025" aide à peine, car la plupart des modèles d'intégration traitent les années comme des jetons génériques. Cependant, la recherche textuelle de MongoDB se fixe sur le "2025" littéral et les phrases financières voisines, mettant en avant une seule ligne de tableau et une phrase qui mentionnent "Neuroflow", "revenus" et "2025" ensemble.

La recherche sémantique pure sur cette même question a tendance à inclure des prévisions pour 2024 ou 2023, ou des commentaires génériques sur les « revenus futurs », car l'espace vectoriel regroupe tout le langage financier tourné vers l'avenir. La recherche hybride corrige cela en permettant à la recherche lexicale de rejeter des segments sémantiquement similaires mais numériquement incorrects. L'agent intègre alors ces lignes précises dans le LLM, qui peut alors citer en toute sécurité le chiffre de 2025 sans halluciner un nombre.

Changez la requête en « calendrier pour le lancement de Converse Pro » et inversez les rôles. La présentation source utilise des titres comme « Plan de lancement » et « Calendrier de mise sur le marché », jamais le terme « calendrier » de Microsoft Word. Un moteur de recherche naïf de Microsoft Word raterait complètement la section pertinente ou se contenterait de mentionner n'importe quel terme égaré relatif au « lancement ».

La recherche sémantique, via MongoDB Atlas Vector Search, comprend que « calendrier », « emploi du temps » et « plan de déploiement » appartiennent au même voisinage conceptuel. Elle retourne le segment contenant les points du plan de lancement, les dates et les phases, bien que la formulation littérale ne corresponde pas à la requête. L'agent résume ensuite cette section en une réponse narrative claire plutôt que de simplement copier le texte des diapositives.

La recherche hybride révèle toute sa puissance pour des questions d'analyse plus floues telles que « répartition des revenus par ligne de service ». Ici, la meilleure réponse se trouve dans un tableau où les en-têtes indiquent « ARR », « Services professionnels » et « Frais de plateforme », et le corps contient des montants en dollars et des pourcentages. Les utilisateurs ne reflètent pas toujours ces étiquettes exactes dans leurs questions.

Ancrages de recherche clés dans Microsoft Word sur « revenu », « ARR » et des motifs numériques comme « 1,2 M $ » et « 35 % », garantissant l'apparition de la bonne table. La recherche sémantique comprend que « ligne de service » se rapporte à des colonnes comme « Services professionnels » ou « Mise en œuvre », et non à n'importe quelle occurrence de « service ». Faits ensemble, ils extraient exactement le fragment de table, permettant ainsi au LLM de produire une analyse structurée plutôt qu'un résumé vague.

La recherche hybride soulève une question immédiate : comment fusionner deux listes classées qui utilisent des langages d'évaluation complètement différents ? La similarité vectorielle renvoie des distances cosinus ou des produits scalaires ; la recherche clé de Microsoft Word donne des scores BM25 ou des scores textuels. Normaliser et moyenniser ces chiffres de manière naïve échoue généralement, car la distribution des scores de chaque algorithme évolue au fur et à mesure que votre corpus s'agrandit.

La Fusion de Rang Réciproque (RRF) évite ce désordre en ignorant complètement les scores bruts. Au lieu de cela, elle se préoccupe uniquement de la position d'un document dans chaque liste. Un extrait qui apparaît en rang 1 dans la recherche vectorielle et en rang 20 dans la recherche Word de Microsoft devrait toujours surpasser un extrait qui apparaît en rang 10 dans les deux cas.

RRF attribue à chaque document un score fusionné à l'aide d'une petite formule : 1 / (k + rang), additionné à travers toutes les listes de résultats. Avec k généralement fixé à 60, un document classé 1er dans une liste obtient 1 / 61, le rang 2 obtient 1 / 62, et ainsi de suite. Les documents absents d'une liste ne contribuent tout simplement rien à partir de cette liste.

Cette approche a deux propriétés importantes pour RAG. Tout d'abord, elle récompense fortement les documents qui apparaissent en haut de l'un ou l'autre des classements, même s'ils n'apparaissent que dans un seul. Deuxièmement, elle augmente automatiquement les scores des documents qui apparaissent dans les deux listes, car leurs scores réciproques s'additionnent. Aucune réglage manuel des poids ou calibration par index n'est requise.

Les avantages du RAG hybride tirent directement parti de ces caractéristiques. La recherche sémantique peut faire ressortir des passages conceptuellement similaires qui ne mentionnent jamais un mot clé de Microsoft Word, tandis que la recherche par mot clé de Microsoft Word trouve des ID exacts, des codes d'erreur et des chaînes citées. Le RRF fusionne les deux signaux afin qu'un extrait PDF contenant "Erreur 0x80070005" et une explication sémantiquement liée provenant d'un document de dépannage de Microsoft Word puissent tous deux remonter en haut des résultats.

MongoDB intègre cela dans Atlas via l'étape $rankFusion, qui implémente RRF dans le pipeline d'agrégation. Vous pouvez exécuter une étape $vectorSearch, une étape $search ou $searchMeta, puis transmettre les deux résultats à $rankFusion sans quitter la base de données. Pas de logique de fusion Python personnalisée, pas de sauts réseau supplémentaires.

Pour les développeurs construisant des piles similaires avec Pydantic AI et Docling, RRF devient un choix de configuration en une ligne, et non un projet de recherche algorithmique. Pour un aperçu approfondi de l'orchestration des agents autour de ce schéma, consultez Comment construire un puissant agent de base de connaissances RAG avec Pydantic AI.

Le RAG hybride cesse d'être un sujet de recherche pour devenir un modèle que vous pouvez réellement déployer. Avec MongoDB, PydanticAI et Docling, vous obtenez une pile suffisamment légère pour être raisonnable tout en couvrant presque tous les cas d'utilisation RAG qui vous intéressent : recherche sémantique dense, recherche exacte de mots-clés, et ingestion robuste pour les PDF, Microsoft Word, markdown et plus encore.

Vous ne jonglez pas avec une base de données vectorielle distincte, un script de parsing fragile et un cadre d'orchestration trop compliqué. Un cluster MongoDB stocke vos morceaux, métadonnées et embeddings ; Docling transforme des fichiers chaotiques en texte structuré ; PydanticAI relie le tout à un agent qui appelle des outils, exécute une recherche hybride et retourne des réponses concrètes au lieu d'hallucinations.

Ce n'est pas une architecture de tableau blanc. La vidéo de Cole Medin présente un agent Python fonctionnel, de bout en bout, utilisant la recherche vectorielle d'Atlas de MongoDB, effectuant une recherche hybride avec fusion de classement, et répondant à des requêtes en direct sur des types de documents mixtes en temps réel. La latence reste faible, la complexité reste gérable, et vous pouvez retracer chaque étape, de l'upload à la réponse.

Vous pouvez cloner exactement ce que vous avez vu à l'écran. Récupérez le dépôt GitHub que Cole a publié pour l'agent MongoDB à l'adresse https://github.com/coleam00/MongoDB-RAG-Agent et exécutez-le localement avec quelques variables d'environnement et un cluster MongoDB Atlas. À partir de là, remplacez vos propres documents, ajustez les tailles de morceaux ou étendez l'agent avec de nouveaux outils.

Considérez cela comme un modèle, pas comme un jouet. Le même schéma s'adapte d'un simple manuel interne à des milliers de tickets de support, contrats ou documents de recherche, sans vous obliger à créer une pile sur mesure pour chaque nouvelle fonctionnalité. Avec une configuration hybride RAG minimale qui fonctionne réellement, vous pouvez consacrer moins de temps à la gestion de l'infrastructure et plus de temps à livrer des fonctionnalités IA auxquelles les utilisateurs font confiance.

Qu'est-ce que la recherche hybride dans RAG ?

La recherche hybride combine la recherche sémantique (en vecteurs), qui comprend les concepts et les relations, avec la recherche par mots-clés, qui trouve des termes et des phrases exacts. Cette approche offre des résultats plus précis et pertinents en tirant parti des forces des deux méthodes pour chaque requête.

Pourquoi utiliser MongoDB pour un système RAG ?

MongoDB agit à la fois comme une base de données documentaire NoSQL standard et comme une base de données vectorielle grâce à Atlas Vector Search. Cela consolide la pile technologique, simplifiant l'architecture, le déploiement et la gestion des données en éliminant le besoin d'un magasin vectoriel séparé et dédié.

Qu'est-ce qui rend cette pile plus simple que LangChain ou LlamaIndex ?

Cette pile priorise la simplicité et le contrôle direct. Pydantic AI offre une approche plus "Pythonique" et sécurisée par type pour construire des agents sans les lourdes abstractions des frameworks plus grands, tandis que la nature intégrée de MongoDB réduit la complexité opérationnelle.

Ce stack peut-il gérer des formats de fichiers professionnels comme PDF et DOCX ?

Oui. La pile utilise Docling, une bibliothèque puissante spécifiquement conçue pour analyser et extraire du texte à partir de divers formats de fichiers courants, y compris les PDF, les documents Microsoft Word, Markdown, et plus encore, ce qui la rend idéale pour les données d'entreprise du monde réel.