前阵子帮一个团队看他们的内部问答助手。有人问“出差住宿标准现在是多少”，助手答得条理清晰，数字却停在两年前的版本。制度文件就放在共享盘里，只是没有人把它递到模型面前。这种尴尬，正是检索增强生成想处理的问题。
它做的事其实很朴素
拿到问题，先去文档库里找一遍，把命中的段落塞进上下文，再让模型基于这些段落作答。模型不再只依赖参数里的记忆，而是临时翻书。翻书这个动作，既给了它依据，也暴露了它的天花板。
我在实际项目里看到的规律是：答得不准，八成不是模型笨，而是递过去的那几段话本身就不对。
难点几乎都压在“检索”这两个字上
- 切分。一份长文档被按字数切开，答案正好落在切口两侧，两半都不完整。
- 措辞。员工问“报销多久到账”，文档里写的是“费用核销周期”，字面几乎不重合，纯向量召回容易漏掉。
- 版本。同一项制度存了三份文件，检索把旧的那份也召了回来，模型只好在两段互相矛盾的文字之间自己挑。
- 权限。检索结果里混进了别的部门才该看的内容，答案本身没错，却不该出现在这个人的屏幕上。
这几件事没有一件能靠换个大模型解决。切分粒度要按文档结构来定，而不能按固定字数；查询要先改写再检索，把口语化的问法翻译成文档里的说法；版本得在入库时就标好有效期，让过期的内容自己退场；权限过滤必须发生在把段落交给模型之前，而不是在答案出来之后。
生成那一侧反而好办一些
提示词里写清楚“只依据给定材料回答，材料没有就说没有”，多数模型能照做。麻烦在于它有时候会过度服从：材料里明明有答案，只是表述绕了一点，它却回一句“未提及”。所以拒答也要留出余地，允许它在材料基础上做有限的归纳，而不是逐字比对。
有些问题它天生不擅长
需要跨全库做统计的问题，比如“今年一共开了多少场评审会”，检索增强生成使不上劲——它只能看到被召回的那几段，看不到整体分布。答案依赖多份文档交叉推理的问题也不轻松，链条一长，中途某一环没被召回，后面的推论就全歪了。
还有一类更隐蔽：问题本身就含糊。“这个流程要走多久”里的“这个”指什么，人靠上下文能猜，检索系统不能。这时候该做的是反问，而不是硬着头皮召回一堆不相干的段落。
评估这件事，别只盯着答案
我见过不少团队只拿最终回答做人工打分，结果每次调整都像在猜。更实用的做法是把链路拆开看：该被召回的那几段，有没有进到候选里；进了候选，有没有被排进最终上下文。前一步的漏召回和后一步的排序失误，修法完全不同。把这两层的记录留下来，调参才有依据。
回到开头那个助手。后来他们做的事情并不复杂：按章节重新切分，给每份制度加上生效日期，把口语问题先改写一遍再检索。答案的准确度上来了，但这并不是因为换了什么新模型。
我越来越觉得，检索增强生成的上限，基本就是这套文档库被整理清楚的程度。文档乱，检索再花哨也只是把混乱搬到了答案里。