一份产品手册改了三个版本，客服仍在群里问：新包装的退换规则到底以哪份为准？把这个问题丢给大模型，回答可能很流畅，却未必知道最新版本。检索增强生成要处理的，正是这类“模型不知道你仓库里刚更新了什么”的尴尬。
它先去找材料，再组织回答
大模型的参数在训练完成后基本固定，企业内部文档、流程说明、会议纪要却持续变化。检索增强生成的做法并不神秘：先把问题拿去检索相关片段，再把片段和问题一起交给模型，让回答落在可追溯的材料上。模型负责组织语言，资料负责提供依据。
这听起来像给模型外接了一个资料柜。真正麻烦的地方在柜子内部：文档怎么切分，切得太碎会丢上下文，切得太整又容易把无关内容带进来；问题怎么改写，用户问“报销多久到账”，检索却要面对“费用支付周期”这类不同表述；召回哪些片段，数量少了可能漏掉关键条款，数量多了又会挤占上下文。
回答有引用，不等于自动可信
不少演示停留在“回答后面挂了几个链接”。链接只能说明材料被取过，不能说明材料被正确理解。片段之间可能互相矛盾：旧版制度与新版通知并存，摘要与原文口径不同。此时检索增强生成需要把冲突暴露出来，而不是让模型自行调和成一句看似圆满的话。权限也是同一层问题：检索阶段若不区分可见范围，回答就可能把不该出现的内容拼进去。
因此，评价一个知识库问答，不能只看回答是否顺滑。还要看它能否说清依据来自哪一段，找不到材料时是否愿意承认不知道，文档更新后能否及时反映，以及面对同一问题的不同问法是否稳定。
工程细节占据的位置
把检索增强生成当成一条提示词模板，往往会很快遇到瓶颈。实际工作包括：给文档建立可维护的元数据，处理表格与附件的解析，设计增量更新，记录检索与回答的中间结果，留出人工校正入口。这些环节不显眼，却决定了系统能不能长期用。
- 文档侧：版本、来源、生效时间要能追溯，避免旧材料混入。
- 检索侧：保留改写前后的查询，观察漏召回发生在哪一步。
- 回答侧：引用要能定位到片段，低置信度时给出边界。
- 运营侧：把用户追问和纠错沉淀为新的检索线索。
我的判断是，它更像一项信息治理工作，而不是一次模型接入。它把问题从“模型会不会说”拉回到“资料是否找得到、对得上、管得住”。当企业愿意在这个层面投入，回答的可靠性才有落脚点；否则，再多引用样式也只是给不确定的答案套了层外壳。