hero

這是針對 Sebastian Raschka 於 2026 年 9 月 29 日發表的長文所做的原創技術整理與分析，不是 10 月 17 日的新產品發布，更不是原文逐節翻譯。Raschka 借文字分類技術史追問一件實務問題：如果只需要「把輸入歸類、選一個動作、附上可信的信心」，為何還要用會長篇生成文字的聊天模型？他以 Jev 作為新型決策模型的例子，同時保留對架構、訓練與測試證據的疑問。

原文摘要

起點：便宜的詞袋方法沒有消失

傳統分類器面對長短不一的文章，通常先將文字轉成固定長度的特徵。詞袋（bag-of-words）把詞彙表中的每個詞對應到一個位置，統計某篇文本各詞出現的次數，再交由樸素貝氏、邏輯迴歸或其他分類器決定標籤。文件有十個詞或三百個詞，向量維度都取決於詞彙表；大量位置為零。TF-IDF 可調整權重，但基本問題仍在：單純詞袋看不到字詞順序。「人咬狗」和「狗咬人」可能得到同樣的計數；加入雙詞組或 n-gram 能補一部分局部順序，也會增加特徵空間。Raschka 的詞袋段落因此不把這個方法當古董，而當低成本、易重現的基準線。

這條基準線有數字佐證，但要讀對範圍：Raschka 引用自己使用 IMDb 電影評論資料集的教學實驗，詞袋加邏輯迴歸得到約 89.9% 準確率；一個從零開始訓練的 LSTM 範例約 85.66%。這不是「詞袋普遍比循環網路強」的結論；模型大小、預處理、調參與是否先經大資料預訓練都會改變比較。例如文章提到的 ULMFiT 先預訓練再微調，在其研究設定下得到 95.4% IMDb 測試準確率。把三個不同訓練流程的百分比排成線性進化史，反而會漏掉預訓練的作用。

順序、上下文與輸出頭各解決不同問題

詞向量（embedding）讓模型不只計數，而以密集向量表示輸入單位；早期固定詞向量仍會把不同語境的同一個詞映成同一向量。RNN／LSTM 沿著輸入順序更新隱藏狀態，因此能感受到先後關係，卻必須逐步處理，長距離訊息受有限狀態約束。文字 CNN 擅長擷取局部片段，可藉更深層堆疊擴大觀察範圍；Transformer 則以注意力處理詞與上下文的關係。這些架構的差異不是「新的一定在每種分類題勝過舊的」，而是它們各自負擔不同的訓練成本、延遲與泛化需求。原文從 RNN、CNN 到 Transformer 的圖解提供了這條脈絡。

拿到語言表示之後，怎樣產生標籤仍是另一個設計選擇。BERT 類編碼器可取 [CLS] 的表示接分類頭；GPT 類解碼器可利用最後非 padding token 的狀態接分類頭，也可直接生成 positive 等文字。前者讓輸出限制在定義好的類別；後者利用通用模型既有的生成能力，但為了一個簡單決策仍需產生 token、處理格式與不必要的輸出。T5 一類編碼器—解碼器也能走分類頭或文字生成路線。把「底層是否是 Transformer」與「對外是自由文字還是固定型別答案」分開，才看得懂 Jev 為何有市場：它賣的並非人類直到今天才會做分類，而是跨任務不必各自微調的決策介面。

Jev 的三種決策介面與各自適用的問題

TypeSafe AI 在 9 月 15 日的產品說明把 Jev 定位為輸入非結構化狀態、輸出預先定義型別及機率的「System One」模型，並稱其訓練採 Reinforcement Learning for Calibrated Decisions（RLCD）。那是供應商對架構和訓練方向的說法；完整模型架構、資料與 RLCD 細節沒有公開。供應商還聲稱其服務的回應時間與價格優勢，但官方自行設計的工作流程評測以大模型的平均答案作參考，並非全都有獨立標註的真值；官方也承認測試流程由自家團隊設計，可能帶入偏差。這些資訊應與外部測試分開看。

Raschka 的實作說明把 API 用法拆成三類。Choice 接收一組互斥候選及各自的定義，用於多選一分類，回傳被選標籤、各類機率與 confidence；Noul 針對一個是非判斷回傳數值，可同時獨立問多個問題以支援多標籤，這些答案並不要求加總為一；Score 依預先定義的等級規則做序位分類。若把一封客服信分成「帳務／技術／帳號」之一，Choice 自然；若同一封信可能同時涉及帳務與帳號，多個獨立 Noul 問題較符合任務。這是類別之間是否互斥的差別，不只是三種端點名字不同。

