Appearance
14.1.1 RAG 不是把资料塞给模型就行，为什么？
先给结论：RAG 的核心不是“把资料塞进去”，而是“把可用证据挑出来，并组织成可回答的问题上下文”。
很多人第一次接触 RAG，会很自然地形成一个直觉：
“我已经有很多文档了，把文档放进知识库，再把检索结果拼给模型，不就能回答问题了吗？”
这个理解并不完全错，但它漏掉了最关键的一步：从原始资料到可回答证据，中间还隔着检索、筛选、组织、约束几层处理。
资料本身只是原材料，不等于模型真的能稳定利用它。
RAG 真正解决的问题，不是“有没有资料”，而是“能不能把正确资料变成正确答案背后的证据”。
资料、证据、答案，是三层不同的东西
1. 资料不等于证据
资料是原始内容，证据是被挑选出来、可以直接支持某个结论的内容。
举个简单例子：
- 一整页产品手册是资料
- 其中一段版本说明、一段限制条件、一段错误处理，才可能组成回答某个问题的证据
如果你把整页都交给模型，模型确实有机会自己挑重点，但这个过程并不稳定。
而 RAG 的价值，恰恰是把“靠模型临场理解”改造成“靠系统先把证据准备好”。
2. 相关不等于可用
一个片段即使和问题相关，也可能仍然不能直接回答。常见原因包括：
- 只讲了主结论，没有讲限制条件
- 只讲了新版本能力，但问题问的是旧版本
- 只讲了流程中的一步，没讲前置条件
也就是说，相关性只是第一层筛选，可用性才是更关键的标准。
3. 检索到不等于能解释
就算正确片段已经进了上下文，如果它们彼此冲突、顺序混乱、缺少边界，模型仍然可能答偏。
所以 RAG 不只是“把片段召回”，还要把这些片段整理成：
- 可推理
- 可解释
- 可引用
的上下文结构。
为什么“塞资料”这件事经常失效
原因一：噪声会迅速膨胀
资料一多，噪声就会跟着增长。
模型虽然能一定程度上做筛选，但当无关信息、旧信息、冲突信息混在一起时，它并不会天然稳定地做出正确选择。
原因二：上下文预算是有限的
无论你用多长上下文的模型，真正高价值的上下文预算始终是稀缺资源。
如果你把大量泛化资料塞进去，真正关键的证据反而可能不突出。
原因三：系统需要可控，而不是偶然正确
即使某些时候“把资料一塞”也能答对，它依然不是一个可靠系统。
因为你无法解释它为什么答对，也无法保证它下次还答对。
而一旦系统要上线，靠偶然成功是没有价值的。
一个更务实的判断方法
当你拿到一批检索结果时，不要先问“资料够不够多”，而要先问下面三件事：
- 这些内容是否直接支持答案
- 这些内容是否包含关键条件和边界
- 这些内容能否被组织成一个清晰、无冲突的回答链条
如果其中任何一项做不到，就说明你得到的还不是“证据”，最多只是“相关资料”。
怎么把“资料”变成“证据”
更可靠的做法通常是这样一条链路：
- 先按结构和语义切块
- 检索出候选片段，而不是整批原始文档
- 用版本、时间、权限、产品线等 metadata 做第一轮过滤
- 必要时用重排把最支持答案的片段排到前面
- 在生成前把上下文整理成“主证据 + 补充说明”的形式
做到这一步，模型看到的就不再是一堆散乱资料，而是一组更容易被利用的回答证据。
常见误区
误区一：资料越多越好
资料越多，并不天然意味着答案越准。
更常见的情况是：资料越多，噪声越大，冲突越多，模型越容易抓错重点。
误区二：模型会自己筛选
模型确实能筛选，但这个筛选过程不稳定，也不透明。
RAG 的目的，就是把原本不可控的筛选，变成一个更可控的工程流程。
一句话总结
RAG 的价值不是“把资料塞给模型”，而是“把真正可用的证据挑出来，并组织成模型能稳定利用的上下文”。