AI-LECTURER 速報課|2026-09-17|約 26 分鐘

當AI放棄「打字」:Jev想用「型別保證」取代「幻覺風險」

取材:Introducing System One Models and Jev(Hacker News(AI 高人氣))
📍 真實場景
阿凱,某中型電商平台的後端工程師,負責維護「退貨自動裁決」服務

這個服務會把每一筆退貨申請丟給LLM判斷「要不要自動核准」,規定AI一定要回傳固定格式的JSON,一天大約要跑六萬次判斷

😖 卡住的地方:尖峰時段常常塞車,因為AI要一個字一個字把整段JSON生完,平均要等1.5秒才拿到答案;更糟的是平均每天總有幾十次AI吐出來的JSON漏了括號或多了逗點,後端parser直接噴錯,得整筆丟進重試佇列,搞得他半夜常常被告警吵醒
💡 這篇會讓阿凱看到,有一種新模型乾脆把「生文字」這一步整個跳過,直接吐出保證能解析、還附機率的判斷結果,號稱快上百倍——以及這種做法犧牲了什麼、還剩下什麼風險沒解決

🧭 這到底是什麼(白話版)

這篇文章的作者Diogo Almeida,以前在OpenAI參與打造讓LLM大型語言模型,像ChatGPT這種會「一個字一個字生成文字」的AI乖乖聽指令、好好聊天的技術,這些研究後來變成ChatGPT背後的關鍵功夫之一。他觀察到一個奇怪的現象:LLM在聊天這件事上已經強到超乎常人,但真正被自動化取代的工作卻沒有想像中多——問題出在哪?

他的答案是:現有LLM的強項是「生文字」,可是企業真正需要的往往不是文字,而是「決策」,例如「這筆訂單要不要核准」「這封信是不是詐騙」。要讓LLM做決策,得先讓它生一段字串(通常是JSON),再由程式碼去解析、驗證;這個過程既慢又容易出包,因為字串本質上什麼都能長,連格式錯誤、答非所問、幻覺(hallucination)AI自信滿滿地說出根本不存在或不正確的內容都算在合法輸出範圍內。TypeSafe AI因此提出「System One Models」這個新類別,第一款公開模型叫Jev,直接把「生文字」這一步跳過,改成輸出結構化輸出答案侷限在事先規定好的格式裡,例如只能回傳「是/否」加上一個0~1的信心分數,不能亂回其他文字,保證不會出現格式錯誤。

要做到這件事,TypeSafe AI換了一套訓練方式。現有LLM多半是用RLHF讓人類幫AI的回答打分數,再用這些分數去調整AI,讓它的回答更討人類喜歡的訓練方式或是「可驗證正確性」的方式去訓練,說白了就是看「人類喜不喜歡」或「答案對不對得上標準答案」。Jev用的是他們自創的Reinforcement Learning for Calibrated Decisions(RLCD),獎勵訊號改成「這個機率有沒有校準(calibration)AI講的信心分數要跟真實命中率吻合,例如講「90%有信心」的判斷裡,真的要有九成是對的」,換句話說,它在乎的不是答案聽起來順不順耳,而是信心分數準不準。

另一個關鍵差異在「怎麼算出答案」。現有LLM是序列採樣(sequential sampling)AI生成文字時要一個字接一個字生,後面的字得等前面的字先跑出來才能生,這也是它們常常讓人等的原因;Jev改用平行採樣(parallel sampling)一次查詢就把所有可能的答案同時算完,不用排隊一個字一個字生,官方宣稱因此快上兩個數量級(也就是差不多一百倍),而且更省算力。目前Jev還在早期使用(early access)產品尚未正式對外公開,只先開放一小群人試用,好蒐集回饋階段,還沒有大規模公開數據可以驗證,這點在解讀「快一百倍」這類宣稱時值得放在心上。

🎯 為什麼值得你花時間

終於有東西不用「猜格式」現有LLM輸出的是字串,後端還得自己parse、驗證,格式一壞整條流程就炸;結構化輸出把「型別正確」變成模型本身的保證,不用再賭運氣
快一百倍不是行銷詞,是取樣方式不同序列採樣要一個字接一個字排隊,平行採樣一次查詢就算完;對客服判斷、風控攔截、推薦系統這種要即時反應的場景,延遲差一個數量級會直接影響使用者體感
「不會幻覺」背後是砍掉了創造力Jev用犧牲字串生成的彈性(不能聊天、不能寫文案)換來可靠度,這是一種取捨,不是免費升級——代表它不會取代所有LLM用途,只是切走了「決策」這一塊

⚙️ 它是怎麼運作的

