给内部知识库配一个问答入口，是不少团队试水大模型的第一步。演示时效果往往不错，上线一段时间后却会冒出一种尴尬：回答语气笃定、条理清晰，引用的条款在原文里却找不到。翻日志才发现，检索环节什么也没捞到，模型自己把话补完了。
检索增强生成的思路并不复杂：先去资料里找相关内容，再让模型基于这些内容作答。麻烦在于，从“找”到“答”之间隔着好几个环节，每一环都可能悄悄失效。
检索之前，先得把问题问对
用户的提问通常很短。“报销多久到账”可能指向差旅、采购、活动三类单据。若直接把这句话拿去检索，返回的多是字面相近却不对症的段落。实践中更常见的做法，是先让模型改写或拆解问题，补全上下文，再分别去查。这一步不显眼，却决定了后面所有环节能在什么水平上工作。
切片方式，会一路影响到答案
把文档切成多大一块，是个容易被低估的决定。切得太碎，一段话丢了前提，检索到的片段读起来像断章；切得太整，一块里混着好几个主题，向量表示被稀释，命中率下降。有的团队改成按标题层级切，有的在片段前补一句所属章节的说明，都是为了让孤立的文字重新带上语境。这件事没有通用解法，得看资料本身长什么样。
找到了，模型也未必照着说
上下文里塞进正确段落，模型仍可能给出与原文不一致的表述，尤其在段落之间存在冲突、或问题需要跨几处拼接时。比较务实的处理是要求回答标注出处，让用户能点回去核对；同时把“资料中没有”设为一种允许的答案。这一点比调参重要——一个会说“没查到”的系统，长期看比一个总有话说的系统更可信。
几个值得提前想清楚的问题
- 时效：资料更新后，索引多久能跟上，旧版本会不会继续被召回。
- 权限：检索层若不分人，用户可能通过提问看到本无权查阅的内容。
- 评测：只测最终答案对错，定位不到是召回不足还是生成跑偏，需要把两段分开看。
- 多跳：需要连着查两三次才能回答的问题，单轮检索增强生成往往力不从心。
还有一点常被忽略：资料本身的质检。知识库里过期文档、重复版本、口吻不一的说明混在一起，检索再准也只是把混乱搬到了答案里。不少项目做到一半才发现，真正耗时的是清理底稿，而不是调模型。
所以检索增强生成的难点，说到底更像工程问题：切片策略、索引更新、权限过滤、分阶段评测，都是些不光鲜的活。把它当成一个需要长期维护的系统，而不是一次接入就完事的功能，预期会现实得多。至于模型能力提升后这些麻烦会不会消失——大概不会全部消失，只是换一种形式出现。