AI 電話知識庫怎麼餵？2026 RAG + 反幻覺 4 道防線完整工程指南
TL;DR — AI 電話最怕「講錯」：語音不可撤回、講錯就要走合規補救流程。實務上的 routing rule 是文件量 ≤10 條且 ≤5,000 tokens 注入 system prompt，超過就走 RAG via xAI Collections file_search。再加上反幻覺四道防線（拒答邊界 / 消息來源 / 一致性 check / 人工監督），把答錯率從技術問題變成可治理的工程問題。本文給你注入 vs RAG 三欄對照表、xAI Collections 餵法（PDF / Markdown / 結構化 FAQ）、4 道防線設計、以及法規敏感場景（個資法第 6 條、保險業務員管理規則第 15 條、醫師法第 11 條）的 KB 設計差異。
為什麼 AI 電話比 chatbot 更怕「講錯」
文字 chatbot 講錯，使用者可以回頭重看訊息、截圖留證、退出對話重來。AI 電話講錯，三個層面同時失守。第一，語音輸出不可撤回——一旦說出「療程價 NT$3,800」實際是 NT$8,300，掛上電話前訂正都來不及；第二，通話錄音是法規文件，依通訊保障及監察法第 29 條需事前告知，講錯話的證據比文字工具留得更完整；第三，AI 電話常用於高合規場景（保險、醫療、金融），講錯話的代價不只是客訴，可能是違反業務員管理規則或醫師法的紅線。
這跟文字 chatbot 是兩個工程問題。文字 chatbot 的目標是回答正確；AI 電話的目標是「不講不該講的」加上「講錯的時候有 fallback」。前者靠模型聰明，後者靠系統設計。
兩階段策略：注入 vs RAG 的分水嶺
知識庫餵 AI 有兩條路：注入 system prompt 或走 RAG（Retrieval-Augmented Generation）。實務驗證的 routing rule 很簡單——文件量 ≤10 條且 token 數 ≤5,000，注入 system prompt；超過任一條件，走 RAG via xAI Collections 的 file_search 工具。
| 維度 | 注入 system prompt | RAG (file_search) | Hybrid |
|---|---|---|---|
| 文件量上限 | ≤10 條 | 數百到數千 | 全文注入小型骨架 + RAG 細節 |
| Token 上限 | ≤5,000 | 視 collection 大小 | 注入 ≤2,000 + RAG 補充 |
| 延遲影響 | 0（已在 prompt 內） | 約 +200–500 ms（檢索一次） | +100–300 ms |
| 維護成本 | 低（直接改 prompt） | 中（需重新索引） | 中高 |
| 可追溯性 | 弱（無檢索紀錄） | 強（每次回答可看引用文件） | 中 |
| 適合場景 | FAQ、開場白、簡短 SOP | 完整療程目錄、保單條款、產品資料 | 通用產品 SaaS |
注入適合「永遠相同」的內容——開場白、合規告知、品牌語氣規則。RAG 適合「會變動且量大」的內容——醫美單店的療程價目表（會調漲）、保險商品條款（會出新版）、產品 SKU 列表（會上下架）。一個典型的 zh-TW 部署是兩者並存：開場白與合規告知注入，產品/法規資料走 RAG。
⚠️ 注意：≤10 條 / ≤5,000 tokens 是 zh-TW 場景的實務閾值，不是 Grok 模型本身的硬限制。文件平均長度、查詢複雜度、模型 context window 都會影響實際分水嶺；建議先以 5,000 tokens 為起點，依照接通後的「答錯率」往上或往下調。
xAI Collections 怎麼餵：PDF / Markdown / 結構化 FAQ
要把資料丟進 xAI Collections 走 file_search，先得把資料變成 collection 能消化的形式。三種來源各有處理方式。
印刷 PDF（保單條款、產品手冊）：用 Mistral OCR (mistral-ocr-latest) 抽文字 + 維持版面，輸出 markdown 格式上傳。Mistral 官方說明 OCR processor 「extracts text in content while maintaining document structure」並支援表格輸出為 markdown 或 HTML（Mistral OCR docs 2026）。閾值經驗值：抽出文字 ≥50 字才視為成功，否則代表可能是掃描影像為主的 PDF，需走 vision LLM 路線。
手寫表單 / 病歷 / 諮詢單（醫美、診所常見）：Mistral OCR 是印刷導向，碰到手寫繁體中文會掉很多字。改走 vision LLM（如 google/gemini-2.5-pro 或同等級多模態模型）做結構化抽取，輸出 JSON 格式對齊 CRM 欄位。便宜的 flash / mini / Haiku 等小模型在手寫繁中常出現「靜默漏字」「同音替代」，採購 KB 工程時不要為了省錢踩這個坑。
結構化 FAQ / 價目表 / SOP：直接用 markdown 上傳，每個 chunk 對應一個邏輯單位（一個療程、一條 FAQ、一段 SOP）。Pinecone 在 RAG 架構文件指出，RAG 的四個組件是「ingestion / retrieval / augmentation / generation」（Pinecone 2024），其中 ingestion 階段的 chunk 邊界決定了後三個階段的天花板。chunk 切錯——例如把療程名跟價格切到不同 chunk——後面再多搜尋技巧都救不回來。
反幻覺四道防線：拒答邊界 / 消息來源 / 一致性 check / 人工監督
RAG 解決「找對資料」的問題，但 LLM 還是可能在資料外的問題上憑空生成。AI 電話場景下，「我不確定」比「猜一個」永遠更安全。實務上的常見作法是用四道防線串起來。
第一道：拒答邊界。在 system prompt 明確列出 AI 不該回答的問題類型——「保險商品的具體理賠條件須由業務員親自說明」、「醫療診斷須由醫師親自診察」、「定價以官網最新公告為準」。把拒答邊界寫進 prompt，比寄望模型自我克制有效得多。
第二道：消息來源可追溯。RAG 回答必須附上來源文件 ID，AI 電話的腳本設計要把這個 ID 帶進通話紀錄，事後出錯時能直接定位是 KB 哪一條 chunk 講錯。注入式知識做不到這層追溯，這也是文件量超過閾值就要走 RAG 的另一個理由——可治理性。
第三道：一致性 check。同樣的問題用兩個略有差異的 query 打同一個 collection，比對回答是否一致。不一致就觸發人工 review。這層在開發階段跑一次驗證 KB 健康度，部署後可定期抽樣。
第四道：人工監督 + handoff。當模型 confidence 低、使用者語氣異常或撞到拒答邊界，依照 AI 客服轉真人怎麼設計 的 4 大觸發邊界自動升級。AI 電話的 handoff 不是「AI 失敗的退場」，是「答錯成本太高時主動讓位」。
💡 實務通則：四道防線不是擋牆，是漏斗。拒答邊界擋掉約 60% 風險、消息來源讓另外 25% 可被事後追責、一致性 check 抓出 10% 的不穩定 KB、剩下 5% 走人工。比例會隨產業變動，但這個分層思路適用任何高合規 AI 電話部署。
法規敏感場景的 KB 設計差異
不同產業的 KB 不只是內容不同，連結構都不同。
保險業：受保險業務員管理規則第 15 條規範，業務員須親自說明條款。意思是 AI 電話的 KB 不應該把「條款細節」當作可以由 AI 完整回答的內容；應該把條款資訊切成「能告知客戶有哪些保障項目」（AI 可答）跟「具體理賠條件」（拒答 + handoff 給業務員）兩層。KB 設計的選擇直接決定產品有沒有踩線。
醫療場景：受醫師法第 11 條規範，診斷須由醫師親自進行。醫美診所的 KB 必須把「療程資訊」（術後照護、預約改期、價目區間）跟「個案診斷」（適合什麼療程、有什麼風險）切開——前者 RAG 可答，後者一律拒答 + 安排與醫師對話。
敏感個資：個資法第 6 條針對醫療紀錄、基因、性生活等敏感資料給更高保護門檻。意思是 KB 裡如果包含特定客戶的「療程紀錄」「健康狀況」「保單條款客製化部分」，這些 chunk 要 access-controlled，不能跟一般 FAQ 混在一起當公開 RAG 來源。Brightalk 採用的 contact-level 資料分層設計就是回應這條法規。
5 個常見 KB / RAG 工程坑
第一，掃描 PDF 變亂碼：用文字抽取（regex / Tj/TJ operators）會把 JPEG bytes 誤抓成偽文字，產生二進位垃圾上傳。閾值要嚴格——抽出 <50 字一律 routing 到 OCR 路線，不要硬塞。
第二，chunk 邊界錯切：療程名跟價格、條款編號跟內容、Q 跟 A 被切到不同 chunk，搜尋找到一半丟一半。chunk 切的邏輯應該是語意單位優先，不是固定字數。
第三，FAQ 過時不重訓：價目調整、條款改版、SKU 上下架後 KB 沒同步，AI 還在講舊資料。建議建立「KB 變動 → 自動觸發 collection 重新索引」的 webhook 流程。
第四，多版本衝突：同一條 FAQ 在不同分店有不同答案、保單條款有舊版新版同時存在，RAG 找到的是哪一條？KB 設計要強制版本標記 + 過期 chunk 軟刪除（保留以對齊舊客戶的歷史回答，但新查詢不召回）。
第五，索引 staleness：上傳了不代表生效。xAI Collections 上傳到可被 file_search 召回中間有索引時間，依檔案大小幾秒到幾分鐘不等。剛上傳的內容若馬上做 AI 電話測試，可能還在用舊索引。
✅ 快速行動：剛開始建 KB 不要追求完整。先把「客戶最常問的 20 個問題 + 5 個拒答邊界」上線，跑一週看接通後的答錯率；再依答錯記錄補 chunk。完整 KB 一次到位的部署成功率比迭代式低很多。
常見問題
AI 客服知識庫該用注入還是 RAG？
文件量 ≤10 條且 ≤5,000 tokens，注入 system prompt 最簡單；超過就走 RAG via xAI Collections file_search。實務 routing rule 以這兩個閾值為起點，再依答錯率調整。
印刷 PDF 跟手寫文件處理方式不同嗎？
不同。印刷 PDF 用 Mistral OCR (mistral-ocr-latest) 抽文字 + 維持版面（Mistral 2026）。手寫繁體中文（醫美諮詢單、病歷）要走 vision LLM（google/gemini-2.5-pro 等多模態模型）做結構化抽取，避免小模型「靜默漏字」「同音替代」的問題。
AI 講錯話該誰負責？
依產業而定。保險業務員管理規則第 15 條要求業務員親自說明，所以 AI 講錯保單條款的責任在業務員與公司；醫師法第 11 條要求診斷由醫師進行，所以 AI 不該做診斷類回答。設計 KB 時就把這些「不該答」的問題列入拒答邊界，而不是事後出錯再補救。
知識庫多久要更新一次？
依 KB 類型不同。FAQ / 開場白 / 合規告知建議季度 review；價目表 / 商品列表 / SOP 改版時即時同步（建立 webhook 觸發 collection 重新索引）；保單條款 / 醫療資訊跟監管同步——條文一改、KB 必須當週更新。
想看完整 AI 電話導入路徑、外撥腳本設計與 KPI 設定？閱讀本系列的支柱長文 AI 電話行銷完整指南。