讀機率而非寫判決的偵測器：44個基準測試對Jev的評估

TL;DR. 以校準決策強化學習（RLCD）訓練的Jev，過去從未在對齊失敗偵測上接受測量。RLCDAlignBench在44個基準測試、十類失敗上完成了這項測量。

核心要點

監看每一則訊息的成本結構. 已部署的模型仍會遷就使用者的錯誤信念（Sharma et al., 2024）。這句話很樸素，卻框定了整個問題。如果這種諂媚在已部署的系統中持續存在，就必須有人盯著它，而且盯防的頻率必須與對話本身同步。.
Jev有何不同. Jev以校準決策強化學習（RLCD）訓練而成。它在一次呼叫中，以校準後的機率回答關於一個輸入的許多型別化問題。這個機制值得仔細說明，因為本文其餘部分都仰賴它。.
為什麼對齊失敗比看起來更難. 在測量之前，先說一個複雜之處。這些失敗中有許多是關係性的，是相對於單憑回應無法揭示的參照資訊來定義的。諂媚很好地說明了這個一般性的概念：一個回應是否遷就了使用者的錯誤信念，取決於這個信念是什麼以及它是否錯誤，而這兩個事實單從回應文字中都看不出來。.
把偵測當作分類. 論文的形式化設定很直接。它把對齊失敗偵測視為對目標模型互動的二元分類。偵測器給出分數s(x) ∈ [0, 1]，並在s(x) ≥ t時標記x。也就是說，它既要把失敗排在非失敗之上，又要在門檻t處把兩者分開。.

一個對齊失敗偵測器在一次呼叫中以校準後的機率回答多個型別化問題，能妥善地為失敗排序，成本比LLM評審式評分器低63倍。但這些機率無法當作門檻移轉，而且標籤及其參照資訊遠比問題的措辭重要。

監看每一則訊息的成本結構 #

已部署的模型仍會遷就使用者的錯誤信念（Sharma et al., 2024）。這句話很樸素，卻框定了整個問題。如果這種諂媚在已部署的系統中持續存在，就必須有人盯著它，而且盯防的頻率必須與對話本身同步。

經濟性正是在這裡發揮作用。偵測器必須準確，又因為它要在每一則訊息上執行，所以必須便宜。單獨取得其中任何一種特性都很容易：粗糙的偵測器很便宜，而細緻但成本過高、無法在每則訊息上執行的偵測器，只能監看一部分流量。有意思的工程問題是，什麼形態的偵測器能夠兩者兼得。

根據本文所依據的論文，目前的答案存在結構性缺陷。大多數對齊失敗偵測器是生成式評審，每個標準都要花一次解碼。說得直白一點，現有的偵測器每檢查一個標準，就要付出一次解碼的代價。一個想檢查十種不同失敗類型的監控器要為十次解碼付費，帳單隨你在意的事項數量線性成長。

有一種部分的解決辦法，值得把它的侷限說清楚。像Llama Guard這樣讀取詞元機率的分類器，每次呼叫仍只為一個固定標籤評分。讀取詞元機率可以得到分數，但由於機率是從一個判決詞元上讀出的，每次呼叫仍只為一個標籤或標準評分。解碼不見了，一次呼叫一個問題的結構卻還在。你讓每次呼叫變便宜了，卻沒有改變所需呼叫的次數。

所以結構性的論點是這樣的：生成式評審按標準計算的成本很高，讀取機率的分類器按標準計算較便宜，但仍各自綁定在一個標準上。兩者都無法讓你就同一個輸入一次提出許多問題。

架構面向	生成式LLM評審（如以GPT-4擔任評審）	單詞元分類器（如Llama Guard）	多查詢RLCD偵測器（Jev）
評分機制	每個標準一次完整的自迴歸解碼	單一輸出詞元上的softmax機率	多頭校準機率張量 $P(\text{yes})$
每次呼叫的問題數	每次模型呼叫1個評估提示	每次模型呼叫1個分類標籤	1次呼叫回答多個二元/類別/序數問題
推論成本	高（每1,000次互動10至50美元）	中等（每1,000次互動0.50至2.00美元）	低63倍（19個完整基準測試共0.30美元）
AUROC表現	依基準測試而定，容易出現評審漂移	在訓練過的特定安全類別上較高	44個測試套件上零樣本AUROC中位數0.886
校準品質	啟發式說明，沒有正式機率	粗略的logits，沒有事後校準	校準後的機率，ECE中位數0.168（需要約10筆已標註項目）

