先看一个不陌生的场景
员工在内部搜索框里问“差旅报销需要哪些附件”，系统很快给出一段完整回答。看上去可用，但真到提交时，问题来了：这段回答依据的是哪份制度？版本是否过期？如果有人只截取其中一句转发，责任边界又在哪里。生成式模型擅长把话说顺，却不天然擅长证明自己为什么这么说。检索增强生成进入企业系统，首先补的往往不是“回答得更漂亮”，而是把回答落回可查的文本。
它到底多做了哪一步
从流程看，检索增强生成把一次问答拆成两段：先从文档、知识库或业务系统中取回与问题相关的内容，再让模型在这些内容的约束下组织答案。听起来像加了一个搜索框，实际麻烦都在中间。文档怎么切分，问题怎么改写，召回多少条，重复内容怎么合并，互相冲突的段落该信哪一条，都会影响最终输出。模型并没有因此变得全知，它只是从“凭参数记忆回答”转向“围绕给定材料回答”。这个转变带来的价值是引用和核查有了落点，代价是系统多了检索、过滤和内容治理的工程量。
引用不是装饰
很多产品把“带来源”当成一个界面功能：答案下面挂几条链接。真正有用的引用，需要能定位到段落，能说明该段落与问题的关系，还要在原文更新后及时失效或重算。否则用户看到来源，却没有能力判断它是否支撑了结论，引用就会变成一种安心感装饰。对编辑和维护者来说，这也是新的工作：同一主题的多份文档需要收敛口径，过期附件要清理，权限边界要在检索层就生效，而不是等答案生成后再遮挡。检索增强生成把知识治理的问题提前暴露出来，这未必轻松，却比把矛盾藏进模型参数里诚实。
边界在哪里
它适合材料相对明确、问题有文本依据、答案需要回溯的场景，比如制度查询、产品文档问答、流程说明。反过来，如果知识本身没有沉淀，文档长期失修，或者问题需要跨系统实时计算，单靠检索增强生成并不能自动解决。另一个常被忽略的点是评估：不能只看回答读起来是否顺畅，还要看引用是否命中、是否完整、是否越权、是否在材料不足时敢于说“没有找到”。这类系统上线后，维护文档和观察失败样本的时间，往往比调提示词更长。