前兩篇已經花了不少篇幅談 LLM-as-a-Judge：Day 13 說明它適合判斷哪些問題，Day 14 則處理 Judge 自己也可能誤判的情況。到了 Day 15，先不要急著把所有評估器接成一條完整流程；這篇只處理 Reward Model。

Reward Model 最容易讓人誤解的地方，是它也會替回答打分。看到一個候選拿到 0.83、另一個只有 0.42，很自然會把它想成考卷分數：前者比較正確，後者比較差；只要設定及格線，似乎就能決定哪些資料可以留下。

實際上，Reward Model 比較擅長回答的是：同一個問題產生多個候選答案時，模型比較偏好哪一個？

「偏好哪一個」和「哪一個符合公司的政策」是兩件事。先把這個差別抓住，後面的分數、排名與使用時機才不會混在一起。

Reward Model 是怎麼學會替回答打分的？

Reward Model 常見於人類回饋強化學習（Reinforcement Learning from Human Feedback，RLHF）與偏好學習（Preference Learning）。

以 InstructGPT 的訓練流程為例，同一個提示詞會產生多個回答，再由標註者比較這些回答，把它們排出先後順序。Reward Model 從這些比較資料中學習：在目前的任務與標註偏好下，什麼樣的回答通常會被排在前面。

這裡可以把它想成選秀的初選評審。評審看過很多組對照後，慢慢學會哪些特徵比較接近既有偏好。新的一批候選進來時，它可以快速給分或排序；但它不一定能完整解釋每個分數，也不代表它手上有一份公司的最新政策。

假設同一個客服問題產生三個候選回答：

• 候選 A 語氣自然，也提供了可以執行的下一步；
• 候選 B 寫得很完整，但加入了原始問題沒有提供的退款時程；
• 候選 C 沒有亂補資訊，卻沒有真正回答使用者的問題。

Reward Model 可以替 A、B、C 打分或排序。如果它在訓練資料裡偏好完整、流暢而且看起來很有幫助的回答，B 甚至可能得到高分。這不代表模型壞掉，而是它正在依照自己學到的偏好工作；「不得承諾未經授權的退款時程」是否包含在它學過的偏好裡，則是另一個問題。

這組候選只是概念示意，不是本次實際執行的模型輸出。

Reward Model 的分數代表什麼？

Reward Model 的分數首先是一個偏好訊號。它告訴我們，在特定模型、輸入格式與資料分布下，模型比較偏好哪些候選。

因此，0.83 通常不能直接翻成以下任一種結論：

• 有 83% 的機率內容正確；
• 有 83% 的機率符合企業政策；
• 這筆資料已經可以加入正式測試集；
• 系統應該對它執行 ALLOW。

分數究竟落在什麼範圍，也可能受模型架構、訓練資料、聊天模板、tokenizer、serving 方法、pooling 與 activation 設定影響。同一個 0.8 換到另一個模型，未必仍代表相同強度的偏好。

跨提示詞比較也要小心。假設客服題目的最高分是 0.76，金融題目的最高分是 0.68，不能只看數字就說客服答案一定比較好。兩題的內容、難度與候選分布都不同；很多 Reward Model 更適合在同一個提示詞產生的候選群組內做相對比較。

所以實務上比 raw score 更容易解讀的，常常是同組排名、候選之間的分數差距，以及換一批受控候選後，排名是否仍然合理。

只談 Reward Model，可以看到三種常見 pattern

Reward Model 不是只有「輸入一段文字、輸出一個分數」這一種形式。依照它如何比較候選、如何產生結果，可以先分成三種常見 pattern。這是本文為了工程選型整理的實用分類，不是唯一的學術分類法。

1. Scalar Reward Model：每個候選各自得到一個分數

Scalar Reward Model 接收提示詞與候選回答，再輸出單一分數。多個候選都跑過一次後，就能依分數排序。

它適合大量初篩、response ranking、Best-of-N、偏好資料清理，以及挑選 chosen／rejected 候選。好處是輸出單純，容易批次處理；限制則是分數通常不會完整說明原因，也容易讓使用者誤以為它是一個已經校準好的品質機率。

2. Pairwise Reward Model：直接判斷 A 和 B 比較偏好哪一個

Pairwise Reward Model 不一定要先替每個回答建立一把絕對刻度。它直接接收兩個候選，判斷 A 與 B 哪一個比較符合學到的偏好。

這種形式很接近偏好標註原本的工作方式，也適合同一個提示詞下的 A/B 比較與候選排序。不過，A 勝過 B 只代表模型在這一組比較中偏好 A；如果 A 與 B 都很差，模型仍然會選出其中一個。

