知识工程进阶之三：RAG 真正难的不是搜到，而是组好上下文
搜到相关材料只是开始。
真正难的是，怎么把这些材料组装成模型一看就能用、而且不容易误解的上下文包。
先给结论
RAG 最容易被低估的一步，是上下文装配。
很多系统检索没问题，但回答还是不稳，常见原因包括：
- 检索结果顺序不对
- 规则和事实混在一起
- 同类片段重复
- 旧版本和新版本同时塞进来
- 当前问题真正需要的证据被噪声盖住
也就是说，RAG 的难点，很多时候不是 retrieval，而是 assembly。
一包好上下文，至少要有四种成分
1. 当前任务
现在要解决的到底是什么问题。
这部分决定检索结果该围绕什么组织。
2. 规则约束
哪些规则必须优先遵守。
例如只能基于给定资料回答、不能编造、不确定要说明。
3. 证据片段
真正支撑回答的文档内容。
这部分应该是最有信息密度的。
4. 来源和版本信息
告诉模型这些内容来自哪里、哪个版本、可信度如何。
否则模型很容易把冲突材料混成一团。
为什么“把 top-k 全塞进去”很危险
因为 top-k 只是检索得分高，不等于最适合最终回答。
常见问题包括：
- 多个 chunk 其实表达的是同一件事
- 一个重要 chunk 被几个次优 chunk 挤掉
- 不同文档的立场冲突，却没有说明优先级
所以 assembly 阶段至少应该做：
- 去重
- 压缩
- 排序
- 规则前置
- 证据与来源标注
知识工程和上下文工程在这里会合
RAG 一旦进入实际系统，就不再只是“搜文档”。
它开始变成上下文工程的一部分。
因为最终你要给模型的，不是“检索结果列表”，而是：
- 当前问题
- 规则
- 证据
- 结构
这些东西一旦装不好，哪怕召回很准，结果也会不好看。
一个很实用的经验
别急着增加更多文档，先看：
- 当前上下文里有多少重复
- 当前上下文里有多少无用背景
- 当前上下文里有没有证据排序错误
很多 RAG 优化，不是“再加数据”，而是“把已有数据组得更合理”。
一句带走
RAG 的上限，不只是由检索决定，还由上下文装配决定。
搜到只是起点，装好才是能力。