Table of Contents
你只是想把一封客訴信分到正確的部門。但你得寫一長串提示詞、祈禱模型不要亂加符號，最後再寫一套脆弱的解析器，把它那段有禮貌的說明文字拆回一個單詞。
TypeSafe AI 的 Jev 反其道而行：不寫字，只回傳決策。
{"department": "billing", "confidence": 0.89}
，70–500 毫秒，輸出 token 免費。
📊 但重點不是快。廠商自己的測試說它的準確率是 67.8%——大約每三個決策就有一個是錯的。
🎯 那為什麼還能用？因為它的訓練目標不是「答對」，是校準：當它說 0.9 的時候，統計上真的有九成會對。
🚦 於是可以分流——高信心自動執行、中信心標記覆查、低信心轉人工。整個系統的表現，可以遠高於模型本身的 67.8%。
🏥 對做品管的人來說，這是老問題的新解：過去只能抽查 5%，而抽樣是盲的，它不知道自己抽到的是不是容易出錯的那一批。信心分數讓覆核從隨機抽樣變成風險分層——而且是由可記錄、可調門檻的旗標觸發，不是由誰的主觀判斷。
⚠️ 但要一起讀進去的：所有數字都是廠商自報，沒有論文也沒有模型權重；「零幻覺」只指格式，它依然會把 A 判成 B，只是用型別正確的方式判錯。
🚪 最關鍵的限制是它不能告訴你為什麼。在受監管的領域，一個 0.93 的分數提供了結果，卻永遠給不出理由。所以這類模型適合當分流器，不適合當決策者——放在流程的入口，不是出口。
👉 真正的轉向不是「AI 不再說話」，而是這個問題被重新問了一次：哪些決策需要理由，哪些只需要一個可靠的機率？
#AI架構 #LLM #決策模型 #品質管理 #校準
當 AI 不再說話
一個只輸出決策的模型，把問題從「準不準」換成了「知不知道自己不準」
過去幾年，「幫產品加上 AI」幾乎等於在裡面塞一個聊天機器人。但如果你要做的只是把一封客訴信分類到正確的部門，這個做法荒謬得可以：你寫了一長串提示詞，祈禱模型不要多加 Markdown 符號，然後再寫一套脆弱的解析器，把它那段有禮貌的說明文字拆回一個單詞。
TypeSafe AI 的 Jev 想解決的就是這件事。它由 OpenAI 前研究員、ChatGPT 共同發明者 Diogo Almeida 創辦，閉關兩年後於 2026 年 9 月 15 日發表，同時宣布完成 4,000 萬美元募資。它的定位很清楚：不寫字，只做決策。
但我認為大多數報導把重點放錯了。快和便宜是結果，不是重點。
一、系統一與系統二
Jev 的命名來自 Kahneman 的《思考，快與慢》。系統一是直覺、快速、自動的判斷——這封信的語氣是不是在生氣；系統二是緩慢、耗力的推理——寫一篇論證完整的長文。
現在的大型語言模型本質上是系統二機器：逐字推理、逐字生成。用它來做一個「這是 A 還是 B」的判斷，就像每次要開燈都先寫一段散文說明為什麼該開燈。
| Jev（系統一） | 聊天模型（系統二） | |
|---|---|---|
| 輸出 | 型別安全的結構化數值 | 字串，需解析與驗證 |
| 生成方式 | 平行取樣，一次回傳 | 自迴歸，一個 token 接一個 |
| 延遲 | 70–500 毫秒 | 數秒到數分鐘 |
| 訓練目標 | RLCD：校準的決策 | RLHF：人類偏好／RLVR：可驗證的正確 |
| 輸入價格 | 每百萬 token 0.042 美元，輸出免費 | 依模型，輸出另計 |
| 適合 | 分類、路由、評分、門控 | 摘要、寫作、長鏈推理、對話 |
二、三個原語
Jev 把問題限縮成三種形狀，而輸出的形狀在發問之前就已經定義好了——模型在數學上不可能跑出格式之外的東西。
Score 的設計有個細節值得注意：它做的是機率加權插值，所以 1.9 和 1.1 雖然落在同一個語義級別裡，1.9 仍然更靠近「憤怒」那一端。這比硬分類保留了更多資訊。
三、真正的重點：67.8% 是什麼意思
TypeSafe 自己的測試說，Jev 在系統一任務上的準確率是 67.8%，略高於某個前沿聊天模型的 66.8%。
很多報導把這句話讀成「它比較準」。但先把那 1% 放一邊，看看 67.8% 這個數字本身：大約每三個決策，就有一個是錯的。
如果這就是全部，那這個東西不能用。任何把三分之一錯誤直接送進生產環境的設計都是災難。
所以它的價值不在那 1%，而在另一個東西：RLCD 這個訓練方法優化的目標不是「答對」，而是校準——當模型說 0.9 的時候，它在統計上真的有九成會對。
校準和準確是兩件不同的事。一個準確率七成、但知道自己哪三成可能錯的系統，比一個準確率八成、卻不知道自己何時會錯的系統更好用。
因為前者可以分流。
answer = response.answers["department"]
if answer.confidence > 0.9:
auto_route_to_department(answer.choice) # 自動執行
elif answer.confidence > 0.5:
route_and_flag_for_review(answer.choice) # 標記覆查
else:
send_to_human_inbox() # 轉人工值得強調的是流程的觸發方式。這裡的人工覆核不是由某個人的主觀判斷發動，而是由一個明確、可記錄、可設定門檻的旗標發動。這和「主管覺得這份寫得不夠好」是完全不同性質的東西——前者可以被稽核、被調整、被統計，後者不行。
四、架構上的兩個實用模式
複合評分
遇到複雜判斷時，不要問一個宏觀問題。評估一份創業企劃，不要問「這個案子好不好」，而是拆成市場規模、技術可行性、團隊背景、創新性四個原子問題，再在程式碼裡加權。這樣做除了穩定，還有一個更重要的好處：當結果有爭議時，你能指出是哪一項拉低了分數。
護欄
在把使用者輸入送進昂貴的推理模型之前，先用低延遲的模型偵測提示注入或有害內容。因為延遲低到使用者無感，這層檢查可以預設全開，而不是只在可疑時才跑。
同樣的邏輯適用於監控：原本只夠抽查 5% 的預算，現在可能足以支撐 100% 的即時掃描。這是成本結構改變之後最實際的一個後果。
五、但請把這幾件事一起讀進去
這是我認為多數介紹文章交代得不夠的部分。
第一，所有數字都是廠商自報。TypeSafe 沒有釋出模型權重，也沒有發表足以讓外部研究者重現的論文。RLCD 的獎勵函數怎麼設計、底層架構是什麼，目前都沒有公開。有評論直接稱它是個黑盒子。67.8% 對 66.8% 這個比較，來自 TypeSafe 自己的測試。
第二，「零幻覺」只指格式。官方的說法是型別錯誤在數學上不可能發生——這是真的，因為輸出空間是預先定義好的。但這跟語義正確完全是兩回事。Jev 依然會把 A 判成 B，只是它會用一個型別正確的方式判錯。
第四，目前仍是封閉的早期測試。發表後 36 小時內處理了約 14 萬筆候補名單，但那是自報的候補數字，不是使用留存率。
六、沒有理由的決策，能放在哪裡
第三點值得展開，因為它決定了這類工具的邊界在哪裡。
在受監管的環境裡，一個決策要能被接受，通常需要三樣東西：結果、理由、以及當初是誰決定的。一個 0.93 的分數提供了第一樣，可以記錄下第三樣，但第二樣永遠是空的。
所以我的判斷是：這類模型適合擔任分流器，不適合擔任決策者。分流是可以被事後檢驗的——你可以統計有多少件被自動放行、其中多少件後來被發現有問題，然後調整門檻。但如果一個結論本身要寫進正式紀錄、要作為後續處置的依據，那就需要理由，而理由現階段只能由人或由另一個能解釋的系統補上。
換個角度說：Jev 適合出現在流程的入口（決定這件事該往哪走、該不該讓人看），不適合出現在流程的出口（決定這件事的結論是什麼）。
七、它適合與不適合什麼
| 適合 | 不適合 |
|---|---|
| 分類（上限 255 項）、評分（2–10 階）、真偽判定 | 寫文字、生成程式碼、長鏈推理 |
| 低延遲、高併發的系統中繼任務 | 需要說明「為什麼」的場景 |
| 把人力導向最需要覆核的案件 | 要寫進正式紀錄、作為處置依據的結論 |
| 原本因成本只能抽樣的全量監控 | 目前也還不適合關鍵路徑——它仍在封閉測試 |
真正有意思的轉向不是「AI 不再說話」，而是這個問題被重新問了一次：哪些決策需要理由，哪些只需要一個可靠的機率？過去我們把兩者混在同一個聊天視窗裡，既慢又貴，而且無論哪一種都得到一段同樣自信的散文。把它們拆開之後，前者仍然需要能解釋的系統和人；後者可以變成軟體裡一個像
if
一樣穩定的語義開關。這個區分，比任何一款模型都活得久。
資料來源：TypeSafe AI 於 2026 年 9 月 15 日發表 Jev 並宣布 4,000 萬美元募資，目前為封閉早期測試。技術細節（RLCD、平行取樣器、70–500 毫秒延遲、每百萬輸入 token 0.042 美元、輸出免費）取自官方發表材料與公開報導；性能比較與候補人數為廠商自報，尚無獨立驗證，亦未釋出論文或模型權重。插圖為內嵌 SVG，屬示意性質。