RAG 客服真正難的是把問題送對地方
看到 Devs Core 9 月 28 日整理的一個美國 D2C 客服案例，我更確定一件事：RAG 專案最難的部分，通常不是把文件塞進向量資料庫，而是判斷每個問題應該走哪條路。這個品牌每天有 2,000 到 3,000 張 tickets，25 到 30 位客服，團隊用 45 天、4 個人做出 42 個 n8n workflows，讓 AI 處理約 40%。
案例裡的路由其實是一個簡化的 mixture-of-experts：troubleshooting 問題走 RAG，簡單問題交 KB，無法可靠回答的才建立 Front ticket，並附上原始對話與分類。retrieval 沒有高信心結果時就交人，不讓模型猜。這是系統設計的一部分。若把所有問題都逼進生成流程，automation rate 可能更高，卻會用錯誤答案製造二次聯絡與信任成本。
我也很喜歡他們讓 GPT 和 Llama 分工。GPT 負責客戶看得到的自然語言，Llama 負責資料整理、分類，以及決定資料來源和 filters。這是把語言生成與結構化控制任務拆開。我會替每條路由留下可觀測欄位：分類 label、候選來源、retrieval score、拒答原因和最終人工結果。沒有這些 trace，團隊無法分辨是意圖辨識錯、filter 過窄，還是文件根本沒有答案。
上線後最值得學的發現，是原本從既有 tickets 推出的分類太窄。真實客戶不會按照資料科學家設計的 taxonomy 提問，錯分又會導致錯誤 retrieval，形成從 schema 到答案的連鎖故障。因此分類不是一次性的前處理，而是會隨新問法演化的產品介面。我會追蹤 macro F1、各意圖的 confusion matrix、retrieval recall@k、groundedness、人工轉接率，以及轉接後是否重開 ticket。拒答與自信錯答也要分開衡量。
客服 RAG 的核心不是選 GPT 還是 Llama，而是能否建立可調整的決策圖。分類路由決定資料邊界，信心門檻決定何時交給人，獨立維護的 workflow 讓團隊能快速修正，生產資料則持續反饋 taxonomy 與 retrieval。模型只是其中一個節點。若沒有這四層，即使 demo 流暢，也很難在每天數千張 tickets 的壓力下維持可靠性。
作者：陳思維