聊天機器人怎麼選？規則型、意圖型、生成式比較

聊天機器人的選型，本質上是在選「機器怎麼理解一句話」。規則型把使用者的輸入拿去跟預先寫好的關鍵字、選單與流程比對，比中了就回傳腳本裡的答案。意圖型在前面加了一層自然語言理解，把不同說法配對到預先定義的意圖再分流。生成式則交給大型語言模型（LLM），當場依你提供的資料寫出一段回答。三種類型不是新舊替代關係，而是三種不同的工程取捨，2026 年的市場把它們同時擺在貨架上，選錯的代價比從前更高。

取捨的第一個維度是問題分布。你的客服或行銷訊息裡，少數高頻問題是否吃掉大部分流量，剩下的是長尾還是雜訊，這個分布決定了該把力氣花在哪一層。第二個維度是維護能力，規則要人寫、意圖要人訓練、生成式要人治理資料與提示，沒有哪一種是真的「設定完就不管」。第三個維度才是成本，而且帳單結構比單價重要，生成式的單位成本未必比較低，這點後面用官方牌價與 Gartner 的預測來算。

三分法的依據可以先講清楚。IBM 在 2026 年 7 月更新的聊天機器人主題頁把世界分成兩半：遵循預先定義規則、決策樹與腳本化流程的傳統機器人，以及用自然語言處理、生成式 AI 與大型語言模型理解意圖並生成回應的 AI 機器人。Google Cloud 的 Conversational Agents 定價頁再把後者切開：以意圖與流程建成的確定性代理，以及用自然語言指令建置的生成式代理。把這兩條官方分界疊起來，就是市面上最實用的三分法：規則型、意圖型、生成式。

這份選型指南處理的是跨平台的框架問題：三種類型各自怎麼運作、成本結構長什麼樣子、什麼情境該選哪一種、又該怎麼混著用。已經鎖定平台的讀者，可以接著參考站上的 Messenger 聊天機器人行銷指南與 ManyChat 的 IG 自動化教學，那兩篇走實作軸，框架與工具的分工剛好互補。

先把三個名詞對齊：聊天機器人、對話式 AI、AI 代理

動手選型之前，得先把三個經常被混用的名詞拆開，因為供應商的銷售頁從不幫你拆。「對話式 AI」是最大的傘，IBM 的定義寫得很直白：它是讓系統理解並回應人類語言的廣義技術類別，聊天機器人只是這個技術的其中一種應用，同一把傘下還有助理、代理與其他對話系統。換句話說，跟你推銷「對話式 AI 解決方案」的廠商，賣的可能是三種類型裡的任何一種，名詞本身不構成採購依據。

「聊天機器人」的定義反而樸素：透過文字或語音與人溝通的軟體應用程式，出現在網站、通訊軟體、簡訊與客服入口。這個物種的歷史比生成式 AI 老得多，1960 年代的 ELIZA 就用簡單的樣式比對模擬對話，辨識關鍵字後回以預寫答案，談不上理解語意。六十年後的規則型機器人，血統上就是 ELIZA 的直系子孫，只是決策樹更完整、介面更漂亮。

「AI 代理」則是近年才進入採購清單的名詞，IBM 給它的界定是能規劃、做任務層級的決策，並在少量人類介入下執行多步驟工作流，途中常使用工具、跟其他軟體互動。聊天機器人回答問題、一步步帶使用者完成任務，代理則可能自己協調換貨、更新庫存、通知其他系統再跟使用者確認。界線正在變模糊，多數平台把三者揉在一起賣，想深究代理這條線，站上的 AI Agent 完全指南有展開，這裡聚焦在「回應使用者的對話系統」這個範圍。

名詞對齊的實際用處在採購談判上。你問廠商「這是規則還是 AI」，得到的答案取決於他那天想賣什麼。你問「使用者講了一句訓練範圍外的話，系統發生什麼事」，答案就藏不住類型的真相：規則型的答案是轉選單或轉真人，意圖型的答案是落到 fallback 意圖，生成式的答案是模型自己想辦法。接下來三節分別拆解這三種行為模式。

