jev-latest

Jev 是 TypeSafe 的旗艦模型，也是新類別 System One 的首個模型。它不撰寫文字，而是快速做出程式可直接使用的決策：傳入狀態（state），即文字或 JSON，以及一組問題，便會取得具有校準機率的特定型別的值。

語言模型為人類撰寫文字；依 TypeSafe 的說法，Jev 更接近程式碼：回答直接採用程式需要的形式、速度快，而且不會產生指定選項以外的值。模型的設計目標，是在重複請求時提供穩定回答。

System One 與語言模型有何不同

• 不生成內容。 Jev 不替使用者撰寫回答，不寫程式碼，也不解釋推理過程。可能的回答由您透過三種問題型別中的一種指定。
• 以校準決策為訓練目標。 TypeSafe 使用 RLCD（Reinforcement Learning for Calibrated Decisions，校準決策強化學習）訓練模型，讓機率貼近實際結果並反映不確定性。在大量機率為 0.8 的回答中，理應約有 80% 正確。校準是大樣本的特性，不保證個別回答正確。
• 訓練目標不同。 聊天模型透過 RLHF 學習讓人滿意；依 TypeSafe 的觀察，這會鼓勵迎合，以及聽起來自信的錯誤回答。RLHF 的共同作者之一 Diogo Almeida，是 TypeSafe 的共同創辦人。

名稱源自 Daniel Kahneman《快思慢想》中的「系統 1」：快速的直覺判斷，對應「系統 2」緩慢且經過思考的推理。Jev 用於快速、範圍明確的判斷。

三種問題型別

每個問題對狀態做出一項判斷；回答是可由程式與門檻比較、排序或傳往下一步的值。

1. Choice：選擇選項。 例如客服案件的承辦部門、商品類別，或程式碼片段的語言。選項以「選項 → 說明」的字典提供，最多 255 個。回答包含所選的 choice、所有選項的 probabilities（總和為 1），以及信心值 confidence。若清單可能未涵蓋所有情況，請加入「其他」或「以上皆非」。
2. Score：依尺度評分。 在您描述的有序尺度上選擇位置，例如錯誤嚴重性、客戶不滿程度或技能水準。可有 2 至 10 個等級，由低至高排列；模型分別評估每個等級，不會看到其編號或相鄰等級。回答包含 score（各等級編號乘以其機率後加總，因此可能介於兩個等級之間）、說明各等級的 legend、probabilities 及 confidence。
3. Noul：是或否。 判斷一項陳述是否成立。回答 noul 是「是」的機率，介於 0 至 1：接近 1 表示有把握的「是」，接近 0 表示有把握的「否」，接近 0.5 表示模型猶豫。沒有獨立的 confidence；單一數值即可完整描述回答。非必填的 criteria 可進一步說明哪些情況算「是」、哪些算「否」。

選擇方式：已知且無順序的選項使用 choice；連續程度中的等級使用 score；單純判斷「是／否」，且重視機率本身時使用 noul。Noul 為 0.5 代表「是」與「否」的機率相同，不是「中等程度」；程度應以 score 衡量。若有兩種型別都適用，請選擇程式能直接據此行動的型別：choice 用於分支，score 用於門檻，noul 用於 if。

可在同一請求中混用不同型別。回答始終限制在您指定的選項中，且不受其他問題影響；增加或移除問題，不會改變其餘回答。

狀態

狀態是模型要評估的內容，例如客戶訊息、文件片段、資料庫紀錄，或應用程式的狀態。

• 字串：適用於單一文字內容，例如訊息、文章或摘錄。
• 物件：適用於具名欄位、關聯紀錄及應用程式狀態。TypeSafe 建議大多數請求使用物件，讓每一部分都有明確名稱。
• 陣列：適用於訊息或紀錄的序列。

如同準備給專家的資料：若決策需要比較對話、訂單及退貨規則，就將它們放在一起。內容放在狀態中，判斷放在問題中。若問題只涉及狀態的一部分，請以反引號標示其路徑，例如 ticket.messages[0].text。

