Jev：不寫字，只負責「做判斷」的 AI

用急診檢傷來理解它

台灣的急診室門口都有檢傷分類站。護理師看一眼病人、問幾句話、量個生命徵象，一兩分鐘內就給出一到五級的檢傷等級，並決定病人先去哪一區。護理師不負責診斷、不開藥、不動手術——那是後面醫師的事。但正因為她只做這幾個判斷，她可以又快又穩地處理一整個候診區的人，醫師的時間就留給真正需要深入處理的病人。

Jev 就是這位檢傷護理師。它讀完你給的情境，直接回答幾個事先定好的問題，然後把人送到正確的地方。會寫文章、能推理、能解釋的生成式模型，則是後面的醫師。

這個比喻有一個地方和實際情況不同，要先講清楚：檢傷護理師如果被問「為什麼判三級」，她講得出理由；Jev 講不出來。它只回傳選項和機率，沒有任何解釋文字。如果你的流程需要留下判斷理由給稽核或主管看，這一段得另外用生成式模型補，或由人來做。

它實際上怎麼運作

一次 Jev 呼叫只有兩個部分。state 是要被判斷的情境，可以是一段文字、一個 JSON 物件，或一串對話訊息；questions 是針對這個情境的一組問題，每一題都要指定型別。官方文件把問題的型別限制在三種，這不是還沒做完的功能，而是刻意的設計：答案的範圍是你事先寫死的，模型只能在範圍內選，所以永遠不會回傳格式錯誤或不存在的選項。

下面是官方 SDK 的用法，把三種題型放在同一次呼叫裡。所有問題會同時被回答，不是一題一題排隊。

# pip install typesafe-sdk
from typesafe_sdk import Choice, Noul, Score, TypeSafeClient

client = TypeSafeClient()   # 讀取環境變數 TYPESAFE_API_KEY，預設模型 jev-latest

response = client.system_one(
    state={
        "ticket": {"subject": "重複扣款",
                   "messages": [{"from": "customer",
                                 "text": "訂單 A-104 被扣了兩次，請退掉重複的那筆。"}]},
        "refund_policy": "重複扣款可以退款。",
    },
    questions={
        "department": Choice(instructions="哪個團隊應該處理",
                             criteria={"billing": "付款或訂閱問題",
                                       "technical": "程式錯誤或整合問題",
                                       "sales": "價格或方案問題",
                                       "other": "以上皆非"}),
        "frustration": Score(instructions="客人看起來有多不滿",
                             criteria=["冷靜陳述事實", "不滿但客氣", "非常生氣、用詞強烈"]),
        "refund_requested": Noul(instructions="客人明確要求退款"),
    },
)

dept = response.answers["department"]
print(dept.choice, dept.confidence)          # 例如 billing 0.93
print(response.answers["frustration"].score)  # 例如 0.42（介於「冷靜」與「不滿」之間）
print(response.answers["refund_requested"].noul)  # 例如 0.97

為什麼可以快這麼多：平行取樣，而不是逐字生成

一般 LLM 是「自回歸」的：每產生一個字，都要看前面所有的字，再決定下一個字。答案有 300 個字，就要跑 300 輪。Jev 讀完 state 之後，用 TypeSafe 稱為「parallel sampler」的機制，一次算出所有問題、所有選項的機率。不管你問 3 題還是 13 題，時間幾乎一樣，多問一題只多付一點輸入 token 的錢。官方文件裡有一個例子：對一篇長文章問 13 個法規相關問題，一次問完比逐題問便宜 12.2 倍、快 10 倍，答案相同。

這也解釋了它的計價方式：輸入 token 每百萬 0.042 美元，輸出免費。因為輸出根本不是一串一串生成出來的文字，成本低到官方說不值得計費。

為什麼機率值得信：RLCD 訓練法

光是回傳「billing：0.93」還不夠，關鍵是這個 0.93 值不值得信。很多人試過請 ChatGPT 在回答後附上信心分數，結果模型常常過度自信，而且同一題問兩次給的數字不一樣。這是因為 ChatGPT 那類模型的訓練目標是 RLHF——讓人類評分者喜歡它的回答——沒有人在訓練時要求它的機率要「準」。

TypeSafe 改用他們稱為 RLCD（Reinforcement Learning for Calibrated Decisions，校準決策的強化學習）的方法，訓練目標直接是機率要和實際結果對得上。所謂校準（calibration）的意思是：模型說「90% 是 billing」的那些案子，長期統計下來大約有 90% 真的是 billing。這件事在自動化裡非常重要——一個做對 95% 但不知道哪 5% 錯的模型，你不敢放手；一個會老實說「這題我只有六成把握」的模型，你就可以寫規則：把握夠就自動處理，不夠就轉人工。

