做 RAG 项目时，我如何建立评估集

“感觉不错”不是指标

RAG 系统很容易在演示时给出流畅答案，但流畅并不代表正确。真正需要验证的是：检索有没有找到依据，回答有没有忠于原文，以及没有资料时系统能不能停下来。

把问题分成四类

我通常先建立一组覆盖真实使用场景的问题：

• 直接事实：答案出现在单个明确段落。
• 跨章节：需要组合两份以上资料。
• 术语与缩写：全文检索和向量检索表现不同。
• 资料外问题：系统理应拒答。

每类至少准备二十条，并记录预期来源、可接受答案和失败等级。

逐层定位失败

用户问题
  -> 检索是否召回正确片段
  -> 重排是否将正确片段放入上下文
  -> 模型是否忠实使用上下文
  -> 引用是否符合原始位置

如果召回阶段就失败，继续调整生成提示词没有意义。把链路拆开评估，才能知道下一轮优化应该落在哪一层。

最小可行评估脚本

评估集不需要一开始就做成平台。一个 JSONL 文件、一个执行脚本和一份手工复核表，就足以支持前十轮迭代。关键是每次修改后都重新运行同一组问题。

最终看什么

除了正确率，我还会记录引用命中率、拒答率、首字延迟和单位问题成本。质量、体验与成本同时可见，技术取舍才有依据。