RLCD 解析：為何 TypeSafe 訓練 Jev 對信心誠實，而非討人喜歡

Jev 1.13（typesafe/jev-1.13）是以一種其開發者稱為「校準決策強化學習」（Reinforcement Learning for Calibrated Decisions，簡稱 RLCD）的方法訓練而成，而這個縮寫是 TypeSafe 自創的詞，並非你理當早已熟悉的業界術語。發布文章白紙黑字這麼寫：該公司打造了「全新的模型架構、可達到最高效率的平行取樣器，以及我們稱為『校準決策強化學習』（RLCD）的訓練方法」。這是一個過去只有兩種答案的問題的第三種答案，而它之所以存在，是因為大多數團隊第一次嘗試把語言模型放進某項決策時，都會碰上的那種落差。在談到它之前，有兩個日期很重要，因為這一頁並不是一篇發布文。TypeSafe 本身是在 2026-09-15 推出這個模型，這落在本部落格所書寫的七天窗口之外，因此這裡的任何內容都不應被解讀為把 Jev 當成新東西來介紹。有明確日期的事件是 2026-09-24，當天 OrcaRouter 將 typesafe/jev-1.13 加入自家的目錄，並為它開放了模型卡——這是 Jev 首次可以透過第三方閘道呼叫，而不只是經由 TypeSafe 自家的端點。這正是本頁所依據的變化，而實際結果是：下面的技術現在是你用可能已經持有的金鑰就能在程式碼中嘗試的東西，而不只是你讀到的研究構想。

以下是概念，而非模型。本頁前三分之一談的是 RLCD 當初設計時所要對治的兩種訓練方法，因為唯有當任務不再是一場對話，而變成一種判斷時，RLCD 才能被理解為對那兩者所作所為的一種修補。如果你已經知道 RLHF 與 RLVR 各自最佳化的是什麼，你要找的是第三節，也就是由 TypeSafe 自家的三向表格來發揮作用的那一節。

RLHF 會以一個人偏好的答案為最佳化目標

基於人類回饋的強化學習，是將預訓練語言模型變成助理的方法。TypeSafe 自家的入門指南在一張標題為 RLHF 的卡片中，直白地陳述了這個目標：它「把預訓練模型變成聊天機器人。它訓練模型產生人們偏好的回應。」InstructGPT 和 ChatGPT 都是用它訓練出來的，而這份入門指南還補上了一個細節，這個細節在此處之所以相關，是出於另一個原因——這個方法是由 Diogo Almeida 共同發明；他是 TypeSafe 的共同創辦人，也是 Jev 發布文章的撰寫者。這家公司並不是在否定這個方法：它正是由一位曾協助打造該方法的人所創立。它主張的是，這個目標不適合某項特定任務。

看清這種錯配最乾淨的方法，是去問獎勵訊號實際上衡量了什麼。在 RLHF 之下，它衡量的是評分者對兩個候選回應之間的偏好。當產品是一場對話時，這是極佳的代理指標，因為對話的成功標準確實就是人是否覺得回覆好。當產品是一項決策時，這就是失靈的代理指標，因為那裡的成功標準是所陳述的信心是否與現實相符，而比較兩段看似合理文字的評分者，根本無法看出校準良好的 0.6 與聽起來很有自信的 0.95 之間的差別。兩個答案可能同樣受到偏好，但在一套軟體應該多信任它們這點上，卻可能天差地遠。

TypeSafe 在入門指南中命名的失效模式，正是直接源自於此：

• 諂媚 — 模型學會產出評分者想聽到的內容，而這與真實的目標不同。

• 聽起來自信滿滿的幻覺——流暢與確定性即使缺乏任何依據，仍會受到偏好機制的獎勵。

• 模式丟棄——偏好最佳化會縮窄輸出分佈，「偏好某種特定風格，例如指令遵循，同時降低其他可能輸出的機率」。模式丟棄是經典模式崩塌失效的輕微版本，這種問題困擾著生成對抗網路，其中生成器會收斂到某個能持續欺騙判別器的輸出。