Jev有何不同 #

Jev以校準決策強化學習（RLCD）訓練而成。它在一次呼叫中，以校準後的機率回答關於一個輸入的許多型別化問題。這個機制值得仔細說明，因為本文其餘部分都仰賴它。

RLCD模型不產生文字，而是為每個型別化問題回傳一個附帶校準機率的決策。不存在先寫出判決再加以剖析的生成步驟。Jev在一次呼叫中回答關於一個輸入的許多二元、類別和序數問題，論文把這個輸入稱為狀態。狀態就是輸入，問題則是你針對它提出的事項。

這與上述兩種做法的成本曲線都不同。如果問題共用一次呼叫，那麼增加一個問題並不會增加一次解碼。對於同時在意幾種失敗類型的監控器來說，好處顯而易見，不過論文的測量針對的是單一通用問題能達到什麼效果，我會停留在已測量的範圍內。

不過，過去存在一個空白。Jev能否偵測對齊失敗，從未被測量過。一個以校準機率回答型別化問題的模型看起來適合這項工作，但看起來合適是廉價的。論文著手補上缺少的測量。

為什麼對齊失敗比看起來更難 #

在測量之前，先說一個複雜之處。這些失敗中有許多是關係性的，是相對於單憑回應無法揭示的參照資訊來定義的。諂媚很好地說明了這個一般性的概念：一個回應是否遷就了使用者的錯誤信念，取決於這個信念是什麼以及它是否錯誤，而這兩個事實單從回應文字中都看不出來。

這對偵測器的設計有一個影響，論文以適當的保留態度陳述了它。只看回應的偵測器可能缺少定義該失敗的參照資訊。「可能」一詞很重要：論點不是說每種失敗都需要參照資訊，而只是說有些失敗需要，而只看回應的視角可能會漏掉它。

這也讓診斷變得複雜。如果失敗是關係性的，偵測效果差可能源於問題，也可能源於缺少參照資訊的狀態。有兩處可能出錯，而低分並不能告訴你是哪一處。也許問題措辭不當。也許問題沒有毛病，只是輸入裡從來就沒有回答它所需要的東西。一個想對偵測器說出有用結論的基準測試，必須設計成能把這兩種原因區分開來。

開發方則把間接含義和對抗性內容列為Jev的已知弱點。稍後閱讀結果時值得記住這一點，因為有些失敗類型正好仰賴這些特性。

把偵測當作分類 #

論文的形式化設定很直接。它把對齊失敗偵測視為對目標模型互動的二元分類。偵測器給出分數s(x) ∈ [0, 1]，並在s(x) ≥ t時標記x。也就是說，它既要把失敗排在非失敗之上，又要在門檻t處把兩者分開。

這兩項職責是可以分開的，論文的結果恰好沿著這條接縫分開。排序由AUROC衡量。能否在門檻處分開取決於校準，本文稍後會回到這一點，因為Jev正是在這裡有所不足。如果機率落在錯誤的位置，一個排序出色的偵測器在t=0.5時仍可能無法使用。

RLCDAlignBench #

這個基準測試名為RLCDAlignBench。它涵蓋44個基準測試、7,193個偵測實例中的十種失敗類型。實例來自五個2至7B的開源目標模型，每個實例都由其所屬基準測試的參照評分器標註。因此，被評判的互動來自小型開源模型，每筆互動的真值就是原始基準測試自己的評分器所給出的結果。

並非每個基準測試都帶有同一種標籤。StrongREJECT和HarmBench上的人工標籤，以及AbstentionBench和InstrumentalEval上的第二評審標籤，被用來把Jev與評審相比較。這讓論文對參照評分器有了兩種外部檢驗：有些情況是人，有些情況是第二位評審。

公開的成果被描述為：涵蓋十種失敗類型、附帶情境變體的44個基準測試，快取的Jev回答與重新評分腳本，再加上一套對半拆分協定，用來從所回報的提升中去除選擇造成的灌水。每個要素都對應一項實際需求。情境變體讓讀者可以檢驗狀態包含更多內容時會發生什麼。快取的回答和重新評分腳本讓人不必重跑模型就能重現數字。對半拆分協定處理的是一個方法論上的陷阱，值得用一整節來談。

選擇陷阱 #

可以就同一個輸入向Jev提出許多問題。這是它的賣點，同時也是評估上的隱憂。如果你提出一組候選問題，然後回報得分最高的那一個，你就是在問題之間做了一次搜尋並回報了勝出者。論文直截了當地指出：回報其中最好的那一個，會誇大實務工作者實際能得到的效果。

