「不生成文字的模型」——Jev 與 System One 新品類：當 AI 只回答選擇題，Agent 架構會怎麼變？

這不是一次漸進式改善。它代表一個新品類：System One 模型，專門做快速、結構化、可校準的決策，把「判斷」與「寫作」徹底拆開。對正在構建 agent 架構的團隊，這是一個值得認真評估的基礎組件。

項目概覽

為什麼這件事重要：一個反直覺的模型

過去三年，整個行業的直覺是「更大的模型 → 更強的生成能力 → 更好的 agent」。每一家實驗室都在追逐下一個 GPT、下一個 Claude，比拼的是上下文窗口更長、生成速度更快、多模態能力更廣。在這個敘事裡，「更好的模型」等於「能生成更多、更好文字的模型」。

Jev 走了一條完全相反的路：

刻意放棄文字生成能力，換取結構化決策的速度、成本與確定性。

它不能寫回覆、不能生成代碼、不能摘要、不能解釋推理。但它在「這封 support ticket 屬於哪個部門？」「這條評論的毒性等級？」「這個交易是否可疑？」這類高頻、高量、需要判斷力的決策上，比 frontier LLM 快兩個數量級、便宜數倍，而且結構化輸出錯誤率為零（by construction，因為根本沒有生成過程，答案必然落在你定義的 schema 內）。

這對 agent 架構的啟示是深層的：不是所有智能行為都需要生成文字。大量 agent 內部的「判斷」步驟，路由分類、實體選取、守門條件、優先級打分，其實只是分類、打分、布爾決策。這些正是 System One 模型的領地，而不是 LLM 的甜區。用 LLM 做這些事，就像用大炮打蚊子：慢、貴、且概率不可校準。

Jev 是什麼：System One 模型的三種題型

Jev 的名字來自 Daniel Kahneman 的《快思慢想》（Thinking, Fast and Slow），System 1 是快速、直覺、模式匹配的思維系統，負責日常大部分判斷；System 2 是慢速、刻意、邏輯推理的系統。Jev 刻意只覆蓋 System 1 這個維度，把 System 2 留給 LLM。

三種題型

一個 API 請求可以同時包含數百條問題，一次 forward pass 並行回答。這與 LLM 的逐 token 自回歸生成形成根本對比，Jev 沒有「生成」過程，它做的是編碼狀態 → 並行打分 → 輸出概率分佈。整個過程是確定性的前饋計算，沒有採樣、沒有解碼、沒有文字拼接。

舉個具體例子：假設你有一個客服工單分類場景，需要判斷工單屬於哪個部門（choice，5 個選項）、緊急程度（score，1-5 級）、是否需要立即升級（noul）。用 LLM 做，你需要構造 prompt → 等待自回歸生成 → 解析 JSON → 驗證 schema → 失敗重試。用 Jev 做，你構造一個包含三條題型問題的請求，~100ms 後拿到三個校準概率分佈，沒有解析層，沒有重試邏輯。

校準概率（Calibrated Probabilities）

Jev 的核心賣點不只是「快」，而是校準：它說 90% 的事，大約 90% 是準的。這不是 accuracy，accuracy 是單次判斷的對錯；calibration 是概率與實際結果的長期匹配度。

一個直覺的类比：一個校準良好的天氣預報模型，在它說「明天有 70% 機會下雨」的日子裡，長期下來確實大約 70% 的日子會下雨。這不代表它每次都能預測對，但那 30% 沒下雨的日子，是它誠實表達的不確定性，而不是系統性的過度自信。

對 agent 架構而言，calibration 才是真正的決策基礎：你可以根據概率高低設定閾值，高信心（>95%）自動執行、中等信心（70-95%）路由到 LLM 做二次確認、低信心（<70%）escalate 到人類。這是 LLM 的 logprobs 長期做不到的事，LLM 的 token 概率在決策場景上普遍過度自信，說 99% 的事可能只有 70% 準。用 LLM 的 logprobs 做 confidence gating，就像用一個沒有校準過的溫度計來控制恆溫器：方向大致對，但精度不夠。

為什麼快 200 倍又便宜 5 倍

TypeSafe 官方聲稱 Jev 比 frontier LLM 快 193.6 倍、便宜 4.6 倍（公司自稱，屬高階估算，尚未獨立驗證；SiliconANGLE 報道指出另一組對比顯示便宜 445 倍，差異取決於比較基準）。但即便打個折扣，量級差異是真實的。原因在架構層面：

