跳至主要内容

微語探索開源決策模型 Laya：讓客服先判斷，再回答

· 閱讀時間約 8 分鐘
Jack Ning
Jack Ning
Maintainer of Bytedesk

客戶說「又扣了一次費，不處理就取消續費」，客服系統首先需要的，可能不是一段流暢的回答，而是辨識投訴、找到負責帳單的團隊，並判斷是否需要人工介入。

微語（Bytedesk）計畫評估透過 Ollama 接入開源決策模型 Laya，讓專門做判斷的模型輔助客服意圖辨識與路由。目前仍是方案評估階段，尚未實作或上線；本文介紹的是預期價值，不是已驗證的產品能力。

微語不會鎖定只使用 Laya。 規劃中的決策能力將支援按需切換模型，包括透過 API 接入阿里雲、智譜等提供方；Laya 是首個驗證選項，而不是唯一選擇。

Laya 是什麼？更像分診員，而不是話術員​

聊天大模型擅長組織語言、解釋問題、產生回覆。Laya 則面向範圍明確的判斷：在預先定義的類別中做選擇、判斷某種情況是否成立，或按約定的等級評分。

例如，它可以協助判斷：

  • 一條訊息更像諮詢、投訴、建議，還是其他？
  • 請求與帳單、技術支援，還是銷售更相關？
  • 客戶是否明確提出取消續費或轉人工？

Laya 由 Convai Innovations 發布，預設模型約 4.21 億參數，基於 ModernBERT-large，採用 Apache 2.0 授權，權重可用於自部署。它不負責產生客服回覆，也不會查詢真實訂單或替坐席完成退款。

有一個重要的語言邊界：Ollama 提供的預設 laya 模型僅支援英文。 Laya 專案另有面向 100 多種語言的 laya-multilingual 模型，但它不隨 Ollama 的預設模型提供。中文、繁體中文及中英混合客服都需要單獨驗證，不能因為專案有多語言版本，就宣稱目前接入方案已支援中文。

為什麼客服系統需要「先判斷，再回答」​

一條訊息如果一開始就分錯佇列，後面的回答再流暢，也可能讓客戶在部門之間來回轉接。意圖辨識的價值，在於讓系統先弄清楚「該進入哪一種處理流程」。

既有做法可以是關鍵詞規則，也可以讓聊天大模型輸出分類結果。前者直觀但可能漏掉不同表達，後者靈活但需要考慮推論開銷與輸出驗證。Laya 提供另一種選擇：把邊界清楚的判斷交給小型決策模型，把複雜解釋留給大模型或人工。

它不一定適合所有任務。明確的時間比較、金額計算、權限驗證仍應由業務規則與程式處理；跨多輪、多個訴求的複雜問題，也不宜硬塞成一次簡單選擇。

引入 Laya，微語希望改善什麼​

1. 減少不必要的等待與轉接​

對於短文字、有限類別的高頻判斷，專用決策模型有望減少生成式分類的開銷。官方公布過特定硬體上的毫秒級結果，但微語真實回應還包含網路、排隊、模型載入與後續處理，不能把官方單次推論速度當作客服端到端承諾。

2. 把「不確定」納入服務流程​

模型回傳的分佈資訊可以協助系統判斷何時自動分流、何時補充資訊、何時交給人工複核。但「置信度高」不等於「答案一定正確」，更不等於該分數就是準確率。自動處理邊界必須用實際客服樣本驗證。

3. 輸出更受約束，但仍可能犯錯​

在已定義的選項中選擇，比自由產生一段分類說明更容易接入業務流程。不過，不產生文字不代表不會誤判：把投訴分成諮詢、漏掉否定表達，同樣會影響體驗。受約束的輸出不能取代業務驗證與人工備援。

4. 為資料留域提供一種部署選擇​

自部署有助於讓這一步判斷在企業內網完成。但是否符合合規要求，還取決於存取控制、日誌去識別化、資料留存，以及後續問答與回退鏈路。如果回退到外部雲端模型，相關訊息仍可能出域，不能只看 Laya 部署在哪裡。

