建構 RAG 系統的一些工程經驗

RAG（檢索增強生成）是目前 LLM 應用落地最主流的架構方案。這不是秘密，但真正動手做過的人才知道工程化的過程中有多少坑要踩。

這篇文章總結我最近一年做 RAG 專案的實戰經驗，不講理論，只講踩過的坑和解決方案。

RAG 不是什麼魔法

先說清楚 RAG 能做什麼、不能做什麼。

RAG 的核心思想很簡單：讓模型在回答之前先檢索相關的文檔，然後把文檔作為 context 給模型。 這樣模型不是在「憑空編造」，而是在「基於已知資訊回答」。

這解決了 LLM 幻覺的問題，但引入了新的問題：檢索的品質直接決定回答的品質。 如果檢索不到正確的內容，模型一樣回答不出來。

所以 RAG 系統有兩個核心環節：檢索（Retrieval）+ 生成（Generation）。 兩者都做好，系統才工作得好。

RAG 系統的第一步是文檔處理。這個環節有非常多的工程細節需要注意。

首先是切分策略。 你需要把長文檔切成小塊（chunk）才能索引。但怎麼切是個技術活。

最簡單的是固定長度切分——比如每 500 個 token 切一塊。這個方法快，但容易把語義相關的段落切成兩半，導致檢索不到相關內容。

好一點的是按語義切分——按照自然段落或者語義邊界切。但實現起來更複雜，需要額外的 NLP 能力。

我的經驗是：先按語義段落切，如果段落太長再按固定長度拆分。 這樣能保證每個 chunk 的語義完整性。

然後是元數據提取。 每個 chunk 除了內容本身，還需要存儲來源文檔標題、章節、頁碼等元數據。這些資訊在生成答案時可以幫助模型判斷內容的可信度。

最後是格式解析。 PDF、Word、網頁、飛書文檔——不同的文檔格式需要不同的解析方案。尤其是表格和圖片裡的文字，解析難度很高。

檢索是 RAG 系統裡被討論最多的環節，但也最容易過度工程化。

向量檢索 vs 關鍵詞檢索。 很多人一上來就用向量檢索（embedding similarity），但實際上 BM25 這種關鍵詞檢索在很多場景下效果更好，而且速度快得多。

我的建議是：先用關鍵詞檢索作為 baseline，效果不夠再疊加向量檢索。 兩者不是替代關係，是互補關係。

Embedding 模型的選擇。 中文場景下，bge 和 text2vec 都是不錯的選擇。關鍵是要選在跟你業務領域相關的語料上微調過的模型——通用的 embedding 模型在自己的垂直領域效果往往一般。

檢索到相關 chunk 之後，就到了生成環節。這個環節的坑主要在於 prompt 設計。

System Prompt 怎麼寫。 System Prompt 需要明確告訴模型：你是誰、你應該怎麼回答、你應該在什麼情況下說「不知道」。我見過太多 RAG 系統的 System Prompt 寫得很敷衍，導致模型要么亂編內容來源，要么回答跑偏。

RAG 是一個聽起來簡單，做起來複雜的系統。它的複雜度不在於某個單點技術，而在於整個鏈路上的工程細節——文檔解析、chunk 策略、檢索演算法、prompt 設計、評估體系，每個環節都有坑。

但正因為有這些坑，才是技術人的機會。如果你能在這些坑上積累足夠的經驗，這就是可以變現的專業能力。