TypeSafe AI 的 System One Models 與 Jev：把 AI 從聊天介面推進 typed decision engine

0. 這不是另一個聊天模型｜TypeSafe AI 想把 AI 變成軟體可以直接呼叫的決策函式

TypeSafe AI 在 2026 年 9 月 15 日發布〈Introducing System One Models & Jev〉，由創辦人 Diogo Almeida 撰文。文章的核心問題很直接：如果模型在聊天上已經很強，為什麼真正的自動化還沒有大規模發生？

Diogo 的答案是：因為 chat model 不是軟體最需要的形狀。現有 LLM 最擅長生成字串，這對人類互動很好，對軟體自動化卻很麻煩。字串要 parse、validate、重試，還要防止模型偏離格式、幻覺工具、或把不該輸出的內容包進一段看似合理的文字。對真正嵌在 production workflow 裡的系統來說，這些自由度不是優點，而是風險。

Jev 的定位剛好反過來。它不是一個可以長篇聊天的模型，而是 TypeSafe AI 稱為 System One Model 的第一個公開模型：輸入可以是非結構化狀態，但輸出必須是預先定義好的 typed probabilistic decisions。你不是請它「寫一段答案」，而是請它在一組可能選項、分數、分類或欄位上做快速、校準過的判斷。

原文最短的比喻是：Jev 像一個具 frontier intelligence 的 function call。這句話很關鍵。TypeSafe AI 不是要把 LLM 包成 JSON mode，而是主張「模型本身」就應該針對結構化決策最佳化：輸入 state，輸出型別安全的機率分布、confidence、classification、ranking 或 branch signal。

這篇魚塘導讀不重刊原文全文。原文仍受版權保護，因此本文提供完整繁中導讀、逐段重述式翻譯摘要、重要表格整理與評析。若要閱讀 TypeSafe AI 的完整原文，請直接看來源連結：https://typesafe.ai/blog/introducing-system-one-models-and-jev

1. System One Model 是什麼｜放棄自由字串，換取低延遲、型別安全與可校準決策

TypeSafe AI 借用 Daniel Kahneman《快思慢想》裡 System 1 / System 2 的概念。System 1 代表快速、直覺、低延遲的判斷；System 2 代表慢速、深思、步驟化推理。公司把自己的模型類別命名為 System One Models，是在主張另一種 AI product surface：不是讓模型慢慢生成推理與文字，而是讓它像軟體內的模糊決策器一樣，在很短時間內回傳可用的 structured answer。

這和傳統 LLM 的差異可以拆成六個層面。

第一，最佳化目標不同。LLM 常見訓練方向是 RLHF 或 RLVR：前者讓人類偏好模型回答，後者讓模型追求可驗證答案。TypeSafe AI 提出的 RLCD，也就是 Reinforcement Learning for Calibrated Decisions，目標是讓模型在 System One tasks 上給出 epistemically honest probabilities。換句話說，不只是答對，而是知道自己有多可能答對。

第二，輸出形狀不同。LLM 輸出字串，字串很有彈性，但也代表一切都可能發生：正確答案、幻覺、拒答、格式錯誤、或看起來像 JSON 但 schema 不符。Jev 輸出預先定義好的 typed values，所有可能答案都由 schema 限定，模型不能臨時發明不存在的欄位或型別。

第三，sampling 方式不同。LLM 逐 token 生成，後一個 token 依賴前一個 token。Jev 則宣稱以 parallel sampling 一次產生所有輸出，這也是它能做到低延遲與低成本的基礎。對 workflow 裡大量獨立決策來說，這種形狀比讓 LLM 一字一字吐出一大段更貼近需求。

第四，confidence 是一等公民。現有 LLM 即使被要求給 confidence，也常常過度自信或不一致。TypeSafe AI 認為 automation 的重點不是模型能不能在 95% 情況答對，而是它能不能在剩下 5% 的時候清楚告訴你「我不確定」。如果 confidence 不能和 accuracy 對齊，軟體就很難可靠地用它做分支。

