本文為 TypeSafe AI 官方部落格文章 Introducing System One Models and Jev 之繁體中文翻譯整理，原文版權歸原作者所有。
TypeSafe 創辦人 Diogo Almeida
模型在聊天方面早已超越人類多年，那麼，所有自動化應用究竟在哪裡？
過去四年，這一直是驅使我前進的核心問題。在 OpenAI，我曾協助開發讓語言模型能遵循指令、與人對話的方法；這項工作後來成為 ChatGPT 背後的研究基礎。當時我以為聊天模型或許會通往 AGI，但儘管市場熱度高漲，我逐漸明白：其中仍缺少一個極其關鍵的部分。
在兩年的秘密研發、無數技術挑戰與研究突破之後，我非常興奮地宣布：TypeSafe AI 今天正式推出第一款 System One 模型。這是一種全新的前沿模型類別，專為做出快速、結構化且能直接供軟體使用的決策而設計。
我們建立了一套完全以自動化為核心的新技術堆疊，包括全新的模型架構、追求最高效率的平行採樣器，以及我們稱為「校準決策強化學習」（Reinforcement Learning for Calibrated Decisions，RLCD）的訓練方法。
我們第一款公開模型是 Jev，今天起開放搶先體驗。在 System One 任務上，Jev 的智慧水準與現有 LLM 相近，但速度與效率高出兩個數量級。Jev 放棄字串生成，改為針對結構化輸出最佳化，因此不會產生幻覺。
你可以把 Jev 想成具備前沿智慧的函式呼叫：輸入非結構化狀態，輸出帶有型別的機率決策。
非凡的主張需要非凡的證據，以下就是我們的佐證。💅
新舊前沿模型比較
| 項目 | 現有 LLM | System One + Jev |
|---|---|---|
| 最佳化方式 | 人類回饋強化學習（RLHF）／可驗證獎勵強化學習（RLVR） | 校準決策強化學習（RLCD） |
| 最佳化目標 | 人類偏好：產生評審較喜歡的文章與聊天回覆。 可驗證獎勵：產生可由程式驗證的輸出。 |
校準決策：在 System One 任務上，以符合知識誠實原則的機率提供答案。 |
| 輸入 | 非結構化資料（例如文字），著重連續訊息。 | 非結構化資料（例如文字），著重結構化程式狀態。 |
| 輸出 | 字串／生成文字。字串彈性極高，可以是聊天回覆、程式碼、幻覺、拒答，甚至型別安全的結構化值。軟體使用前必須解析並驗證，而且 AI 永遠存在失控風險。 | 型別安全的結構化值。可用輸出及結構會預先定義。模型不會出現型別錯誤；所有答案都附有經校準的機率與信心分數。 |
| 採樣 | 循序。一次生成一個 token，每個 token 都取決於前一個。 | 平行。單次查詢就生成所有輸出，效率極高並針對硬體最佳化。 |
| 成本 | 輸入 token：每百萬個 $0.20～$10。 輸出 token：約比輸入貴 5 倍。 |
輸入 token：每百萬個 $0.042（每十億個 $42）。 輸出 token：免費（成本低到不值得計量）。 |
| 速度 | 前沿模型的端到端回應時間為 3～329 秒。與人互動已足夠快，但整合至程式碼時會成為嚴重瓶頸。 | TypeSafe 的端到端回應時間為 70～500 毫秒。在 System One 型態的查詢中，以相同前沿智慧水準計算，可快 40～200 倍。 |
| 信心 | 即使要求模型估計信心，它仍往往過度自信且前後不一致。如果模型有 95% 的成功率，卻無法指出何時落入失敗的 5%，就不能自動化該任務。 | 每次輸出都會表達信心與不確定性。經過校準：信心越高，準確率越高；一致性也更佳：相似輸入會得到相似答案。 |
| 使用情境 | 有人類介入的任務（聊天機器人、副駕駛、程式代理）。通用且強大，但因自由度也可能導致失控，仍需人類監督。
可驗證問題（數學證明、核心最佳化）。若能低成本自動檢查正確性，LLM 可反覆生成、測試與修正，直到找到可行答案。 展示原型。字串的彈性很適合快速製作偶爾能運作的原型。 |
AI 工作流程／智慧型 if 判斷。結構化輸出可直接嵌入一般軟體，作為模糊決策規則：分類、路由、評分、擷取，或在手寫邏輯過於僵化時進行分支。周邊程式碼會限制模型自由度，使其更容易組合為可靠系統。
對大數據執行 MapReduce。將 PB 級資料轉換為特徵與洞察。 即時應用。約 100 毫秒的速度，讓 AI 可用於使用者體驗極為關鍵的應用。 驗證一切。對 LLM 提示詞、推理軌跡與輸出進行評分、判定、驗證、防護及越獄偵測。 |
證據與技術成果
我們喜歡懷疑論者，因為我們自己也是。
有些主張很容易驗證：
- 每次呼叫的速度：我們真的有那麼快。不過，已發布的評測通常是在美國西岸、透過我們自己的筆電執行，因為服務目前架設於該地區。
- 每次呼叫的成本：我們公開透明地揭露定價。我們無法證明價格未受補貼；只有長期營運才能證明其可持續性——而且我們預期價格會下降，不會上升。
- 零型別錯誤：只需一個反例就能推翻這項說法，但從數學上來說，發生型別錯誤是不可能的。
至於更大膽的主張，我們希望盡可能完整地說明其中細節。
並排展示
我們的並排展示突顯模型與 LLM 的關鍵差異：Jev 會平行輸出所有機率，而不是按 token 自回歸生成。字串非常強大、通用，但代價高昂；「放棄」字串，反而賦予我們許多超能力！
注意事項
- 已取得 TypeSafe 搶先體驗資格的使用者，可以查看實際查詢。
- 眼尖的人可能注意到，錄製的那次執行中，Jev 與 GPT-5.6 Terra 唯一的分歧在「客戶流失可能性等級」。我們認為這題的實際答案確實有歧義。
- 此範例使用預設推理模式的 GPT-5.6 Terra，因為平均而言，我們發現它的智慧水準最接近 Jev。
- 有趣的是，當初正是類似的展示說服我們全力投入 System One 模型！
工作流程評測
我們設計了一種新的評測方法，用來衡量 AI 在程式碼中的運作成效。我們不針對單一標準答案分類進行最佳化，也不允許評測框架與模型同時改動——後者可能透過「評測框架工程」造成過度擬合。相反地，我們假設存在一張正確的計算圖（以程式碼表示的「工作流程」），並以最大、最聰明、最昂貴的外部模型預測結果作為參考機率。
換句話說：每個模型都使用同一套工作流程；我們測試它們與最聰明模型平均結果（此處為 Astra 與 Fable）的差距。
Jev 的表現突破圖表範圍，在接近兩個數量級的尺度上主宰帕累托前沿。我們也拿它與另一種方案比較：讓模型使用生成的提示詞，將所有邏輯放進思維鏈；但這種做法通常遠不如直接使用工作流程。
請注意，這裡的呼叫複雜許多，因為它們更能代表真正業務自動化所需的正式環境負載。以下是我們公布的四套工作流程中最簡單的一套：
最可靠的真實世界工作流程，通常包含許多彼此獨立、經拆解的問題，並依據機率而非離散決策做出細緻行為。最終結果仍是離散分支，但抵達答案的過程需要大量領域工程，而且必須維持高度一致。
完整的範例、分歧、查詢及各項工作流程，請參閱工作流程評測網站。
注意事項
- 官網宣稱快 193.6 倍、便宜 444.6 倍的數據源自此處；我們預期這些數字接近真實世界效益的高端。
- 這些工作流程並非刻意挑選或設計來凸顯模型優勢，也不在訓練資料分布中。不過，它們是由模型能力團隊成員製作，因此仍可能存在偏差。
- 我們以 GPT-6 Astra 與 Fable 5.1 的平均結果作為參考答案，這會使結果偏向 OpenAI 與 Anthropic 的模型；因此，我們可能低估了自家模型及 DeepSeek 模型的相對表現。
- LLM 使用我們的 System One LLM 包裝器，將輸出限制為與 API 相容的結構化決策。我們發現，這是讓 LLM 產生決策最準確的方法，但通常比直接輸出不含機率的決策更慢、更昂貴。
幻覺與型別安全
幻覺與型別安全有本質上的關聯；我們認為，後者是自動化最基本的門檻。代理中的幻覺工具呼叫只是令人困擾，但若它存在於具延遲保證的系統，或深埋於多層相依鏈中，就完全不可接受。無論現有模型多麼聰明，仍會產生幻覺與型別錯誤。
注意事項
- LLM 的數字來自 OpenRouter，因此幾乎肯定存在偏差：較複雜的查詢可能被路由至更好的模型。
- 我們的數字並非實證所得。結構描述符合度有保證，所以可以有把握地在圖上標示 0%。
趣味展示
這項工作最令人興奮的地方，或許是它能開啟全新使用情境。我們還有很多內容準備展示，以下先介紹團隊最喜歡的兩個範例。
Doom
我們很喜歡這個 Doom 展示，因為它呈現了即時智慧，以及程式碼加 AI 能做到什麼。負責開發的工程師原本擔心每秒進行 10 次查詢（最後成本約每小時 $7），但團隊其他人都覺得這比預期便宜！這實在太有趣了；我們不只打算推出深入教學，也會舉辦活動，讓大家一起開發。
注意事項
- 此展示的輸入是包含文字的結構化資料，而不是影像——至少目前還不是……
- 不使用 AI 的 Doom 機器人或許玩得更好，但我們想打造的是能對不同遊戲狀態表示方式做出反應的機器人；而且最重要的是，能遵循指令真的酷斃了！
維基競速（Wikiracing）
遊戲目標是從某個 Wikipedia 頁面出發，只能點擊沿途看到的連結，最後抵達另一個指定頁面。每一步都可能要在數百至數千個連結中做選擇！這不僅很適合展示每秒智慧量，也能展現面對高基數選項時，不產生幻覺所帶來的複利效益。
注意事項
- 據我們所知，第二與第三項挑戰都從「Rubber Duck」開始純屬巧合；作者直到團隊指出後才發現。
- 這裡的速度提升通常不如前面展示明顯，因為比較對象採用模型的非推理模式（Astra 除外，它設為最低推理強度）。這也解釋了為何 Jev 往往能以較少步驟完成——這是智慧更高的跡象。我們之所以這樣設定，是為了讓展示不至於太難看完；如果啟用推理，LLM 在這項任務的表現會好得多。
- Jev 最多支援 255 個候選項目。面對更多選項時，我們採用兩階段系統：先獨立評分，再做出明確選擇，因此偶爾會變慢。
接下來呢？
Jev 仍處於早期階段。我們還有許多內容正在開發，也非常期待持續推出新成果 🔥。
今天起，我們開放搶先體驗，並會盡快邀請候補名單上的開發者加入。我們想知道你需要自動化哪些決策、Jev 在哪些地方有效，又在哪些地方不足。告訴我們，你想打造什麼科幻般的未來！
我們創立 TypeSafe，是因為相信 AI 需要一個軟體可以信賴的介面。我們迫不及待想看見新的使用情境持續擴散至社群與整體經濟。
常見問題
「System One Models」與「Jev」這兩個名稱從何而來？
靈感來自 Daniel Kahneman 的《快思慢想》。模型類別名稱取自快速、直覺的「系統一」思考，與緩慢、審慎的「系統二」推理之間的區別。
「系統一思考」也常被認為容易出錯。基於一些未來會進一步說明的理由，我們相信 System One 模型可以比其他方案更可靠。
Jev 的名稱來自 William Stanley Jevons。我們預期，機器智慧會走上與煤炭類似的道路：蒸汽機效率提升後，煤炭需求反而增加。智慧成本每下降一個數量級，都會解鎖多個數量級的新使用情境。
為什麼需要新的訓練演算法？
Jev 適合哪些使用情境？
Jev 只是比較小的 LLM 嗎？
Jev 在公開基準測試中的表現如何？
我們的訓練資料從何而來？
這些結果實在太驚人了——究竟怎麼可能？
Hacker News 網友反應整理
整體風向：高度關注、概念獲得認同，但對行銷措辭與技術證據保持強烈懷疑。許多開發者能立即想到分類、排序、路由與代理工作流程等用途；同時，社群普遍要求公開更多架構、評測及實際測試結果。討論串在整理時已有逾千點與數百則留言。[1]
👍 正面反應
- 實際解決正式環境痛點：不少開發者表示，他們本來就會把 LLM 限縮為「從少數選項中做決策，並輸出結構化資料」。若 Jev 的成本、延遲與校準機率符合宣稱，可能成為代理系統的新標準元件。
- 成本與速度很有吸引力：批次分類、內容排序、RAG chunk ranking、工具選擇、客服路由、CI／語意 lint、遊戲 QA 與即時 UI 控制，是最常被提到的潛在用途。
- 適合與 LLM 搭配，而非取代 LLM：多位網友認為，LLM 可負責拆解問題、生成規格與較長程推理，再交由 Jev 執行高頻、低延遲的結構化決策。一位早期使用者也表示，它很適合作為其他模型輸出的第二道驗證。
- Doom 與智慧家庭展示讓價值更具體：這些示範讓部分網友理解「結構化狀態輸入、決策輸出」的工作方式，並聯想到遊戲 QA、機器人與電腦操作等場景。
- 零樣本通用分類器的定位受到關注：部分留言將 Jev 概括為「可在執行時指定選項、一次平行回答多個問題的通用零樣本分類器」，認為這比傳統上為每項任務自行蒐集標註資料、訓練分類器更容易採用。[1]
👎 主要質疑
- 「不會幻覺」被認為是最有爭議的說法。網友普遍指出：型別正確不等於內容正確；模型仍可能以很高信心輸出錯誤但符合結構描述的值。較精確的表述應是「不會產生格式或型別不合法的輸出」，而不是不會犯錯。
- 速度比較可能是蘋果比橘子。Jev 不生成文字，本來就能省去自回歸解碼成本；若拿它與需要輸出完整字串或思維鏈的 LLM 比較，40～200 倍的差距未必能代表相同工作量下的公平比較。
- 公開證據仍不足。社群希望看到 RLCD 的技術細節、模型架構、預訓練來源、參數規模、校準方法、公開基準、可重現程式碼與獨立評測。有人特別質疑：以 Astra 與 Fable 的平均預測作為參考答案，並不能等同於真實正確答案。
- 行銷定位過度膨脹。部分網友認為「frontier model」及與完整 LLM 正面比較的說法容易誤導；較準確的定位或許是「以速度與成本推進結構化決策前沿」。
- Doom 展示的限制。模型接收的是遊戲內結構化狀態，而非畫面，因此電腦視覺、狀態擷取與遮蔽等難題已由外部系統處理。有人認為示範仍很酷，但不能直接推論它能處理自駕等完整感知問題。
- 開發者仍需大量狀態工程。要把複雜需求拆成單一維度的問題、定義候選輸出、組合信心分數及處理例外情境，本身就是程式設計工作；錯誤或不完整的問題空間可能讓模型穩定地給出不理想答案。
- 封閉模型與雲端依賴。不少人希望提供技術報告、開放權重或本地部署版本，尤其是智慧家庭與敏感資料用途。亦有人希望未來可透過 OpenRouter、AWS Bedrock 等平台採用，以降低供應商審查與整合成本。[1]
🛠️ 網友提出的具體用途
- 從大量文章中排序並挑選最相關項目
- 大規模逐字稿與內容分類、隱私合規稽核
- RAG 檢索結果與記憶的相關性排序
- 代理的工具選擇、語意分支、輸出驗證與內容護欄
- 客服意圖辨識、工作流程路由與詐欺訊號評分
- 遊戲 QA、即時 NPC／控制決策、智慧家庭指令處理
- CI、可觀測性、語意 lint 與程式碼上下文篩選
- 由 LLM 先建立規格，再由 Jev 反覆執行的混合式架構[1]
❓ 社群仍等待回答的問題
- RLCD 與 RLVR、一般分類器或 conformal prediction 的本質差異是什麼？
- 機率在跨領域、分布外輸入與複合工作流程中，是否仍能維持校準？
- Jev 與 encoder-only Transformer、一般 embedding 加分類頭或小型開源模型相比，實際優勢多大？
- 32k context、候選項目數量及複雜推理能力會如何限制真實應用？
- 是否會公布論文、模型細節、公開評測、開放權重或本地版本？
- 在企業正式環境中，隱私、安全、SLA 及供應商鎖定問題如何處理？[1]
綜合判讀
HN 社群並未否定 Jev 的核心方向。相反地，許多開發者認為「將高頻、窄範圍的 AI 判斷，從通用文字生成模型中獨立出來」很合理，也符合現有正式環境的架構趨勢。真正的爭議集中在宣傳用語是否超過證據：如果 TypeSafe 能以獨立測試證明準確率、機率校準、成本與延遲優勢，Jev 可能成為 LLM 工作流程的重要配套元件；在此之前，較穩健的態度是把它視為一款令人期待、但仍待驗證的高速結構化決策模型。[1]