最近聊 RAG 的朋友特別多從剛接觸大模型的初學者到已經在做企業(yè)知識庫落地的工程師都在問同一個問題RAG 到底怎么搭、怎么做才能真的解決問題。我最早接觸 RAG 是在給內部團隊做文檔問答的時候當時的痛點是模型再強也記不住我們自己的業(yè)務文檔微調成本又太高RAG 幾乎是唯一的合理選擇。陸陸續(xù)續(xù)做了幾個項目之后我發(fā)現自己踩過的坑、調過的參數、換過的方案其實是可以沉淀成一套有章可循的方法的。這篇文章就是把我從零開始搭建 RAG 的過程梳理出來的完整記錄包括核心鏈路、文本拆解、向量化、檢索優(yōu)化、工具選型以及那些最容易讓人抓狂的細節(jié)問題。如果你正準備做一個知識庫問答、文檔助手或者只是想把 RAG 跑通并搞清楚它的邊界這篇文章應該能幫你省下不少摸索的時間。1. RAG 到底是什么先搞清楚它解決了什么問題1.1 大模型不是搜索引擎它只“記得”訓練時見過的內容很多人第一次接觸 RAG 時的第一反應是大模型不是什么都知道嗎為什么還要外掛一個知識庫這個理解偏差是后面所有困惑的根源。大模型在你提問時給出的答案本質上是對訓練語料里學到的統計規(guī)律做逐詞生成它沒有能力去“查”任何實時資料。你問它今年發(fā)布的新產品規(guī)格它回答不出來不是它笨而是那些信息根本不在它的訓練數據里。它也沒有辦法區(qū)分哪些信息是真實的、哪些是編造的因為它只是在做概率上的續(xù)寫。所以當你要讓模型回答“我們公司內部規(guī)章里遲到怎么定義”這種問題時如果你只把問題丟給模型它只會給你一段聽起來合理但完全不可信的答案。RAG 做的事情就是改變這個局面在你的問題進入模型之前先從一個外部知識庫里檢索出相關的內容片段把這些片段作為背景材料拼進提示詞里再讓模型基于這些材料生成答案。這樣一來模型回答的內容就不再依賴它“記得什么”而是依賴你的知識庫里“有什么”準確性、時效性、可追溯性都發(fā)生了本質變化。用一句話概括RAG 是把“生成”和“檢索”組合起來的問答架構外部知識庫負責找材料大模型負責寫答案。它最典型的應用場景就是企業(yè)內部知識問答、產品文檔助手、合規(guī)審查輔助、客服工單處理這類“答案必須出自指定資料”的任務。適合的人群也很寬——在校學生、后端工程師、算法工程師、產品經理都可以通過它快速做出一個可用的問答系統而且不需要從頭訓練任何模型。1.2 RAG 的核心鏈路從文檔到知識的五步流程RAG 的完整鏈路可以拆成兩個階段。第一個階段是知識庫構建也就是“離線處理”把原始文檔變成可以被檢索的形式。第二個階段是在線問答用戶提問后實時檢索并生成回答。離線構建階段通常分五步文檔加載、文本拆解、向量化、建索引、存儲。文檔加載是指把 PDF、Word、Markdown、網頁等不同格式的內容讀成純文本文本拆解是把長文檔切成適合檢索的小段也就是業(yè)內常說的 chunk向量化是調用 embedding 模型把每個文本段轉換成一串浮點數向量讓語義相近的文本在向量空間里距離更近建索引和存儲則是把這些向量連同原文一起寫入向量數據庫方便后續(xù)快速查找。在線問答階段也有固定流程把用戶問題同樣轉成向量到向量數據庫里做相似度檢索取回最相關的一批文本段再把這些文本段和原始問題一起組裝成提示詞交給大模型生成最終答案。我第一次看這個流程時覺得不復雜但真正動手做才發(fā)現每一步都有不少隱藏的變量。文本拆成多長合適向量模型選哪個檢索結果怎么排序這些問題如果只是默認參數跑通一遍出來的效果往往很一般。后文我會逐個環(huán)節(jié)展開講具體怎么調。1.3 什么時候該用 RAG什么時候不該用RAG 不是萬能方案它也有自己的適用邊界。首先需要明確一點如果你的問題都能被模型自身知識準確回答且不需要引用任何外部資料那就不需要 RAG。比如“Python 列表怎么去重”這種基礎問題直接問模型就夠了加一套檢索鏈路反而增加了延遲和復雜度。RAG 真正發(fā)揮價值的地方有三個特征一是答案必須來自特定資料比如公司內部制度、產品技術文檔二是資料內容會持續(xù)更新比如每周發(fā)布的新版本說明不可能每次更新都重新微調模型三是需要答案可溯源用戶抽查時能知道回答來自哪一份文檔的哪一段。反過來如果這些問題涉及大量跨文檔推理、需要多步邏輯鏈或者問題本身就是開放的、沒有確定答案純粹的 RAG 就會比較吃力這類任務通常要引入智能體或多跳檢索機制而不是簡單的一次檢索一次生成。明白邊界之后再接具體項目就不會亂。下面我從知識庫構建開始帶你走一遍完整的實操步驟。2. 從零搭一個 RAG 知識庫文本拆解和向量化2.1 文檔接入前的第一步格式歸一化與文本抽取很多人拿到一批 PDF 就直接開始做切分這是第一個坑。PDF 里的內容并不都是“文本”大量商業(yè)文檔里含掃描圖片、復雜表格、頁眉頁腳直接抽取出來的文本經常是亂序或者缺失的。我處理過一份內部制度文件PDF 里正文分成了兩欄默認抽取工具把左右兩欄交叉讀出來句子完全錯亂檢索結果自然慘不忍睹。所以文檔接入的第一步不是切分而是格式歸一化。把所有源文件統一轉成干凈、規(guī)范的純文本或者結構化 Markdown再進入后續(xù)流程。對 Word、Markdown、HTML 這類本身就帶文本層的內容標準做法是優(yōu)先保留原有結構——標題、列表、表格里的內容按層級提取。對 PDF處理方案取決于文件質量如果是數字生成的 PDF直接用 pdfplumber 或者 PyMuPDF 提取文本保留基礎版式如果是掃描件則需要先做 OCR這一步可以調用本地 Tesseract也可以接 PaddleOCR 這類效果更好的引擎。這里要重點說一個工具Unstructured。它是一個專門做文檔解析的開源庫能把 PDF、Word、PPT、HTML 等格式解析成帶元數據的元素列表比如每個元素是標題、正文、表格還是圖片。我在 Mac 上做本地解析時常用它配一個簡單的 Python 腳本就能把整批文檔抽出干凈文本。如果你處理的是學術論文或者產品手冊還可以試試 Marker它能把 PDF 直接轉成帶層級結構的 Markdown對雙欄和表格支持比普通 PDF 抽取庫好很多。文本抽取這個環(huán)節(jié)多花二十分鐘后面檢索效果能提升一個檔次這是性價比最高的前期投入。2.2 文本拆解的“體感調參”chunk size 與 overlap文本拆解是 RAG 項目里讓人又愛又恨的環(huán)節(jié)。切得太短語義碎片化一個問題可能被拆散到好幾塊里檢索時哪一塊里都找不到完整信息切得太長噪聲太多向量化后語義被稀釋檢索出來的內容里真正有用的可能只有一兩句話大模型還要從一大段廢話里挑答案準確率同樣下降。我常用的起點參數是 chunk size 在 256 到 512 token 之間overlap 按 chunk size 的 10% 到 20% 設置。以 512 token 的 chunk、64 token 的 overlap 為例相鄰兩個文本塊之間會共享一部分內容這樣即使一個關鍵句恰好落在前一個塊的末尾也能在后一個塊的開頭再出現一次避免漏檢。這個參數組合對絕大多數中文文檔都算穩(wěn)妥但實際效果仍然要按內容類型做調整。2.3 向量化與 embedding 模型選型文本切好之后下一步是把每一塊轉成向量。embedding 模型的選擇直接決定了檢索的召回質量這是 RAG 項目里最不該隨便應付的環(huán)節(jié)。開箱即用的方案是調用 OpenAI 的 text-embedding-3-small 這類在線接口質量穩(wěn)定、接入快缺點是每一篇文檔都要上傳到外部服務對數據敏感的內網項目不適用。本地部署的方案里我測試過 BGE 系列模型表現很好尤其是 BGE-M3在中文語義理解上比很多同體量英文模型強很多同時支持稠密檢索和稀疏檢索兩種模式后面做混合檢索時可以共用一套向量。如果你的環(huán)境跑不了大模型也可以用更輕量的 text2vec 或者 m3e 系列效果略遜一籌但速度更快。最近 Ollama 也支持了 nomic-embed-text 和 bge-m3一條命令就能在本地起一個 embedding 服務對做實驗和搭建個人知識庫來說性價比很高。選模型的時候有一個容易忽略的細節(jié)檢索用的 embedding 模型和生成回答的大模型不需要來自同一家公司也不需要綁定運行。常有人覺得“我用 Llama 本地部署那 embedding 也必須用 Llama 系列”其實沒有這個限制embedding 和生成兩套模型是獨立的可以分開選型。只要保證一個關鍵前提所有文檔切片和用戶查詢都要用同一個 embedding 模型不能用兩個不同的模型分別向量化否則向量空間不一致相似度計算就沒有意義了。3. 知識庫到底能不能存圖片多模態(tài) RAG 的邊界3.1 為什么圖片經?！斑M不了”知識庫“RAG 知識庫能存圖片嗎”是搜索熱度很高的問題也是很多初學者繞不過去的困惑。直接回答純文本 RAG 的向量庫不能直接理解圖片內容。原因在于最主流的 embedding 模型處理的是文本圖片直接送進去沒有任何意義。很多人在本地搭建知識庫時發(fā)現傳了幾張截圖進去檢索的時候卻完全檢索不到就是因為沒有對圖片做任何處理圖片壓根沒有變成可檢索的文本。這并不意味著知識庫完全和圖片絕緣。如果你用的向量數據庫本身支持多模態(tài)向量比如 Milvus 這類專業(yè)向量庫接入了 CLIP 或 ImageBind 模型確實可以把圖片編碼成向量做圖搜圖。但這屬于多模態(tài)檢索的范疇實現成本和工程復雜度比普通文本 RAG 高不少初學者通常不需要一上來就走這條路。3.2 實際可行的做法圖片轉描述再入庫對絕大多數知識庫場景最穩(wěn)妥的做法不是把圖片直接入庫而是把圖片“翻譯”成文本描述之后再把文本放進知識庫。具體流程是用大模型或者專門的圖像理解模型給每一張圖片生成一段文字說明比如“圖中展示的是系統登錄界面左上角為用戶名輸入框右側為驗證碼區(qū)域”然后把這段描述和圖片在文檔中的上下文一起拼成文本塊入庫。用戶提問時檢索發(fā)生在文字描述層模型讀到的是“圖片內容的文字版”照樣能給出有用回答。我實際處理過一個產品說明書項目文檔里有大量界面截圖和流程圖最初直接用 PDF 抽取圖片內容全部丟失導致很多問題回答不了。后來我把 PDF 先轉成 Markdown再用多模態(tài)模型對圖片逐張生成描述插入到對應章節(jié)的位置整個知識庫的召回率明顯提升。這個流程現在有標準化的開源工具可以做比如一些文檔解析庫已經內置了“OCR 圖像理解 文本化”的流水線無需自己組裝。3.3 表格、PDF 掃描件這類“偽圖片”怎么處理有些內容看起來不是圖片但處理方式卻和圖片類似。表格就是最常見的例子原生從 PDF 抽取出來的表格經常是一堆散落的字符行列關系全丟掃描版的合同、發(fā)票就更不用提本質上就是圖片。這些內容如果直接丟進文本 RAG檢索到之后回答質量大概率是不合格的。表格類內容的推薦做法是轉成 Markdown 表格或者 JSON 結構化之后當作一個整體 chunk 存入知識庫。大模型對 Markdown 表格格式的識別能力很強只要文本塊里保留了完整結構它在生成答案時就能正確理解“第一列是配置項第二列是默認值”這類關系。掃描件則必須走 OCR這一步做完之后還要做版式還原盡量把識別出來的文本按原始閱讀順序重新拼接。我見過不少項目卡在“掃描件檢索到了但答案不對”這個問題上排查下來都是 OCR 文本順序出了問題排版亂掉的文本塊比檢索不到更誤導模型。4. 檢索鏈路才是 RAG 的靈魂檢索增強不只是搜一下4.1 相似度檢索的局限關鍵詞與語義之間的平衡很多初學者以為 RAG 的檢索就是用向量數據庫查一下相似度跑通之后發(fā)現效果時好時壞。原因在于純向量檢索對長尾關鍵詞、編號、產品型號這類精確信息并不敏感。比如用戶問“CH-3200 的額定功率是多少”向量模型可能把這串型號理解成“某個設備型號”但“CH-3200”這個精確匹配信號在向量檢索里并不占優(yōu)勢最相關的文檔反而排不到前面。解決這個問題需要意識到RAG 的檢索本質上應該分兩路走一路做語義召回靠向量相似度找到意思相近的內容另一路做關鍵詞召回靠 BM25 這類經典算法做精確匹配。然后把兩路結果做合并和重排術語叫“混合檢索”Hybrid Search。我用過的方案里向量庫用 Milvus 或者 Qdrant關鍵詞檢索可以直接用 Elasticsearch也可以用一個更輕量的 MeiliSearch 或者 SQLite FTS5按數據量級來選。合并策略上常用的是用倒數排名融合RRF算法把兩份結果按排名做加權合并保證兩路召回的內容都有機會進到最終候選集。4.2 重排序讓最相關的答案排到最前面混合檢索拿到一批候選文檔之后另一個關鍵步驟是重排序。向量相似度衡量的是“整段文本語義上有多接近”但語義接近不等于“問題中的核心信息在答案里都有”。做重排序最有效的方法是引入一個專門的重排模型reranker它會把問題和候選文檔逐條拼接起來計算相關性得分這種交互式打分比純向量距離更精準。開源方案里我會優(yōu)先推薦 BGE-Reranker它的模型設計就是針對中文問答場景做的重排效果和推理速度平衡得不錯。實測下來一個嵌入模型召回后有 30 條候選的查詢用重排模型重新排一遍之后Top 1 結果往往和實際需要的答案高度相關對比不重排的情況提升顯著。需要注意重排模型也是本地部署時的主要算力消耗點之一對性能要求高的線上場景一些團隊甚至會專門做緩存和并發(fā)優(yōu)化。但哪怕只是做一個小工具我認為重排這一步也不該省它是性價比非常高的精度提升手段。4.3 知識圖譜 RAG 和 RAG 智能體的差異“知識圖譜 RAG”和“RAG 智能體”是最近熱度很高的兩個詞初學者容易混為一談。簡單來說知識圖譜 RAG 是在傳統 RAG 基礎上額外引入了一層的結構化知識文檔切塊和向量化照舊做但你同時把文檔里的實體、關系抽取出來建成圖譜結構比如“張三”是“市場部”的“員工”“市場部”的“負責人”是“李四”。圖譜可以回答那些依賴多級關聯的問題比如“張三的部門負責人是誰”普通 RAG 需要從多篇文檔里拼湊推理知識圖譜可以直接走關系路徑。這類方案搭建成本高因為實體識別、關系抽取都要精確處理但對特定領域比如醫(yī)療、法律的關聯問答場景收益明顯。RAG 智能體則是把 RAG 從“查一次、答一次”升級成“可以多輪決策”的形態(tài)。智能體收到問題后先判斷要不要檢索再決定檢索哪幾個知識庫對結果不滿意就改關鍵詞再檢索一次甚至同時調用另外一個 API 獲取結構化數據最后把多來源信息組裝成答案。它的核心特征是擁有循環(huán)和工具調用能力適合復雜查詢。但代價是可控性下降出問題的時候排查鏈路變長。對初學者我的建議是先扎實掌握普通 RAG 和混合檢索再研究知識圖譜和智能體否則很容易陷入“什么都要接智能體但什么問題都回答不準”的泥潭。5. 本地搭建 RAG 的常見路徑與工具選型5.1 在自己電腦上搭建 RAG 的配置思路以 Mac 為例“怎么在 Mac 上搭建 RAG 知識庫”是搜索量很高的問題確實很多剛接觸大模型應用的朋友手上只有一臺 Mac不想上來就買服務器。以一臺 Apple Silicon 芯片的 Mac 為例完全可以在本地跑起一套完整的 RAG 鏈路Ollama 負責本地大模型和 embeddingChroma 做向量庫再加一個小型 Python 腳本做文檔處理全部內網運行數據不出本機。具體流程我建議按這樣走第一步安裝 Ollama拉取一個大語言模型起步可以用 qwen2.5:7b 這類中文表現不錯的 7B 模型再拉一個 bge-m3 作為 embedding 模型第二步用 Python 寫一個簡單的文檔加載腳本把 Markdown、TXT 這些文本類型直接讀入PDF 用 Unstructured 解析第三步把文本塊交給 embedding 模型轉成向量寫入 Chroma 持久化目錄第四步寫一個查詢函數用戶輸入問題后先向量化再從 Chroma 取出相似度最高的幾個文本塊連同問題一起拼進提示詞交給 Ollama 生成回答。整個過程不依賴任何外部云服務一臺 16G 內存的 Mac 跑 7B 模型雖然速度不算快但做學習驗證和個人知識庫完全夠用。如果你不想寫代碼也可以直接用現成的開源應用。RAGFlow 是我實測下來對新手比較友好的一套系統它自帶文檔解析、知識庫管理、問答界面部署后就能用對中文文檔支持也很好。LangChain 和 LlamaIndex 則更適合想深入理解原理、通過代碼自由控制流程的人兩者定位略有差異LangChain 的組件生態(tài)更豐富適合構建復雜鏈路LlamaIndex 主打文檔索引和檢索對 RAG 場景更聚焦。5.2 常見開源 RAG 框架怎么選框架選型是大家問得最多的問題之一我把幾種典型方案的定位和適用場景整理成了表格方便對比。方案核心定位上手難度適合場景自研腳本Ollama Chroma最小可用鏈路低學習原理、快速驗證LangChain / LlamaIndex開發(fā)框架中定制化程度高、需要代碼控制RAGFlow開箱即用系統低快速搭建知識庫應用中文友好Dify低代碼平臺低面向業(yè)務配置、可視化流程編排企業(yè)級生產方案Milvus Elasticsearch 等生產級鏈路高高并發(fā)、大規(guī)模文檔、需要精細化治理初學者選擇時不要一上來就上最重的框架。我見過不少朋友第一天就在折騰生產級集群最后光部署就卡了一周核心鏈路反而沒跑通。建議先用手寫腳本跑通最小鏈路切身理解每一環(huán)的功能之后再挑選框架去簡化開發(fā)。紙上談兵沒有意義跑通一次你對 RAG 的體感會完全不同。5.3 從“demo”到“可用”要跨過的幾道坎把 RAG 從演示跑通變成能穩(wěn)定使用中間有幾道坎幾乎人人都會遇到。第一道坎是文檔更新機制。很多人做了知識庫之后就忘記更新文檔內容已經變了檢索出來的還是舊信息。這個問題不解決知識庫很快失去價值。第二道坎是檢索質量評估。跑一次效果好不好是主觀感受但上線前需要建立客觀評估基準準備一批有確定答案的測試問題統計檢索結果里包含正確答案的比例用這個指標來驅動參數調優(yōu)。第三道坎是提示詞穩(wěn)定性。同樣的檢索結果提示詞寫法不同回答質量可能差異巨大需要反復調試才能穩(wěn)定輸出。這三道坎不是一次性工程而是持續(xù)迭代的過程。我在做完第一個可用版本后花了將近一半的時間在整理測試集和調提示詞上這個投入非常值得。后面常見問題部分我會再展開講幾個高頻故障的排查思路。6. 常見問題與排查技巧實錄6.1 檢索結果差是模型的問題還是檢索的問題這是排查 RAG 問題時的第一個分岔路。一個常見的錯誤是回答質量差就先怪大模型但很多時候問題出在檢索環(huán)節(jié)知識庫里根本沒有相關內容或者相關內容沒有被正確召回。排查方法很簡單先在系統里把檢索到的文本塊原樣打印出來人工判斷這些文本塊是否真的能回答問題。如果檢索結果本身就對不上說明問題在文檔處理、切分、向量模型或檢索策略換再大的生成模型也沒用如果檢索結果是對的但模型回答得不好那才需要優(yōu)化提示詞或者換一個更強的生成模型。我經常用一個比喻RAG 系統的效果上限由檢索決定下限由生成決定。檢索不到關鍵信息再強的模型也巧婦難為無米之炊檢索到了關鍵信息至少模型不會胡編太離譜。所以排查問題永遠先查檢索再查生成。6.2 知識庫更新了為什么回答還是舊內容這個問題的根因幾乎都是緩存和索引不同步。向量數據庫里的數據是構建索引時刻的快照如果新增或者修改了文檔但沒有重新執(zhí)行向量化和寫入流程檢索結果自然不包含新內容。解決思路是建立清晰的更新策略全量重建用在小規(guī)模知識庫上最簡單可靠每次變更后直接清空舊索引、重新入庫增量更新用在內容經常變動的場景需要根據文檔的唯一標識判斷新增、修改、刪除再對應地做向量寫入和刪除。增量更新實現起來比全量重建復雜得多如果文檔總量不大系統設計時我傾向于先用全量重建每天定時跑一次成本不高邏輯還不會出錯。等到文檔量級上來之后再遷移到增量策略。6.3 RAG 的瓶頸與它不適用的場景明確說出瓶頸在哪里也很重要。當前 RAG 最主要的瓶頸有三個一是長文檔多跳問題的推理能力弱當答案需要跨多個文檔片段組合推理時單次檢索往往漏掉必要信息二是知識沖突處理難同一問題在知識庫不同位置有矛盾表述時模型很難判斷以哪個為準三是評估困難沒有標準化的評測集和統一指標很難準確判斷系統的真實水平。不適合的場景同樣需要警惕回答開放性的主觀題、需要最新實時信息的強時效任務、以及需要深度邏輯推理的復雜分析這些場景里 RAG 的表現都會打折扣需要配合其他架構解決。說到底RAG 是一個需要持續(xù)調優(yōu)的系統工程不是跑通 Demo 就結束的事情。根據我個人在這些項目里的體會投入產出比最高的三件事分別是前期的文檔解析質量、檢索階段的重排序、以及一套能重復使用的評測問題集。把這三件事做好你的 RAG 項目就已經超過了大多數停留在平均水平的實現剩下的就是在具體數據上持續(xù)迭代了。