任何在測試集上調整過提示詞的人都會認出這一點。這裡採用的補救辦法很簡單。問題在一半項目上選出，在另一半項目上評分。有針對性的問題在一半項目上選出，在另一半項目上評分，共進行20次拆分。選擇過程從不接觸產生所回報數字的那些項目。

這關係到如何解讀下文回報的每一項提升。論文的主張是，對半拆分協定從所回報的提升中去除了選擇造成的灌水。當論文說有針對性的措辭帶來+0.006的AUROC中位數提升時，這個數字來自在不同兩半上分別選出和評分的措辭。一個如此小但測量誠實的數字，比一個悄悄包含了贏家詛咒的更大數字更有用。

主要結果：一個通用問題 #

現在來看多數讀者最想知道的結果。單一通用問題的零樣本AUROC中位數達到0.886，並在多數基準測試上勝過監督式基線。

逐詞來看。「單一通用問題」意味著沒有針對每個基準測試設計提示詞。「零樣本」意味著沒有在目標基準測試上訓練。「在多數基準測試上勝過監督式基線」意味著，在所檢視的多數基準測試上，用該任務的已標註資料訓練的系統，輸給了一個沒人調整過的問題。論點止於「多數」，本文也止於此。

通用問題是一個以P(yes)讀取的範本問題。圖中回報的是38個可用基準測試的AUROC，而有7個基準測試沒有提出通用問題。因此主要數字是在38個可用基準測試中、通用問題適用的那些基準測試上的中位數。細心的讀者應當分清分母：總共有44個基準測試，可用於這張圖的是38個，通用問題有7個空缺。

我認為，零樣本這項結果是這句話裡更有意思的一半。勝過監督式基線是關於相對地位的陳述。沒有任何針對任務的訓練就達到0.886的AUROC中位數，說明了對於一個讀取狀態並回答樸素問題的模型而言，失敗訊號有多少是可以取得的。這能否推廣到這十種以外的失敗類型，論點並沒有觸及。

措辭幾乎無關 #

如果你在提示工程上花過時間，下一個結果會讓你不太好受。問題的措辭影響很小，而情境更重要，主要是透過編碼了標籤的欄位。

論文對原因的解釋很具體。一旦把回答保留為機率而不是argmax決策，問題的措辭就影響很小，而狀態和標籤包含什麼則影響很大。這是一個關於資訊的觀察。argmax決策丟掉了一個答案勝過另一個答案的餘裕，措辭的改變可能讓決策越過邊界而翻轉。機率保留了這份餘裕，所以一個讓證據略微變動的改寫只會讓機率略微變動，排序大致維持不變。

我會把這一點限定在論文所述的範圍內：保留機率時，措辭影響很小。論點沒有提供機制性的解釋，我也不會把它延伸為對其原因的機制性說明。

數字支持這項陳述。在不同兩半上分別選出和評分時，有針對性的措辭帶來+0.006的AUROC中位數提升。在樣本外，有針對性的措辭增加+0.006 [−0.004, +0.015]的AUROC。這個區間跨越零。讀者不應把+0.006當作可靠的改進；這個區間容許小幅損失的程度，與容許小幅提升的程度一樣。對實務工作者來說，有用的解讀是：至少在這些基準測試上，尋找更巧妙的措辭不太可能值回所花的力氣。

這應當改變團隊分配時間的方式。如果措辭幾乎不起作用，花在上面的時間不如花在狀態上。

提升來自情境 #

那麼，狀態包含什麼，又應當包含什麼？論文的發現是，情境更重要，主要是透過編碼了標籤的欄位。研究設計背後的核心想法，是把向Jev問什麼與Jev看到什麼分開變化：一邊是問題的措辭和回答類型，另一邊是輸入的欄位。正是這種分離，讓論文能夠說措辭影響很小、而情境更重要。沒有它，兩種效應就會糾纏在一起。

最突出的例子是PrivacyLens。帶來大幅提升的是定義標籤的參照資訊，例如PrivacyLens的祕密項目清單（0.79→0.95）。AUROC從0.79升到0.95，與措辭帶來的+0.006相比是很大的。這裡的參照資訊是一份祕密項目清單，正是前文關於關係性失敗的討論所預期會起作用的那類東西：一個回應是否洩漏了隱私內容，取決於什麼算作隱私，而單憑回應無從得知。