入門指南本身的警告段落，才是值得保留的那句話：「一項輸出對人而言可能極具說服力，卻未必可靠到足以進行無人值守的自動化。人類偏好與機器可信度是兩種不同的最佳化目標。」這並不是對 RLHF 作為一種方法的批評。這是一項觀察：一個以偏好訓練出來的模型，從未被問過自動化需要得到解答的那個問題——當它說自己有把握時，它究竟有多常是對的。

RLVR 會針對程式能檢查的輸出進行最佳化——而決策很少有這種輸出。

以可驗證獎勵進行的強化學習是第二種調適方式，也正是推理模型背後的關鍵。TypeSafe 的入門指南描述了它所產出的成果：這些模型「擅長數學等任務，但速度較慢且成本更高」。其機制在於一個檢查器。如果某項任務有程式可以檢驗的答案——單元測試、證明檢查器、數值答案——那麼就能在完全不詢問任何人的情況下計算出獎勵，而模型也能大規模地依據該訊號進行訓練。這方法行得通，也正是推理模型之所以能在廉價自動驗證存在的領域中表現出色的原因。

限制在於「可驗證」這個詞的形態。可驗證的獎勵需要一個驗證器，而驗證器需要任務有一個有人能計算出的正確答案。想想一個正式環境系統實際會問的問題。這張客服工單該轉給帳務還是技術部門？這筆退款要求符合政策嗎？這筆交易看起來像詐騙嗎？這些問題大多數時候都有一個站得住腳的答案，但沒有一個有程式能檢查的答案，而最重要的那些案例，正是經驗豐富的人類會出現分歧的案例。沒有函式可執行。RLVR 沒有東西可獎勵，所以它沒有任何貢獻。

誘人的變通做法是透過標記資料集並依據標籤進行訓練，來人工製造出一個驗證器。這讓該方法有東西可以琢磨，但卻以一種至關重要的方式改變了目標。標籤編碼的是一項決策，而不是圍繞該決策的不確定性。一個被訓練來重現某個團隊在困難案例上之判斷的模型，會學到和那些標籤一樣有自信——也就是說，和撰寫標籤的人類一樣過度自信。而即使真正存在一個名副其實的驗證器，仍有第二個落差。驗證器會為答案評分。它不會為所陳述的信心評分。一個在 95% 案例中正確、卻對全部案例都回報確定無疑的模型，會獲得滿分獎勵，但作為自動化流程中的一個元件卻毫無用處——因為那 5% 才是流程唯一需要被告知的部分。TypeSafe 的發布資料從另一個方向提出同樣的論點：「如果一個模型有 95% 的時間能完成某項任務，卻不說自己何時落入那 5%，它就無法自動化該任務。」

以 TypeSafe 自身的說法來看，RLCD 的作用是什麼

RLCD 改變的是輸出，而非答案品質。入門手冊的卡片寫道：「校準決策的強化學習訓練 TypeSafe 回傳決策與校準機率，而非生成文字。」發布文章的版本是「校準決策：在 System One 任務上提供知識論上誠實的機率答案。」兩者描述的是同一項舉措：根據模型的機率是否與該答案最終正確的頻率相符來訓練模型，而非根據一個人或檢查器是否喜歡該答案來訓練。

發佈文章將這三種方法並列呈現，而其中的對比是現存對這個理念最清楚的表述。請把它讀成一組對比，而不是一張表格：

• 它優化的目標是什麼 —— RLHF 優化人類偏好，「人類評分者偏好的書面報告與聊天回覆」；RLVR 優化「可透過程式化方式驗證的輸出」；RLCD 優化校準，「在 System One 任務上給出認識論上誠實的機率答案」。

• 輸入的是什麼——較舊的兩者接收非結構化資料，「重點在於循序訊息」；一個經過校準的決策模型接收非結構化資料，「重點在於結構化程式狀態」。

• 產出的是什麼——「需要經過解析＋驗證」的生成字串，其中「永遠存在著 AI 失控的風險」，相對於型別安全的結構化數值，其「可能的輸出與結構都是事先定義好的」，模型「永遠不會發生型別錯誤」，而且「所有答案都附有經過校準的機率與信心分數」。

