不說話的 AI：TypeSafe Jev 與 System One 模型解析

2026-09-21

傳統呼叫大語言模型（LLM）的流程充滿摩擦：組裝提示詞、等待逐字串流輸出，接著處理 JSON 遺漏閉合括號、格式錯亂，以及為了防範模型胡言亂語而寫下的繁複防禦邏輯。

2026 年 9 月 15 日，由 ChatGPT 共同發明人 Diogo Almeida 創立的 TypeSafe AI 發表了旗下首款模型 Jev。它最反直覺的特點在於：它完全不生成文字。

Jev 接收非結構化狀態與一組型別化的問題，直接輸出具備型別安全與校準機率的決策。它的核心定位不是與通用語言模型競爭生成能力，而是充當軟體架構中快速、便宜且輸出結構可靠的「智慧型條件分支」。

什麼是 System One 模型

TypeSafe AI 將 Jev 定義為 System One Model（第一系統模型），概念取自心理學家康納曼（Daniel Kahneman）的雙系統理論：

 +------------------------------------------------+
 |             AI System Architecture             |
 +------------------------------------------------+
            |                         |
            v                         v
 +----------------------+  +----------------------+
 |  System 1: Jev       |  |  System 2: LLM       |
 |  Fast, intuitive     |  |  Slow, analytical    |
 |  Decision & Routing  |  |  Generation & CoT    |
 +----------------------+  +----------------------+

在雙系統架構中，System 2 負責慢想、長程推理、寫程式與生成長文，由主流 frontier LLM 掌管；System 1 則專注於快思、直覺分類與即時過濾，例如判斷信件是否為釣魚詐騙、或工單該分派給哪個組別。

A frontier-intelligence function call: unstructured state in, typed probabilistic decisions out.

—— TypeSafe AI 官方定義

它的本質就像一個高度聰明的 if 判斷式。它不直接與使用者對話，而是嵌入後端程式碼中，取代那些過去難以用規則寫死的模糊決策。

Diogo Almeida 曾是 OpenAI 研究員，也是 ChatGPT 的共同發明人之一。在歷經兩年的低調研發後，他對目前 AI 發展提出了一個關鍵質疑：

Why have superhuman chat models not led to AGI?

—— Diogo Almeida

Almeida 認為，聊天模型的輸出形式是為人類閱讀設計，而非供軟體系統使用。Jev 採用全合成資料訓練，在底層徹底揚棄了文字生成機制。

模型名稱取自 19 世紀經濟學家 William Stanley Jevons 提出的傑文斯悖論（Jevons paradox）：當資源使用效率大幅提升時，總消耗量反而會增加。當單次 AI 決策的延遲降至 100 毫秒、成本降至近乎免費時，模型呼叫便能全面滲透進資料庫寫入前、工具呼叫守門點與即時過濾等高頻使用情境中。

架構與運作原理

雖然 TypeSafe 尚未公開具體的模型參數量與底層細節，但從公開文件與技術分析中，已能勾勒出 Jev 的關鍵技術特徵。

平行取樣器（Parallel Sampler）

傳統自迴歸模型在產生結構化輸出時，必須按順序一個 token 接一個 token 計算。Jev 採用了硬體感知的非自迴歸平行取樣機制，能在單次查詢中同時評估並產出所有結構化數值。

這帶來了一項顯著的架構優勢：在同一次請求中增加問題數量，幾乎不會增加回應延遲。針對同一筆資料同時評估五個或十個問題，耗時與單一問題大致相同，僅需支付極低的額外輸入 token 成本。

RLCD：為機率校準而生

主流語言模型多採用人類回饋強化學習（RLHF），最佳化目標是產生符合人類偏好的文字。Jev 則採用 RLCD（Reinforcement Learning for Calibrated Decisions） 訓練方法，核心指標在於機率校準度（Probability Calibration）。

機率校準看的不是單次預測是否正確，而是大量預測的長期統計：若把預測依信心分數分組，信心約為 85% 的那組，實際正確率也應接近 85%。良好的機率校準，使輸出數值能直接作為程式中自動化流程的決策門檻。

三種提問原語

Jev 透過三種原語型別定義問題空間：

Noul：布林機率是非題，代表連續機率度量而非離散的二元開關，回傳 0 至 1 之間的機率值（0.5 代表不確定，0.98 代表強烈為真）。
Choice：多選一分類，回傳選取項目、各選項完整機率分布以及信心分數（上限 255 個選項）。
Score：依有序評分量表打分，回傳機率加權後的連續分數與分布。

在提示工程實務上，Vercel 指南特別建議使用具體描述性的準則（criteria）（如以「完全阻斷且無替代方案」取代抽象的「高嚴重性」），能顯著提高判斷的一致性。

實際呼叫：一次請求如何運作

以下是 Python SDK 的典型呼叫範例：

from typesafe_sdk import Choice, Noul, Score, TypeSafeClient