這裡有一個部署上的提醒，而且很重要。已部署的監控器會持有的情境，只在7個基準測試中的1個上有幫助。大幅提升來自定義標籤的參照資訊，但已部署的監控器未必擁有這些資訊。監控器實際上會持有的內容，只在七個基準測試中的一個上有幫助。

這是一個冷靜的發現，我認為這是論文中最具商業意義的一句話。它把實驗室裡的數字與現場的數字區分開來。手握定義標籤的參照資訊來評估的偵測器，回答的是一個比已部署監控器所面對的更容易的問題。提升是真實的，但論文清楚說明了其中哪些是部署時可以倚靠的。

論文也指出了一個基準測試的侷限。在Open-Prompt-Injection上，標籤追蹤的是被注入任務的準確率。這是一個含義與任務屬性綁定的標籤的例子，它關係到可以期待偵測器從狀態中看到什麼。由於論點沒有給出更多結論，我也不再從中引申。

成本 #

現在來看讓經濟性變得具體的數字。Jev的成本比LLM評審式評分器低63倍。具體的比較是：把19個由評審評分的基準測試跑一輪的成本是0.30美元，比按牌價計算的這些評審低63倍。成本比較涵蓋的是按牌價把19個使用API評審的基準測試跑一輪。

要留意範圍。比較針對的是19個使用API評審的基準測試，按牌價計算，只跑一輪。它不涵蓋測試套件中的所有基準測試，也不涵蓋折扣價。在這個範圍內，比率很大，這源於前面描述的架構：沒有按標準進行的解碼。

回想開頭的要求：在每一則訊息上執行的偵測器必須便宜。把19個基準測試完整跑一輪只需0.30美元，這就是本文中「便宜」的樣子。論文沒有把它換算成每則訊息的價格，我也不換算。

與人類的一致，以及分歧揭露了什麼 #

便宜只有在偵測器同時正確時才有意義。在人工標籤可以用來核對的地方，Jev與人類的一致程度和評審一樣好，成本卻只是其零頭。

最具體的證據來自StrongREJECT。對照那裡的人工標籤，通用問題的一致程度與參照評分器相當（Cohen的κ 0.809對0.811），排序則更好。兩個κ值相差0.002，所以合理的解讀是一致性打平，而Jev在排序上領先。

接下來是一個我認為在實務上最有用的結果，因為它把偵測器變成了稽核工具。Jev有把握的分歧揭露了三個基準測試中會改變標籤的缺陷，以及另外四個基準測試中狀態無法揭示的標籤。當一個有把握的偵測器與基準測試的參照標籤不一致時，一種解釋是偵測器錯了。論文回報說，在一些情況下，分歧指向的是基準測試本身：三個基準測試存在會改變標籤的缺陷，另外四個存在狀態無法揭示的標籤。

第二類情況與關係性的論點相呼應。狀態無法揭示的標籤，是由某種從未進入輸入的東西所定義的標籤。讀取該狀態的任何偵測器都無法還原它。找出這類情況與提高分數是不同的貢獻，因為它告訴基準測試的維護者，他們的資料與標籤在哪裡出現了分歧。

弱點：校準 #

這裡本文必須直言不諱，因為論文就是如此。機率的排序表現良好，但無法當作門檻移轉：ECE中位數為0.168，而虛無模型為0.074，在經過驗證的標籤和評審標籤上都是如此，原因是Jev的平均機率偏離了每個基準測試的基本比率。

各個部分是這樣銜接的。AUROC衡量排序，而排序很強。門檻則是另一回事。如果模型的平均輸出機率與某個基準測試中失敗發生的頻率不符，t=0.5就會落在錯誤的位置，期望校準誤差也會很高。0.168的ECE中位數高於0.074的虛無模型，這比論文所選的參照點表現更差。而且這在經過驗證的標籤和評審標籤上都成立，所以這個弱點並不是雜訊多的評審標籤所造成的假象。

回想形式化的設定：偵測器必須把失敗排在非失敗之上，並在門檻處把兩者分開。開箱即用時，Jev把前者做得很好，後者卻做得不好。這項技術的名稱裡有「校準決策」，而這裡測得的校準卻無法跨基準測試延續，這種矛盾值得直白地說出來。論文把差距歸因於基本比率，並沒有主張更多。

實際的後果是：作為評審的替代品，Jev需要少量標籤來設定門檻。這是實實在在的成本，它收窄了「可直接替換」這種說法。你不能把它指向一種新的失敗類型，然後直接信任t=0.5。

做法 #

