公開 benchmark 抓不到你的回歸
OpenRouter 在 2026 年 9 月 30 日發表了一篇教學，主題是怎麼從 production traffic 建出一套 golden eval dataset。它針對的問題每個做 LLM 產品的人都遇過：你改了一句 prompt，或是供應商在同一個 model ID 底下悄悄換了新的 checkpoint，某個功能就在線上悄悄退化。像 MMLU 這種公開 benchmark 量的是學術性的通用能力，不會反映你的產品流量發生了什麼事。
OpenRouter 給的答案很直接：一組從真實流量抽出的輸入，配上經過人審的預期輸出，放進 Git 版控，每次有意義的變更前都跑一遍。這其實和之前談過的做法一脈相承——改了 prompt 或換了模型之後，agent 需要一套鎖住的測試案例——差別在於 OpenRouter 把「測試案例從哪來」講得更完整：答案就是你自己線上的流量。
為什麼生產資料勝過合成資料
根據這篇教學，production data 作為基礎有三個理由。第一，分佈是對的：如果七成流量在問定價，eval set 就應該有七成是定價題，回歸分數才對得上使用者感受。第二，失敗模式是使用者替你找出來的——三種語言混在一句話、整段 error log 貼進來、引用一個你上季已改名的功能——合成資料不會憑空想到這些。第三，產品會漂移，半年前只處理密碼重設的客服 bot，現在要面對退款升級和競品截圖，只有真實流量會跟著演化。
合成資料不是不能用，但定位是補洞：對你真實樣本太少的已知失敗模式做補充，在 metadata 標記為 synthetic，並且維持少數。
五步流程的重點
OpenRouter 的流程是：抽樣流量、去重與聚類、加上預期輸出、跑第一輪評測修正 rubric、最後進 Git 和 CI。幾個我覺得最值得抄的細節：
- 抽樣時就把之後想切片的欄位記下來——intent、功能區、模型與 prompt 版本——事後補不回來。另外別忘了 PII 清洗要在資料進 eval harness 之前做完。
- 規模看用途：探索單一問題約 10 筆，完整回歸集 100 到 1,000 筆（OpenRouter 引用 Langfuse 的指引作為起點）。覆蓋失敗模式比堆量更重要。
- rubric 用二元準則加分析式評分，每個準則分開打分，分數掉了才知道「哪裡」變差。兩個人獨立標一批子集，不一致就修 rubric，而不是怪標註者。
- 第四步一定會砍掉一部分資料集，而「砍」正是重點。一套不管模型怎麼換 pass rate 都一樣的 golden set，什麼都沒量到。
進 Git、進 CI，才算回歸測試
OpenRouter 建議的目錄結構把資料、rubric、harness 和 baseline 放在一起：
/evals
/golden
dataset.jsonl
rubric.md
run.ts
baseline.json
/synthetic
dataset.jsonldataset.jsonl 每行一筆，輸入、預期輸出、機器可檢查的 rubric 準則和 tags 各自獨立欄位：
{ "id": "pw-reset-locked-account", "input": "i cant log in, tried resetting three times", "expected": "Bot must acknowledge the lockout, ask for the account email, and route to account recovery.", "rubric": "must_ask_email;must_route_recovery", "tags": ["password_reset"], "synthetic": false }CI 裡每個 prompt 或模型變更都跑一次，pass rate 掉超過門檻就擋下 build。rubric 也要一起版控——否則六週後你看到 pass rate 異動，分不清是模型退化還是有人改了評分標準。還有一條反直覺的建議：一直通過的項目不要退役，它是在證明行為仍然成立；只有產品裡那個行為消失了才淘汰。
一個務實的起點
如果你手上還沒有任何 eval set，最省力的路就是照第一、二步做：抽兩週流量，去重到幾百筆，先給最容易退化的那個 intent 手寫 rubric。不用一開始就追求完整覆蓋，先讓下一次改 prompt 時有一個會擋人的關卡，再逐季更新。
參考來源
本文由 AI 協助自上述來源整理，經人工審核後發布。