RAG avancé : explication de LongRAG, Self-RAG et GraphRAG
LongRAG, Self-RAG, GraphRAG – des techniques de nouvelle génération
La Génération Augmentée par Récupération (RAG) a évolué bien au-delà de la simple recherche de similarité vectorielle. LongRAG, Self-RAG et GraphRAG représentent l’avant-garde de ces capacités.
Les systèmes RAG modernes doivent gérer des documents massifs, comprendre des relations complexes entre entités et bien plus encore.
Cette belle image est générée par le modèle IA Flux 1 dev.
L’évolution au-delà du RAG de base
Les systèmes RAG traditionnels suivent un schéma simple : découper les documents, les transformer en vecteurs, récupérer les fragments similaires via la similarité cosinus, et les transmettre à un LLM. Bien qu’efficace pour de nombreux cas d’utilisation, cette approche peine face à trois scénarios critiques :
Comprendre la distinction entre recherche, deepsearch (recherche approfondie) et deep research (recherche intensive) aide à clarifier pourquoi des variantes RAG avancées sont nécessaires pour les tâches de récupération d’informations complexes. Pour une exploration plus approfondie de ces concepts, consultez Recherche vs Deepsearch vs Deep Research.
- Dépendances à longue portée : Des informations contextuelles importantes peuvent s’étendre sur des milliers de jetons à travers plusieurs fragments
- Confiance en la récupération : Le système n’a aucun moyen d’évaluer si le contenu récupéré est réellement pertinent
- Complexité des relations : La similarité vectorielle ne peut pas capturer les connexions complexes entre les entités
Les variantes RAG avancées répondent à ces limitations avec des architectures spécialisées adaptées à des défis spécifiques.
LongRAG : Conquérir le contexte étendu
Vue d’ensemble de l’architecture
LongRAG repense fondamentalement la stratégie de découpage en exploitant des LLM dotés de fenêtres de contexte étendues (32K, 100K, voire 1M de jetons). Au lieu de fragmenter les documents en petits morceaux de 512 jetons, LongRAG utilise une approche hiérarchique :
Embedding au niveau du document : L’ensemble du document (ou de très grandes sections) est traité comme une unité unique. Un embedding au niveau du document capture le sens sémantique global, tout en conservant le texte complet pour le traitement en aval.
Fragmentation minimale : Lorsqu’un découpage est nécessaire, LongRAG utilise des fragments beaucoup plus larges (4K-8K jetons) avec un chevauchement significatif (20-30 %). Cela préserve le flux narratif et réduit la fragmentation du contexte.
Assemblage du contexte : Au moment de la récupération, LongRAG renvoie des documents complets ou de grandes sections cohérentes plutôt que des fragments éparpillés. Le LLM reçoit un contexte continu qui préserve les relations structurelles et sémantiques.
Stratégie de mise en œuvre
Voici une implémentation conceptuelle utilisant Python et des modèles d’embedding modernes :
from typing import List, Dict
import numpy as np
class LongRAGRetriever:
def __init__(self, model, chunk_size=8000, overlap=1600):
self.model = model
self.chunk_size = chunk_size
self.overlap = overlap
self.doc_embeddings = []
self.documents = []
def create_long_chunks(self, text: str) -> List[str]:
"""Créer de grands fragments chevauchants"""
chunks = []
start = 0
while start < len(text):
end = start + self.chunk_size
chunk = text[start:end]
chunks.append(chunk)
start += (self.chunk_size - self.overlap)
return chunks
def index_document(self, doc: str, metadata: Dict):
"""Indexer le document avec un embedding hiérarchique"""
# Encoder le document entier
doc_embedding = self.model.embed(doc)
# Créer de grands fragments avec chevauchement
chunks = self.create_long_chunks(doc)
chunk_embeddings = [self.model.embed(c) for c in chunks]
self.doc_embeddings.append({
'doc_id': len(self.documents),
'doc_embedding': doc_embedding,
'chunk_embeddings': chunk_embeddings,
'chunks': chunks,
'full_text': doc,
'metadata': metadata
})
self.documents.append(doc)
def retrieve(self, query: str, top_k: int = 3) -> List[Dict]:
"""Récupérer du contenu pertinent de longue forme"""
query_embedding = self.model.embed(query)
# Noter au niveau du document en premier
doc_scores = [
np.dot(query_embedding, doc['doc_embedding'])
for doc in self.doc_embeddings
]
# Obtenir les meilleurs documents
top_doc_indices = np.argsort(doc_scores)[-top_k:][::-1]
results = []
for idx in top_doc_indices:
doc_data = self.doc_embeddings[idx]
# Pour chaque document, trouver les meilleurs fragments
chunk_scores = [
np.dot(query_embedding, emb)
for emb in doc_data['chunk_embeddings']
]
best_chunk_idx = np.argmax(chunk_scores)
# Retourner un contexte étendu autour du meilleur fragment
context_chunks = self._get_extended_context(
doc_data['chunks'],
best_chunk_idx
)
results.append({
'text': ''.join(context_chunks),
'score': doc_scores[idx],
'metadata': doc_data['metadata']
})
return results
def _get_extended_context(self, chunks: List[str],
center_idx: int) -> List[str]:
"""Obtenir un contexte étendu autour du fragment pertinent"""
start = max(0, center_idx - 1)
end = min(len(chunks), center_idx + 2)
return chunks[start:end]
Cas d’utilisation et performances
LongRAG excelle dans les scénarios où le contexte est crucial :
- Analyse de documents juridiques : Les contrats et mémoires juridiques ont souvent des dépendances s’étendant sur des dizaines de pages
- Récupération d’articles de recherche : Comprendre la méthodologie nécessite des sections cohérentes, non des paragraphes isolés
- Dépôts de code : Les fonctions et classes doivent être comprises dans le contexte de leur module
Caractéristiques de performance :
- Latence : Plus élevée en raison du traitement de grands fragments (2 à 5 fois plus lent que le RAG standard)
- Précision : Amélioration de 15 à 25 % sur les benchmarks de Q/R longue forme
- Mémoire : Nécessite 3 à 4 fois plus de mémoire pour les fenêtres de contexte
Self-RAG : Récupération réflexive
Principes fondamentaux
Self-RAG introduit une couche métacognitive aux systèmes RAG. Au lieu de récupérer et générer aveuglément, le système réfléchit activement à ses propres processus via des jetons de réflexion spéciaux :
Jetons de récupération : Décide si la récupération est nécessaire pour une requête donnée Jetons de pertinence : Évalue si les documents récupérés sont réellement pertinents Jetons de soutien : Vérifie si la réponse générée est étayée par le contenu récupéré Jetons de critique : Évalue la qualité globale de la réponse générée
Composants de l’architecture
L’architecture Self-RAG se compose de trois phases entrelacées :
class SelfRAGSystem:
def __init__(self, retriever, generator, critic):
self.retriever = retriever
self.generator = generator
self.critic = critic
def generate_with_reflection(self, query: str,
max_iterations: int = 3):
"""Générer une réponse avec autoréflexion"""
# Phase 1 : Décider si la récupération est nécessaire
retrieve_decision = self.critic.should_retrieve(query)
if not retrieve_decision:
# Génération directe sans récupération
return self.generator.generate(query)
# Phase 2 : Récupérer et évaluer la pertinence
retrieved_docs = self.retriever.retrieve(query)
relevant_docs = []
for doc in retrieved_docs:
relevance_score = self.critic.assess_relevance(
query, doc
)
if relevance_score > 0.7: # Seuil
relevant_docs.append(doc)
if not relevant_docs:
# Retour à la génération sans récupération
return self.generator.generate(query)
# Phase 3 : Générer et vérifier le soutien
best_answer = None
best_score = -1
for _ in range(max_iterations):
# Générer une réponse candidate
answer = self.generator.generate(
query, context=relevant_docs
)
# Évaluer le soutien et la qualité
support_score = self.critic.check_support(
answer, relevant_docs
)
quality_score = self.critic.assess_quality(answer)
total_score = 0.6 * support_score + 0.4 * quality_score
if total_score > best_score:
best_score = total_score
best_answer = answer
# Arrêt anticipé si une haute qualité est atteinte
if total_score > 0.9:
break
return {
'answer': best_answer,
'confidence': best_score,
'sources': relevant_docs,
'reflections': {
'retrieved': retrieve_decision,
'relevance': len(relevant_docs),
'support': support_score
}
}
Entraînement des mécanismes de réflexion
Self-RAG nécessite l’entraînement du composant critique pour effectuer des évaluations fiables. Cela implique généralement :
- Entraînement supervisé sur des datasets annotés avec des jugements de pertinence
- Apprentissage par renforcement avec des récompenses pour les prédictions précises
- Apprentissage contrastif pour distinguer les affirmations étayées des non-étayées
Les jetons de réflexion peuvent être implémentés sous forme de :
- Jetons spéciaux dans le vocabulaire (comme
[RETRIEVE],[RELEVANT]) - Têtes de classificateurs séparées sur le modèle
- Modèles critiques externes (approche d’ensemble)
Considérations de production
Lors du déploiement de Self-RAG dans des systèmes de production :
Compromis de latence : Chaque étape de réflexion ajoute 20 à 40 % de surcoût d’inférence. Équilibrez la rigueur avec les exigences de temps de réponse.
Seuils de confiance : Ajustez les seuils de réflexion en fonction de votre cas d’utilisation. Les applications juridiques ou médicales nécessitent une confiance plus élevée que les chatbots généraux.
Surveillance : Suivez les décisions de réflexion pour identifier les tendances. Si la récupération est rarement nécessaire, une architecture plus simple pourrait être bénéfique.
GraphRAG : Récupération enrichie par les graphes de connaissances
Fondations conceptuelles
GraphRAG transforme le problème de récupération d’une similarité vectorielle en une traversée de graphe. Au lieu de trouver des fragments de texte sémantiquement similaires, GraphRAG identifie des sous-graphes pertinents d’entités et de relations connectées.
Extraction d’entités : Identifier les entités nommées, les concepts et leurs types Cartographie des relations : Extraire les relations entre les entités (temporelles, causales, hiérarchiques) Construction du graphe : Construire un graphe de connaissances avec les entités comme nœuds et les relations comme arêtes Récupération de sous-graphes : Étant donné une requête, trouver des sous-graphes connectés pertinents
Pipeline de construction du graphe
Construire un graphe de connaissances à partir de texte non structuré implique plusieurs étapes :
class GraphRAGBuilder:
def __init__(self, entity_extractor, relation_extractor):
self.entity_extractor = entity_extractor
self.relation_extractor = relation_extractor
self.graph = NetworkGraph()
def build_graph(self, documents: List[str]):
"""Construire un graphe de connaissances à partir de documents"""
for doc in documents:
# Extraire les entités
entities = self.entity_extractor.extract(doc)
# Ajouter les entités comme nœuds
for entity in entities:
self.graph.add_node(
entity['text'],
entity_type=entity['type'],
context=entity['surrounding_text']
)
# Extraire les relations
relations = self.relation_extractor.extract(
doc, entities
)
# Ajouter les relations comme arêtes
for rel in relations:
self.graph.add_edge(
rel['source'],
rel['target'],
relation_type=rel['type'],
confidence=rel['score'],
evidence=rel['text_span']
)
def enrich_graph(self):
"""Ajouter des relations dérivées et des métadonnées"""
# Calculer l'importance des nœuds (PageRank, etc.)
self.graph.compute_centrality()
# Identifier les communautés/clusters
self.graph.detect_communities()
# Ajouter un ordonnancement temporel si les horodatages sont disponibles
self.graph.add_temporal_edges()
Traitement des requêtes avec des graphes
Les requêtes GraphRAG impliquent un raisonnement multi-sauts à travers le graphe de connaissances :
class GraphRAGRetriever:
def __init__(self, graph, embedder):
self.graph = graph
self.embedder = embedder
def retrieve_subgraph(self, query: str,
max_hops: int = 2,
max_nodes: int = 50):
"""Récupérer un sous-graphe pertinent pour la requête"""
# Identifier les entités semences dans la requête
query_entities = self.entity_extractor.extract(query)
# Trouver les nœuds correspondants dans le graphe
seed_nodes = []
for entity in query_entities:
matches = self.graph.find_similar_nodes(
entity['text'],
similarity_threshold=0.85
)
seed_nodes.extend(matches)
# Étendre le sous-graphe via traversée
subgraph = self.graph.create_subgraph()
visited = set()
for seed in seed_nodes:
self._expand_from_node(
seed,
subgraph,
visited,
current_hop=0,
max_hops=max_hops
)
# Classer les nœuds par pertinence
ranked_nodes = self._rank_subgraph_nodes(
subgraph, query
)
# Extraire et formater le contexte
context = self._format_graph_context(
ranked_nodes[:max_nodes],
subgraph
)
return context
def _expand_from_node(self, node, subgraph, visited,
current_hop, max_hops):
"""Étendre récursivement le sous-graphe"""
if current_hop >= max_hops or node in visited:
return
visited.add(node)
subgraph.add_node(node)
# Obtenir les voisins
neighbors = self.graph.get_neighbors(node)
for neighbor, edge_data in neighbors:
# Ajouter l'arête au sous-graphe
subgraph.add_edge(node, neighbor, edge_data)
# Élargir récursivement
self._expand_from_node(
neighbor,
subgraph,
visited,
current_hop + 1,
max_hops
)
def _format_graph_context(self, nodes, subgraph):
"""Convertir le sous-graphe en contexte textuel"""
context_parts = []
for node in nodes:
# Ajouter le contexte du nœud
context_parts.append(f"Entity: {node.text}")
context_parts.append(f"Type: {node.entity_type}")
# Ajouter les informations sur les relations
edges = subgraph.get_edges(node)
for edge in edges:
context_parts.append(
f"- {edge.relation_type} -> {edge.target.text}"
)
return "\n".join(context_parts)
Implémentation GraphRAG de Microsoft
L’approche GraphRAG de Microsoft est unique car elle génère des résumés de communautés :
- Construire un graphe initial à partir de documents en utilisant l’extraction d’entités/relations basée sur LLM
- Détecter les communautés en utilisant l’algorithme de Leiden ou similaire
- Générer des résumés pour chaque communauté en utilisant des LLM
- Structure hiérarchique : Construire plusieurs niveaux d’abstractions de communauté
- Temps de requête : Récupérer les communautés pertinentes et traverser vers des entités spécifiques
Cette approche est particulièrement efficace pour :
- Requêtes exploratoires (“Quels sont les thèmes principaux dans ce corpus ?”)
- Raisonnement multi-sauts (“Comment A est-il connecté à C via B ?”)
- Analyse temporelle (“Comment les relations de cette entité ont-elles évolué ?”)
Analyse comparative
Quand utiliser chaque variante
Utilisez LongRAG lorsque :
- Les documents ont une forte cohérence interne
- Les fenêtres de contexte de votre LLM supportent de grandes entrées (32K+)
- Les réponses aux requêtes nécessitent de comprendre des dépendances à longue portée
- Vous travaillez avec des documents structurés (rapports, articles, livres)
Utilisez Self-RAG lorsque :
- La précision et la fiabilité sont critiques
- Vous avez besoin de décisions de récupération explicables
- Les faux positifs issus d’une récupération non pertinente sont coûteux
- La complexité des requêtes varie considérablement (certaines nécessitent une récupération, d’autres non)
Utilisez GraphRAG lorsque :
- Votre domaine possède des relations riches entre entités
- Les requêtes impliquent un raisonnement multi-sauts
- Les relations temporelles ou hiérarchiques sont importantes
- Vous devez comprendre les connexions entre entités
Comparaison des métriques de performance
| Métrique | RAG Standard | LongRAG | Self-RAG | GraphRAG |
|---|---|---|---|---|
| Temps d’indexation | 1x | 0.8x | 1.1x | 3-5x |
| Latence de requête | 1x | 2-3x | 1.4x | 1.5-2x |
| Utilisation mémoire | 1x | 3-4x | 1.2x | 2-3x |
| Précision (Q/R) | baseline | +15-25% | +20-30% | +25-40%* |
| Interprétabilité | Faible | Moyenne | Élevée | Élevée |
*Les améliorations de GraphRAG sont fortement dépendantes du domaine
Approches hybrides
Les systèmes de production les plus puissants combinent souvent plusieurs techniques :
LongRAG + GraphRAG : Utiliser la structure du graphe pour identifier les clusters de documents pertinents, puis récupérer les documents complets plutôt que des fragments
Self-RAG + GraphRAG : Appliquer des mécanismes de réflexion aux décisions de traversée de graphe (quels chemins suivre, quand arrêter l’expansion)
Pipeline en trois étapes : Utiliser GraphRAG pour la récupération initielle basée sur les entités → Self-RAG pour le filtrage de pertinence → LongRAG pour l’assemblage du contexte
Considérations d’implémentation
Modèles d’embedding
Les variantes RAG ont des exigences d’embedding différentes :
LongRAG : Nécessite des embeddings qui fonctionnent bien à la fois au niveau du document et au niveau des fragments. Envisagez des modèles entraînés avec un apprentissage contrastif sur de longues séquences.
Self-RAG : Bénéficie d’embeddings qui capturent les nuances sémantiques pour une évaluation fine de la pertinence.
GraphRAG : Nécessite des embeddings conscients des entités. Les modèles affinés sur des tâches de liaison d’entités performant mieux.
Le choix du modèle d’embedding a un impact significatif sur la performance. Lors du travail avec des modèles locaux, des outils comme Ollama offrent un moyen simple d’expérimenter avec différents modèles d’embedding avant de s’engager dans un déploiement de production.
Stratégies de découpage révisitées
Le découpage de taille fixe traditionnel est insuffisant pour le RAG avancé :
Découpage sémantique : Couper aux frontières naturelles (paragraphes, sections, changements de sujet) Découpage récursif : Créer des fragments hiérarchiques avec des relations parent-enfant Fenêtre glissante : Utiliser des fragments chevauchants pour préserver le contexte aux frontières Conscient de la structure : Respecter la structure du document (titres Markdown, balises XML, blocs de code)
Pour les implémentations basées sur Python, des bibliothèques comme LangChain et LlamaIndex offrent un support intégré pour ces stratégies de découpage.
Intégration du Reranking
Le reranking améliore considérablement la qualité de récupération pour toutes les variantes RAG. Après une récupération initiale, un modèle de reranking spécialisé re-classe les résultats en fonction des caractéristiques d’interaction requête-document. Cela procure une augmentation significative de la précision (10-20 %) avec un impact minimal sur la latence lorsqu’il est intégré de manière réfléchie.
Passage à l’échelle pour la production
Pipeline d’indexation :
- Utiliser un traitement distribué (Ray, Dask) pour les grands corpus de documents
- Mettre en œuvre une indexation incrémentielle pour les mises à jour en temps réel
- Stocker les embeddings dans des bases de données vectorielles optimisées (Pinecone, Weaviate, Qdrant)
Optimisation des requêtes :
- Mettre en cache les requêtes fréquentes et leurs résultats
- Mettre en œuvre le routage de requêtes (différentes variantes RAG pour différents types de requêtes)
- Utiliser la recherche de voisinage approximatif pour une mise à l’échelle sous-linéaire
Surveillance :
- Suivre les scores de pertinence de récupération
- Surveiller les décisions de réflexion dans Self-RAG
- Mesurer les chemins et profondeurs de traversée de graphe
- Journaliser les scores de confiance et les retours utilisateur
Applications réelles
Recherche de documentation technique
Un fournisseur cloud majeur a implémenté GraphRAG pour sa documentation :
- Entités : Points de terminaison API, paramètres, codes d’erreur, noms de services
- Relations : Dépendances, compatibilités de version, chemins de migration
- Résultat : Réduction de 35 % des tickets de support, temps de résolution 45 % plus rapide
Découverte juridique
Une entreprise de technologie juridique a combiné Self-RAG avec LongRAG :
- Self-RAG filtre les documents non pertinents tôt
- LongRAG préserve le contexte dans les documents conservés
- Les avocats examinent 60 % de faux positifs en moins
- La préservation du contexte critique s’est améliorée de 71 % à 94 %
Revue de littérature scientifique
Moteur de recherche académique utilisant une approche hybride :
- GraphRAG identifie les réseaux de citations et les communautés de recherche
- LongRAG récupère des sections complètes en préservant le contexte de la méthodologie
- Amélioration de 40 % dans la découverte d’articles pertinents
- Réduction du temps de revue de littérature de semaines à jours
Sujets avancés
RAG Multi-Modal
Extension de ces variantes pour gérer les images, tableaux et code :
- Ancrage visuel : Lier les entités textuelles aux images dans les documents
- Compréhension des tableaux : Analyser les données structurées dans un format de graphe
- Analyse de code : Construire des graphes de dépendances à partir de bases de code
RAG Adaptatif
Sélection dynamique de la stratégie RAG basée sur les caractéristiques de la requête :
- Classificateur de complexité de requête
- Détecteur de type de document
- Optimiseur de coût-bénéfice pour la sélection de stratégie
RAG préservant la confidentialité
Implémentation de ces variantes avec des contraintes de confidentialité :
- Récupération fédérée à travers des silos de données
- Confidentialité différentielle dans les embeddings
- Recherche de similarité chiffrée
Démarrage rapide
Démarrage rapide avec Python
Pour ceux qui souhaitent mettre en œuvre ces techniques, commencer par des bases solides en Python est essentiel. L’écosystème riche de Python pour l’apprentissage automatique en fait le choix naturel pour le développement RAG.
Voici un point de départ simple pour l’expérimentation :
# Installer les dépendances
# pip install sentence-transformers faiss-cpu langchain
from sentence_transformers import SentenceTransformer
import faiss
import numpy as np
# Configuration de base pour expérimenter avec de longs fragments
model = SentenceTransformer('all-MiniLM-L6-v2')
documents = [
# Vos documents de longue forme ici
]
# Créer des embeddings
embeddings = model.encode(documents)
# Construire un index FAISS
dimension = embeddings.shape[1]
index = faiss.IndexFlatL2(dimension)
index.add(embeddings.astype('float32'))
# Requête
query = "Votre question ici"
query_embedding = model.encode([query])
distances, indices = index.search(
query_embedding.astype('float32'), k=3
)
Sélection de framework
LangChain : Idéal pour le prototypage rapide, intégrations étendues LlamaIndex : Optimisé pour l’indexation et la récupération de documents Haystack : Prêt pour la production, abstractions de pipeline solides Sur mesure : Lorsque vous avez besoin d’un contrôle et d’une optimisation totaux
Cadre d’évaluation
Mettre en œuvre une évaluation rigoureuse avant le déploiement en production :
Métriques de récupération :
- Précision@K, Rappel@K, MRR (Rang Réciproque Moyen)
- NDCG (Gain Cumulatif Discounté Normalisé)
Métriques de génération :
- ROUGE, BLEU pour la similarité textuelle
- BERTScore pour la similarité sémantique
- Évaluation humaine pour l’assessment de qualité
Métriques bout-en-bout :
- Taux de succès de la tâche
- Scores de satisfaction utilisateur
- Percentiles de latence (p50, p95, p99)
Conclusion
Le paysage des systèmes RAG a considérablement mûri au-delà de la simple recherche de similarité vectorielle. LongRAG, Self-RAG et GraphRAG adressent chacun des limitations spécifiques des approches traditionnelles :
LongRAG résout le problème de fragmentation du contexte en adoptant des fenêtres de contexte étendues et un découpage minimal. C’est le choix privilégié lorsque la cohérence des documents compte et que vous disposez des ressources informatiques pour gérer de grands contextes.
Self-RAG ajoute une conscience critique aux systèmes de récupération. En réfléchissant à ses propres décisions, il réduit les faux positifs et améliore la fiabilité—essentiel pour les applications à haut risque où la précision prime sur la vitesse.
GraphRAG débloque la puissance de la représentation structurée des connaissances. Lorsque votre domaine implique des relations complexes entre entités, la récupération basée sur les graphes peut mettre en évidence des connexions que la similarité vectorielle ignore complètement.
L’avenir du RAG impliquera probablement des approches hybrides combinant les forces de ces variantes. Un système de production pourrait utiliser GraphRAG pour identifier des clusters d’entités pertinents, Self-RAG pour filtrer et valider les récupérations, et LongRAG pour assembler un contexte cohérent pour le LLM.
À mesure que les LLM continuent de s’améliorer et que les fenêtres de contexte s’élargissent, nous verrons émerger des variantes RAG encore plus sophistiquées. La clé est de comprendre vos exigences spécifiques de cas d’utilisation—structure des documents, motifs de requêtes, demandes de précision et contraintes informatiques—et de sélectionner la technique appropriée ou sa combinaison.
L’écosystème d’outils mûrit rapidement, avec des frameworks comme LangChain, LlamaIndex et Haystack offrant un support de plus en plus sophistiqué pour ces modèles avancés. Combiné à des runtime LLM locaux puissants et à des modèles d’embedding, il n’a jamais été aussi facile d’expérimenter et de déployer des systèmes RAG de qualité professionnelle.
Commencez par les bases, mesurez rigoureusement la performance, et évoluez votre architecture selon que les exigences le dictent. Les variantes RAG avancées couvertes ici fournissent une feuille de route pour cette évolution.
Liens utiles
- Reranking avec des modèles d’embedding
- LLM et sortie structurée : Ollama, Qwen3 & Python ou Go
- Fournisseurs cloud LLM
- Comparaison LLM : Qwen3:30b vs GPT-OSS:20b
- Tutoriel RAG étape par étape
- Comparaison du découpage en RAG
- Comparaison des bases de données vectorielles pour RAG
Références externes
- Microsoft GraphRAG : Un système modulaire de Génération Augmentée par Récupération basé sur les graphes
- Self-RAG : Apprendre à récupérer, générer et critiquer par autoréflexion
- LongRAG : Amélioration de la Génération Augmentée par Récupération avec des LLM à contexte long
- Génération Augmentée par Récupération pour les grands modèles de langage : Une étude
- FAISS : Une bibliothèque pour une recherche de similarité efficace
- Documentation LangChain : Techniques RAG avancées
- HuggingFace : Transformers de phrases pour les modèles d’embedding
- Enquête RAG : Une analyse complète de la Génération Augmentée par Récupération