高玉璁 Samuel這篇文章會帶你認識最近受到關注的決策模型 Jev，以及它和大型語言模型最大的差異。相較於 ChatGPT、Claude 這類擅長生成文字與推理的模型，Jev 專注在「是不是、是哪一個、程度多少」這類快速判斷，並直接輸出結構化結果與機率。
當我們只需要一個「是／否」、一個分類，或一個分數時，真的每一次都需要叫一個大型語言模型，花時間「寫出」答案嗎？
最近 AI 圈出現了一個很有意思的新模型：Jev。
先不要焦慮，它不像 ChatGPT、Claude 或 Gemini。你不會用它寫文章、不會叫它幫你寫程式，甚至不會拿它來聊天。因為它被設計出來的目的，幾乎只有一件事：
做判斷
你給它一份資料，再告訴它你想判斷什麼，以及可能的答案有哪些，它會直接告訴你：
「我認為 A 的機率是 82%、B 是 13%、C 是 5%。」
這件事情乍看之下好像沒有大型語言模型那麼厲害，但如果我們回頭看看現在大量的 AI 自動化流程，可能會發現一件很有趣的事：
我們其實正在用非常會寫申論題的 AI，處理大量只需要回答選擇題的工作。
而 Jev 想要解決的其實就是這件事。
想像一個很常見的客服自動化流程。
今天有一封客戶訊息進來：
「我上週已經完成付款，但東西到現在都還沒收到，客服三天前說會幫我處理，結果也沒有人回覆。如果今天還沒有處理，我希望直接退款。」
系統可能需要知道：
現在很常見的做法，是把整段訊息交給 ChatGPT、Claude 或 Gemini，然後寫一串 Prompt：
「請分析以下客服訊息，判斷案件類型、嚴重程度、退款意圖與客戶情緒，並按照以下 JSON 格式回答……」，這裡用 JSON 的原因是方便後面程式往下運作！
模型可能最後會回答：
{
"category": "logistics",
"severity": 9,
"refund_requested": true,
"emotion": "highly frustrated"
}
這樣做當然沒有錯。但仔細想一下，我們真正需要的，其實不是讓 AI 寫這一串 JSON。
我們只是想知道：
換句話說，這些工作本質上都是判斷。
但我們現在卻習慣叫一個非常擅長生成文字的大型語言模型，先理解問題、再逐字把答案「寫出來」。
這就是 Jev 想重新設計的地方。
Jev 是 TypeSafe AI 在 2026 年 9 月 15 日公開的模型。
TypeSafe 把它稱為第一個 System One Model，定位是一種專門處理快速、結構化判斷的模型。這個命名來自 Daniel Kahneman 在《快思慢想》（Thinking, Fast and Slow）中普及的 System 1／System 2 概念：System 1 代表快速、直覺、自動的思考；System 2 則代表較慢、需要注意力與推理的思考。
不過，TypeSafe 的 System One Model 並不是在宣稱 Jev 等同於人類心理學中的 System 1，也不是 AI 學術界已經普遍採用的正式模型分類。它更像是一個產品定位：把需要快速反應、結構化輸出的判斷工作，從較慢、較昂貴的生成與深度推理流程中拆出來。
官方自己的描述非常直接：
Unstructured state in, typed probabilistic decisions out.
可以翻成：
把一段沒有固定格式的情境交給模型，得到一組有明確類型、帶有機率的判斷。
TypeSafe 創辦人 Diogo Almeida 過去曾參與 OpenAI 的 InstructGPT 研究；InstructGPT 是將人類回饋與強化學習帶進語言模型 instruction-following 的重要研究之一。
但 Jev 和我們現在熟悉的聊天模型，方向正好反過來。
ChatGPT、Claude、Gemini 的強項是：理解 → 推理 → 寫出內容。
Jev 的目標則是：理解 → 判斷。
例如你可以給它這段資料：
客戶已付款。 商品尚未出貨。 客戶已等待 7 天。 客服昨天曾承諾處理。 客戶要求退款。
再問：
這個案件應該交給哪個部門？ A. 帳務 B. 物流 C. 技術
它可能回傳：
物流 0.82 帳務 0.15 技術 0.03
這就是它的核心設計哲學。
它不是另一個比較小的 ChatGPT，它從一開始就沒有打算跟你聊天。
TypeSafe 甚至把 Jev 描述成：frontier-intelligence function call
也就是一個可以直接放進軟體流程裡的「智慧判斷函式」。
第一次看到 Jev 的人很容易產生一個疑問：如果它不是聊天模型，那它怎麼知道現在發生什麼事情？
答案其實和我們熟悉的大型語言模型很接近：
外部系統還是要先把 Context 準備給它，Jev 把這些資訊稱為 State。
假設今天你正在處理一張客服單。
State 可以包含：
客戶訊息 + 客戶 CRM 資料 + 訂單紀錄 + 過去客服紀錄 + 目前物流狀態 + 公司相關政策
例如：
客戶：VIP 最近 30 天客訴次數：2 訂單金額：NT$32,000 付款：成功 物流：尚未出貨 客戶留言：「如果今天還沒有處理，我希望直接退款。」
上面這整包資訊就是模型現在看到的 State。
換句話說，Jev 不是自己去讀 Email、查 CRM、搜尋 Database，或呼叫 API。這些工作通常由外部系統先完成，再把取得的結果整理成 Jev 可以使用的 State。因此，原本那段流程可以改寫成：
Email、CRM、Database、RAG、API、Tool Result 等等的各種資訊進行彙整
↓
整理成 State
↓
Jev
↓
Decision
↓
Workflow
也可以把它理解成：
外部系統負責提供資訊
↓
State 負責描述目前情況
↓
Jev 負責根據情況做判斷
↓
Workflow 負責執行後續動作
這意味著一件很重要的事：
Jev 並沒有取代 RAG、Database、API 或 Tool Calling 這些流程或者架構
假設使用者問：「按照我的合約，我現在可以提前解約嗎？」
你的系統仍然可能需要：
所以 Jev 解決的不是：「去哪裡找到資訊？」而是：「資訊都準備好了，現在到底應該怎麼判斷？」
要理解這件事情，可以先理解大型語言模型是怎麼回答問題的，我們平常看到 ChatGPT 一個字、一個字出現，並不是單純的畫面效果。
大型語言模型的基本生成方式，本來就是：
Token 1 ↓ Token 2 ↓ Token 3 ↓ Token 4 ↓ ……
這種一路往下猜測生成的概念，前面的內容產生之後，再預測下一個 token。
所以即使你最後只想知道：
refund（退款與否）= true
模型仍然需要把答案逐步生成出來。
如果你要求它回答：
{
"refund_requested": true,
"severity": 9,
"category": "logistics"
}
底層仍然在進行一段文字生成。Jev 的方向不同。
它放棄了自由文字生成，改成直接針對預先定義好的答案空間產生判斷。
TypeSafe 表示 Jev 採用了新的模型架構、parallel sampler，以及稱為 RLCD 的訓練方式；目前完整模型架構、訓練資料與 RLCD 細節並沒有全部公開。看到這裡，可以先簡單理解 RLCD 是一種用於訓練模型的方式；如果有興趣，再進一步研究其具體原理與實作細節即可。
所以你可以把兩者想像成底下這張圖：
這是最近討論 Jev 時最容易看到的（聳動）標題。
TypeSafe 官方公布的測試中，在部分 System One 類型的工作上，確實測得接近兩個數量級的速度與成本差異。Jev 官方公開的價格目前為每 100 萬 input tokens 約 US$0.042，而且 output 不另外按照生成 token 收費；官方宣稱典型延遲大約落在數十到數百毫秒。
但這裡有一個非常重要的判斷原則：
Benchmark 最大值，不等於所有情境下的實際效果。
「快 200 倍」不是說：
Jev 在任何工作都比 GPT 快 200 倍。
而是：TypeSafe 在特定的 decision workflow 與特定比較模型中，測得過最高接近這個幅度。
到底實際可以快多少，可能還會受到：
等以上各種因素的影響。
所以看到：「某個 AI 快 200 倍！」
更好的下一個問題永遠是：在哪個任務上？跟誰比？怎麼測？
這也是之後看到任何 AI benchmark 時，我們都值得保留的習慣！
Jev 現在的介面其實非常單純，基本上所有問題都可以拆成三種。
第一種：「是不是？」（Noul）
例如：
這封訊息是否要求退款？
模型可能回：
Yes = 0.94
也就是 Jev 認為「有要求退款」成立的機率是 94%。
TypeSafe 把這種題型稱為 Noul。
它特別適合：
第二種：「是哪一個？」（Choice）
例如：這封客服單是哪一種類型？
選項：
Billing Technical Logistics Sales
Jev 可能回：
Billing 0.07 Technical 0.08 Logistics 0.81 Sales 0.04
這叫做 Choice，目前公開的 Jev 規格允許 Choice 提供大量預先定義的選項，官方文件上限為 255 個。
第三種：「程度多少？」（Score）
例如：這個客服案件有多嚴重？
你先定義：
0 = 一般詢問 1 = 輕微問題 2 = 已影響使用 3 = 嚴重影響使用 4 = 可能造成重大損失
Jev 再根據 State 判斷它落在這個光譜的哪一個位置，這叫 Score。
它適合：
簡單來說，大部分工作上的判斷，其實都可以重新拆成三句話：
這句話聽起來很工程，但其實是我們最需要了解的（笑），先不要談 AI。
假設公司有一條規則：
訂單金額超過 NT$100,000，要送主管審核。
電腦非常會處理。
如果金額 > 100,000 → 主管審核
因為條件非常明確，但是如果公司的規則變成：
「如果客戶看起來已經非常不滿，就通知主管。」
問題來了！「非常不滿」是多少？
畢竟我們很難寫：
如果出現「生氣」兩個字 → 通知主管
因為「我沒有生氣，只是已經等了一個月而已🙂」 可能比「我有點生氣。」嚴重很多。傳統程式語言非常擅長處理「數字是不是大於 100？」，卻不擅長處理：這個人現在是不是已經非常不爽？
那以前我們是如何處理的呢？過去我們可能會建立大量規則，例如
出現「投訴」 → +1 分，出現「消保官」 → +2 分， 如果客戶是 VIP → +1 分，如果三天未處理 → +2 分這種千奇百怪的規則，同時規則很快就會變得又長又複雜，而 Jev 的 Decision Model 想做的是：
State ↓ Jev ↓ 「高風險客訴」成立機率：91%
接下來，真正的程式再依照算出來的結果進行決定，例如
接下來，真正的程式再決定：
這就是所謂的：probabilistic condition。
如果把它翻成完全不需要程式背景的版本：
以前電腦只能很可靠地判斷「明確規則」；現在 AI 開始可以幫軟體判斷「模糊的語意條件」。
這才是 Jev 真正有意思的地方 😎
假設我們現在有兩個模型，兩個模型都做 100 題客服分類，而且都答對 90 題。
也就是：Accuracy = 90%
單看準確率，兩個模型看起來一樣厲害。
但模型 A 有一個問題，它幾乎每一題都告訴你：「我有 99% 的把握。」
結果 100 題裡，還是錯了 10 題，那問題就來了：
如果它明明每十題會錯一題，為什麼每次都說自己有 99% 的把握？
更麻煩的是，當你把這個模型接進自動化流程時，你根本分不出來哪一次的 99% 是真的可靠，哪一次只是模型過度自信。
模型 B 則不太一樣：
最後它一樣可能答對 90 題，但如果今天要把 AI 放進真正的自動化流程裡，我反而會更希望使用模型 B，原因不是它比較準，而是：
我知道什麼時候可以相信它，也知道什麼時候不應該讓它自己做決定。
這就是 Jev 非常強調的概念：Calibration。
Calibration 可以用氣象預報來理解，假設氣象預報告訴你：
如果我們把過去所有「預報 70% 下雨」的日子全部找出來，總共有 100 天，而其中大約：
那這個「70%」就是一個很有意義的數字，因為當氣象預報說 70% 時，長期來看真的差不多七成會發生，但如果同樣把所有「70% 下雨」的預報拿出來，最後其實只有 30% 的日子下雨，那這個 70% 就很難拿來做任何決策。
同樣的事情也適用在 AI，假設 AI 告訴你：「這個案件有 90% 的機率是詐騙。」
我們真正希望的不是它看起來很有自信，而是：長期來看，所有被它判斷為大約 90% 詐騙機率的案件，真的有接近 90% 最後被確認為詐騙。這才叫做比較好的 calibrated probability。
所以 Calibration 關心的其實不是「AI 有沒有信心？」，而是「AI 表達出來的信心，到底值不值得相信？」
這對一般聊天可能沒有那麼重要，但對自動化流程非常重要，因為只要這個機率足夠可信，我們就可以開始建立規則：
也就是說，AI 不一定非得每一次都替我們下最後決定，它也可以很有價值地告訴系統：「這題我其實沒有那麼確定。」
這個段落我們先收在這裡，到目前為止，你可以先記住一件事：
Jev 真正值得注意的地方，不只是「更快、更便宜」，而是它把 AI 裡的「判斷」這件事，從「生成內容」裡獨立拆了出來。
過去我們很習慣把所有工作都交給大型語言模型：分類、判斷、打分數、決定下一步，甚至只是回答一個 Yes / No，也會讓模型完整跑一次生成流程。
但 Jev 提出的是另一種思考方式：
這也讓 AI 從原本比較像「會回答問題的人」，開始變成一個可以直接放進系統裡的「判斷零件」。
更重要的是，這些判斷不只是單純給答案，而是開始附帶 Probability，讓後續流程可以根據「有多確定」來決定是否自動執行、繼續確認，或交回真人。所以看完這一篇，你可以先留下三個關鍵問題：
Hahow for Business 提供客製化的線上與實體混成培訓方案，透過數據驅動，打造最佳人才培訓策略。
