从一次答非所问说起
企业知识库上线后，常见一幕是：员工问报销流程，模型答得流畅，却把旧版本制度当成现行规则。问题未必出在生成端。资料就在库里，只是没有被准确找到，或者找到了却没有被正确放进上下文。
检索增强生成要做的事并不神秘：先把问题转成检索请求，从可维护的资料集中取回相关片段，再让模型基于这些片段组织回答。它把一部分“记忆”交给外部知识库，让更新内容不必反复训练模型。听起来像补一条搜索链路，真正麻烦的却在链路之间。
检索不是搜到就行
把检索增强生成理解成“接一个搜索框”，往往会在真实问题前露怯。文档切得太碎，上下文断掉；切得太整，噪声又被一起带进模型。用户问“试用期请假怎么算”，检索若只匹配“请假”，可能漏掉“试用期”这个限定；若只看字面，又会错过制度里写成“见习期”的表述。
- 切分要兼顾段落完整与主题集中，不能只按固定字数硬切。
- 查询需要处理同义表达、缩写和多轮追问，避免把用户的省略当成完整问题。
- 召回结果要控制噪声，相关性不足的片段宁可少放，也不要堆满上下文。
回答要留下可核对的痕迹
企业场景里，流畅不是终点。实际的要求是：回答能指向来源，找不到依据时愿意说找不到。引用不是装饰，它让提问者能回到原文核对，也方便维护者发现知识库里的过期内容。若检索结果彼此冲突，模型应当暴露冲突，而不是自行调和成一个看似完整的结论。
这也解释了为什么检索增强生成不是一次接入就结束的工程。资料更新、权限过滤、片段质量、评估问题集，都会影响最终体验。评估时若只看回答是否通顺，可能漏掉“答对了但引错资料”这类问题；若只看检索命中，又可能忽视生成阶段的遗漏和误读。
它的边界同样值得说清
检索增强生成不负责让模型变全能。资料里没有的内容，它无法凭空变出可靠答案；检索质量差，生成端措辞再顺也只是把错误包装得更顺。它面向的是知识相对明确、更新频繁、需要追溯来源的场景，而不是所有问答的通用解。
所以，判断一套方案是否成熟，不妨少看演示时的漂亮回答，多问几个笨问题：资料变了，它能不能跟上？答案错了，能不能定位到哪一段检索或哪一句生成出了问题？用户追问时，它是否还记得前面的限定？这些细节不显眼，却决定了检索增强生成是停留在概念里，还是能进入日常流程。