QA 系統的聊天回覆
本文整理 QA 系統中常見的聊天回覆方案，依「是否需要向量資料庫」與「QA 規模、彈性、成本」幫助選型。聚焦方案取捨與適用情境，不附實作程式碼。
ℹ️ 實作細節以官方為準
各家 LLM SDK 的套件名、client 寫法與 model id 變動快（套件會 deprecate、模型會退役）。本文只談方案層級的判斷，確切 API 與當前可用模型請在動手時查官方 SDK 文件與 deprecations 頁，不在筆記釘死版本。
方案總覽
| 方案 | 每次查詢成本 | 實作複雜度 | 回覆彈性 | 適合規模 |
|---|---|---|---|---|
| 直接塞 Prompt | 高 | 最低 | 高 | < 200 條 |
| 直接塞 + Cache | 中低 | 最低 | 高 | < 200 條 |
| 分類器 + 規則 | 最低 | 中 | 最低 | 類別固定 |
| Embedding 比對 | 最低 | 低 | 低 | 不限 |
| RAG | 低 | 中 | 高 | 不限 |
| Fine-tuning | 低 | 高 | 中 | QA 穩定不變 |
如何選擇
| 條件 | 建議方案 |
|---|---|
| QA < 200 條，快速上線 | 直接塞 Prompt |
| QA < 200 條，查詢頻繁 | 直接塞 + Cache |
| 問題類型固定且有限 | 分類器 + 規則 |
| 只需回傳固定答案，不需改寫 | Embedding 比對 |
| QA ≥ 200 條，需要語意理解 | RAG |
| QA 穩定不變，需統一風格 | Fine-tuning |
直接塞 Prompt
把所有 QA 問答對放進 system prompt，讓 LLM 直接比對回覆。
- 優點：幾乎不需基礎設施，最快上線。
- 缺點：受 context window 限制，QA 太多塞不下；每次都把全部 QA 送進去，token 費用高。
- 適合：QA 數量少（< 200 條）、快速 MVP。
直接塞 Prompt + Prompt Caching
與上面相同，但利用 API 的 Prompt Caching 機制降低成本：重複的 system prompt 會被快取，cached input 享有折扣，查詢越頻繁效益越高。各平台機制不同：
- OpenAI：自動快取，只要 system prompt 內容相同且長度達門檻（約 1024 tokens 起），不需改程式碼。
- Anthropic：需在請求中明確標記
cache_controlbreakpoint，指定哪些內容要快取。 - Gemini：分「顯式」與「隱式」兩種。顯式快取需先建立快取物件再綁定使用，且有逐模型的最低輸入 token 門檻（量級約數千 tokens，確切值依模型與時間變動），內容過小會直接建立失敗（回
Cached content is too small）；小量內容應改用隱式快取或直接塞 prompt。
重點：顯式快取是為「夠大的長文 context」設計的；幾條 QA 這種小量內容不適用。
分類器 + 規則回覆
用關鍵字規則把問題對應到類別，直接回傳預設答案，完全不經過 LLM。
- 優點：成本最低、速度最快、回覆完全可控。
- 缺點：無法處理未知問題、關鍵字維護成本高、彈性最差。
- 適合：問題類型固定且有限的場景。
Embedding 直接比對
用 embedding 計算使用者問題與各 QA 問題的相似度，直接回傳最相似的答案，完全不經過 LLM。通常會設一個相似度門檻（如餘弦相似度 0.7），低於門檻就回「找不到相關答案」。
- 優點：成本最低（只需 embedding 費用）、速度快。
- 缺點：無法整合多條 QA、答案不能改寫或補充。
- 適合：標準客服問答、FAQ 機器人。
RAG（檢索增強生成）
RAG（Retrieval-Augmented Generation）結合「資訊檢索」與「文字生成」：先從知識庫檢索相關文件，再把檢索結果作為上下文交給 LLM 生成回覆。
核心流程四步：
- 文件切割（Chunking）：把原始文件拆成適當大小的片段。
- 向量嵌入（Embedding）：用 embedding 模型把片段轉成向量，存入向量資料庫。
- 檢索（Retrieval）：依使用者問題，從向量庫找出最相關的片段。
- 增強生成（Augmented Generation）：把檢索到的片段與問題一起送進 LLM 生成回覆。
與純 LLM 回覆的差異
| 比較項目 | 純 LLM 回覆 | RAG 回覆 |
|---|---|---|
| 知識來源 | 模型訓練資料 | 即時檢索的外部文件 |
| 時效性 | 受限於訓練截止日期 | 可隨時更新知識庫 |
| 幻覺風險 | 較高，可能編造答案 | 較低，基於實際文件回覆 |
| 可追溯性 | 無法追溯來源 | 可標示引用來源 |
| 領域適用 | 通用知識 | 可針對特定領域客製化 |
文件切割策略
文件切割是 RAG 品質的關鍵。常見參數：
- Chunk Size：每個片段大小，通常 200–1000 tokens。
- Overlap：相鄰片段的重疊區域，通常為 chunk size 的 10%–20%。
策略選擇：
- 固定大小切割：簡單直接，適合結構統一的文件。
- 遞迴字元切割：按分隔符號層級切割，保留語意完整性。
- 語意切割：依語意相似度分段，品質最好但計算成本較高。
向量資料庫選型
| 資料庫 | 特點 | 適用場景 |
|---|---|---|
| Chroma | 輕量、易上手、支援本地部署 | 開發測試、小型專案 |
| Pinecone | 全託管、高效能、自動擴展 | 生產環境、大規模應用 |
| Qdrant | 開源、支援過濾、豐富的 API | 需要進階過濾的場景 |
| Weaviate | 開源、支援混合搜尋 | 需要關鍵字 + 語意混合搜尋 |
| pgvector | PostgreSQL 擴充、無需額外基礎設施 | 已使用 PostgreSQL 的專案 |
檢索策略
- 相似度搜尋：最基礎，計算查詢向量與文件向量的餘弦相似度來排序。
- 混合搜尋（Hybrid Search）：結合關鍵字搜尋（BM25）與語意搜尋（向量）。BM25 基於詞頻與文件長度，擅長精確匹配；語意搜尋擅長理解同義詞與上下文，兩者互補提升準確度。
提示詞設計
好的 system prompt 能引導 LLM 依檢索結果回覆、避免幻覺：
- 明確指示 LLM 僅根據提供的參考資料回答。
- 找不到相關資訊時，要求 LLM 誠實告知而非編造。
- 要求回答時標示引用來源，方便查閱原始文件。
回退策略
當檢索不到足夠相關的文件時，要有明確處理邏輯：
- 設定相似度門檻值（threshold），過濾低相關性結果。
- 沒有文件通過門檻時，回傳預設的「無法回答」訊息，而非讓 LLM 自行發揮。
- 建議使用者換關鍵字，或引導至人工客服。
多輪對話
多輪對話需維護歷史訊息以保持連貫：
- 視窗記憶體（Window Memory）：保留最近 N 輪對話作為上下文，避免歷史無限增長超出 token 限制。
- 查詢改寫（Query Rewriting）：把後續問題結合對話歷史改寫成完整的獨立問題再檢索。例如先問「RAG 是什麼？」再問「它的缺點呢？」，改寫成「RAG 的缺點是什麼？」，提升檢索準確度。
Fine-tuning
把 QA 資料微調進模型，推論時不需額外塞 context（訓練資料通常為 JSONL，每筆含問題與答案）。
- 優點：推論時 input tokens 最少、回覆風格一致。
- 缺點：訓練成本高、更新 QA 要重新訓練、幻覺難控制。
- 適合：QA 穩定不常變動、需要統一語氣風格的場景。