第一，沒有自回歸生成。 LLM 的延遲主要來自逐 token 解碼，一個 500-token 的回覆需要數百次 forward pass，每次都要跑完整個模型。Jev 一次 forward pass 完成所有問題，延遲固定在 70-500ms，與問題數量幾乎無關。當你需要同一個 prompt 上回答 100 條問題時，LLM 的成本隨問題數線性增長，Jev 的成本幾乎不變。

第二，並行 sampler。 TypeSafe 設計了專用並行取樣器，一個 prompt 同時展開數百條題型查詢。這更像是 batch inference 的極致優化，而非傳統 chat serving。從開源複製品 OpenJev 的數字推測（H100 上 28ms 完成 10 條問題），這種並行化在硬體層面已經被充分實現。

第三，output 免費。 定價模型完全基於 input tokens（$0.042/MTok），output 零成本。對比 GPT-5.6 Luna 的 $0.20-10/MTok input + 可觀 output 費用，Jev 在高吞吐決策場景的成本優勢是結構性的。TypeSafe 官網給出的對比是：每 1,000 個工作流 $0.39，而 OpenAI GPT-5.6 Luna 要 $3.31，差距約 8.5 倍。

第四，更小的有效模型。 雖然 TypeSafe 沒有公開 Jev 的參數量，但從其開源複製品（0.4B-0.6B）的性能推測，Jev 的底層模型規模遠小於 frontier LLM，它只需要足夠做類型化決策，不需要承載世界知識與生成能力。模型小 → 推理快 → 硬體成本低 → 定價便宜。這是一個正向循環。

RLCD：與 RLHF 的根本差異

Jev 的訓練方法叫 RLCD（Reinforcement Learning for Calibrated Decisions），這是 TypeSafe 的核心技術貢獻，也值得理解，因為它代表了對「模型應該優化什麼」這個根本問題的一個新答案。

RLHF 優化什麼？

RLHF（Reinforcement Learning from Human Feedback）優化的是人類偏好：給模型兩個回覆，讓人類選較好的那個，訓練一個 reward model 去預測人類選擇，再用 PPO 等算法優化策略。結果是模型學會「寫出人類喜歡的文字」，但這個「喜歡」與「正確」之間的關係是間接的、模糊的。人類偏好受措辭、長度、語氣、格式等表面特徵影響，reward model 很容易學到這些表面特徵而非深層正確性。這就是為什麼 LLM 可以「自信地說錯話」，它優化的是「看起來對」，而非「確實對」。

RLCD 優化什麼？

RLCD 優化的是概率與實際結果的匹配度：如果模型給某個選項 90% 概率，那在大量類似場景中，該選項確實應該在 ~90% 的情況下是正確的。損失函數直接度量這個 calibration gap，常用指標包括 Brier score（預測概率分佈與真實結果之間的均方距離）或 ECE（Expected Calibration Error）。

這意味著 RLCD 不關心模型「說了什麼」，它只關心模型給出的概率分佈是否與現實匹配。一個 RLCD 訓練的模型可能「不知道」法國的首都是巴黎（因為它不需要生成文字），但它能準確告訴你「這段文字是否包含虛假信息」的概率是 87%。

根本差異

Diogo Almeida 作為 RLHF 的共同發明人，轉而設計 RLCD，這個軌跡本身就值得注意。他不是否定 RLHF，RLHF 在開放式生成場景上仍然是最優解，而是在一個特定場景（結構化決策）找到了一個更合適的優化目標。這種「知道自己發明的方法在哪裡不夠用，然後設計更好的方法」的態度，比任何技術細節都更能說明問題。

刻意放棄的能力 = 設計哲學

Jev 最有趣的設計決策不是它能做什麼，而是它不做什麼：

• ❌ 不能寫回覆
• ❌ 不能生成代碼
• ❌ 不能摘要
• ❌ 不能解釋推理
• ❌ 不能進行開放式對話

這些「不能」不是技術限制，而是設計選擇。TypeSafe 的論點是：當你把「生成」能力從模型中移除，你得到的是：

