Pattern RAG Agent : réponses fondées sur des sources

Essence du pattern

RAG Agent est un pattern où l'agent commence par trouver des sources pertinentes, puis produit la réponse à partir d'elles, au lieu de s'appuyer seulement sur la mémoire paramétrique du modèle.

Quand l'utiliser : quand la réponse doit s'appuyer sur des documents à jour et des références, pas seulement sur la mémoire du modèle.

Au lieu de répondre "depuis la tête du modèle", RAG ajoute une étape dédiée :

• trouver des faits dans la base de connaissances
• sélectionner les extraits les plus pertinents
• répondre avec des citations

Problème

Imaginez qu'un utilisateur demande :

"Quel est le SLA du plan enterprise ?"

L'agent répond sans étape de recherche, uniquement depuis la mémoire du modèle.

Le texte peut sembler sûr de lui mais rester faiblement vérifié :

• valeur obsolète d'une ancienne version de policy
• faits mélangés depuis plusieurs documents
• absence de source vérifiable
• formulation "précise" sans preuve

Sans recherche contrôlée, même une réponse plausible peut être non fondée.

C'est particulièrement risqué pour le support, la compliance, les policies internes et la documentation technique.

Le problème est là : sans ancrage aux sources, l'agent peut fournir une réponse convaincante mais non vérifiée, difficile à auditer.

Solution

RAG ajoute une grounding-policy qui pilote la recherche avant la génération.

Analogie : c'est comme répondre avec un livre ouvert. D'abord vous trouvez les bonnes pages, ensuite vous formulez la réponse. Si les sources manquent, mieux vaut clarifier la demande que d'inventer.

Principe clé : d'abord trouver et vérifier les sources, ensuite générer la réponse.

L'agent peut proposer un texte, mais la grounding-policy détermine :

• quelles sources sont valides
• ce qui peut entrer dans la réponse
• quand un scénario fallback est nécessaire au lieu de "combler"

Processus contrôlé :

1. Retrieve : trouver les extraits pertinents
2. Ranking/filtrage : supprimer bruit et doublons
3. Ancrage aux sources : construire le contexte autorisé
4. Génération : répondre uniquement dans ce contexte
5. Citation : attacher liens/metadata aux affirmations

Cela apporte :

• moins de risque d'hallucinations sur les requêtes factuelles
• ancrage des réponses dans les documents
• vérifiabilité et auditabilité
• réponses plus à jour quand les documents changent

Cela fonctionne bien si :

• la recherche a un index de qualité + metadata
• le ranking filtre le bruit de façon stable
• le modèle ne répond pas hors du contexte ancré
• en absence de sources, un fallback sûr se déclenche

Le modèle peut "vouloir" répondre de mémoire, mais c'est la couche RAG qui décide si la base de preuve est suffisante.

Comment ça fonctionne

RAG ne remplace pas l'agent. Il ajoute une couche de connaissance avant la génération de réponse.

Idée clé : s'il n'y a pas de contexte pertinent, le système ne doit pas "inventer une réponse".

En code, ça ressemble à ceci

chunks = retrieve(goal, top_k=8, filters={"tenant_id": tenant_id})
context = rerank_and_pack(goal, chunks, max_tokens=2500)

if not context:
    return ask_clarifying_or_fallback(goal)  # sans contexte pertinent, on ne génère pas de réponse

answer = generate_grounded_answer(goal, context)  # génération uniquement depuis les sources trouvées
answer = attach_citations(answer, context)

return answer

Ce que ça donne pendant l'exécution

Goal: Quel est le SLA du plan enterprise ?

Retrieve:
- 6 extraits trouvés dans les policies de support
- après rerank, 2 restent pertinents
- si fragments pertinents = 0 -> question de clarification / fallback au lieu d'une réponse inventée

Ground:
- contexte construit à partir de deux extraits
- metadata ajoutées : doc_id, section, updated_at

Generate:
- réponse générée uniquement depuis ces sources

Cite:
- lien ajouté vers "Support Policy v3.2"

Quand c'est adapté - et quand non

Adapté

Non adapté

Parce que RAG ajoute des étapes supplémentaires d'indexation, de recherche et de ranking.

Différence avec ReAct

ReAct pilote la boucle d'actions de l'agent.

RAG pilote la qualité des connaissances qui servent à construire la réponse.

Quand utiliser RAG (vs autres patterns)

Utilisez RAG quand la réponse doit s'appuyer sur des documents externes ou une base de connaissances dans la requête courante.

Test rapide :

• si vous devez "trouver des sources pertinentes et répondre à partir d'elles" -> RAG
• si vous devez "mémoriser le contexte utilisateur entre étapes ou sessions" -> Memory-Augmented Agent

Comment combiner avec d'autres patterns

• RAG + ReAct: d'abord l'agent récupère les faits depuis les sources, puis exécute les étapes sur un contexte vérifié.
• RAG + Supervisor: si les sources valides manquent, la réponse est bloquée ou envoyée en approbation.
• RAG + Multi-Agent Collaboration: tous les agents partagent le même knowledge context et travaillent de manière cohérente.

En bref

Avantages et Inconvénients

FAQ

Q: Est-ce que RAG garantit une réponse correcte à 100% ?
A: Non. RAG réduit le risque d'erreur, mais la qualité dépend toujours de l'index, de la recherche et du ranking.

Q: Que faire si aucune source pertinente n'est trouvée ?
A: Il faut un fallback sûr : question de clarification, refus avec raison, ou escalade à un humain.

Q: Est-ce que RAG remplace le fine-tuning ?
A: Non. RAG gère l'accès à la connaissance à jour. Le fine-tuning change le style ou le comportement du modèle. En production, on combine souvent les deux.

Et ensuite

RAG donne à l'agent des connaissances externes à jour pour la requête en cours.

Mais comment conserver un contexte d'interaction utile entre les sessions utilisateur ?