第五，成本模型不同。原文列出 Jev 早期定價：input tokens 每百萬美元 0.042，output tokens 免費。TypeSafe AI 的理由是 structured output 太便宜，不值得單獨計費。這也是他們對「大量決策、map-reduce over big data、real-time UX」有野心的原因。

第六，適用場景不同。LLM 適合 chatbots、copilots、coding agents、可驗證問題與 demo。System One Models 則瞄準 AI-powered workflows、smart if-statements、分類、路由、抽取、排序、打分、guardrail、jailbreak detection，以及任何「需要一點語意判斷，但結果必須進入程式邏輯」的地方。

2. 技術棧與 RLCD｜真正的賣點不是 JSON，而是「校準過的結構化決策」

很多產品都說自己支援 structured output。OpenAI、Anthropic、Google 和開源模型生態都有 JSON schema、tool calling、function calling 或 constrained decoding。那 TypeSafe AI 到底想說自己不一樣在哪裡？

原文的答案有三層。

第一層是模型架構。TypeSafe AI 說他們做了新的 model architecture，從一開始就針對 structured decisions 而設計，而不是把文字模型包一層 parser。這代表輸出空間、訓練方法、inference path 都可以假設「答案是一組 typed alternatives」，而不是假設「答案是一段字」。

第二層是 parallel sampler。Jev 不必像 LLM 一樣序列化生成每個 token，因此在多個 decision slots 上可以並行產生答案。這非常適合 workflow：例如同時判斷一個客戶的 churn risk、upsell fit、support urgency、fraud probability、routing destination。傳統 LLM 即使用 JSON 回答，也還是在逐 token 寫出 JSON；Jev 則把它視為多個結構化決策。

第三層是 RLCD。這是 TypeSafe AI 最想建立的新名詞。RLCD 的重點不只是正確答案，而是 calibrated decisions。以工程語言翻譯，就是模型回傳的 probability 要可被下游邏輯信任。當模型說 0.82，系統可以用 0.8 threshold 做分支；當模型說 0.51，系統知道這不該被當成確定判斷。

這個主張若成立，價值會很大。很多 AI automation 失敗不是因為模型從來不答對，而是因為模型沒有穩定的 uncertainty interface。它 90% 時候看似神準，10% 時候自信地胡說，工程師就只能把人類放回 loop 裡。TypeSafe AI 要賣的正是這個缺口：讓 AI 的不確定性也變成 typed output 的一部分。

不過這也意味著 Jev 的能力邊界很清楚。它不是拿來寫文章、寫程式、做開放式 reasoning transcript 的工具。它刻意放棄 string generation，換來 type-safety、latency、cost 和 confidence calibration。如果你的產品需要的是「創造一段新文字」，Jev 不是主要工具；如果你需要的是「把 messy state 轉成可靠的 software decision」，它才進入討論範圍。

3. 原文拿出的證據｜速度、成本、型別安全比較容易驗；智能與泛化仍要看 eval 設計

Diogo 在原文裡特別說，他們自己也喜歡懷疑者。這是對的，因為這篇文章有不少很大膽的宣稱：兩個數量級更快、更便宜、同等 frontier intelligence、不能 hallucinate、不能 type error。這些說法需要拆開看。

速度最容易驗。TypeSafe AI 宣稱 Jev 端到端延遲約 70ms 到 500ms，並說在 System One shaped queries 上，相對 frontier LLM 可能快 40 到 200 倍。這個數字的可信度取決於測試地點、服務區域、query shape、比較模型和 reasoning setting。原文也承認，他們的公開 eval 大多從美國西岸筆電跑，這會影響延遲。

成本也相對可驗。定價公開，所以每次 call 的帳單可以算。不過原文也承認，短期價格是否被補貼、長期是否可持續，仍要時間證明。這裡的重點不是今天的美元數字，而是架構形狀：如果 output 不是 token-by-token 文字生成，成本模型確實可能不同。

