Un système RAG peut récupérer les bons documents… et produire une mauvaise réponse. La fiabilité ne dépend pas uniquement de la qualité du retrieval. Elle dépend de la manière dont le système gouverne les limites, le périmètre et les conditions de réponse.
Idée centrale
Un RAG fiable n’est pas seulement un système qui récupère les bons passages. C’est un système qui :
- respecte le périmètre autorisé
- évite l’inférence abusive
- gère la non-réponse légitime
- maintient une trace interprétative auditables.
Où le retrieval échoue
- Fragmentation : le chunk récupéré manque de contexte.
- Hiérarchie absente : plusieurs passages sont récupérés sans priorité canonique.
- Version obsolète : le document est valide, mais périmé.
- Ambiguïté : la requête active un passage partiellement pertinent.
Le vrai problème : les limites
1) Limite de périmètre
Le système ne sait pas quand une réponse dépasse le champ autorisé.
2) Limite d’inférence
Le modèle extrapole à partir d’un fragment partiel.
3) Limite de version
Le système ne discrimine pas entre version actuelle et ancienne.
4) Limite de réponse
Le système répond alors qu’il devrait produire une non-réponse légitime.
Conditions minimales d’un RAG fiable
- Hiérarchie canonique explicite.
- Versionnement clair.
- Conditions de réponse opposables.
- Trace d’interprétation.
- Mesure d’écart canon-sortie.
Pourquoi cela devient critique en agentique
En environnement agentique, une réponse déclenche une action. Un RAG non gouverné transforme une faiblesse d’interprétation en décision erronée.
Liens recommandés
FAQ
Un bon embedding suffit-il ?
Non. La similarité vectorielle ne garantit ni fidélité ni respect du périmètre.
Pourquoi la hiérarchie est-elle importante ?
Parce que tous les documents récupérés ne sont pas équivalents en autorité.
Peut-on rendre un RAG totalement sûr ?
On peut réduire drastiquement le risque en gouvernant les limites et en intégrant des règles de non-réponse.
