实地报告 · 我们自己的运行
重排序器看起来是一次提升。证据无法判断。
我们用 Oloproof 测试了一个并非由我们运营的在线检索增强文档助手：它自己的检索器和索引、真实的生成、一个 LLM 评判器，以及其所有者原封不动的 58 题黄金测试集。不涉及任何客户。这是我们自己的运行，按我们审计时的样子如实报告。
- 58
- 所有者黄金测试集中的题目
- 76 个中的 0 个
- 得出结论的功能开关比较
- 每 9 个中 1 个
- 在完全相同的运行之间改变判定的用例
- 23 个中的 15 个
- 换入黄金段落后恢复的失败回答
开启重排序与关闭重排序对比，2026 年 9 月 22 日
| 指标 | 开启重排序 | 关闭重排序 | 配对差值（开启减关闭） |
|---|---|---|---|
| 排名第 1 的页面正确 | 0.745 [0.519, 0.875] · 58 个中的 51 个 | 0.618 [0.449, 0.760] · 58 个中的 55 个 | +6.2 个百分点 [−36.3, +45.5] · 48 对配对 |
| 正确页面位于前 3 | 0.742 [0.270, 0.939] · 58 个中的 31 个 | 0.683 [0.350, 0.875] · 58 个中的 41 个 | +3.7 个百分点 [−73.9, +76.2] · 27 对配对 |
| 回答正确（LLM 评判器） | 0.760 [0.519, 0.888] · 58 个中的 50 个 | 0.685 [0.501, 0.819] · 58 个中的 54 个 | +6.5 个百分点 [−39.4, +48.4] · 46 对配对 |
之前
这个助手原本已有一套不错的测试框架：黄金测试集、LLM 评判器和发布门控。无论测试集多大，门控都直接拿点估计与目标值比较。按这种读法，重排序器让“第 1 位即为正确页面”提高了 12.7 个百分点，本会被发布上线。而在用于门控发布的忠实度评分中，评判器未能评分的回答被算作完全失败。
之后
Oloproof 只在两组都已回答的问题上进行配对，把 4 次服务器错误和 2 个无法解析的判定记为缺失，并加宽每个区间以涵盖它们。三个差值都大幅跨过零：这个测试集无法判断重排序器是有益还是有害。
用黄金段落替换检索到的段落，重新运行 23 个失败回答，恢复了 15 个，旁边设有一个原样重跑的对照组。诊断将 5 个标记为检索遗漏、7 个标记为生成失败，另有 11 个未能确定，并指出检索深度和索引配置是下一步要做的实验。
重复测量三次，在什么都没改的情况下，大约每九个用例就有一个改变了判定，且 13.8% 的调用返回了服务器错误。将这些错误声明为暂时性错误后，22 个缺失用例中有 18 个得到恢复，区间收窄了 39%。随后对该助手的十九个功能开关进行扫描，得到 76 项配对比较，没有一项得出结论；再增加约 40 道题，就能对最有希望的三项得出结论。
“一个只有 58 个用例、且每九个中就有一个每次被问都回答不同的测试套件，不具备四位小数的分辨率。”
概览
- 运行方Oloproof，自主发起
- 被评估的系统一个并非由我们运营的在线 RAG 文档助手
- 测试集58 道题，所有者自己的，未作改动
- 评判器一个 LLM 评判器，尚未与人工标注核对
- 运行日期2026 年 9 月 22 日和 23 日
- 后续运行19 个功能开关；24 段对话
它不能说明什么
一个系统、一个语料库，以及一个小到无法回答它自身问题的测试集。每个回答评分背后的评判器尚未经过人工验证，诊断中也如实说明了这一点。该测试集是单轮的：一次包含 24 段对话的后续运行发现了两个可复现的失败，这是单轮测试集无法产生的，其中包括助手否认自己上一轮刚说过的话。它不是基准测试，也不代表任何客户。