top of page

JEV 由淺入深：一個不寫字的模型，怎樣替系統做判斷

13小时前
讀畢需時 11 分鐘

2026 年 9 月 15 日，TypeSafe AI 發佈 JEV（官方寫法為 Jev）。過去三年大家熟悉的 ChatGPT、Claude 一類模型，強項是寫文章和對話；JEV 走的卻是相反方向。它不寫任何文字，只回答預先定義好的選擇題、評分題與是非題，並為每個答案附上機率。

用足球比喻：賽後寫戰術分析的是分析員，場邊舉旗的是旁證。分析員要組織語言，旁證只需在一瞬間答「越位」或「不越位」，而且要答得準。過去的 AI 系統把兩類工作都交給同一個會寫字的模型，JEV 想接手的是旁證那一類。

本文涉及賽果預測與博彩市場的例子，只作技術說明，不構成任何投注建議。

本文重點

本文分四部分：先解釋 JEV 的設計概念，再逐項對比傳統 LLM，然後用幾個足球數據工作流程示範它應該放在哪裏、不應該放在哪裏，最後交代 AIP 系統打算怎樣使用這類模型。

讀完之後，讀者應能判斷一個 AI 工作步驟屬於「寫」、「判斷」還是「計算」，並知道三者各自應交給甚麼工具。


一、先分清兩類工作：寫與判斷

TypeSafe 把這類模型稱為 System One Model，名稱取自 Daniel Kahneman《Thinking, Fast and Slow》的雙系統理論。System Two 是緩慢、刻意、用語言推理的思考，LLM 寫出一段推理過程，模仿的正是這一類。System One 則是一瞬間的直覺判斷。

軟件裏有大量 System One 式的工作：這宗客戶查詢屬於哪一類？這條新聞與今晚的比賽有沒有關係？這個 tool call 是否安全？這些問題的答案本身很短，一個標籤、一個分數或一個是與否，並不需要一段文字。

模型名稱則來自經濟學家 William Stanley Jevons。他在 1865 年指出，蒸汽機燒煤效率提高之後，英國的用煤量不減反增，後世稱為 Jevons paradox。TypeSafe 的判斷是機器智能會走同一條路：判斷的成本每降一個數量級，就會多出一個數量級的用途。

創辦人 Diogo Almeida 曾在 OpenAI 參與令語言模型學會遵從指示的研究，也就是 ChatGPT 背後的方法。他在發佈文章中提出的問題相當直接：模型在對話上早已超越人類，自動化卻遲遲未普及，原因在哪裏？


二、JEV 的輸入與輸出

JEV 的調用只有兩部分。state 是背景資料，可以是一段文字、一個 JSON 物件或一組文字；questions 是針對這份 state 提出的問題，每條問題屬於三種型別之一。

圖 1：同一個分支判斷，傳統 LLM 與 JEV 的兩種做法

三種型別如下：

Choice： 從最多 255 個帶描述的選項中選取一個，回傳選中的標籤、每個選項的機率，以及整體 confidence。

Score： 在 2 至 10 級的有序量表上定位，回傳一個可帶小數的加權分數、完整分佈與 confidence。

Noul： 是非題，回傳「是」的機率，介乎 0 至 1。Noul 沒有另外的 confidence，因為機率本身已表達確定程度：0.5 最不確定，兩端最確定。

圖 2：三種問題型別，以足球情境示範（數值為示意）

下面是一個賽前例子。兩條新聞互相矛盾：官方說名單稍後公佈，另一個來源說中鋒訓練受傷。一次請求可以同時問三條問題：

