Si vous avez construit un système RAG classique, vous en connaissez les atouts : il retrouve des segments pertinents, le LLM génère des réponses fondées sur les sources, les performances sont raisonnables et les coûts prévisibles. Cette approche suffit à la plupart des requêtes portant sur une base de connaissances.
Certaines requêtes mettent toutefois le RAG classique en échec : les questions à plusieurs sauts (« Quels clients utilisent la fonctionnalité X et nous ont quittés au cours des six derniers mois ? »), les questions riches en relations (« Comment nos tarifs se comparent-ils à ceux des concurrents A, B et C ? ») ou les demandes de synthèse (« Résumez tout ce que nous savons sur le parcours de ce client »). La recherche classique par segments les combine mal ; le LLM finit par manquer des éléments de contexte dispersés entre de nombreuses sources.
Les approches « au-delà des segments » — graph RAG, RAG agentique et RAG à contexte long — répondent chacune différemment à ces limites. Cet article explique leur nature, les situations où elles conviennent, leur fonctionnement réel en production et les compromis essentiels.
Les limites du RAG fondé sur des segments
Pour comprendre ce que nous corrigeons, voici les limites :
Limite 1 : aucune structure relationnelle. Les segments sont des unités indépendantes. Le lien entre le segment A, qui traite du compte du client X, et le segment B, qui décrit une plainte de ce même client, disparaît : ce ne sont plus que deux segments d’un espace vectoriel, trouvés ou non indépendamment.
Limite 2 : aucun raisonnement à plusieurs sauts. Identifier « les clients qui utilisent la fonctionnalité X et se sont plaints de Y » exige de combiner deux sources au moyen d’une logique ensembliste. La recherche par segments ne le fait pas.
Limite 3 : synthèse limitée. « Résumez l’évolution de cette relation client » exige de réunir de nombreux segments dans un récit cohérent. Le LLM doit recommencer cette synthèse à partir de zéro à chaque requête.
Limite 4 : rigidité du pipeline fixe. Le RAG classique suit toujours la séquence embedding de la requête → recherche de K résultats → génération. Les requêtes complexes qui exigent une recherche itérative ou un raisonnement en plusieurs étapes ne s’y prêtent pas.
Limite 5 : dilution du contexte. Les cinq premiers segments peuvent contenir des correspondances lexicales néanmoins hors sujet. Le LLM doit les parcourir, au détriment de la qualité.
Les variantes présentées ci-dessous répondent chacune à une partie de ces limites.
Graph RAG
L’idée consiste à représenter les données sous forme de graphe de connaissances. Les entités — personnes, produits, documents et événements — deviennent des nœuds, et leurs relations des arêtes. Les requêtes parcourent ce graphe au lieu d’effectuer une recherche vectorielle, ou en complément de celle-ci.
Quand le graph RAG est utile
Domaines axés sur les relations. Structures client-compte-transaction-interaction. Hiérarchies organisationnelles. Taxonomies de produits. Réseaux de citations. Tout ce qui implique que les connexions entre les entités sont aussi importantes que les entités elles-mêmes.
Raisonnement à plusieurs sauts. « Qui dirige l’équipe qui a acheté le produit X au troisième trimestre ? » exige le parcours produit → transaction → équipe → responsable. Le graph RAG le gère naturellement.
Agrégation. « Combien de clients du segment Y ont intégré le système Z ? » exige des opérations ensemblistes sur les entités. Une requête SQL sur un graphe de connaissances surpasse alors la recherche textuelle.
Citations et explications. Les relations du graphe sont explicites et auditables. Le LLM peut citer « John dirige l’équipe Acme [arête : gère] » plutôt qu’affirmer « d’après le contexte, je pense que John dirige l’équipe Acme ».
Fonctionnement réel du graph RAG
Le pipeline typique :
1. Extraction. Construire le graphe à partir de vos données. Deux approches courantes :
- Sources structurées (bases de données, API structurées) : importer directement. Les clients, les produits, les transactions sont déjà dans des tables.
- Sources non structurées (documents, transcriptions, e-mails) : utiliser un modèle de langage pour extraire les entités et les relations. “À partir de cette transcription, extrayez les personnes, les organisations et les relations entre elles.”
La sortie : des nœuds (avec des types et des propriétés) et des arêtes (avec des types et des propriétés).
2. Stockage. Une base de données de graphe — Neo4j, Memgraph, Postgres personnalisé avec des tables d’arêtes. Le choix dépend des schémas de requête et de l’échelle.
3. Enrichissement par des embeddings. Chaque nœud reçoit également une représentation textuelle et un embedding. Une approche hybride peut ainsi parcourir le graphe tout en effectuant une recherche sémantique.
4. Interrogation au moment de la recherche. Trois schémas sont courants :
- Requête uniquement sur le graphe. Le modèle de langage (ou une logique de routage) génère une requête de graphe (Cypher, SQL). Exécuter. Retourner les résultats au modèle de langage.
- Embedding d’abord, puis expansion du graphe. Trouvez les entités pertinentes par embedding, puis étendez la recherche à leurs voisins et aux entités associées.
- Hybride. Combiner la recherche vectorielle + le parcours du graphe dans un seul pipeline.
5. Formater pour le modèle de langage. Les résultats du graphe sont formatés en texte structuré que le modèle de langage peut utiliser. Entités avec leurs propriétés ; relations explicites.
Exemple concret
Une entreprise SaaS avec des données clients. Entités : clients, contrats, produits, tickets de support, interactions, employés.
Approche RAG classique : segmenter les documents clients, calculer les embeddings et rechercher. La structure relationnelle disparaît.
Approche graph RAG :
- Nœuds : client, contrat, produit, ticket, interaction, employé.
- Arêtes : client→a→contrat, client→souscrit→produit, client→soumis→ticket, ticket→assigné→employé, contrat→vendu_par→employé.
Requête : “Quels clients du niveau SaaS ont plus de 3 tickets de support au premier trimestre et sont en renouvellement au deuxième trimestre ?”
C’est naturellement une requête de graphe :
MATCH (c:Customer)-[:HAS]->(contract:Contract)
WHERE contract.tier = "SaaS"
AND contract.renewal_date BETWEEN "2026-04-01" AND "2026-06-30"
MATCH (c)-[:SUBMITTED]->(t:Ticket)
WHERE t.created BETWEEN "2026-01-01" AND "2026-03-31"
WITH c, count(t) as ticket_count
WHERE ticket_count > 3
RETURN c, ticket_count
Le LLM génère cette requête, ou la sélectionne parmi des modèles prédéfinis. Le système l’exécute, met en forme les résultats et génère la réponse.
Le RAG classique répond difficilement à cette question ; le graph RAG la traite proprement.
Compromis
Avantages :
- Gère naturellement les requêtes relationnelles.
- Structure explicite et auditée.
- Compatible avec les embeddings.
Inconvénients :
- La construction du graphe est un véritable travail d’ingénierie. En particulier pour les sources non structurées, l’extraction est imparfaite.
- La conception du schéma compte ; de mauvais schémas vous limitent.
- Maintenance : à mesure que les données évoluent, le graphe évolue.
- Outils moins matures que la recherche vectorielle.
Quand choisir :
Choisissez le graph RAG lorsque les relations sont des éléments de premier plan dans votre domaine. Ne l’adoptez pas simplement parce qu’il semble sophistiqué : dans de nombreux domaines centrés sur les documents, le RAG classique reste plus simple et tout aussi efficace.
GraphRAG de Microsoft et travaux connexes
Le projet open source GraphRAG de Microsoft (2024) a popularisé une approche spécifique :
- Extraire des entités et des relations à partir de documents (basé sur un modèle de langage).
- Regrouper les entités en communautés.
- Générer des résumés par communauté à plusieurs niveaux hiérarchiques.
- Au moment de la requête, rechercher les résumés de communauté pertinents et les utiliser comme contexte.
Cela fonctionne bien pour les questions “globales” qui couvrent un corpus (ex. : “quels sont les thèmes principaux dans l’historique des plaintes de ce client ?”) plutôt que des recherches spécifiques.
Les variantes incluent LightRAG, Graphiti et d’autres — chacune avec des choix architecturaux spécifiques.
RAG agentique
L’idée consiste à remplacer le pipeline fixe recherche puis génération par un agent LLM qui décide quelles informations rechercher, à quel moment et comment affiner sa démarche. Il peut lancer des recherches supplémentaires, examiner les résultats, les juger insuffisants et explorer d’autres pistes.
Quand le RAG agentique est utile
Requêtes complexes nécessitant plusieurs itérations. « Aidez-moi à comprendre pourquoi notre taux d’attrition a augmenté au premier trimestre » exige d’examiner plusieurs dimensions : segment, période, fonctionnalités et concurrents. Un agent peut les explorer de manière itérative.
Requêtes pour lesquelles une seule recherche ne suffit pas. Si la réponse exige de combiner les résultats de plusieurs recherches distinctes, un agent le gère naturellement.
Requêtes comportant une logique conditionnelle. « Si X est vrai d’après la recherche 1, recherchez Y ; sinon, recherchez Z. » Les agents gèrent ces embranchements, contrairement aux pipelines fixes.
Requêtes ambiguës. L’agent peut demander à l’utilisateur (ou aux données) une clarification.
Fonctionnement du RAG agentique
Le pipeline :
User query
↓
Agent reasons about what it needs
↓
Agent calls retrieval tools (one or many)
↓
Agent reads results
↓
Agent decides: enough info? Or another retrieval?
↓
Loop until done
↓
Generate final answer
L’implémentation implique :
Recherche sous forme d’outils. Exposez à l’agent des fonctions de recherche telles que search_documents(query), lookup_by_id(id) et aggregate(field, filter). Il les appelle selon ses besoins.
Mémoire. L’agent mémorise les informations trouvées au fil des appels, ce qui évite de charger plusieurs fois le même contenu.
Prise de décision. L’agent détermine explicitement s’il dispose de suffisamment d’informations : « Est-ce que je connais la réponse à la question de l’utilisateur ? Sinon, quelles autres informations dois-je rechercher ? »
Arrêt. L’agent doit savoir quand s’arrêter, au moyen d’un nombre maximal d’étapes, d’un seuil de confiance ou d’une condition « J’ai répondu ».
Un exemple concret
Requête : “Quels étaient les trois principaux problèmes des clients au premier trimestre, avec des exemples ?”
Approche RAG classique : rechercher quelques segments de retours clients et espérer qu’ils couvrent le sujet.
Approche RAG agentique :
Agent: I need to find Q1 customer concerns. Let me start by searching for customer complaints in that period.
> Tool: search_documents(query="customer complaints Q1 2026", filter={date_range: "Q1 2026"})
Agent: I got 25 results. Let me see what topics they cover.
> [reads results]
Agent: I see three main themes: pricing, slow support, and missing integrations. Let me get specific examples for each.
> Tool: search_documents(query="customer pricing complaints", filter={...})
> Tool: search_documents(query="customer support speed complaints", filter={...})
> Tool: search_documents(query="customer integration missing complaints", filter={...})
Agent: Now I have 3-5 specific examples per theme. Let me compile the answer.
L’agent affine plusieurs recherches de manière itérative et détermine la structure de la réponse en fonction de ses résultats.
Compromis
Avantages :
- Gère les requêtes complexes, multi-étapes.
- S’adapte à la complexité de la requête (les requêtes simples ne déclenchent pas de longues exécutions d’agent).
- Peut clarifier l’ambiguïté en demandant.
Inconvénients :
- Latence plus élevée en raison des recherches multiples.
- Coût plus élevé (plusieurs appels LLM).
- La fiabilité de l’agent compte ; de mauvais agents bouclent ou abandonnent.
- Plus difficile à évaluer (plus de chemins d’exécution variés).
- Plus difficile à contrôler (l’agent pourrait faire des choses inattendues).
Quand choisir :
Choisissez le RAG agentique lorsque la complexité des requêtes varie fortement. Les requêtes simples peuvent emprunter des chemins rapides, tandis que les requêtes complexes bénéficient du traitement agentique. Pour des requêtes uniformément simples, le surcoût ne se justifie pas.
Schémas du RAG agentique
Quelques schémas courants :
Schéma 1 : ReAct (Raisonnement + Action). L’agent raisonne explicitement, puis agit (récupère), puis observe, puis raisonne à nouveau. Boucle jusqu’à ce que ce soit terminé.
Schéma 2 : planification et exécution. L’agent crée d’abord un plan en plusieurs étapes qui précise les informations à rechercher et leur ordre, puis l’exécute en l’ajustant si nécessaire.
Schéma 3 : auto-évaluation. Après la recherche, l’agent évalue si les informations obtenues suffisent. Dans le cas contraire, il affine la requête et relance la recherche.
Schéma 4 : agent doté de nombreux outils. L’agent dispose de plusieurs outils de recherche — recherche plein texte, requêtes SQL ou de graphe et appels d’API — parmi lesquels il choisit.
Différents schémas conviennent à différents cas d’utilisation. L’agent riche en outils fonctionne pour les sources de données hétérogènes ; ReAct fonctionne pour les requêtes exploratoires ; plan et exécution fonctionne lorsque la structure d’une requête complexe peut être planifiée à l’avance.
RAG à contexte long
L’idée : avec des fenêtres de plus d’un million de tokens, comme celles de Gemini et GPT-5, pourquoi rechercher des segments ? Il suffit de placer l’intégralité du corpus dans le contexte.
Quand le RAG à contexte long est utile
Petits corpus. Un corpus de 100 000 tokens tient aisément dans une fenêtre d’un million de tokens. Aucune infrastructure de recherche n’est nécessaire.
Compréhension d’un document entier. « Résumez l’intégralité de ce document de 500 pages. » Un modèle à contexte long traite directement cette tâche.
Requêtes croisées sur de petits ensembles. Pour « Comparez ces 10 contrats », il est plus simple de tous les placer dans le contexte que de les rechercher avec précision.
Prototypage. Un contexte long constitue la voie la plus simple vers un système fonctionnel. Construisez ainsi le prototype, puis optimisez-le ultérieurement avec la recherche si nécessaire.
Fonctionnement du RAG à contexte long
Le pipeline est trivial :
[corpus, possibly 100K-1M tokens]
↓
+ [user query]
↓
LLM call
↓
[answer]
Aucune base de données vectorielle, aucune segmentation et aucun reclassement.
En pratique, une recherche légère peut encore être nécessaire pour faire tenir le corpus dans le contexte. Pour un corpus de cinq millions de tokens, recherchez par exemple un sous-ensemble de 500 000 tokens. La recherche reste toutefois grossière : le LLM se charge de trouver précisément les passages pertinents.
Le problème de la dégradation du contexte
Une réalité de 2025-2026 : les modèles à contexte long n’exploitent pas toujours efficacement les contextes volumineux.
Expérimentalement :
- La qualité est optimale avec environ 5 000 à 50 000 tokens de contexte. Le mécanisme d’attention positionnelle sous-jacent est documenté dans « Lost in the Middle » de Liu et al. et dans les évaluations ultérieures des contextes longs.
- La qualité diminue nettement au-delà de 100 000 tokens.
- Au-delà de 500 000 tokens, des informations importantes sont souvent omises ou mal appliquées.
Les modèles acceptent techniquement les contextes longs, mais les benchmarks de type « aiguille dans une botte de foin » surestiment leurs performances. Leur utilisation réelle se dégrade.
Le RAG à contexte long fonctionne donc de manière fiable pour les corpus comptant jusqu’à environ 50 000 tokens. Au-delà, sa qualité devient inférieure à celle d’une bonne recherche.
Compromis
Avantages :
- Architecture la plus simple possible.
- Aucun pipeline de recherche à maintenir.
- Meilleur pour les tâches de compréhension du corpus entier.
Inconvénients :
- Dégradation de la qualité à de grands tailles de contexte.
- Coût par requête élevé (vous payez pour le contexte complet chaque fois).
- Latence élevée (grand contexte = réponse plus lente).
- Ne passe pas à l’échelle au-delà des corpus qui tiennent de manière fiable dans la fenêtre de contexte.
Quand choisir :
Petits corpus de moins de 50 000 tokens, analyses ponctuelles et prototypes. Cette approche ne convient PAS à la recherche généraliste dans de vastes bases de connaissances.
Approche hybride : recherche et contexte long
Un schéma courant consiste à rechercher un contexte plus large que dans un RAG classique — entre 50 000 et 200 000 tokens de contenu pertinent — tout en restant sous la taille du corpus complet. Le LLM reçoit suffisamment de contexte sans subir une dégradation excessive.
Mise en œuvre : recherchez les 50 premiers segments au lieu des 5 premiers, incluez-les tous et laissez le LLM les parcourir.
Cela fonctionne bien lorsque :
- Les requêtes nécessitent un contexte large.
- Les modèles gèrent bien les contextes intermédiaires, de 50 000 à 200 000 tokens.
- Le coût est acceptable.
Un compromis intéressant en 2026 consiste à rechercher largement, avec 50 à 100 segments, à tous les inclure et à laisser le LLM exploiter les passages pertinents. Le coût augmente au bénéfice de la simplicité et de la qualité.
Choisir la bonne variante
Un cadre de décision :
Utilisez le RAG classique fondé sur des segments lorsque :
- Les documents sont les données principales.
- Les requêtes sont principalement de type recherche.
- Le volume et le coût comptent (le moins cher par requête).
- Vous avez besoin d’une latence prévisible.
Utilisez le graph RAG lorsque :
- Les données ont une structure riche en entités et relations.
- Les requêtes impliquent un raisonnement multi-étapes, des opérations d’ensemble, des agrégations.
- Vous pouvez investir dans la construction et la maintenance du graphe.
Utilisez le RAG agentique lorsque :
- La complexité des requêtes varie largement.
- Certaines requêtes nécessitent une exploration itérative.
- Vous acceptez une latence et un coût supérieurs pour les requêtes difficiles.
- Vous avez une observabilité pour déboguer les exécutions d’agents.
Utilisez le RAG à contexte long lorsque :
- Le corpus est petit, avec moins de 50 000 tokens.
- Vous souhaitez l’architecture la plus simple.
- Analyses ponctuelles ou prototypes.
Combinez lorsque :
- La plupart des systèmes réels le font.
- RAG classique + graphe pour les requêtes relationnelles.
- RAG classique + RAG agentique pour les requêtes complexes.
- RAG classique avec une recherche plus large et un contexte intermédiaire pour les cas limites.
En 2026, la réponse la plus aboutie consiste à appliquer toutes ces approches, requête par requête. Un routeur choisit la variante selon les caractéristiques de la requête.
Réalités en production
Quelques observations à partir de déploiements réels :
La complexité s’accumule. Chaque variante ajoute de la complexité. Un système utilisant les quatre est un véritable travail d’ingénierie. Commencez par le classique ; ajoutez des variantes uniquement lorsque vous atteignez clairement des limites.
L’évaluation est plus difficile. Avec plusieurs chemins de recherche, elle doit tous les couvrir. Le jeu de test doit inclure des requêtes qui exercent chacun d’eux.
Les coûts varient fortement. Le graph RAG peut être peu coûteux puisqu’il exécute une requête de base de données. Le RAG à contexte long est cher. Le coût du RAG agentique dépend de la complexité. Suivez les dépenses par requête.
La latence varie de la même manière. Une réponse agentique en 30 secondes convient à certains cas d’usage, mais pas à d’autres. Choisissez les variantes selon le contexte UX.
Charge de maintenance. Les schémas de graphes dérivent, les prompts des agents doivent être ajustés et les modèles d’embedding évoluent. Chaque variante entraîne ses propres coûts de maintenance. Planifiez-les.
La règle des 80/20. Le RAG classique traite correctement 80 % des requêtes. Les variantes au-delà des segments prennent en charge les 20 % difficiles. Ne remplacez pas le RAG classique : enrichissez-le.
Une architecture combinée
Une architecture pratique utilisant plusieurs variantes :
Query
↓
Router (classify the query)
├→ "Lookup" → Classic RAG (cheap, fast)
├→ "Relational" → Graph RAG
├→ "Complex / open-ended" → Agentic RAG
└→ "Whole-corpus / small corpus" → Long-context
Each variant produces an answer.
Observability tracks which path was used.
Eval suites cover all paths.
Cette architecture est plus complexe que chaque variante isolée, mais traite efficacement toute la diversité des requêtes. Elle constitue souvent l’architecture cible des systèmes matures.
Une mise en œuvre pratique
Si vous commencez à partir d’un RAG classique fonctionnel et souhaitez l’étendre :
Ajoutez d’abord le RAG à contexte long. Son coût d’ingénierie est le plus faible. Il convient à certains types de requêtes et produit souvent des gains immédiats.
Ajoutez le RAG agentique pour les requêtes complexes. Identifiez les requêtes que le RAG classique traite mal, construisez un agent adapté et dirigez-les conditionnellement vers celui-ci.
Ajoutez le graph RAG en dernier. Son coût d’ingénierie est le plus élevé et ne se justifie qu’en présence de schémas de requêtes relationnelles bien établis.
Cet ordre correspond généralement au retour sur investissement : le RAG à contexte long offre une valeur réelle à faible coût ; le RAG agentique comble de véritables lacunes pour un coût modéré ; le graph RAG répond à des cas d’usage précis pour un coût élevé.
Enrichir plutôt que remplacer
Le RAG classique fondé sur des segments reste la solution de référence, mais il présente des limites. Les variantes « au-delà des segments » — graph RAG, RAG agentique et RAG à contexte long — offrent chacune des capacités différentes.
La voie à suivre ne consiste pas à remplacer le RAG classique, mais à l’enrichir. Les systèmes matures combinent plusieurs variantes et dirigent chaque requête vers celle qui lui convient.
L’investissement est significatif — chaque variante est un véritable travail d’ingénierie. Mais pour les systèmes où le RAG classique atteint un plafond, les gains en capacité sont réels. Un système qui gère bien les requêtes “recherche” est beaucoup moins utile qu’un système qui gère également les requêtes relationnelles, complexes et à corpus complet.
Cartographiez vos requêtes. Identifiez celles que le RAG classique gère mal. Choisissez la variante qui convient. Construisez l’amélioration. Itérez.
C’est ainsi que les systèmes RAG cessent d’être utiles pour quelques requêtes seulement et deviennent capables de traiter la diversité des questions réelles.
