RAG et récupération de connaissances

RAG (Retrieval-Augmented Generation) est actuellement l'une des architectures de déploiement de LLM les plus répandues.

L'idée centrale de RAG est :Pour répondre à des questions, laissez le LLM d'abord récupérer le contenu pertinent depuis une base de connaissances externe, puis générer une réponse basée sur les résultats de récupération, plutôt que de s'appuyer uniquement sur les connaissances mémorisées pendant l'entraînement du modèle.

Cela résout deux problèmes majeurs des LLM : la coupure de connaissances (le modèle ne connaît pas les événements survenus après l'entraînement) et l'hallucination (le modèle invente des réponses lorsqu'il n'est pas sûr).

Principes de base du RAG

Un système RAG complet se compose de deux pipelines :pipeline d'indexation hors ligne(prétraite les documents et les stocke dans une base de données vectorielle) etpipeline de requête en ligne(reçoit les questions des utilisateurs, récupère et génère).

Lors de la phase hors ligne, les documents bruts sont découpés en petits segments, convertis en vecteurs via un modèle Embedding, puis stockés dans une base de données vectorielle.

Lors de la phase en ligne, la question de l'utilisateur est également convertie en vecteur, les segments de document les plus similaires sont trouvés dans la base de données, concaténés au contexte, puis transmis au LLM pour générer une réponse.

La figure ci-dessous montre le flux de requête complet du RAG :

Basic RAG Flowchart RAG complete request flow: user questions are converted into query vectors via the Embedding model, similar document chunks are retrieved in the vector database, the question and retrieval results are concatenated into a Prompt, and input to the LLM to generate the final answer. User question Embedding Convert to query vector Vector database Similarity retrieval Top-K Prompt concatenation Question + document chunks LLM generation Answer based on retrieval results Offline indexing (one-time preprocessing) Original documents Chunking / cleaning Embedding Convert to document vectors Write Vector database Online query flow (every request goes through)

Prétraitement des données et découpage des documents

Défi préalable : analyse de documents complexes

Avant le découpage, le RAG est souvent confronté àdes défis d'analyse de format. En particulier pour les tableaux, les images et les mises en page multicolonnes dans les PDF, les documents Word ou les fichiers numérisés, une extraction de texte ordinaire peut facilement provoquer une confusion sémantique.

L'approche dominante actuelle dans l'industrie consiste à introduiredes moteurs d'analyse de documents(tels que LlamaParse, Unstructured) ou des grands modèles multimodaux, en convertissant des images et du texte complexes en Markdown structuré, ce qui pose les bases d'un découpage de haute qualité ultérieur.

Stratégies de découpage des documents

Le découpage des documents est le fondement de l'efficacité du RAG ; la granularité des segments affecte directement la qualité de la récupération. Des segments trop grands introduisent du bruit, tandis que des segments trop petits perdent le contexte. Les stratégies courantes sont les suivantes :

Stratégie de découpage Scénarios applicables Avantages Inconvénients
Découpage à taille fixe Texte général Simple à implémenter, rapide Peut couper des phrases sémantiquement complètes
Découpage récursif par caractères Texte structuré (Markdown, code) Privilégie la découpe selon des frontières sémantiques telles que les paragraphes et les phrases Un peu complexe à implémenter ; nécessite de définir une liste raisonnable de séparateurs
Découpage sémantique Documents longs, livres Utilise Embedding pour calculer la similarité entre phrases adjacentes et trouve automatiquement les points de rupture sémantiques pour le découpage Coût de calcul élevé, prétraitement lent
Récupération de documents parent-enfant
(Du petit au grand)		 Scénarios de couverture complète Utilise des « petits segments » pour une recherche vectorielle de haute précision, et en cas de correspondance renvoie le « grand segment » correspondant (document parent) au LLM, équilibrant précision de récupération et complétude du contexte. Les coûts de conception et de maintenance de la base de données doublent

En pratique, il est courant d'ajouter lors du découpageun chevauchement, c.-à-d. que des segments adjacents partagent plusieurs caractères pour éviter que des informations importantes soient tronquées aux frontières. Configuration typique : taille de segment 512 tokens, chevauchement 50~100 tokens.

Exemple : découpage récursif avec LangChain

from langchain.text_splitter import RecursiveCharacterTextSplitter

splitter = RecursiveCharacterTextSplitter(
    chunk_size=512,        # Nombre maximal de tokens par segment
    chunk_overlap=50,      # Nombre de tokens de chevauchement entre segments adjacents pour éviter la perte d'informations aux frontières
    separators=["\n\n", "\n", "。", ".", " ", ""]  # Donner la priorité au découpage par paragraphes et phrases
)

chunks = splitter.split_text(document_text)
print(f"Découpage en {len(chunks)} segments de document")

Recherche vectorielle

Modèles d'embedding

Les modèles d'embedding convertissent le texte en vecteurs denses (généralement des tableaux de flottants à 768 ou 1536 dimensions). Les textes sémantiquement similaires sont plus proches dans l'espace vectoriel, ce qui constitue la base mathématique de la recherche de similarité.

Comparaison des modèles d'embedding courants :

Modèle Dimensions Langues prises en charge Fonctionnalités
text-embedding-3-small（OpenAI） 1536 Multilingue Rapport coût-efficacité élevé, adapté à l'indexation à grande échelle
text-embedding-3-large（OpenAI） 3072 Multilingue Précision maximale, coût plus élevé
BAAI/bge-m3 1024 Chinois et anglais Open source, excellentes performances en chinois, prend en charge plusieurs langues
sentence-transformers/all-MiniLM-L6-v2 384 Anglais Petite taille, grande vitesse, adapté à un déploiement local extrêmement léger

Calcul de similarité et algorithmes ANN

Le cœur de la recherche est la mesure de distance. La plus couramment utilisée estla similarité cosinus, qui calcule le cosinus de l'angle entre deux vecteurs, avec une plage de [-1, 1] ; plus la valeur est proche de 1, plus les vecteurs sont similaires. De plus, il y a le produit scalaire et la distance euclidienne (distance L2).

Pour obtenir une recherche à l'échelle de la milliseconde parmi des millions de vecteurs, les bases de données utilisent généralementdes algorithmes de recherche approximative des plus proches voisins (ANN)(tels queHNSW, IVF). HNSW est actuellement l'algorithme le plus répandu. Il construit un réseau de graphes à sauts multicouche, sacrifiant très peu de précision en échange d'une amélioration d'un ordre de grandeur de la vitesse de recherche.

RAG avancé (architecture avancée)

L'architecture de base (Naive RAG) fait souvent face à des problèmes tels qu'une recherche imprécise et une « saturation du contexte » causée par des informations redondantes. Le RAG avancé y répond parune optimisation avant la recherche → une fusion de la recherche → une optimisation après la rechercheen utilisant une architecture en trois étapes pour les résoudre.

1. Pré-recherche : optimisation des requêtes

Les questions originales des utilisateurs ne sont souvent pas précises :

  • Réécriture de requête: Utilisez un LLM pour réécrire des requêtes en langage courant en termes de recherche standardisés.
  • HyDE（Hypothetical Document Embedding）: Laissez d'abord le LLM « deviner à l'aveugle » une réponse hypothétique. Comme la réponse générée contient généralement plus de terminologie métier que la question d'origine, utiliser le vecteur de cette réponse hypothétique pour la recherche permet souvent de retrouver des documents de meilleure qualité.

2. Recherche hybride

vaRecherche vectorielle(comprend la sémantique, grande tolérance aux fautes) etRecherche par mots-clésLes résultats sont fusionnés par pondération. Ceci est particulièrement important lorsqu'on rencontre des noms propres, des modèles de produits et des extraits de code, car la recherche vectorielle traditionnelle a tendance à « échouer » sur des noms propres spécifiques.

3. Optimisation après récupération : reclassement

Il s'agit d'une conception en deux étapes :classement grossier → classement fin. Bien que la recherche vectorielle soit rapide, son scoring n'est pas suffisamment précis. Le reclassement introduitun modèle Cross-Encoder(tel que `bge-reranker`), qui injecte des paires « question » et « document » dans le modèle pour une inférence et un scoring conjoints. Il est coûteux en calcul et n'est responsable que de sélectionner le Top-20 jusqu'au Top-5.

Exemple : pseudo-code du pipeline de reclassement

from sentence_transformers import CrossEncoder

reranker = CrossEncoder("BAAI/bge-reranker-v2-m3")

# 1. Classement grossier : la recherche vectorielle rappelle rapidement le Top-50
candidates = vector_store.similarity_search(query, k=50)

# 2. Classement fin : construire des paires [question, document] pour un scoring précis
pairs = [[query, doc.page_content] for doc in candidates]
scores = reranker.predict(pairs)

# 3. Filtrer le Top-5 final à transmettre au LLM
ranked_docs = sorted(zip(scores, candidates), reverse=True)
final_docs = [doc for _, doc in ranked_docs[:5]]

4. Self-RAG et CRAG (RAG correctif)

Un mécanisme d'auto-réflexion est ajouté. Par exemple, CRAG (RAG correctif), après avoir obtenu les résultats de récupération, fait d'abord jouer au LLM le rôle de « juge » pour les noter. Si la base de connaissances locale n'a aucun document correspondant ou si la qualité est extrêmement faible, le système déclenche automatiquement une recherche Web (comme l'API Google) en complément, réduisant considérablement les hallucinations.