5. 更合理地分配運算預算​

把高頻、簡單的判斷從大模型中分離，有望改善整體資源利用率。自託管並非「一次投入、永久免費執行」：硬體、電力、維運、擴充與評測都屬於持續成本。是否划算，需要在相同品質與流量條件下比較。

一個客服場景，如何協作​

以重複扣費投訴為例，擬議流程是：辨識「投訴、帳單相關」的訊號，交給既有規則確認處理佇列；需要時由坐席或具備權限的業務工具核查帳單，再由人工或大模型組織回覆。

其中，Laya 提供的是分類或處理建議，不是退款授權。緊急程度、流失風險與轉人工建議可以作為後續探索方向；它們不是已經上線的功能，也不能僅憑客戶說「退款」就斷定客戶將流失。

中文業務會繼續使用既有處理鏈路，直到獨立的語言與品質驗證通過。即使回傳「需要人工」，也仍須由微語的工作組、排隊與坐席規則完成實際接待。

Laya 與 Jev：如何選擇，而不是簡單排高低​

Jev 是 TypeSafe 的決策模型，同樣面向選擇、判斷與評分等結構化任務。Laya 的決策介面採用類似的 System One 風格，但這不代表兩者的語言能力、模型效果、閾值或所有功能可以直接互換。

關注點LayaJev
公開接入方式開源權重，可透過 Ollama 自部署預設英文模型官方文件提供託管 API 與 SDK
團隊投入自行承擔部署、容量規劃、升級與品質評估可減少自建推論服務的工作；服務條款仍需評估
資料治理可內網處理；仍須檢查日誌與回退鏈路核對資料處理區域、留存、合約及企業部署選項
成本比較計算硬體、維運與評測的總成本以官方目前價格與合約為準，不假定固定計費模式
效果比較在目標語言與業務樣本上實測用相同樣本、品質要求及端到端指標比較

希望掌握模型部署與執行環境的團隊，可以優先研究 Laya；希望減少推論基礎設施維護的團隊，可以評估 Jev 的託管服務。本文不依據不同硬體上的公開基準宣布哪一個「更快、更準或更便宜」。

不綁定單一模型：讓企業保留選擇權​

不同團隊對語言、效果、延遲、預算與資料部署的要求並不相同。微語計畫把「客服需要做什麼判斷」與「由哪個模型完成判斷」分開：企業可以選擇自部署 Laya，也可以在相應適配完成後，透過 API 選用阿里雲、智譜等提供方中適合決策任務的模型或服務；Jev 也是可評估的候選。切換已適配的模型應透過設定完成，不必重寫客服意圖分類與路由流程。

這裡的「自由切換」不代表所有模型天然相容。各家的介面、語言、輸出形式與資料處理條款需要分別核實；通用模型經結構化輸出承擔判斷任務，也不代表它就是 Laya 一類的專用決策模型。本文不宣稱阿里雲或智譜已有與 Laya 完全相同的介面、機率或置信度能力。

每次切換都應經過業務樣本評測與小範圍驗證。切換到雲端 API 前需確認資料出域許可；不會因為本地模型失敗，就未經授權自動把客戶訊息傳送給另一家服務。

下一步：先驗證，再決定上線​

微語擬從供應商無關的決策介面與 Laya 英文協定驗證起步，並將阿里雲、智譜 API 適配及模型切換納入分期規劃，再進行離線評測、工具路由影子執行、小範圍灰度與回滾。中文支援可評估獨立多語言模型服務或通過驗收的 API 模型，不受限於 Laya；具體型號、接入順序、會話自動分類、管理後台與實際轉人工改造，仍需在規劃中確認。

  • 開發者可閱讀 Laya 意圖辨識與路由開發指南。
  • 倉庫內的實作規劃位於 docs/plans/2026-10-18-laya-intent-routing-plan.md，狀態為待確認，不發布到文件站。

方案確認之前，不開始業務程式碼實作。

相關資源​

本文依據上述官方資料整理；模型發布、服務條款與價格可能變更。外部 Demo 僅用於體驗，不應上傳未經授權的客戶資料。