【2026 最新】CLM 本機教學：Choice／Noul／Score 怎麼跑？十題驗收 Agent 決策

你讓 AI Agent 幫忙把客服訊息分給帳務或技術團隊。一般聊天模型會先寫一段解釋；CLM 本機教學要解決的，是把「目前發生什麼事」和「有哪些動作可選」交給決策器，直接拿到一組選項分數。可是速度快，並不代表遇到未知案件時會自動停手。

這篇寫給第一次接觸本機決策模型、願意照著終端機指令操作的讀者。我會從零拆開 CLM 的運作方式，帶你照官方範例送出 Choice、Noul、Score，再給十道可自己重跑的驗收題。文中的測例是待執行的測試設計；AlphaLab 這次沒有可支援官方 vLLM 範例的 GPU 環境，因此不會填入推測的正確率或延遲。

先說結論：CLM 本機教學的三個重點

• CLM 的核心可記成：狀態編碼 × 候選動作編碼 → 分數 → 選擇。它評比你給的候選項，不靠生成一段自由文字作答。
• 截至 2026 年 10 月 1 日，官方 CLM-v0.1-8B 範例需要 Qwen3-8B 編碼服務與 CLM 投影頭；約 75 MB 的頭檔不是整個 8B 模型。
• 把「其他／交人工」列成真實候選項，再用獨立的門檻和人工複核流程決定何時棄權。先收集自己的錯題與延遲，再談替換現有 Jev 式呼叫。

CLM 是什麼？先看一張決策便條

想像你拿著一張客服便條：左邊寫「客人說發票重複扣款」，右邊有「帳務」「技術」「其他」三張處理卡。CLM 分別把便條與處理卡變成向量，再比較哪張卡與便條最相配。官方把這叫 state（狀態）與 action（候選動作）分開編碼；候選卡反覆使用時，可以重用已算過的向量。官方架構說明也指出，已發佈的推論組合是凍結的 Qwen3-8B 主幹加上分別處理狀態與動作的投影頭。

這也是它和一般生成式聊天的分工差別：前者適合先從有限動作中選一個，後者適合產出新的內容。CLM 可以成為 Agent 的決策零件，卻不能用一個高分代替整套風險規則。若你想先看 Agent 的完整循環，可讀Agent Harness 白話篇；要把決策器接入程式循環，再看Harness 實作篇。

CLM 本機教學：三種題型與一次完整追蹤

① Choice：「這張單要去哪裡？」

Choice 會在你提供的選項說明之間評分，回傳被選中的 key 與各選項的 probabilities。假設 state 是「發票被扣了兩次」，criteria 寫成 {"billing":"扣款、發票與退款","technical":"登入錯誤與服務故障","other":"資訊不足，交人工確認"}。你要看的是實際回傳哪個 key、正確答案是否在候選集合，以及不同改寫會不會翻盤；本文不預填模型結果。官方 API Reference 說明了 Choice 的欄位與輸出。

② Noul：「這件事需要立即處理嗎？」

Noul 回傳介於零與一之間的 p_true，適合問一個二元判斷。它的數字不是已替你的客服任務校準好的「真實事故機率」：要決定例如 p_true ≥ 0.8 才升級，必須先在另外一批有標記的案件上檢查誤報與漏報，並記下門檻。

③ Score：「情緒落在哪一級？」

Score 接收按順序排列的等級，如「平靜、困擾、憤怒」，回傳預期等級索引與各級分布。若回傳 1.7，意思接近第二與第三級的加權位置，並非你能直接宣稱「情緒強度 1.7 分」的醫學量表。這三個問題可以共用同一段 state，一次請求拿回三種答案。

CLM 本機教學：照官方範例啟動與送出第一題

