检索评估流水线是什么
评估流水线的最小闭环是四步：收集真实问题、标注相关片段、脚本化计算指标、与当前线上配置输出对比报告。它的价值不在于单次跑分，而在于可复跑——数据与脚本一起入库并版本化，任何配置改动都能在几分钟内得到与历史可比的结果。标注不必一开始就做全：五十到一百条覆盖主要问法的问答已经能暴露多数问题，之后随线上问题持续增补，评测集本身就是资产。
基本信息
| 数据形态 | 问题 + 标准相关片段 id 的 jsonl 文件 |
|---|---|
| 核心指标 | Recall@k、MRR、NDCG |
| 起步规模 | 50~100 条真实问答即可发现主要问题 |
| 标注方式 | 强模型产出候选，人工只做增删改 |
| 版本化 | 数据集、脚本、指标报告一并入库 |
典型使用场景
- 配置改动验收：切分、模型、索引参数变更后跑同一套用例对比
- 上线门禁：把 Recall@k 等指标接入 CI，超阈即阻断
- 问题定位：指标下滑时按业务线分组，快速锁定受影响的语料范围
- 标注提效：用强模型先给出候选相关片段，人工只做修正
- 长期趋势：定期重跑，捕捉语料漂移带来的缓慢劣化
目录与命令
目录与命令
eval/
dataset/questions.jsonl # 问题 + 标准相关片段 id
run.py # 计算指标并与基线对比
python eval/run.py --index kb_v3 --topk 10
# 输出：recall@10=0.86 mrr@10=0.72 ndcg@10=0.79标注辅助
标注辅助
# 用强模型先给候选，人工只做增删改，降低标注成本
candidates = retriever.search(q, top_k=20)
label = human_review(strong_model_label(candidates, q))
save_label(q, label, reason='条款第 3 条直接回答') # 记录判定理由指标与用途
| 指标 | 回答的问题 | 短板 |
|---|---|---|
| Recall@k | 答案有没有被捞进候选 | 不反映排序质量 |
| MRR | 第一个相关片段排多前 | 只看首个命中 |
| NDCG | 整体排序质量 | 需要分级相关性标注 |
| 人工通过率 | 答案能不能直接用 | 成本高、样本量小 |
标注时记录判定理由：出现分歧时能复盘是标注口径问题还是检索问题，否则同一批数据反复讨论也得不出一致结论。