語意條件路由：讓工作流依語意自動分流

每一條自動化流程。遲早會遇到一個分岔路口。一封郵件進來。它該轉給業務。還是客服。還是技術支援。一張表單送出。它是抱怨。是詢價。還是單純的感謝。傳統的做法是用關鍵字寫一堆 if-else。如果信件含「退款」兩個字。就轉到客服。聽起來很合理。但這條規則很脆。因為客戶不會照你的字典說話。有人說「我想把錢拿回來」。有人說「這個我不要了」。有人甚至打錯字寫成「推款」。這些句子的意思都一樣。但你的關鍵字規則一個都接不住。語意條件路由（Semantic Routing）要解決的。就是這個分岔路口的判斷問題。它不看你用了哪個字。它看你「到底想做什麼」。

一、關鍵字路由為什麼總是接不住真實的人

先把問題看清楚。關鍵字路由的脆弱。來自一個根本的錯位。它假設「意思」等於「用字」。但人類語言從來不是這樣運作的。同一個意圖。可以用上百種說法表達。同一個字。在不同句子裡又可能代表完全相反的意思。當你用關鍵字當路由條件。你其實是在賭客戶會用你預想的那幾個字。而這場賭。你長期一定會輸。

更麻煩的是維護的惡性循環。每次有一句話沒被接住。跑錯了分支。你的反應通常是「再加一條關鍵字規則」。於是規則越長越長。三個月後。沒有人敢動那一坨 if-else。因為你不知道改了這一條。會不會弄壞另外十條。這就是關鍵字路由的宿命。它一開始很簡單。但會隨著時間長成一團沒人敢碰的義大利麵。

還有一種更隱蔽的失敗。叫做「假性命中」。客戶寫了一句「我不想退款。只是想問問流程」。這句話的真實意圖是詢問。但裡面剛好有「退款」兩個字。關鍵字規則一看到就把它送進了退款分支。於是客戶被當成要退錢的人來處理。雞同鴨講。這種錯誤特別難抓。因為規則表面上「有命中」。看起來運作正常。實際上卻把意思完全搞反了。語意路由因為理解的是整句話的意圖。而不是單一字詞。它能分辨「我想退款」和「我不想退款」這兩句話。儘管它們共用了同一個關鍵字。卻指向相反的意圖。這種對否定與語境的理解。正是關鍵字規則的死角。語意路由換了一個思路。它不去窮舉所有說法。而是讓模型直接去理解這句話背後的意圖。再把意圖對應到分支。說法可以有千百種。但意圖往往只有那固定的幾類。抓意圖。比抓字。穩定得多。

這裡有一個常被忽略的好處。值得特別點出來。當你用意圖來分流。你的流程其實同時具備了「跨語言」與「抗錯字」的能力。一句用英文寫的退款要求。一句把字打錯的抱怨。一句夾雜表情符號的留言。對關鍵字規則來說全都是地雷。但對理解意圖的模型來說。它看的是整句話傳達的意思。而不是逐字比對。這代表你不必為了每一種語言、每一種口語、每一種打字習慣。各寫一套規則。你只要把意圖類別定義好。剩下的變化。交給模型去吸收。這種「一次定義。廣泛覆蓋」的特性。是關鍵字路由永遠做不到的。也是語意路由真正省下維護成本的地方。

二、語意路由節點的內部結構

語意條件路由的核心。是流程裡的一個判斷節點。它跟傳統的 if-else 節點站在同一個位置。但內部運作完全不同。下面這張圖把一條訊息進到路由節點之後的處理過程。完整攤開。

[訊息進入]  客戶留言 / 郵件 / 表單內容
     │
     ▼
[語意路由節點]
     ├─ 步驟一  把這句話交給模型。判斷它屬於哪一個預先定義的意圖類別
     ├─ 步驟二  模型回傳意圖標籤。並附上一個信心分數
     ├─ 步驟三  信心高於門檻  → 直接走對應分支
     └─ 步驟四  信心低於門檻  → 走「兜底分支」。轉人工或要求補充說明
     │
     ▼
[分流結果]
     ├─→ 業務分支
     ├─→ 客服分支
     ├─→ 技術支援分支
     └─→ 兜底分支（人工接手）

這個節點有三個關鍵設計。第一是「意圖類別要預先定義」。你得先想清楚這條流程總共要分成哪幾類。類別不能太多。太多模型會分不清。也不能太少。太少就失去分流的意義。第二是「信心分數」。模型不只回答這句話屬於哪一類。還要回報它有多確定。第三是「兜底分支」。這是整個設計裡最重要的一條。當模型沒把握的時候。它不該硬猜一個分支。而該走兜底分支。把這句話交給人。寧可多一步人工確認。也不要讓一句模稜兩可的話。被默默送錯地方。

三、實作案例：客服進線的自動分流

把結構落到一個會真實發生的場景。某公司的客服信箱。每天收到大量訊息混在一起。退款、報價、故障、單純讚美。全都擠在同一個收件匣。過去靠一位資深客服花上午的時間。一封一封手動分類轉發。現在改成語意路由。流程設想如下。訊息一進來。先送進路由節點。模型把它歸到四類意圖之一。退款申請、產品詢價、技術故障、其他。每一類都附帶信心分數。

