有人在内部问答框里敲下“出差住宿标准是多少”，回车之后，屏幕上很快出现一段措辞得体的回答，金额精确到个位。去查制度原文，数字对不上。模型没有撒谎的动机，它只是没被允许翻那份文件。
这类场景是「检索增强生成」被反复提起的原因。名字听着像术语堆叠，拆开看其实很朴素：先去找资料，再让模型基于资料说话。
链路上松动的环节不止一个
把一份制度文档变成一句可靠回答，中间要过几道手。
- 切分。长文档被裁成片段，裁在哪里很讲究。一句“以上条款除外”如果被切到下一段，前半段的含义就变了。
- 向量化。片段变成一串数字，语义相近的靠得近。但“近”是统计意义上的近，未必是业务意义上对得上。
- 召回。问题进来，取回若干片段。取多少、怎么过滤，往往靠经验调。
- 拼接。片段塞进上下文，和问题一起交给模型。塞得太多，关键那句被淹没；塞得太少，回答缺依据。
- 生成。模型最后开口。它仍可能忽略材料，按自己的记忆作答。
检索到了，不等于用上了
很多人以为检索增强生成的难点在检索。实际跑起来会发现，最后一公里更别扭：材料明明躺在上下文里，模型还是给出了一个“更常见”的答案。文档存在新旧两版、或者几个片段互相矛盾时，这种情况尤其明显。模型倾向于挑那个读起来最顺的，而不是最新的那一版。
另一个被低估的问题是切分带来的语义断裂。检索单元是片段，人理解靠上下文。片段越短，召回越准，但片段本身携带的信息越残缺；片段越长，语义越完整，噪声也跟着变多。这个权衡没有通用解，只能跟着文档类型走。
它改变的是责任边界
把检索增强生成当成“减少幻觉的技术”，视野有点窄。它更实际的作用，是把一段回答的依据摆到明面上。回答旁边挂着几条来源，人可以点开核对；核对不上的时候，问题出在检索还是出在生成，也更容易分清。
这对维护同样有影响。制度改了，不必重新训练模型，更新文档库就行。代价是文档库本身得有人管：版本、权限、过期内容，一项都躲不掉。不少项目上线时把精力全押在模型和向量库上，最后却卡在这些琐碎的地方。
评估是另一道坎
怎么判断一套系统到底能不能用？通用的问答评测集参考价值有限，因为每个团队的问题分布、文档风格都不一样。比较可行的办法是攒一批真实问题，人工看回答有没有依据、依据对不对。这件事枯燥，但绕不过去。没有它，调参只能凭感觉。
所以回到开头那个住宿标准的场景。问题不在于模型答得多流畅，而在于它开口之前有没有去查，查到的内容有没有被真正用上，用错了能不能被发现。检索增强生成把这三件事从黑箱里拽出来一部分，剩下的仍然要人兜着。