去年冬天，一个做工业设备售后的团队给我看他们新做的问答入口。演示时提问“E-31 报警要不要停机”，系统答得干净利落，还附了手册页码。三个月后同一套系统上线，客服说不敢用了：有一次它引用的是 2019 年版手册，而那条说明两年前就改过了。
这套系统用的就是检索增强生成——先从文档库里捞出相关片段，再让模型基于这些片段组织回答。思路不复杂，也确实是目前让大模型回答“它训练时没见过的事”的常见做法。问题在于，不少人把它当成一个纯软件工程问题：装个向量库、切一切文档、接上模型，就算完事。
捞错了，说得再顺也没用
检索这一半经常被低估。用户问的是“要不要停机”，手册里写的可能是“E-31 属于二级告警，处理见 4.3 节”。两句话字面重合度不高，靠相似度未必对得上。要是分块策略再把跨页的表格切碎，模型拿到的就是半句话——它不会说“我没找到”，而是顺着半句话往下编。
这里有个容易被忽略的落差：生成那部分的质量是看得见的，读起来顺不顺、像不像人话，一眼能判断；检索那部分是看不见的，除非你逐条翻日志，看它到底捞回了什么。于是团队把精力花在调提示词、换模型上，真正出问题的一环反而没人碰。
脏活都在文档里
我跟过几个项目，卡住的地方几乎都不在算法。举几个具体的：
- 同一台设备，销售叫它“主机”，手册叫“控制单元”，工单里写“主控”，三种叫法在检索时被当成三个东西。
- 扫描版 PDF 过 OCR，把“0”认成“O”，型号全错；检索照样能匹配上，答案却指向另一个部件。
- 文档有十几个版本，没人标注哪份是现行有效的，系统一视同仁全收进去。
- 权限没打通，一线能看到只有工程师才有权查看的参数表。
这些活没有技术光环，做起来枯燥，还得跟业务部门来回确认。但它们决定了检索增强生成的天花板在哪：模型再好，也只能在捞回来的那几段文字里做文章。
它也有干不了的活
需要跨十几份文档做汇总计算的问题，RAG 并不擅长，检索只能捞回有限几段，拼不出全貌。答案本身不在文档里的问题，它同样无能为力；硬上只会得到一段“有出处”的错误回答，这比没有出处更危险，因为引用看起来太像证据了。
还有一种情况常被忽略：如果问题空间很小，答案稳定，比如就那么几十种故障对应几十种处理方式，老老实实写规则、做决策树，维护成本更低，出了错也好追查。用不用检索增强生成，取决于知识是不是真的又多、又散、又在变。
所以我现在的判断顺序有点反着来：先问这个团队有没有一份自己敢信的文档，再问他们更新文档的速度跟不跟得上业务，最后才轮到用什么模型、什么库。前面两问答不上来，后面那些选型讨论，多半是在给自己找麻烦。