實地報告 · 我們自己的執行
重新排序器看起來是一次提升。證據無法判斷。
我們用 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 段對話的後續執行發現了兩個可重現的失敗，這是單輪測試集無法產生的，其中包括助理否認自己上一輪剛說過的話。它不是基準測試，也不代表任何客戶。