1. 確定性輸出：答案必然落在你定義的 schema 內，結構化錯誤率為零。不需要 JSON mode、不需要 schema validation、不需要重試邏輯。
2. 可校準的概率：模型不試圖「說服」你，只給出概率分佈。沒有措辭修飾、沒有語氣操控、沒有「我很確定但其實不確定」的幻覺。
3. 極致速度與低成本：不需要自回歸解碼，不需要大參數量承載世界知識。模型只做一件事，做到極致。
4. 可組合性：Jev 的輸出是類型化的概率值，可以直接餵給確定性代碼，不需要解析層。這是「AI as software primitive」的理念，模型不是聊天對象，而是代碼中的一個函數調用。

這背後的哲學是決策與生成分離：

Jev 決定，LLM 寫作。

在 agent 架構中，這意味著一個清晰的分工：

• 路由、分類、守門、打分 → Jev（System One），快、便宜、可校準、確定性輸出
• 回覆生成、代碼編寫、解釋推理、開放式對話 → LLM（System Two），慢、貴、靈活、創造性

兩層模型各司其職，整體系統更快、更便宜、更可控。這不是「Jev 取代 LLM」的敘事，而是「Jev 與 LLM 組成互補架構」的敘事。

開源複製品生態

Jev 的 API 仍在早期訪問（waitlist），但開源社區已經在極短時間內產出了一批複製品。截至 2026-09-19，主要有以下項目：

幾個值得注意的觀察

OpenJev 的數字最扎實。 kotobalabs 給出了完整的三種子實驗、in-domain vs OOD 拆分、與 LoRA-tuned LLaDA-MoE-7B-A1B 的對比（0.835 in-domain，延遲 16 倍），以及 head ablation（marker-token head 不學習，span head 學習）。這是目前開源複製品中方法論最透明的一個。它的結論很誠實：in-domain 0.847 說明 Jev 式架構在熟悉場景上有效，OOD 0.678 說明泛化仍是開放問題。

openjev 的 NLI 角度有趣。 AlexWortega 把 Jev 式決策歸約為自然語言推斷（NLI），entailment / contradiction / neutral 三分類，然後用這個 primitive 做 rerank、grade、guard，甚至從像素直接玩 Doom。這展示了「Jev 式決策」的歸約能力：一個足夠強的 NLI cross-encoder 可以充當通用決策引擎。35B MoE 版本在 zero-shot 下就能玩 Doom，這是一個令人印象深刻的 demo。

PyPI 的 jev 套件把 API 接入做到了 Pythonic 極致：一個 @jev.fn decorator，函數簽名就是決策規範，docstring 是 state，return annotation 是 schema，沒有 prompt 字串、沒有 JSON schema、沒有解析層。bool 欄位自動編譯為 noul、Literal[...] 自動編譯為 choice、帶 Field(ge=, le=) 的 int 自動編譯為 score。這是「function signature as decision spec」理念的完整實現，也是 Python 生態中少見的「類型系統即接口」的優雅設計。

對 Agent 架構的啟示

1. 結構化決策不必用 LLM

Agent 內部大量步驟是「判斷」而非「生成」：路由分類、實體選取、守門條件、優先級打分、意圖識別、毒性檢測。這些步驟用 LLM 做，就像用大炮打蚊子，慢、貴、且概率不可校準。

Jev 式模型提供了一個新選項：把 System One 決策下沉到專用模型，只在需要開放式生成時才調用 LLM。這可以顯著降低 agent 的整體延遲與成本，同時提高決策的可控性。

2. 本地小模型可行性

OpenJev 在 H100 上 28ms/10 題、在 M1 Max CPU 上 1.8s/4 題的數字表明：Jev 式決策可以在本地小模型上跑，不需要依賴雲端 API。對延遲敏感或隱私敏感的場景（金融交易守門、醫療分類、法律文檔分類），這是一個重要選項。

0.4B-0.6B 的模型規模意味著它可以跑在消費級 GPU 甚至 CPU 上，這與 WeMM-Embedding 2B 在 Mac Studio 上 47ms 的實測形成呼應：agent 基建的下一代組件，正在向消費級硬體遷移。

3. Calibration 是 agent 決策的正確基礎

LLM 的 logprobs 長期被用來做 confidence gating，但 LLM 的 token 概率在決策場景上普遍過度自信，說 99% 的事可能只有 70% 準。Jev 的 RLCD 訓練直接把 calibration 作為優化目標，這才是 agent 自動駕駛（auto-routing、confidence-gated escalation）的正確基礎。