規則型：用決策樹換完全可控

規則型機器人的運作原理一句話可以講完：把使用者的輸入，跟預先定義的規則、關鍵字或對話流程比對，認出請求就回傳預寫的回應，或引導使用者走下一步。所有可能的路徑在設計階段就被畫死，機器人不需要理解任何東西，它只做比對。這種「笨」是刻意選擇的，因為笨的系統完全可預測，而可預測在客服與交易場景裡是硬需求。

市面上最常見的規則型實作是通訊軟體裡的關鍵字觸發。ManyChat 官方說明中心的Keywords Trigger 文件寫得明白：把特定字詞設為觸發條件，使用者訊息一提到指定關鍵字，系統立刻回訊、啟動自動化流程或執行其他動作，而且這個功能跨 Instagram、Facebook Messenger、WhatsApp、Telegram 與 SMS 運作。網站常見的按鈕選單式客服 widget，粉絲團的自動回覆私訊，電商的棄單挽回流程，都屬於這一族。它們的共同點是：觸發條件是字面比對，回應內容是人事先寫好的。

規則型的優勢有兩條，而且兩條都直接對應到商業價值。第一是答案的一致性，機器人用核定過的內容與商業規則回應，跨對話的答案不會漂移，法務與品保容易簽字。第二是全天候可用，不像營業時間有限的客服團隊，機器人任何時間都能回。

代價同樣清楚。IBM 的評語一針見血：傳統機器人對可預期的請求表現良好，但碰到超出預寫回應範圍的問題就會卡住，通常只能改引導使用者或轉接真人。使用者把「我要退訂」打成「想取消昨天買的東西」，關鍵字沒中就是沒中，機器人不會猜。變通做法是把同義詞全部塞進觸發清單，但清單會越長越難維護，而且永遠有下一種沒想過的說法。

所以規則型的適用條件可以列得很具體：問題集合封閉且穩定，例如營業時間、取貨方式、活動辦法。任務路徑需要百分百按規則走，例如身分驗證後的查詢、折扣碼使用。回應內容有合規壓力，答案必須一字不差。行銷場景裡的關鍵字自動回覆、選單式互動廣告，也是規則型的主場，因為行銷要的是精確控制消費者看到的每一句話。反過來說，當你的問題集合是開放的，或使用者喜歡用自己的話講事情，規則型的維護成本就會超過它的好處。

意圖型：把不同說法配對到預先定義的意圖

意圖型機器人在規則層前面加了一個自然語言理解模組。NLU 是自然語言處理（NLP）的專門分支，聚焦在解讀使用者意圖與上下文，做的比認關鍵字多一層。這一層做的事情叫意圖分類：使用者說「我想查貨到哪了」「訂單怎麼還沒來」「上次買的東西什麼時候會到」，NLU 把這三句收斂成同一個「查詢訂單狀態」意圖，後面的流程只需要為每一個意圖寫一次。

Google 的 Dialogflow 是這一類的代表，意圖總覽文件把機制講得很白：每個代理要定義多個意圖，整組意圖合起來要能處理一場完整對話，使用者寫下或說出一段內容時，系統把它配對到代理中最佳意圖。工程師的工作不是窮舉說法，而是為每個意圖提供訓練語句範例，Dialogflow 內建的機器學習會用相似說法自動擴充清單。比對成功後，系統還能從使用者的表達裡抽出參數，參數是結構化資料，比原始輸入更容易拿去做邏輯處理。「查訂單」意圖抽出訂單編號、「訂位」意圖抽出人數與時間，就是這一層的產物。

Amazon Lex 走同一條路，術語略有不同。Lex 的開發者指南定義：意圖代表使用者想執行的動作，一個 bot 支援一或多個相關意圖，每個意圖要給範例語句與履行方式。Lex 的招牌是欄位填補對話：意圖需要欄位時，系統在執行期間提示使用者補齊特定欄位值，所有必填欄位到位後才履行意圖，而且使用者回覆夾帶多餘字詞，比如把尺寸講成一整句話，Lex 仍能抽取出欄位值。語音與文字同一套引擎，底層是自動語音辨識（ASR）與自然語言理解。官方快速學習路徑估的工時很誠實：從範本開始到可運作的聊天機器人，約 50 分鐘，這是含範本的情況，真實專案的意圖盤點與訓練遠多於此。