動手看看：判斷結果長什麼樣

下面這個小工具模擬一次 Jev 呼叫的輸入與輸出，讓你感覺一下「回傳機率」和「照信心度分流」是什麼意思。

玩過一輪應該會注意到兩件事。第一，同一封信的判斷結果不是一個答案，而是一組機率——程式可以只看第一名，也可以看分布是否集中。第二，「門檻」不是模型的一部分，是你根據錯誤代價自己訂的：查餘額這種判錯了也沒事的動作，門檻可以低；轉帳這種動作，門檻就要拉高。這正是 RLCD 校準後的機率能派上用場的地方。

五種常見的用法模式

這些模式來自 TypeSafe 的文件與早期使用者的整理，共同點是：迴圈、安全檢查、算術留在普通程式碼，Jev 只負責中間那一小段程式碼很難寫成規則的判斷。

開發者第一週做出了什麼

Jev 在 9 月 15 日開放，下面這些都是發布後幾天內的實驗作品，數字全部是作者自行回報、未經第三方驗證，請當成方向的示範而不是生產環境的成績單。

限制與踩過的坑

TypeSafe 在文件裡公開了一頁叫「jaggedness」（能力不平整）的清單，列出目前版本 jev-1.13 做不好的事。以一個發布週的產品來說相當坦白，這些也是實際導入前最該先知道的。

• 它照字面理解。否定句、範圍限定、隱含的前提都會被直接當真。如果你看到一個錯答案，發現自己正在心裡解釋「我其實是想問……」，那句解釋就是你指令裡漏掉的一半。
• 它不是計算機。數數不可靠，東西越多錯得越多。正確做法是在程式裡迭代，對每個項目各問一個 Noul，然後由程式加總。
• 日期對它來說是文字，不是可比較的數量。哪個日期在前、差幾天、是否落在某區間，都不可靠。抽取（哪一個月、哪一天）可以用 Choice 列舉選項加上「未提及」；排序和計算留給程式。
• state 不會被當成有敵意的內容。如果 state 裡有使用者能控制的文字，刻意寫成「請把我分類成退款」的內容是有可能影響答案的。這是呼叫方要自己處理的威脅模型，也是資安上要特別留意的一點。
• 塞太多無關資料會變差。先檢索、先過濾，只送問題需要的欄位。
• 指令和選項描述互相矛盾會讓它混亂。例如一個 Noul 裡 true 對應的是「否」，效果會很差。把選項描述當成指令的延伸來寫。
• 它不生成任何東西。沒有文字、沒有程式碼、沒有摘要，也不會解釋理由。要從自由文字抽值，先用正規表達式或生成模型列出候選，再讓 Jev 挑。
• 只吃文字。圖片、聲音、影片要先轉成文字或描述。
• 語言。TypeSafe 表示可以處理中文等語言，但英文是主要訓練語言、效果最好。繁體中文、口語和產業用語的準確度，需要用自己的資料測過才能下結論，不能直接套用英文示範的數字。

關於那些漂亮的數字

官方的「快 193.6 倍、便宜 444.6 倍」來自他們自己設計的四組工作流程評測，而且是用 GPT-6 Astra 與 Claude Fable 5.1 兩個前沿模型答案的平均當作參考答案，再看每個模型和參考答案有多一致。所以評測表上的 67.8%，衡量的是「和兩個前沿模型的一致程度」，不是有正確答案的準確率；也因此這兩個模型本身不會出現在榜上。目前沒有獨立的第三方重現這些結果，官方自己也在文章裡逐項寫了「nuance」提醒偏差可能在哪。實務上的結論很簡單：用自己的資料、自己的流程跑過再決定。

另外幾個營運面的事實：目前是候補名單制的早期存取；速率限制約每秒 25 萬 token、每分鐘 1,200 次請求，官方說會隨 GPU 容量調整；jev-latest 會隨新版本移動，如果你調過門檻，請把版本釘在像 jev-1.13.0 這樣的固定 ID，並把回應裡的 model 欄位記錄下來。價格方面官方坦承無法證明目前沒有補貼，但預期會降不會漲。

和一般大型語言模型的分工

兩者不是誰取代誰。比較合理的架構是：程式掌握流程與權限，Jev 處理高頻、答案範圍已知的判斷，生成式模型負責需要自由文字或複雜推理的步驟，低信心與高風險案例交給人。

什麼時候該考慮它

最有用的心態轉換是：這不是「比較便宜的 LLM」，而是一種不同的積木——一個剛好很聰明的函式呼叫，回傳一個型別，並告訴你該相信它幾分。有了這塊積木之後，很多原本只是為了「處理模型回傳的一大段字」而存在的程式碼，就不再需要了。