14.2.2 为什么 RAG 的核心不是某个单点技术，而是整条链路协同？

先给结论：RAG 的瓶颈，通常不在某一个模块，而在模块之间有没有协同起来。检索、过滤、重排、上下文构造、生成，只要其中一环失效，整体效果就会被拖下去。

很多人做系统时会不断寻找“关键技术点”：

• 是不是 embedding 不够好
• 是不是 reranker 不够强
• 是不是模型不够大
• 是不是 prompt 写得不够精细

这些点都重要，但它们都不是决定系统成败的唯一变量。
真实系统里，更常见的情况是：某个局部其实已经不差了，但整体依然不稳定，因为链路没有协同起来。

为什么单点优化经常没有想象中有效

你会看到很多类似情况：

• 检索做得不错，但切块破坏了语义边界
• 候选找得不少，但 metadata 不完整，过滤做不了
• 重排质量还可以，但上下文组织混乱，模型仍然抓错重点
• 模型能力很强，但证据本身不够完整，最终还是答偏

这说明一件事：
RAG 不是一个“谁最强谁赢”的单点竞赛，而是一条证据流转链。

从原始数据到最终答案，中间至少经过这些阶段：

原始数据 -> 清洗与切块 -> 建索引 -> 召回 -> 过滤/重排 -> 上下文构造 -> 生成

任何一环短板明显，后面再强也只能被动补救。

什么叫“链路协同”

所谓协同，不是空泛地说“大家都要配合”，而是每一层都要与上下游对齐。

至少包括下面这些关系：

• 切块方式要匹配文档结构和检索目标
• metadata 设计要匹配权限、版本、范围过滤需求
• 召回数量要匹配重排能力和上下文预算
• 最终 prompt 要匹配证据组织方式

如果这些关系没有对齐，就会出现一种很典型的情况：
每个模块单独看都好像说得过去，但整体用起来总是不稳。

怎么判断问题是不是出在“链路协同”上

遇到效果问题时，你可以先问下面几个问题：

1. 问题更像是召回没找到，还是找到了但没用好
2. 候选里有没有真正正确、足够完整的证据
3. 进入生成阶段的上下文是否已经被整理成可解释结构
4. 同一个失败案例能否稳定复现，并拆解到具体环节

如果这些问题很难回答，通常说明系统还没有形成真正的链路协同。

一个典型的错误优化顺序

很多项目会这样推进：

1. 发现答案不准
2. 先换模型
3. 发现还是不稳
4. 再加重排
5. 发现延迟变高
6. 最后才回头补日志、评测和数据治理

这个顺序的问题，不是这些动作本身错，而是它们都发生在系统仍然不可解释的时候。
于是每加一层复杂度，排障难度就再上一个台阶。

更合理的顺序通常应该是：

1. 先看数据和切块是否健康
2. 再看召回是否覆盖关键证据
3. 再看过滤、重排和上下文组织是否到位
4. 最后才引入更多复杂能力

一句话总结

RAG 不是单点技术竞赛，而是链路协同工程。系统稳定性来自每一步都可解释、可评估、能和上下游对齐。