TL;DR
Jev 是由 TypeSafe AI 開發的決策模型。TypeSafe 於 2026 年 9 月 15 日推出 Jev,作為其首個 System One 模型,專為返回可直接被軟體使用的結構化決策與機率而設計。本指南主要基於 TypeSafe 的官方文件、快速上手指南、模型參考,以及公司對 Jev 的官方公告。
Jev 不撰寫長文、不生成程式碼,也不進行對話。它會針對文字狀態評估已定型別的問題,並返回可被應用程式直接使用的結構化答案。
這種區別對軟體工作流程至關重要。傳統大型語言模型會輸出連續代碼(tokens),即使應用程式只需要一個類別、一個分數,或是是/否判斷。Jev 以「決策」為中心設計。其介面接受一個 state 與一個或多個問題,然後返回具型別的值與機率分佈。對於 Choice 與 Score 類型的答案,還會提供信心值。
Jev 用於分類、路由、評分、驗證、守護欄(guardrails)及其他邊界明確的決策。它不是 GPT、Claude、Gemini 或其他生成式模型的一般替代品。在一個 AI agent 中,生成式模型可用於規劃或創作內容,而 Jev 處理高頻的決策,例如選擇路由、檢查風險,或判斷結果是否需要複核。
Key Takeaways
- Jev 由 TypeSafe 開發,並以其旗艦 System One 模型呈現。
- 該模型接受文字型 state 與具型別的問題,返回的是結構化決策,而非生成長文。
- Jev 支援三種問題型別:Choice、Score、Noul。
- 在單一請求中可對同一 state 獨立且並行地評估多個問題。
- TypeSafe 以 RLCD(Reinforcement Learning for Calibrated Decisions)訓練 Jev。
- 官方模型頁目前列出 Jev 1.13,請求上限為 64,000 個 token,僅支援文字輸入。
- 官方定價為每百萬輸入 token $0.042。輸出 token 標示為免費。
- 型別安全的輸出可防止綱要(schema)不匹配;但不保證每個業務決策都正確。
- TypeSafe 報告的延遲在 70 至 500 毫秒,以及其自身工作流程評估中的大幅提升。這些數據為廠商報告,且適用於 System One 形狀的任務。
What Is Jev?
Jev 是 TypeSafe AI 打造的決策模型。官方文件將其描述為公司的旗艦模型與首個 System One 模型。其輸入主要由兩部分構成。
第一部分是 state。state 是 Jev 應檢視的資訊,例如客戶訊息、事故報告、資料集合,或包含應用程式情境的 JSON 物件。
第二部分是一組具型別的問題。每個問題定義要做的判斷與允許的答案形式。Jev 會針對該 state 評估問題並返回結果,供程式用於分支、排序、評分或路由。
考慮一個支援請求,描述支付整合已故障三天。支援系統可能不需要一段描述情況的段落,而是需要三個窄化的決策:
- 該工單應指派給哪個團隊?
- 客戶顯示多大程度的挫折?
- 這則訊息是否需要緊急關注?
Jev 可在一次請求中將這些分別表示為一個 Choice、一个 Score 與一個 Noul 問題。回應包含所選分類或分數、相關機率分佈,以及在支援的情況下提供信心值。應用程式再依據這些值決定後續動作。
這樣的責任分工是刻意設計的。模型以穩定格式提供帶有不確定性的判斷。應用程式端保留對閾值、權限、副作用與回退行為的控制。
What Is a System One Model?
TypeSafe 將 System One 模型用於描述一類能做出快速、結構化決策且可被軟體消費的模型。這個名稱源於丹尼爾・卡尼曼(Daniel Kahneman)關於快思與慢想的區分。它描述的是模型的預期角色,而非宣稱軟體模型再現人類認知。
一個 System One 任務具有受限的目標。當提供足夠上下文時,知情的審查者應能快速做出判斷。範例包括選擇意圖、在定義量表上評定緊急性、檢查某主張是否被支持,或判定某請求是否應升級處理。
需要延展研究、多步推理、長篇解釋或內容創作的任務並不自然適配。TypeSafe 建議將廣泛的判斷拆解為原子問題,並在程式碼中合併其結果。
例如,「評分這個新創提案」過於寬泛,不利於產出可檢視的決策。可改以市場規模、技術可行性與差異化作為分離問題來評估。應用程式可用明確公式合併這些分數。若業務優先順序改變,可在程式碼中更改權重,而非讓模型提示變成隱性的業務邏輯。
How Does Jev Work?
Jev 的運作契約可寫為:
State + typed questions -> typed decisions + probabilities
這有別於常見的語言模型流程:
Prompt -> generated tokens -> parsing and validation -> application decision
差異不只是回應格式不同。傳統的結構化輸出仍是要求生成式模型產生符合綱要的 token 序列。Jev 旨在從預先定義的答案空間返回值。
目前的 API 接受 string、JSON 物件或文字陣列作為 state。輸入僅為文字。圖像、音訊、視訊與二進位文件必須先轉為文字或結構化欄位再提交。
單一請求中的每個問題都會獨立針對相同的 state 評估。依據 TypeSafe 的文件,新增問題幾乎不改變回應時間,因為問題是並行評估的。獨立性也防止同一呼叫中某個問題的答案成為另一個問題的上下文。
此行為帶來重要的設計後果。若一個決策確實依賴於另一個決策,依賴關係應放在應用程式工作流程中。先執行第一次評估,更新 state 或在程式碼中分支,然後再執行下一次評估。單一請求最適合共享證據但彼此答案不相互依賴的問題。
The Three Jev Question Types
Jev 提供三個原語,每一種對應不同的軟體決策。
| 問題類型 | 目的 | 返回 | 適用範例 |
|---|---|---|---|
| Choice | 從定義集合中選擇一個選項 | 所選選項、各選項機率、信心值 | 意圖分類、團隊路由、模型選擇 |
| Score | 依據有序量表對 state 進行評定 | 分數、各層級機率、信心值 | 緊急性、品質、風險、購買意圖 |
| Noul | 估計某陳述為真的可能性 | 介於 0 到 1 的數值 | 政策檢查、完成度檢查、二元資格判斷 |
Choice
Choice 問題會從應用程式定義的選項中選擇一個。支援工作流程可能提供 billing、technical、sales,並為每個類別提供描述。Jev 返回所選選項、為每個選項分配的機率,以及由該分佈形狀導出的信心值。
類別設計會影響結果的實用性。重疊的選項會造成歧義。缺失的選項會迫使模型選擇可能不合適的答案。生產用分類法在需要保留不確定性的情況下,應包含例如 insufficient_evidence 或 human_review 的路由。
措辭也應匹配實際決策。哪個團隊應先行調查是在詢問暫定路由;哪個團隊導致故障則是在尋求診斷。它們也許使用相同的團隊清單,但並非在問同一個問題。
Score
Score 問題將 state 放在有序量表上。其標準可描述如冷靜、沮喪、憤怒等層級,或定義更細緻的商務量表。回應包含數值分數、將數字與層級對應的對照表、各層級的機率分佈,以及信心值。
有用的 Score 量表應描述可觀察的差異。僅有標籤而缺乏定義,會讓模型與人類審查者各自推斷不同的標準。風險量表應說明各層級的分野;品質量表應說明存在哪些要求或缺少哪些要件。
若一個分數混合了彼此獨立的面向,拆分為多個問題更好。相關性、事實支持、語氣與政策遵循可分別提問。應用程式可用可見且可測試的權重計算合成分數。
Noul
Noul 是 TypeSafe 的二元決策原語。它估計某陳述為真的機率,並返回 0 到 1 的數值。0.9 表示相比 0.6 對該陳述為真具更高的估計機率。
Noul 不返回像 Choice 與 Score 所使用的獨立 confidence 欄位。其輸出本身就是對被評估陳述為真的機率。因此問題應寫成可測試的陳述,例如「訊息傳達了緊迫性」或「答案受提供的來源支持」。
Noul 適合用於驗證與閘控,但閾值屬於應用程式決策。低風險的介面建議可容忍較低閾值,而不可逆的財務或行政操作則需要更高的門檻。
Atomic Questions and Composed Workflows
當每個問題只問一件窄化的事情時,Jev 表現最佳。此設計使輸出更易檢視,並讓軟體保有最終策略的主導權。
假設一個 agent 需要決定是否執行工具呼叫。像「是否應執行此動作」這樣的廣泛問題可能混合了許可、可逆性、資料敏感度、使用者意圖與作業風險。更可檢視的工作流程可分別評估這些面向:
- 工具呼叫是否與使用者的請求一致?
- 是否會傳送敏感資訊?
- 此動作是否具破壞性或難以回復?
- 是否影響外部帳戶?
- 是否依政策需要額外確認?
接著,控制程式可用確定性規則合併答案。具破壞性的操作可在任何情況下都要求確認;唯讀操作則可走較寬鬆的路徑。此安排讓許可留在程式碼中,只將無法可靠以固定規則表達的判斷交給 Jev。
Jev vs Traditional LLMs
Jev 與大型語言模型扮演不同角色。
| 面向 | Jev | 傳統 LLM |
|---|---|---|
| 主要輸出 | 具型別的決策與機率 | 生成文字、程式碼或結構化 token |
| 答案空間 | 推論前即定義 | 非受限,除非被約束 |
| 取樣方式 | 問題並行評估 | token 逐序生成 |
| 自然工作負載 | 分類、路由、評分、驗證 | 對話、推理、寫作、編碼 |
| 不確定性 | 機率分佈;Choice 與 Score 提供信心值 | 視提供者與方法而定 |
| 綱要行為 | 輸出符合支援的問題型別 | 結構化輸出需依賴受綱要約束的生成 |
| 最佳系統角色 | 軟體中的決策層 | 規劃與生成層 |
Jev 不應被描述為較小的聊天機器人。TypeSafe 未公布參數規模或足以按大小分類的架構細節。其公開區別在於訓練目標、取樣方法與介面。
Jev 也不取代確定性程式碼。當條件明確且穩定時,固定規則仍是合適工具。稅務計算、權限名單或檔案大小限制不應變成一個機率模型呼叫。當手寫規則過於脆弱,但期望答案仍可被界定時,Jev 才派上用場。
Jev vs Structured LLM Output
結構化輸出讓語言模型返回符合綱要的 JSON 或值。當工作流程既需要生成式推理又需要機器可讀的結果時,它很有價值。Jev 則針對更窄的問題。
對 LLM 而言,綱要約束的是生成回應的形式。對 Jev 而言,問題與答案空間就是模型介面。Jev 返回旨在參與應用程式邏輯的機率分佈,且獨立問題會針對共享的 state 分別評估。
JSON 形狀相同不代表行為相同。兩個系統都可能返回名為 department 的欄位,但在延遲、校準、歧義處理與回應穩定性上存在差異。比較 Jev 與結構化 LLM 輸出時,團隊應保持應用程式綱要不變,並在相同帶標記資料上測試兩個系統。
RLCD and Calibrated Decisions
TypeSafe 表示 Jev 以 RLCD(Reinforcement Learning for Calibrated Decisions)訓練。RLCD 的目標不同於 RLHF 與 RLVR。
RLHF 使用人類偏好訊號優化回應,廣泛用於對話型助理。RLVR 使用可驗證的回饋,常見於可程式化檢驗正確性的任務。RLCD 則訓練 TypeSafe 的模型返回決策與校準的機率,而非生成文字。
校準關注的是一組預測。若模型校準良好,對某集合的案例而言,被賦予約 0.8 機率的事件,應約有 80% 的時間正確。這不保證特定一次 0.8 機率的預測必然正確。
機率與信心不應被視為可互換。Choice 與 Score 會暴露完整機率分佈。TypeSafe 從每個分佈的形狀導出信心值。分佈集中於單一選項會產生較高信心;較平坦的分佈則表示歧義。團隊可使用提供的信心值,或基於機率自行計算其他統計量。
Noul 沒有獨立的信心欄位。其值即為所評估陳述為真的估計機率。
Jev Model Specifications and Pricing
以下細節來自 2026 年 9 月 21 日查閱的 TypeSafe 官方模型文件。
| 項目 | 官方文件記載的值 |
|---|---|
| 當前穩定模型 | Jev 1.13 |
| 版本化模型 ID | jev-1.13.0 |
| 穩定別名 | jev-latest |
| 輸入 | 文字;string、JSON 物件或文字陣列 |
| 請求上下文上限 | state 與所有問題合計 64,000 個 token |
| 額外上下文規則 | state 加上最長問題合計 32,000 個 token |
| 輸入價格 | 每百萬 token $0.042,或每十億 token $42 |
| 輸出價格 | 免費 |
| 公布的速率限制 | 每秒 250,000 token、每分鐘 1,200 次請求 |
| 主要訓練語言 | English |
| 非文字輸入 | 目前不直接支援 |
TypeSafe 指出速率限制正動態調整,可能不另行通知而變更。生產部署前應再次確認當前限制與價格。
文件亦指出 English 為主要訓練語言,目前提供最佳準確度。其他語言(包含 CJK 文字)也受支援,但效果不一。中文、日文或韓文工作負載在自動化決策前應以具代表性的資料進行評估。
TypeSafe 表示 Jev 不會針對每位客戶的資料進行微調或 LoRA 調適;所有帳戶共享相同模型權重。領域行為透過 state、指示、標準與應用程式端的組合來塑形。公司亦表示客戶的請求與回應不會用於訓練 Jev。企業客戶可參考 TypeSafe 的法律文件以取得零資料保留條款。
How Fast Is Jev?
TypeSafe 報告端到端回應時間介於 70 至 500 毫秒。其發佈文章將此區間與部分前沿模型呼叫的 3 至 329 秒相比,並描述 Jev 在可比智慧水平下對 System One 形狀的查詢快 40 至 200 倍。
公司還報告在其工作流程評估中,速度峰值提升 193.6 倍、成本峰值下降 444.6 倍。這些數據需要置於脈絡中理解。
它們來自 TypeSafe 自身的評估框架。這些工作流程在結構化決策圖上比較模型,並以選定高端外部模型的平均預測作為參考機率。TypeSafe 表示所報告的提升可能接近真實世界改善的高端,並承認因模型能力團隊成員製作工作流程而可能存在偏差。
不應將這些結果理解為一般宣稱 Jev 在所有任務上都比每個 LLM 快數百倍。Jev 放棄了文字生成,並瞄準受限決策。公平的比較應使用兩者都能執行的任務,既測量決策品質亦衡量延遲,並包含驗證、重試與人工審查的成本。
What Is Jev Best for
Jev 最適合答案空間已定義且需要不確定性估計的高量工作流程。
- 客服分流:按部門、緊急性、挫折感、流失風險或是否需要人工審查進行分類。
- 意圖與模型路由:識別請求類型並路由至適當的工具、工作流程、agent 或模型。信心值可決定是否自動路由。
- Agent 工具風險檢查:在執行前評估建議的工具呼叫是否具破壞性、包含敏感資料,或與使用者請求不一致。應用程式依然負責權限。
- LLM 輸出評估:檢查 LLM 回應是否受提供的上下文支持、是否遵循所需格式,或是否需要人工審查。
- 內容審核:使用 Choice 做政策類別、Score 做嚴重度、Noul 做二元規則檢查。低信心案例可送交審核員。
- 高量資料處理:處理日誌、電子郵件、評論、潛在客戶、廣告或文件片段,只要每筆紀錄可獨立評估,且輸出為類別、分數或機率。
Where Jev Fits in an AI Agent
一個 AI agent 通常結合生成式模型、工具、應用程式 state 與控制執行的規則。Jev 作為結構化決策層,圍繞主要生成式模型運作。
生成式模型可處理開放式任務,例如理解請求、規劃工作流程、撰寫內容或生成程式碼。Jev 則處理工作流程中需頻繁發生的較窄決策:
- 應使用哪個工具或模型?
- 建議的操作是否有風險或與請求不一致?
- agent 應繼續、重試、停止,或要求澄清?
- 結果是否符合定義的要求?
- 是否應將任務升級給人工?
應用程式仍負責許可、閾值與副作用。Jev 提供決策及其相關機率,而應用程式程式碼決定接下來的動作。
這形成責任分工。生成式模型處理開放式推理,Jev 處理受限評估,確定性程式碼執行政策,工具負責外部操作。因此,Jev 是 AI agent 的補充,而非取代其主要推理模型。
Limitations of Jev
Jev 不生成長文、程式碼或開放式解釋。它設計用於答案空間已定義的聚焦問題。
型別安全的回應仍可能包含不正確的決策,因此必須用真實資料評估業務準確性。目前僅支援文字輸入,且 English 的表現最強。其他語言需要另行測試。
Jev 的速度與成本結果來自 TypeSafe 自身評估,不應視為普遍的效能保證。
Jev and CometAPI
截至 2026 年 9 月 21 日,Jev 尚未列為 CometAPI 公開目錄中的一般可用模型。CometAPI 計畫在可取得存取與開放必要連線後,評估並整合 Jev。開發者應查閱 CometAPI 模型目錄以取得最新可用性。
目前可透過 TypeSafe 控制台與其官方 API 使用 Jev。TypeSafe 亦提供官方 Python 與 JavaScript SDK。當前 API 使用 state 與具型別的 questions,jev-latest 作為穩定模型別名。
一旦 Jev 可透過 CometAPI 使用,開發者即可在CometAPI API 文件與模型目錄中找到其模型 ID、支援的端點、定價與請求格式。
Frequently Asked Questions
What is Jev AI?
Jev 是 TypeSafe 的旗艦模型與首個 System One 模型。它針對文字型 state 評估具型別的問題,返回結構化決策與機率,而非生成文字。
Is Jev a large language model?
TypeSafe 並未將 Jev 呈現為傳統 LLM。公司稱 Jev 為用於結構化決策的 System One 模型。其未公開參數規模,因此不應依公開資訊將其按大小分類。
What are Choice, Score, and Noul?
Choice 從定義集合中選擇一個選項並返回機率與信心值。Score 依有序量表評定 state,亦返回機率與信心值。Noul 返回 0 至 1 的數值,表示被評估陳述為真的機率。
Does Jev generate text or code?
不會。Jev 返回受限的決策。當工作流程需要長文、對話、原始碼或開放式解釋時,需要生成式模型。
Can Jev replace GPT, Claude, or Gemini?
不行。Jev 處理受限決策任務,而通用 LLM 處理生成與延展推理。生產系統可在同一工作流程的不同階段同時使用兩類模型。
Does Jev support images, audio, or video?
不直接支援。當前模型接受文字作為 string、JSON 物件或文字陣列。非文字輸入必須先轉為文字或結構化欄位。
Does type-safe output guarantee a correct decision?
不保證。型別安全僅保證輸出符合支援的結構。Jev 仍可能選錯有效選項或分配不準確的機率。必須以具代表性的資料衡量業務準確性。
Is Jev open source?
TypeSafe 尚未公開 Jev 的模型權重。公司發布文件、SDK、範例與相關整合程式碼,但這些資源本身不構成開放權重。
Conclusion
Jev 引入一種以「決策」而非語言生成為核心的模型介面。它接受共享的 state 與原子、具型別的問題,然後返回類別、分數、二元機率與可供軟體直接使用的不確定性量測。
其最可信的角色不是取代通用 LLM,而是負責圍繞其周邊的高頻、受限判斷。客服路由、模型選擇、工具風險檢查、輸出驗證、審核與工作流程分類,在答案空間預先定義的情況下,都符合此模式。
生產價值不僅取決於低延遲或有效綱要。團隊需要具代表性的評估、校準的閾值、明確的許可規則、模型版本控管與人工審查路徑。TypeSafe 公佈的速度與成本數據讓 Jev 值得在決策密集的工作負載中測試,但這些主張仍取決於其評估方法,應在真實應用資料上驗證。
對已透過 CometAPI 使用多個生成式模型的團隊而言,Jev 展現一種更廣的架構:生成、機率判斷、確定性政策與工具執行為相互獨立的元件。這種分離讓每一部分更易測試,並讓應用程式程式碼對接下來的動作保有最終控制權。
