有人把公司内部的产品手册交给助手，问：退款流程走到第三步卡住了该怎么处理。回答流畅、条理清楚，还引用了手册里根本没有的条款编号。这类场面听得太多，已经不算新鲜。检索增强生成被寄予的期望，正是把这种凭空作答按下去：先去资料库里捞出相关段落，再让模型照着这些段落说话。
逻辑上说得通，工程上不轻松。
这条链上有三处容易松的地方
检索这一处最容易被低估。用户问的是“卡住之后怎么处置”，检索系统返回的却往往是流程概述、名词解释，甚至几段沾边的宣传话术。关键词匹配和向量相似度都能找出“看起来相关”的文字，但相关不等于有用。真正需要的，是那种能回答具体处置动作的段落，而它可能藏在手册的附录里，措辞还很枯燥。
拼装这一处，是体力活，也是判断活。捞回来的段落要截断、排序、塞进上下文。塞少了不够用，模型只能靠猜；塞多了噪声大，几段互相打架的旧文档混在一起，模型容易和稀泥，给出一个谁都不得罪的模糊答案。谁的优先级更高、哪一版已经作废，这些判断常常没人明确写下来，最后就落在拼装规则里，成了一处隐形的业务约定。
生成这一处，问题最隐蔽。模型面对检索到的内容，往往表现出过分的顺从：段落里写了什么就照着说什么，哪怕那段文字只是某个人的临时备注，或者已经过期很久。它不会主动提醒你“这段资料可能不可靠”。检索增强生成把模型从记忆里拉了出来，却没教会它对眼前的材料保持一点怀疑。
难的地方其实不在生成
关于检索增强生成的讨论，很容易滑向换模型、调提示词、加长上下文。这些当然有用，但如果检索层返回的东西本身就不对，生成层再强也只是把错误说得更漂亮、更像那么回事。反过来同样成立：资料是对的，模型也可能读偏。上下文里同时存在新旧两版规则，它未必分得清哪一版当前有效；一段话前面是条件、后面是例外，它也可能只记住前面。
所以这类系统真正吃功夫的地方，往往在模型之外：文档怎么切分，元数据怎么标，权限怎么隔离，版本怎么清理。这些活不显眼，却决定了答案的地基稳不稳。
评估这件事，比做出来更难
一个检索增强生成系统上线前，绕不开一个问题：怎么算答对了。检索命中了算成功，还是最终答案正确才算成功？如果答案对但引用的段落不对，该记一分还是零分？如果资料里本来就没有答案，模型老老实实说“没查到”，这算不算好表现？
这些口径不统一，团队很容易陷入自我感觉良好：演示时挑几个顺利的问题，看起来都挺像样；真实使用中，用户问的偏偏是那些边角情况。比较务实的做法是把失败样本攒起来，按“检索没找到”“找到了但没用上”“用上了但读偏了”分开记录，久而久之能看出瓶颈到底在哪一层，而不是笼统地归因于“模型不行”。
它有用，但别指望它包治百病
检索增强生成确实解决了一类真实问题：知识不在模型参数里、更新频繁、需要给出出处。这些场景下，它比单纯依赖模型记忆要可靠得多。但它不解决的问题同样清楚：资料本身口径混乱、同一件事有多个版本、权限边界不清——这些是治理问题，换什么模型都绕不过去。
判断一套系统值不值得继续投入，有个简单的试探：把背后的模型换一个，答案会变多少。如果变化很大，说明问题多半不在检索，而在资料本身还没理清楚；如果变化很小、错得稳定，那才轮到去检查检索和拼装这两环。这个顺序搞反了，容易在错误的地方反复花钱。