内部知识库里明明存着那份文档，模型却答得含糊，末了还补上一句听起来很顺、实际并不存在的说法。很多团队正是在这种尴尬里第一次听说检索增强生成，也第一次对它产生过高的期待。
把它理解成「接一个向量库就完事」，多半会失望。它的效果上限，往往不由模型决定。
它做的事其实很朴素
拆开看，检索增强生成并不神秘：在模型开口之前，先从外部资料里找出与问题相关的若干片段，把这些片段连同问题一起交给模型，让它在给定材料的范围内组织答案。检索负责找到，生成负责表达。顺序很重要——先有材料，后有措辞。
这也解释了它为什么有用。模型参数里存的是训练时被压缩过的、平均化的印象，覆盖面广，但颗粒度粗，而且停留在某个时间点之前。检索拿到的则是一份具体的、可以随时更新的、能指出出处的文本。前者擅长语言与推理，后者擅长事实与细节，两者拼接起来，才谈得上可用。
真正难的地方在检索那一侧
实际用起来，出问题的环节大多不在生成端。回答跑偏，往往是因为交给模型的材料本身就不对。
- 切得太碎，一段话丢了主语和前提，检出来也读不明白；
- 切得太长，噪声跟着一起进来，真正相关的那两句被埋掉；
- 提问的说法和文档的写法对不上，字面相似度直接失效；
- 文档改了，索引没跟上，模型拿到的是旧版本。
这些问题都落在检索一侧，模型再怎么调整提示词也补不回来。所以做这类系统时，先盯着检索命中情况看，比盯着回答措辞看更有意义。
它能做什么，不能做什么
检索增强生成把「模型不知道」转换成「我们没检索到」，这一步很有价值，但并没有消除不确定性。资料本身写错了、检索到两段互相冲突的内容、问题需要跨多份文档做综合推断，模型仍然可能给出似是而非的结果。所以带出处的引用不该被视为装饰，它是让人能够回去复核的接口。
还有一点常被忽略：它解决的是知识时效与私有知识接入的问题，不解决推理能力。需要多步计算、需要理解隐含条件、需要从零做判断的问题，检索帮不上太多忙。把一份合同丢进去问「这条条款对我意味着什么」，检索能找出条款原文，剩下的分析仍要靠模型自己，也仍可能出错。
从哪里开始比较稳妥
如果真要动手，建议挑答案有明确出处、答错代价可以承受的场景起步：制度条款查询、产品参数对照、内部文档问答之类。这类问题的共同点是，正确答案就写在某一页上，检索到的片段能否支撑回答，人可以很快判断。
次序上，先看检索命中，再看回答质量；先攒一个小规模的评测问题集，再谈覆盖多少文档。很多项目走弯路，是因为一开始就在调提示词，而底层检索根本没能把该找的东西找出来。
检索增强生成更像是给模型配了一张可查的案头，而不是换一颗脑子。想清楚这层关系，预期就不容易跑偏，也更容易判断哪些需求该交给它，哪些不该。