結構化決策驗證器

資料來源#

• Building Prod with Jev and LangGraph
• Inside the JEV Ecosystem: 13 Answer Verifiers on One Test Set
• Introducing System One Models & Jev

摘要#

型別化決策模型透過一次前向傳遞，回傳結構化判決——布林值、選項或序位分數；不產生任何 token，成本比用自由文字向前沿模型詢問同一問題低一到三個數量級。TypeSafe AI 的 Jev 為這個類別命名（稱為「System One models」；發布文章，2026-09-15，vendor-claim——下文將討論）；其周邊生態系也已逐漸成形，包括 VIDRAFT 的 ZTC、開放重現專案 open-jev、Patronus 的 Lynx，以及 Convai 的 Laya。直到這項研究（Proto_AGI / mayafree，HuggingFace 社群文章，2026-09-20 發布，empirical）出現以前，還沒有任何共同測試集讓它們全數接受評估。

共同基準測試#

共 2,018 個項目，其中 508 個不正確，涵蓋 5 個領域，答案來自 4 個不同模型，沒有提供依據文件（純粹的事實驗證，並非來源歸屬判定）。指標：AUC，先按領域彙整，再依規模加權——論文指出，若採用其自行計算的合併數字，結果會是 0.80，而按領域計算則是 0.73；論文明確採用較低、可重現的數字，而非更好看的合併數字。不確定性：配對自助法，重抽樣 3,000 次；若 95% 區間包含零，便不排名。這項規則明確寫在結果表上方，而非藏在註腳中。兩個參考列可作為所有其他數字的對照：十項表面特徵（長度、數字數量、格式）的邏輯斯模型，以及作答模型自行提供的信心值。

#	系統	供應商	AUC
1	ZTC (397B)	VIDRAFT	0.7364
2	JEV	TypeSafe AI	0.7350
3	ZTC (27B)	VIDRAFT	0.7282
—	長度與格式基準	參考	0.7036
4	open-jev 4B	pngwn	0.6844
5	Patronus Lynx 8B	Patronus AI	0.5179
6	Laya-Typed-Decisions 421M	Convai	0.5144
—	模型自行提供的信心值	參考	0.5000
7	Laya-Multilingual 322M	Convai	0.4796

參考系統，會產生 token，因此不在此比較範圍內，也不排名：GPT-5.2 0.7148、Qwen3-Next-80B 0.6366、GPT-4o-mini 0.5878、Gemini 2.5 Flash-Lite 0.5822。採用完全不同的評估軸（依據來源文件判定歸屬，而非開放式事實驗證）：Vectara HHEM-2.1 0.4852。

誤差範圍之外仍成立的四項發現#

真正的門檻是表面特徵基準。 單靠答案長度與格式就達到 0.7036，高於 13 個受測系統中的 8 個。低於這條線的驗證器，辨識的是形式，而非正確性。

排行榜前段在統計上不分軒輊。 ZTC (397B) 領先 JEV 0.0014 AUC；差距的 95% 信賴區間為 −0.019 至 +0.032，包含零。

同一家族內，規模較大不代表表現較好。 整體而言，ZTC 397B 勝過 ZTC 27B；但在科學推理上，排名則大幅反轉（27B 為 0.7410，397B 為 0.6287——大 14 倍的模型反而低了 0.11）。這與另一個文中引述的 180B 級模型結果一致：其分數為 0.7146，輸給分數 0.7284 的 4B 模型。驗證品質追蹤的是表徵幾何，而非參數數量。

前沿 LLM 評審排名居中，成本也高。 GPT-5.2（0.7148）低於兩種 ZTC 設定及 JEV，還會產生 token，每 1,000 次呼叫成本約 $0.55，而 JEV 為 $0.024。GPT-4o-mini 和 Gemini 2.5 Flash-Lite 的排名更後面（分別為 0.5878、0.5822）。

