RAG Formation · 第 14 课 · 可靠性与产品就绪

延迟、成本与可观测性

在回答质量、响应时间、Token 成本、图调用和运维可见性之间取得平衡。

$ lesson --status
▸ course RAG Formation
▸ lesson 14 / 16
▸ phase 可靠性与产品就绪
▸ status 已完成
● build → measure → learn

独立课程

在这里学习完整课程并检验你的理解。

RAG Formation 的 16 节课程内容已完成。本页包含完整课程内容、本地参考资料和可直接在浏览器中完成的即时练习。

本课的具体收获

学完本课，你会有一份 MVP 性能预算和一张遥测清单，并为每一项标记“已测量”或“仅假设”。

观看讲解视频

1 · 核心技能

打开一份报告，明确哪些预算——延迟、后端调用、上下文大小、模型调用——是真正测量出来的，哪些只是你的假设。

p50 和 p95：分别是中位响应时间和慢尾响应时间。两者都要跟踪——平均值很快，也可能掩盖少数极慢的请求。这套评估工具有个特别之处：p95 只有在跑 answer 模式时才会计算——纯 retrieval 模式只会报告 p50（见第 2 节）。
成本驱动因素：嵌入调用、图谱 LLM 调用、答案生成、评审调用，以及你塞入上下文的大小。
唯一真正能调的杠杆：--graph-topk（默认 20）。LightRAG 每次查询都要做基于 LLM 的关键词抽取，还要做好几次图遍历，调低这个值就是用图谱信号的深度换延迟，效果真实可测。这套代码里没有办法在一次线上请求中把 LightRAG 整个关掉——不要去找一个并不存在的成本开关。
可观测性：结构化的追踪、指标和日志，细致到足以解释发生了什么，同时不泄露密钥或文档内容。

主要阅读：OpenTelemetry《文档》

2 · 运行证据闭环

cd demo
python3 eval.py run --mode both --workspace meridian_demo --tag lesson-14-latency

这跟第 4 课用的是同一份 eval_set.yaml 基线——要跟那个结果对比，不是凭空冒出来的新数字。一定要用 --mode both，别只用 --mode retrieval：检索汇总报告永远只有 latency_p50_s，p95 只存在于 answer 汇总里，而这需要跑 answer 模式才会有。要记录的字段：results[].answer.stats.total_context_chars、results[].answer.stats.graph_context_chars（检索模式里同样意思的字段名不一样，叫 results[].retrieval.counts.graph_chars——两种模式各自独立计算、各自命名，这不是评估工具的 bug）、summary.answer.latency_p50_s / latency_p95_s，以及 summary.retrieval.latency_p50_s。然后把 --graph-topk（默认 20）调低再跑一次，比较结果——密钥和原始敏感内容永远不要记进日志。

记住：好看的平均延迟可能掩盖足以拖垮试点的慢尾。

3 · 决策工作表

基线证据	一个假设/改动	指标	回归检查	有边界的结论
_____	_____	_____	_____	_____

4 · 检索练习

问题：中位数看起来很好，但 p95 很慢。实际应该报告什么？

企业场景连接

试点团队不仅需要正确答案，还需要知道系统不会让他们破产、不会让他们长时间等待，也不会在质量下降时变成一个黑盒。

5 · 交付物与下一步

保存命令输出或报告本身。
填写决策工作表。
写下一个失败案例，以及下一项要验证的内容。

交付物是一份 MVP 性能预算和遥测清单，并为每一项标记“已测量”或“仅假设”。

下一步：第 15 课将讲安全、权限和部署边界。

如果对证据、指标、失败案例或下一步尝试有疑问，尽管继续问我。 这门课我就是你的老师。

← 上一课参考资料下一课 →