客戶找上我們的第一句話幾乎都一樣：「我們官方帳號每天回一樣的問題回到手軟，能不能讓 AI 幫忙？」過去一年我們接了好幾個這類案子，幾乎全部用 RAG（Retrieval-Augmented Generation）落地，而不是大家以為的「拿公司資料去 fine-tune 一個模型」。

這篇筆記把我們從零搭一套 LINE Bot RAG 客服的完整流程攤開來——技術選型、架構、踩過的坑、真實成本，還有一份能直接照做的上線檢查清單。也誠實講哪些情境其實不該做 RAG。

1. 為什麼選 RAG 不選 fine-tune

幾乎每個客戶都先問：「不是把我們的資料丟給 AI 學一學就好了嗎？」這就是 fine-tune 的迷思。我們的判斷標準很簡單，看三件事：

  • 知識會不會變：客服 FAQ、退換貨政策、產品規格幾乎每個月都在改。fine-tune 改一條答案就要重新訓練、重新部署；RAG 只要更新知識庫一筆資料，下一秒就生效。
  • 要不要溯源：客戶最怕 AI 亂講話。RAG 每個回答都能附上「這段是從哪份文件來的」，出事好追查；fine-tune 把知識揉進權重裡，你永遠不知道它為什麼這樣答。
  • 幻覺控制：RAG 把模型限制在「只能根據我給你的這幾段內容回答」，prompt 一句「找不到就說不知道、不要自己編」就能擋掉大半亂答。

實務上，fine-tune 適合的是「調語氣、調格式」這種風格層面的需求，不是「灌知識」。我們做過的所有 LINE 客服案，沒有一個真正需要 fine-tune——RAG 加上好的 prompt 就解決了。

有個做美妝電商的客戶原本被外包商說服要花六位數做 fine-tune，我們接手後改用 RAG，知識庫更新從「等廠商重訓三天」變成「後台貼上新文件五分鐘生效」，第一個月就把人工客服的重複問答量壓掉約 65%。

2. 向量資料庫選型

RAG 的核心是把知識切塊、轉成 embedding 向量存起來，問問題時用語意相似度撈回最相關的幾段。存向量的地方就是向量資料庫。我們的選型不複雜，照規模分三層：

小案子：pgvector

如果客戶本來就有 Postgres，或知識量在數千 chunk 以內，我們直接用 pgvector extension。好處是不多養一個服務、備份與權限沿用現有 DB、SQL 就能做 metadata filter。八成的 LINE 客服案，pgvector 綽綽有餘。

要快速上雲：Pinecone / Qdrant

客戶沒有 DB 團隊、想要 managed service，我們用 Pinecone（全 managed、最省事）或 Qdrant（可 self-host、open source、filter 強）。這層適合知識量上萬、要水平擴展、或多租戶隔離的場景。

選型踩過的坑

  • 別一開始就上重武器：有個案子前手用了 Milvus 叢集跑 800 條 FAQ，維運痛苦又貴。我們搬回 pgvector，成本降到趨近於零。
  • embedding 模型要先定：換 embedding model（例如從 OpenAI 換成 Cohere）等於整個庫要重新 embed，先測好再大量灌。
  • metadata 比向量更重要：能用「文件類別 / 更新日期 / 適用商品」過濾，召回品質會比純語意搜尋高一大截。

3. LINE Webhook 架構

LINE 官方帳號的訊息是用 Messaging API 的 Webhook 推給你的伺服器。整條鏈路我們長這樣：

  • 接收：LINE Platform → 你的 /webhook endpoint（HTTPS）
  • 驗證：用 channel secret 驗 x-line-signature，擋掉偽造請求
  • 先回 200：立刻回應 LINE，把實際處理丟進 queue 非同步做
  • RAG 處理：embedding → 向量檢索 → 組 prompt → LLM 生成
  • 回覆：用 reply token 或 push message 把答案送回使用者

這裡有兩個一定要做對的點，否則上線一定出事：

第一，先回 200 再處理。LINE 的 Webhook 有逾時限制，RAG 一輪跑下來常常要 3–8 秒，如果你等 LLM 回完才回應 LINE，會被判定逾時、觸發重試，使用者就收到重複訊息。正解是收到就先回 200，把工作丟進 BullMQ / Cloud Tasks 之類的 queue，處理完用 push message 送回。

