Comment un système RAG doit échouer : dégrader ou refuser clairement | Leçon 13

Dans la Leçon 13 de RAG Formation, nous concevons le comportement d'un système RAG lorsqu'une de ses dépendances tombe en panne — Qdrant, Meilisearch, l'index de graphe, le service d'embeddings, l'appel de complétion, Redis.

La question d'ingénierie n'est pas de savoir si une dépendance tombera en panne. C'est de savoir si la panne reste contenue, et si la réponse du système correspond réellement à ce qui vient de se casser.

Deux pannes appellent deux réponses honnêtes différentes. Si l'index vectoriel tombe, la recherche par mots-clés et la recherche dans le graphe continuent de fonctionner : la dégradation maîtrisée consiste à continuer de répondre, en précisant que les résultats sont actuellement limités aux mots-clés. Si le service de complétion tombe, il ne reste plus de chemin vers une réponse étayée : il faut alors échouer par fermeture, avec un refus clair, et non en inventer un qui aurait l'air normal.

Une réponse normale sans preuve n'a jamais été une dégradation maîtrisée. C'était seulement une réponse dangereuse, mieux présentée.

Site du cours :
https://shenyi.dev/fr/ai-lab/rag-formation/lessons/0013-failure-isolation-and-graceful-degradation

Dépôt GitHub :
https://github.com/scheffershen/yt-rag-formation/

Chapitres

• 00:00— Phase 3 terminée : le jalon de la réponse fondée
• 00:14— Début de la phase 4 : fiabilité et maturité produit
• 00:31— Titre : isolation des pannes et dégradation maîtrisée
• 00:43— Matrice des dépendances : deux réponses honnêtes à la panne
• 01:20— Conclusion : une panne contenue, pas une réponse dangereuse mieux présentée

#RAG #IsolationDesPannes #DegradationMaitrisee #IngenierieDeLaFiabilite #IngenierieIA #RAGFormation