Drex 1.5 開放權重：讓本機模型回傳選項機率，怎麼做客服分流？
Drex 1.5 是回傳選項機率的決策模型，開放權重與程式。用帳單、帳戶、產品與人工接手的客服例子，說明本機部署、標記資料、拒判條件與錯誤驗收。
Drex 1.5 是 Nace 釋出的決策模型，讀取一段狀態與命名選項後，回傳各選項的機率。模型權重是訓練完成的核心參數，下載後可用來部署模型。
客服問題不一定需要模型先寫一整段回答。有些流程最先要做的事，只是分辨這封訊息該進帳單、帳戶還是產品說明，再交給適合的人處理。
這是決策模型與聊天模型的差別。前者把問題對應到預先設定的選項，後者生成自然語言內容，兩種輸出可以放進不同的工作階段。
依 2026 年 10 月 10 日核對的官方文件，Drex 1.5 提供權重與程式，可透過官方支援的執行方式自架。它的結果仍要在自己的資料上驗證。
我會先拿它做低風險分流，保留人工接手，而不是讓最高分直接觸發退款或停權。讀者可以從一小份客服題目，建立可測的分類與拒判條件。
Drex 1.5 回傳機率，怎麼接進客服？
先把需求縮小成「這封訊息由誰先看」。輸入包括需要判斷的內容與選項，輸出是選項機率，讓後面的程式或負責人決定下一步。
官方程式庫提供的 API 是供程式呼叫模型的介面。它接受狀態與命名問題，問題可以是是非、多選或評分，客服分流可以從多選問題開始。
假設訊息是「我已付款但沒有收到收據」，候選部門包含帳單、帳戶與產品。模型可以為這些選項給出分數，但分數不等於事情已經處理完成。
付款問題可能還需要查交易記錄，帳戶問題可能需要驗證身分。分類只決定第一站，不能替代這些工作，也不應自動生成承諾或向客戶發出處理結果。
這個分工有助於縮小測試範圍。你可以先問路由有沒有選對，再測負責人後續怎麼解答，不必一次評估整套自主客服系統。
為什麼要保留「不確定」的處理方式？
客戶可能同時提出「帳號進不去，也不知道付款有沒有成功」。硬選一個類別，會讓接手部門只看其中一半，留下另一個問題沒有人負責。
設計時可以加入不確定選項，或在應用層設定人工接手條件。這是讀者自己的分流規則，不表示模型會自動替所有難題做正確拒判。
最高分也可能只有略高於第二名。這種結果表示選項之間不容易分開，應用程式要根據自己的驗證資料決定是否轉人工，而非只拿第一名執行。
機率還需要校準，也就是檢查高分是否真的比較常答對。如果模型在你自己的客服題目中常常高分選錯，單看數值便不適合做自動路由依據。
部署之前，先確認模型、分支與授權
官方程式庫列出 Python、llama.cpp 與 Ollama 三種執行方向。它們是讓模型執行的工具，但不是每個一般發行版本都已經支援決策模型請求。
Drex 1.5 的官方文件指定 Nace 的相關分支。準備自架時，先確認下載的是對應模型與支援分支，不能只裝常見 Ollama 版本就假設所有介面能直接使用。
Python 路線適合依官方參考實作準備環境。llama.cpp 與 Ollama 路線則需要按模型檔案準備相應格式與編譯條件，硬體支援也要用對應說明核對。
這裡的教學重點是選擇部署路線與驗證模型是否正確載入。實際安裝命令應從官方模型頁複製，保留版本資訊，避免之後升級卻不知道結果為什麼變了。
第一次載入後，先以官方示例請求檢查服務，再放自己的客服題目。模型沒載入、請求格式錯誤與分類失誤是不同問題，需要分開記錄。
開放權重與開放程式的授權一致嗎？
不一定。官方程式庫寫明程式採用 Apache-2.0，模型權重另看各模型頁。Drex 1.5 與 Drex DLM 也有不同的權重授權，不能混在一起談。
Drex 1.5 列 Nace.AI Open RAIL-M，Drex DLM 列非商用的 CC BY-NC 4.0。若要用於企業客服，先確認自己選的模型與用途符合對應條件。
下載得到檔案與能否用於你的業務是兩件事。部署記錄可以寫模型名稱、來源、版本與授權條款位置，之後接手的人就不會把另一個模型的條件套過來。
模型大小也不能當成每臺電腦的效能保證。載入格式、硬體記憶體與同時處理的任務都會影響使用體驗，先以自己的小批資料測等待時間與穩定性。
用人工標記資料建立分流規則
本文的假設客服分流有四個方向：帳單、帳戶、產品與人工接手。先寫每一類的說明，再準備題目，避免標記者只憑直覺理解標籤。
帳單包括付款、收據與方案費用。帳戶包括登入與帳號存取，產品包括功能操作。多重問題、訊息不完整與敏感處置則先由人工看。
這些邊界是案例設定，不是 Drex 官方提供的客服分類。讀者需要按自己的組織分工修改，若兩個部門本來就處理同一種問題，標籤也應重新安排。
準備一批去除個人資料的歷史問題，或自行設計測試題。先讓人工標記正確第一站，再給模型讀取，不要拿模型自己的結果當作標準答案。
人工意見不一致的題目，要先討論標籤邊界。若同樣一封信，兩位客服都無法判斷該送哪個部門，問題可能出在流程本身，不能直接把失誤歸給模型。
測試資料要包含哪些難題？
除了簡單題，也準備短訊息、口語錯字與多重問題。真實客服不會每次都寫得像說明書，測試若只用完整標準句，就看不出分流遇到邊緣情境的表現。
「收不到信」就是一個容易模糊的例子。它可能指登入驗證，也可能指付款收據，訊息不完整時應回人工，或進一步收集說明，不要只憑關鍵詞就決定。
再加入與業務無關的內容，例如廣告或無法識別的附件說明。即使模型總能給出一個最高分，也不表示這封訊息屬於任何一個既有部門。
保留另一批沒有參與規則調整的題目，作為最後驗證。否則你可能只把門檻調到已看過的題目表現很好，卻不知道新訊息能不能正確分類。
門檻從錯誤類型決定，不直接照抄分數
拒判門檻應依驗證結果選擇。門檻太低可能把模糊訊息送錯，太高則讓大量問題回人工，最後要比較的，是分類品質與人工工作量。
可以先記錄最高分、第二名與實際正確類別，再看哪些錯誤反覆出現。分數接近的題目是否經常送錯，只有用這份資料才能回答。
本文不設一個適用所有團隊的固定門檻。若帳單分類錯誤會拖延退款流程，與一般功能說明被分錯的代價不同，就應採用對應的人工接手條件。
驗收也分開看每一類。整體準確率不錯，可能掩蓋帳戶問題經常被誤送產品部門，這會讓某類客戶持續等待，不應只看一個平均數字。
| 核對項目 | 要回答的問題 | 可以採取的修正 |
|---|---|---|
| 帳單分流 | 付款與收據問題有沒有送對？ | 澄清類別與補測試題 |
| 帳戶分流 | 登入問題是否被產品類吸走？ | 調整邊界與人工接手 |
| 模糊訊息 | 缺資料時是否仍強制選第一名？ | 設拒判與補充資訊流程 |
| 多重問題 | 是否漏掉訊息中的另一項需求？ | 人工拆單或共同接手 |
| 高分錯誤 | 很有把握的結果是否仍常選錯？ | 檢查校準與模型適用性 |
每次調整標籤或門檻，都保留舊規則與測試結果。這樣才能知道錯誤減少來自哪一次變化，也能在升級模型後確認沒有發生迴歸。
多重問題由誰負責完整接手？
分流表還要規定一個主要負責人。客戶同時提到帳號與付款時，若兩個部門都以為另一方會處理，模型即使選對第一站，問題仍可能停在原地。
可以由第一站負責人確認是否需要拆成兩件工作，再把第二項交給對應部門。這是客服流程的設計，模型只提供分類線索，不能替團隊完成協作。
拒判也要有落點。回人工的訊息進哪個待辦、由誰看、怎麼記錄最後類別，都需要先寫好，否則不確定結果只是換一種方式堆積。
人工改判原因可以用簡單文字記錄，例如資料不足、雙重需求或標籤邊界模糊。下一輪檢查時分開看，才能決定該補資料、改類別還是調整門檻。
若錯誤來自組織分工，先修流程再重測。一直替模型增加題目，卻沒有統一部門責任，會讓測試資料含有互相矛盾的答案。
報告結果時也分開列自動路由與人工接手。人工確認後的正確率不能拿來宣稱模型獨立判斷同樣可靠，保留差別才能評估下一步是否適合自動化。
上線先只路由，保留可以回查的記錄
小批測試通過後，先進入有人確認的流程。模型提出第一站，客服確認再接手，期間記錄人工改了哪些結果，當作下一輪改進資料。
不要讓分類結果直接退款、發信或封帳。這些動作牽涉更多事實與權限，先完成路由品質驗收，再另行建立對應處置流程。
記錄裡可以保留經去識別的題目編號、模型版本、選項分數與人工決定。避免把完整個人資訊散放在測試檔案，資料只保留完成評估需要的範圍。
分流變慢時，先分辨是模型載入、排隊還是單題處理時間。若同時來很多訊息，也要測試等待過程，不以一題成功推斷持續工作一定穩定。
升級後用原來的驗證題目回測，再看新客服題。模型版本與分流規則各有變動時分開測，能減少問題發生後找不到原因的情況。
一個月後是否繼續使用，可以看錯送數量、人工改判與處理等待。這個判斷不需要世界第一排名，只需要結果對自己的客服流程確實有用。
延伸閱讀：Ollama 支援本機決策模型：把快速分類留在電腦，部署前要確認什麼？
延伸閱讀：Cresta × Marshawn Lynch「Beast Mode」是什麼？AI 客服 Agent、真人接手與對話分析一次看懂
Drex 1.5 常見問題
它可以直接回覆客戶嗎？
官方模型的輸出是選項機率，不是聊天回答。客服系統可以把分類結果交給人或其他處理流程，但回答內容、交易查核與對外傳送仍需另外設計。
回傳零點九，就表示九成機會答對嗎？
不能直接這樣使用。分數是否對應實際正確率，需要以你自己的標記資料校準。沒有做過這項驗證，高分也可能在某類問題上持續選錯。
一般版 Ollama 裝好就能跑嗎？
官方程式庫要求相應支援分支與模型部署步驟。按照 Drex 1.5 的模型頁確認，不把一般發行版與原作者修改過的版本視為相同。
官方分數為什麼在不同頁面不同？
本次查得的開發者頁與程式庫使用不同 Decision Index 版本。比較分數必須保留評測版本與條件，本文不將它們混成固定排名或世界第一結論。
自架就沒有費用嗎？
沒有雲端逐次模型費，不代表沒有硬體、電力與維護工作。先記錄自己環境的載入與處理時間，再比較整體成本，不由開放權重推算零成本。
先把一個分類層測清楚
Drex 1.5 的機會在於把有限選項的判斷獨立出來。適合從客服第一站開始，先證明分類與人工接手條件可用，再討論更複雜的後續自動化。
今天先寫好帳單、帳戶與產品的分類說明，標記一小批題目，並保留模糊訊息。確認部署版本後測分流，逐題檢視錯誤，再決定第一批哪些結果可以進真實流程。
訂閱 AI 郵報，持續取得 AI 工具的新功能與可執行教學。也把本篇的方法用在下一個小任務，留下自己的驗收記錄。
資料來源
資料查詢日期：2026 年 10 月 10 日。客服分流為本文設計的假設案例，未宣稱完成模型實測或部署驗收。