信心高於門檻的訊息。直接轉到對應的處理隊列。退款進財務客服。詢價進業務。故障進技術。信心低於門檻的。例如一句「你們這個東西到底是怎樣」。意圖不明。就走兜底分支。轉給資深客服人工判斷。同時系統會記下這一筆。事後拿來檢視。是不是有一類新的意圖。還沒被納入分類。這個案例的重點不在於「全自動分類」。而在於「把九成意圖明確的訊息自動分對。只把一成模糊的留給人」。讓資深客服的時間。花在真正需要判斷的地方。所有數字與情境皆為示意。請依自身進線量重新評估。

這個流程上線之後。還會帶來一個意想不到的副產品。就是「需求的能見度」。因為每一封訊息都被歸了類。你第一次能用數字回答一些過去只能靠感覺的問題。這個月退款類的訊息是不是變多了。某個產品的故障進線是不是突然飆高。哪一類問題佔了客服最多的時間。這些洞察。過去都埋在一封封沒人統計的信件裡。語意路由在分流的同時。順手把它們結構化了。於是分流節點不只是一個轉接台。它還變成了一個持續產出需求趨勢的感測器。讓你能更早看出哪裡出了狀況。這層價值。在流程跑久之後。往往比省下的分流工時還要珍貴。

四、Prompt 範本：把意圖判斷交給模型

語意路由節點的判斷。可以用一段提示詞驅動。重點是把意圖類別寫清楚。並強制模型回報信心。以及在不確定時誠實走兜底。以下提供一段可調整使用的範本。

【角色】你是一名訊息分流判斷器。

【背景】我會貼上一段客戶訊息。你要判斷它屬於哪一類意圖。

【任務】請把訊息歸到下列四類其中之一。並輸出意圖標籤與信心。
- refund   客戶想退款、退貨、把錢拿回來
- quote    客戶想詢價、問方案、想購買
- support  客戶回報故障、操作問題、東西壞了
- other    以上皆非。或意圖不明確

【限制】
- 只能輸出上述四個標籤其中之一。不可自創新標籤。
- 必須附上信心分數。介於 0 到 1 之間。
- 若訊息語意模糊、同時像兩類、或資訊不足。一律歸到 other 並給低信心。嚴禁勉強猜測。
- 只輸出標籤與信心。不要加任何解釋。

這段提示詞的設計。把語意路由最重要的紀律寫進去了。第一是標籤封閉。模型只能在你給的四類裡選。不能自己發明。第二是強制信心。讓後面的門檻判斷有依據。第三是模糊歸 other。這對應到流程裡的兜底分支。當模型發現一句話同時像退款又像故障。或者根本看不懂。它該做的不是賭一把。而是誠實地說「我不確定」。把球交還給人。一個會誠實認輸的路由器。遠比一個總是給出答案、但常常給錯的路由器。安全得多。

五、導入 SOP：先定義意圖，再設門檻，最後才放手

導入語意路由。最常見的失敗是「一開始就想分太細」。正確的順序是從粗到細。建議的導入步驟可以拆成五步。

第一步。先盤點這條流程「真正需要分幾類」。從最粗的幾類開始。寧可三類起步。也不要一開始就切成十五類。第二步。為每一類寫下清楚的定義與一兩個例句。這份定義就是日後提示詞的基礎。也是團隊對齊認知的依據。第三步。設定一個保守的信心門檻。一開始把門檻調高一點。寧可多送一些到兜底分支讓人看。也不要讓低信心的訊息亂跑。第四步。並行試跑。讓路由節點先跑。但人照常分類。比對兩邊結果。看模型在哪一類最常出錯。第五步。建立回饋迴路。把每一筆走兜底分支的訊息。定期回頭檢視。如果發現某一種意圖反覆出現卻沒有對應類別。就把它補進分類。讓路由的覆蓋面隨時間越來越完整。

六、ROI 評估：算的是「省下的分流人力」減「分錯的代價」

要不要把流程的分岔路口從關鍵字升級成語意路由。最好先把成本與報酬一起放上桌面。以下這張表。左側是你需要投入的每一項。右側是它帶來的實際改變。表內的數字皆為假設情境下的舉例。請依貴單位每天的進線量自行推估。

評估時要避開一個陷阱。不要只看「省下多少分流的人力」。還要算「訊息分錯之後的代價」。一封該進技術支援的故障訊息。被誤分到業務。客戶等了三天沒人理。流失的可能就是一個客戶。所以信心門檻不能為了追求自動化率而調太鬆。語意路由的價值。一半在於它分得快。另一半在於它懂得在沒把握時收手。把這兩面一起算。才看得出真正的投資報酬。

❓ 讀完後，先問自己這幾個問題

你這條流程的分岔路口，真正需要分成幾類意圖？

• 如果你列得出三到五類。而且每一類都能用一句話講清楚。那它就很適合改成語意路由。
• 如果你發現怎麼分都會有一堆「不上不下」的訊息。那正是你需要設計兜底分支的訊號。
• 不論分幾類。先問自己。當模型沒把握時。你希望它把訊息送去哪裡。那個答案。就是你的兜底分支。

結語：讓流程聽懂意圖，而不是只認得字

語意條件路由的價值。不在於它取代了 if-else。而在於它把分流的依據。從脆弱的「用字」。換成穩定的「意圖」。它讓你的流程第一次真正聽懂了人在說什麼。記得最重要的兩條紀律。一是類別要先定義清楚。寧可從粗分起步。再慢慢補細。二是一定要有兜底分支。讓模型在沒把握時把球交給人。而不是硬猜。下一步。可以先挑一條目前靠關鍵字硬撐、而且常常分錯的流程。把它的意圖類別列出來。那就是你把它升級成語意路由的起點。