{
  "model": "jev-latest",
  "state": {
    "fixture": "主隊 vs 客隊，開賽前 70 分鐘",
    "news": [
      {"source": "主隊官方帳戶", "time": "T-75m", "text": "正選名單將於開賽前一小時公佈"},
      {"source": "本地體育網站", "time": "T-90m", "text": "據報主隊正選中鋒昨日訓練時扭傷腳踝"}
    ]
  },
  "questions": {
    "striker_out": {
      "type": "noul",
      "instructions": "已有官方來源確認主隊正選中鋒不會上陣"
    },
    "lineup_change": {
      "type": "score",
      "instructions": "主隊預計正選與上一場相比的變動程度",
      "criteria": ["沒有變動", "輪換一至兩人", "主力缺陣", "大規模輪換"]
    },
    "next_step": {
      "type": "choice",
      "instructions": "系統下一步應怎樣處理這場比賽",
      "criteria": {
        "rerun": "陣容已確定，可以重算模型",
        "wait": "消息未經官方確認，等待正式名單",
        "escalate": "消息互相矛盾且影響重大，需要人手判斷"
      }
    }
  }
}

合理的回應會是 striker_out 偏低（例如 0.38，因為沒有官方確認），next_step 選 wait。請留意 striker_out 的寫法：問題名稱不會傳給模型，判斷條件必須完整寫在 instructions 內，「官方來源確認」這個限定詞正是答案偏低的原因。

程式收到答案後按門檻分流，例如 next_step 的 confidence 高於 0.85 就照做，否則轉交人手。整個過程沒有任何文字需要解析。


三、與傳統 LLM 逐項對比

TypeSafe 在發佈文章中列出一張對照表，下面按原文整理。表中數字均屬廠方公佈：

項目

傳統 LLM

JEV

訓練方法

RLHF（人類偏好）、RLVR（可驗證獎勵）

RLCD（Reinforcement Learning for Calibrated Decisions）

優化目標

人類評分員較喜歡的回答；可程式驗證的輸出

機率誠實的判斷

輸出

字串，需要解析與驗證

預先定義的型別，附機率

生成方式

逐個 token 順序生成

所有答案一次平行產生

Input 價格

每百萬 token 0.20 至 10 美元

每百萬 token 0.042 美元

Output 價格

約為 input 的 5 倍

免費

端到端延遲

3 至 329 秒

70 至 500 毫秒

信心

即使要求自報，也傾向過度自信且前後不一

每個答案都附校準機率

圖 3：延遲與 input 價格區間（廠方公佈，對數尺度）

生成方式是差距的根源。LLM 即使開啟 JSON mode，也是一個 token 接一個 token 寫出答案，問十條問題就要寫十段輸出。JEV 放棄生成字串，改用 TypeSafe 所稱的平行 sampler，一次產生所有答案。LangChain 的整合文章也指出，同一請求多加幾條問題，回應時間幾乎不變，成本只增加那幾條問題的 input token。

輸出型別帶來第二個差異。LLM 的輸出可以是任何內容，包括格式錯誤、拒答或幻覺出來的欄位，程式要做解析、驗證與重試。JEV 的答案只能是預先定義的選項、量表上的一點或 0 至 1 的機率，型別錯誤在結構上不可能出現。

這一點需要準確理解。TypeSafe 宣稱 JEV「不會幻覺」，指的是不會幻覺出格式或選項；答案本身仍然可以錯，例如在四個合法選項中選錯一個。第三方整理網站 Made with Jev 對此寫得很清楚：它不是「零幻覺」，所以才需要 confidence。

速度數字方面，TypeSafe 首頁寫「快 193.6 倍、平 444.6 倍」。發佈文章交代這組數字來自他們自建的 workflow eval，以 GPT-6 Astra 與 Fable 5.1 的平均答案作參考，並承認這屬於實際收益的較高一端。獨立測試方面，Every 的 Dan Shipper 用十二段文字、四項寫作檢查比較 JEV 與 Fable 5.1：JEV 每段中位數 0.35 秒，Fable 8.83 秒，成本低約 580 倍；在七個預先埋下的錯誤中，JEV 找到六個，Fable 找到全部七個。

這個結果大概就是現時最公允的描述：在判斷類工作上快得多、平得多，準確度略低於頂級推理模型。值不值得換，視乎要做多少次判斷。


四、RLCD 與校準：為何機率比答案更重要

