企業 AI 客服實戰：從掃描紙本單據到自動回答的完整記錄（2026）

企業 AI 客服系統，是指將公司內部的文件、訂單、知識庫結構化後，讓員工或客戶用自然語言直接查詢的問答系統。核心不是「裝一個聊天機器人」，而是「把散落在紙本和 Excel 裡的資料變成 AI 能讀懂的格式」。

這篇記錄的是一個飯店宴會部的 AI 問答系統。業主名稱和細節已匿名處理，但技術選型、踩坑經驗、費用數字都是真實的。

如果你在評估「我們公司適不適合做 AI 客服」，這篇的經驗可能比任何產品 demo 都有參考價值 — 因為 demo 不會告訴你 開源模型冷啟動 73 秒的時候系統長什麼樣子。

業主的痛點：每天翻紙本回答一樣的問題

宴會部業務每天被問的問題，80% 是重複的：

• 「下週三晚上 A 廳幾桌？」
• 「6/15 那場有沒有素食需求？」
• 「這個月還有哪幾天 B 廳是空的？」

答案全部寫在 EO 單（Event Order）上 — 一張紙本表單，記錄每場宴會的場地、時間、桌數、菜單需求、特殊備註。

問題是，EO 單是紙本的。業務要回答這些問題，就得翻檔案。一天翻個十幾次，每次翻完還要手動比對日期和場地。有時候還會翻錯、看漏。

業主跟我說的原話是：「我的人每天花兩小時在翻紙，這些時間拿去跟客戶提案不是更有價值嗎？」

這就是這個案子的起點。不是「我想導入 AI」，是「我想讓業務不要再翻紙了」。

做了什麼（業主視角）

從業主的角度看，整個系統很簡單：

1. 每天把掃描好的 EO 單 PDF 丟進系統
2. 系統自動辨識、自動存檔
3. 業務打開查詢介面，用說人話的方式問問題
4. 系統回答

就這樣。業主不需要知道背後跑了什麼模型、用了什麼搜尋演算法。他只在乎兩件事：答案對不對，速度快不快。

但在開發端，為了讓這四步看起來「這麼簡單」，踩了不少坑。

從這個案子學到的 4 個原則

寫到這裡先暫停一下。這個案子跑完之後，我整理出 4 個跟 AI 開發有關的 high-level 原則。不是什麼 API 層的 bug fix，而是「下次再做類似案子，我第一天就會記住的事」。

省 API 費用 vs 使用者體驗，不要猶豫

一開始選了一套開源 AI 模型做主力。原因很單純 — 便宜，費用大概是商用模型的十分之一。

結果冷啟動（cold start）要 73 秒。

系統的 HTTP timeout 設 30 秒。每次第一個查詢都是 timeout。業務按了查詢、等了半分鐘、看到錯誤訊息、以為系統壞了。

我當時做了一個補救措施：系統每 5 分鐘自動送一個假查詢，讓模型保持「醒著」的狀態。結果開源模型那邊的保活策略不穩定，有時候 5 分鐘保得住、有時候保不住。更慘的是深夜沒人用的時候，早上第一個查詢還是爆。

最後換成商用模型。費用確實變高了，但啟動時間在 2-3 秒內，使用者體驗從「這系統是不是壞了」變成「哦，答案出來了」。

這個決定花了我大概一週的猶豫時間。回頭看，應該第一天就換。省 API 費用省到使用者覺得系統不能用，那就不是省錢，是在燒信任。

永遠假設 AI 的輸出是髒的

AI 回傳的資料庫查詢指令，有時候會被包在 markdown 的 code block 裡面：

```sql
SELECT * FROM events WHERE date > '2026-06-01'
```（結尾）

直接拿去跑資料庫？噴錯。因為實際字串包含了反引號和 sql 這個語言標記。

這不是某個模型的 bug，這是 AI 語言模型的本質 — 它傾向於用「對人類友善的格式」回答，而不是「對程式友善的格式」。

解法是在 AI 輸出和資料庫執行之間，加一層防禦性處理：

• 剝離 markdown code block 的反引號和語言標記
• 驗證 SQL 語法的基本結構（是否為 SELECT 開頭、有沒有危險操作）
• 如果解析失敗，不要直接噴錯給使用者，而是回傳「我沒辦法理解這個問題，可以換個方式問嗎？」

原則：AI 的輸出永遠要經過一層清洗。不管指令寫得多精確，不管測試的時候跑了幾百次都正常，上線之後它就是會在你沒想到的地方給你驚喜。

AI 呼叫越少越好

一開始的架構是 2 次 AI 呼叫：

1. 意圖判斷：使用者的問題是查詢型、閒聊型、還是超出範圍？
2. 查詢生成：根據意圖，生成 SQL 或回傳制式回答

這個設計在邏輯上很乾淨。但實際上線：

• 延遲翻倍（兩次 API round trip）
• 費用翻倍（兩次 token 消耗）
• 失敗機率翻倍（任一次呼叫失敗 = 整個查詢失敗）

後來把兩步合成一步 — 一次 AI 呼叫就同時判斷意圖和生成查詢，用結構化格式約束 AI 的回傳內容，確保它回的東西程式能直接用。

