2026 年 2 月RAG

設計可上正式環境的 RAG 系統

檢索增強生成（RAG）已成為讓大型語言模型以自有資料為依據的預設做法。Demo 很容易，正式系統不容易。差距在架構——你怎麼取入、檢索、排序與評估。

1. 取入與切塊

檢索品質在任何查詢執行前就決定了。忠實解析文件（表格、標題、程式碼），然後依語意邊界切塊，而不是固定字元數。附上豐富的中繼資料——來源、章節、時間戳、權限——才能篩選與引用。內容變動時做增量重建索引。

選擇符合你領域與語言的嵌入模型，索引兩端使用同一個模型。向量資料庫是營運系統，不是玩具：為篩選檢索、中繼資料索引、分片與更新成本做規劃。把原文與向量一起儲存，生成階段才有乾淨、可引用的上下文。

純向量檢索會漏掉精確詞彙；純關鍵字檢索會漏掉語意。兩者結合（dense + BM25）並融合結果，再用 cross-encoder 對前幾名候選重排序，把真正相關的段落推到最上面。寬鬆檢索、積極重排，只把精簡、高訊號的上下文交給模型。

指示模型只根據檢索到的上下文回答、引用來源，並在上下文不足時回答「我不知道」。把引用回傳到 UI 讓使用者驗證。這是把「聽起來合理的聊天機器人」變成「值得信賴的助理」的關鍵。

無法衡量就無法改進。在固定測試集上追蹤檢索指標（recall、precision）與回答指標（faithfulness、relevance），每次變更都重跑。記錄查詢、檢索到的區塊與回饋，建立飛輪。把延遲與每次查詢的成本當成一級 SLO 監控。

做得好的 RAG，重點不在模型，而在它周圍的檢索管線。把取入、混合檢索、重排序與評估做對，模型幾乎會自己照顧好自己。