client = TypeSafeClient()
response = client.system_one(
    state={
        "message": "I was charged twice! This is unacceptable.",
        "order_id": "A-104",
        "customer_history": "3-year loyal customer",
    },
    questions={
        "topic": Choice(
            instructions="Classify the primary issue",
            criteria={
                "billing": "Charges, invoices, refunds",
                "orders": "Order status, delivery, returns",
            },
        ),
        "is_urgent": Noul(
            instructions="Does this convey urgency?",
            criteria={
                "true": "Explicitly time-sensitive language",
                "false": "No urgent tone expressed",
            },
        ),
        "customer_satisfaction": Score(
            instructions="How satisfied is the customer?",
            criteria=["Very satisfied", "Neutral", "Dissatisfied"],
        ),
    },
)

回應格式與型別解析

上述呼叫會在幾百毫秒內回傳結構化 JSON，完全不包含需要剖析的自由文字：

{
  "model": "jev-latest",
  "answers": {
    "topic": {
      "type": "choice",
      "choice": "billing",
      "probabilities": { "billing": 0.89, "orders": 0.11 },
      "confidence": 0.88
    },
    "is_urgent": { "type": "noul", "noul": 0.87 },
    "customer_satisfaction": {
      "type": "score",
      "score": 0.2,
      "legend": { "0": "Very satisfied", "1": "Neutral", "2": "Dissatisfied" },
      "probabilities": { "0": 0.02, "1": 0.11, "2": 0.87 },
      "confidence": 0.85
    }
  },
  "usage": { "input_tokens": 412, "output_tokens": 156 }
}

這個回應結構體現了幾個重要特點：

topic.choice 保證為合法列舉值，程式碼可直接進行 match 或 switch 分支，無需 try/catch 防禦。
Choice 與 Score 具備獨立的 confidence（反映分布集中程度），而 Noul 的機率值本身即為判斷依據。
API 提供完整的機率分布。若首位選項機率為 0.51 且次位為 0.49，系統能輕易識別出邊界爭議案例。
定價上 Input 每百萬 tokens 為 $0.042，Output 因輸出結構化型別值而完全免費。

雙重門檻自動化模式

在工程實務中，建議針對整體分布集中度與首選機率強度設置雙重門檻，並依錯誤代價分別設定：

ans = response.answers["topic"]

# 雙重門檻：分布夠集中且勝出者夠強
if ans.confidence >= 0.6 and ans.probabilities[ans.choice] >= 0.7:
    assign_ticket_to(ans.choice)  # 高信心：全自動分派
else:
    queue_for_human_review()      # 中低信心：交由人工審核

能力邊界與選型評估

在架構選型時，必須釐清 Jev 所能保證的邊界，以及無法跨越的結構限制。

型別保證與「零幻覺」的精確定義

官方宣稱，Jev 的結構化輸出與工具呼叫格式錯誤率皆為 0%。模型輸出空間嚴格限於預先定義的 schema，因此 Jev 在數學與結構層面上絕不會產生格式違規。

但需釐清的是：「零幻覺」僅代表符合 schema，不代表答案必然客觀正確。Jev 不會捏造未定義的列舉值，但完全可能在定義好的五個分類中選錯選項。

硬限制清單

在工程選型時，CloudRaft 的技術分析列出了以下硬限制：

無法生成文字與解釋：不輸出自然語言，亦無法提供決策理由。在需要可解釋性稽核的合規使用情境（如金融授信、醫療判斷）並不適用。
分類基數上限：Choice 單題最多支援 255 個選項，超高基數使用情境需拆解為多階段管線。
純文字輸入與上下文窗口：僅支援純文字，每請求上限 64k tokens，其中 state 加最長一題為 32k；處理圖片須先經多模態模型轉為文字。
不擅長抽取、算術與多跳推理：缺乏測試時計算（test-time compute），無法勝任資料抽取、日期比對或長推理鏈任務。
託管 API 依賴：目前僅提供 hosted API（排隊申請中），無開源權重與自建部署方案。

基準效能與真實代價

TypeSafe 自行揭露的四項工作流程測試資料如下（官方宣稱，未經第三方獨立驗證）：

模型	準確率	每案成本	延遲
Jev	67.8%	$0.0004	0.4s
GPT-5.6 Terra	67.9%	$0.0304	10.1s
GPT-5.6 Sol	74.1%	$0.0836	23.3s
Opus 5	73.1%	$0.1761	37.8s

ExplainX 的查核報告指出：Jev 的速度與成本優勢，是以約 6 個百分點的準確率落差為代價換取的——DataCamp 整理官方資料的結論是，Jev 約與中階的 Terra 持平，仍落後頂級推理模型。官方宣稱端到端回應時間為 70 至 500 毫秒、多數查詢約 100 毫秒；測試中的 0.4 秒，則是同一案件多題打包為單一請求後的整體時間。

混合架構：與現有 LLM 的分工

在系統架構中，Jev 的定位不是替代語言模型，而是作為 LLM 的前置分工層。

 Incoming Request
   |
   +--> [Jev: System 1] --> Fast Decision / Routing
   |      |                 (~100ms, $0.0004)
   |      |
   |      +--- High Confidence ----> Direct Code
   |      |                         Execution / Action
   |      +--- Medium Confidence --> Human-in-the-loop
   |      |                         Review
   |      +--- Low / Ambiguous ----+
   |                               v
   +------------------------------> [Frontier LLM: System 2]
        --> Complex Reasoning & Text