結果：延遲砍半、費用砍半、程式碼也變簡單了。

每一次 AI 呼叫 = 費用 + 延遲 + 一個可能的失敗點。在設計的時候，先問自己：「這兩次呼叫真的不能合成一次嗎？」

AI 解析不能盲信，要設計信任閥門

Azure Document Intelligence 解析 EO 單的結果，每個欄位都帶一個 confidence score（信心分數）。一開始我沒管這個數字，全部照單全收。

然後就出事了 — 有一張 EO 單的桌數欄位印得比較淡，AI 辨識成 18 桌，實際是 13 桌。業務用系統查出來跟實際不符，直接失去對系統的信任。

解法是把信心分數分成三檔：

這個設計讓系統不會因為一筆錯誤資料就失去業務的信任。業務知道「系統不確定的東西會先問我」，反而更願意用。

如果你正在做文件解析相關的系統，信心分數分流是我目前遇過投資報酬率最高的防禦機制。成本幾乎為零（Document Intelligence 本來就會回傳分數），但對信任感的影響是巨大的。

關於 Document Intelligence 的技術細節，可以參考之前寫的 Document Intelligence 文件理解分析。

搜尋設計：精確、語意、還是混合？

業務問的問題有兩種極端：

• 精確型：「6/15 A 廳幾桌？」→ 需要精確匹配日期和場地
• 語意型：「下週有沒有吃素的活動？」→ 需要理解「吃素」= 素食需求

只用關鍵字搜尋，語意型的問題接不住。只用語意搜尋，精確型的日期和場地編號反而會被忽略。

最後用混合搜尋（Hybrid Search）— 兩路同時跑，關鍵字搜尋負責精確匹配，語意搜尋負責理解意圖，再把兩邊的結果合在一起排名。

之前寫過一篇 混合搜尋技術深入分析，有興趣的可以看那篇。

查詢流程用非同步設計：使用者送出問題後，系統先回傳「收到了，正在處理」，前端每 2 秒自動去問一次結果。這樣做是因為 AI 回應時間不穩定（快的 1 秒，慢的可能 5-8 秒），讓使用者乾等的體驗很差。

外部系統整合：最不性感但最花時間的部分

飯店不只有紙本 EO 單，還有一套舊的宴會管理系統。這套系統會推送訂單異動通知過來。

聽起來很簡單？實際上推過來的訂單要跟 AI 解析出來的資料做合併，合併規則分三種：

• Case 1：新訂單 — 舊系統有、AI 解析沒有 → 直接新增
• Case 2：更新訂單 — 兩邊都有，但欄位值不同 → 以舊系統為主（因為舊系統有人工輸入）
• Case 3：衝突 — AI 解析的信心分數很高但跟舊系統的值不一樣 → 送人工審核

這三種 Case 的處理邏輯佔了整個專案大概 30% 的開發時間。這也是為什麼我說 AI 專案最花時間的部分通常不是 AI 本身。

費用和監控

上線後用監控工具追蹤每次查詢的 AI 用量和回應速度。這不只是為了算帳，更重要的是抓出異常 — 有一次發現某類問題的 AI 用量暴增 3 倍，追查之後發現是系統指令被重複送出了。

費用拆解（月估算，中小型飯店用量）：

跟「一個人每天省 2 小時」的人力成本比，回本速度很快。

回頭看：什麼可以做得更好

• 一開始就該設信心分數分流，不是等到出錯才加
• 開源模型的冷啟動問題應該用效能測試先確認，不是上線了才發現
• 外部系統整合的規格應該在開發前就跟業主 100% 確認，不是邊做邊改

這些聽起來都是「事後諸葛」，但如果你現在正要做類似的案子，這些是我真心希望有人第一天就告訴我的事。

整個系列的其他案子可以從 中小企業自動化實戰總覽 看到。

如果你在評估類似的 AI 專案，歡迎參考 我的合作方案。

FAQ

企業導入 AI 客服系統要花多少錢？

主要成本分三塊：開發費（一次性）、AI 雲端服務月費（文件辨識 + 問答引擎）、以及維護費。AI 費用跟查詢量直接相關，這個案子透過架構優化把 AI 運算次數減半，費用也跟著砍半。實際月費看用量，中小型飯店大約落在幾千台幣以內。

AI 辨識紙本文件的準確率夠高嗎？

AI 文件辨識對印刷體的辨識率很高，但不代表可以盲信。這個案子設計了信心分數三檔機制：高信心自動入庫、中信心送人工確認、低信心擱置不用。實際跑下來大約 70-80% 的欄位直接通過，需要人工確認的大約 15-20%。關鍵是不要讓錯誤的資料悄悄混進資料庫。

為什麼不直接用 ChatGPT 回答，還要做這麼複雜的系統？

因為 ChatGPT 沒有你公司的即時資料。業務問的是「下週三晚上 A 廳有幾桌」，這種答案每天都在變，必須從你自己的資料庫撈。AI 客服的核心不是 AI 多聰明，而是資料管線能不能把正確的、最新的資料送到 AI 面前。沒有這條管線，AI 就只能瞎猜。