先看一个常见场景：内部系统里问“这项流程上周改到哪里了”，模型若只凭参数记忆，容易给出看似完整却无法核对的答案。工程师把最新文档检索出来，连同问题一起交给模型，回答才落到具体条款。这个动作，就是检索增强生成。
它并不神秘。检索端先从可访问的资料中找候选片段，生成端再把问题、片段和指令组织起来。价值在于把“记住什么”与“能否查到”拆开。模型不必把所有知识压进参数，资料更新也不必等待重新训练。但拆开之后，责任也分开了：检索没找到，生成再流畅也缺依据；片段找到了，模型读错上下文，答案仍会偏。
资料进来了，答案就可靠吗
不少人把这件事理解成给模型配一个资料库，仿佛接上就能少犯错。实际落地时，影响结果的环节不少。文档切分过碎，语义被切断；切分过长，关键句被淹没。召回阶段看的是相似度，未必等于答案所需；重排能补一些，但也会把表面相关的内容推到前面。提示词里如何要求“只依据材料回答”，如何定义“材料不足时拒答”，同样关键。
一个容易被忽略的点是引用。回答后面附上链接或段落，不自动等于可信。链接可能只支持句子里的一小部分，也可能与结论方向相反。可用的做法是把引用粒度做细，要求模型在关键判断处对应来源，并在界面上让用户能快速回看原文。对内部知识库而言，权限过滤要在检索前完成，而不是等答案生成后再遮盖。
不是所有提问都值得先查一遍
检索增强生成有适用边界。稳定的通用知识、纯语言改写、格式转换，未必需要先检索；资料变化快、答案需要溯源、内部术语多的场景，检索可以优先考虑。全都先查一遍，会增加延迟和成本，也可能把不相关片段塞进上下文，反而干扰回答。判断标准可以朴素一些：这个问题如果答错，代价是什么？用户是否需要看到依据？资料是否比模型参数更新？
另一个现实问题是维护。知识库不是一次性工程。文档有版本，页面会迁移，权限会变化。检索系统需要能处理失效链接、重复内容和过期条目。否则，模型面对一堆互相矛盾的材料，只能给出看起来合理的折中答案。清理、标注和回退应当成为日常动作。
把“不知道”留在系统里
我倾向于把拒答能力看作检索增强生成的一部分，而不是体验瑕疵。材料不足时明确说不足，给出已查到的范围，请用户补充条件，让系统保留不知道的余地。工程上可以设置检索命中阈值、答案覆盖检查和人工兜底入口；产品上则要允许回答“这需要确认”。这套设计不会让系统显得无所不能，却能让使用者知道什么时候该相信它。
回到开头那个停顿：检索增强生成真正改变的，不只是答案里多了几段资料，而是把回答变成了可检查的工作流。检索质量、生成约束、引用呈现和拒答机制彼此咬合，缺一块，答案就可能回到“听起来对”的状态。对企业来说，先想清楚哪些问题必须可追溯，再决定资料怎么组织、系统何时停手，这件事本身就需要产品与工程一起坐下来讨论。