【2026 最新】System One Model 是什麼？用 Jev 看懂不生成文字、直接做決策（新手白話篇）

如果 AI 的工作只是把客服單分到正確部門，它真的需要先寫出一段話嗎？TypeSafe AI 在 2026 年 9 月推出 Jev，並把它歸入自家提出的 System One Model：輸入一份狀態，不逐字生成回覆，而是直接回傳事先定義好的型別與機率。

這個介面很吸引人，因為軟體真正需要的往往不是漂亮句子，而是「送到 billing 還是 technical」、「風險有多高」、「要不要交給真人」。但型別正確、信心高、機率有校準與答案正確，是四件不同的事。把它們混在一起，就會把一個可控的決策元件誤當成永遠不犯錯的裁判。

這篇用一張客服工單，從零拆解 State、Choice、Score、Noul，帶你看懂 Jev 與規則、傳統分類器、Structured Output LLM 的差別；最後再給一套可重跑的比較方法。你不需要先懂機器學習，也不需要相信發布會上的速度倍數。

先說結論：System One Model 是「決策介面」，不是聊天模型

先記住本文的錨點：

System One Model ＝ State（狀態）＋ Typed Questions（型別化問題）→ Probabilities（機率答案）＋ Code-owned Action（程式決定行動）。

模型負責判斷，程式負責規則、門檻與副作用

你可以把 Jev 想成一個很快的「機率版 if／else 助手」。你先把選單寫好，它只在選單內判斷，並交回機率分布；它不替你寫信、不產生程式碼，也不自己按下退款按鈕。最後要自動處理、要求確認、轉給真人，仍由你的程式決定。

• 它擅長：封閉答案空間、高頻、可重複的語意判斷，例如分流、評分、是否符合條件。
• 它不做：開放式寫作、自由擷取文字、長鏈推理、產生解釋或自主規劃下一步。
• 它沒有消除：分類錯誤、資料偏移、門檻設錯，以及高風險動作需要覆核的問題。

這也是它和 AI Agent Harness 的責任邊界：Harness 可以管理工具、狀態與流程；Jev 只回答流程中的窄問題。若要真正動手搭 Agent，再接著看最小 AI Agent Harness 教學。

System One Model 是什麼？先看兩種資料流

一般自回歸 LLM 會一個 token 接一個 token 地生成字串。若軟體只接受固定 JSON，你還要驗證 schema、處理缺欄位，必要時重試。Structured Output 或 constrained decoding 能把格式風險大幅壓低，但底層任務仍可能包含生成與推理。

TypeSafe 對 System One Model 的定義則是：讀取自然語言或結構化 state，直接輸出 typed decisions 與 probabilities。官方稱 Jev 採用新架構、平行取樣器，以及 Reinforcement Learning for Calibrated Decisions（RLCD）；但截至 2026 年 9 月 16 日，公開內容主要描述介面、訓練目標與自家評測，尚不足以讓外部完整重建架構或訓練流程。因此，本文只用可觀察的 API contract 教你判斷價值，不猜模型內部。

名字借用了 Daniel Kahneman 普及的 System 1／System 2 比喻：前者快而直覺，後者慢而審慎。但「System One Model」目前是 TypeSafe 對自家模型類別的命名，不是所有研究者已共同採用的標準分類。

State、Choice、Score、Noul：四個零件怎麼配？

Jev 的請求由一份 State 與一組 Questions 組成。依官方 State 文件，State 可以是字串、JSON object 或 array；同一請求中的問題會看見同一份 State，並各自獨立判斷。

1. State：模型要看的現況

State 不是聊天歷史的別名，而是這次決策真正需要的材料。客服分流可以放客戶訊息、帳務狀態與方案；詐騙檢查可以放交易、裝置與地理訊號。原始欄位之間有關係時，用 object 比把所有內容黏成一段字串更清楚。

2. Choice：從封閉選項中選一個