型別安全最可驗，也最不等於「事實正確」。Jev 若真的只能輸出 schema 內的值，那它就不會出現 type error。這和幻覺有關，但不是同一件事。模型不能發明不存在欄位，不代表它選的分類一定正確；它不會輸出 malformed JSON，不代表它對世界的判斷一定準。TypeSafe AI 把 hallucination 和 type-safety 綁在一起討論時，開發者應該讀成「不會 hallucinate 出 schema 外的結構」，而不是「永遠不會做錯判斷」。

最需要仔細看的，是 workflow evals。TypeSafe AI 建了一種評估：假設有一個正確 compute graph，也就是一段 workflow code；每個模型都跑同一個 workflow；再把最大、最聰明、最貴的外部模型平均答案當成 reference probabilities。原文說這次 reference 是 GPT-6 Astra 和 Fable 5.1 的平均。

這個 eval 設計很有意思，因為它不是測「單題 classification ground truth」，而是測模型能否在真實 workflow 形狀裡產生接近強模型的機率判斷。它也避免讓每個模型改 prompt、改 harness、改 compute graph 去過度適配 benchmark。對「AI in code」這個問題來說，這比一般問答 benchmark 更貼近 production。

但限制也很明顯。第一，reference 不是 ground truth，而是兩個 frontier model 的平均。這代表 eval 測的是「接近這兩個模型」，不一定是「接近真相」。第二，workflow 由 TypeSafe AI 的 model capabilities team 製作，即使不是刻意挑有利題，也仍可能有內部偏差。第三，LLM 對照組使用 TypeSafe AI 的 System One LLM wrapper，這可能是合理的 structured decision wrapper，但也會影響速度與成本比較。

所以這裡最公平的讀法是：Jev 在 TypeSafe AI 設計的 System One workflow 形狀上，看起來拿到非常漂亮的 Pareto frontier；但外部開發者仍應該用自己的 workflow、自己的標準答案、自己的 latency/cost constraints 重新驗證。

4. Demo 真正想展示什麼｜Doom 和 Wikiracing 都在說「選項很多、時間很短、不能亂編」

原文的 demo 有兩個：Doom 和 Wikiracing。

Doom demo 的重點不是讓 AI 看畫面打遊戲。TypeSafe AI 特別說，目前 demo 是把遊戲狀態以資料結構與文字表示，不是 image input。真正展示的是：如果一個模型可以每秒多次讀取 structured state，並快速回傳 typed action decision，那它就可以進入 real-time loop。工程師擔心每秒 10 次 query 的成本，但團隊反而覺得每小時約 7 美元比想像低。

這個 demo 的意義不在於 Jev 是最強 Doom bot。非 AI bot 當然可以更會玩。重點是它能不能在不同 state representation 下跟著指令反應，而且延遲與成本低到可以被放進互動系統。

Wikiracing demo 則展示高基數選擇。遊戲目標是從一個 Wikipedia 頁面出發，只透過頁面上的連結走到目標頁。每一步可能有數百到上千個 link。這種任務很適合說明「不能亂編選項」的重要性：LLM 可能產生不存在的 link，或在大量選項中慢慢生成推理；Jev 的優勢則是對既有選項做快速 scoring / choice。

原文提到 Jev 支援的 cardinality 上限是 255。超過時，他們會用兩階段系統：先獨立 scoring，再做 explicit choice。這代表 Jev 不是無限高基數 oracle；當選項太多，系統仍要設計分層流程。這一點很實在，也提醒開發者：System One Model 仍然需要 surrounding code。它不是替代 workflow engineering，而是讓 workflow 裡的 fuzzy decisions 更便宜、更快、更可控。

5. 逐段重述式翻譯摘要｜不重刊原文，但完整保留論述脈絡

以下是原文的繁中重述摘要。它不是逐字翻譯，也不替代原文閱讀；目的是讓讀者掌握每一段主張、轉折與證據。