Dialogflow 的CX 版文件有個值得記下的比喻：代理類似人類客服，你訓練兩者處理預期的對話情境，而且訓練不必鉅細靡遺。這句話點出意圖型的真實維護模型，它像帶新人，上線只是訓練的開始，實際對話進來後，你得持續看哪些說法被誤判、哪些意圖互相搶客、哪些該合併拆分。訓練語句的品質決定分類的品質，而說法的分布會隨著產品與季節漂移。

意圖型的甜區因此很明確：問題有一定的說法變異，但意圖集合本身收斂，客服與交易類的任務大多是這個形狀，查詢、修改、取消、預約、申請，意圖集合可以清楚盤點，每個意圖對應明確的系統動作。它換掉規則型的比對層，但保留了流程層的確定性，意圖之後走的還是你畫的對話流。限制則在意圖清單的管理成本，以及長尾問題依然沒有家：訓練範圍外的說法會落到 fallback，處理方式跟規則型卡住時沒有本質差別，差別只在它能涵蓋的說法空間大得多。

生成式：LLM 現場寫答案，接地決定能不能上線

生成式機器人把「回答」這件事整個換掉。規則型與意圖型都從預寫的腳本裡挑答案，生成式用大型語言模型當場生成一段回答，能記住對話前段的資訊，讓使用者自然追問或換話題。IBM 舉的例子很有畫面：顧客說上週買的夾克想換尺寸，AI 機器人不必讓顧客從選單裡挑選，能理解請求、詢問訂單號碼、調出購買明細並帶顧客走完換貨流程。開放式提問、跨主題跳躍、長尾問題，這些前兩代處理不了的需求，正是生成式的主場。

平台端的對應變化已經發生。Google Cloud 把 Dialogflow CX 併入 Conversational Agents 後，定價頁上並列兩個版本：以意圖與流程、用自然語言理解建成的 Flows，以及能用自然語言指令建置的 Playbooks 生成式代理，後者背後的資料存放工具能依網站內容與上傳資料，提供 AI 生成的代理回應。微軟的 Copilot Studio 走得更前面，用自然語言描述就能建立代理，它依你給的指示行事、取用你接入的知識來源並用工具行動。兩家把建置介面從畫流程圖改成寫說明書，這是生成式時代的建置範式。

但「能生成」跟「能上線」之間隔著一道牆，牆的名字叫接地。接地總覽文件的定義：接地是把模型輸出連結到可驗證資訊來源的能力，讓模型存取特定資料來源後，接地會把輸出拴在這些資料上，降低編造內容的機率。官方列的好處有三條：降低模型幻覺（生成非事實內容的情形）、把回應錨定在你的資料上、附上連向來源的連結提供可稽核性。沒有這一層，模型回答你的退貨政策時靠的是訓練資料裡的統計印象，而你的政策可能跟全世界的平均值都不一樣。接地有多種實作方式，檢索增強生成是其中一種，站上的 RAG 完整解析拆過相關技術，選型時只需要記住結論：生成式機器人的品質上限由模型決定，品質下限由接地決定。

幻覺不是理論風險。IBM 的提醒寫得直接：AI 聊天機器人偶爾會生成不準確、不完整或誤導的回應，當機器人拿不到可靠資訊、或被問到知識範圍外的問題時，這種情形更可能發生，把機器人接上可信賴的資料來源並定期檢視表現能改善。對照客服場景，這正是「模型很會講話」變成事故的地方，顧客問能不能退費，模型流暢地編出一套期限與條件，跟你的實際政策對不上。幻覺的成因與完整防禦工法，站上的 AI 幻覺指南有專文，選型時的行動版結論是：沒有資料可以接的題目，先別上生成式。