GraphRAG : intégration du graphe de connaissances + de la récupération

Le RAG traditionnel traite la base de connaissances comme des fragments de texte indépendants et ne peut pas répondre à des questions telles que « trouver toutes les entreprises fondées par le PDG actuel et dont la valeur de marché dépasse 100 billion » qui nécessitentun raisonnement inter-documents et multi-sautsproblèmes complexes.GraphRAGIntroduction d'un graphe de connaissances pour modéliser explicitement les entités et les relations.

GraphRAG architecture diagram GraphRAG fuses vector retrieval with the knowledge graph: the user question triggers both vector retrieval and graph retrieval, and the results of the two paths are fused and fed into the LLM to generate an answer. User question Vector retrieval Relevant document chunks Graph retrieval Entity-relationship subgraph Context fusion Document chunks + graph paths Entity A → Relationship → Entity B Entity B → Relationship → Entity C

Étapes clés de GraphRAG

  1. Construction des connaissances: dans la phase hors ligne, utiliser un LLM pour extraire des triplets (sujet, relation, objet) à partir des documents et les écrire dans des bases de données de graphes telles que Neo4j.
  2. Récupération à double chemin: pour les entités de la requête, non seulement une récupération vectorielle traditionnelle est effectuée, mais un parcours de graphe est également déclenché dans le graphe de connaissances afin d'extraire des chaînes de relations multi-sauts.
  3. Génération par fusion graphe-texte: Assemblez les « chunks » récupérés par la recherche vectorielle et les « structures de chemin » récupérées par la recherche dans le graphe dans le Prompt, en donnant au LLM à la fois une vue globale et des détails spécifiques.

