LINE Bot＋Gemini 做 AI 客服：從產品手冊 RAG 到多租戶客服平台的實戰踩坑
Threads 分享 PM 以 Vibe Coding 將 LINE Bot、Gemini Embedding、pgvector、Jina Reranker、Gemini 2.5 Flash 組成 AI 客服，並做成多租戶平台；本文整理文件同步、RAG pipeline、File Search 取捨、LINE 後台衝突、模型退役與回饋閉環。
AI Customer Support · LINE Bot · Gemini RAG
這則 Threads 的價值在於它不是「AI 客服可以做」的概念文，而是一個 PM 把 GDG / Google I/O Extended 2026 聽到的 LINE Bot＋Gemini 想法，真的做進公司產品的實戰紀錄。技術棧不複雜，但取捨很真實：GitHub 文件同步、Gemini Embedding、pgvector、Jina Reranker、Gemini 2.5 Flash、多租戶隔離與 LINE 後台設定。
實作架構
| 層級 | 做法 | 為什麼重要 |
|---|---|---|
| 知識來源 | 產品操作手冊原本就在 GitHub Repo 維護；透過 GitHub App 串兩個 repo 自動同步。 | 工程師更新 Markdown 文件時，AI 客服知識也更新；避免人工搬檔。 |
| 變更偵測 | 每份文件計算 checksum；只有內容異動才重建索引；來源刪除也從知識庫移除。 | 降低重建成本，避免舊文件殘留。 |
| Embedding | 文件切段後用 Gemini Embedding 轉向量。 | 與客服自己的 Gemini API Key 共用，少管理一組 provider。 |
| 向量庫 | PostgreSQL + pgvector。 | 對 SaaS 平台友善，能和業務資料/租戶資料同一治理框架。 |
| Rerank | Jina Reranker 重新排序候選段落。 | 避免只靠向量相似度抓到「看起來像但不是最適合」的內容。 |
| 回答模型 | Gemini 2.5 Flash 產生自然回答。 | 速度/成本適合客服場景；中文表現符合作者需求。 |
為什麼沒直接用 Gemini File Search
Evan Lin 的分享提到 Gemini API 家族已包含 File Search、Agents API、Webhook、Batch、Live API 與 Context Caching；Google 官方 File Search 確實能加速一般 RAG 助理開發。但這個案例最後選擇自己組 pipeline，原因是公司需求更像平台：
- 一套系統要服務多條產品線。
- 每個客服有自己的知識庫、LINE 官方帳號、API Key、資料來源。
- 要控制文件同步、索引更新、provider 切換與資料刪除。
- 金鑰與憑證需加密存放，租戶彼此隔離。
踩坑清單
AI 太謙虛
手冊沒有逐字寫到時，模型會說「沒有這功能」或「要客製」。Prompt 需禁止它否定功能存在、禁止自行推論需客製，改成引用手冊證據或要求轉真人。
換句話問不到
商家用別名或英文名稱會漏檢。解法是把文件 frontmatter 的 keywords / aliases 一起轉向量。
模型會退役
Gemini 舊版模型曾突然 404。模型名稱必須設定化，不可寫死在程式。
LINE 後台會搶答
LINE 官方帳號的自動回應、AI 自動回應、加好友問候語要關掉，否則會和自架 bot 同時回覆。
客訴/訂單處理風險
回答 FAQ 和處理訂單不是同一級風險。能自動處理前，需明確規則、轉真人條件、權限與稽核。