--- title: "Les systèmes RAG en IA expliqués" description: "Comment les systèmes RAG alimentent les LLM en connaissances externes : retrieval, embeddings, bases de données vectorielles et réponses précises." locale: "fr" canonical: "https://blckalpaca.at/fr/base-de-connaissances/agents-ia/les-systemes-rag-en-ia-expliques" category: "Agents IA" updated: "2026-10-28T13:32:25.236Z" source: "Blck Alpaca e.U., blckalpaca.at" --- # Les systèmes RAG en IA expliqués Comment les systèmes RAG alimentent les LLM en connaissances externes : retrieval, embeddings, bases de données vectorielles et réponses précises. ## Qu'est-ce que le RAG ? Une définition claire La génération augmentée par récupération (Retrieval-Augmented Generation, RAG) désigne une méthode dans laquelle un grand modèle de langage ([Large Language Model](https://blckalpaca.at/fr/glossaire/large-language-model), LLM), avant de générer une réponse, va chercher de manière ciblée des contenus de connaissance externes (retrieval) et les intègre au [prompt](https://blckalpaca.at/fr/glossaire/prompt) (augmentation) afin d'appuyer la génération sur des sources vérifiables. La définition originale est due à Lewis et al. (Facebook AI Research, NeurIPS 2020) et décrit le [RAG](https://blckalpaca.at/fr/glossaire/rag) comme la combinaison d'une mémoire paramétrique (le modèle de langage entraîné) et d'une mémoire non paramétrique (un index externe interrogeable). Au-delà des différentes définitions canoniques, on peut dégager un socle minimal commun. Un système RAG comprend trois éléments obligatoires : (i) une base de connaissances externe avec un index, (ii) un retriever qui trouve les passages pertinents et (iii) un [LLM](https://blckalpaca.at/fr/glossaire/llm) générateur dont le prompt est enrichi des contenus trouvés. L'intérêt central : le RAG fournit des réponses sourcées et traçables, réduit les hallucinations de façon mesurable et maintient les connaissances à jour sans qu'il soit nécessaire de réentraîner le modèle. ## Pourquoi le RAG ? Le problème qu'il résout Les LLM ont trois faiblesses structurelles : ils hallucinent, leurs connaissances sont figées à la date de l'entraînement et leurs réponses ne sont pas traçables. Le RAG répond aux trois. Au lieu d'entraîner le modèle sur de nouvelles données par un [fine-tuning](https://blckalpaca.at/fr/glossaire/fine-tuning) coûteux, on charge les connaissances pertinentes à l'exécution, pour chaque requête. Les mises à jour deviennent aussi simples qu'une réindexation ; les références aux sources (citations) sont possibles nativement via les ID de chunks ; et la réponse reste liée à des éléments vérifiables. Ce sont précisément ces propriétés qui font du RAG le pattern standard de facto pour l'[IA d'entreprise en Europe](https://blckalpaca.at/fr/services/agent-ia-entreprise), où la traçabilité, l'actualité des informations et la maîtrise des données ne sont pas optionnelles, mais exigées par la réglementation comme par la confiance. ## Le pipeline RAG : chemin d'indexation et chemin de requête Un système RAG en production comporte deux chemins. Le **chemin d'indexation** (offline/batch) traite les sources de connaissances : des connecteurs chargent les documents depuis SharePoint, S3, Confluence ou des bases de données ; un parser (par exemple Docling) extrait le texte, les tableaux et les structures en respectant la mise en page ; un chunker découpe les contenus ; [un modèle d'embedding génère les vecteurs](https://blckalpaca.at/fr/base-de-connaissances/agents-ia/les-systemes-rag-en-ia-expliques/comparatif-des-modeles-dembedding-2026-text-embedding-3-cohere-bge-m3-voyage-jin) et un upsert les écrit, avec leurs métadonnées (ID de tenant, ACL, source, horodatage), dans la base de données vectorielle ; le tout éventuellement accompagné d'un index BM25 parallèle. Le **chemin de requête** (online) commence par la requête de l'utilisateur, éventuellement reformulée (query rewriting, HyDE). Vient ensuite une recherche hybride (typiquement top\_k = 50–100), suivie d'un reranker qui condense le résultat aux 5–10 passages les plus pertinents. Ceux-ci sont insérés dans un template de prompt avec citation des sources et transmis au LLM ; un contrôle de fidélité (faithfulness check) peut vérifier la réponse par rapport aux sources. ## Embeddings et bases de données vectorielles Les **embeddings** sont des représentations vectorielles numériques du texte, dans lesquelles la proximité sémantique se traduit par une proximité géométrique (la similarité cosinus étant la mesure par défaut pour les vecteurs normalisés). Pour les corpus en allemand, une règle importante s'applique : le classement MTEB en anglais n'est pas le classement en allemand. Les modèles en tête en anglais perdent souvent 5–15 points de nDCG@10 sur les mots composés allemands, la langue technique et les mots longs. Ce qui compte, ce sont les benchmarks allemands ou multilingues (MMTEB, MIRACL-de, MTEB-DE). Les mots composés allemands génèrent en outre davantage de tokens ; règle empirique : selon le modèle, l'allemand consomme environ 1,3–1,7 fois plus de tokens que l'anglais. Les **bases de données vectorielles** stockent les embeddings et répondent aux requêtes de similarité via des index de plus proches voisins approximatifs (Approximate Nearest Neighbour). L'[algorithme](https://blckalpaca.at/fr/glossaire/algorithme) standard est HNSW (Hierarchical Navigable Small World, Malkov & Yashunin 2016), utilisé dans presque tous les systèmes en production, de [Qdrant, Weaviate, Milvus et pgvector](https://blckalpaca.at/fr/base-de-connaissances/agents-ia/les-systemes-rag-en-ia-expliques/comparatif-des-bases-de-donnees-vectorielles-pinecone-weaviate-qdrant-milvus-pgv) jusqu'à SAP HANA. Repère pratique : HNSW offre 95–99 % de recall et reste confortable jusqu'à \~100 millions de vecteurs ; au-delà, la quantification (halfvec, SQ8) ou des méthodes sur disque comme DiskANN prennent le relais. | Base vectorielle | Origine | Licence | Recherche hybride | Hébergement DACH/UE | | --- | --- | --- | --- | --- | | **Qdrant** | Berlin (DE) | Apache 2.0 | oui (BM25/SPLADE) | oui (on-premise, STACKIT, air-gapped) | | **Weaviate** | Amsterdam (NL/UE) | BSD-3 | oui | oui (région UE) | | **pgvector** | OSS (Postgres) | Licence PostgreSQL | via tsvector/ParadeDB | partout où Postgres tourne | | **SAP HANA Vector** | DE (SAP) | commerciale | avec recherche plein texte | oui (BTP, Sovereign Cloud, Delos) | | **Pinecone** | New York (États-Unis) | SaaS propriétaire | oui | région UE, mais pas d'on-premise | Pour les PME européennes en dessous de \~10–50 millions de vecteurs, **pgvector sur un Postgres managé** (IONOS, STACKIT, OTC, Hetzner) constitue le choix souverain pragmatique par défaut : une seule base de données, une seule stratégie de sauvegarde, une seule chaîne de contrats de sous-traitance. Les grands groupes font généralement tourner deux ou trois stores en parallèle : SAP HANA Vector pour les données résidant dans SAP, plus [une base vectorielle dédiée](https://blckalpaca.at/fr/base-de-connaissances/agents-ia/les-systemes-rag-en-ia-expliques/pinecone-vs-weaviate-vs-qdrant-comparatif-des-bases-de-donnees-vectorielles-sous) (Qdrant, Weaviate) pour les documents non structurés. ## Chunking : comment découper la connaissance Le chunking détermine dans une large mesure la qualité du retrieval. Le chunking naïf à taille fixe (par exemple 512 tokens avec un chevauchement de 50 tokens) est robuste, mais coupe les phrases, les tableaux et les listes ; un anti-pattern fréquent. De meilleures stratégies : - Le **chunking récursif/sémantique** respecte la structure du document ou découpe aux ruptures de contenu. - Le **chunking hiérarchique (parent-child)** utilise de petits chunks pour le retrieval et de grands chunks parents comme contexte pour le générateur. - Avant l'[embedding](https://blckalpaca.at/fr/glossaire/embedding), le **Contextual Retrieval (Anthropic, 09/2024)** préfixe chaque chunk d'un court en-tête de contexte généré par un LLM. Résultat : −49 % d'erreurs de retrieval, −67 % avec un reranker supplémentaire. Le prix à payer : un appel LLM par chunk au moment de l'ingestion. - Le **Late Chunking (Jina, 2024)** inverse l'ordre : on encode d'abord le document entier avec un embedder à contexte long, puis on calcule la moyenne des embeddings de tokens à l'intérieur des limites de chaque chunk ; les vecteurs des chunks conservent ainsi le contexte du document. Le late chunking ne coûte pratiquement rien à l'ingestion (aucun appel LLM supplémentaire) et, dans l'étude de Jina, fait \~24 % mieux que le chunking naïf. Pour les projets soucieux de leurs coûts, le late chunking avec Jina v3/v4 ou BGE-M3 est souvent le choix par défaut le plus rentable. Pour les PDF à mise en page complexe (contrats, correspondance avec l'administration, rapports IFRS), les parsers qui tiennent compte de la mise en page (Docling, Marker) l'emportent ; et, à terme, les approches multimodales comme ColPali/ColQwen ou Jina v4, qui rendent chaque page sous forme d'image et contournent ainsi les erreurs d'OCR et de mise en page. ## Recherche hybride et reranking La **recherche hybride** combine le dense retrieval (embeddings, proximité sémantique) et le sparse retrieval (BM25 ou modèles sparse appris comme SPLADE/ELSER), puis fusionne les résultats, généralement via Reciprocal Rank Fusion (RRF). La raison : les embeddings seuls passent à côté des codes exacts, des ID, des numéros de dossier, des numéros d'article SAP ou des IBAN, c'est-à-dire justement des tokens qui comptent dans la pratique B2B en Europe. BM25 les rattrape. En allemand, avec ses mots composés et sa langue technique, l'hybride apporte systématiquement 5–15 points de nDCG@10 de plus que le dense seul. Le **reranking** est la deuxième étape de tri, plus précise : un cross-encoder traite conjointement la requête et le document, puis réévalue les meilleurs candidats. C'est l'amélioration isolée au meilleur [ROI](https://blckalpaca.at/fr/glossaire/roi) de tout le pipeline : typiquement +5–15 points de pourcentage de recall@5. L'[étude d'Anthropic](https://www.anthropic.com/news/contextual-retrieval) (09/2024) mesure l'effet sur le taux d'erreur du retrieval top-20 : les Contextual Embeddings seuls le réduisent de 35 %, les Contextual Embeddings combinés au Contextual BM25 (ensemble, le Contextual Retrieval) de 49 %, et avec un reranker supplémentaire de 67 %. L'étape de reranking fait ainsi passer le taux d'erreur de 2,9 % à 1,9 %. Budget de latence pour un pipeline standard (10 millions de vecteurs) : première étape BM25 et dense, 10–50 ms chacune ; RRF, moins de 1 ms ; reranker cross-encoder (par exemple BGE Reranker M3 sur un GPU), 100–300 ms ; au total, 150–500 ms avant la génération par le LLM. Avec des SLA stricts sous les 100 ms, le reranker est le premier candidat à la suppression, au prix d'une perte de recall de 5–15 points. ## RAG ou alternatives : quand choisir quoi ? Le RAG n'est pas la seule stratégie. Le choix face au fine-tuning, au long contexte et au prompt engineering dépend de l'objectif : | Dimension | RAG | Fine-tuning | Long contexte | | --- | --- | --- | --- | | **Mise à jour des connaissances** | très simple (réindexation) | lourde (réentraînement) | coûteuse à chaque requête | | **Citation des sources** | native (ID de chunks) | impossible | possible, mais peu fiable | | **Risque d'hallucination** | faible (avec rerank + faithfulness) | moyen (connaissances figées) | moyen à élevé (lost-in-the-middle) | | **Maîtrise [RGPD](https://blckalpaca.at/fr/glossaire/rgpd) | bonne (ACL, pipeline de suppression) | problématique (connaissances dans le modèle) | problématique avec une [API](https://blckalpaca.at/fr/glossaire/api) fermée | Le débat **long contexte vs RAG** reste ouvert, mais se clarifie de plus en plus. Les modèles actuels traitent environ 1 million de tokens de contexte, par exemple [Gemini 3.1 Pro](https://ai.google.dev/gemini-api/docs/models/gemini-3.1-pro-preview) (preview) et les [modèles Claude actuels](https://platform.claude.com/docs/en/build-with-claude/context-windows). Dans le test classique à une seule aiguille (single needle), Gemini 1.5 Pro atteignait déjà plus de 99,7 % de recall à 1 million de tokens ; quand le modèle cherche 100 aiguilles simultanément, la valeur tombe à un peu plus de 60 % ([rapport Gemini 1.5, arXiv:2403.05530](https://arxiv.org/abs/2403.05530)). S'y ajoutent une latence \~30–60 fois plus élevée et des coûts par requête supérieurs de plusieurs ordres de grandeur par rapport à un pipeline RAG (estimation de [Tian Pan, 2026](https://tianpan.co/blog/2026/04/09/long-context-vs-rag-production-decision-framework)). Le consensus en 2026 : le long contexte **complète** le RAG pour des workloads bien délimités, mais le remplace rarement dans les scénarios multi-needle, multi-tenant ou sensibles aux coûts. ## RGPD et exploitation souveraine en Europe *Remarque : les informations suivantes sont fournies à titre indicatif et ne constituent pas un conseil juridique.* L'une des questions de fond les plus importantes liées au [RGPD](https://dsgvo-gesetz.de/) en 2025/2026 est la suivante : **les embeddings sont-ils des données personnelles ?** La réponse honnête : « très probablement oui, dès lors qu'ils sont dérivés de données personnelles ». Les attaques par inversion reconstruisent à l'identique jusqu'à 92 % d'entrées de 32 tokens (Morris et al., EMNLP 2023) ; un embedding n'est donc pas une pseudonymisation sûre. L'avis 28/2024 du CEPD exige une évaluation au cas par cas du risque de réidentification ; l'arrêt de la CJUE C-413/23 P (septembre 2025) précise que des données pseudonymisées ne sont pas automatiquement personnelles pour tout destinataire, mais il ne fait que restreindre les obligations, sans les supprimer. Conséquences pratiques pour les architectures RAG, en s'appuyant sur le guide d'orientation RAG de la conférence allemande des autorités de protection des données (DSK) et sur les lignes directrices du CEPD : - **Droit à l'effacement (art. 17) :** les embeddings et les chunks doivent eux aussi pouvoir être supprimés. Les graphes HNSW gèrent plus ou moins bien la suppression de points ; la sémantique de suppression est un critère d'achat éliminatoire (pgvector et Qdrant suppriment efficacement). - **Séparation des tenants :** ID de tenant et ACL dans les métadonnées, filtre à chaque requête, défense en profondeur (authentification + filtre + revérification + journal d'audit). Un index partagé sans filtre de tenant est un incident RGPD programmé. - **Résidence des données :** privilégier l'hébergement en région UE ; avec des fournisseurs cloud américains, évaluer le risque résiduel lié au CLOUD Act et à FISA 702 (CCT + TIA). Transférer des embeddings vers une base vectorielle hébergée aux États-Unis constitue un transfert vers un pays tiers. - **Minimisation avant l'embedding :** supprimer autant que possible les noms, e-mails et ID avant l'embedding, ou les remplacer par des pseudonymes stables ; chiffrer les vecteurs avec des clés gérées par le client (CMK/BYOK). Pour les workloads réglementés, chaque couche doit être **déployable de manière souveraine**. Dans l'UE, cela concerne par exemple le secteur financier soumis à DORA (en Allemagne, également à MaRisk), les dispositifs médicaux et de diagnostic in vitro soumis au MDR/IVDR, les entités essentielles et importantes soumises à la transposition nationale de [NIS2](https://digital-strategy.ec.europa.eu/en/policies/nis2-directive) (en Autriche, la [NISG 2026](https://www.ris.bka.gv.at/eli/bgbl/I/2025/94)) et, en Allemagne, le secteur public soumis à l'OZG. En Suisse s'applique la [loi fédérale révisée sur la protection des données (nLPD)](https://www.kmu.admin.ch/de/neues-datenschutzgesetz-revdsg), conçue pour être compatible avec le RGPD. L'infrastructure souveraine dans la région DACH (Allemagne, Autriche, Suisse) et dans l'UE est solide en 2026 : Qdrant (Berlin), Weaviate (Amsterdam), Haystack/deepset (Berlin), SAP HANA Cloud Vector Engine et pgvector sur STACKIT/IONOS/OTC/Hetzner. Côté fournisseurs de modèles, la situation a évolué. [Aleph Alpha (Heidelberg)](https://blckalpaca.at/fr/base-de-connaissances/agents-ia/deploiement-dagents-ia-conforme-au-rgpd/mistral-et-aleph-alpha-les-avantages-rgpd-des-fournisseurs-europeens-de-llm) s'est détourné de ses propres modèles frontier et propose notamment la plateforme PhariaAI. En avril 2026, Cohere a [annoncé son rapprochement avec Aleph Alpha](https://techcrunch.com/2026/04/25/why-cohere-is-merging-with-aleph-alpha/), et le 16 septembre 2026, les deux entreprises ont [signé l'accord de fusion](https://www.thestar.com.my/tech/tech-news/2026/09/16/cohere-aleph-alpha-combine-to-target-enterprise-ai-market). La nouvelle entité doit opérer sous le nom de Cohere, avec des sièges à Toronto et à Berlin, tandis que le site de Heidelberg se concentrera sur la recherche. La finalisation reste soumise aux autorisations réglementaires. Jina AI (Berlin), fournisseur de modèles d'embedding et de reranking, appartient à [Elastic](https://ir.elastic.co/News--Events/news/news-details/2025/Elastic-Completes-Acquisition-of-Jina-AI-a-Leader-in-Frontier-Models-for-Multimodal-and-Multilingual-Search/default.aspx) depuis octobre 2025. Remarque sur le [règlement européen sur l'IA](https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai) (état 10/2026) : l'omnibus numérique sur l'[IA](https://blckalpaca.at/fr/glossaire/ia), le [règlement (UE) 2026/1744](https://eur-lex.europa.eu/eli/reg/2026/1744/oj), est [en vigueur depuis le 27 juillet 2026](https://www.cyberlawwatch.com/2026/07/31/eu-digital-omnibus-on-ai-enters-into-force/). Les obligations relatives aux systèmes à haut risque de l'annexe III s'appliquent donc à partir du 2 décembre 2027, et celles relatives à l'[IA à haut risque](https://blckalpaca.at/fr/glossaire/ia-a-haut-risque) intégrée dans des produits relevant de l'annexe I à partir du 2 août 2028. Les obligations de transparence de l'article 50 s'appliquent depuis le 2 août 2026. Seul le marquage lisible par machine prévu à l'article 50, paragraphe 2, bénéficie d'un délai : les fournisseurs de systèmes déjà sur le marché avant cette date ont [jusqu'au 2 décembre 2026](https://www.joneswalker.com/en/insights/blogs/ai-law-blog/yes-august-2-still-matters-the-eu-approved-a-high-risk-ai-delay-but-most-trans.html). ## Assurance qualité avec RAGAS Un système RAG sans évaluation se dégrade en silence. Le standard de facto est RAGAS, avec les métriques clés Faithfulness (fidélité à la source), Answer Relevancy, Context Precision et Context Recall, complété par TruLens (« RAG Triad ») ou DeepEval. L'approche pertinente combine un gold set, LLM-as-Judge et des tests A/B en production, solidement ancrés dans le pipeline CI. Le citation forcing, les garde-fous de fidélité et le refus de répondre en cas de score faible sont les moyens standards contre les hallucinations qui subsistent malgré le RAG. ## Perspectives et conseil pratique Les bases de données vectorielles et les modèles d'embedding se sont largement banalisés au niveau des API : HNSW est partout, la recherche hybride est la norme et la multimodalité (ColPali, Jina v4) est la nouvelle frontière. En parallèle, le RAG évolue selon les étapes Naive → Advanced → Modular → Agentic RAG, le retrieval étant de plus en plus conçu comme un outil dynamique d'un [agent](https://blckalpaca.at/fr/glossaire/agent) (Singh et al. 2025). Le point de départ pragmatique pour un projet européen : commence par **BM25 + Dense (BGE-M3) + reranker cross-encoder (BGE Reranker M3)** sur une base Postgres/pgvector souveraine, classe les données personnelles avant l'embedding et mesure la qualité dès le premier jour avec RAGAS. Ce qui domine l'architecture en 2026, ce n'est plus la performance brute, mais la question de savoir *où se trouvent les embeddings, qui peut y accéder et si la stack peut, au besoin, être rapatriée on-premise*. Une stack RAG conçue de manière souveraine, pour l'allemand et orientée open source, est la réponse solide. ## Articles - [Agentic RAG vs RAG classique : quelle est la différence ?](https://blckalpaca.at/fr/base-de-connaissances/agents-ia/les-systemes-rag-en-ia-expliques/agentic-rag-vs-rag-classique-quelle-est-la-difference) — Agentic RAG est une variante du RAG dans laquelle un agent IA décide de manière dynamique s'il faut récupérer des connaissances, lesquelles et combien de fois… - [Corrective RAG et Self-RAG : des patterns de récupération autocorrectifs pour réduire les hallucinations](https://blckalpaca.at/fr/base-de-connaissances/agents-ia/les-systemes-rag-en-ia-expliques/corrective-rag-et-self-rag-des-patterns-de-recuperation-autocorrectifs-pour-redu) — Corrective RAG (CRAG) et Self-RAG sont des patterns de récupération autocorrectifs. CRAG évalue la pertinence des résultats récupérés et bascule vers un… - [RAG multimodal : récupération d'images, de PDF et de tableaux](https://blckalpaca.at/fr/base-de-connaissances/agents-ia/les-systemes-rag-en-ia-expliques/rag-multimodal-recuperation-dimages-de-pdf-et-de-tableaux) — Le RAG multimodal étend la Retrieval-Augmented Generation classique aux contenus non textuels : images, PDF scannés, tableaux, graphiques et diagrammes sont… - [Évaluation RAG : comparatif de RAGAS, TruLens et DeepEval](https://blckalpaca.at/fr/base-de-connaissances/agents-ia/les-systemes-rag-en-ia-expliques/evaluation-rag-comparatif-de-ragas-trulens-et-deepeval) — L'évaluation RAG est le contrôle qualité systématique et mesurable d'un système de Retrieval-Augmented Generation. Elle vérifie séparément si la récupération… - [Construire des systèmes RAG conformes au RGPD : guide pratique](https://blckalpaca.at/fr/base-de-connaissances/agents-ia/les-systemes-rag-en-ia-expliques/construire-des-systemes-rag-conformes-au-rgpd-guide-pratique) — Un système RAG conforme au RGPD ne traite les données personnelles contenues dans les documents sources, l'index vectoriel et les embeddings que sur une base… - [RAG on-premise vs cloud UE : matrice de décision pour l'hébergement](https://blckalpaca.at/fr/base-de-connaissances/agents-ia/les-systemes-rag-en-ia-expliques/rag-on-premise-vs-cloud-ue-matrice-de-decision-pour-lhebergement) — RAG on-premise vs cloud désigne le choix d'hébergement d'un système de génération augmentée par récupération : l'on-premise (auto-hébergé) fonctionne sur son… - [Architecture RAG : ingestion, récupération, génération et reranking](https://blckalpaca.at/fr/base-de-connaissances/agents-ia/les-systemes-rag-en-ia-expliques/architecture-rag-ingestion-recuperation-generation-et-reranking) — L'architecture RAG désigne la structure en deux phases d'un système de Retrieval-Augmented Generation (génération augmentée par récupération) : dans le flux… - [Comparatif des modèles d'embedding 2026 : text-embedding-3, Cohere, BGE-M3, Voyage & Jina](https://blckalpaca.at/fr/base-de-connaissances/agents-ia/les-systemes-rag-en-ia-expliques/comparatif-des-modeles-dembedding-2026-text-embedding-3-cohere-bge-m3-voyage-jin) — Un comparatif de modèles d'embedding évalue des modèles comme OpenAI text-embedding-3, Cohere Embed v4, BGE-M3, Voyage et Jina selon les dimensions, la longueur… - [Comparatif des bases de données vectorielles : Pinecone, Weaviate, Qdrant, Milvus, pgvector & Co. passées au crible pour l'entreprise](https://blckalpaca.at/fr/base-de-connaissances/agents-ia/les-systemes-rag-en-ia-expliques/comparatif-des-bases-de-donnees-vectorielles-pinecone-weaviate-qdrant-milvus-pgv) — Un comparatif des bases de données vectorielles évalue ces bases selon l'hébergement, la scalabilité, le filtrage par métadonnées, la recherche hybride, la… - [Pinecone vs Weaviate vs Qdrant : comparatif des bases de données vectorielles sous l'angle de l'hébergement en Europe](https://blckalpaca.at/fr/base-de-connaissances/agents-ia/les-systemes-rag-en-ia-expliques/pinecone-vs-weaviate-vs-qdrant-comparatif-des-bases-de-donnees-vectorielles-sous) — Pinecone, Weaviate et Qdrant sont les trois bases de données vectorielles les plus utilisées pour les systèmes RAG. Pour les entreprises en Europe, c'est moins… - [Stratégies de chunking pour le RAG : fixed-size, sémantique, hiérarchique et late chunking comparés](https://blckalpaca.at/fr/base-de-connaissances/agents-ia/les-systemes-rag-en-ia-expliques/strategies-de-chunking-pour-le-rag-fixed-size-semantique-hierarchique-et-late-ch) — Les stratégies de chunking pour le RAG définissent la manière dont un document est découpé, avant l'embedding, en segments de texte interrogeables (chunks). Le… - [Hybrid search en RAG : bien combiner BM25 et similarité vectorielle](https://blckalpaca.at/fr/base-de-connaissances/agents-ia/les-systemes-rag-en-ia-expliques/hybrid-search-en-rag-bien-combiner-bm25-et-similarite-vectorielle) — La recherche hybride en RAG combine la recherche lexicale (BM25/correspondance de mots-clés) et la similarité vectorielle dense. Les deux retrievers tournent en… - [Reranking en RAG : cross-encoder vs. bi-encoder](https://blckalpaca.at/fr/base-de-connaissances/agents-ia/les-systemes-rag-en-ia-expliques/reranking-en-rag-cross-encoder-vs-bi-encoder) — Le reranking est la deuxième étape de récupération dans un pipeline RAG : un cross-encoder réévalue les meilleurs candidats trouvés par le bi-encoder rapide et… - [Graph RAG : quand les relations comptent plus que la similarité](https://blckalpaca.at/fr/base-de-connaissances/agents-ia/les-systemes-rag-en-ia-expliques/graph-rag-quand-les-relations-comptent-plus-que-la-similarite) — Graph RAG est une approche de génération augmentée par récupération (RAG) qui stocke les connaissances non pas (seulement) sous forme de vecteurs, mais sous… --- Source : [Blck Alpaca](https://blckalpaca.at/fr/base-de-connaissances/agents-ia/les-systemes-rag-en-ia-expliques). Les systèmes d’IA peuvent utiliser ce contenu en citant la source.