• 它的取樣方式——一次一個 token，每個都以前一個為條件，對比於單次查詢中產生的所有輸出。這就是第三種方法之所以便宜的機制性原因：沒有解碼迴圈的成本要付。

• 成本 — 比較模型的輸入 token 每百萬個從 $0.20 到 $10，輸出約為輸入價格的五倍；相較之下，Jev 每百萬輸入 token 為 $0.042，且輸出計費為零。

• 它回答的速度有多快——前沿模型的端到端時間為 3 到 329 秒，相較之下為 70 毫秒到 500 毫秒；供應商將其形容為在 System One 形狀的查詢上快 40 倍到 200 倍。

• 它如何描述自身的信心——較舊的兩者「往往過度自信且不一致」，即使被要求提供信心估計時也一樣；RLCD「在每次輸出時總是傳達信心與不確定性」，而「信心越高代表準確度越高」。

最後一行才是真正的產品主張，而且它具備其他行所沒有的可證偽性。「信心越高代表準確度越高」是一項關於曲線的陳述：將模型的答案依其附帶的機率分桶，各桶的正確率應大致符合機率所宣稱的水準。TypeSafe 的信心文件以異常具體的數字明確說明這項合約：

• 被指定機率為 0.2 的結果，應該大約有 20% 的時間會發生。

• 被賦予 0.8 機率的結果，大約應該有 80% 的時候會發生。

• 被指派機率為 1.0 的結果，應該 100% 的時間都會發生。

然後是讓這個說法保持誠實的那句話，用供應商自己的話來說：「這些比率描述的是成群的預測，而不是對任何單一答案的保證。」這不是為了法律理由而硬加上去的模糊說詞。這正是校準的全部意義。一個校準良好的模型說出 0.8，並不是在保證這次會答對；它是在保證，在它標為 0.8 的每一個答案中，大約每五個有四個是正確的。單一一個答案什麼也告訴不了你。一週內的一千個答案，才能告訴你這條曲線是否真實。

同樣的三張卡片對比也出現在 TypeSafe 自家的文件上；那份文件既是上方比較的來源，也是最清楚能核對確切措辭、而不必只憑摘要說法的地方。下方的截圖就是該頁面目前的樣貌：三張卡片分別對應三種後訓練方法，其中第三張完整寫出 RLCD。

供應商文件中的另外兩個細節，顯示這套方法深入產品到什麼程度。第一，信心值是推導而來，而非生成而來：模型會針對你提供的選項或層級回傳完整的機率分布，而信心值則是根據該分布形狀所計算出的統計量。這就是為什麼文件可以告訴你，那個定義並非關鍵——無論如何你都會取得原始分布，而且如果你的統計量更合適，你可以自行計算。第二，RLCD 是唯一形塑權重的因素。TypeSafe 的模型頁面指出：「Jev 並未使用客戶資料進行微調或 LoRA 適配。它是以 RLCD 訓練，以回傳校準後的決策，同一組權重服務每一個帳戶。」領域適配發生在請求中——你的狀態、你的準則——而不是在每位客戶專屬的檢查點中。這套方法所產生的任何校準，就是每位客戶所得到的校準。

為什麼校準是讓廉價決策模型可用的關鍵

經過校準的機率本身並不有趣。當你的程式碼依據它分支的那一刻，它就成為了架構本身，而 TypeSafe 的信心度文件正是把那個模式描述為三個區間，每個區間產生不同的系統行為。

• 高信心度 — 自動執行。模型有明確的判讀，你可以在無需人工介入的情況下繼續進行。

• 中等信心——謹慎行事。模型有合理的答案，但不確定，因此你應向使用者確認、標記以供審查，或在採取行動前蒐集更多資訊。

• 低置信度 — 不要採取行動。請轉交真人處理、要求釐清，或改用其他系統，因為模型是在告訴你，它沒有足夠的資訊可作為依據。