1
輸入現況,不用特別包裝成對話把目前的程式狀態或文字資料直接丟進去,不用刻意寫成「使用者說…AI回答…」這種聊天格式
2
模型架構專門為決策設計不是通用的文字接龍模型,而是設計成一次能吐出多個型別化欄位(例如布林值、信心分數)的模型
3
用RLCD訓練,獎勵訊號是「校準」訓練時不是看人類喜不喜歡這個答案,而是看模型講的信心分數跟實際命中率吻不吻合
4
平行採樣,一次查詢全部算完不像傳統LLM要一個字一個字生成,Jev在同一次查詢裡把所有可能的輸出欄位平行算出來
5
輸出型別保證正確的結構化值拿到的結果已經是規定好的型別加上機率分數,後端可以直接使用,不用再寫容錯parser
現有LLM vs System One + Jev,差在哪
面向現有LLM(RLHF / RLVR)System One + Jev(RLCD)
訓練方式用人類打分數(RLHF)或可驗證正確性(RLVR)用「校準決策」當獎勵訊號(RLCD)
優化目標人類比較喜歡的文字、或能驗證對錯的答案答案的機率有沒有校準到跟真實命中率一致
輸出型態字串,理論上什麼都能生,但要自己解析、驗證事先定義好的型別化結構,附機率,不會型別錯誤
取樣方式序列——一個字接一個字生平行——一次查詢就把所有欄位算完
會不會幻覺有可能亂編內容、格式錯誤官方宣稱不會,但只保證型別正確,不保證判斷一定對

🛠️ 動手做:傳統LLM vs System One:同一個決策,兩種做法一起跑給你看

  1. 把三個任務都試一次,看看兩邊的行為有沒有不一樣
  2. 連續按5~10次「同時丟給兩邊模型跑跑看」,數數看左邊出現幾次JSON解析失敗
  3. 比較兩邊的耗時數字,感受平行採樣跟序列生成的落差
  4. 想想看:如果你的系統一天要跑十萬次這種判斷,哪一種做法比較適合上線?
👇 下面是活的,直接操作

🧠 工程思維透鏡(資深工程師看到的是什麼)

🔭 犧牲「生成文字的彈性」真的划算嗎?
多數LLM的萬用性來自「什麼都能講」,但很多生產環境其實只需要決策,不需要散文。System One把泛用性換成速度與型別安全,這是「通用模型 vs 專用模型」的經典取捨,有點像CPU跟ASIC的關係:ASIC對特定任務快很多,但換了任務就沒用了。
🔭 「不會幻覺」是真的做到,還是把幻覺藏起來了?
型別安全只保證格式不會錯,不保證判斷內容一定正確。信心分數校準得好不好才是關鍵——如果校準做得爛,一樣會有系統性偏誤,只是不會再長得像亂七八糟的字串,而是變成一個看起來很正經、但其實不準的機率數字,反而更難被工程師察覺。
🔭 為什麼一家早期使用階段的新創,敢說服工程師換掉推論後端?
換一個新推論後端牽涉到監控重建、重新驗證、供應商風險,這些轉換成本不小。只有在「延遲/幻覺已經痛到不行」的場景(像阿凱的退貨裁決系統)才值得冒險先試,這也反映了技術採用曲線的現實:早期使用者往往是被現有方案的痛點逼出來的,不是被宣稱的效能數字說服的。

📝 隨堂考(點選答案,立即回饋)

Q1. Jev跟一般LLM最大的差異是什麼?
✅ 文中明說Jev「gives up string generation」,改成輸出typed probabilistic decisions,也就是型別保證正確的結構化決策。
Q2. 文中的RLCD跟RLHF/RLVR最主要的差別是什麼?
✅ 文中比較表格寫得很清楚:RLHF/RLVR優化人類喜好或可驗證獎勵,RLCD優化的是「校準決策」。
Q3. 為什麼System One的取樣方式被說成「平行」?
✅ 文中提到現有LLM是sequential(一次一個token),Jev是parallel(單次查詢生成所有輸出),這也是效率差異的主要來源。
Q4. 文中提到「Jev不會產生幻覺」,這句話比較精確的理解是?
✅ 文中的「不會幻覺」是針對型別安全而言——輸出被限制在事先定義好的結構裡,不代表判斷內容一定正確,只是不會出現格式錯亂。
Q5. 什麼情境最適合考慮像Jev這種System One模型?
✅ Jev的設計目標就是取代「LLM生字串再parse」這種容易出錯又慢的流程,最適合高頻率、格式固定的結構化決策任務。

🃏 翻牌記憶卡(先想答案,再點開對答)

System One Models點我翻面
TypeSafe AI提出的新模型類別,捨棄文字生成,專門做快速的結構化決策
Jev點我翻面
TypeSafe AI首個公開的System One模型,號稱比現有LLM快上百倍,目前開放早期使用
RLCD點我翻面
Reinforcement Learning for Calibrated Decisions,用「機率是否校準」當獎勵訊號的訓練法
校準(calibration)點我翻面
模型講的信心分數要符合真實命中率,例如講90%有信心的判斷裡真的要有九成是對的
平行採樣點我翻面
一次查詢就把所有輸出算完,不用像傳統LLM一個字一個字排隊生成
結構化輸出點我翻面
答案侷限在事先定義好的型別欄位裡,保證不會出現解析失敗或格式錯誤

✅ 離開前自測(全勾=這課真的學會了)

0%