生成式還帶來三個前兩代沒有的治理負擔。一是持續維護，商業資訊、政策與顧客需求會變，機器人需要定期更新，模型本身還會改版。二是隱私與資料治理，機器人處理顧客、員工與商業資訊，組織要建立保護敏感資料、控管系統存取並遵守隱私法規的政策，接給模型的知識庫範圍要逐項盤點。三是透明度，人們應該知道自己正在跟機器人互動，並了解它能存取哪些資料，這不只是倫理建議，監管方向已經明確，後面成本段會看到 Gartner 對法規的預測。

三種類型攤開對照

把三種類型放進同一張表，決策的骨幹會清楚很多。表中的性質形容是跨官方文件的綜合判讀，各儲存格的機制描述在前面三節都有原文依據。

選型前先回答六個問題

類型特性懂了之後，剩下的工作是把自己的業務放上來比對。下面六個問題按順序回答，答案會直接指向一個起點，注意它通常只是起點，也可以按需求組合成混合式架構。

第一個問題：你的問題分布是封閉還是開放。把一個月的真人對話紀錄抓出來，排序統計，如果少數高頻問題吃掉大部分流量，而且這些問題的答案寫得出標準版，規則型就值得先做，它能把最大的流量塊用最低風險接住。如果分布平坦、長尾佔比高、問題會隨季節與產品線變動，意圖型或生成式才有意義。這個分布不會憑空知道，對話紀錄、客服工單、站內搜尋關鍵字，都是資料來源。

第二個問題：任務需要動到系統嗎。只回答資訊，規則型與生成式都行，差別在可信度要求。要執行動作，查訂單、改資料、退款、預約，意圖型的地位就出來了：意圖分類確認使用者要做什麼，參數抽取確認要做到哪個對象，欄位填補確認資訊齊全，然後系統用結構化資料去執行。這條鏈每一環都是確定性的，出錯可以定位。讓生成式模型直接決定要不要退款，等於把對帳系統交給一個會自信犯錯的實習生。

第三個問題：你有多少可用的知識資產。生成式的上線前提是接地資料，產品說明、政策文件、常見問答、維修紀錄，整理得出單一真相來源才有得接。資產缺漏時先補文件，機器人救不了沒有答案的知識庫。反過來，資產齊全但使用者的問法千奇百怪，知識查詢類的生成式代理可以很快見到成效，Google 那套以網站內容與上傳資料生成回應的工具，鎖定的就是這個情境。

第四個問題：答錯的代價多大。低代價場景，推薦餐廳、找商品、閒聊，生成式的偶發出錯可以容忍，體驗增益大於風險。高代價場景，醫療、金融、法務、金流，答案錯一個字就是事故，這裡的設計原則是把生成式放在限縮的位置，摘要、改寫、輔助真人，最終裁決與對外承諾留給規則與人。

第五個問題：誰來維護。沒有工程資源的團隊，要把所選工具的建置門檻納入評估，意圖型至少要有能看懂對話資料的人，生成式要有能治理資料與提示的人，維護人力決定類型的上限。

第六個問題：頻道在哪。網站 widget 三種都能做，電話語音要考慮 ASR 與延遲，通訊軟體要看平台規則，這在後面台灣場景段展開。

成本的帳怎麼算：單價、資料與建置三層

先看市場為什麼搶著自動化。Gartner 在 2022 年發布的預測（由產業媒體全文轉載）給出背景數字：當時全球約有一千七百萬名聯絡中心客服人員，人力成本可占聯絡中心成本的 95%，許多組織受人力短缺與刪減勞務成本所苦。同一份預測估計，當時僅 1.6% 的客服互動由 AI 自動化，到 2026 年將達十分之一，並為聯絡中心減少 800 億美元的人力成本。這組預測呈現了聯絡中心投入自動化的成本動機，也解釋了為什麼選型錯誤的代價越來越高。