Choice 適合「哪一類？」問題。你提供 billing、technical、sales 與各自定義；回應包含最高機率選項、全部選項的機率分布，以及由分布形狀計算的 confidence。選單可能漏接真實世界時，要主動加上 other 或 none_of_the_above，不要逼模型在三個錯誤答案中挑一個。

3. Score：沿著有順序的刻度評分

Score 適合「程度多高？」問題。你先寫好由低到高的描述，例如 calm、frustrated、very angry；回應是各層級機率的加權平均，所以可能得到 1.035 這類小數，而不是硬塞進某一格。平均分相同，背後的分布仍可能不同，因此不要只存一個 score。

4. Noul：一個 yes／no 的機率

Noul 適合「是否？」問題，回傳 0 到 1 的 noul，代表 yes 的機率。0.82 不是八成有把握的口語形容，而是模型對 yes 的數值輸出。Noul 沒有另一個獨立的 confidence 欄位；接近 0.5 表示 yes／no 很接近，不是「中等嚴重」。

Choice 與 Score 的完整欄位、上限與回應格式，以當下的Primitives 文件為準。特別注意：同一個 request 裡的多個問題彼此獨立；如果第二題必須讀第一題答案，就要由程式分成第二次呼叫。

同一張客服單，System One Model 會怎麼決策？

假設客戶寫：「Stripe 已經連線失敗三天，我正在流失訂單，請盡快幫忙。」我們同時問三件彼此獨立的事：

• Choice：應該送 billing、technical 還是 sales？
• Score：客戶在 calm、frustrated、very angry 的刻度上落在哪裡？
• Noul：這則訊息是否具有急迫性？

官方 Quickstart 的示例回應把部門選為 technical，三個部門的機率約為 0.159、0.840、0.001；frustration score 為 1.035；urgency 的 Noul 為 0.999。這些數字只是官方範例，不是 AlphaLab 的重跑結果。真正上線時，你的程式可以先檢查帳號狀態與服務事故，再把低 confidence 或高風險案例送人工覆核。

型別限制能阻止 Jev 突然創造一個「legal」選項，卻不能阻止它在正解是 technical 時選成 billing。

格式邊界不等於事實正確

因此，退款、封鎖帳號、轉帳、醫療分流等不可逆動作，不應只靠一次模型判斷。先做 deterministic checks，再依風險分層確認，才是 AI Evals 真正要保護的系統行為。

Jev 與規則、分類器、Structured Output LLM 差在哪？

不要問「哪個永遠最好」，要問「哪個最適合這個決策邊界」。四種方法各有責任：

1. 程式規則：相同輸入必得相同結果，便宜、可稽核，最適合金額上限、權限、黑名單等硬條件；但面對同義句、語氣與模糊語意會很脆弱。
2. 傳統分類器：固定標籤下通常很快，能用自己的標註資料訓練與校準；代價是每個任務要準備資料、訓練、部署與監控。
3. Schema-constrained LLM：保留 LLM 的開放理解與推理能力，又能限制 JSON 形狀；適合需要解釋、擷取或多步推理的工作，但 schema 正確仍不保證欄位值正確。
4. Jev：TypeSafe 主張它能在不為每個任務重新訓練的情況下，以自然語言定義 Choice、Score、Noul，直接取得 typed probabilities；代價是答案空間必須先關閉，且目前仍是 early access。

最實用的架構通常是混合式：規則處理硬限制，模型處理模糊語意，程式再把兩者組合。例如「交易金額超過上限」一定人工覆核；其餘案件才讓 Jev 判斷意圖。這和短輸出壓縮證書的精神相同：縮小模型能做的事，並讓另一層重新驗證，而不是把自由度當成能力。

最容易混淆的四件事：型別、機率、信心、正確

型別有效：回應能不能被程式安全讀取？

這是結構層。Choice 應回傳你宣告的 option，Score 應回傳數值與分布，Noul 應回傳 0 到 1。TypeSafe 把這層描述成沒有 type errors；較精確的理解是「答案被限制在 primitive 的 schema」，而不是 API 永不逾時、永不過載或語意永不出錯。

