不少人对检索增强生成的想象很直接：模型不知道，就去知识库里查，查到再答。这个描述没错，但它省略了中间那段容易出问题的路。上线后，用户看到的通常不是“查没查到”，而是答案读起来顺不顺、引用能不能对上、下一次问法变了还稳不稳。
先把“查什么”说清楚
这套方法的一个难点不在生成，而在检索前的意图整理。用户的问题经常带着上下文、省略和口语，直接拿去匹配文档，命中率未必理想。一种稳妥的做法是先做查询改写：把模糊指代替换掉，把长问题拆成可检索的片段，再决定去哪些资料里找。这里没有万能配方，业务问题越垂直，越需要把术语、同义词和排除条件写进检索策略。
文档切分也常被低估。切得太碎，上下文断了；切得太整，召回又不够准。实际处理时，除了按标题和段落切，还要保留表格说明、版本信息和适用范围，否则模型拿到的是一段“看起来相关”的文字，却不知道它是否仍然有效。
引用不是装饰，是验收线
这套方法容易给人安全感：答案后面挂了来源，似乎就可信了。但引用是否真的支撑结论，需要单独检查。一个常见问题是，模型引用了文档，却把文档里的条件去掉了；另一个问题是，多个来源说法不一致时，答案把它们揉成一句话，读者看不出分歧。因此，产品层面要把“引用定位”做扎实：能回到原文哪一段、哪一句，是否覆盖了问题中的限制条件。没有这层验收，引用很容易变成装饰。
它适合处理“有据可查”的问题
检索增强生成并不是把所有问答都变准的开关。资料清楚、更新可控、答案需要出处的场景，是它发挥价值的地方；开放式的判断、资料本身缺失或冲突的问题，它只能把边界暴露出来。团队在使用时，不妨先接受一个事实：它解决的是“让回答有依据”，不是“让所有问题都有答案”。把无法回答的情况设计清楚，再考虑生成；强行凑一段流畅文字，并不值得。
- 问题改写：先处理指代、范围和同义词，再进入检索。
- 文档治理：切分时保留条件、版本和上下文，别只留结论。
- 引用验收：能定位到原文，并说明答案依赖了哪条限制。
- 边界管理：资料不足时允许说“不知道”，并给出下一步。
回到使用现场，检索增强生成的价值不在演示时的那一次惊艳，而在重复提问、资料更新和错误暴露之后，系统还能不能给出可核对、可维护的回答。把检索、引用和边界当作同一件事来处理，它才不只是一个听起来合理的技术名词。