如何提出問題

• 每個問題只做一項快速判斷。 好問題是熟悉情況的人能在一秒內回答的問題，例如「這則訊息是否有急迫性？」。「分析訊息並決定該怎麼做」已是較慢的推理，應拆成簡單問題。
• 完整問題放在 instructions。 問題的鍵，例如 refund_requested，只供您的程式使用，不會傳給模型。
• 同一狀態的所有問題放在同一請求。 模型平行評估；依 TypeSafe 說明，額外問題幾乎不增加回答時間，只計入自身的 token 成本。預先多問一題的成本幾乎可忽略，程式再自行決定需要哪些回答。
• 複雜判斷拆開處理。 與其要求「評估新創公司的申請」，不如分別詢問市場規模、技術可行性及競爭差異，再於程式中加權計算結果。優先順序變動時，調整權重即可，不必改寫問題。
• 相依問題放在第二個請求。 同一請求的回答不會成為彼此的上下文。只有無法在取得第一個回答前組成後續請求時，例如需要載入資料或選擇下一題的選項，才需要第二個請求。
• 長問題使用物件。 instructions 與 criteria 通常是字串，也可以是物件或陣列：一個欄位放問題，其他欄位放資料。這樣可用單一問題方便地比對履歷與資料庫紀錄。

信心值

choice 與 score 的 confidence 介於 0 至 1，表示機率集中在單一回答的程度：1 代表全部集中於一個選項，0 代表平均分配給所有選項。對 score 而言，相鄰等級對信心值的降低，比距離較遠的等級小。noul 的信心直接反映在數值本身：離 0.5 越遠，回答越確定。

TypeSafe 建議分為三個範圍：

1. 高信心：自動執行操作。
2. 中信心：謹慎行動，例如請使用者確認。
3. 低信心：交由人員處理、釐清請求，或使用備用路徑，例如較強的推理模型。

錯誤代價越高，門檻就應越嚴格；不可逆的操作應比讀取操作採用更高門檻。回答指出該選什麼，信心值則協助判斷是否應行動。請以自己的資料比較信心與正確率，設定門檻。

如何圍繞 Jev 建立系統

Jev 的設計對象是由程式碼控制流程、模型回答狹窄語意問題的程式，而非自行選擇下一步、每次循環都可能偏離方向的代理。TypeSafe 提出八個設計步驟：

1. 凡是能用程式碼完成的事，就用程式碼完成，可靠且成本低。
2. 狀態只放目前問題需要的內容；新事實來自自己的知識庫，而非模型記憶。
3. 狀態保持結構：使用巢狀 JSON；若能減少歧義，在問題中以反引號標示所需欄位路徑。
4. 問題盡量狹窄、具體。依 TypeSafe 的說法，這或許是最重要的規則：寬泛的問題會將多項判斷藏在同一回答中。
5. 問題也保持結構：主問題簡短，說明、範例與資料庫中的值，放在 instructions 或 criteria 物件的其他欄位，而非塞進同一條長字串。
6. 同一狀態的多項獨立問題放在同一請求，提高每一美元的效益。
7. 由程式碼整合回答，可使用規則、加權總和，或作為傳統機器學習模型的特徵。
8. 依信心值分支：不確定的情況交給人員或推理模型。

Jev 不是聊天模型，也不是程式碼自動完成模型，不能直接取代程式開發代理中的語言模型。但代理可替您撰寫程式，在需要快速且經過校準的回答時呼叫 Jev。

使用情境

