同事在内部文档里搜不到答案，转头去问聊天模型。回答很顺，引用却对不上原文。问题不在于模型不会表达，而在于它没有先去找。检索增强生成要补的，就是“先找再答”这个动作。
把它理解成给模型外接一个资料柜，不算错，但容易低估中间的摩擦。资料柜里的文件可能命名混乱，切片后语义断裂，检索命中的段落未必能回答完整问题。模型拿到几段材料，还要判断哪些相关、哪些只是词面相似。这个过程不像开关，更像调音。
所以，检索增强生成并不只是“接一个向量库”。它把答案质量分散到资料治理、召回策略和提示词约束里，任何一环松动，最后都会在回答里显形。
检索这一步，常被低估
检索结果如果偏了，后面的生成往往只是把偏差包装得更像答案。一个常见做法是只调相似度阈值，却忽略文档本身是否可读、切片是否保留了上下文。对问答来说，一段话被切成两半，意思可能就断了；对摘要类任务，过细的切片又会让模型缺少全局。这里没有通用配方，只有针对语料的反复试。
文档质量也值得提前看。重复文件、过期版本、表格截图、层层嵌套的标题，都会让召回变得不稳定。与其急着加模型，不如先回答几个朴素问题：资料由谁维护，版本怎么标记，找不到答案时系统怎么表现。这些问题不性感，却决定系统能不能被长期使用。
拼接上下文，是一场取舍
命中的材料不是越多越好。塞得太满，模型容易在无关段落里分心；给得太少，又可能缺少必要条件。冲突信息则不好处理：旧流程和新流程同时被召回，模型若不说明冲突，回答会显得确定但危险。让回答标注依据，并允许“未找到”，能减少这种确定却危险的输出。
还有一个细节常被忽略：检索到的片段如何排布。相关段落被放在长上下文的中段，模型未必稳定利用；来源标记如果只放文末，用户也很难核对。把引用贴近结论，把冲突材料并列展示，用户才有机会自己核对。
边界不在模型，而在流程
我倾向于把检索增强生成看成一套流程：资料整理、切分、索引、召回、重排、提示词约束、答案校验，每一环都可能漏。模型只是最后发言的人。若前段资料没治理，指望一句提示词解决，通常会把问题推迟到用户面前。反过来，流程里留出人工复核和反馈入口，系统才有机会慢慢贴近真实业务。
还有一个容易被忽略的边界：有些问题本来就不适合靠检索回答。需要实时状态、需要跨文档推理、需要判断责任归属的提问，单靠资料拼接会显得勉强。此时把问题拆小，或者直接承认资料不足，能让回答少一点编造。检索增强生成能缓解知识陈旧和来源缺失，但它不负责替组织做决定。
最后要提醒的是，别把“有引用”直接等同于“可信”。引用只能说明答案有出处，不说明出处被正确理解。真正需要长期打磨的，是资料维护、检索评估和回答规范。它们不够热闹，却决定这套系统能不能从演示走进日常。