Jev 模型是什麼？TypeSafe System One 決策模型技術解析：三種問題型態、信心分數門檻、9 個已知弱點，以及怎麼接進客服分流與既有系統

Jev 模型是 TypeSafe AI 在 2026 年 9 月 15 日發表的決策模型：你把一段文字或一包 JSON 當作「狀態」丟給它，附上幾個答案範圍固定的問題，它回給你選項、分數或是非，每個答案都附機率與信心分數。它不寫句子、不解釋理由、不產生程式碼。官方把這類模型叫 System One 模型，名字借自康納曼《快思慢想》裡「系統一」那種快速直覺的判斷。

我們公司內部跑的客服分流流程，三層全是判斷題：這封信跟我們有沒有關係、屬於哪一類、有多急。這三層今天都靠 LLM 吐 JSON 來做，每一封信都要等模型一個字一個字把 JSON 生完、再由程式解析。Jev 發表當天，我們第一件事就是把它的 API 文件對著這條流程逐段看過。這篇把看到的東西整理出來：它怎麼運作、三種問題型態各回傳什麼、信心分數該怎麼設門檻、定價與速率限制、官方自己列的 9 個弱點，以及要接進客服分流或既有系統時，它該放在哪個位置。

先講它為什麼值得花時間看。Vercel 在 AI Gateway 的統計是：上線 24 小時內就有將近 13% 的付費團隊用過它，是 GPT-5.6 系列的 2 倍、Fable 5.1 的 6 倍，成了該平台史上採用最快的模型。開發者搶著測它的理由很單純：TypeSafe 官方宣稱在分類、路由、評分這類任務上，它比前沿 LLM 快 40 到 200 倍、便宜 40 到 400 倍，而且輸出 token 完全免費。

Jev 模型到底是什麼：一個只回答選擇題的 AI

一句話定位：Jev 是給程式用的判斷引擎，把「這封信該給誰」「這筆訂單像不像詐騙」「這段回答有沒有離題」這種答案範圍有限的問題，用一次呼叫換成帶機率的結構化答案。下面這張表先把整篇的結論擺出來，後面每一節再展開。

要理解 Jev，先看 LLM 在做分類時的真實流程。你請 GPT 或 Claude 把一封客服信歸類，它做的事是「預測下一個 token」：先吐一個左大括號，再吐 department，再吐冒號，再吐 technical，一路吐到 JSON 收尾。每個 token 都是一次完整的模型前向傳遞。你要的其實只是「technical」這一個答案，卻付了整份 JSON 的生成成本，還得處理它偶爾漏一個逗號害解析失敗的狀況。

Jev 把這件事反過來做。它讀一次狀態，對每個問題直接輸出「答案空間裡每個選項的機率」。用海關檢查員來比喻：LLM 像一個會替你把整份入境申請書重寫一遍的職員，Jev 像只在你表格上打勾、打分數、蓋章的檢查員，從頭到尾沒寫過一個字。

它背後的人是 Diogo Almeida，前 OpenAI 研究員、InstructGPT 論文共同作者，也就是把 RLHF 這套後來變成 ChatGPT 基礎的方法做出來的團隊成員之一。iThome 的報導提到，TypeSafe 用大量合成資料訓練，並用官方稱為 RLCD 的強化學習方法讓模型的機率貼近實際命中率，這就是他們口中「校準」的意思：一群信心 0.8 的答案，長期看大約 8 成是對的。校準是群體性質，單一答案還是可能錯，這點後面講弱點時會再回來。

講到「AI 讀完內容做判斷、程式接著動」這種形狀的任務，這件事我們自己已經有現成的在跑：SalesKing是我們每天在用的 CRM，AI 讀完 LINE 對話後判斷客戶處在哪個銷售階段、生成追蹤計畫。「判斷銷售階段」就是一題標準的 Choice：選項固定、答案要能讓後面的自動化直接用。Jev 這類模型出現後，這一層判斷可以做得更便宜、更快，也更容易在程式裡設門檻。如果你正在評估類似的系統，可以直接跟我們聊，我們可以先幫你看流程裡哪幾個判斷點適合這樣拆。

