決策模型是什麼？Jev、Clef 與 OpenAI 一次搞懂

決策模型（decision model）能協助軟體在你預先定義的選項中做出選擇。你給它一則訊息、一個問題和一組允許的選項，它就會回傳一個帶有機率的判斷結果。大型語言模型（LLM）能生成全新的文字回覆，而決策模型能幫你決定那則訊息應該先送到哪裡。

TypeSafe 的 Jev、Cloudflare 的 Clef，以及 OpenAI 的 Decisions API 都支援這種有明確範圍的判斷。應用程式可以用它們來選擇支援佇列、辨識問題類型，或評估嚴重程度。後續的撰寫工作則交給生成式模型。

一則訊息，兩種不同的工作

假設一位客戶寫道：「同一筆訂單被收了兩次費用。」支援系統有兩件事要做：把工單送到正確的團隊，並由某人撰寫有用的回覆。這兩件事需要不同的輸出。

生成式 LLM 可能會寫出：「我可以幫你查看那筆扣款。」而決策模型可以回答「哪個團隊應該處理這個問題？」，答案是 billing，從 billing、technical 和 review 中選出。

應用程式可以直接檢查這個答案。它可能會將工單路由到帳務團隊，或在結果不確定時送交審查。之後再由人或另一個模型來撰寫回覆。決策模型負責的是整體流程中一項聚焦的判斷。TypeSafe 的 System One 介紹描述了這種分工方式。

下圖比較了兩種模型在同一個路由問題上的表現。文字模型產生 JSON 格式的答案；決策模型則對三個允許的選項進行評分。

決策介面通常支援三種問題類型：選擇一個選項、判斷某件事是否為真，或給出一個分數。你提供證據並定義答案的含義。同一則客戶訊息可以支撐多個獨立的判斷。

TypeSafe 將這些稱為 Choice、Noul 和 Score。OpenAI 則使用 choice、predicate 和 score。Predicate 就是一個是/否問題。

問題的措辭很重要。「哪個團隊應該優先回應？」要求的是單一團隊。「這則訊息是否提到帳務問題？」和「這則訊息是否提到技術問題？」是兩個獨立的問題，兩者都可以得到「是」。如果一張工單描述了兩個問題，強行歸入單一類別可能會遺失有用的資訊。

LLM 也可以在 JSON（一種軟體可讀取的資料格式）中回傳類別。透過結構化輸出，支援的 schema 可以將答案限制在允許的值之內。這使得 LLM 成為許多分類任務的可行替代方案。

差別在於專用決策模型產生答案的方式。傳統的 LLM 以序列方式生成文字，使用稱為 token 的小片段。即使輸出只是 {"team":"billing"}，本質上仍然是文字生成。

Cloudflare 的 Clef 則是讀取輸入後直接對允許的答案進行評分，而非逐 token 生成答案。Cloudflare 在其 Clef 公告中描述了這種做法。Clef 仍然使用 LLM 作為理解輸入的基礎。

OpenAI 的文件記載了 Decisions API 的輸入與輸出，但並未證實其使用 Clef 的內部設計。介面相似不代表底層架構相同。

兩種做法都能回傳有效的類別，但仍然可能選錯。有效的類別仍需要與客戶的實際問題相符。

這些產品提供軟體可以直接檢查的判斷結果。Jev 是 TypeSafe 的決策模型。Clef 是 Cloudflare 的可下載模型系列，也可透過 Workers AI 使用。OpenAI 提供 Decisions API 處理有明確範圍的問題。要從中選擇，需要在實際任務上測試。

產品	首先需要了解的
TypeSafe Jev	以文字與結構化資料上的型別化問題為核心設計。訓練目標是產生實用且校準良好的機率值。
Cloudflare Clef 與 Clef-flash	提供可下載的權重與託管服務。其公開的設計以語言模型為骨幹，對答案進行評分。
OpenAI Decisions API	用於選項選擇、是/否判斷和評分的託管介面。目前為公開測試版，使用 `gpt-6-luna`。

它們的回應格式與支援的輸入各不相同。OpenAI 也可能回傳拒絕（refusal），應用程式必須處理這種情況。從一個供應商切換到另一個，意味著需要同時檢查整合方式和答案品質。

機率代表的是模型針對你所提出的問題，對某個答案的估計值。比起只回傳勝出的標籤，機率提供了更多資訊。但在用這些數字決定哪些案例可以跳過人工審查之前，仍然需要實際測試。

想像我們的工單得到以下結果：

帳務的機率明顯最高。如果是一則同時涉及扣款和儀表板故障的混合訊息，帳務可能得到 52%，技術得到 43%。帳務仍然勝出，但兩者機率接近，讓應用程式有理由要求人工審查。

校準（calibration）是指檢驗機率是否在大量範例中與實際結果相符。在約 90% 的相似預測中，一個校準良好的模型應該有大約 90% 的正確率。單一標記為 90% 的答案仍然可能是錯的。

一個名為「信心」（confidence）的欄位可能用來表示機率的集中程度。它並不代表實際測得的成功率。TypeSafe 的信心指南解釋了這個區別。

當任務需要解讀語意，且可能的答案已知時，決策模型就很有用。常見應用包括路由訊息、選取相關文件，以及根據評分標準對項目進行評分。它們可以與負責撰寫或調查的生成式模型搭配使用。

避免產生生成式回覆可以減少模型的工作量。這是否能改善速度或成本，取決於整個應用程式，包括網路延遲、輸入大小和備援呼叫。比較時，應該拿決策模型跟被要求回答同一個簡短問題的 LLM 比，而不是跟一個會產生冗長解釋的 LLM 比。

它們也有其限制。決策模型可能誤讀訊息、選錯允許的選項，或過度自信。獨立的 Red Hat 護欄測試發現 Jev 在一項任務上表現最強，但在另一項任務上被其他方案超越。這些測試並未比較全部三個產品。

對於精確計算和權限檢查，請使用一般程式碼。當任務需要新的回覆、程式碼或解釋時，請使用生成式模型。要試用決策模型，請從一個小型判斷開始，收集具有已知答案的範例，並衡量它犯的錯誤以及它所節省的工作量。

Jev 和 Clef 的決策介面回傳的是選項與分數，而非新的文字。OpenAI 的 Decisions API 同樣回傳有明確範圍的答案。當應用程式需要書面解釋時，請使用文字生成模型。

你可以直接定義問題與允許的答案，不需要訓練新模型。不過你仍然需要具有已知結果的範例，用來驗證準確度並判斷哪些結果可以自動採用。

決策模型回傳的是判斷結果。你的應用程式決定是否採用、檢查權限，並執行任何動作。選取退款標籤並不代表授權退款。