TypeSafe 對 RLHF 的批評相當尖銳。以人類偏好訓練的模型，學會的是寫出評分員喜歡的回答，而語氣肯定的回答往往得分較高，副作用就是過度自信。發佈文章舉的例子很實際：一個模型九成五的時間做得對，卻無法指出哪些是出錯的那半成，這項工作就不能自動化。

RLCD 的目標是校準：JEV 說 80% 的時候，長期應該有大約 80% 是對的。

圖 4：校準曲線與信心門檻（左圖為概念示意）

足球模型的讀者對這個概念不會陌生。一個賽果模型給主勝 60%，如果把所有「60% 主勝」的比賽集合起來，主隊實際贏的比例應接近六成。這與評估賠率模型時畫的 reliability diagram 是同一件事。

有了校準機率，程式就可以分級處理。TypeSafe 文件建議三級：高信心自動執行，中信心請用戶確認或標記覆核，低信心不行動，轉交人手或其他系統。破壞性動作的門檻要比唯讀動作高。

一個公開例子可以說明這種分流。開發者 Hassan 用 JEV 分類 100 封電郵（正常與詐騙各 50 封），全部完成只需 1.42 秒；confidence 低於 95% 的 31 封轉交 Kimi K3 複查，整條流程答對 96 封，總成本約 0.07 美元，其中 JEV 只佔 0.003 美元。

門檻不應照抄。官方文件與社群指南都強調 confidence 不等於 accuracy，門檻要用自己的標註樣本釐定。


五、足球案例：JEV 應該放在哪裏

以下四個例子由淺入深，全部屬設計示範，數值與門檻均為示意，並非實測結果。

案例一：文字直播批量標註

很多聯賽沒有商業事件數據，只有文字直播。「左路傳中，主隊中鋒頭槌攻門，稍稍高出」這一句，可以用一條 Choice 問題歸類為射門、傳中、解圍或犯規，再用一條 Noul 問是否屬於定位球。

這是 JEV 最典型的用途：量大、每次判斷簡單、答案類別固定。歷史直播動輒數十萬句，逐句交給 LLM 的時間與成本都難以接受。低 confidence 的句子另外交給 LLM 或人手複核，做法與上文的詐騙電郵分流相同。

案例二：賽前陣容新聞分級

第二節的 JSON 例子就屬這一類。重點在 state 的內容：要把來源、發佈時間與原文一併送入。JEV 只根據送入的 state 作答，「本地體育網站」與「球會官方帳戶」的分別，只有寫進 state，JEV 才看得到。

輸出的 Score 與 Choice 不應直接改動機率，而是觸發程式動作：陣容確定就重算模型，未確定就等待。

案例三：即場狀態判斷

即場賠率以秒計變動。LLM 動輒數秒的延遲放在這條迴路裏太慢，70 至 500 毫秒則在可用範圍之內。

圖 5：即場第 67 分鐘的一次調用，四條問題同時作答（示意）

圖中程式把最近十分鐘的統計與事件整理成 state，一次問四條問題：比賽形勢、客隊換人的防守意圖、數字與文字事件是否互相矛盾、是否值得讓 LLM 寫一段即場短評。四個答案同時回來，再由程式規則決定下一步。

賠率 feed 是否過時，則用時間戳在程式裏計算，不交給 JEV。

案例四：不應交給 JEV 的問題

TypeSafe 為 jev-1.13 維護一份「jaggedness」清單，列出模型表現參差的地方。換成足球場景，以下幾類問題都不應交給 JEV：

算術與點算： 「兩隊過去五場合共入了多少球」屬點算題，它傾向辨認答案的形態，而非真正加總。官方建議在程式裏計算，或每項各問一條 Noul。

日期比較： 「這條傷訊是否早於上一場比賽」。JEV 把日期當文字讀，而非有序數值，應先抽出日期再由程式比較。

多重轉折： 「上季對賽時入球的那名球員，今場是否上陣」需要多步推理，準確度會下降。應減少轉折，直接把相關欄位寫進 state。