再看單價層。雲端意圖型的計價單位是請求：Lex 的定價頁定義，每次使用者輸入都算一次獨立 API 呼叫，文字與語音分開計，官方範例是每通文字請求 0.00075 美元、每通語音請求 0.004 美元。Google 的 Conversational Agents 定價把兩個版本並列：Flows 文字對話每次請求 0.007 美元，Playbooks 生成式代理每次 0.012 美元，語音則是每秒 0.001 對 0.002 美元。換算成每千通的口徑：Lex 文字 0.75 美元，Flows 7 美元，Playbooks 12 美元。生成式代理的單價大約是同平台意圖型的 1.7 倍，這個倍數會直接乘在你的流量上。要注意請求的定義比你想的寬，Google 明講任何打到平台的 API 呼叫都算，含整合與主控台的間接使用。

把單價換成月費來感受量級，假設每月十萬次文字請求（此為換算示範，請代入自己的流量）：Lex 的帳單約 75 美元，Conversational Agents 的 Flows 約 700 美元，Playbooks 約 1,200 美元。這三個數字都不是採購決策的全部，規則型平台的費用要依方案另行核對，意圖型的低單價要乘上意圖維護的人力，生成式的高單價買的是長尾覆蓋。真正的比較基準是「每一通被接住的對話花多少錢」，沒被接住的對話最終會以真人工時的形式回到帳上，那才是最貴的計價單位。

生成式還有資料層的成本。接地的資料要計索引儲存費，Google 以每頁 500 KiB 估算網站資料存放，一千頁約 0.477 GiB，按超額單價換算為每月 2.38 美元。索引儲存每月有 10 GiB 免費額度，若免費額度尚未用完，一千頁範例不會產生額外索引儲存費，超額原始資料才按每 GiB 每月 5 美元計費。知識庫規模小時這層近乎零成本，但企業級文件量加上定期同步，就會是一條固定開銷。建置層的成本則很難用牌價呈現：規則型與意圖型的建置是畫流程與養意圖，生成式的建置是整理資料、設提示、建評估集，後者的隱性工時常被低估，尤其評估集，沒有它你連「改了提示有沒有變好」都無法回答。

單價與趨勢要放在一起看。Gartner 在 2026 年 1 月 26 日的新聞稿提出另一個成本面向的預測：到 2030 年，生成式 AI 的每次解決成本將超過 3 美元，高於許多 B2C 營運的離岸真人客服。背後的推力是資料中心成本上升、AI 供應商從補貼成長轉向獲利、使用情境日益複雜而吃掉更多 token 並需要昂貴人才。分析師的結論更直接：客服主管一心想用 AI 降本，但投資回報遠非保證，對多數組織而言，全面自動化將貴到不可行。把這句話跟前面每千通 12 美元的牌價放在一起，結論不是不要用生成式，而是不要用「生成式比較先進所以比較省」的假設做預算，省錢的主要槓桿依然是把高頻問題用規則與意圖接住，生成式負責它獨有的長尾價值。

混合架構：意圖收線、生成接球、真人兜底

三選一的題目，三層可以按需求組合，以下是一種混合形態：最外面是意圖層，高頻任務各有明確意圖與流程，行為確定、成本最低。中間是生成層，意圖沒接住的問題，交給接了知識庫的生成式回答，撈住長尾。最裡面是真人層，機器都處理不了、或不該由機器處理的對話，轉給人。這不是發明，已有平台把它做成內建行為，微軟把 fallback 行為寫成了產品邏輯，生成式回答文件的順序是：代理在主題定義的意圖中找不到相符項時，自動改用生成式回答嘗試作答，意圖沒對到主題也沒被生成式回答接住時，才走 Fallback 系統主題。從意圖到生成再到 fallback，平台已經替你排好順序，真人層就接在這條線的末端。

各層的細節設計比架構圖重要。意圖層要守住高頻路徑的穩定，訓練語句定期用真實對話回補。生成層的知識來源要設得具體，微軟文件明說想要成效，生成式回答節點要設定特定的知識來源，別讓代理漫無邊際地找資料，知識來源依你提供給代理的資訊提供權威回應。真人層的轉接不能是懲罰，IBM 的標準講得很清楚：設計良好的機器人應認得自己的極限，需要時提供清楚通往真人客服的路徑。