• 背景自動化：在無人值守的情況下，重複執行一百萬次的決策。
• 即時處理：依 TypeSafe 說明，多數請求約在 100 毫秒完成，足以進行即時資料處理及介面互動。
• 大量資料：搜尋龐大資料集、標記代理工作紀錄，以及建立預測特徵。
• 檢查其他模型：檢查請求、擷取內容、推理與工具呼叫，辨識繞過限制、引用錯誤及捏造內容。
• 搜尋與排序：判斷「查詢 — 候選項」配對的相關性、重新排序及篩選上下文。
• 依意圖分流：判斷使用者需求與處理方式，例如簡單邏輯、專門模型或人員；主題、複雜度及風險決定應交給哪個語言模型。
• 防護檢查：檢查語言模型的輸入、輸出與工具呼叫，包含注入指令、違反規則及個人資料外洩。
• 客服：案件主題與意圖、急迫性、不滿程度、流失風險、退款要求及佇列安排。
• 內容審核：依平台規則檢查有害言論、霸凌、垃圾訊息、詐騙、危險建議及個人資料；再依嚴重程度與信心值決定放行、警告、人工檢查或封鎖。
• 產業應用：保險案件、金融調查與 KYC、合約及廣告、商品頁、人員招募、潛在客戶、遊戲、風險、需求預測、知識圖譜、科學文獻回顧，以及 CI 中的程式碼語意檢查。

特性

• jev-latest：最新穩定版本的別名，目前為 Jev 1.13；實際回答版本會出現在 model 欄位，例如 jev-1.13.0。推出新版本後，別名會指向新版本，回答可能在您未修改程式的情況下改變。若門檻是依特定版本調整的，請留意此欄位。
• 上下文：每項請求為 64K token，包含狀態及所有問題；狀態加上最長問題，最多為 32K。模型只讀取狀態一次，再平行評估所有問題。
• 輸入：僅文字，可為字串、JSON 物件或文字陣列。尚不支援圖片、音訊與影片，應先轉成文字。
• 語言：主要訓練語言為英文，目前以英文的正確率最高。也接受其他語言，包括中文、日文與韓文，但正確率較低，應以自己的資料驗證。
• Ailoot API 的價格與計費 — 條件依所選方法而定，並列於該方法的卡片中。
• 設定：Jev 不以客戶資料微調。自有資料放在 state，領域規則放在 instructions 與 criteria。
• 資料：TypeSafe 表示，Jev 不會以客戶的請求與回答進行訓練。

Jev 1.13 的已知弱點

TypeSafe 公開列出目前版本的弱點，並表示未來版本會改善許多部分。模型速度快、機率經過校準，也擅長常識判斷，但仍有下列限制：

1. 按字面理解。 回答寫出的問題，而非隱含的意思；保留條件、否定及隱含條件都按字面解讀。請在 criteria 寫出精確條件與邊界情況；無法避免的解讀，拆成兩個字面問題。
2. 不是計算機。 字元、重複項與清單元素的計數不可靠，資料量越大，錯誤越容易增加。請在程式碼中計數，每個候選項各問一題。模型對 hex 或 RGB 色彩的理解，不如顏色名稱。score 適合門檻判斷，不適合取得等級間的精確數字。
3. 日期與時間。 比較日期先後、計算間隔或判斷是否落在期間內，均不可靠，混合格式與相對日期尤其如此。可透過 choice 擷取日期各部分，加入「未註明」選項，再用程式碼比較。
4. 間接問法。 雙重否定及詢問某種特性的特性，會降低正確率。請直接表達，並明確寫出狀態各部分的名稱。
5. 狀態中的多餘內容。 無關文字會降低正確率。請用程式碼過濾；若無法過濾，可用 noul 問題排除不相關內容。
6. 惡意文字。 模型預設不會預期狀態中有陷阱；注入指令，或試圖爭辯自身分類的文字，可能改變回答。請指定精確條件，並在上線前檢查邊界情況。
7. 相互矛盾。 若 instructions 與 criteria 要求不同，例如 noul 的「是」被描述成「否」，正確率就會下降。判斷條件是問題的延伸。
8. 選項順序。 模型有時偏向 choice 的第一個選項。請重新排列選項，檢查回答是否維持一致。
9. 內容生成。 Jev 未受過文字撰寫訓練。擷取資料時，請先以正規表示式或生成模型找出候選內容，再讓 Jev 透過 choice 選出正確項目。