先確認你有能跑 Qwen3-8B 編碼服務的 GPU、可用記憶體與模型下載空間。官方 Quickstart 用 vLLM 服務 Qwen/Qwen3-8B，再由 clm-serve 提供 8700 埠 API；頭檔初次執行才下載。完整依賴與 GPU 相容性請按自己的系統核對當前 Quickstart。本文的指令是官方路徑的操作說明，不代表已在你的硬體上驗證。

1. 在 Python 環境執行 python -m pip install contrastive-lm；另依官方專案的依賴說明安裝適用的 PyTorch、vLLM 與 GPU 驅動。不要把「pip 安裝成功」當作編碼服務可啟動。
2. 啟動編碼器：vllm serve Qwen/Qwen3-8B --served-model-name qwen3-8b --runner pooling --max-model-len 2048 --port 8090。讓這個終端機保持運作。
3. 開第二個終端機執行 clm-serve。依官方預設，瀏覽器可打開 http://127.0.0.1:8700/ 查看 Playground；先確認 http://127.0.0.1:8700/health 回應，再送出題目。

最小請求可用 Python 客戶端：from clm import CLMClient, Choice, Noul, Score；建立 client = CLMClient()，再呼叫 client.system_one(state="Customer: my invoice was charged twice", questions={"team": Choice(instructions="Which team?", criteria={"billing":"Charges and refunds","technical":"Bugs and outages","other":"Unclear; human review"}), "urgent": Noul(instructions="Needs immediate attention?"), "tone": Score(instructions="How frustrated?", criteria=["Calm","Concerned","Angry"])})。印出 r.answers、r.usage.input_tokens 與 r.latency_ms，先保留完整回應供複查。這段語法依官方 Python 範例改成同一組客服題。

官方預設將超過 2048 token 的 state 截斷；若要驗長文，編碼器的 --max-model-len 和 CLM 的 --max-tokens 要一起調整，並重新量測記憶體與延遲。不要只把長文丟進同一組預設值，就把結果解釋成「模型讀完全文」。

十題驗收：先填標準答案，再看選擇與棄權

建立一份只含虛構資料的測試紀錄。每題先固定 state、問題、選項說明與人工標準答案，再記 CLM 原始輸出、你的外層路由決定、暖機前後延遲和記憶體峰值。下面十題是可重跑的測例，不是本篇的已完成跑分：

1. 「發票重複扣款」→ Choice 預期 billing。
2. 「登入後顯示 500 錯誤」→ Choice 預期 technical。
3. 「請問退款何時入帳」→ Choice 預期 billing。
4. 「查詢團隊方案報價」→ 若候選只有 billing、technical、other，預期 other；加上 sales 後另跑一次，觀察候選集合改變的影響。
5. 「請幫我處理」→ 資訊不足，預期外層流程交人工。
6. 同時說「重複扣款」和「無法登入」→ 預期外層流程交人工，記下模型選擇與理由欄位是否能支持複核。
7. 「整站無法使用，所有客戶受影響」→ Noul 的人工標記為急件；在獨立校準集選出的門檻下檢查。
8. 「下週有空再回覆即可」→ Noul 的人工標記為非急件；同時看誤報。
9. 「我已經等三天，真的很生氣」→ Score 標為最高情緒級；記錄連續值與各級分布。
10. 把第 1 題關鍵句放到長文字的開頭與結尾各跑一次 → 標準答案仍是 billing；分別記錄輸入 token、截斷設定和輸出，檢查長文位置效應。

第 5、6 題考的不是模型是否「選對 other」，而是你的 Agent 是否真的能停下來。實作時可先明訂：若候選項是 other，或最高分與第二名差距低於你用獨立標記資料選定的門檻，就送人工；這只是待校準的外層規則，不能把本文示例門檻直接用於正式案件。統計時分開報「有答案題的正確率」「需交人工題的成功棄權率」「漏放率」；十題是冒煙測試，不足以宣稱整體準確率。

和 Jev 式方案同題對照，怎麼才算公平？