開放替代方案的速度主張成立，準確度主張卻無法套用。 Laya 是最接近 Jev 的開放式、非自回歸類比系統（Apache-2.0，每次呼叫約 0.015 秒，速度約為此處測得的託管 API 的 140 倍），但在這組資料上的分數是 0.4796／0.5144，與其在供應商自家基準上勝過 Jev 的公開主張不同——研究指出：「兩個數字可以同時成立，因為測的是不同資料」，並以此說明為何需要共同基準。

AUC 不是部署時該看的數字#

排名回答的是「哪個系統最能區分對錯」，而不是「哪個系統能幫助我的代理」。第二項實驗直接測試後者：為每個項目評分，把分數最低的 20% 交給較強模型重新作答，其餘項目維持原樣；所有實驗組使用同一個重答池，因此沒有任何一組能靠較幸運的重試占優勢；以 200 個隨機種子取平均。未使用閘門的基準為 74.83%：

閘門	最終準確率	相較未使用閘門
ZTC	76.16%	+1.34 pp
JEV	74.76%	−0.07 pp
隨機	74.58%	−0.25 pp

ZTC 與 JEV 之間 0.0014 的 AUC 差距，轉化為端到端準確率 1.4 個百分點的變化，因為重答有利有弊——送回重答的錯誤答案有 38% 的機率被修正；正確答案則有 30% 的機率被弄錯——因此閘門部署價值取決於精確率，而非召回率。在 20% 預算下，JEV 導向重答的 403 個項目中，有 216 個原本正確（「修好的數量和弄錯的差不多」）；ZTC 導向重答的 403 個項目中，有 195 個原本正確。AUC 欄位看不出這種不對稱。適用範圍：一個升級目標、一組項目——研究將此結果視為一種機制，而非普遍定律。

已發布、尚未發布與待處理的內容#

所有分數、標籤與評分程式碼均已發布；原始項目並未重新散布（受語料及商業模型輸出授權／存取限制）。有四項重現無法使用已發布的產物執行（缺少分類器輸出層、不支援的架構、tokenizer 不完整），研究列出失敗原因，沒有略去。有一項重新測量的結果與先前數值相差甚多，重現工具目前仍無法解釋；研究將其標記並保留舊數字，而非默默調低。

供應商自己的論述（TypeSafe 發布文，2026-09-15）#

發布文章（創辦人 Diogo Almeida，vendor-claim）是此類別的主要來源，其對產品的定位比上述基準更廣。驗證（「評分、判斷、驗證、設置護欄，以及偵測越獄」）是四項主打用途之一；排在首位的是**「AI 驅動工作流程／智慧 if 陳述式」**——將結構化輸出嵌入一般程式碼，作為模糊決策規則（分類、路由、評分、擷取、分支），適用於「手寫邏輯太脆弱」的地方，並由周邊程式碼限制模型的自由度。上方的共同排行榜只評估驗證用途。

主張內容。 一種搭配平行取樣器的非 LLM 架構——每次查詢即可產生所有輸出，選項數最多可達 255——透過用於校準決策的 RL（RLCD）訓練，目標是產生「具備認識論誠實機率的答案」，而非評分者偏好的文字（RLHF），或可由程式檢查的輸出（RLVR；供應商指稱後者在判斷任務上會造成「尖峰／不穩健的智慧」）。每個輸出都帶有機率；供應商主張，信心愈高，準確度也愈高，而且相似輸入會得到相似答案。價格為輸入每 MTok $0.042，輸出不計費；每次呼叫需 70–500 毫秒。訓練演算法、架構及資料細節均未公開。首頁標題所稱的速度快 193.6 倍、便宜 444.6 倍，來自下方的工作流程評估；供應商自己稱之為「真實世界效益較高的一端」。

工作流程評估能說明什麼，不能說明什麼。 四個工作流程都以程式碼撰寫（固定計算圖）；每個模型都執行相同工作流程，而「準確度」指的是與 GPT-6 Astra 和 Fable 5.1 機率平均值的一致程度，並非對照真值。已公開的最簡單案例是安全警示分類：三項判讀（是否未經授權？是否有紀錄事先說明？證據強度為何？）、負責關閉、排隊或採取行動的程式碼（P(未經授權) > 0.75 時採取行動；身分警示若落在 0.15–0.60 的灰色區間，則通知使用者）、十一項圍堵判讀，以及依序比對五組規則、以「緊急則升級處理」結尾的操作手冊。以下為四個工作流程的平均值（從對數刻度圖表讀取，約略值）：

