14.2.1 做 RAG 时，为什么应该优先保证“可用、可控、可评测”，再追求“高级”？

先给结论：高级能力只有建立在“可用、可控、可评测”的基础上，才真正有价值。否则它们大概率只会放大系统的不确定性。

很多团队做 RAG 时，最容易兴奋的部分往往是那些“高级能力”：

• 多路召回
• 重排
• 查询改写
• Agentic Retrieval
• 多阶段规划式检索

这些能力当然有价值，但它们有一个共同前提：
基础链路必须先站稳。

如果基础链路都还不稳定，就急着加复杂能力，结果通常不是系统更强，而是系统更难解释。

为什么要先保证“可用”

可用的意思不是“偶尔演示能跑通”，而是：

• 用户能稳定提问
• 系统能稳定检索到候选证据
• 多数典型问题能得到基本可接受的答案
• 失败时也能暴露出明确的问题信号

没有这个基础闭环，后续一切优化都没有稳固落点。
你甚至无法判断某次改动到底有没有真正提升系统。

为什么要先保证“可控”

可控意味着：当系统出问题时，你知道该查哪一层。

如果一个系统做不到这一点，你就会不断陷入这些局面：

• 回答不准，但不知道是召回错了还是生成错了
• 某次改动后效果变差，但不知道是数据、参数还是提示词导致的
• 新文档上线后结果波动，但你没有证据链去回溯

所以可控性的本质，是给系统建立“可解释的内部结构”。

这通常依赖于：

• 检索日志
• 上下文快照
• metadata 可视化
• 问题复现链路
• 改动版本对比能力

为什么要先保证“可评测”

评测的作用，是把“感觉系统变好了”变成“能证明它变好了”。

没有评测时，系统优化很容易变成两种错觉：

• 某次演示效果不错，就误以为整体提升了
• 某几个用户反馈变差，就误以为全部回退了

但真实系统从来不是靠印象优化的。
你至少要有一组最小评测集，去回答两个问题：

1. 当前系统在哪些问题上稳定失效
2. 某次改动后，这些问题是变好还是变差

为什么“高级能力”必须后置

因为高级能力几乎都会引入新的复杂度：

• 更多模块
• 更多参数
• 更多调试维度
• 更高延迟和成本

如果你现在连“为什么这个问题答错了”都还说不清，那么继续加复杂度，只会让问题更难定位。

更合理的优先级通常是：

1. 先把数据质量、切块、metadata、基础检索跑顺
2. 再补日志、评测集、问题复现能力
3. 然后再考虑混合检索、重排、查询改写
4. 最后再考虑更复杂的 Agent 化检索或多阶段链路

一个很实用的判断标准

你可以用一句话判断自己现在是不是该追求“高级能力”：

如果你还不能稳定说明“为什么这个问题答错了”，那就还没到该上复杂能力的时候。

这句话非常重要，因为它把注意力从“还能加什么功能”拉回到“系统是否已经可解释”。

一句话总结

先稳后强，永远比先强后稳更可靠。先把系统做成可用、可控、可评测，再追求高级能力，才是长期可持续的路线。