雜訊過多的 state： 把整季數據一次全部送入，無關內容會干擾判斷。先過濾，只送問題需要的部分。

對抗內容： 爬取回來的新聞或留言可能夾帶指令，影響答案。判斷條件要寫得精確，並測試邊界情況。

此外，JEV 目前只接受文字與 JSON，不能直接讀影像或聲音；tracking 或轉播畫面要先轉成結構化數據。context 上限是 state 加問題共 64k token。至於入球期望值、Poisson 或 Dixon-Coles 一類計算，本來就屬統計模型的工作。


六、寫、判斷、計算：三分法

JEV 發佈三日後，社群出現一個新名詞「Jev Engineering」，核心是一條簡單的分工規則：

工作步驟

交給

足球例子

產生文字

LLM

賽前分析、推介說明、賽後檢討

選擇、評分、答是否

JEV

事件分類、陣容變動分級、數據是否可用

依照確定規則

程式

機率計算、去水、時間戳檢查、「未確認不出推介」

提出這套說法的指南也提醒，調用本身是最容易的部分，真正的工程在於送入甚麼 state，以及程式在甚麼 confidence 下才行動。它建議的遷移方法相當務實：先記錄一次完整運行中的所有模型調用，標出哪些是寫、哪些是判斷、哪些是規則；選取最常出現的一個判斷換成 JEV，新舊兩條路徑用同一批標註案例比較準確度、時間與每項任務的完成成本，然後再換下一個。

LangChain 在 9 月 17 日推出的整合，示範了兩個通用位置。其一是 model routing：讓 JEV 判斷一個請求要用便宜的小模型還是昂貴的大模型。其二是 Auto Mode：在 agent 執行 tool call 之前，先由 JEV 判斷動作是否危險，危險就攔截。


七、學術界的延伸：Jev-Mem

JEV 發佈後不久，德州大學達拉斯分校的 Dongming Jiang、Yi Li 與 Bingzhe Li 在 arXiv:2609.23986 提出 Jev-Mem: System-One-Controlled Agentic Memory for Efficient AI Agents，把同一套分工用在 agent 的長期記憶上。

長期記憶系統要不斷決定：這段對話屬哪類記憶、與哪些舊記憶有關、查詢時走哪條路徑、證據是否足夠。現有系統多數每一步都調用 LLM。Jev-Mem 把這些高頻判斷交給 System One 控制層，LLM 只負責最後綜合證據與生成答案。

在 LoCoMo 長對話基準上（生成部分用 gpt-4o-mini），Jev-Mem 的 LLM-as-a-Judge 總分為 0.777，最強基線為 0.700，相對提升 11.0%。記憶建構時間 158 秒，最快的對手要 1,044 秒；平均查詢延遲 0.93 秒，對手最快為 1.47 秒。

作者特別說明，論文的新意在於把輕量控制與深度推理分開的架構，JEV 只是 System One 控制器的其中一種實現。準確度與速度同時改善，說明判斷層的分拆並不一定要以犧牲質素換取效率。


八、限制與保留

廠方數字：延遲、價格與 193.6 倍這類數字，多來自 TypeSafe 自己的測試。它自己也承認，workflow eval 由內部團隊設計，可能有偏差；定價能否長期維持，仍有待時間證明。

準確度：Every 的測試中，JEV 找到七個錯誤中的六個，Fable 5.1 找到七個，準確度略遜頂級模型。低頻而每次出錯代價高的判斷，未必適合交給 JEV。

問題設計：社群反覆提到，要取得好的準確度，必須仔細劃分問題空間、寫清楚每個選項的邊界，這是真正的工程。用 LLM 寫一段 prompt 就能跳過的工作，換成 JEV 就要做足。

只讀文字：足球分析中大量資訊來自影像與 tracking，這部分要先由其他系統轉成結構化 state。


總結：把判斷從寫作中拆出來

