Jev 是什麼？System One 模型的用途、限制與成本

Jev 回傳的是判斷，不是文字#

TypeSafe API 目前提供三種問題型別：

一次 API 呼叫可以放進多個彼此獨立的問題。Jev 會以相同 state 平行評估，程式再依結果決定要直接執行、要求人工確認，或把案例交給較強的推理模型。

1
使用者輸入
2
    ↓
3
Jev：意圖、風險、是否需要推理
4
    ↓
5
程式依門檻分流
6
    ├─ 明確、低風險 → 固定程式流程
7
    ├─ 不確定 → 要求補充資料或人工審核
8
    └─ 複雜問題 → Codex／其他推理模型

這種設計和一般 JSON mode 不完全相同。JSON mode 仍由生成式模型逐字產生內容，再由程式驗證；Jev 的答案空間則在請求中先被限定。不過「輸出格式不會亂掉」只代表介面穩定，不代表判斷必然正確。

哪些工作適合交給 Jev#

最合適的任務通常同時符合三個條件：答案空間有限、判斷範圍窄、程式知道拿到答案後要做什麼。

例如客服工單可以同時判斷處理部門、緊急度與是否要求退款；搜尋流程可以先替候選段落評估相關性；Agent 也能先判斷下一步應呼叫哪個工具。這些工作都不需要一段寫給人看的文字，只需要一個能被程式消化的訊號。

反過來說，下列工作不該硬塞給 Jev：

• 產生文章、程式碼或自然語言解釋。
• 多步驟規劃，且後一步依賴前一步推理結果。
• 精確計算、計數與日期先後比較。
• 答案事先無法列舉，也沒有候選值可供選擇。
• 必須從大量無關內容中自行找出關鍵線索的任務。

TypeSafe 的已知限制頁面也提醒，Jev 1.13 對數字、日期、間接指令、矛盾條件及對抗性內容較不可靠；state 塞入太多無關資料也會降低準確率。該由程式計算的值，仍應留在程式裡。

速度與成本數字要怎麼看#

Jev 1.13 的官方價格是每百萬輸入 Token 0.042 美元，輸出不計費；API context 上限為 64K，但 state 加上最長問題另有 32K 限制。官方目前列出的 rate limit 是每秒 25 萬 Token、每分鐘 1,200 個請求，而且註明限制仍可能動態調整。

TypeSafe 首頁展示的 193.6 倍速度與 444.6 倍成本差距，來自自家設計的 System One workflow 評測。官方發布文章也主動補充：短而密集的輸入對 Jev 有利，測試由自家模型能力團隊設計，193.6／444.6 倍應視為實際收益的高端案例。

因此，這些數字可以證明「封閉式、平行的小判斷有機會比生成式模型便宜很多」，不能改寫成「任何 AI 任務都會快 200 倍」。像 jev-ultrafast 的 Google Flights 展示確實完成約 7.1 秒的瀏覽器流程，但其六次交替測試只涵蓋同一任務，和舊版相比的中位時間改善約為 25%。

信心值不能直接當成正確率#

Choice 與 Score 的 confidence 是從各選項的機率分布濃度計算而來。答案集中在一個選項時較高，分散在多個選項時較低；Noul 則沒有另一個獨立信心欄位。

這個值適合拿來設計分流，但門檻應以自己的資料驗證。高信心仍可能答錯，低信心也可能只是兩個選項都合理。較安全的流程是先收集實際標註資料，再分別觀察：

• 不同信心區間的正確率。
• 錯誤分類造成的代價。
• 哪些案例應交給人工或推理模型。
• 模型版本更新後，原本門檻是否仍成立。

若只是想選最大機率的分類，不一定需要門檻；只有當「不確定時要走另一條路」時，信心分流才有實際作用。

中文工作負載要另外測#

TypeSafe 文件明確寫出英文是 Jev 的主要訓練語言，CJK 雖可處理，但表現不一致。準備用在繁體中文客服、文章分類或 Agent 路由時，不能直接沿用英文展示的準確率與門檻。

最小評估可以先整理 100 到 300 筆真實但去識別化的中文案例，固定問題與選項，記錄正確答案、Jev 機率與處理時間。先在 shadow mode 只記錄、不控制正式流程，等錯誤類型與門檻穩定後再逐步開放自動處理。

如果你已經確定問題適合 Jev，下一步可參考 Jev TypeScript API 教學；若目標是接到 coding agent，先看 Jev 接入 Codex 真的能省 Token 嗎？。想把模型留在本機，則可比較 Laya 開源 System One 模型。

常見問題#