Cloudflare推出Clef與Clef-flash兩款開源 decision model,整合至Workers AI,主打以更低延遲完成分類、路由與下一步決策,適合 AI agent 工作流程。
Cloudflare 近期開源 Clef 與 Clef-flash 兩款 decision model,並已整合至 Workers AI,可直接供開發者呼叫使用,同時以 Apache 2.0 授權開放模型權重。兩款模型也提供與 Jev 相容的程式介面,讓既有採用 Jev 的應用較容易遷移。來源
這次發布的定位相當明確:Clef 不是用來產生長篇文字的 generative model,而是專注在 AI agent 的分類、判斷與下一步動作選擇。Cloudflare 同步說明,Clef 與 Clef-flash 也可從 Hugging Face 取得模型權重自行部署,並開始提供模型微調服務,未來還規劃讓客戶以自助方式完成資料準備、微調與重新部署。來源
決策模型與一般 LLM 的核心差異,在於輸出形態與推論流程。一般 LLM 會逐步生成文字,適合對話、摘要與工具操作;Clef 則先讀取輸入,再直接對預先定義的答案集合計分,輸出符合格式的決策結果與各選項機率,因此更適合結構化判斷。來源
Cloudflare 公布的設計重點包括多模態輸入、64K context,以及與 Jev 類似的 typed questions 工作模式。依官方資料,Clef 可讀取文字、JSON、圖片或影片,並回傳每個允許選項的機率;Clef-flash 則強調速度,適合延遲敏感的自動化流程。來源
在模型基礎上,Cloudflare 表示 Clef 與 Clef-flash 分別以 Qwen3.8-27B 與 Qwen3.5-9B 為基礎,再針對 decision task 進行訓練。其關鍵優勢在於推論方式不同於生成式模型,因為模型不需要先產生一段文字再由系統解析,而是直接對候選答案做評分,這使得分類與路由類工作能大幅縮短處理時間。來源
Cloudflare 公布的 43 項評測結果顯示,Clef 的中位延遲為 209.3 毫秒,Clef-flash 為 38.8 毫秒,Jev 為 524.1 毫秒。這代表在需要快速判斷的代理式流程中,Clef 系列可顯著壓縮等待時間,但同時也不能忽略不同測試項目中的準確度差異,因為部分測試仍由 Jev 取得較高成績。來源
從工程角度看,這類模型最適合被嵌入客服分流、工單優先級判定、風險標記、流程決策與資料審核等場景。其價值不在生成能力,而在穩定輸出可直接被系統消化的結構化結果,進而減少人工介入。來源
對使用 Cloudflare Workers AI 的團隊而言,Clef 的導入門檻相對低,因為可直接透過平台呼叫,不必自行建置完整模型推論環境。對已有 Jev 介面整合的系統來說,相容介面也降低了切換成本。來源
對 AI agent 開發者而言,這代表決策層可以從大型生成模型中拆分出來,形成更清楚的職責分工。大型語言模型負責理解、生成與工具調用,決策模型則負責分類、路由與下一步選擇,整體可降低流程中的不確定性。來源
對安全與營運團隊而言,這類模型有機會用於告警分流、事件嚴重度判定與案件升級規則,但也意味著組織需要更嚴謹地設計輸入格式、答案集合與人工覆核邏輯,否則決策錯誤會直接影響後續處置。來源
此外,Cloudflare 同步釋出微調服務,顯示其不只提供模型本體,也試圖進一步切入企業客製化決策流程。這會讓模型更貼近各產業情境,但同時也提高了資料品質與標註一致性的要求。來源
若組織考慮導入 Clef,第一步應先將決策範圍明確化,避免讓模型處理超出答案集合的問題。輸入欄位、可選答案與失敗回退機制都應事先定義,確保模型只在可控範圍內做判斷。來源
第二步應建立人工覆核條件,特別是高風險案件、低信心輸出或關鍵流程節點,不能完全依賴模型自動決策。若模型無法確定,應保留轉人工處理的路徑,以降低誤判成本。來源
第三步應針對資料來源進行驗證,尤其是圖片、文字與 JSON 混合輸入時,要防範垃圾資料、格式污染與惡意誘導內容。對於客服、工單與告警系統,建議先做欄位標準化,再交由決策模型處理。來源
第四步應將模型評估拆成延遲、準確度與失敗率三個層面,不可只看速度。Cloudflare 公布的結果已顯示,不同測試下的領先者可能不同,因此在真實環境中更需要以自家資料進行驗證。來源
第五步應檢查供應鏈與部署路徑。若採用 Workers AI,需確認權限控管、日誌留存與 API 存取策略;若採用 Hugging Face 自行部署,則應同步檢查模型權重、版本管理與更新流程,避免未授權變更影響決策品質。來源