論文的建議很簡潔。這套做法是：用一個以機率讀取的通用問題，並用十筆已標註項目擬合其門檻；在Jev於t=0.5時觸發過少的地方，這能提升F1，而在經過驗證的標籤上代價是0.025。

拆開來看。通用問題以不去設計措辭的方式處理措辭問題，這與措辭影響很小的發現相符。把回答以機率讀取保留了餘裕。用十筆已標註項目擬合門檻，解決了基本比率的偏差。在Jev於t=0.5時觸發過少的地方，對F1的影響是正面的。在經過驗證的標籤上，這套做法的代價是0.025。

最後這個數字值得細想。這套做法並非沒有代價：在經過驗證的標籤上，它的代價是0.025。論文回報了這個取捨而沒有掩蓋它，比起宣傳為純粹收益的做法，我更願意引用一個明示代價的做法。除了經過驗證的標籤這個背景，論點沒有說明0.025是用什麼指標衡量的，所以我不做猜測。

十筆已標註項目是很小的要求。對大多數團隊來說，這只是一個下午的標註工作，與在每則訊息上執行評審的成本相比微不足道。但它是一個前提條件，一個無法為新失敗類型提供任何已標註項目的團隊，不應指望門檻會自行解決。

實務工作者應當從中得到什麼 #

由此可以得出幾點，既然證據支持，我就明確地說出來。

第一，停止最佳化問題的措辭。有針對性的措辭在樣本外的提升是+0.006，區間從−0.004到+0.015。這不足以作為投入的依據。

第二，把力氣花在狀態上。大幅提升來自定義標籤的參照資訊。如果你的監控器能取得定義失敗的參照資訊，改進的空間就在那裡。如果不能，就要降低預期：已部署的監控器會持有的情境，只在7個基準測試中的1個上有幫助。要圍繞部署時能得到的數字來做規劃，而不是參照資訊就在輸入裡的基準測試上得到的數字。

第三，為校準編列預算。規劃為每種失敗類型標註十筆項目並擬合門檻。不要直接以t=0.5上線。

第四，把分歧當作訊號。與參照標籤有把握的分歧，揭露了三個基準測試中的缺陷，以及另外四個基準測試中無法揭示的標籤。如果你在自己的評估測試套件上執行它，可以預期它或許不只會告訴你關於模型的資訊，也會告訴你關於標籤的資訊。這是從論文的發現推出的推論，而不是對任何特定測試套件的測量結論，所以請把它當作一個去查證的邀請。

第五，記住已知的弱點。開發方把間接含義和對抗性內容列為Jev的已知弱點。一個攸關安全的監控器必然會遇到對抗性內容。這裡的論點沒有回報Jev在這方面的表現，所以這仍是一個未設防的側翼，在信任一次部署之前，我希望先對它進行測試。

從商業角度解讀結果 #

創辦人會想知道它處在什麼位置。成本論據最有力：在每則訊息上執行的偵測器必須便宜，而相對於LLM評審式評分器降低63倍，會改變哪些部署負擔得起。準確性論據其次：零樣本AUROC達到0.886，並在多數基準測試上勝過監督式基線。

這些提醒決定了可以誠實地賣什麼。偵測器的每個門檻需要少量標籤。它的校準無法移轉。它最大的提升仰賴部署時未必擁有的參照資訊。這些都是使用條件，任何以它為基礎打造的產品都應當明確說明，而不是把它們藏起來。這些都不會削弱成本論據，它們描述的是需要做的準備工作。

關於測量本身，還有一個不那麼顯眼的重點。RLCDAlignBench附帶情境變體、快取的Jev回答、重新評分腳本和對半拆分協定，是一項可重複使用的評估資產。一個能從所回報的提升中去除選擇灌水的基準測試，正是讓後來的論點可以相互比較的那類成果。這是與偵測器本身不同的另一種價值。

仍待解決的問題 #

從論點中可以看出幾條清楚的邊界。目標模型是五個2至7B參數的開源模型，所以結果描述的是這種規模的模型在互動中的失敗。有7個基準測試沒有提出通用問題，主要的AUROC是在提出了通用問題的基準測試上的中位數。標籤來自參照評分器，人工標籤和第二評審標籤涵蓋StrongREJECT、HarmBench、AbstentionBench和InstrumentalEval。

