RAG 架構如何應用在 LINE 問答機器人？

很多公司做 LINE Bot 的初衷，是想讓它自動回答客服問題。但做完之後發現：它只能回幾個寫死的關鍵字對應，稍微問歪一點就不知道怎麼回，或是給出通用到沒有意義的回答。

問題不是 LINE Bot 不夠強，而是傳統的 Bot 邏輯根本沒有「理解」的能力——它只是在做字串比對。

RAG 架構的出現，讓這件事有了不同的解法。

RAG 是什麼

RAG（Retrieval-Augmented Generation，檢索增強生成）是一種讓 AI 回答問題的架構。

簡單說，它的邏輯是：先找到相關的資料，再根據這些資料來生成回答。

一般的 LLM（大型語言模型）回答問題，靠的是訓練時學到的知識。問它你公司的產品規格，它不知道，因為那不是公開資料。但如果你把產品規格文件放進一個可以被檢索的知識庫，然後在每次提問前先找出相關段落、附給 AI 看，它就能根據那些資料給出準確的回答。

這就是 RAG 的核心概念。它不改變 LLM 本身，而是在提問的過程裡多了一個「先查資料」的步驟。

用一個公司 FAQ 機器人為例，完整流程大概是：

整個流程，對使用者來說就是傳了一個問題、收到了一個答案，跟一般的 Bot 體驗沒什麼差別。但答案的品質完全不同——它是真的從你的資料裡找出來的，不是憑空捏造的。

這是 RAG 裡比較陌生的一塊，值得多說一點。

傳統的關鍵字搜尋是字面比對：問「保固」，就找含有「保固」這個詞的文件。但語言的意思不只在字面上——「維修期限」、「售後服務年限」說的可能是同一件事，關鍵字搜尋找不到這種語意上的關聯。

向量搜尋的做法是：把每段文件用 Embedding 模型轉換成一個數字向量，這個向量代表了這段文字的語意。當使用者提問，問題也被轉成向量，然後找出在語意空間裡最接近的文件段落。「保固多久」和「維修期限是幾年」的向量會很接近，所以可以找到同樣的答案。

常見的向量資料庫有 Pinecone、Qdrant、Weaviate，或用 PostgreSQL 加 pgvector 擴充也可以處理。

知識庫的建立：把你的文件（FAQ、產品手冊、規章、常見問答）切分成適當大小的段落，逐一轉換成向量存進資料庫。這個過程叫 Indexing，是一次性的前置作業，之後資料更新時再同步就好。

Embedding 模型：把文字轉成向量用的模型。可以用 OpenAI 的 Embedding API，或者選擇開源模型自行部署。同一份資料的 Indexing 和查詢時的 Embedding，必須用同一個模型，不然向量比不起來。

LLM 選擇：最終生成回答的部分。用 GPT-4、Claude，或是成本考量下選較小的模型都可以。

Prompt 設計：怎麼把檢索到的段落和使用者問題組合成給 LLM 的指令，很影響回答品質。「根據以下資料回答，如果資料裡沒有相關內容，請如實說明，不要自行推測」這類的指示能有效降低 AI 亂回答的情況。

公司內部知識問答：員工用 LINE 問 HR 規章、IT 支援流程，不用翻文件，直接問 Bot。

產品售後客服：使用者問安裝步驟、常見問題，Bot 從產品手冊裡找答案。

法規 / 合約查詢：把合約條款、法規文件放進知識庫，用自然語言問問題，比搜尋關鍵字直覺得多。

活動 FAQ：大型活動期間，把所有 Q&A 放進 RAG，讓 Bot 自動應答重複性問題，減輕客服壓力。

RAG 不是萬能的——知識庫的品質決定回答的品質，文件寫得不清楚，AI 再強也回答不好。但對「想讓 LINE Bot 真的能回答業務問題」這個需求來說，RAG 是目前最務實的做法。它讓 AI 說的話有來源、有根據，而不是在胡謅。