Skip to main content
Jev 決策
Jev 是 TypeSafe 的結構化決策模型。輸入業務狀態 state 和具名問題 questions,同步獲得分類、評分或真假機率,而不是生成聊天文本。 POST https://api.mixroute.ai/typesafe/v1/systemone 使用 MixRoute API Key,以 Authorization: Bearer $MIXROUTE_API_KEY 認證,Content-Type: application/json。請求體保留 TypeSafe 原生的 modelstatequestions 層級,不使用 metadata、聊天 messages 或非同步任務輪詢。

支援模型

jev-1.13.0 是固定版本 ID,jev-latest 是最新穩定版別名,當前都呼叫 Jev 1.13,屬於同一個模型,不是兩個獨立型號。以後 latest 可能隨新版本釋出更新;需要固定行為時使用版本 ID,並讀取響應的 model 確認實際版本。 僅使用賬戶 模型列表 中返回的完整型號。

選擇問題型別

頂層引數

問題 ID 只用於請求與答案的對應,不參與模型推理;不要把真正的問題只寫在 ID 中。多個問題針對相同 state 獨立評估,可以混合三種類型,但不能依賴同一次請求中其他問題的答案。需要前後依賴時,在應用層分兩次呼叫。

問題引數

以下欄位位於 questions[question_id] 內。建議為每個問題顯式填寫 instructions,一次只描述一個明確的判斷目標。

Choice 分類

返回 choice 為機率最高的選項;probabilities 包含所有選項,機率和約為 1。可增加 other 或 insufficient_information 選項處理資訊不足的輸入。

Score 評分

等級索引從 0 開始:三個等級對應 0、1、2。score 是等級索引的機率加權位置,範圍為 0 到等級數減 1,可以是小數,並非固定的 0-1 分數。legend 把字串形式的索引映射回原始描述,probabilities 使用相同索引。使用返回的 score,不要直接截斷為整數;需要離散等級時由應用選擇對映規則。

Noul 真假判斷

返回的 noul 是 0-1 的機率,不是布林值:接近 1 傾向於真,接近 0 傾向於假,接近 0.5 表示不確定。Noul 沒有單獨的 confidence 欄位,也不是用於衡量程度的評分;程度問題使用 Score。

輸入與上下文限制

文字內容、instructions 和 criteria 都佔用上下文預算。多問題請求中的 state 共用,但各個問題仍增加總輸入量。不要把廠商的公開速率上限當作 MixRoute 賬戶的可用配額,實際限額以賬戶配置為準。

請求示例

設定服務端環境變數 MIXROUTE_API_KEY。下面在一次請求中混合三種問題。

響應示例

示例機率和 token 用量僅用於展示響應格式;不同輸入或呼叫可能返回不同值。 在應用層設定機率/置信度閾值,併為不確定的輸入保留人工處理或補充資訊的路徑。高 confidence 不保證結論正確;尤其要用自身業務資料驗證非英語任務。

結構化輸入

state、instructions 和描述性 criteria 可以使用原生 JSON 結構。以下示例同時展示物件指令、陣列指令及結構化等級描述。

對話陣列

對話記錄直接作為 state 陣列傳入;這裡的 role/text 是業務欄位,不是 Chat Completions 的訊息協議。

Python

需要 Python 3 和 requests。示例直接讀取同步答案,不進行任務輪詢或自動重複提交。

JavaScript

Node.js 18+,使用 ES module(.mjs)。API Key 僅儲存在服務端,不放入瀏覽器程式碼。

價格與用量

以上為美元基礎單價,實際價格以 模型廣場、賬戶分組倍率及賬單為準。輸入用量包括 state 和問題定義,更多問題與選項也會增加輸入 token。響應的 usage.output_tokens 可以大於 0,但輸出 token 不收費。 使用 usage.input_tokens 估算費用:輸入 token 數 × 輸入單價 ÷ 1,000,000,再應用賬戶倍率。平臺按內部額度逐筆結算,取整後的賬單可能與直接按美元計算的微小金額略有差異。 額度換算說明見 認證與額度

響應處理

先檢查 HTTP 狀態,再讀取 JSON。成功響應直接包含 answers;錯誤響應通常使用 detail,可能是字串、物件或欄位錯誤陣列。保留響應頭 x-oneapi-request-id 便於定位請求,不要記錄完整 API Key。 網路超時不等於請求沒有執行。重複提交會建立新的評估並可能再次計費,重試策略應由應用明確控制。