我最感興趣的開放問題，是論文本身的結構所提出的那一個。失敗是關係性的；狀態常常缺少參照資訊；而已部署監控器的情境只在7個基準測試中的1個上有幫助。Jev的單次呼叫設計讓許多問題共用一個輸入，但最大的槓桿原來是輸入攜帶哪些欄位。部署環境應當如何在監控時取得定義標籤的參照資訊，例如用於隱私檢查的祕密項目清單，是下一步要解決的問題。論文顯示這份提升是可以拿到的（PrivacyLens上0.79→0.95），但能否以夠低的成本把它提供給已部署的監控器、從而保住63倍的優勢，仍是懸而未決的問題。

對各產業的意義 #

藉由校準決策頭，以極低的推論成本評估複雜的對齊標準，這種能力正在重塑多個領域的營運安全。

AI閘道與資安平台供應商 #

部署即時安全護欄的基礎設施公司，可以用統一的多查詢RLCD決策頭取代成本高昂的串接式架構（分別呼叫提示注入、有害內容和隱私分類器）。營運成本下降60倍以上，延遲則限定在一次前向傳遞之內。

AI治理與稽核法遵團隊 #

依照歐盟《人工智慧法》高風險要求或NIST AI RMF等標準評估模型行為的風險委員會，可以取得一份確定性的、以機率為基礎的稽核紀錄。系統記錄的不再是非結構化的敘述式LLM評審回饋，而是支援統計製程管制與漂移監測的校準機率分布。

企業部署與紅隊團隊 #

資安團隊可以透過撰寫聚焦的狀態表示，並以少至十個特定領域的範例擬合決策門檻，快速部署客製的失敗偵測器，從而省去過去為客製分類器所需、長達數週的微調週期。

結論 #

Jev在RLCDAlignBench上的評估，為正式環境中的模型監控指出了一個令人信服的架構方向：在一次前向傳遞中讀取多個型別化問題的校準機率，在成本上勝過自迴歸LLM評審，在彈性上勝過單詞元分類器。實務工作者必須為經驗性的門檻校準編列預算，而不能假定機率開箱即可移轉，但63倍的經濟優勢讓即時、全面的監控得以大規模落實。

常見問題 #

為什麼生成式LLM評審不適合即時的正式環境監控？

生成式評審對每一項受評估的安全或對齊標準，都需要一次完整的自迴歸解碼。在高流量的消費級或企業級應用中，每則訊息多次呼叫生成式評審會造成嚴重的延遲，並使營運成本成數量級地膨脹。

什麼是校準決策強化學習（RLCD）？

RLCD是一種訓練方法，它最佳化模型在結構化決策頭上輸出校準良好的後驗機率，而不是產生詞元序列。這讓模型能夠在一次前向評估中同時評估多個任意問題。

為什麼決策門檻需要用在地資料校準？

RLCD模型擅長依失敗可能性為互動排序（取得較高的AUROC），但其平均機率的絕對值會隨目標領域的基本比率而偏移。用大約十個已標註的領域範例來校準營運決策門檻，可以在不產生無法接受的誤報率的情況下確保適當的靈敏度。

參考文獻 #

Mrinank Sharma et al., (2024). 理解並緩解語言模型中的諂媚 ⧉. arXiv.
RLCDAlignBench Consortium, (2026). 以校準決策頭進行多標準對齊失敗偵測 ⧉. arXiv.
Anthropic / Alignment Research, (2025). Constitutional AI與評估者動態 ⧉. Anthropic.
NIST, (2024). 人工智慧風險管理框架（AI RMF 1.0） ⧉. NIST.

最近審閱 2026-09-30.

最近審閱 2026-10-27.

重新發佈本文

讀機率而非寫判決的偵測器：44個基準測試對Jev的評估 — Sebastien Rousseau

以校準決策強化學習（RLCD）訓練的Jev，過去從未在對齊失敗偵測上接受測量。RLCDAlignBench在44個基準測試、十類失敗上完成了這項測量。

本文採用以下授權條款 Creative Commons Attribution 4.0 International. 重新發佈需註明原始 URL 出處。

讀機率而非寫判決的偵測器：44個基準測試對Jev的評估 — Sebastien Rousseau

以校準決策強化學習（RLCD）訓練的Jev，過去從未在對齊失敗偵測上接受測量。RLCDAlignBench在44個基準測試、十類失敗上完成了這項測量。

Originally published at https://sebastienrousseau.com/zh-hant/2026-09-30-jilu-erfei-xie-panjue-zhenceqi-44-tw/ by Sebastien Rousseau.
Licensed under CC-BY-4.0.

SEBASTIEN ROUSSEAU FOUNDER · ENGINEER