機率分布：各答案拿到多少權重？

Choice 的三個 option 機率會形成一個總和為 1 的分布；Score 也有各 level 的分布；Noul 則直接給 yes 的機率。完整分布比單一贏家更有用，因為 0.51／0.49 與 0.99／0.01 雖然都選同一類，決策風險完全不同。

Confidence：分布有多集中？

依TypeSafe Confidence 文件，Choice 與 Score 的 confidence 是從機率分布形狀算出的摘要值；越集中通常越高。它不是「答案正確率」的同義詞。模型可以很集中地選錯，而官方頁面也沒有公開這個摘要公式。

Calibration 與 accuracy：一群預測是否誠實？單題是否答對？

如果 100 個條件相近的案例都拿到約 0.8，校準關心的是其中是否約 80 個最後為真；它不告訴你哪 20 個會錯。Accuracy 則直接比對預測與 ground truth。模型可能校準尚可但辨識力很差，也可能 accuracy 高卻過度自信。資料分布改變後，兩者都可能退步。

這也是校準與真實 anchor必須一起看的原因。門檻不能從文件抄一個 0.9 就上線；要在自己的 holdout、罕見案例與資料偏移條件下，看 reliability diagram、Brier／log loss，以及拒答後剩下案例的錯誤率。

速度快、成本低、不會幻覺？先讀懂證據邊界

TypeSafe 的發布文章報告 70–500ms 端到端延遲、相對可比 frontier model 快 40–200 倍，並從自家 workflow eval 得出最高 193.6 倍快、444.6 倍便宜的首頁數字。這些是廠商在特定 System One-shaped workflow、地理位置、wrapper 與模型設定下量到的結果，不是所有任務的普遍倍率。

發布文也主動揭露限制：workflow 由 TypeSafe 模型能力團隊製作，可能存在偏差；參考答案取自 GPT-6 Astra 與 Claude Fable 5.1 的平均，而非獨立人工 ground truth；官方並稱這組速度與成本增益可能位於真實情境的高端。這不代表結果無效，只代表你不能把它直接搬到自己的客服、風控或審核流程。

至於「can’t hallucinate」，若把 hallucination 定義成生成 schema 外的字串，封閉型別確實縮小了輸出空間；若它的意思是「不會做出語意錯誤的判斷」，現有證據不支持。TypeSafe 自己的概念文件也明說：校準以一群預測衡量，不保證單一答案正確。比較成熟的結論是：Jev 可能減少格式與解析失敗，但沒有消滅判斷錯誤。

截至本文日期，Jev 仍是 early access。AlphaLab 的執行環境沒有 early-access API key，因此本文不提供自家延遲、成本或校準實測，也不把官方範例包裝成實測。這種對 vendor claim 的處理方式，也可參考小模型評測的證據分層。

Jev 快速上手：目前 API 與 Python SDK 怎麼寫？

先在 TypeSafe console 取得 API key，再依目前 Quickstart使用 POST https://api.typesafe.ai/v1/systemone 與 model alias jev-latest。Python SDK 要求 Python 3.10 以上：

pip install typesafe-sdk
export TYPESAFE_API_KEY="your_key_here"

下面是依官方 0.6.0 介面整理的最小範例。Score 的 criteria 是有順序的 sequence；不要照舊文章寫成整數 key 的 map。

from typesafe_sdk import Choice, Noul, Score, TypeSafeClient

client = TypeSafeClient()  # 從 TYPESAFE_API_KEY 讀取金鑰

ticket = (
    "Hi, I've been trying to connect my Stripe account for 3 days "
    "and it keeps failing. I'm losing sales. Please help ASAP."
)