三種問題型態：Choice、Score、Noul 各回傳什麼

先給答案：Choice 回一個選項加每個選項的機率、Score 回一個分數加每個等級的機率、Noul 只回一個 0 到 1 的「是」的機率。前兩種附 confidence，Noul 沒有。三種可以塞在同一次呼叫裡，模型只讀一次狀態，所有問題平行評估。

實際的請求長這樣。狀態是一封客服訊息，三個問題一次問完：

POST https://api.typesafe.ai/v1/systemone
Authorization: Bearer <API_KEY>

{
  "state": "你好，我的 LINE 官方帳號串接三天了一直失敗，客戶訊息都收不到，已經掉單了，拜託今天處理。",
  "model": "jev-latest",
  "questions": {
    "department": {
      "type": "choice",
      "instructions": "這封訊息應該由哪個團隊處理",
      "criteria": {
        "billing": "付款、發票、訂閱方案問題",
        "technical": "系統錯誤、串接或功能異常",
        "sales": "詢價、方案內容、合約問題"
      }
    },
    "frustration": {
      "type": "score",
      "instructions": "客戶看起來有多不滿",
      "criteria": ["冷靜陳述事實", "不滿但語氣克制", "非常生氣、用詞強烈"]
    },
    "is_urgent": {
      "type": "noul",
      "instructions": "訊息表達了急迫或有時效壓力"
    }
  }
}

回應也是純結構，程式拿到就能用：

{
  "model": "jev-1.13.0",
  "answers": {
    "department": {
      "type": "choice",
      "choice": "technical",
      "confidence": 0.78,
      "probabilities": { "technical": 0.85, "billing": 0.15, "sales": 0.0 }
    },
    "frustration": {
      "type": "score",
      "score": 1.0,
      "confidence": 1.0,
      "legend": { "0": "冷靜陳述事實", "1": "不滿但語氣克制", "2": "非常生氣、用詞強烈" },
      "probabilities": { "0": 0.0, "1": 1.0, "2": 0.0 }
    },
    "is_urgent": { "type": "noul", "noul": 1.0 }
  },
  "usage": { "input_tokens": 392, "output_tokens": 65 }
}

三件事要注意。第一，criteria 就是你的分類規則，寫得越像「每個選項的邊界條件」它越準；官方文件的建議是，當你發現自己在解釋「我其實是要問…」的時候，那句解釋就是 criteria 缺的那一半。第二，Score 的等級是有順序的描述文字，模型回的 score 可以落在兩個等級之間（例如 1.4），但官方明講不要拿它做精確的數值換算，它擅長的是「有沒有過某個門檻」。第三，Noul 沒有 confidence，你直接拿 noul 的值設門檻就好，但同一個問題用 Noul 問和用 Choice 的 yes／no 問，數字不會對得上，這點在弱點那一節有實際數據。

一次呼叫多題的設計，是它跟 LLM 用法上最大的差別。狀態只被讀一次，每多一題只多付那一題的 token，而且回應時間幾乎不變。官方的 speculative fan-out 模式就是建議你把「可能用得到」的問題一次全丟，例如一封信同時問部門、急迫、有沒有抱怨、有沒有提到合約、有沒有提到退款，程式再依需要挑答案用。用 LLM 做這件事，每多一個欄位就是多幾十個輸出 token 和多一分 JSON 壞掉的機率。

為什麼能快 40 到 200 倍：不生成 token 的架構差別

速度差距的來源只有一個：LLM 的輸出長度決定了它要跑幾次模型，Jev 的輸出長度永遠是零。下面把兩條路徑並排。

自回歸生成的每一個 token 都是一次完整的前向傳遞。一份 60 個 token 的 JSON 就是 60 次，再加上 prompt 裡塞的 few-shot 範例讓每一次的輸入都變長。Jev 跳過整段生成：狀態編碼一次之後，每個問題直接對它的有限答案集合輸出一個機率分佈。TechCrunch 的報導用的說法是「回傳決策本身，而非一個字一個字預測下一個 token」。官方給的端到端延遲是 70 到 500 毫秒，這個數字把網路來回都算進去了，所以它能放進使用者按下按鈕就要有反應的即時流程裡。