混合架構的營運重點，是盯著層與層之間的流量遷移。每週看三個數：落 fallback 的量、生成層接住的量、轉真人的量。fallback 持續升高的那類問題，是下一個該建成意圖的候選，因為它證明了自己夠頻繁、值得確定性。生成層反覆被問、答案也穩定的題目，可以考慮下沉成規則或意圖，把每次請求的成本換成近乎零。反過來，某個意圖的觸發持續誤判，先補訓練語句，補不動就承認它是長尾，交還生成層。三層不是蓋完就固定的大樓，是依流量持續搬移傢俱的房間，搬運的依據就是這三個數字的走勢。

真人層在可見的未來只會更重要，不是更不重要。Gartner 的預測：到 2028 年，AI 相關法規變動將使人工協助的服務量增加 30%，因為確保「有權找真人」的監管壓力，會讓大量客戶行使退出 AI 的權利。把機器人設計成困住使用者的迷宮，不只是體驗問題，正在變成法規風險。同一份預測裡還有一個值得記的面向：到 2030 年，10% 的財富五百大企業將把客服支出翻倍，把 AI 用於超個人化與主動式體驗及競爭優勢。這項預測顯示，部分大型企業可能把 AI 預算投向體驗與競爭優勢。

混合架構也改寫了三種類型的採購順序。可以從生成式開始做試驗，因為它見效快、不用先畫流程，但生產環境的骨幹應該從意圖與規則層長出來，因為確定性與成本可控是營運的底盤。生成式負責的是原來只能轉真人的那一塊，每接住一題原本要人工的長尾，就直接反映在人力帳上，這才是生成式的成本公式，它不是替代規則與意圖的每千通單價，而是替代真人工時的單價。

台灣場景：頻道現實與 LINE 生態

選型在台灣還有一個繞不開的變數：頻道。多數消費者的主要訊息管道是 LINE，官方帳號往往是顧客接觸的第一線。LINE 的 Messaging API 就是用來建機器人、在 LINE 上提供個人化體驗的官方介面，它的運作模型文件寫得很精簡：使用者傳訊息給官方帳號，平台把 webhook 事件送到你伺服器的 webhook URL，你的伺服器檢查事件後經平台回應使用者。這個模型意味著，對話邏輯在你自己的伺服器上，三種類型都能做，你可以用關鍵字規則回應，可以把訊息丟給意圖分類，也可以串生成式模型再透過 API 回傳。

webhook 模型對選型還有一層工程含義：對話邏輯住在你自己的伺服器上，類型的選擇權與組合權在你手裡，同一個官方帳號背後，可以讓關鍵字規則先擋掉高頻互動，剩下的訊息送進意圖分類，分類落空再交給接好資料的生成層，三種類型共用同一個入口。代價是要維運接收 webhook 事件並經 LINE 平台回應使用者的機器人伺服器，人力配置要一起算進選型。

頻道約束會回頭影響類型選擇。通訊軟體的訊息有版面與互動元件的限制，按鈕與選單是原生互動，規則型的體驗反而順，許多關鍵字自動化工具正是長在這個生態上，跨 Instagram、Messenger、WhatsApp 等頻道運作。網站 widget 沒有這些限制，生成式的開放對話有發揮空間。電話語音則要考慮辨識準確率與延遲，按秒計費的結構也讓長對話變貴。先定頻道，再定類型，順序反了會一直在改架構。

在地的實務節奏通常是把 LINE 官方帳號當第一層入口：高頻的營業資訊、取貨問答用規則型選單接，行銷活動用關鍵字觸發做互動，需要彈性的客服對話再往後端送意圖或生成層。這個分層跟前述混合架構是同一套邏輯，只是入口換成在地的主場頻道。

導入的五個階段：從對話紀錄到上線

把選型變成專案，常見的落地順序可以拆成五個階段，順序的用意是把風險最貴的部分往後放。