模型	工作流程內：成本／準確度	生成提示詞、在 CoT 中處理邏輯：成本／準確度
Jev	~$0.0004 / ~68%	—
GPT luna	~$0.0035 / ~67%	~$0.008 / ~52%
GPT terra	~$0.03 / ~68%	~$0.075 / ~61.5%
GPT sol	~$0.085 / ~74%	~$0.2 / ~63.5%
Claude Opus 5	~$0.18 / ~73%	~$0.35 / ~65%
Claude Sonnet 5	~$0.12 / ~68%	~$0.22 / ~60.5%
DeepSeek v4 pro	~$0.04 / ~65.5%	~$0.09 / ~60%

標題沒有呈現的三項觀察。Jev 贏得的是成本前緣，而非準確度前緣：sol 和 Opus 5 與參考答案的一致度高出約 5–6 個百分點，成本則高出約 200–450 倍——帕累托前緣依序為 Jev → luna → terra → sol。這項指標有天花板：若某模型比 Astra 和 Fable 更正確，卻因意見不同而得分更低；因此，這項評估衡量的是與前沿模型有多接近，而供應商也承認，參考答案偏向 OpenAI 和 Anthropic 的模型。其他所有可能影響結果的因素也都由供應商掌控，文章對此直言不諱：工作流程由 TypeSafe 的能力團隊撰寫（「可能存在某些偏差」，但「不在我們的訓練分布內」）；LLM 則透過 TypeSafe 自家的「System One LLM wrapper」執行。供應商稱這是從 LLM 取得決策最準確的方式，而且比不要求機率的決策方式更慢、更貴——因此，LLM 的成本數字包含供應商自行選擇加入的額外開銷。工作流程與提示詞的比較是最容易推廣的結果，本文將其放在將代理工作結晶為工作流程中討論；在每個受測 LLM 上，相同模型置於固定程式碼中，都比透過 chain-of-thought 推理邏輯高出約 5–15 個百分點，成本約為一半——部分原因是評估本身的設計所致，因為其前提（「我們假設存在正確的計算圖」）意味著參考答案也是透過工作流程計算的。

型別安全作為可靠性論據。 發布文的第二張圖使用 OpenRouter 流量資料，列出 LLM 的結構化輸出與工具呼叫錯誤率；Jev 的 0% 並非「實證結果——而是由於 schema 比對有保證。」LLM 的數字比 0% 更值得注意：各供應商排名在兩個圖表之間完全反轉。結構化輸出錯誤：luna 和 terra 為 0.58%，sol 0.83%，astra 1.43%，Gemini 3.1 Pro 1.94%，Gemini 3.8 Flash 3.15%，Opus 5 5.73%，Fable 5.1 8.25%，Sonnet 5 13.2%，Haiku 4.5 45.5%。工具呼叫錯誤：Opus 5 0.67%，Fable 5.1 1.38%，Haiku 4.5 1.76%，Sonnet 5 2.07%，Gemini 3.8 Flash 2.15%，Gemini 3.1 Pro 3.17%，terra 5.5%，luna 7.67%，astra 16.6%，sol 17.0%。OpenAI 模型在一種介面上最佳，在另一種上最差；Anthropic 則相反。供應商自己的但書仍適用——OpenRouter 路由資料並非受控樣本。型別安全也不等於正確性：符合 schema 的錯誤判決仍然是錯的，而這正是上方重試閘門結果衡量的內容。