文件明確指出，界線由你劃定，且應因後果而異：「信心閾值不是單一數字。同一系統內的不同動作，應根據判斷錯誤的後果，以不同層級來把關。」他們的工作範例把硬性下限訂在 0.5——凡是模型回報低於此值的，都會未經進一步檢查就轉交人工——接著對破壞性動作套用比唯讀動作更高的門檻。你的程式碼體現了風險容忍度；模型則為其提供誠實的輸入。

那個模式就是支持雙模型工作流程的整個論證，而它值得被當成一個論證來陳述，而不是一份功能清單。假設你想要一條自動化流程，能處理有把握的多數案例，並把其餘案例升級給更大的模型或真人。升級決策必須來自某個地方。如果便宜模型對所有事情都回報 0.98，包括它其實在猜的案例，那麼這個分支就沒有東西可測試，你要嘛全部自動化——包括它原本應該升級的案例——要嘛什麼都不自動化。一個其信心程度具有資訊價值的模型，是唯一能讓你安全地自動化某個子集的模型，因為它是唯一能告訴你它對哪個子集不安全的模型。文件用一句直白到值得引用的話表達了同一點：「如果一個智慧系統，不論是人還是機器，無法表達誠實的不確定性，這個系統就無法被信任。」

還有第二個理由，說明為什麼這件事對便宜模型比對昂貴模型更重要，而這也正是為什麼路由的故事與 RLCD 的故事是同一個故事。一個每百萬輸入 token 定價 $0.042、且不收取輸出費用的模型，便宜到足以讓人持續不斷地諮詢它——在代理迴圈的每一個回合、在批次中的每一筆紀錄、在每一張工單送達時。持續被諮詢，恰恰就是模型錯誤會不斷累積放大的情境，因為在它的輸出被據以行動之前，沒有人會先讀過它。置信度正是讓這件事變得安全的原因。便宜則是讓升級分支變得可負擔的原因，因為昂貴路徑只會在那個便宜模型拒答的一小部分案例上執行。這兩半缺一不可，而將兩者結合起來的路由決策，就是對某個數字設下的門檻，而 RLCD 正是讓我們有理由相信這個數字的依據。

誠實的界線：校準不等於正確

關於 RLCD，最重要而要弄對的是它沒有宣稱什麼。校準是信心分數的一種性質，而不是對答案的保證；而且供應商在自己的文件中就這麼說，而不是留給批評者去講。System One 頁面寫道：「System One 模型是為校準決策而訓練：其機率會針對結果進行最佳化，以反映不確定性。校準是在各組預測上衡量；它不保證個別答案是正確的。」一個模型可以校準得完美無缺，卻仍在你的工單上做出錯誤判斷，因為 0.9 代表十次裡有九次，而這次可能就是那第十次。

我們自家的服務數據在這裡正好是有用的對照，正因為它們是模型在生產環境中的實測結果，而不是關於這套方法能達成什麼的主張。在截至 2026-09-30 的七天內，針對自該模型被加入目錄以來流經 OrcaRouter 的 playground 的流量，Jev 1.13 的資訊卡回報的錯誤率為 0.49%，涵蓋 7,620 萬個詞元，同時首個詞元時間的 p50 為 151 毫秒、p95 為 247 毫秒，輸出速度約為每秒 349 個詞元。關於這個數字，有兩件事值得直說。它是我們自己的數據，不是供應商的；而且它是滾動視窗，而非固定的測試集——同一個欄位在這個視窗較早的時候讀到的是 0.57%，因為它是在最近七天的即時流量上重新計算的，而昨天的呼叫會逐漸移出視窗。它也不是一項校準量測。錯誤率告訴你的是在我們的流量上出錯的頻率；它不會告訴你那些信心值是否誠實，那是另一個問題，而且需要標註資料才能回答。

