14.2.3 一个成熟 RAG 系统最重要的设计原则有哪些？

先给结论：成熟 RAG 的核心原则，不是“功能越多越好”，而是“可用、可控、可评测、可更新、可回退”。

如果前面两篇是在讲为什么要先稳住系统，那么这一篇就是把“稳住系统”具体拆开。
下面这些原则，不是用来背诵的，而是你在做设计取舍时可以直接拿来判断的标准。

1. 可观测优先

没有可观测性，问题就只能靠猜。
所以第一原则不是“先把功能做满”，而是“先让系统内部发生了什么能够被看到”。

至少建议记录：

• 用户问题
• 检索返回了哪些候选
• 每条候选的关键 metadata
• 最终拼给模型的上下文
• 最终答案和引用来源

只要这些信息缺失，排障成本就会非常高。

2. 评估先于优化

没有评估，就没有真正意义上的优化。
你做的每一次改动，都应该可以被比较，而不是只能靠印象判断。

哪怕一开始没有完整评测体系，也至少应该先建立一组最小评测集，用来覆盖：

• 高频问题
• 容易出错的问题
• 权限和范围敏感的问题
• 更新后容易回归的问题

只要这个基础在，系统就具备了持续改进的可能。

3. 证据优先于模型

答案质量的上限，很大程度上由证据质量决定。
如果关键证据都没稳定进入上下文，那么再强的模型也只是更流畅地输出不完整答案。

所以当团队讨论“是不是该换模型”时，更值得先问的是：

• 关键证据是否稳定可召回
• 证据是否足够完整
• 证据是否带着正确边界和时间信息

只有这些基本成立后，模型能力才真正开始成为主要变量。

4. 更新与回退必须内置

成熟系统必须假设这些事情一定会发生：

• 文档会更新
• 数据会误入库
• 某次索引构建会导致回归
• 某条规则会在未来失效

所以更新策略和回退能力不是附加项，而是系统生命线。

如果系统不能快速失效旧知识、重建索引、对比新旧结果、必要时回滚，那它迟早会在持续运行中失稳。

5. 权限与范围控制必须前置

生产环境里，权限和范围是刚性约束，不能等到生成之后再补救。

这条原则非常重要，因为错误内容一旦进入上下文，就已经构成风险。
所以更合理的做法是：

• 在检索前或检索中就做范围约束
• 让 metadata / payload 过滤成为索引设计的一部分
• 把租户、版本、产品线、地域、状态等边界前置

这样系统才是真正可上线的。

6. 复杂能力延后

重排、多路召回、多模态、Agentic Retrieval 都是有价值的。
但它们都应该建立在“基础链路已经稳定”的前提上。

这条原则不是保守，而是为了控制复杂度增长速度。
成熟系统不是“能堆多少能力”，而是“每加一层复杂度，都知道它在解决什么问题，以及怎么证明它真的有效”。

7. 参数服务于结构，不要反过来

像 chunk_size、overlap、TopK 这些参数都很重要，但它们应该服务于数据结构、检索策略和上下文预算，而不是被当成一切问题的总开关。

如果系统性问题还没解决，就过早沉迷参数微调，通常只会在局部补丁上反复打转。

8. 优先建设最小可维护闭环

一个系统真正进入“可持续优化”阶段的标志，不是它已经很强，而是它至少具备下面这个最小闭环：

• 能稳定跑通
• 能复现问题
• 能记录关键过程
• 能比较改动前后
• 能在出问题时回退

只要这个闭环建立起来，系统就能逐步变强；
如果这个闭环没有建立，再强的局部能力也很难长期稳定。

一句话总结

成熟 RAG 的设计原则，可以浓缩成一句话：先让系统可控，再让系统变强。
可观测、可评测、可更新、可回退，是长期稳定的真正基础。