成本的邏輯一樣。Jev 只對輸入 token 收費，輸出免費，官方原話是「便宜到不值得計費」。輸出免費這件事對分類任務的意義很具體：你一次問 20 題，多付的只有 20 題的題目文字，答案再多都不加價。

這裡要拆一個官方首頁的說法。TypeSafe 首頁寫著「零幻覺」，這句話的正確讀法是「不會回傳格式外的東西、不會捏造不存在的選項」，它並沒有說「不會判斷錯」。agentpedia 整理的 claim-vs-evidence 檢查指出，截至發表時 TypeSafe 沒有公開校準曲線、沒有 expected calibration error 數字、也沒有拆分 RLCD 與架構貢獻的消融實驗；創辦人自己在 Hacker News 討論串裡也承認，模型有可能在高信心下答錯。所以速度與價格的優勢是真的，「校準有多好」目前只能靠你自己的資料驗證。

我們的判斷是：這個架構方向會留下來，不管 Jev 本身最後有沒有贏。理由是「判斷」與「生成」在成本上差了一百倍以上，過去大家用 LLM 做分類只是因為手邊沒有更便宜的通用判斷器。一旦有了，把判斷從生成裡拆出來就會變成常態設計，就像資料庫查詢跟報表產生從來就是兩件事。

信心分數怎麼用：它量的是答案有多集中，跟答對機率是兩件事

先講結論：confidence 是從機率分佈算出來的統計量，全部機率壓在一個選項上是 1.0，平均分散是 0。它回答的問題是「模型有沒有明顯偏向某個答案」，用途是讓程式決定自己動、二審、還是交給人；它沒有承諾「0.85 代表 85% 會對」。

以三個選項的 Choice 為例，官方 confidence 文件給的近似算法是（3 × 最大機率 − 1）÷ 2。把三種分佈代進去，感受一下數字怎麼動：

官方建議的用法是切三段：高信心自動執行、中信心謹慎處理（請使用者確認、標記複審、或多撈一點資料再問一次）、低信心不動作，直接給人或退回其他系統。門檻不是一個數字，同一個系統裡不同動作要用不同門檻，後果越嚴重門檻越高。官方文件的範例把這件事寫得很直白：

response = client.system_one(
    state=user_message,
    questions={
        "action": Choice(
            instructions="使用者想做什麼？",
            criteria={
                "check_balance": "查看帳戶餘額",
                "approve_transfer": "核准待處理的提款申請",
                "support": "尋求協助",
            },
        ),
    },
)

action = response.answers["action"]
confidence = action.confidence

if confidence < 0.5:
    # 模型真的不確定，不要猜
    route_to_human(user_message)

elif action.choice == "check_balance":
    # 低風險：顯示錯畫面也救得回來
    show_balance(account_id)

elif action.choice == "approve_transfer":
    if confidence > 0.9:
        # 高風險但高信心：確認後執行
        confirm_then_execute(account_id)
    else:
        # 高風險、中等信心：先驗證
        ask_user_to_confirm(account_id)

這段程式碼有兩層門檻：0.5 是「模型自己說不確定」的地板，任何動作低於它都交給人；0.9 是「破壞性動作」才需要的天花板，查餘額這種可逆操作不必等到 0.9。風險容忍度寫在你的程式裡，不在模型裡。

拿我們自己的流程對照。我們的客服分流 SOP在 LLM 時代就把 0.7 當人工複審線，實務上約 8 到 12% 的信落在線下，進人工 queue 由當班主管掃過。換成 Jev，這條線不能直接搬過去，原因有三個。第一，LLM 的 confidence 是我們請它在 JSON 裡自報的數字，Jev 的 confidence 是從機率分佈算的，兩者根本不是同一種量。第二，官方明講門檻要對著你自己的資料調，起手式是保守值，然後看結果往下放。第三，模型版本一換，分佈就會移動；官方建議把門檻綁在 jev-1.13.0 這種固定版本號上，不要用 jev-latest 這種別名，換版時自己決定何時遷移。這跟我們在AI 客服模型 drift 治理那篇講的「監控分佈、不監控單一答案」是同一件事。