response = client.system_one(
    state=ticket,
    questions={
        "department": Choice(
            instructions="Which team should handle this?",
            criteria={
                "billing": "Payments or subscription issues",
                "technical": "Bugs or integration problems",
                "sales": "Pricing or account questions",
                "other": "None of the listed teams clearly fits",
            },
        ),
        "frustration": Score(
            instructions="How frustrated does the customer appear?",
            criteria=[
                "Calm, just stating facts",
                "Frustrated but civil",
                "Very angry, strong language",
            ],
        ),
        "is_urgent": Noul(
            instructions="Does the message convey urgency?",
        ),
    },
)

department = response.answers["department"]
urgency = response.answers["is_urgent"].noul

print(department.choice)
print(department.probabilities)
print(department.confidence)
print(urgency)

先只列印結果，不要第一天就接生產副作用。接著才在程式裡加入三條路：高信心且低風險可自動分流；中間區間要求確認；低信心、other 或高風險一律人工覆核。門檻要從你的標註資料決定，不能把官方文件的示意數字當成安全保證。

沒有 early access 也能先做：四組公平基準

真正有用的比較不是「Jev 對最強 LLM 誰比較聰明」，而是同一個封閉決策任務，哪個系統在你的限制下最划算。先從最近的人工決策整理一份去識別資料，凍結定義與 ground truth，再建立四組基準：

1. 規則 baseline：關鍵字、欄位條件與優先順序；保存每條規則命中原因。
2. 傳統分類器 baseline：用 train split 訓練，只在固定 holdout 評估；不要用測試答案反覆調參。
3. Structured Output LLM baseline：同一 State、同一選項文字、同一輸出 schema，固定模型版本與設定。
4. Jev candidate：取得存取後才加入；使用同一資料、同一 answer space，保存完整 distributions 與 usage。

每組至少分開記六類指標：Choice 的 accuracy／macro-F1、Score 的 MAE、機率的 Brier 或 log loss、schema validity、p50／p95 latency、每千次決策成本。再畫 selective risk／coverage：門檻升高、交給人工的比例增加時，剩餘自動案例錯多少？只比較平均 latency，會把尖峰逾時與重試藏掉；只比較 accuracy，又會漏掉模型是不是知道自己不確定。

再加一組 shifted set：新產品名、拼字錯誤、混合語言、空欄位、蓄意誘導與選單外案例。若你想把這套設計變成可重跑工作簿，先讀 AI Evals 教學；重點不是做一張排行榜，而是找出哪一類錯誤會觸發錯誤行動。

決策樹：什麼時候該用 Jev？

• 答案可以事先列完嗎？不能，就先用 LLM、搜尋或擷取工具；能，才繼續。
• 規則已經夠準嗎？夠，就保留規則。不要為了用 AI 換掉更簡單的解法。
• 有大量標註與穩定任務嗎？有，就把傳統分類器列為強 baseline；Jev 要用數據證明增量價值。
• 需要長解釋、程式碼或自由文字嗎？需要，就不是 Jev 單獨能完成的形狀。
• 錯一次會不可逆嗎？會，就把模型當訊號，不當執行許可；加規則、確認與真人覆核。
• 高頻、封閉、可逆、語意模糊嗎？這才是最值得拿 Jev 與既有方案 A/B 的區域。

一個好候選是客服路由：分錯還能轉隊，人工答案能形成回饋資料。壞候選是「根據一句話直接凍結帳戶」：即使型別完全正確，false positive 的代價仍可能不可接受。

常見的 7 個 System One Model 實作陷阱

1. 選項不完備：沒有 other，就會把未知案例硬塞進已知類別。
2. 問題彼此依賴：同一 request 內的問題獨立，後題不能偷看前題；真的有依賴就分兩步。
3. 把 confidence 當正確率：它是分布摘要；一定要和真實標籤一起驗。
4. 全域只設一個門檻：顯示說明頁與核准退款的風險不同，門檻與確認流程也應不同。
5. 只測乾淨資料：生產環境會有缺欄、拼錯、惡意文字與分布漂移；shifted set 不能省。
6. 讓模型執行副作用：模型輸出應先經規則與授權層，再由程式呼叫工具。
7. 看到 vendor 倍數就省略 baseline：任務、網路、wrapper 與品質門檻不同，速度與成本就不可直接搬用。

