先把 LINE 當成通道，不要把它當成整套客服系統
在許多導入案裡，第一個常見誤區是把 LINE 官方帳號想成 AI 客服的主系統。比較穩健的做法，是把 LINE OA 視為使用者進出的訊息通道，真正的客服邏輯放在後端服務。LINE Messaging API 負責接收事件、驗證簽章、回覆訊息與推播；後端則負責判斷使用者身分、查詢知識、呼叫模型、記錄對話、轉接人工與串接內部系統。
這樣切分的好處是可替換性與可治理性。未來如果同一套 AI 客服也要接網站 chat、Facebook、App 或內部客服台，不需要重寫核心邏輯。LINE 只是一個 adapter，企業的知識、流程與權限規則留在共用層。工程上建議把 webhook handler 做薄，收到事件後先標準化成內部 message event，再交給對話編排服務處理。
- Webhook 層：處理 LINE 簽章驗證、reply token、事件去重、重送保護與基本格式轉換。
- Conversation 層：管理對話狀態、使用者上下文、意圖判斷、回覆策略與人工轉接條件。
- Knowledge 層：負責文件切分、向量檢索、權限過濾、版本管理與引用來源。
- Integration 層：串接 CRM、ERP、訂單、維修、會員或 IoT 平台，並把可執行動作明確隔離。
- Observability 層：保留請求紀錄、模型輸入輸出、檢索結果、錯誤與人工修正紀錄。
RAG 要設計成可稽核的知識流程，而不是單純塞文件
LINE AI 客服最常被期待回答產品、報修、訂單、服務條款與操作問題。這類問題通常不適合只靠模型記憶，因為企業內容會更新，也涉及部門責任與法務措辭。實務上通常會用 RAG，讓模型先檢索企業知識，再根據可引用的內容產生回答。關鍵不在於有沒有向量資料庫，而在於資料治理是否清楚。
文件進入知識庫前，應該先定義來源與更新責任。官網 FAQ、產品手冊、客服 SOP、內部公告、價格規則、維修政策，可信程度不同，更新頻率也不同。工程團隊需要替每份內容保留版本、來源、有效日期與適用對象。檢索時也要考慮權限，經銷商、企業客戶、一般消費者與內部客服看到的內容可能不同。
回覆策略上，我們通常建議 AI 回答時採取保守原則：只根據檢索到的內容作答；找不到依據時承認不確定；涉及合約、金額、個資、醫療、法律或保固爭議時轉人工。這不是讓 AI 變笨，而是讓系統可控。企業客服真正需要的是穩定與可追溯，不是每次都講得很像專家。
把工具呼叫和一般問答分開，降低錯誤操作風險
LINE 客服常不只回答問題，還會查訂單、建立工單、預約服務、更新會員資料或查設備狀態。這些動作牽涉企業系統，因此架構上要把一般問答和工具呼叫分開。模型可以判斷使用者需求與產生參數草稿，但真正執行前應由後端做 schema 驗證、權限檢查、業務規則檢查與必要的人類確認。
例如使用者說「幫我查上次維修進度」，系統不應直接讓模型自由組 SQL 或呼叫任意 API。比較合理的方式是讓模型選擇預先定義好的工具，例如 getRepairStatus，後端再依 LINE userId 對應會員或客戶資料，確認身分後才查詢維修系統。如果資料不足，AI 應該先補問，而不是猜測。
- 低風險工具：查詢公開 FAQ、查門市資訊、查一般服務流程，可以較自動化。
- 中風險工具：查訂單、查維修、建立客服單，需要身分確認與完整紀錄。
- 高風險工具：取消訂單、修改資料、退款、合約變更，通常需要二次確認或人工審核。
- 不可開放工具：直接資料庫寫入、任意內部 API 呼叫、未授權跨客戶查詢，應該由後端封裝或禁止。
人工轉接、失敗處理與營運後台要一開始就納入
一套可上線的 AI 客服，不能只設計成功路徑。LINE 對話裡常出現語意不完整、圖片截圖、語音、錯字、連續追問、情緒性抱怨與多議題混在一起的情況。系統需要明確的 fallback 流程：何時補問、何時提供選單、何時轉人工、何時建立工單、何時停止自動回覆。
人工轉接也不能只是回一句「請等候客服」。實務上需要把對話摘要、使用者身分、已查過的資料、模型判斷、檢索來源與建議下一步一起交給客服人員。否則 AI 前面處理越久，人工接手時反而越難理解。若企業已有 Zendesk、Freshdesk、Salesforce、HubSpot、自建 CRM 或 ERP 工單模組，AI 層應該用 integration adapter 串接，而不是另外做一套孤立後台。
營運後，工程團隊應定期檢查無法回答的問題、錯誤引用、人工改寫、熱門主題與工具呼叫失敗原因。這些資料會回饋到知識庫、prompt、工具 schema 與轉接規則。AI 客服不是一次建好就放著，而是一個持續校準的系統。若企業沒有內部 AI 平台團隊，與熟悉 LINE、雲端、資料治理和企業系統整合的團隊合作，通常能少走很多架構彎路。