Jev 是 TypeSafe AI 的首個 System One 模型，為需要結構化決策而非生成散文的應用而設計。它會根據明確定義的問題評估所提供的資訊，並返回具型別的答案、機率分佈，以及（如適用）信心分數。

不同於傳統大型語言模型，Jev 並非用於聊天、撰寫程式碼或創作長篇內容。其目的在於做出可被軟體立即使用的邊界化判斷，用於分類、路由、評分、驗證、優先級排序與流程控制。

模型資訊於 2026 年 9 月 21 日審閱。

Jev 技術規格

價格、別名與速率限制可能變更。開發者在將工作負載投入生產前應驗證最新資訊。

什麼是 Jev？

Jev 是由 TypeSafe AI 開發的決策模型。它不是生成開放式的 token 序列，而是從開發者定義的答案空間中選擇值。

一個 Jev 請求包含兩個主要組成：

• 具有狀態：模型應評估的資訊，例如支援工單、交易紀錄、代理行為追蹤、產品描述，或 JSON 格式的應用程式狀態。
• 問題：針對該狀態需要做出的判斷之具型別定義。

產生的答案旨在由軟體直接使用。應用程式可以依所選類別分支、比較分數、檢視機率、套用信心門檻，或將不確定案例送交人工審查。

因此，Jev 充當應用資料與決定性商業邏輯之間的機率式決策層。它處理難以用固定規則表達的判斷，同時讓應用程式代碼保有對門檻、權限與動作的控制。

Jev 如何運作

三種決策基本類型

Jev 支援三種問題類型，針對不同的軟體決策需求而設計。

Choice 從預先定義的集合中選擇一個選項。適用於意圖分類、工單路由、政策分類與模型選擇等任務。回應包含選定選項、各選項的機率，以及一個信心分數。

Score 依有序量表評估狀態。可衡量緊急程度、風險、關聯性、挫折感或內容品質等特性。回應包含一個分數、各量表等級的機率，以及一個信心分數。

Noul 估計某敘述為真的機率。回傳 0 到 1 之間的值，適用於驗證、政策檢查、資格判定與完成門檻。與 Choice 與 Score 不同，Noul 不另行返回信心欄位，因其輸出本身即為機率。

平行問題評估

單一請求可同時包含多個 Choice、Score 與 Noul 問題。Jev 會在相同的狀態上獨立且並行地評估它們。

例如，支援平台可以在一次請求中對工單進行分類、評估其緊急程度，並估計是否需要人工升級。TypeSafe 表示，加入彼此獨立的問題對回應時間影響很小。

同一請求中的問題不能相互依賴彼此的答案。序列式決策應透過由應用邏輯串接的多次呼叫來實作。

型別安全的回應

Jev 的可能回應結構會在推理前定義。這可避免在需要類別或數值的位置出現格式錯誤的 JSON、非預期欄位或解釋性文字。

型別安全僅保證回應格式。Jev 仍可能返回格式正確但決策不正確的結果，因此生產團隊必須使用具代表性的資料來評估其準確度。

顯式機率與信心

Choice 與 Score 會揭露每個答案背後的機率分佈。它們的信心值總結了該分佈對某一結果偏好的強度。

應用程式可利用信心值來自動化明確的決策、在不確定性中等時請求確認，並將模糊案例路由給人工或後備模型。

適當的門檻取決於風險。為工單加上標籤能容忍較高的不確定性；批准交易或執行不可逆動作則需要更高的把關。

低延遲推理

TypeSafe 回報端到端回應時間約為 70 到 500 毫秒。這使 Jev 適用於互動式路由、重複的代理檢查，以及其他決策密集但使用較慢生成式模型可能影響回應性的工作流程。

實際延遲取決於狀態大小、服務負載、網路條件與部署區域。

請求層級的自訂

Jev 不透過帳戶特定的微調或 LoRA 轉接器來自訂。開發者透過提供相關狀態、撰寫精確指示、定義明確準則，並在應用程式代碼中組合原子化決策來進行調適。