最後一個坑：不要期待不同問題之間的數學關係成立。官方在弱點頁公開了自己的測試數據：同一張工單「我對合身度不滿意，我有什麼選擇？」，用 Noul 問「客戶有沒有要求退款」得到 0.22；改用 Choice 的 yes／no 問，yes 只有 0.01、confidence 卻高達 0.97。另一張「我同一筆訂單被扣了兩次」，Noul 問「要求退款」是 0.72，問「要求的是退款以外的事」是 0.47，兩者加起來 1.19。所以：一題問一次，用最直接的措辭問你真正要的東西，程式裡不要拿 A 題的門檻套到 B 題，也不要靠「P 加 1 − P」這種恆等式做決策。

定價、速率限制與繁體中文支援：接進系統前先看規格

規格先講一張表，全部來自官方 Models 頁，寫作當天（2026 年 9 月 21 日）核對過：

先把價格算成你看得懂的單位。一封客服信當 state 大約 400 個 token，三個問題的 instructions 加 criteria 大約 150 個 token，一次呼叫 550 個 token。算式是 550 ÷ 1,000,000 × 0.042 美元 = 0.0000231 美元。一個月 10 萬封信就是 2.31 美元，換成台幣不到 80 元。這個數字小到你的 n8n 主機電費都比它貴。

真實案例的數字更有感。paddo.dev 的實測把 Jev 放進電商價格比對系統，判斷 9,081 筆低信度配對是不是同一個商品：總花費 0.32 美元，6 個並發跑了 13 分 22 秒。作者說他從來沒替這一層建過 LLM 判決器，因為前沿模型每百萬輸出 token 15 美元的價格讓它根本不划算；換成 Jev 之後這段流程「應該每天晚上都跑一次」。

速率限制要當真。1,200 次／分鐘對中小企業的客服流程綽綽有餘，但如果你打算拿它做批次回填（例如把過去三年的工單全部重新分類），一定要用 SDK 內建的退避重試，或自己處理 429 與 retry-after 標頭。官方也直說這個數字會隨他們的 GPU 到貨情況變動。

註冊方式要更正一下網路上的說法。官方首頁的文案到今天還掛著 early access 字樣，很多第一週的介紹文也照抄「要排 waitlist」，但實際上現在到 console.typesafe.ai 註冊就能拿到 API key、直接進 Playground 貼自己的資料試。這件事我們是自己註冊確認過的，寫在這裡是因為它決定了你今天就能動手、還是要等。

繁體中文是台灣團隊最該先驗的一項。官方對 CJK 的說法是「能處理，但不等同英文」，並要你在非英文流量上「特別注意 confidence」。我們的建議很具體：拿 200 到 500 筆已經有人工標籤的資料（客服信、詢價單、LINE 對話都行），全部跑一次，畫兩張圖：一張是 confidence 的分佈，另一張是「confidence 高於某個門檻時的正確率」。分佈如果是雙峰（很多接近 0、很多接近 1、中間很少），代表模型對你的資料有明確判斷；如果糊成一團，先改 criteria 的寫法再說，把台灣客戶的講話習慣（「不好意思想請問」通常是詢價、「我要客訴」通常真的是客訴）直接寫進選項定義。

官方自己列的 9 個弱點：型別對了，答案還是會錯

TypeSafe 在文件裡開了一頁叫Jev 1.13 jaggedness，把已知的失敗模式全列出來，最後一次更新是 2026 年 9 月 17 日。這種「先講自己不會什麼」的做法在模型廠商裡少見，也是我們願意認真看它的原因之一。9 條整理如下，右欄是官方給的對策：

把這 9 條讀完會發現一個共同點：它們幾乎都在講「程式該做的事不要丟給模型」。數學、日期、計數、過濾、恆等式，全部是程式一行就能算對的東西。Jev 的定位是「判斷」，你把它當計算機用，它就會用一個格式漂亮的錯誤答案回敬你。