Référence du contenu GraphRAG :https://www.example.com/ai-agent/graphrag-usage.html

Recommandations pour le choix des technologies et des bases de données

Sélection de base de données/outil Type Scénarios de mise en œuvre recommandés
Pinecone / Zilliz Cloud Service cloud entièrement géré Prêt à l’emploi, aucune infrastructure à maintenir. Combiné à Cohere Rerank + GPT-4o, c’est la solution commerciale la plus rapide.
Qdrant Open source + géré Écrit en Rust, excellente gestion de la mémoire, performances extrêmement élevées. Adapté à un déploiement privé de niveau entreprise.
Weaviate / Elasticsearch Open source + géré Bénéficie d’une recherche hybride BM25 + vectorielle extrêmement mature (Hybrid Search), et constitue le premier choix pour les scénarios comportant de nombreux noms propres.
Milvus Open Source distribué Adapté aux plateformes de recherche d'entreprise à très grande échelle, au niveau du milliard à la dizaine de milliards.
Chroma / FAISS Bibliothèque locale / embarquée Extrêmement léger, aucun besoin de déployer un service autonome. Très adapté au développement local et à la validation de projets de base de connaissances personnelle.

Métriques d'évaluation RAG (cadre RAGAS)

L'évaluation d'un système RAG ne peut pas reposer uniquement sur l'intuition ; elle utilise principalementRAGASun cadre pour des tests quantitatifs automatisés selon les deux dimensions de « récupération » et de « génération » :

  • Rappel du contexte: Quelle proportion des informations de la réponse standard peut être récupérée.
  • Précision du contexte: Quelle proportion des documents récupérés est réellement pertinente.
  • Fidélité (métrique de fidélité/hallucination): Si les réponses générées sont toutes étayées par les documents récupérés.
  • Pertinence de la réponse: Si la réponse générée répond réellement à la question de l'utilisateur, en évitant les réponses non pertinentes.
Autres extensions