關於基準測試。 TypeSafe 表示刻意不發布任何公開基準分數，只在產品更新時進行單次評估，並鼓勵使用者自行建立評估（「System One 任務容易得多，較易評估」）——這是供應商採納來自生產環境的評估立場。共同排行榜開頭則提出了相反的提醒：「每家答案驗證供應商都會發布一項基準測試，而每一家都在自己的基準測試中獲勝。」TypeSafe 自家的評估也在其選定的軸線（成本）上勝出；值得注意的是，供應商並未宣稱自己在一致度上勝出。

供應商與獨立排行榜之間的歧異#

• 校準與閘門精確率。 RLCD 承諾提供誠實的機率，這正是重試閘門所需的特性。在共同排行榜中，Jev 分數最低的 20% 有 216 個答案原本正確，共導向重答 403 個項目（ZTC 則為 195 個）；閘門淨效果為 −0.07 個百分點。這並非反證——沒有依據文件的答案正確性驗證，不等同工作流程決策，而且 AUC 0.7350 是排行榜並列最佳——但這是校準主張唯一的獨立測量結果，且在校準最重要之處表現並不理想。此處以 empirical 的權重高於 vendor-claim；問題仍未解決（見下文）。
• 延遲。 供應商稱，從美國西岸筆記型電腦測得 70–500 毫秒。排行榜稱 Laya 約 0.015 秒，「比我們測量的託管 API 快約 140 倍」；依上下文判斷，該 API 指 Jev，約需 2 秒。兩者都未說明輸入長度或客戶端位置；尚無定論。
• 價格。 兩者一致：排行榜上的每 1,000 次呼叫 $0.024，相當於供應商每 MTok $0.042、每次呼叫約 570 個輸入 token 的價格。

合作夥伴部署：另外三個數字，沒有一個是準確度（LangChain，2026-09-25）#

LangChain 的整合文章（Runkle 與 Lovell，vendor-claim——Jev 整合合作夥伴，同時銷售文中展示的 LangGraph 執行環境及 LangSmith 追蹤工具）是此類別第一篇第三方部署報告，其中所有數字都關乎速度或穩定性：在訴訟證據探索審查圖的分類步驟中，Jev 比 Sonnet 快 5–6 倍；Jev 作為評審的分數「在重複執行 100 次後幾乎沒有變動，遠低於我們測試過的任何 LLM 評審」；Browserbase 的 Stagehand act() 中位數從 1.97 秒降至 0.46 秒，由 Jev 選擇瀏覽器動作，信心低於 0.7 時則交由 LLM 備援。詳情見 Jev。

對照本文來看，每個數字涵蓋的都是獨立排行榜未測量的面向，並漏掉排行榜有測量的面向：

• 一致性不等於校準。 100 次執行的穩定性主張，是供應商所稱「相似輸入會得到相似答案」這項特性的首次實驗驗證（但未量化）。它沒有說明穩定分數是否正確——排行榜上的重試閘門結果是與一致性相容的失敗：一批穩定排名低分的答案中，超過一半原本正確。對 LLM-as-a-Judge 而言，這項主張本身就有意義：評審在不同執行間的變異，是測量必須承受的雜訊；穩定的評審能消除一個誤差來源，但不會改變偏差。
• 0.7 備援閾值就是另一種形式的重試閘門。 Stagehand 的級聯架構將低信心決策轉給較強的模型——這正是排行榜測試的機制；結果是 Jev 閘門因精確率不佳，淨效果為 −0.07 個百分點。Browserbase 報告了延遲改善（大多數呼叫走低成本路徑），卻沒有提供備援比例或任務成功率。因此，排行榜指出決定閘門價值的唯一問題仍未回答：有多少高信心錯誤操作能通過閾值？下方列為開放問題。
• Stagehand 是動作空間的案例。 網頁會提供一份有限的互動元素清單，因此下一個瀏覽器動作就是從清單中選擇——推理與行動交錯（ReAct）所稱的「從列舉的有效集合中，以分類方式選擇動作」。這項作法已搭配型別化選項模型投入使用，而模型最多可支援 255 個選項，構成列舉數量的硬上限。

證據與利益衝突#

