hero

Simon Willison 在 2026 年 9 月 21 日介紹 TypeSafe AI 的 Jev；它被 10 月 19 日的匯總再次列入，不是本週新推出的模型。此前本站已從詞袋、Transformer 與 IMDb 實測整理過 Jev 的分類定位。這篇不重講演進史，而聚焦 Willison 更尖銳的問題：當一個模型只交出分數，不交出理由，開發者能拿什麼證據讓它參與真實決策？

原文摘要

「輸入狀態，輸出判斷」到底省下什麼

Willison 的介紹指出，Jev 仍讀取文字或半結構化的狀態，但不以自由文字作答，而是針對事先給定的問題，產生是非機率、多選一分布或序位分數。Noul 是二元判斷；Choice 在候選標籤間選擇並回傳分布；Score 對預先描述的等級給分。可以把一份客服工單的描述作為同一個 state，一次提交多個判斷問題。TypeSafe 宣稱這些問題平行評估，因此增加問題數通常比要求聊天模型逐題生成文字省時；實際延遲仍須依題數、輸入長度與服務負載測量。

Willison 援引當時的TypeSafe 定價與產品說明，記錄每百萬輸入 token 0.042 美元、輸出不另外計價的發布時定價。這是 9 月文章所記載的價格，不是對 10 月或未來方案的保證。其低成本來自限定輸出型態，不能與能撰寫完整答覆的模型只比單次請求價格，卻忽略後續驗證、人工覆核和錯誤決策的成本。若企業本來就在程式裡寫一個分支條件，改用決策 API 的收益是能處理文字描述的模糊性，代價是把原本可讀的規則變成需要經驗驗證的模型判斷。

Willison 提到一個可能的用途：先用 BM25 這類便宜的檢索方法取回約百個候選，再讓 Jev 判斷候選與查詢是否相關。這是他正在試驗的 reranking 設想，不是文章公布了資訊檢索提升幅度的對照實驗。真正驗收時須固定候選集合、相關性標註與比較基線，再看排序品質、延遲和費用是否一起改善；單看 Jev 能對每個候選吐出一個浮點數，沒有告訴你檢索品質是否提升。

輸出有效格式，並不等於決策理由可查

一個只回傳 0.87 的系統，好處是下游程式不用猜測自由文字如何解析，也不會憑空產生未定義的候選標籤。可是「型別正確」與「判斷正確」是不同驗收層次；第三層則是「為何這次判斷如此」。Willison 指出聊天模型至少可以被要求解釋，雖然它說出的解釋也未必忠實；Jev 連這種自然語言理由都不提供。若它把一封信判為垃圾郵件，外部看不到具體是哪一段內容造成決定。原文的黑箱段落因此主張更重視實驗，而不是把機率小數點的精確度誤認為可解釋性。

這不表示外部完全無法查驗。可以把同一案例的輸入、問題文字、候選定義、選項順序、模型版本與回應留成可回放紀錄，在不影響個資的前提下，用成對的反事實案例逐項改變一個條件：例如只改客訴文本的退款日期，判斷有沒有依規則變化；再換一組與決策無關的姓名或地區，檢查結果是否意外翻轉。這種測試能發現不穩定與潛在偏差，不能反推出模型內部的真實因果路徑，更不能由一兩個示例替整個族群下結論。

Willison 曾把灣區城市名稱交給 Jev，問哪個是「好城市」，結果 Cupertino 排在高處、East Palo Alto 排在低處。這是文章描述的探索性單次實驗，不是已控制房價、收入、交通、資料集代表性及提示措辭的偏差研究；「好」本身也沒有可操作的定義。它足以提醒我們：含糊的評價題會讓模型把未知的既有關聯塞進分數，卻不足以單憑排名斷言模型已被證實歧視某一群人。Willison 明確反對不經審查就拿這種分數替求職者排序；在人事領域，決策者需要的證據遠多於一個城市例子或廠商的自評。

廠商自己的文件，已列出會讓分數改變的條件

TypeSafe 的 Jev 1.13 已知限制並沒有把它描述成萬用判官。文件承認：模型可能過度照字面理解；對數值運算與日期比較不可靠，建議把計數與比較交還程式碼；多層間接推理、夾雜大量無關資訊的 state 也可能失準。最關鍵的是，文件提醒 Choice 候選順序有時會影響答案，甚至偏向先列出的選項。對一個回傳機率分布的 API，這意味著類別描述與排列本身就是實驗條件；修改 UI 顯示順序若連帶改了送進模型的順序，可能改變判斷。

同一頁還明言，state 中若混入企圖指揮模型的對抗性文字、偏頗敘事，答案可能受到影響。這一點與「回傳固定型別」並不矛盾：攻擊者不一定要讓系統輸出奇怪的字串，只要把原本該為否的問題推成是、或推高某個候選的分數，就已改變下游分支。服務能限制答案格式，不代表能自動辨別輸入的哪一部分是可信指令、哪一部分只是外部文本。供應商建議精確設問與測試邊界案例；應把這看成部署前仍需執行的工作，而不是已解決注入風險的保證。

當前服務另有一個較細的限制：文件說 Score 的等級期望值不適合拿來內插精確數字。若要算折扣、期限、金額或人數，直接以程式解析和計算；若需要語義判斷，例如「這段內容是否表達退款請求」，才考慮交給模型。這條分工不是貶低決策模型，而是避免把它放進已有確定解法、又要求精度的工作。

一份能用的驗收設計，不能只有總準確率

若要把 Jev 接進工單分流，先寫清楚每種分支會造成什麼後果：錯把緊急申訴列為普通案件，和把普通案件升級人工處理，代價並不對稱。從既有工單抽取涵蓋不同語言、時間、來源與罕見類別的留出資料，由人工先定義正確標籤與爭議處理規則；每筆保留原始輸入、輸出的機率及所用版本。依業務錯誤成本設閾值，低信心或規則衝突時交由人確認，再量測各類別的漏判、誤判、人工接手量與實際總成本。這是基於 Willison 的疑問和廠商限制提出的通用評測做法，不是 TypeSafe 已替特定企業交付的成效報告。

還需要對問題寫法做壓力測試：把同義的類別描述改寫、調換選項先後，加入無關敘述和帶命令語氣的外部文本，逐一測量分布怎麼變；對姓名、地區等不應單獨左右結果的欄位做配對測試。若要把 0.8 當作風險機率使用，應檢查留出資料中所有預測約 0.8 的案例實際有多少成立，並在關鍵群組上分開看。當類別比例、輸入來源或模型版本改變，舊門檻必須重新驗證。分數的可信度是某種問題寫法、某個資料分布、某個決策代價下的經驗結論，不會因 API 型別安全而自動成立。

Jev 讓「大量小判斷」變得便宜又容易接進程式；Willison 的提醒是，省下生成文字與格式處理，不等於省下驗證。這也是它與既有文字分類方法與 IMDb 對照文章最不同的切面：這次要檢查的，不是它能否完成一項分類，而是當結果開始影響人的機會、資源或資料權限時，誰能重跑、質疑和改掉那個分支。