過去由昂貴 LLM 承擔的意圖辨識、安全檢查與流程分流，改由 Jev 在百毫秒內以極低成本（輸入每百萬 tokens $0.042，輸出免費）完成；真正需要撰寫長文或深度推理的環節，才轉交給 System 2 模型。

相較於 BERT 等傳統機器學習分類器，Jev 的優勢在於任務在 runtime 透過自然語言問題動態定義，免去了資料標註、模型訓練與維運多個專用分類器的工程負擔。

核心應用情境與邊界

綜合實踐經驗，Jev 的最佳應用情境可歸納為三大模式：

1. 即時守門與安全過濾（Guardrail & Moderation）

Agent 工具安全檢查：在 Agent 執行 Shell 指令、刪除資源或傳送對外通訊前，平行評估多個 Noul 問題（破壞性、外發性、人工確認需求）。延遲約 100ms 不會拖慢 Agent 迴圈，並能依風險設不同門檻（刪除需 0.99，讀取 0.7 即可）。
高流量即時審核：在社群留言串流中，一次呼叫平行偵測垃圾訊息、釣魚威脅、騷擾與違規等級。極低單價使系統能執行全量即時掃描而非抽樣檢查。
邊界反例：若合規流程要求「阻擋時必須輸出人類可讀的文字理由留存稽核」，Jev 無法單獨完成，需由 LLM 補足解釋。

NOTE

延伸閱讀：Bear CLI 與 MCP 如何重塑 Apple 原生筆記的自動化版圖

2. 意圖路由與批次標註（Routing & Batch Classification）

客服工單智慧分流：解析進線內容並回傳部門分類與緊急程度評分。達到門檻者自動派工，模糊案例則退回人工審核佇列。
大量資料初篩與 PII 標註：在資料湖 PII 掃描或研究文件分類中，免除 JSON 格式修復與重試機制。Flavio Copes 引述的實測顯示，分類 1,018 篇學術論文僅花費 $0.08。
邊界反例：若任務是從合約中提取生效日期與金額，則屬於資訊抽取任務，Jev 明確不擅長，應交由 LLM 或專用抽取模型。

3. 即時控制與自我驗證（Control Loops & Fact Checking）

百毫秒互動控制：應用於瀏覽器自動化點選判斷或遊戲 AI 決策，讓模型得以介入過去 LLM 秒級延遲無法參與的即時控制迴圈。
生成內容的事實查核層：在生成式內容輸出前，將查核需求拆解為多個平行 Noul 是非題（引用是否支持主張、前後文是否矛盾），以極低成本建立全量驗證防線。
邊界反例：需要長程規劃、多步推理鏈或需裁判撰寫具體糾錯評語的任務，不適用於 Jev。

爭議、風險與導入實務

將決策層全面押注於新架構前，必須正視其評測方法與長期可行性的爭議。

評測標準與護城河爭議

ExplainX 查核指出，TypeSafe 的官方基準主要衡量「Jev 與其他 frontier 模型的一致性」，而非客觀標準答案。Every 的獨立測試顯示加速與成本節省趨勢成立，但在抽取任務上的加速比約為 25 倍，低於官方宣稱的極端值。

此外，評論者 Sean Goedecke 質疑其架構是否具備長期護城河，猜測現有開源模型透過激進的 prefill 與單 token 受限取樣，或能達成類似效果。

任務拆解的敏感性

XenoSpectrum 的分析揭示了一項關鍵現象：在釣魚郵件偵測資料集上，將判斷拆解為五個子問題再組合，準確率由最佳單題的 89.4% 提升至 95.0%（五題分別檢查網域偽造、緊迫語氣、索取登入憑證、短網址與冒名寄件者）。

相對地，若僅以單一概括問題詢問，Jev 的準確率僅有 62.6%；不過此數字測於完整資料集，與拆分實驗的評測集不同，不宜直接相比。

這顯示 Jev 的表現高度仰賴精細的問題拆解。未經拆解的粗略提問，可能導致效能大幅低於預期。在工程實務中，應將複雜判斷拆分為多個正交的原子問題平行評估。

漸進式導入：影子測試策略

在評估將決策層遷移至 System One 模型時，建議遵循四步導入流程：

影子測試（Shadow Testing）：讓 Jev 與現有判斷邏輯平行運作，僅記錄決策結果與信心分數，不直接影響生產環境。
驗證校準曲線：以自身業務的真實資料集比對 ground truth，確認其機率分數的客觀可信度。
低風險路徑試行：先對錯誤代價較低的標記或初篩流程啟用高門檻自動化。
動態微調門檻：根據實測錯誤成本，逐步調整信心門檻並擴充自動化覆蓋率。

保持決策層的介面抽象，使系統在必要時能平滑退回規則引擎或 LLM，是現階段應對供應商鎖定最穩健的工程實踐。

簡單來說，若任務能被表達為固定選項、需要機率判斷且呼叫量大，Jev 值得評估；若需要生成、解釋或多步推理，仍應交給 LLM。