Jeff：與 Jev 相容的 0.8B 與 2B 決策模型，用於零樣本分類

Jeff 是一系列小型、開放權重的語言模型，專為零樣本分類進行了微調。透過單次前向傳遞（forward pass）來返回一組選項的校準機率，而無需生成文字，Jeff 為傳統基於 LLM 的分類提供了一種高速替代方案。0.8B 參數模型在 NVIDIA RTX PRO 6000 上可達到約 22ms 的決策延遲，在 Apple M4 Max（透過 MLX）上則為 28ms。

高速決策

Jeff 的主要價值在於極致的速度與成本效益。與需要迭代 Token 的生成式 LLM 不同，Jeff 作為分類器可以直接嵌入應用程式碼中。

效能指標

模型	參數	NVIDIA RTX PRO 6000	Apple M4 Max (MLX)	CPU (32 執行緒)
Jeff-Qwen3.5-0.8B	0.8B	22 ms	28 ms	463 ms
Jeff-Qwen3.5-2B	2B	24 ms	60 ms	708 ms
Jeff-Gemma4-E2B	2B effective	29 ms	N/A	1.0 s

這些速度允許進行即時決策迴圈，例如語音導航或遊戲 AI，在這些場景中，傳統基於 API 的模型（如 Jev）可能會引入過高的延遲（例如每次呼叫 114–212 ms）。

零樣本分類與基準測試

Jeff 專為零樣本任務設計，使用者以簡單的文字描述情況與選項列表，模型隨後根據描述選擇最可能的選項。

基準測試結果

在五項公開基準測試中，Jeff-Qwen3.5-2B 模型達到了 83.1% 的總體準確率，與 Jev 公布的數據（83.0%）相當。雖然 Jeff 在分類與接地（grounding）任務中表現出色——在 Financial PhraseBank（96.3% 對 77.0%）與 RAGTruth（88.9% 對 77.3%）上超越了 Jev——但在推理密集型基準測試中則較為落後：

• BBH: 64-68% (Jeff) 對 94.3% (Jev)
• JudgeBench: 60-64% (Jeff) 對 78.6% (Jev)
• JevBench Hard: 47-53% (Jeff) 對 73.3% (Jev)

考慮到這些模型體積較小（0.8B 至 2B 參數），這種效能差距在預期之內，因為它們旨在作為「系統 1」的判斷者，而非多步驟推理者。

本地訓練與實作

Jeff 完全在本地硬體上建構，使用了一台 RTX PRO 6000 工作站 GPU。訓練過程包括對權重進行一個 Epoch 的完整微調，批次大小為 256，並對選項字母進行交叉熵計算。

• 合成資料： 訓練資料由 Qwen3.8-Flash-Next 在兩台 DGX Sparks 上生成，封閉模型僅用於品質抽查。
• 訓練時間： 0.8B 模型訓練約需 2 小時，2B 模型約需 3.5 小時。
• 微調： 對於特定領域的任務，短時間的微調可以顯著提高準確率。在一個範例中，語音導航任務在單個 GPU 上不到 30 分鐘內，準確率從 31.7% 提升至 95.8%。

實際應用：遊戲測試

為了測試非基準資料上的零樣本能力，Jeff 被用於遊玩三款遊戲：Doom、Frogger 與 Pac-Man。

• Doom： Jeff-0.8B 在每集達到 6.55 次擊殺，與手寫規則機器人及 Jev 的公開執行結果相當。
• Frogger： Jeff-0.8B 達到 10.3 次過關，顯著優於未經訓練的基礎模型（1.0）。
• Pac-Man： Jeff-0.8B 收集了 57 顆豆子，約為規則機器人效能的 60%。

使用指南與注意事項

為了最大化 Jeff 的效能，開發者應遵循以下準則：

• 在程式碼中推理，用 Jeff 決策： 將 Jeff 作為分類器使用，而非規劃器。提供動作的後果（例如「這個動作會讓你被車撞」），而不是要求它預測未來狀態。
• 措辭很重要： 選項的一致性與描述性措辭至關重要。描述目標的方式若有微小變化，可能會導致效能顯著提升。
• 選項鍵： 使用短鍵（例如 {"1": "Refund request"}）以最小化延遲與 Token 開銷。

社群回饋

雖然該專案因其本地優先的方法與速度而受到讚譽，但一些使用者指出，零樣本準確率會根據使用案例而有巨大差異。一位使用者報告稱，在他們的特定應用中，與 Jev 相比存在顯著的準確率差距（70% 對 94%），這凸顯了針對專業任務進行微調的重要性。

專案歷史與授權

Jeff 是 AutoJev 的分支，AutoJev 是一個用於微調模型以返回 Jev 風格決策的開源配方。權重以 Apache 2.0 授權發布，程式碼則以 MIT 授權發布。