企业 RAG 为什么上线后答非所问：从检索质量到答案可信度的系统优化

先判断问题发生在检索还是生成

RAG 回答不准确时，团队容易直接更换模型，但真正决定上限的往往是检索结果。应把一次问答拆成查询理解、候选召回、重排序、上下文组装和答案生成五段，分别保存输入输出。若正确材料从未进入候选集，问题在召回；若材料存在但排名靠后，应优化重排序；若上下文正确而答案仍偏离，才需要调整提示词、模型或生成约束。

切片必须保留业务语义

固定字数切片会把表格、条款和步骤拆散。更可靠的做法是按标题层级、段落结构与文档类型切分，并保留来源、版本、部门、有效期和访问权限等元数据。对制度类文档，可同时建立段落块与章节摘要两级索引；对表格，应将表头与行数据共同编码。索引更新还要绑定文档版本，避免已废止内容继续被召回。

混合检索比单一向量更稳

产品型号、错误码和专有名词适合关键词检索，语义表达则适合向量检索。将两种召回结果融合，再用重排序模型判断问题与证据的真实相关性，可以显著减少“看起来相似但不能回答”的材料。查询改写不能无限扩展，应保留原始实体与约束条件，并对多意图问题先拆分再检索。

让答案可以核验

生成阶段应要求每个关键结论绑定引用，证据不足时明确拒答或请求补充条件。评测不能只看语言流畅度，要建立检索命中率、引用正确率、事实一致率、拒答准确率与权限越界率。用真实用户问题持续构建回归集，每次调整切片、模型或索引后自动复测。

上线治理

生产环境需要记录低置信度查询、无结果查询和用户纠错，将其转化为知识缺口清单。对高风险场景增加人工复核，对普通场景采用抽样审计。RAG 的核心不是把资料塞给模型，而是建立一条从权威内容、可控检索到可验证答案的证据链。