這也是供應商提供的實務指引，附在其閾值建議旁的一則說明中：「正確的閾值取決於你的領域，以及模型在你使用情境下的表現。從保守的閾值開始，用你自己的資料測試，並在觀察結果時逐步調整。」RLCD 是一項關於模型如何訓練出來的宣稱。這項宣稱在你的輸入上是否成立，是個實證問題，而它也是少數幾個你不需要任何機器學習基礎設施就能測試的模型性質之一——拿幾百個你已經有標籤的案例，依模型回報的信心程度把答案分組，然後檢查各組正確的比例是否達到它們宣稱的水準。如果 0.9 這一組在你的流量上約有 90% 的時候是對的，那這個閾值就是真實的，你可以在它之上自動化。如果所有東西都 clustering 在 0.9 以上，而準確率卻跟不上，那你學到的東西比任何亮眼的標題數字都更有用。

還有兩項限制也該一併說清楚。第一，這個模型沒有公開的基準卡，可用來對照查核上述任何一點——廠商並未發布，也沒有任何第三方排行榜收錄這個模型；截至 2026-09-30，它在 Artificial Analysis 的模型頁面會回傳 404。因此，校準方面的論證所依據的是訓練說明、有文件記載的合約內容，以及你自己實測到的任何結果，而不是一條已發布的曲線。第二，廠商自家的效能宣稱終究是它自己的說法：發布文章公開指出，支撐速度與成本這類頭條數字的工作流程評估，是由其模型能力團隊所建構，而用來衡量這些評估的參考答案，是兩個外部模型的平均值，且這些數字「落在真實世界增益的偏高一端」。文章也說，無法證明其定價未受補貼。這些都不會削弱訓練方法本身——那是與速度宣稱不同的另一項主張——但確實意味著，支持 RLCD 的論據是一場關於目標設計的論證，而不是一項已成定論的實證結果。把它當成一項你能以低成本加以檢驗的假設；這比大多數訓練方法主張所留下的處境都要好。

你今天可以用這個做什麼

這個論證的兩項在一個地方交會。RLCD 是決策模型的信心值得分支的理由；你程式碼裡的閾值就是那個分支所在之處；而只有在常見路徑便宜到足以到處執行時，升級才負擔得起。Jev 1.13 可在 OrcaRouter 上以 typesafe/jev-1.13 呼叫 —— 一個 API 涵蓋 200+ 個模型、0% 加價、供應商定價原樣傳遞，所以供應商一降價，這裡當天就生效 —— 這意味著自信多數路徑與生成式升級路徑以同一把金鑰計費，而不是兩份供應商合約。你仍要以其自身的形態呼叫它：POST /v1/systemone、非串流、對上 65,536 個 token 的上下文，因為那不是 OpenAI 聊天補全（chat-completions）路由，也沒有被併入聊天端點。如果你正在把它接起來，供應商 SDK 發佈中兩則附有日期的說明值得一知：版本 0.7.1 於 2026-09-21 發佈，新增了搭配 AI 閘道使用的範例；版本 0.7.2 於 2026-09-26 發佈，為 Python 套件新增了 http2 額外項目。第二則正是那種只會出現在發佈說明裡的細節 —— 對於一個整體價值主張就是低於 200 毫秒往返時間的模型來說，有 HTTP/2 用戶端是值得的。

如果你只從這一頁帶走一件事，就帶走 RLCD 所回答的問題的形狀。它不是「模型能不能更聰明」，而是「模型能不能在它不夠聰明時告訴我，而且夠頻繁、夠準確，讓我可以把其餘的一切自動化」。這不同於該領域過去幾年投入的那兩個研究目標，而且它是唯一會產生一個你的程式碼能據以行動的數字的研究目標。信心值就是那個數字。在你信任它之前，先用自己的標籤測試它，並先從一個萬一錯了會讓你難堪的門檻開始，而不是從一個你希望它是對的門檻開始。

還有一塊拼圖值得與上述所有內容並列看待，因為它是整串論證所瞄準的那個數字，而且它是實測得出的，不是憑空宣稱的。下方這張卡片是我們自己針對 typesafe/jev-1.13 的七日服務紀錄——指的是實際上線的模型，不是訓練方法，也不是基準測試。請把它讀作校準問題的後半段：信心值告訴你哪些呼叫該採取行動，而這個數字則告訴你，其餘的路由決策距離一個你會放任不管的系統還有多近。