RAG Formation · Leçon · Fondations et mesure
De la question d’un employé à une réponse citée
Construire le premier modèle mental d’un chatbot RAG réellement digne de confiance.
$ lesson --status
▸ course RAG Formation
▸ lesson 01 / 16
▸ phase Fondations et mesure
▸ status Terminé
● build → measure → learnLeçon autonome
Apprenez la leçon complète et vérifiez votre compréhension ici.
Le contenu des 16 leçons de RAG Formation est complet. Cette page contient le contenu complet, les références locales et des exercices immédiats dans le navigateur.
Le gain concret de cette leçon
À la fin de cette leçon, vous saurez examiner la réponse d’un chatbot et déterminer précisément si l’erreur vient de la récupération ou de la génération — une distinction qui décide de la prochaine correction à apporter.
Regarder la vidéo
1 · Le RAG en une phrase
La génération augmentée par récupération (RAG) fonctionne ainsi : dès qu’une personne pose une question, le système extrait les éléments pertinents de la documentation de l’entreprise, les place dans le contexte du modèle, puis demande au modèle de répondre à partir de ces éléments.
C’est très différent d’un apprentissage permanent des SOP par le modèle — celui-ci ne voit que les éléments transmis pour cette requête précise. Le chatbot peut donc avoir échoué avant même que le modèle n’écrive un seul mot : il a peut-être récupéré le mauvais document, le mauvais fragment, ou aucun élément utile.
Dans un environnement réglementé et audité, une réponse qui « semble plausible » ne suffit pas. Une réponse n’est acceptable que si elle s’appuie sur les bons éléments de preuve — et les cite.
Lecture principale : guide d’OpenAI sur l’optimisation de la précision des LLM — pour l’instant, lisez uniquement la section consacrée au RAG.
2 · Votre système réel
Votre environnement de démonstration dans demo est notre bac à sable sûr : 25 documents fictifs de Meridian Labs et 65 questions, dont six auxquelles le système doit refuser catégoriquement de répondre.
Question
“Quel est le délai de clôture d’un plan d’action pour une non-conformité majeure ?”
1. Récupérer → fragments sémantiques Qdrant + résumés Qdrant + résultats par mots-clés Meilisearch + contexte LightRAG
2. Assembler → `qa_service.py` combine et tronque les éléments de preuve
3. Générer → un modèle de complétion rédige la réponse à partir du contexte assemblé
4. Citer → les sources sont extraites des éléments de contexte effectivement présentés au modèle
5. Évaluer → `demo/eval.py` évalue séparément la récupération, l’exactitude de la réponse, les citations, les refus, les hallucinations et la latence
Cette séparation constitue le fondement de toute la formation : le rapport de démonstration n’est pas qu’un pourcentage, il vous indique précisément où le système est faible.
3 · Diagnostiquer avant de modifier le code
| Observation | Couche probable | Premier élément à inspecter |
|---|---|---|
| Document attendu absent de `/api/v1/search` | Récupération | Index, segmentation, formulation de la requête, seuils, classement |
| Document attendu récupéré, mais non cité | Assemblage du contexte/des citations | Troncature du contexte et extraction des sources |
| Document cité, mais un fait requis manque dans la réponse | Génération | Prompt, organisation du contexte, comportement du modèle |
| Une question sans réponse reçoit une réponse assurée | Ancrage/sécurité | Instruction de refus, seuil de preuve, jeu d’évaluation |
| Réponse correcte mais réponse lente | Opérations | Latence du backend, appels au graphe, taille du contexte, concurrence |
4 · Exercice : récupérer ou générer ?
Scénario A : La réponse indique « 24 heures », mais `/api/v1/search` n’a jamais renvoyé `PR-QA-MRD-009`. Quelle a été la première défaillance ?
Scénario B : `PR-QA-MRD-009` figure bien dans les résultats, mais la réponse indique « 60 jours » alors que la preuve indique clairement « 45 jours ». Qu’est-ce qui a échoué ?
Scénario C : Une question sans réponse réelle reçoit une réponse détaillée et assurée, sans aucune source. Quel indicateur devrait détecter cela ?
5 · Votre contrat de réussite du prototype
Avant de lancer une nouvelle expérience, formulez ces cinq objectifs avec vos propres mots :
- Quelles catégories de questions doivent absolument fonctionner en premier ?
- Quel niveau de précision le premier MVP doit-il atteindre ?
- Quel est le taux minimal acceptable de sources retrouvées ?
- À partir de quel taux d’hallucination faut-il renoncer ?
- Quel temps de réponse un véritable employé tolérera-t-il réellement ?
Ne recopiez pas simplement les chiffres historiques de `demo-fixed` pour en faire vos objectifs. Il s’agit d’une base de discussion, pas d’une preuve que le système actuel est prêt pour la production.
Lien avec la mission
Vos utilisateurs sont des équipes QA, des autorités de contrôle, des fournisseurs et des auditeurs — des personnes qui se soucient peu de l’éloquence d’une réponse. Elles veulent savoir si celle-ci est conforme à la bonne SOP, à la bonne politique ou au bon questionnaire. C’est pourquoi notre première habitude d’ingénierie est la suivante :
Lorsqu’une réponse est erronée, vérifiez les éléments récupérés avant de toucher au prompt.
Prochaine action
Restez dans la démonstration désensibilisée et exécutez ces vérifications hors ligne :
cd demo
python eval.py verify
python test_scoring.pyOuvrez ensuite le rapport existant, demo-fixed.md, et trouvez deux défaillances : l’une où la récupération a fonctionné mais où la réponse reste partielle ou erronée, et l’autre où une source n’a jamais été récupérée.
Posez-moi vos questions sur tout ce qui reste flou — un terme, un indicateur ou un cas d’échec. Dans la prochaine leçon, nous suivrons une question de bout en bout dans le code réel et le dispositif d’évaluation.