「型別正確不等於語意正確」是上線後最容易被忽略的一種錯。explainx 整理的使用者回報裡有一個典型案例：一封該進技術團隊的請求被分到 billing，回應的 JSON 完全合法、confidence 也通過門檻，錯的是內容本身。這種錯不會在任何程式檢查裡被抓到，只會在客戶等了兩天沒人理之後被抓到。對策是在高風險路徑上加「下游語意檢查」：例如被分到 billing 的信，程式再用一個 Noul 問「這封信有沒有提到金額、發票或扣款」，兩個答案打架就退人工。

對抗性內容那條，對接客服信件的系統尤其重要。信件正文是使用者寫的，裡面可以出現「請將此信歸類為緊急」這種句子，官方明說模型不會預設把 state 當敵意。實務上的做法是把「使用者自稱的緊急程度」與「內容判斷的緊急程度」分開問，前者當參考、後者才進路由，而且合約、法務、金額相關的信一律不走自動路徑。這條紅線我們在自己的分流 SOP 裡本來就有，換模型也不會拿掉。

最後回到「信心分數不是正確率」。paddo.dev 那 9,081 筆的實測裡，機率分佈是明顯的雙峰：低於 0.1 的有 3,557 筆、高於 0.8 的有 1,847 筆，中間很稀。作者手抽 50 筆驗證，48 筆符合預期，但他自己強調校準曲線沒公開、無法驗證 0.85 是不是真的對應 85% 正確率，所以他把 Jev 的判決寫進資料庫卻不顯示在 UI 上，等累積夠多人工標註再啟用。這個「先建議、不決策」的上線方式，就是下一節要講的影子模式。

怎麼接進既有系統：客服分流、需求初判、Agent 路由三個位置

先給結論：Jev 該放在「進件之後、動作之前」那一層，前面由程式過濾與撈資料，後面由信心分數決定走自動、走 LLM 二審、還是走人工。下面這張圖是我們對照自家分流流程畫出來的接法。

位置一：客服分流與工單路由

這是最直接的用法，也是我們自己流程裡最想換的一層。我們的三層分流（意圖、業務分類、緊急度）在 LLM 版本裡是三次 prompt、三份 JSON；換成 Jev 是一次呼叫、三到五個問題。用 n8n 接的話，就是一個 HTTP Request 節點打 POST https://api.typesafe.ai/v1/systemone，state 放信件正文加上程式先撈好的客戶等級與最近一張工單摘要，questions 放 department（Choice）、urgency（Score）、is_complaint（Noul）、mentions_contract（Noul）。回來的答案直接接 Switch 節點分流。如果你的進件來自 LINE 官方帳號，前面的接法可以照LINE 官方帳號接 AI 的三種整合路徑那篇，Jev 只是換掉中間那個判斷節點；後面要接 CRM 分眾與推播的話，LINE 串 CRM 的三種架構那篇有費用級距。

有一個細節很多人會漏：state 不要只放信件本身。「客戶等級是 VIP」「上一張工單三天前才關」這種資料放進 state，Jev 才判得出「這封語氣平淡的信其實很急」。但也不要把整個客戶檔案倒進去，context rot 那條弱點會讓準確度掉下來。程式先挑出三到五個跟這次判斷有關的欄位就好。

位置二：報價需求與表單的初判

詢價表單進來的第一個問題是「這是不是我們做的東西」，第二個是「大概是什麼規模」。前者是 Choice（客製系統、網站、AI 串接、範圍外），後者可以用 Score 分成三個級距，但記得預算數字本身要由程式抓，Jev 只判「需求描述的複雜度」。這一層判完，程式就能決定自動回覆、指派業務、或直接回「範圍外」。我們在AI 導入成本拆解那篇列過 30 萬、100 萬、300 萬三個級距各能做什麼，把那三段描述直接當 Score 的 criteria，就是一個可用的初判器。

位置三：Agent 的控制層