3. Generative Reward Model：讀取原則，產生分析再給結果

Generative Reward Model（常縮寫為 GenRM 或 GRM）不只輸出一個分數。它可以接收自然語言寫成的原則或任務說明，產生評論、分析、候選比較、判定或分數。

這使它比較能處理動態評估原則，也比較容易留下判斷理由。例如 RewardAnything 探索的就是 principle-following reward model：模型依照使用者提供的自然語言原則，評分或排序不同類型的內容。

代價也很直接。輸入與輸出變長後，延遲、成本、提示詞敏感度與格式控制都會增加。如果評論寫得很完整，最後卻無法穩定轉成資料管線需要的欄位，批次處理仍然會卡住。因此，Generative Reward Model 不能只看「有理由」就算完成，還要檢查輸出格式與重跑穩定性。

什麼時候適合用 Reward Model？

Reward Model 最有價值的情境，是手上有同一個問題產生的大量候選，而且目前需要的是排序或縮小範圍。

例如合成資料工具替同一個 Seed 產生許多 variants，全部逐筆深度審查的成本很高。Reward Model 可以先完成幾件事：

• 找出同組候選裡相對偏好的回答；
• 選出 top-k，交給後續流程繼續檢查；
• 找出低分、同分過多或排序不穩定的候選群組；
• 準備 chosen／rejected pair，供偏好資料整理或後續訓練使用。

這裡的重點是「同組候選」與「先做排序」。如果工作本身需要確認客服是否越權、金融內容是否構成投資建議，或回答是否符合最新內規，Reward Model 的偏好分數不能單獨完成這個判斷。這個邊界先留在這裡；各種評估方法如何分工，等 Day 17 再用同一個客服案例收束。

API 有回分數，還不代表 Reward Model 能用

筆者先前的 PoC 曾遇到一個很直接的問題：Reward Model endpoint 正常回應，批次資料也順利拿到分數，但大量候選的結果幾乎都擠在高分區間。

從系統整合角度看，API 已經接通；從評估角度看，這個訊號卻沒有足夠的辨識力。明顯較好、普通與較差的候選都擠在相近區間時，再設定一條看似精準的 threshold，也沒有解決問題。

該次既有實驗後來調整為觀察 pooling raw logits，分數分布才恢復到可以分析的程度。這只是當時模型與 serving 設定下的處理方式，不能推廣成所有 Reward Model 的通用修法。真正可以帶走的是：endpoint health 與 reward signal quality 要分開驗證。

至少可以從三個方向檢查：

1. 準備差異明確的 sanity pairs，確認模型能否把較合理的候選排在前面。
2. 觀察分數是否全部擠在狹窄區間，以及不同品質候選之間是否有可辨識的差距。
3. 固定模型、模板與候選群組後重跑，確認排名與 ties 是否穩定。

這些檢查能證明的是分數是否具有基本辨識力，還不能證明它符合企業政策，更不能直接宣稱模型已可用於正式環境。

top-k 會選出贏家，但不保證贏家合格

Reward Model 常見的使用方式，是從同一個 Seed 的多個候選中選出 top-k。這很適合控制後續要處理的資料量，但它有一個不能忽略的性質：即使整組候選都很差，top-k 還是會排出第一名。

因此，排名與合格門檻要分開看：

• 排名回答「這一組裡誰相對比較好」；
• 合格門檻回答「它是否已經達到可以被使用的最低條件」。

前者正是 Reward Model 擅長的工作。後者若牽涉明確規則、業務政策或高風險判斷，就需要另外定義，不能直接拿 rank 1 代替。

同樣地，raw score 也不宜直接變成 ALLOW、BLOCK 或實際執行動作。Reward Model 產生的是評估訊號；系統最後如何處理資料，仍是另一層責任。

結語：把 Reward Model 當成偏好與排序工具

Reward Model 的價值很明確：它把人類偏好或評估原則轉成可以大量執行的分數、比較與排序訊號。當同一個問題有許多候選，需要先縮小範圍時，它比逐筆深度審查更適合站在第一線。

使用時也要記得三條邊界：分數不是正確率，第一名不等於合格，API 能回分數不等於訊號具有辨識力。

只要守住這三條，Scalar、Pairwise 與 Generative Reward Model 的差異就容易理解：一個負責逐筆給分、一個直接比較候選，另一個把自然語言原則與判斷理由帶進評估。至於它們要如何和 Rule、Judge 及人工審查接起來，留到 Day 17 再完整處理。

參考資料

• Training language models to follow instructions with human feedback
• RewardAnything: Generalizable Principle-Following Reward Models