RAG Formation · Leçon · Fiabilité et préparation du produit
Latence, coûts et observabilité
Arbitrer entre qualité de réponse, temps de réponse, coût des tokens, appels au graphe et visibilité opérationnelle.
$ lesson --status
▸ course RAG Formation
▸ lesson 14 / 16
▸ phase Fiabilité et préparation du produit
▸ 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 disposerez d’un budget de performance MVP et d’une liste de contrôle de télémétrie, chaque ligne étant identifiée comme mesurée ou supposée.
Regarder la vidéo
1 · La compétence
Ouvrez un rapport et déterminez quels budgets — latence, appels backend, taille du contexte, appels au modèle — sont réellement mesurés et lesquels ne sont que des hypothèses.
- p50 et p95 : le temps de réponse médian et le temps de réponse dans la longue traîne. Suivez les deux : une moyenne rapide peut cacher quelques requêtes extrêmement lentes. Un piège propre à cet outil : p95 n’est calculé que pour les exécutions en mode answer — une exécution purement en mode retrieval ne rapporte que p50 (voir section 2).
- Facteurs de coût : appels d’embeddings, appels LLM du graphe, génération des réponses, appels de l’évaluateur et volume de contexte injecté.
- Le seul vrai levier actionnable :
--graph-topk(20 par défaut). LightRAG effectue une extraction de mots-clés par LLM ainsi que plusieurs parcours de graphe par requête ; le réduire est donc un compromis réel et mesurable entre la profondeur du signal du graphe et la latence. Il n’existe aucun moyen de désactiver entièrement LightRAG sur une requête en direct dans cette base de code — ne cherchez pas un interrupteur de coût qui n’existe pas. - Observabilité : traces, indicateurs et journaux structurés, suffisamment détaillés pour expliquer ce qui s’est produit sans divulguer de secrets ni de contenu documentaire.
2 · Exécuter la boucle de preuve
cd demo
python3 eval.py run --mode both --workspace meridian_demo --tag lesson-14-latencyIl s’agit de la même base de référence eval_set.yaml que celle utilisée dès la leçon 4 — comparez-vous à ce résultat, pas à un chiffre nouveau et inconnu. Utilisez --mode both, pas --mode retrieval seul : le résumé agrégé de récupération ne rapporte jamais que latency_p50_s ; p95 n’existe que dans le résumé de réponse, qui nécessite le mode answer pour exister. Capturez, par question et en agrégat : results[].answer.stats.total_context_chars, results[].answer.stats.graph_context_chars (le champ équivalent en mode retrieval porte un nom différent — results[].retrieval.counts.graph_chars — les deux modes le calculent et le nomment indépendamment, ce n’est pas un bug de l’outil), summary.answer.latency_p50_s / latency_p95_s, et summary.retrieval.latency_p50_s. Essayez ensuite de réduire --graph-topk (20 par défaut) sur une seconde exécution et comparez — ne consignez jamais de secrets ni de contenu sensible brut.
N’oubliez pas qu’une latence moyenne flatteuse peut cacher une longue traîne assez lente pour faire échouer un pilote.
3 · Fiche de décision
| Preuve de référence | Une hypothèse/modification | Indicateur | Contrôle de régression | Conclusion délimitée |
|---|---|---|---|---|
| _____ | _____ | _____ | _____ | _____ |
4 · Exercice de récupération
Question : Votre médiane est excellente, mais p95 est mauvais. Que devez-vous réellement communiquer ?
Lien avec la mission
Une équipe pilote n’a pas seulement besoin de réponses correctes : elle doit savoir que le système ne la ruinera pas, ne la fera pas attendre et ne deviendra pas une boîte noire dès que la qualité diminuera.
5 · Livrable et prochaine action
- Enregistrez la sortie de commande ou le rapport.
- Complétez la fiche de décision.
- Notez un cas d’échec et un élément à vérifier ensuite.
Le livrable : un budget de performance MVP et une liste de contrôle de télémétrie, chaque élément étant identifié comme mesuré ou supposé.
Prochaine étape : leçon 15 — sécurité, permissions et limites de déploiement.
Posez-moi vos questions sur les preuves, l’indicateur, le cas d’échec ou l’expérience à tenter ensuite. Je suis votre enseignant pour cette formation.