文章提供一個小而重要的警訊：對同一則正面電影評論範例，Choice 給正面類別的示例輸出是 1.0；換成 Noul 的正面判斷卻是 0.98。兩種介面的數值不宜直接視為同一個事件的同一個機率，更不能因回傳欄位叫 confidence，就認為特定業務資料上已經驗證過校準品質。若要把分數拿去作自動拒件或風險分流，先要知道問題怎麼問、類別怎麼定義，以及不同群組是否呈現相同的錯誤率。

25,000 則影評的實測能說明什麼

Raschka 使用 IMDb 25,000 則測試評論跑 Jev：Choice 正確 24,117 則、準確率 96.47%，用時 22 分 24 秒，報告的總費用 0.6492 美元；Noul 正確 24,050 則、96.20%，用時 23 分 3 秒，總費用 0.6345 美元。這是作者自己的 API 實測，與 TypeSafe 的公司 benchmark 不同。文章指出重跑 Choice 也可能得到略有差異的成績，故兩種 API 之間的微小差距不宜過度解釋。更重要的是，外部並不知道 IMDb 測試集是否出現在 Jev 的訓練材料裡；結果描述的是這組公開測試的表現，而不是保證全新領域也有相同泛化。IMDb 實測與重跑討論保留了這個限制。

作者也在 DGX Spark 上微調一個 ModernBERT 對照：微調約 23 分鐘，測試集推論約 7 分鐘；它需要專用訓練步驟，但之後本地部署可以避免每次都送資料給外部服務。另一方面，Jev 不需為 IMDb 收集專用訓練集就得到上述成績。這不是同硬體、同網路與同部署限制下的嚴格吞吐量對照：API 的並行方式、排隊、成本計法與本地硬體折舊都不同。當任務固定、請求量大、資料敏感時，微調本地模型仍有價值；任務常變、標註資料不足時，免微調的決策服務可能較省啟動工。

API 很容易仿，跨任務能力不容易仿

Raschka 展示一個可理解的 Jev-like Choice 設計：把輸入、任務說明、各個候選描述分別送進 BERT 或 GPT 類編碼表示，讓共用的一個輸出頭逐候選產生分數，再在候選分數之間做 softmax。候選數量改變，頭部參數無須跟著改；訓練時可以對正確選項最小化交叉熵。這解釋了為什麼「做一個像 Jev 的 API」與「做出 Jev 在各領域的效果」不是同一道題。作者曾做出 ModernBERT 原型，後來沒有將它當完整替代品釋出：電影評論分類學得好，不表示模型會在客服路由、遊戲狀態、規則判斷都同樣可靠。訓練資料覆蓋及跨任務評測，比把幾個端點名稱模仿出來更難。原型架構與限制也因此沒有被寫成 Jev 的真實內部架構。

TypeSafe 未公開 Jev 詳細架構與 RLCD 公式。原文推測它可能接近小型 ModernBERT，也討論一篇不同團隊、不同方法的 RLCR 論文：在正確性獎勵外，再懲罰與答案對錯不符的信心估計。RLCR 的 HotpotQA 等實驗數字，不能當作 Jev 使用 RLCR、或 Jev 已在那些題目複製結果的證據。這個對照只能幫讀者理解「獎勵答對」與「獎勵信心也說準」是兩種目標。

校準是後者的驗收方式之一：如果模型在大量案例中說「正面機率約 0.8」，同一群案例中約八成真的應為正面，這才接近校準。交叉熵在理想條件下本來就鼓勵合理機率，有限資料和過擬合卻可能讓實際信心失真；溫度縮放等後處理可在保留集調整機率，而不必改變最高分標籤。scikit-learn 校準文件說明了可靠度圖與不同方法的用法。即使單一測試集的總準確率漂亮，也不足以判定按時間、新客戶或新語言切分後的機率仍可信。

對開發者的具體選擇

從工程角度看，應先界定答案型態、漏判與誤判代價，再挑方案：標籤少而固定、已有標註且必須本地保存資料，先跑詞袋＋邏輯迴歸和小型編碼器基準；任務頻繁換規則、還來不及蒐集標註，才測試 Jev 類服務與便宜的生成模型。評測不能只報一個 accuracy：還要測類別不平衡時的召回、改寫標籤描述後的穩定性、低信心人工接手的門檻、延遲分布、資料外送規則與在本公司保留集上的機率校準。這些是基於文章所述介面與限制提出的通用驗收項目，不是 Raschka 已替每個部署環境做過的實驗。

這篇 9 月舊文在 10 月新聞匯總再次出現，最值得保留的不是「分類器取代 LLM」這句口號，而是兩個可拆開檢查的問題：需要的是生成，還是決策？返回的機率能否在自己的資料上被驗證？ Jev 的展示與 Raschka 的實測讓第一個問題有了便宜、快速的候選答案；第二個問題仍須由實際部署者以自己的標註、錯誤成本與資料治理條件回答。