保留 empirical——這是一項真實且可重現的基準測試，評分程式碼已公開，並以共同測試集測試，而非使用供應商自家的資料。文章由單一社群作者撰寫，未經同儕審查；作者看不出與任何上榜供應商有關聯（兩個與 VIDRAFT 有關的帳號只在 HuggingFace 文章中擔任按讚者，並非作者） (2026-09-29 重新閱讀 Jev 發布文原始資料並彙整時，這一點已被新資訊推翻：方法段落表示「在我們自己的系統上，合併數字為 0.80，而按領域平均則為 0.73」；待處理項目註記則寫道：「僅憑我們自己的不可信程式碼調低競爭對手的分數，不能算是更正」——因此作者在這份排行榜上有自己的系統。按領域計算的 0.73 與兩個 ZTC 列相符（0.7364／0.7282），而與 VIDRAFT 有關的帳號也為該文按讚；作者的系統最可能是 ZTC，也就是排名高於 Jev 並在重試閘門實驗中勝出的項目。尚未確認，但這表示這是一份參賽者自己執行的排行榜，而非中立排行榜)。據此調整權重：沒有第二個團隊重現這份排行榜；「一個項目待處理」的揭露，是作者自己尚未解決的差異，並非外部稽核發現。

延伸閱讀#

• 程序獎勵模型與結果獎勵模型 — 這項研究中的受訓參賽者（ZTC、JEV、open-jev、Lynx、Laya）位於答案／結果驗證器的訓練發展脈絡下游；該文指出，候選項目超過數百個後，驗證器精確率會下降，這是不同於本文跨系統 AUC 比較的軸線（候選數量擴展），但兩者有相同主題：「驗證器的摘要分數並不能說明全部」
• 在雜訊驗證器下停止 — 本文核心結果的一般形式。該文根據修復模型，計算驗證與修復迴圈的停止邊界；驗證器的辨別力（Youden's J）只能指出相對位置。本文則提供第二個獨立實證案例，展現相同的分離現象——0.0014 的 AUC 差距造成部署準確率 1.4 個百分點的變化，因為閘門價值取決於精確率，而非 AUC 以召回率加權的排名
• Weak-Verifier Ensembling — 本研究以 13 個系統及同一測試集進行評估，是本文語料中最接近 Weaver 式實際驗證器集合的實證案例。這些驗證器由不同團隊獨立建立，包含訓練分類器及 LLM 評審，不同於單篇論文內的消融實驗；但研究沒有提供系統間的成對錯誤相關性，因此無法回答該文的開放問題：不同類型（訓練式驗證器與提示式評審）之間的錯誤相關性，是否低於 wiki 實際測得的評審對評審相關性
• LLM-as-a-Judge — 四個會產生 token 的參考列（GPT-5.2、GPT-4o-mini、Gemini 2.5 Flash-Lite、Qwen3-Next-80B），正是該文所探討的主題；在同一軸線與資料集上，與型別化決策參賽者比較後，排名位於中段至末段，每次呼叫的成本也比排名最高的型別化決策系統高一到三個數量級
• Jev — 為此類別命名的模型；其實體頁並列發布主張與獨立測量數字
• Trained Calibration — RLCD 是供應商命名的一種方法，把校準作為決策模型的完整訓練目標；上方的重試閘門結果，是唯一獨立檢驗它是否能提供閘門所需特性的結果
• 將代理工作結晶為工作流程 — Jev 的主要宣傳訴求，正是該文所述的第二類混合模式（程式碼掌控控制流程，模型提供讀數）；發布文中工作流程與提示詞的比較，以測量結果支持此分工，但也有循環論證的但書
• Cost-per-Task Over Cost-per-Token — 以每個工作流程的成本作為分母：發布文為整張決策圖定價，其帕累托前緣顯示，Jev 的成本約為前沿 LLM 的二百分之一，一致度則低約 5–6 個百分點
• 苦澀的教訓 — TypeSafe 所稱的「最苦澀教訓」（正確的訓練目標勝過資料、計算資源與演算法）是對 Sutton 主張的供應商式反轉，卻未提供證據
• 推理與行動交錯（ReAct） — Stagehand 的 act() 重建版（LangChain 文章）是在生產環境中實作該文所說的有效動作列舉分類：標示互動元素、由型別化選項挑選一項，信心不足時升級交由 LLM 處理
• 來自生產環境的評估 — 供應商拒絕發布公開基準分數，轉而推動客戶自行建立評估；這是該文主張被採納為行銷政策的例子

