从“它知道”到“它找得到”
很多团队第一次接触检索增强生成，是被一个问题逼出来的：模型回答得很流畅，却把公司制度说错，或者引用了过期的产品说明。它的基本动作并不神秘：先把问题改写成便于检索的查询，从文档、FAQ、工单或内部知识库里取回相关片段，再把这些片段和原问题一起交给生成模型。与单纯依赖参数记忆相比，检索增强生成把“知道”拆成了“找得到”和“说清楚”两步。这两步任何一步松动，最终答案都会显得不可靠。
检索层常常决定体验
实际落地时，限制常常不在模型写作，而在知识库是否可用。文档切得太碎，语义会断；切得太大，噪声会挤占上下文。标题、更新时间、适用范围、权限标签这些元数据如果缺失，检索就只剩模糊的相似度。用户问“新版本怎么配置”，系统若不能识别版本和角色，找到的可能是旧说明。
还有一个容易忽略的细节：提问方式。员工的真实问法往往口语、省略、带上下文，而知识库标题偏正式。查询改写不是装饰，它决定检索器是否找对入口。检索增强生成要稳定，通常需要把查询理解、召回、重排和上下文组装当成一条链路来调试，而不是只盯着最终答案。
答案有出处，不等于答案可信任
引用来源能降低核验成本，但不能自动解决冲突。内部文档可能互相矛盾，检索会把这些矛盾一起带上来；生成模型若没有被告知如何处理冲突，容易把不同版本的表述揉成一句看似完整的回答。更稳妥的做法是让系统在证据不足或冲突明显时明确说明不确定性，而不是强行补全。
- 先看检索结果是否覆盖正确段落，再看答案是否忠于这些段落。
- 把权限过滤放在检索之前，避免“先看到再隐藏”的路径。
- 保留问题、召回片段和最终回答的对应关系，方便定位是知识问题还是表达问题。
这也是我判断检索增强生成是否值得投入的一个尺度：它适合知识更新快、答案需要可追溯、问题边界相对清楚的场景；如果任务更依赖跨文档推理或对沉默信息的理解，单靠检索拼接未必够用。先拿真实问题做一小套评估集，观察召回、引用和拒答表现，再决定是否扩大范围，通常比先讨论模型参数更实际。