第一階段是盤點。拉出對話紀錄與工單，統計問題分布，標出高頻題與長尾題，順便盤點知識資產的完整度，哪些問題有標準答案文件、哪些只有老員工知道。這個階段的產出決定後面所有取捨，跳過它直接選工具，等於閉著眼睛畫架構。第二階段用規則型承接高頻題，把營業時間、取貨方式、活動辦法這類封閉問題做成選單與關鍵字流程，上線快、風險低，而且立刻減輕真人負擔，這是專案的第一個可見成果。第三階段為說法變異大的任務建意圖，從對話紀錄裡挑真實語句當訓練語句，讓分類器貼近你的使用者怎麼說話，而非貼近範本語庫。

意圖的養護有自己的紀律。訓練語句要從真實對話來，範本語句教出來的分類器只認得範本。新增意圖前先確認沒有舊意圖能涵蓋，兩個意圖搶同一批說法，誤判率會一起變差。一段時間沒被觸發的意圖，要嘛是設計錯了、要嘛是該合併，留著只會稀釋訓練資料。Dialogflow 那句「訓練不必鉅細靡遺」的前提，是你持續在養，不是丟著不管，這也是意圖型與規則型在維護性格上最大的差異：規則是寫完就對，意圖是養了才準。

第四階段上生成層，範圍先收窄在知識齊全的主題，接好接地資料與引用來源，並且先建評估集再調提示，沒有評估集的調整是憑感覺。生成式回應的知識來源要設得具體，這個原則前面引過官方文件，落地時就是每個生成節點綁定明確的文件集。第五階段把規則、意圖與生成層組成混合架構，再進入衡量與迭代。機器人上線不是終點，是資料的起點，IBM 點出 AI 機器人的對話內容能揭露常見問題、重複出現的議題與資訊缺口，這些回饋同時餵養三層：規則該補哪條、意圖該養哪個、知識庫該寫哪篇。追蹤的指標至少三個：機器自行解決的比例、意圖與生成層都沒接住而落 fallback 的比例、轉真人的比例與轉接原因分布，三者合起來就是混合架構的健康儀表板。

五個最常見的地雷

第一個地雷是跳過盤點直接上生成式。演示都很神奇，因為演示問的是模型會的問題，上線後使用者問的是你的政策細節，沒有接地資料與評估集，神奇會變成事故。第二個地雷是沒有逃生門，機器人接不住時讓使用者困在迴圈裡，正確設計是認得極限就轉真人，而且轉得乾脆。第三個地雷是不透明，使用者不知道自己在跟機器說話、不知道資料會被怎麼用，信任磨損的速度遠快於功能帶來的加分，把「與機器人對話」講清楚是最低成本的信任工程。

第四個地雷是上線後不維護。規則會過時、意圖會漂移、知識會失效、模型會改版，機器人是需要定期保養的系統，不是一次性的採購。第五個地雷是隱私治理滯後，等資料外流或法規開罰才回頭補政策，代價遠高於事前建立，敏感資料的範圍、存取權限、法規遵循，要在接資料給模型之前就畫好線。

上線前的最終檢查

採購單送出去之前，把這份清單走一遍：問題分布有數字支撐，不是憑印象。高頻題有標準答案文件，答案內容經過核定。任務動到系統的部分走意圖與結構化參數，不讓模型自由心證。生成層的知識來源逐節點綁定，回答附出處。真人轉接的路徑清楚，帶上下文，而且使用者找得到。機器人身分揭露與資料使用告知就位。評估集與三個追蹤指標建好，第一週就能看到儀表板。維護的負責人與週期指派完成，不是「大家輪流看」。

回到最初的問題：聊天機器人怎麼選？三種類型對應三種信任結構，你信任腳本就選規則型，信任訓練出來的分類就選意圖型，信任接地後的模型就上生成式，而真實世界的大型專案三種信任都需要。先用對話紀錄找出流量結構，讓規則與意圖接住可預測的大宗，讓生成式去撈原本只能轉真人的長尾，再把逃生門與衡量儀表板裝好。類型是手段，把對的問題送到對的處理層，才是這個選型題唯一不變的答案。

選型地圖還會繼續擴張，決策型模型是最新的一塊拼圖，決策模型是什麼整理了 Jev 這類模型的題型與適用場景。