Jeff 決策模型：28 毫秒很快，選錯第 27 個選項怎麼辦？（2026）

2026 年 9 月 28 日，開發者 firelex 在 GitHub 公開了〈Jeff〉，一組可在本機執行的開放權重分類模型；9 月 29 日又發布 v1.1。Jeff 決策模型吸引人的地方，是讓程式把「下一步選哪個選項」交給小模型，而不必先等模型寫出一段文字。讀完原文與使用者回報後，更值得追問的是：快到數十毫秒的判斷，究竟在哪些題目可靠？

這篇先把 Jeff 的主張與數字放回原來的測試條件，再看一個社群使用者抓出的長選項漏洞，最後判斷它適合放在哪種決策環節。

Jeff 決策模型做的是什麼？

你給模型一段狀態、一個問題，以及「帳務」「物流」「帳號」等候選選項和描述；Jeff 回傳各選項的機率與選出的答案。它沿用 Jev 風格的 Choice、Noul、Score 請求格式，但專案明說兩者沒有隸屬關係。TypeSafe 的 Choice 文件也確認，這種介面的答案空間由呼叫者先定義，回應含每個選項的機率。相容的是請求形狀，並不保證兩個模型會做出相同判斷。

Reason in code, decide with Jeff.

中文：讓程式處理規則與流程，再讓 Jeff 做局部選擇。

Jeff 專案 README，「Using it well」

這句話也是原文最好的邊界。Jeff 可以替客服單選主責隊伍，或在已列出的遊戲動作中挑一個；它讀到的選項描述越清楚，越容易作出有用的局部判斷。若任務要求先發現未知選項、推導數步後果，或核對外部事實，單次分類輸出本身做不到那些工作。

原文還展示三款模型：Qwen3.5 的 0.8B、2B，及仍停在 v1.0 的 Gemma 4 E2B。作者用 Doom、Frogger、Pac-Man 示範把遊戲狀態與動作後果寫成選項，也另做棋類與語音導覽的領域微調；這些案例說明「先寫清楚候選動作，再由模型挑選」的思路。作者同時提醒，遊戲不等於一般文字分類，公開題分數也不能直接預測遊戲表現。訓練在自有硬體完成、合成資料由開放模型產生，是專案的製作紀錄，本文未獨立重現。

28 毫秒與 82.0%：兩種數字不能混讀

專案作者報告：Jeff-Qwen3.5-0.8B 在 Apple M4 Max 的 MLX 後端，對約 200 個輸入 token、一次一題的 200 個測試問題，中位數為每次 28 毫秒；RTX PRO 6000 上為 22 毫秒。這是作者在指定硬體與工作負載上的本機量測，不是跨裝置、含網路與後續動作的端到端延遲，也不是 AlphaLab 的實測。

準確度看的是另一回事。README 的 v1.1 表格把 0.8B、2B 在五組公開題上的整體分數列為 79.1% 與 82.0%，另列 Jev 已發表的 83.0%。但 README 自己註明，Jev 的數字使用同名基準中的不同題目樣本；「82.0 對 83.0」不能當作同題、同條件的勝負。更關鍵的是，在偏重推理的 BBH、JudgeBench 和 JevBench hard tier，Jeff 的分數明顯低於表中的 Jev 已發表值。這更像一個速度與任務範圍的取捨，而不是通用推理能力的替代品。

The two times were not measured on the same hardware.

中文：原文自己提醒，Jeff 與 Jev 的兩種時間不是在相同硬體條件下量到的。

Jeff 專案 README，「Games: a zero-shot test」

一次可重現的失敗，讓 v1.1 更值得看

9 月 29 日，一位使用者在專案 Issue #1貼出測試：同一句「訂往 Zurich 的機票」，把 Zurich 排在第 28 個選項時，v1.0 的 0.8B 與 2B 都選錯；移到第 3 個時，兩者又選對。回報者還在三組意圖資料上測了兩個模型共 1,458 次回答，記錄到第 27 個以後的選項一次也沒被選中。這是有版本、設定、程式與輸出的獨立原始測試，但它只證明被測 v1.0 在這些設定下的問題。

作者隨後在 v1.1 加入長清單訓練題，宣稱 0.8B 在自家的長清單測試從 40.3% 升至 94.7%，並把 Qwen 兩款的可接受上限改成 254 個選項。這是修正說明與作者測試，尚不能直接當作獨立驗證。開放程式碼與權重的真正價值，在於他人能像 Issue #1 一樣搬動選項位置、換資料與重跑，而不必只看行銷摘要。

版本變動還影響另一個標籤：README 承認 v1.1 的訓練資料加入 MASSIVE 與 CLINC150 的訓練切分，因此這兩組題目不應再被直接稱為「完全零樣本」證據。專案的「zero-shot classification」描述可以指呼叫時自行定義選項的能力；評測某一資料集是否真正未見過，仍要看訓練資料與測試切分。

我同意它的方向，也會保留三個問號

我同意：大量重複、答案集合清楚的分流任務，確實值得先試小模型。與其讓生成式模型寫一段話再解析，不如直接取得選項機率，讓程式決定是否放行、複核或回退。Jeff 把這種設計帶到可在本機檢查的權重與程式碼，降低了測試門檻。

我存疑：第一，28 毫秒不能回答真實流程從輸入到完成有多快；還要算資料準備、載入、網路、重試與錯誤處理。第二，「有機率」不等於「可放心自動執行」：若客服分類錯把退款單送去物流，省下的毫秒可能換來更長的人工補救。第三，公開基準與自家長清單修正尚不足以證明繁體中文、長文件、選項分布變動後也會維持同樣表現。作者自己把目前範圍寫成英文與文字輸入，其他語言要另測。

It’s a classifier, not a planner.

中文：它負責在給定選項間分類，不負責規劃多步行動。

Jeff 專案 README，「Using it well」

因此，Jeff 決策模型最合理的起點是低風險、可回復、可留人工出口的分流節點。若你的應用已有資料，先凍結選項定義，再用同一批保留題比較 Jeff v1.1、現用模型、簡單分類器和人工；同時報錯誤率、未答或轉人工比例，以及完整流程延遲。若只是把錯誤更快地送出去，單次推論再快也沒有省下真正的成本。