此作法可讓商業規則保持可見，並使團隊在不重新訓練模型的情況下調整工作流程邏輯。

版本化模型與穩定別名

TypeSafe 提供固定的模型 ID 與可移動的別名。jev-1.13.0 代表特定版本，而 jev-latest 指向最新穩定版。jev-preview 在有預覽版可用時可能移動到更新的預覽版本。

別名簡化了試驗，但其行為在更新後可能變化。以校準門檻部署於生產的應用應固定至已測試的版本，並記錄每個回應所返回的模型 ID。

Jev 的基準效能

Jev 並非為著重寫作、編碼、數學推導或長篇推理的一般用途基準而設計。更相關的衡量包括決策品質、機率校準、延遲、成本與輸出可靠性。

TypeSafe 報告：

• 端到端回應時間為 70–500 毫秒
• 在可比的 System One 任務上約快 40–200×
• 工作流程峰值結果達到 193.6× 的速度提升
• 成本峰值改善達 444.6×

以上為供應商回報結果，不應視為普遍的效能保證。TypeSafe 的工作流程評估在結構化決策圖上比較模型，並以選定高端外部模型的平均預測作為參考機率。

TypeSafe 亦承認，其模型能力團隊的成員建立了受評估的工作流程，可能引入偏差。所報告的提升可能更接近應用可觀察到的上限。

Jev vs 結構化輸出的 LLM vs 傳統分類器 vs 規則引擎

當固定規則過於脆弱、建立專用分類器成本高昂，且應用不需要生成式文字時，Jev 最為實用。

當任務需要研究、解釋、內容創作、規劃或多步推理時，傳統 LLM 仍是更佳選擇。當正確條件已可明確且決定性地表達時，規則引擎仍更可取。

建議使用情境

Jev 最適合具有預定義答案空間的高頻決策。

• 路由與分流： 對請求分類、選擇佇列或工具，並優先處理緊急案例。
• 代理控制： 檢查任務完成度、評估提議的動作，並識別需要確認的案例。
• LLM 評估： 評估關聯性、證據支援度、政策相容性或回應品質。
• 審核： 分類政策違規、評分嚴重程度，並升級不確定案例。
• 資料豐富化： 將訊息、評論、潛在客戶與紀錄轉換為類別、分數與機率特徵。
• 即時決策： 支援低延遲的應用行為，當完整的生成式回應非必要時。

Jev 的限制

Jev 是刻意專精的，這種聚焦設計帶來一些重要限制。

• 無法生成散文、程式碼、摘要或對話式答案。
• 不適用於延展研究或多步推理。
• 型別安全的輸出不保證商務決策正確。
• 影像、音訊、視訊與二進位檔需先轉為文字或結構化資料後再提交。
• 英文是文件最完整的語言。
• 非英文與 CJK 工作負載需獨立評估。
• 同一請求內的問題彼此獨立評估。
• 模型無法在這些問題之間構建序列推理鏈。
• TypeSafe 未披露模型參數規模，也未釋出權重。
• 自訂是透過請求進行，而非客戶專屬的微調。
• 公布的效能提升來自 TypeSafe 自身的評估框架。
• 可移動的別名可能在未變更應用程式代碼的情況下帶來行為變化。

在權限、財務計算、法規要求、檔案大小限制或不可逆動作政策等方面，Jev 不應取代決定性程式碼。機率式模型適用於不確定的判斷，而非軟體已能精確評估的條件。

CometAPI 如何提供 Jev API 的存取？

Jev 目前尚未出現在 CometAPI 的公開模型目錄中。CometAPI 計畫在模型開放存取且所需連線權限開啟後，評估並整合 Jev。

整合完成後，開發者將可在 CometAPI 的模型目錄與 API 文件中查詢支援的模型 ID、請求格式、價格、速率限制與端點可用性。

在官方宣布整合之前，開發者應使用 TypeSafe 的主控台、原生 API 或官方 SDK 存取 Jev。只有當 Jev 出現在公開模型目錄並附有驗證過的 API 資訊時，方可視為 CometAPI 已提供整合。