開場段落：作者先問，模型在聊天上早已超越多數人類，為什麼自動化仍未真正爆發？他回顧自己在 OpenAI 參與 instruction following 與 ChatGPT 相關研究時，曾以為聊天模型可能一路通往 AGI，但幾年後他認為缺了一塊非常大的拼圖：軟體需要的不是更多文字，而是可靠決策。

產品發布段落：TypeSafe AI 經過兩年 stealth、許多技術挑戰與研究突破後，發布第一個 System One Model。這是一類 frontier model，目標是做快速、結構化、可被軟體直接使用的決策。Jev 是第一個公開模型，目前 early access。

核心能力段落：Jev 在 System One tasks 上達到接近現有 LLM 的智能水準，同時速度與效率高兩個數量級。它放棄字串生成，專注 structured outputs，因此不會輸出 schema 外的結構。作者把它比成一個 frontier-intelligence function call：輸入未結構化狀態，輸出 typed probabilistic decisions。

新舊 frontier 對照段落：文章用表格比較既有 LLM 與 System One + Jev。既有 LLM 透過 RLHF / RLVR 最佳化人類偏好或可驗證 reward；Jev 透過 RLCD 最佳化校準過的決策。LLM 輸入以對話與文字序列為主，輸出字串；Jev 輸入也可包含非結構化資料，但重點是 program state，輸出則是預先定義的 typed values、probabilities 和 confidence。

成本速度段落：文章列出 LLM token 成本、output token 通常更貴，以及 frontier model 端到端回應可能需要數秒到數分鐘。TypeSafe AI 則宣稱 Jev input token 每百萬美元 0.042，output 免費，端到端延遲 70ms 到 500ms。作者認為這個速度使 AI 能進入過去不適合 LLM 的 real-time UX 與大量 workflow。

confidence 段落：作者批評現有 LLM 即使被問 confidence，也容易過度自信或不一致。若模型在 95% 情況能做對，但無法標示剩下 5% 的不確定，系統就不能真正自動化。Jev 的賣點是每次輸出都帶 uncertainty，且高 confidence 應對應高 accuracy。

use cases 段落：LLM 適合 human-in-the-loop，例如聊天機器人、copilot、coding agent，也適合可驗證問題與 demo。Jev 則適合 AI-powered workflows、smart if-statements、分類、路由、打分、抽取、map-reduce over big data、real-time application，以及用來 judge、verify、guardrail 或偵測 prompt jailbreak。

證據開場段落：作者說他們歡迎懷疑。速度、成本、型別安全是比較容易驗的 claim。速度可以自己 call API 測；成本可以看定價，但長期是否可持續還需要時間；型別錯誤只要一個反例就能推翻，但 TypeSafe AI 認為它在數學上不可能發生，因為 schema 已限制輸出。

side-by-side demo 段落：示範重點是 Jev 同時輸出所有 probability，而不是像 LLM 一樣 autoregressively 生成 token。作者承認 demo query 很簡化，問題 key 設計得比較人類可讀，state 也短而密集，這讓 Jev 的 sampling 方法較容易被看見。他們用 GPT-5.6 Terra 作為對照，因為平均而言智能接近 Jev。

workflow evals 段落：TypeSafe AI 建了一種新 eval：假設 workflow code 是正確 compute graph，所有模型跑同一個 workflow，再比較它們和最強外部模型平均答案的差距。這不是讓模型自由寫 prompt 或改 harness，而是測它們在固定 workflow 中做 structured decisions 的能力。

eval 結果段落：文章宣稱 Jev 在 Pareto frontier 上大幅領先，接近兩個數量級。對照組包括用 prompt 讓 LLM 在 chain-of-thought 裡做完整邏輯的版本，但這通常比把 workflow 寫在 code 裡更差。作者說公開的四個 workflow 比 side-by-side demo 更接近 production workload。

eval 限制段落：作者說 193.6x faster、444.6x cheaper 來自主頁 claim，可能代表真實世界增益的高端。workflow 不是刻意挑來讓模型好看，也不在訓練分布中，但由內部能力團隊製作，可能仍有偏差。reference answer 是 GPT-6 Astra 和 Fable 5.1 平均，這可能偏向 OpenAI 與 Anthropic 的模型。

