一、背景與緣由

筆者任職的公司客戶為電商平台，因人力不足，加上客服人員非專門編制，需要輪流值班，常常在本身工作之外抽空處理客戶提問。若能透過自動化回覆減少真人客服負擔，將大幅提升效率。

既然決定開發自動化客服，首先需要研究可用技術。筆者去年在 RAG（Retrieval-Augmented Generation） 與 function calling 正火熱時，就開始設計系統架構，先從 FAQ 與活動說明資料入手。

在選擇 LLM 時，建議依公司政策與模型能力決定。筆者所在單位主要使用 Google 服務，因此選擇 Gemini，並暫時放棄 GPT（因開發票流程繁瑣）。

接著需要決定向量資料庫，最初選擇 Pinecone：免費額度、可視化界面、SaaS 架構方便管理。這讓 FAQ 與活動內容的自動回覆可以順利運行。

隨著初步架構完成，開始搜集客服常見問題，發現除了 FAQ 和活動說明，更多是詢問到貨日、產品疑問等。於是陸續增加功能，同時考慮將部分工具回傳結果再交給 LLM 處理，以減少重複邏輯，提高可維護性。

早期使用 Gemini 原生架構時，需要自己實作很多流程，且偶爾會遇到 500 錯誤，需要切換不同模型版本。這也促使後續引入 LangChain 以提升穩定性與可控性。

二、Why LangChain

• 快速替換 LLM
  原生框架容易被綁定特定模型，LangChain 提供抽象化接口，方便替換。

• 流程可控
  早期需控制工具使用順序，原生寫法麻煩，使用 LangGraph 可透過節點與條件分支明確流程。

• Debug 工具
  可搭配 LangSmith，提供網頁後台記錄每次呼叫，快速定位問題。

筆者早期嘗試 LangChain 時覺得寫法不順手，但若要快速驗證流程，原生寫法也是可行方案。

三、系統架構

• 前台：使用 Line 做串接，需考慮真人客服與機器人協作的上下文問題。
• Webhook 部署：選用 GCP Cloud Run，按需付費。
• 語言模型框架：LangChain + LangGraph，提升流程控制與可替換性。
• 向量資料庫：Pinecone，提供 SaaS 服務與可視化界面，可快速替換為 FAISS 等其他資料庫。
• 圖片與聊天記錄儲存：存於 Firestore，採 ** 對話過期機制**：若對話長時間無新訊息則過期，有新訊息則延長到期時間。