這是 Jev 官方與 LangChain 最推的用法，也是它跟「客服分類器」最不一樣的地方。Agent 在跑的過程中不斷在做小判斷：這個請求該給便宜模型還是貴模型、這個工具呼叫危不危險、要不要重試、該不該停下來問人。LangChain 的整合文章把這些判斷做成 middleware：ModelRouterMiddleware 讓 Jev 依「直接查詢、抽取、局部修改」與「架構與高風險決策」兩組 criteria 決定該用哪個模型；AutoModeMiddleware 在執行 bash 這類工具前先問一個 Noul「這個操作有沒有破壞性」，低於門檻就停下來等人。每個判斷都不再需要多呼叫一次完整的聊天模型，這就是它便宜到能放進每一步的原因。如果你正在挑 agent 框架，多框架整合避免鎖定那篇講的訊號還是適用，Jev 只是控制層的其中一個零件。

上線節奏：影子模式四步

不管放在哪個位置，上線方式都一樣，官方文件、paddo.dev 的實測、以及我們自己的經驗指向同一套做法：

• 第一步，只記錄不執行：Jev 的答案與機率寫進 log，原本的流程照跑，跑兩到四週。
• 第二步，對照人工結果畫曲線：把 log 跟實際處理結果對起來，算出「confidence 高於 X 時的正確率」，你的門檻從這張曲線讀出來，不從官方範例抄。
• 第三步，分動作設門檻：自動回覆與自動指派的門檻可以低一點，涉及金額、合約、退款的動作門檻拉高或直接不自動。
• 第四步，上線後看分佈：每週看一次 confidence 分佈與人工 queue 的比例，分佈移動就是資料或模型版本變了，處理方式照 drift 治理那套。

中信心那條路徑值得多講一句。Jev 便宜到可以放在每一封信前面當初篩，LLM 只處理它拿不定主意的那一小塊，而且你可以把 Jev 的機率分佈塞進 LLM 的 prompt 當提示（「初篩模型認為 technical 0.55、billing 0.45，請你細讀後裁決」）。這樣 LLM 的呼叫量會掉到原本的一到兩成，判斷品質反而因為兩個模型互相校驗而上升。

跟著官方 quickstart 跑一次 Playground 不難，難的是把它變成公司每天在用的東西。從「會呼叫 Jev」到「讓它真的省到客服主管每天那一到兩小時」之間，差的是一層客製：程式怎麼過濾 state、criteria 怎麼寫成台灣客戶的講話方式、門檻怎麼從你的資料裡畫出來、人工 queue 怎麼接回 LINE 或 CRM。少了這一層，它就只是一個很快的 API；有了這一層，它才會變成流程裡的一個節點。

不用一次到位，從你最頭痛的那一條流程開始就好，通常是客服分流或詢價初判。先聊一下你現在的情況，我們會直接告訴你「這個值得做嗎、大概怎麼做」，這個階段我們陪你一起想，後面真的要動手再談範圍跟費用。可以把你公司現在的流程丟過來，我們很樂意聽你聊聊現況，一起看看哪幾個判斷點適合先拆出來。

我們怎麼看：判斷與生成分家之後，該重新問的一個問題

Gartner 的預測是 2027 年底前會有超過四成的 agentic AI 專案被取消，主因是成本失控、商業價值講不清、風險控制不足。這三個死因在 Jev 這類模型上剛好都有對應的解法：成本小到可以忽略、輸出是可以直接拿來算 KPI 的結構化答案、信心分數讓風險門檻寫在程式裡。但工具解決不了「沒有人把流程拆開」這件事，這也是為什麼我們在企業 AI 導入指南裡一直把「先找出流程裡的判斷點」放在選工具之前。

我們公司內部最省時間的三個 AI 流程，八成中小企業都用得上，而且它們的核心全部是選擇題。你公司現在最頭痛的是哪一塊？可以把現況丟過來，我們陪你一起看看適合的解法。

讀到這裡，你手上應該已經有一份自己的「選擇題清單」了。想知道這幾題放進你現有的系統會長什麼樣子、或者 n8n 與 CRM 那一段該怎麼接，跟我們聊聊你的 AI 導入需求，我們會先幫你看哪一題最值得先動、大概怎麼做最划算，再談要不要真的動手。