若模型是第二意見而非主裁判，也要防止兩個模型共享相同盲點。把可被程式驗證的條件留給 deterministic checks；把難以驗證的部分抽樣人工審查，並保存 State、question 版本、模型 alias、完整分布、行動與最終結果。

截至 2026 年 9 月，哪些部分仍在變？

Jev 正處於 early access，jev-latest 是目前文件使用的移動 alias。公開資訊沒有提供可依賴的固定 SLA、一般開放日期或可完整重現的訓練規格；SDK、primitive 限制、價格與 alias 指向也可能調整。上線前要重新查 API reference與 changelog，並把 request／response contract 鎖進測試。

若你需要版本可追蹤的生產系統，至少保存每次評測日期、model 回傳值、SDK 版本、questions hash 與資料版本。移動 alias 更新後先跑 canary，再升級；這和任何模型更新都要重跑回歸 Eval是同一件事。

常見問題 FAQ

1. Jev 是一個小型 LLM 嗎？

公開證據不足以這樣下結論。TypeSafe 稱它採用不同架構與取樣方式，但未公開到可供外部重建。對使用者最可靠的描述是：Jev 是一個不生成自由文字、以 Choice／Score／Noul 回傳機率判斷的 early-access 模型 API。

2. System One Model 能取代 ChatGPT 或一般 LLM 嗎？

不能全面取代。它沒有自由寫作、程式碼、解釋與長鏈推理輸出。它更像工作流裡的一個判斷元件；需要文章、摘要或開放式回答時，仍要生成式模型。

3. 型別保證是否等於不會幻覺？

不等於。封閉 schema 能防止出現未定義的輸出形狀或選項，但模型仍可能選到錯的合法選項。把它稱為「格式層不亂跑」比「事實永遠正確」精確。

4. Confidence 0.9 是否代表九成會答對？

不能直接這樣讀。Choice／Score 的 confidence 是分布集中程度的摘要，不是經你資料驗證的個案正確率。只有在代表性樣本上完成校準檢查後，才能知道某個區間對你的任務代表什麼。

5. Noul 0.8 和 confidence 0.8 一樣嗎？

不一樣。Noul 0.8 是 yes 的輸出機率；Noul 沒有另一個 confidence 欄位。Choice／Score 的 confidence 才是從多項分布形狀衍生的摘要。

6. Jev 一定比 Structured Output LLM 快嗎？

不能先假定。TypeSafe 在自家特定 workflow 報告顯著速度優勢，但你的輸入長度、地區、模型、重試、並行量與品質門檻都不同。用相同資料量 p50、p95 與失敗率才公平。

7. 沒有 Jev API key，現在能做什麼？

先把問題做成可比較的決策任務。整理 State、封閉選項、other 路徑、標註 holdout、規則 baseline 與 Structured Output baseline。取得存取後只新增一個 candidate，不必臨時改評分規則。

8. 哪些情境不該只靠 Jev？

任何錯誤會直接造成重大或不可逆後果的情境。金融授權、醫療處置、法律結論、身分停權與安全封鎖都需要硬規則、權限檢查、確認或真人覆核；模型機率只能是輸入訊號。

給新手的 7 個重點

1. System One Model 是 TypeSafe 對一類 typed probabilistic decision model 的命名。
2. Jev 讀取 State，透過 Choice、Score、Noul 回傳封閉答案與機率。
3. 它不生成回覆、程式碼或推理說明，也不應直接擁有副作用。
4. 型別正確不等於語意正確；confidence 也不等於個案答對率。
5. 校準要在一群有真實結果的案例上測，並在資料漂移後重測。
6. 官方速度、成本與準確性是 vendor results，必須用自己的 baseline 重跑。
7. 最適合先試的是高頻、封閉、可逆的語意決策；高風險動作永遠加閘門。