開放問題#

• 這項研究在共同資料集上報告各系統 AUC，卻沒有提供系統間的成對錯誤相關性。**型別化決策系統彼此之間的錯誤相關性，與型別化決策系統對 LLM 評審的錯誤相關性是否不同？**兩者是否都低於本 wiki 在其他地方測得的評審對評審相關性（在 wiki 的評審依賴研究中，ρ̄ ≈ 0.2–0.97）？需要取得已發布的逐項目分數，但這份原始資料沒有收錄。
• 重試閘門機制（部署價值取決於精確率，而非召回率）只在一個升級目標、一個項目池與一種預算（20%）下測量。ZTC 在精確率上的優勢是否也適用於其他重試預算？還是會像科學推理上 397B 和 27B 設定間的規模效應那樣反轉？
• 來源中尚未解決「待處理」項目（重新測量結果不同，而工具尚無法解釋）。是哪個系統？最後的結果調和後，分數是否會落到表面特徵基準以下？
• 發布文宣稱 RLCD 能產生校準良好且一致的機率；唯一的獨立測試（上方的重試閘門）發現，Jev 的低分區只比其他區域多一點錯誤。**若在工作流程決策任務中，對照真值而非雙 LLM 參考答案，Jev 的校準表現如何？**例如，能否以 TypeSafe 自家的安全分類工作流程和標註結果繪出可靠度圖？
• Browserbase 的 Stagehand act() 級聯架構（Jev 選擇動作；信心 <0.7 時交由 LLM 備援）只報告延遲（中位數從 1.97 秒降至 0.46 秒）。**有多少比例的動作會高於 0.7 閾值？與純 LLM 的 act() 相比，端到端任務成功率是持平、下降還是上升？**也就是說，共同排行榜測得的重試閘門精確率問題，是否會在正式環境的級聯架構中再次出現？

資料來源#

• Inside the JEV Ecosystem: 13 Answer Verifiers on One Test Set — Proto_AGI（mayafree），Inside the JEV Ecosystem: 13 Answer Verifiers on One Test Set，HuggingFace 社群文章，發布於 2026-09-20，empirical。排行榜：huggingface.co/spaces/mayafree/typed-decision-leaderboard。沒有表格解析風險——問題是 HTML／Markdown 被截斷，而非從 PDF 衍生；所有引用數字都直接符合來源文章中的文字與表格。
• Introducing System One Models & Jev — Diogo Almeida，TypeSafe AI 部落格，Introducing System One Models & Jev，2026-09-15，vendor-claim。比較表、工作流程評估帕累托圖（攝取時從對數刻度圖讀取數值，為約略值，誤差 ±~1 個百分點／成本 ±~20%；彙整時重新核對）、安全分類工作流程圖（fig2）、結構化輸出／工具呼叫錯誤率長條圖（fig3；印刷標籤，已對照圖片確認）。未收錄三段示範影片。非 PDF 衍生，無 docling 風險。
• Building Prod with Jev and LangGraph — Sydney Runkle 與 Hunter Lovell，LangChain 部落格，Building Prod with Jev and LangGraph，2026-09-25，vendor-claim（Jev 整合合作夥伴）。引用三項合作夥伴提供的數字（比 Sonnet 快 5–6 倍、100 次執行的評審穩定度、Stagehand 延遲；最後一項來自 Browserbase，屬二手資訊）。文中沒有任何準確度、一致度或備援比例數字。非 PDF 衍生；四個數字已於資料攝取時謄錄，兩張 LangSmith 螢幕截圖已於彙整時重新核對。