hallucination/type-safety 段落：作者認為幻覺與型別安全高度相關，後者是自動化的基本門檻。agent 叫錯 tool 很麻煩；如果這種錯誤藏在有 latency guarantee 或深層 dependency chain 的系統裡，就是不可接受的。文章中的 LLM 錯誤率數字來自 OpenRouter，作者也承認可能有偏差；Jev 的 0% 不是 empirical measurement，而是 schema guarantee。

Doom demo 段落：團隊展示 Jev 在 Doom-like loop 裡做即時決策。作者強調它不是看 image，而是讀結構化 game state。這個 demo 的價值不是打得比傳統 bot 好，而是說明 code + AI 可以在低延遲 loop 裡做反應式智能。

Wikiracing demo 段落：遊戲要求從一個 Wikipedia 頁面點連結走到另一個頁面。每一步都有大量候選 link，因此很適合展示「每秒智能」與「不幻覺高基數選項」的重要性。作者承認這些 speedup 通常比前面的 demo 小，因為對照組使用非 reasoning mode；Jev 有時步數更少，代表可能做出更聰明的路徑選擇。

未來段落：TypeSafe AI 說 Jev 還在早期，接下來會繼續 shipping。他們開放 early access，會逐步讓 waitlist 上的開發者進來，希望大家回報哪些決策需要自動化、Jev 哪裡有效、哪裡不足。

FAQ 段落：System One Models 的名字來自 Kahneman 的快思慢想。作者承認 System 1 常被聯想到容易犯錯，但他們相信 System One Models 可以做得比替代方案更可靠。Jev 則命名自 William Stanley Jevons，呼應 Jevons paradox：當蒸汽機效率提升，煤炭需求反而上升；TypeSafe AI 預期機器智能成本每下降一個數量級，也會解鎖更多需求。

6. 開發者該怎麼看｜Jev 最值得關注的是介面形狀，不是 benchmark 數字本身

這篇發布文最有價值的地方，不是某一張圖上的倍率，而是它把「AI 接進軟體」的介面問題講得很清楚。

過去兩年，很多團隊把 LLM 接進產品的方式是：prompt、JSON schema、retry、validator、fallback、人類審核。這條路可以做出很多東西，但本質上仍是把一個文字生成器馴化成軟體元件。TypeSafe AI 的主張是：如果需求本來就是分類、路由、抽取、排序、打分、branch，那模型就不該以文字生成器的形狀存在。

這個方向很合理。真正的 AI automation 需要三件事：穩定的輸出介面、可信的不確定性、足夠低的單次決策成本。Jev 正好把這三件事擺到產品中心。

但開發者也不要把它讀成「LLM 不重要了」。Jev 放棄 string generation，所以它不會取代寫 code、寫報告、長文 reasoning、open-ended agent planning。比較可能的未來是分工：LLM 負責長上下文推理、規劃、生成與人機協作；System One Models 負責工作流裡高頻、低延遲、結構化、可校準的判斷。

最值得實驗的地方，是把現有 prompt-based classifiers、routing prompts、support triage、lead scoring、fraud flags、moderation guards、agent output verifiers 拿來對照。不要只問「Jev 比 GPT 快幾倍」，而要問：

• 它在你的 schema 上能不能保持 calibration？
• confidence threshold 能不能穩定對應實際錯誤率？
• 它失敗時是低 confidence，還是高 confidence 錯誤？
• 它對邊界案例是否比 LLM wrapper 更可預測？
• 它的成本是否低到讓你改變產品設計？
• 它能不能讓原本需要人類審核的分支，變成只在低信心時升級？

TypeSafe AI 這篇文章其實是在提出一個新的 AI software primitive：不是 chatbot，不是 agent，不是 embedding，也不是 traditional classifier，而是 typed probabilistic decision function。Jev 能否成為這個 primitive 的代表，還要看外部使用者的實測。但方向本身很值得放進工具箱。