工具呼叫準確率對代理式應用的關鍵影響

在服務開放權重模型時，工具呼叫（Tool Call）的準確性是決定應用品質的核心因素。當模型生成的工具呼叫不符合預定的 JSON Schema 結構時，推理引擎無法正確解析指令，導致後續步驟建立在無意義或錯誤的上下文之上。

Ubicloud 工程師 Jesse Donkervliet 與 Junhao Li 指出，這種情況在需要多輪互動的代理式工作負載（Agentic Workloads）中尤為嚴重。若工具呼叫失敗，系統必須重試，這不僅增加計算成本，還會因錯誤訊息佔用上下文視窗而降低模型整體表現。

以 Kimi K2.6 為例，當使用 vLLM 0.28 版本服務時，僅有 92% 的請求能產生符合預期的工具呼叫架構，意味著每 25 次嘗試就有 2 次失敗。社群討論指出，若單次成功率為 95%，在一個需要連續執行 50 個工具呼叫的任務中，整體無錯誤完成的機率僅剩約 8%。

受限解碼技術如何強制結構正確性

傳統做法依賴模型訓練後的自由生成能力，信任模型能遵循結構化模式，但語言模型的機率性質意味著即使提示詞清晰，仍可能產生格式錯誤的輸出。例如，模型可能因訓練數據偏差而生成不存在的工具名稱或欄位。

受限解碼（Constrained Decoding）改變了這一機制，它不再讓模型自由生成後再驗證結果，而是在生成的每一步驟中，僅允許符合語法規則的 Token 被採樣。vLLM 利用 XGrammar 庫實現此功能，透過結構標籤定義工具呼叫的有效路徑，包括開始標記、函數名稱、索引及參數格式。

在生成過程中，推理引擎會根據提供的 Schema 動態計算並遮罩無效的 Token。例如，當進入參數階段時，引擎僅允許符合 JSON 語法的 Token 通過，其他則被屏蔽。這種方法將架構準確率從「盡力而為」轉變為執行時的保證，且由於預計算 Token 遮罩並在 GPU 上高效應用，其帶來的效能開銷可忽略不計。

vLLM 版本演進與預設行為的衝突

Moonshot AI（Kimi 開發商）建議啟用受限解碼，其官方 API 亦預設開啟此功能。Ubicloud 最初在 vLLM 分支中自行實作該功能，後轉用上游 vLLM 0.25 版本提供的支援。然而，隨後發現工具呼叫準確率降至 91%。

調查顯示，vLLM 的受限解碼實作本身正確，但為了維持對多種模型的廣泛相容性，vLLM 維護者將預設行為改為關閉此功能。這是因為部分模型（如 gpt-oss-20b、Qwen 3.6、GLM 5.1）在強制受限下可能偏離預期輸出，或存在語法轉換錯誤及與其他功能（如投機解碼）的互動 Bug。

vLLM 隨後引入了 --tool-strict-level 旗標，允許使用者針對特定部署啟用工具呼叫嚴格模式。Ubicloud 基於服務 Kimi 和 DeepSeek 模型的品質要求，選擇手動啟用此設定，並通過 K2VV ToolCall 基準測試驗證準確率達到 100% 後才部署至生產環境。

社群觀點與未解的品質影響爭議

社群評論指出，Ubicloud 的文章標題易讓人誤以為是修復了 vLLM 的 Bug，實際上主要是配置問題。vLLM 團隊成員 mmastrac 補充，受限解碼技術同樣用於將自回歸模型轉換為特定端點，且工具定義可能在執行期間動態變化，增加了處理複雜度。

另有開發者質疑受限解碼對模型輸出分佈的潛在影響，並提出「備份與重試」策略作為替代方案。該觀點認為，雖然重試會增加少量 Token 消耗（約 9%），但不改變模型本身的生成邏輯，且同樣能達到高準確率，建議比較兩者對最終任務品質的實際差異。

Ubicloud 作者回應稱，整合 LLM、推理引擎與受限解碼以確保預期輸出需要嚴謹的工程測試。目前文章主要聚焦於解決架構符合性問題，並未提供啟用受限解碼後對模型語義理解或內容品質深層影響的詳細數據比較。