文章目錄
先選一個確實需要協助的流程，再決定要不要放聊天視窗。 如果訪客只是找營業時間，清楚的頁面可能就夠；如果每天有大量產品規格比較、文件查詢或詢問分流，AI 才有值得驗證的工作。
這裡的「接 ChatGPT」指在網站後端串接模型 API 或採用客服服務，不是把個人的 ChatGPT 對話視窗直接嵌進官網。
四種用途，需要不同設計
| 用途 | 先確認什麼 | 失敗時怎麼處理 |
|---|---|---|
| 公開 FAQ 與產品問答 | 有沒有經過確認且持續更新的答案 | 顯示來源、轉人工，不猜政策 |
| 內部知識庫 | 文件版本與每位員工的存取權限 | 沒權限不檢索，找不到就明確說明 |
| 文案與回覆草稿 | 品牌用語、產品事實、誰負責核稿 | 人工確認後再發布 |
| 分類與系統操作 | 錯分成本、可執行動作、是否可撤回 | 例外送人工，重要操作先確認 |
像查訂單這種工作，重點是核對使用者身分、從系統讀取最新狀態，以及限制可回傳的欄位。把訂單文件放進知識庫，不能取代這些設計。
若需求主要是固定條件分流，可以先看〈自動化一定要用 AI 嗎〉，比較規則、AI 與人工各自負責的部分。
RAG 有幫助，但不會自動消除錯誤
RAG（檢索增強生成）會在回答前尋找相關文件，把找到的片段與問題一起交給模型。它讓回答有機會依據你的資料，但文件過時、檢索錯段、權限判斷錯誤，或模型誤讀原文，都可能造成錯誤。
OWASP 的生成式 AI 錯誤資訊指南將 RAG 列為降低風險的方法，也同時建議驗證與人工監督。不能把「有做 RAG」寫成「保證只會回答正確資料」。
我會把驗證拆成三步：
- 先看有沒有找到正確、有效且允許讀取的文件。
- 再看回答是否忠於來源，引用是否真的支持結論。
- 最後測試資料不足、相互矛盾、超出服務範圍時，系統能否停止回答並交給人工。
知識量很少時，直接提供經整理的內容也可能足夠。要先用問題集驗證，再決定需不需要向量資料庫或其他檢索工具。
三條實作路徑怎麼比較？
| 路徑 | 適合先評估的情境 | 要由誰承擔的工作 |
|---|---|---|
| 現成 SaaS | 現有客服流程接近產品提供的功能 | 供應商維護平台；你負責資料、設定、抽檢與人工接手 |
| API 串接 | 需要客製介面、權限或系統整合 | 開發者負責應用與串接；模型由供應商提供 |
| 自行部署模型 | 有明確部署限制、維運能力與驗證過的需求 | 團隊負責模型、設備、更新、監控及服務可用性 |
SaaS 也可能支援知識庫與整合；自行部署也不代表天然符合隱私規範或一定更便宜。需要比較的是實際方案、資料流、測試結果與長期維運責任。
時程取決於資料是否就緒、要串接幾套系統、驗收條件和內部確認速度。應請廠商把原型驗證與正式上線拆開估，而不是用「一週裝好」代替完整交付範圍。
資料與成本，要在試用前問清楚
先畫出資料會經過哪些服務，逐一確認是否用於訓練、保留多久、儲存地點、誰能讀取，以及刪除方式。
以 OpenAI API 資料控制文件為例，API 資料預設不會用於訓練，除非主動選擇分享；但濫用監控紀錄與部分功能的應用狀態仍可能被保留。「不拿來訓練」不等於「完全不留存」，也不能直接套用到其他產品或供應商。
費用則分成：
- 模型用量：分開計算輸入、輸出、快取及所用模型。
- 額外服務：搜尋、工具呼叫、文件儲存、資料庫及主機。
- 營運工作：文件更新、回覆抽檢、例外處理與程式維護。
先以真實對話測量，並記錄每段對話觸發幾次模型請求。各模型與工具費用以官方 API 價格頁和實際帳單為準。更完整的拆法見〈AI 客服真的要花多少〉。
上線前先做一個小範圍試驗
選定一組問題與一群使用者，先記錄目前人工處理時間，再測試 AI 能處理多少、哪些必須轉人工，以及是否增加了更正錯誤的時間。
例如先只回答公開產品文件，暫不修改訂單或承諾退費。若文件不足，先整理文件；若入口不清楚，先改善導覽。每一輪都應該能說明「解決了哪個問題」，再決定要不要擴大範圍。
常見問題
什麼是 RAG，AI 客服一定需要它嗎？
RAG 會先檢索相關資料，再交給模型生成回答，適合需要查閱文件的情境。它不保證答案正確，也不是所有 AI 功能都必須使用；固定流程可用規則處理，即時訂單資料則通常要透過有權限控管的 API 查詢。
把 ChatGPT 接到網站每個月要花多少錢？
要分開估算模型輸入與輸出用量、工具與儲存費、平台月費及維護人工。先拿真實對話測量每次請求，再依月對話量估算；只知道對話次數，還不足以推算帳單。
AI 客服上線後沒人用，應該先檢查什麼？
先確認訪客是否真的有需要協助的問題、入口是否容易找到、回答能否解決問題，以及轉真人是否順暢。用使用率、問題解決率與人工接手紀錄找原因，不要只憑對話數決定成敗。
想評估自己的場景，可以預約免費需求釐清，先帶一段目前流程與幾個真實問題來討論。