想像一個 agent 的 triage 流程：Jev 對每條輸入給出決策概率，>95% 自動處理、70-95% 路由到 LLM 做二次確認、<70% escalate 到人類。這個流程的可靠性直接取決於 calibration 的質量，如果 Jev 說 95% 的事只有 80% 準，那自動處理的閾值就需要調高，更多流量會漏到 LLM 和人類，成本優勢就會縮小。

4. 「決策與生成分離」是架構模式

Jev 的哲學不只是「用另一個模型做分類」。它提出的是一個架構模式：

Agent Loop:
  ├─ System One（Jev / OpenJev）：路由、分類、守門、打分 → 快、便宜、可校準
  └─ System Two（LLM）：生成、推理、解釋、對話 → 慢、貴、開放式

這個模式與人類認知系統的雙過程理論（Kahneman 的 System 1 / System 2）直接對應，也與 agent 架構中「fast thinking / slow thinking」的分層需求吻合。它不是要取代 LLM，而是要把 LLM 從它不擅長的「高頻低延迟決策」中解放出來，讓它專注於「開放式生成與推理」。

冷眼觀察

公司自稱數字需驗證

TypeSafe 聲稱 Jev 比 frontier LLM 快 193.6 倍、便宜 4.6 倍（或 445 倍，依比較基準不同）。這些數字尚未獨立驗證，且高度依賴工作負載、比較基準與網絡環境。SiliconANGLE 報道明確指出「Those figures have not been independently verified and will vary by workload, network location and comparison method.」在親手跑 benchmark 之前，這些數字應該視為高階估算，而非工程事實。

校準 ≠ 準確

Calibration 是概率與結果的匹配度，不是單次判斷的準確度。一個模型可以完美校準但準確率只有 60%（說 60% 的事確實 60% 對），這在低難度任務上可以接受，但在高風險決策（醫療、金融、法律）上可能不夠。開發者需要在自己的數據上驗證 Jev 的 calibration 與 accuracy，而不是盲目信任官方數字。

賽道競爭

Jev 不是唯一瞄準「結構化決策」賽道的玩家。Conformal Prediction、Guidance 框架、Outlines、LLM-based structured output（JSON mode、tool use）都在解決類似問題。Jev 的差異化在於端到端專用模型 + RLCD 校準，但這個護城河是否足夠深，開源複製品的快速湧現（7 個項目在一週內）是一個值得關注的信号，它說明「Jev 式決策」的架構門檻並不高，核心壁壘可能在數據與校準質量，而非架構本身。

開源複製品的性能差距

OpenJev 的 in-domain 0.847 / OOD 0.678 數字表明，開源複製品在 OOD 場景上仍有顯著性能下降。TypeSafe 的 Jev 聲稱達到 frontier LLM 水平的 intelligence，但這個聲稱基於私有測試，無法直接與開源數字對比。結論：開源複製品已經證明「Jev 式決策」的架構可行，但性能差距仍需閉源模型與開源社區共同推進。

結語

Jev 代表的不只是一個新模型，而是一個新品類的出現：System One 模型，專門做快速、結構化、可校準的決策，與 LLM 的開放式生成能力形成互補。

對 agent 架構師而言，它提出了一個值得認真考慮的模式：把決策與生成分離，用 System One 模型處理高頻、高量的判斷步驟，用 LLM 處理需要開放式生成的步驟。這可以顯著降低延遲、成本與不可控性。

開源社區的快速跟進（7 個複製品項目在一週內湧現）證明這個品類的吸引力與架構可行性。但公司自稱的性能數字仍需獨立驗證，校準與準確的區別仍需牢記，賽道競爭仍在早期。

我們的下一步：在一個真實 agent 工作流（support ticket triage）上跑 Jev API 與 OpenJev 本地模型，測量真實延遲、成本與 calibration，與現有 LLM-based 方案對比。數據說話。

參考：TypeSafe AI 官方博客 · Flavio Copes 深度拆解 · SiliconANGLE 報道 · The Register 報道 · OpenJev (kotobalabs) · openjev (AlexWortega) · jev PyPI v0.3.0 · OpenJev 瀏覽器演示