JEV 沒有令 LLM 過時。它處理的是 LLM 一直做得不划算的那部分工作：大量、短答案、需要知道自己有多少把握的判斷。對足球數據流程而言，最直接的改變是即場與賽前這類時間緊迫的環節，判斷層終於可以在一秒內完成，而且附帶可以設門檻的機率。

技術概念

實務作用

章節位置

System One／System Two

區分即時判斷與語言推理兩類工作

第一節

state 與 questions

背景資料與型別化問題，一次請求平行作答

第二節

Choice／Score／Noul

選擇、有序評分、是非機率三種型別

第二節

平行 sampler

放棄字串生成，換取延遲與成本優勢

第三節

型別安全

不會出現格式錯誤，但答案仍可能錯

第三節

RLCD 與校準

機率誠實，令程式可以按門檻分流

第四節

信心分流

高信心自動執行，低信心升級或轉交人手

第四、五節

jaggedness

算術、日期、多重轉折、雜訊與對抗內容

第五節

寫、判斷、計算三分法

LLM、JEV、程式各司其職

第六節

Jev-Mem

同一分工用於 agent 長期記憶

第七節

AIP 系統將怎樣使用 JEV

第四節提到，RLCD 追求的是「說 70% 就中 70%」。AIP 系統 一直以同一標準評估自己的賽果模型：機率先以校準曲線與 Brier score 檢查，再與市場隱含機率對照，差距不足或關鍵數據缺失時不出推介。JEV 能改善的，是這條流程中目前最依賴人手或以規則寫死的判斷環節。

圖 6：AIP 系統加入 JEV 後的分工（規劃示意）

規劃中的做法分三個位置。第一是數據守門：賽前把陣容新聞、數據完整性一類文字判斷交給 JEV，以 Noul 與 Score 決定模型應否重算；賠率是否過時等可以用時間戳計算的檢查，仍留在程式。第二是推介前檢查：推介成形之後，用一次請求平行問幾條是非題，例如推介理由是否與最新新聞矛盾、是否依賴已過時的數據，任何一條信心不足就不出推介。第三是分流：判斷哪些比賽值得讓 LLM 撰寫較詳細的分析與賽後檢討。

各盤口的機率模型、ensemble、校準、去水與差距計算不會交給 JEV。按第五節的 jaggedness 清單，這些正是它不擅長、也不應承擔的算術工作。每個判斷點在換上 JEV 之前，都會用過往的標註案例把新舊兩條路徑並行比較，門檻按 AIP 自己的數據設定，而不是沿用廠方或社群的數字。


Reference

  1. D. Almeida. Introducing System One Models & Jev. TypeSafe AI Blog, 15 Sep 2026. https://typesafe.ai/blog/introducing-system-one-models-and-jev

  2. TypeSafe AI 官方網站（定價與 workflow eval 說明）. https://typesafe.ai

  3. S. Runkle, H. Lovell. Building a Harness with Jev. LangChain Blog, 17 Sep 2026. https://www.langchain.com/blog/building-a-harness-with-jev

  4. D. Jiang, Y. Li, B. Li. Jev-Mem: System-One-Controlled Agentic Memory for Efficient AI Agents. arXiv:2609.23986, 2026.

  5. Firecrawl. What Is Jev? Inside TypeSafe's Decision-Only AI Model and Its Developer Use Cases. 2026.（整理 Every 獨立測試與 jaggedness 清單） https://www.firecrawl.dev/blog/what-is-jev

  6. Made with Jev. What is Jev Engineering? 19 Sep 2026. https://madewithjev.com/what-is-jev-engineering

  7. OpenRouter. Jev 1.13 API Pricing & Providers. https://openrouter.ai/typesafe/jev-1.13

  8. D. Kahneman. Thinking, Fast and Slow. Farrar, Straus and Giroux, 2011.

  9. W. S. Jevons. The Coal Question. Macmillan, 1865.

  10. A. Maharana et al. Evaluating Very Long-Term Conversational Memory of LLM Agents.（LoCoMo）ACL, 2024.


原文 Paper



bottom of page