RAG 准确率停在 60% 时，先别换大模型
RAG 系统答错问题时，最容易出现的反应是换更大的模型、增加更长的提示词，或者一次性叠加向量检索、关键词检索、查询改写和重排序。这样做可能让少数示例变好，却很难回答一个更重要的问题：到底是哪一层产生了增量？
更稳妥的方法是先建立一条排障阶梯，把“回答不准”拆成六个可以单独观察的环节：数据、切分、召回、排序、生成和评测。每次只改一层，并用同一组真实问题验证。
第一步：先固定一组真实问题
不要从模型自动生成的漂亮问题开始。先从搜索词、客服问题、文档目录和失败日志中选出 30 到 50 个真实问题，覆盖事实查询、跨段推理、版本差异、否定条件和无答案问题。
每个问题至少标注四项：
- 是否应该回答；
- 正确答案需要哪些证据；
- 证据所在文档和段落；
- 可接受答案的边界。
这组数据不必一开始很大，但必须可以版本化。否则每次优化都在更换考题，分数没有可比性。
第二步：区分“没找着”和“找着但答错”
先看检索，不要先看最终答案。对每个问题记录目标证据是否进入 Top-K：
- 目标证据不在 Top-K，属于召回失败；
- 目标证据进入 Top-K，但排位过低，属于排序失败；
- 目标证据排位足够高，模型仍答错，才进入生成和约束层排查。
这一步会直接决定后续动作。召回失败时继续调系统提示词通常无效，因为模型根本没有拿到需要的事实。
第三步：先检查数据，再调切分参数
很多检索问题并不是 Embedding 不够强，而是源数据已经丢失结构。检查标题、章节、列表、表格、代码块、版本号和更新时间是否在清洗后仍然存在。
切分不要只用一个全局字符数。API 文档、教程、FAQ 和政策文件的结构不同，应分别测试。每次记录 chunk 大小、重叠、标题继承方式和父子关系，并用目标证据召回率判断，而不是凭肉眼挑几个看起来舒服的片段。
第四步：在基线之后引入混合检索与重排序
向量检索擅长语义近似，关键词检索擅长产品名、错误码、版本号和专有名词。先分别测量两者，再做混合，而不是直接把所有结果拼起来。
混合后继续观察三项：
- 目标证据召回率是否提高；
- 无关片段是否挤占上下文；
- 延迟和成本是否仍在预算内。
只有候选集中经常包含正确证据但顺序不稳定时，重排序才最有价值。如果候选集里根本没有答案，增加 reranker 只是给错误候选重新排队。
第五步：让生成层能够拒答
生成提示应明确区分“证据不足”和“模型不知道”。要求答案引用实际证据，并在缺少支持时返回可识别的拒答状态。不要用“尽量回答”掩盖检索失败。
评测至少分开记录：答案正确性、证据支持度、引用准确性和错误拒答率。一个更会猜测的模型可能提高表面回答率，却降低系统可靠性。
第六步：一次只改一个变量
为每次实验保留最小记录：数据版本、切分版本、检索配置、重排序模型、生成模型、提示版本、Top-K、延迟、成本和评测结果。
建议使用下面的停止条件：
- 真实问题集上没有稳定增量，就撤销改动；
- 增量只来自少数重复问题，就扩充失败样本后重测；
- 正确率提高但延迟或成本越界，就不进入生产；
- 无答案问题的幻觉率上升，就不能用平均分掩盖。
RAG 优化不是“把组件都装上”，而是让每个增量都能对应到一类失败。这样从 60% 往上走时，团队知道为什么提高，也知道下一次回归应该检查哪里。
更完整的中文案例涵盖数据摄取、查询策略、混合检索、重排序和评测，可参考：构建 RAG 系统的核心策略：从 60% 到 94% 准确率。