Liquid d1 決策模型登場：AI 分類郵件，為什麼不必先寫一段答案？
Liquid d1 直接回傳固定選項的機率。用客服分流案例，理解分類定義、機率門檻和實際導入成本。
客服信箱收到一封信，軟體最想知道的可能只有一件事：這封應該交給訂單、帳務，還是技術支援？如果先請 AI 寫一篇分析，再從文字中找出部門名稱，就多了一層整理工作。答案即使讀起來合理，程式也可能因為拼字、格式或多餘解釋，無法順利接下去。
Liquid AI 在 2026 年 9 月介紹 d1 決策模型，官方 X 發布貼文查核時已有超過八十八萬次瀏覽。這類模型的重點，是直接評估事先定義好的結果，回傳各結果的機率。它把許多軟體需要的分類步驟，從一段需要閱讀的文字，改成可以直接處理的數值。
我的判斷是：d1 值得優先用在答案範圍固定、錯誤可以回頭檢查的分流工作。真正的難題會移到另一個地方：選項怎麼定義、機率多少才採取動作，以及資訊不足時交給誰。格式穩定只是開始，團隊仍要證明分類結果符合自己的業務規則。
決策模型，把已知選項變成可比較的機率
一般聊天模型適合產生開放內容，例如回信、摘要或解釋。決策模型則適合在已知選項中做判斷。Liquid 官方文件說明，模型可以在一次呼叫中回傳固定結果的機率，沒有逐字生成的輸出。這項設計省去解析長篇回答的步驟，並讓下游程式清楚知道收到哪一類資料。
先想像信件分流。系統已有訂單、帳務、技術與其他四個部門，就能詢問每個分類的可能性。收到結果後，程式可以根據最高機率與預先設定的規則，決定是否轉交。這和要求模型自由提出一個部門名稱，對工程維護有不同的影響，因為系統不必猜測新的文字是否代表既有選項。
但模型只能在你提供的問題框架中判斷。如果信件同時要求退款與修改帳號，四個互斥分類可能太粗。模型即使成功回傳四個機率，流程也可能漏掉第二個需求。因此，上線前先研究真實信件有哪些情況，比先把選項名稱寫得漂亮更有價值。
分類的範圍也不宜隨意擴大。某個部門本來負責付款問題，後來接手優惠券，原有規則可能就需要調整。把類別定義與變更日期保留下來，才能比較不同版本的結果。否則分類表偷偷改變，報表中的正確率也會失去共同的衡量基準。
三種輸出，對應三種不同問題
官方文件列出三種主要形式。Noul 回答是非問題，以零到一之間的機率表示判斷。Choice 在沒有大小順序的類別間選擇。Score 則針對有順序的評分規準，回傳可比較的結果。選擇哪一種形式，應先看業務問題是否真的具有這種結構。
「這封信是否提到退款」適合是非判斷。「這封信由哪個部門處理」適合無順序分類。「這項需求有多緊急」則需要先定義程度，才適合有順序的評分。緊急程度不能只靠低、中、高三個字，還應說明哪些情況屬於每一級，讓人工標記與模型判斷能對照。
在是非機率中，接近中間的數值代表判斷不明確，不能直接當成問題的強度。例如退款機率接近一半，可能是信中用語模糊，也可能是同時提到退款與取消。它並不代表顧客有一半不滿。把機率誤讀成情緒強度，容易讓報表產生看似精準的錯誤解釋。
同一個工作也可能需要多個問題。可以分別判斷是否涉及退款、是否需要技術協助，再決定主責部門。這樣的設計比硬塞進單一類別更接近實際流程。不過問題愈多，團隊要維護的定義也愈多，應保留真正會影響下一個動作的判斷，避免收集一堆沒有用途的分數。
回傳有效格式，還要證明業務判斷正確
固定輸出對軟體很有幫助，因為不必處理模型忽然多寫一段說明的情況。但格式符合要求，和內容符合事實，是兩個需要分別檢查的項目。系統可能收到一組完全有效的機率，卻把改地址需求分到技術支援。測試若只檢查資料能否讀取，就會漏掉這種錯誤。
可以先整理一批已處理過的信件，留下實際內容、正確接手部門與判斷理由。資料應包含常見需求、少見需求，以及容易混淆的邊界案例。若只選措辭清楚的信件，測試會比真實環境容易很多。加入短句、打字錯誤與多個需求，才有機會看見流程在哪裡失準。
人工答案也需要一致。如果兩位客服對同一封信分到不同部門，問題可能出在內部分工。這時繼續調模型，未必能消除爭議。先讓團隊釐清接手規則，再把規則寫進測試資料，才有一個可信的參考答案。這項整理工作也會讓新進同事更容易理解流程。
測試資料和正式輸入應使用相同版本的定義。分類結果若需要覆核，應讓覆核者看到原文與規則，而不只是模型給出的類別。模型的數字有時會讓人先入為主，先完成獨立判斷，再對照結果，通常更容易找出定義不清或輸入缺漏的地方。
門檻應由錯誤後果決定
系統拿到機率後，仍需決定什麼時候自動分流。沒有一個數值能適用所有公司。部門轉錯後只需重新指派，和轉錯後錯過客戶時限，影響相差很大。門檻應由實際代價與測試結果共同決定，不能因為某個數字看起來很高，就認為可以放心執行。
可以先把結果分成自動處理、人工確認與資訊不足三種狀態。清楚且符合測試條件的需求自動轉交，其餘留在等待覆核佇列。這裡的佇列就是一份尚未完成判斷的工作清單。它必須有接手者與期限，否則模型雖然避免做錯，工作仍會停在沒有人處理的地方。
除了最高機率，也可以觀察前兩個分類是否接近。若訂單與帳務都很有可能，最高者稍微領先，未必代表需求已足夠明確。這是流程設計上的參考方式，實際規則仍要以自己的資料驗證。不要把一個合理想法，直接寫成產品保證具有的判斷能力。
機率是否可靠，還可以用分組方式檢查。把相近機率的歷史判斷放在一起，看實際正確比例是否接近。若數字很高的那組仍經常分錯，使用者就需要重新檢查資料、規則或模型適配程度。機率的價值，在於能幫助安排覆核資源，而非讓錯誤看起來更有權威。
沒有生成文字，仍有運算與整合成本
Liquid 文件使用沒有生成輸出字詞的描述，這不等於沒有推論成本。模型仍須讀取輸入、完成計算並傳回結果。網路等待、系統整合、重試與人工處理也會影響總時間。評估時應量整個分流流程，而非只看回傳資料很短，就推定每封信一定更便宜。
官方範例目前使用 d1:free 作為模型名稱。這是查核時文件提供的試用範例，不能據此承諾所有使用情境永遠免費。正式導入仍應確認當時的帳號條件、可用量與服務安排。本文沒有實際呼叫模型服務，也沒有用自己的郵件資料完成效能或價格測試。
成本比較應包含每封成功分流的總支出。若便宜模型需要較多覆核，人工時間可能抵銷省下的運算費。相反地，即使單次呼叫稍貴，只要降低來回指派與待處理時間，整體流程仍可能更划算。先訂衡量單位，才不會比較兩個完全不同的成本數字。
整合時也要保留失敗路徑。服務暫時無法連線、輸入過長或資料缺少必要欄位，都應留下可追查狀態。不要把沒有取得結果的信件，直接當成其他類別。輸入與輸出紀錄應能對回同一封信，讓重試和人工處理不會造成重複轉交。
選項有限的任務，適合先小範圍試做
決策模型很適合拿來思考哪些步驟其實只需要有限答案。文件分類、訊息分流、資料是否完整，都可以先盤點。但有些任務需要提出新觀點、解釋原因或寫出完整內容，聊天模型仍有作用。兩類工具可以分工，不必把每個工作都改成固定選項。
例如客服流程可以先由決策模型判斷主題，再讓寫作模型根據已確認的資料準備回覆草稿。最後由客服檢查內容與處理權限。每個步驟都有自己的完成條件，系統也能記錄錯誤發生在哪一段。這會比一個模型同時判斷、轉交和回信，更容易分析問題。
第一輪試做應挑一種訊息、一個接手流程，並先保留現有人工方式。讓模型產生建議但暫時不自動轉交，觀察哪些情況最常需要改判。這種並行比較能建立具體證據，也讓團隊知道後續要改的是模型設定、資料品質，還是原本的工作規則。
有了結果，再決定要不要開放部分自動處理。記錄每次改規則的理由，並保留一組沒有參與調整的資料，檢查新規則是否仍有效。若所有例子都被拿來修設定，最後的成績可能只是熟悉舊資料的表現，無法說明遇到新信件時是否同樣可靠。
常見問題
d1 可以取代聊天模型嗎？
適用範圍不同。d1 面向答案事先已知的結構化判斷。寫摘要、產生程式或開放對話，需要生成新的內容，仍應選擇對應工具。先把一個工作拆成判斷與產出兩部分，通常更容易看出哪裡值得採用決策模型。
機率最高的類別就一定正確嗎？
最高機率只是模型在指定選項中的判斷。選項可能缺少真正答案，輸入也可能不足。應保留其他與等待覆核路徑，並用已知答案資料檢查實際錯誤。數字能協助管理不確定性，無法代替原文與業務定義。
沒有輸出字詞，就不用付費嗎？
沒有逐字生成輸出，仍需要計算、服務與整合。官方範例的免費模型名稱不構成長期價格承諾。正式導入要查當時條件，並計算成功處理一項工作的總成本，包含人工覆核與重試。
從一個有明確答案的流程開始
Liquid d1 最值得帶來的改變，是讓團隊重新區分「需要新內容」與「需要在已知答案中選擇」的工作。選項、機率與後續動作接得清楚，軟體就比較容易維護。若規則模糊，固定格式也只會把模糊的判斷送得更快。
下一步可以挑一小批已結案的客服信件，先寫出分類定義與資訊不足的處理方法。再用這批資料檢查建議結果，記錄錯誤和覆核時間。當你能說明哪些信件適合自動分流、哪些必須交給人，才有足夠依據把新模型接進日常流程。