第二，reply token 會過期。reply token 只能用一次且有時效，非同步處理太久就失效。我們的做法是先用 loading animation 撐住體感，超過 reply token 時效就改用 push message。有個餐飲連鎖的案子，就是沒處理這段，尖峰時段大量訊息卡在同步處理、token 過期，回覆掉了快三成——改成 queue + push 後掉訊率降到趨近於零。

4. 知識庫建構

這是整個專案最被低估、卻最決定成敗的一段。我們的經驗是：成效的 80% 來自知識庫怎麼切、怎麼標，而不是模型選哪一家。

Chunking 策略

  • 按語意切，不要按字數硬切：一段 FAQ 的問與答要切在一起，別讓答案被切兩半。
  • chunk 不要太大：太大會稀釋語意、撈回一堆不相關內容；我們常用 300–600 字一塊，視內容調整。
  • 保留 overlap：相鄰 chunk 重疊一兩句，避免關鍵句剛好被切斷。

資料清洗與 metadata

客戶給的原始資料通常是 Word、PDF、甚至 LINE 對話截圖。我們會先轉成乾淨的 Markdown，去掉頁首頁尾雜訊，然後幫每個 chunk 打上 metadata：文件來源、類別、最後更新日。檢索時先用 metadata 縮小範圍，再做語意比對，召回精準度明顯提升。

持續維運才是重點

知識庫不是建一次就結束。我們會給客戶一個簡單後台或一份共用文件，讓他們自己更新；改動觸發 re-embedding，自動同步進向量庫。這也是 RAG 完勝 fine-tune 的地方——維護成本天差地遠。

5. 成本估算

客戶最關心的永遠是錢。以一個每月約 3,000 則對話的中小型官方帳號估算（數字會隨知識量與模型浮動）：

項目 用量假設 月成本（約）
Embedding（建庫＋查詢） 初次建庫一次性＋每次提問轉向量 NT$100 以內
LLM 生成（Claude / GPT） 3,000 則 × 平均輸入輸出 token NT$1,200–2,500
向量資料庫 pgvector 共用現有 DB 趨近 0
伺服器 / Webhook 託管 小型 VPS 或 serverless NT$300–800
合計 — 約 NT$1,500–3,300

對照一個客服人力一個月動輒三、四萬，這套系統承接掉 60% 以上的重複問答，ROI 通常第一個月就轉正。要再壓成本，可以把簡單問題路由到便宜的小模型、難題才送大模型，我們實測能再省 30–40% 的 LLM 費用。

6. 上線檢查清單

交付前我們會逐項確認以下這些，缺一項都不敢上：

  1. Webhook 簽章驗證已開啟，偽造請求會被擋
  2. 收到訊息先回 200、處理走非同步 queue
  3. reply token 過期時自動 fallback 成 push message
  4. prompt 有明確指令：找不到答案就誠實說不知道、不要編造
  5. 每筆回答記 log：問題、撈回的 chunk、最終回覆，方便事後追查與調優
  6. 設好人工接手機制：使用者打「找真人」或連續答不好時轉專員
  7. 知識庫更新流程客戶能自己操作，並驗證 re-embedding 有生效
  8. 準備 30–50 題回歸測試題庫，每次改 prompt 或知識庫都跑一遍
  9. 設定用量與費用告警，避免被刷爆 API

結語：RAG 不是萬靈丹，但用對地方非常香

我們誠實說：RAG 不是所有客服都該上。如果你的問題大多需要「即時查這位客人的訂單到哪了、這個品項還有沒有貨」，那要做的是串你的後台 API，RAG 只是其中一塊；如果你的知識量小到十條 FAQ 就能涵蓋，那一個圖文選單或關鍵字自動回覆就夠了，不必動用 AI。

但只要你的客服每天在回大量會變動、需要溯源、又無法用固定選單窮舉的問題，RAG × LINE 幾乎是目前 CP 值最高的解法。

如果你正在評估要不要幫官方帳號上 AI 客服，加 LINE 跟我們聊 30 分鐘，我們會先看你的問答樣態，誠實告訴你該做 RAG、該串 API、還是其實一個選單就解決——不收顧問費，因為這通常是合作的起點。