先固定同一份 state、選項文字、題型、答案與失敗定義，再分別呼叫 CLM 和你現有的 Jev 式端點。TypeSafe 官方介紹與 CLM 的相容 API 都採用 Choice／Noul／Score 類型，但欄位相近不等於模型能力、機率校準或硬體成本相同。若你還不熟悉 Jev 的決策形式，先讀Jev 白話解析；未知選項的設計可接著讀Choice 棄權教學。

CLM 至少各跑冷啟動與暖機後的一輪；Jev 式託管端點用同一批請求重複量測。分開記錄伺服器時間、從程式送出到收到回應的端到端時間、每題輸入長度、GPU／CPU 與記憶體。CLM 的 r.latency_ms 是回應欄位；Jev 的網路呼叫要用同一台客戶端計時。官方 README 的「最高快 9 倍」是作者在指定工作負載與硬體下的報告，不是你的十題預期結果。官方也公開了 T-Rex 等實驗程式，適合查測試範圍；不同資料、主幹與快取狀態不能直接互比。

一份 2026 年 9 月 25 日公開的獨立長輸入案例紀錄，用 CLM-v0.1-8B 與託管 Jev 評估 140 對資料，作者說在其實體關聯任務中無法直接替換。其原始資料未公開，40 筆標準標籤由另一個模型製作，所以它是「長輸入與門檻值得重測」的警訊，不是 CLM 在其他任務的總排名。要看另一種本機決策器如何規劃交人工，也可參考本機決策與棄權教學。

最常踩的四個坑

1. 把 75 MB 認成整個模型。那是參考投影頭；主幹仍是 Qwen3-8B。下載與部署估算要把兩部分算進去。
2. 把 softmax 分布當成可直接信任的風險機率。分數會隨候選項描述、集合與溫度改變；決策門檻要在自己的任務資料上校準。
3. 把選項外案件硬塞進已知類別。加上 other 與交人工路徑，並量測真正的漏放率；不要只看 overall accuracy。
4. 只量暖快取或只看伺服器延遲。記下冷／暖、候選項數量、端到端時間與資源。官方快取說明也把重複狀態和全新狀態分開報告。

FAQ：開始前先回答八個問題

CLM 是聊天模型嗎？

就本文的官方推論 API 而言，它用狀態與候選項回傳選擇、分數或排序；要寫自然語言回覆，Agent 還需接其他產生內容的步驟。

裝好 contrastive-lm 就能跑嗎？

還要依官方 Quickstart 啟動相符的 Qwen3-8B 編碼器與 CLM 服務，並確認模型檔、驅動與記憶體。

Noul 的 0.8 能直接當急件門檻嗎？

不能直接套用；先用獨立標記資料選門檻，再看漏報與誤報。0.8 在本文只示範門檻的寫法。

Choice 會自己說「我不知道」嗎？

依目前官方 Choice schema，它回傳候選集合中的 choice 和分布。你可以提供 other 作為選項，再由外層流程決定交人工。

長輸入只調一個長度參數可以嗎？

官方說明要求同時調整編碼器 --max-model-len 與 CLM --max-tokens；調長後另記資源與輸出變化。

十題全對，就能上線自動分流嗎？

不能。十題只檢查基本接線和幾種失敗型態；正式門檻仍需更大、獨立且貼近實際分布的標記資料。

官方九倍速度是我的預期嗎？

不是。那是官方在指定任務與設定下的自報結果；你的結果取決於硬體、網路、快取、輸入長度與候選數。

何時值得接進現有 Agent？

當你有明確的有限動作、可標記的錯誤案例、能交人工的路徑，且同題比較顯示任務品質與資源符合你的要求時，再從低風險流量開始。

給新手的三個重點與下一步

記住這句話：狀態編碼 × 候選動作編碼 → 分數 → 選擇。先寫好選項與人工答案，再跑模型；把交人工當成真正的動作；最後才比較正確率、棄權與端到端延遲。想把這套驗收接到完整 Agent，AlphaLab 課程有更多從零上手的練習。