1. 為什么知識獲取管道是 AI Agent 落地的第一道生死線做 AI Agent 的人十有八九會把注意力先放在Agent 怎么規(guī)劃任務(wù)怎么調(diào)用工具怎么多輪對話上但真正把項目推到生產(chǎn)環(huán)境之后你會發(fā)現(xiàn)一個很扎心的事實Agent 的智能上限往往不是被模型能力卡住的而是被它拿到的知識卡住的。模型再強如果檢索回來的上下文是錯的、過時的、殘缺的它輸出的東西就是一本正經(jīng)地胡說八道。這就是為什么我把知識獲取管道放在整個 Agent 體系里優(yōu)先級最高的位置——它是 Agent 的眼睛和耳朵眼睛瞎了腦子再好也沒用。這一篇是走進 AI Agent系列的第四篇前面我們聊了 Agent 的基本架構(gòu)、工具調(diào)用、記憶機制現(xiàn)在正式進入 RAGRetrieval-Augmented Generation檢索增強生成這個繞不開的核心話題。我盡量不寫成教科書而是把我自己在搭知識管道時踩過的坑、做過的取舍、以及那些文檔里不會寫的經(jīng)驗原原本本講清楚。不管你是剛接觸 RAG 的新手還是已經(jīng)用 LangChain、Spring AI、LangChain4j 搭過 demo 的老手這篇都能幫你把知識獲取管道這件事從能跑推進到能扛。先說清楚 RAG 到底解決什么問題。大模型的知識有兩個硬傷一是時效性訓(xùn)練數(shù)據(jù)有截止日期昨天剛發(fā)的文檔它不知道二是私域性你公司內(nèi)部的 ERP 數(shù)據(jù)、產(chǎn)品手冊、客服話術(shù)模型訓(xùn)練時根本沒見過。RAG 的思路很樸素——既然模型不知道那就在它回答問題之前先把相關(guān)資料檢索出來塞進上下文讓它開卷考試。聽起來簡單但檢索什么怎么檢索檢索多少怎么塞這四個問題每一個都能讓項目翻車。我見過太多團隊RAG 的 demo 半天就跑通了然后興沖沖上線結(jié)果用戶一問稍微繞一點的問題就答非所問。問題幾乎都出在知識獲取管道上文檔切分切碎了語義、嵌入模型選錯了語言、檢索只做了向量召回漏掉了關(guān)鍵詞、召回的內(nèi)容沒做重排直接喂給模型。這些環(huán)節(jié)環(huán)環(huán)相扣任何一環(huán)掉鏈子最終體驗都會崩。所以這一篇我會把管道拆成文檔處理—嵌入表示—檢索召回—重排增強四段逐段講透。提示RAG 不是向量數(shù)據(jù)庫 大模型這么簡單。把它理解成一條流水線每個工位的良品率都會影響最終產(chǎn)出而流水線的瓶頸往往在最不起眼的那一環(huán)。2. 文檔處理切分策略決定了檢索質(zhì)量的天花板2.1 為什么切分是 RAG 里最容易被低估的環(huán)節(jié)很多人拿到 RAG 項目第一反應(yīng)是去挑向量數(shù)據(jù)庫、去比嵌入模型卻把文檔切分當(dāng)成一個隨便切切就行的預(yù)處理步驟。我的經(jīng)驗恰恰相反切分策略決定了檢索質(zhì)量的天花板后面所有環(huán)節(jié)再優(yōu)化也突破不了這個天花板。原因很簡單檢索的最小單位是塊chunk如果一塊內(nèi)容本身語義不完整那無論你的嵌入模型多強、重排多精細召回來的都是一堆殘缺信息。舉個我實際遇到的例子。有個做產(chǎn)品檢索的項目文檔是產(chǎn)品說明書最初用固定長度 500 字符切分結(jié)果產(chǎn)品 A 的保修期是 3 年這句話被從中間切斷前半句在上一塊后半句在下一塊。用戶問產(chǎn)品 A 保修多久檢索召回了前半句產(chǎn)品 A 的保修期是模型只能瞎猜。后來改成按語義段落切分問題立刻消失。這就是切分的威力——它不改變模型能力但直接決定了模型能不能拿到完整信息。切分策略大致分三檔我按適用場景排一下切分策略適用場景優(yōu)點缺點固定長度切分結(jié)構(gòu)松散的純文本、日志實現(xiàn)簡單、塊大小可控容易切斷語義遞歸字符切分通用文檔、Markdown兼顧結(jié)構(gòu)與長度需要調(diào)分隔符優(yōu)先級語義/結(jié)構(gòu)切分說明書、合同、代碼語義完整度高實現(xiàn)復(fù)雜、依賴解析我個人的默認選擇是遞歸字符切分配合合理的分隔符優(yōu)先級段落 換行 句號 逗號再疊加一個重疊窗口overlap。重疊窗口這個參數(shù)特別關(guān)鍵它讓相鄰塊之間有一段共享內(nèi)容避免關(guān)鍵信息正好落在邊界上被割裂。我一般設(shè) overlap 為塊大小的 10%~20%比如塊 500 字符overlap 設(shè) 50~100 字符。2.2 元數(shù)據(jù)讓檢索從能搜到進化到搜得準光有文本塊還不夠每個塊都必須帶上元數(shù)據(jù)這是很多人忽略的一步。元數(shù)據(jù)包括來源文檔、章節(jié)標題、頁碼、更新時間、文檔類型等等。為什么重要因為檢索時你可以用元數(shù)據(jù)做過濾。比如用戶問2025 年最新的報銷政策你可以先用元數(shù)據(jù)過濾出更新時間在 2025 年的文檔再在里面做語義檢索命中率會高一大截。我在一個企業(yè)知識庫項目里就吃過虧。最初所有文檔混在一起檢索用戶問研發(fā)部的考勤規(guī)則結(jié)果召回了行政部的考勤規(guī)則因為兩段文本語義太像了。后來給每個塊打上部門標簽檢索時先按部門過濾準確率直接從 60% 多提到 90% 以上。元數(shù)據(jù)不是錦上添花它是結(jié)構(gòu)化過濾的抓手尤其在文檔量大、領(lǐng)域交叉的場景下沒有元數(shù)據(jù)的 RAG 基本沒法用。元數(shù)據(jù)的設(shè)計我建議至少包含這幾項source來源文件、section所屬章節(jié)、updated_at更新時間、doc_type文檔類型、tags業(yè)務(wù)標簽。這些字段在入庫時就要一起寫進向量庫檢索時作為 filter 條件傳入。別等到出問題了才回頭補那時候重新處理全量文檔的成本高得嚇人。2.3 文檔解析的坑PDF、表格、掃描件怎么處理真實項目里的文檔格式五花八門PDF、Word、Excel、PPT、網(wǎng)頁、掃描件都有。PDF 是重災(zāi)區(qū)尤其是那種雙欄排版、帶表格、帶公式的 PDF直接抽取文本經(jīng)常亂序。我處理 PDF 一般分兩步先用解析庫抽取文本和版面信息再根據(jù)版面信息重建閱讀順序。如果 PDF 是掃描件還得先做 OCROCR 的準確率又直接影響后續(xù)所有環(huán)節(jié)。表格的處理更麻煩。表格里的信息是二維的直接轉(zhuǎn)成文本會丟失行列關(guān)系。我的做法是把表格轉(zhuǎn)成 Markdown 或 HTML 格式保留結(jié)構(gòu)或者把每一行轉(zhuǎn)成列名: 值的鍵值對形式。比如一張產(chǎn)品價格表轉(zhuǎn)成產(chǎn)品: A, 價格: 100, 庫存: 50這樣的文本塊檢索和生成都會更準確。這個轉(zhuǎn)換過程看起來笨但實測效果比直接塞原始表格好太多。注意文檔解析的質(zhì)量是隱形的它不會報錯但會悄悄拉低整個管道的效果。上線前一定要抽樣人工檢查解析結(jié)果尤其是表格和特殊排版。3. 嵌入表示稠密與稀疏不是二選一而是組合拳3.1 稠密嵌入和稀疏嵌入到底差在哪嵌入Embedding是把文本轉(zhuǎn)成向量的過程向量之間的距離代表語義相似度。這里有個關(guān)鍵分叉稠密嵌入Dense Embedding和稀疏嵌入Sparse Embedding兩者原理和適用場景完全不同很多人只知道稠密結(jié)果在關(guān)鍵詞敏感的場景下翻車。稠密嵌入用神經(jīng)網(wǎng)絡(luò)把文本壓成一個幾百到幾千維的稠密向量每一維都有值代表某種抽象語義特征。它的強項是語義匹配——用戶問怎么退款文檔里寫如何申請退貨字面不一樣但語義相近稠密嵌入能匹配上。缺點是它對精確關(guān)鍵詞不敏感比如產(chǎn)品型號XZ-2000這種稠密嵌入可能把它和XZ-3000混為一談。稀疏嵌入典型代表是 BM25、SPLADE 這類則是高維稀疏向量大部分維度是 0只有出現(xiàn)過的詞對應(yīng)的維度有值。它的強項是關(guān)鍵詞精確匹配用戶搜XZ-2000它就能精準命中包含這個詞的文檔。缺點是不懂語義退款和退貨在它眼里是兩個無關(guān)的詞。我把兩者的差異整理成表方便對照維度稠密嵌入稀疏嵌入向量形態(tài)低維稠密如 768/1024 維高維稀疏詞表維度匹配方式語義相似關(guān)鍵詞精確強項同義改寫、模糊提問專有名詞、型號、代碼弱項精確關(guān)鍵詞、罕見詞語義泛化典型代表BGE、E5、text-embeddingBM25、SPLADE3.2 混合檢索為什么我?guī)缀醪辉儆脝我幌蛄繖z索看完上面的對比你就明白了稠密和稀疏是互補的不是替代關(guān)系。我現(xiàn)在的默認方案是混合檢索Hybrid Search同時跑稠密和稀疏兩路召回再用融合算法比如 RRFReciprocal Rank Fusion把兩路結(jié)果合并排序。這樣既能抓住語義又能保住關(guān)鍵詞實測召回率比單路高出一大截。RRF 的融合邏輯很優(yōu)雅它不關(guān)心兩路分數(shù)的絕對值只看排名。公式大致是每個文檔的最終得分 各路排名倒數(shù)的加權(quán)和。這樣即使稠密和稀疏的分數(shù)尺度完全不同也能公平融合。我一般給兩路各 0.5 的權(quán)重如果業(yè)務(wù)偏關(guān)鍵詞比如代碼檢索、型號檢索就把稀疏那路權(quán)重調(diào)高?；旌蠙z索的代價是計算量翻倍因為要跑兩套索引。但在大多數(shù)場景下這個代價完全值得。我做過一個對比測試同一個知識庫純稠密檢索的 Top-5 命中率是 72%混合檢索能到 89%。這 17 個百分點的差距直接決定了用戶覺得你的 Agent聰明還是智障。3.3 嵌入模型選型中文場景別照搬英文榜單嵌入模型的選擇上我踩過最大的坑就是照搬英文榜單。MTEB 榜單上排名靠前的模型很多是英文優(yōu)化的直接拿來處理中文效果可能還不如一個中等規(guī)模的中文專用模型。中文場景我一般優(yōu)先考慮 BGE 系列的中文版、以及一些國產(chǎn)的中文嵌入模型它們在中文語義上的表現(xiàn)明顯更穩(wěn)。選型時還要看向量維度和推理成本的平衡。維度越高表達能力越強但存儲和檢索成本也越高。768 維和 1024 維在實際效果上差距不大但存儲成本差 30% 多。我的建議是先用 768 維起步如果效果不夠再往上加。另外要注意最大輸入長度很多嵌入模型只支持 512 token超過就被截斷所以塊大小要配合模型長度來定別切出超過模型上限的塊。還有一個容易被忽略的點嵌入模型和查詢必須用同一個。有人入庫用模型 A查詢用模型 B結(jié)果向量空間對不上檢索全是噪聲。這個錯誤聽起來低級但我在真實項目里見過不止一次尤其是多人協(xié)作時一個人換了模型沒同步整個庫就廢了。4. 檢索召回從能搜到到搜得準的最后一公里4.1 Top-K 不是越大越好召回和噪聲要平衡檢索階段最直觀的參數(shù)是 Top-K也就是召回多少個塊。新手容易犯的錯是把 K 設(shè)得很大覺得多召回一些總沒錯。但召回越多噪聲越多喂給模型的上下文里混進無關(guān)內(nèi)容反而會干擾生成。我見過有人把 K 設(shè)成 20結(jié)果模型被一堆無關(guān)信息帶偏回答質(zhì)量還不如 K3。我的經(jīng)驗是Top-K 先設(shè) 5~10再配合重排做二次篩選。第一路召回可以稍微寬一點比如 20保證不漏然后用重排模型精排取前 3~5 個真正相關(guān)的喂給模型。這樣既保證了召回率又控制了噪聲。K 的具體值要看文檔粒度和問題類型事實型問題 K 可以小一點綜述型問題 K 可以大一點。4.2 重排RAG 效果提升性價比最高的一步如果只能選一個優(yōu)化點我會毫不猶豫選重排Rerank。重排模型Cross-Encoder 架構(gòu)會把查詢 候選塊拼在一起打分比單純的向量相似度精細得多。它的原理是讓查詢和文檔在模型內(nèi)部做充分的交叉注意力捕捉細粒度的相關(guān)性代價是計算慢不能對全庫做只能對召回的小候選集做。實測下來加一層重排Top-3 的準確率能提升 15~25 個百分點這是所有優(yōu)化手段里性價比最高的。重排模型我一般選 BGE-Reranker 系列中文場景表現(xiàn)穩(wěn)定。流程就是混合檢索召回 20 個候選重排模型打分取前 3~5 個。這套組合拳打下來檢索質(zhì)量基本能到生產(chǎn)可用的水平。提示重排模型和嵌入模型是兩回事別搞混。嵌入模型負責(zé)粗篩重排模型負責(zé)精排兩者配合才能發(fā)揮最大價值。4.3 查詢改寫用戶的問題往往不是好的檢索詞用戶提問和文檔表述之間經(jīng)常有語義鴻溝。用戶問我買的手機壞了咋辦文檔里寫的是售后維修流程直接拿用戶原話去檢索效果往往不好。這時候需要查詢改寫Query Rewriting把用戶的口語化問題轉(zhuǎn)成更適合檢索的形式。查詢改寫有幾種做法一是用大模型把問題改寫成多個檢索式Multi-Query并行檢索后合并二是做 HyDEHypothetical Document Embeddings先讓模型生成一個假想答案再用這個答案去檢索因為答案和文檔的表述風(fēng)格更接近三是做查詢擴展補充同義詞和相關(guān)詞。我常用的是 Multi-Query讓模型生成 3 個不同角度的檢索式召回率提升很明顯。查詢改寫不是萬能的它會引入額外的模型調(diào)用增加延遲。我的建議是對復(fù)雜問題開啟對簡單問題關(guān)閉或者用一個輕量分類器判斷問題類型再決定。別為了追求效果把所有查詢都改寫一遍延遲上去了用戶體驗反而差。5. 把管道串起來一個可復(fù)現(xiàn)的 RAG 基礎(chǔ)實現(xiàn)5.1 整體流程與關(guān)鍵參數(shù)前面講了四段現(xiàn)在把它們串成一條完整管道。整體流程是文檔解析 → 切分 → 嵌入 → 入庫 → 查詢改寫 → 混合檢索 → 重排 → 上下文組裝 → 生成。每一段都有對應(yīng)的參數(shù)我把我的默認配置列出來你可以直接抄作業(yè)再按需調(diào)整。環(huán)節(jié)關(guān)鍵參數(shù)我的默認值調(diào)整方向切分chunk_size / overlap500 / 80文檔結(jié)構(gòu)化程度高可調(diào)大嵌入模型 / 維度中文 BGE / 768效果不夠升 1024檢索Top-K召回20文檔量大可調(diào)大重排Top-N精排5事實型問題可調(diào)小融合RRF 權(quán)重稠密 0.5 / 稀疏 0.5關(guān)鍵詞場景調(diào)高稀疏這套配置我在多個項目里驗證過屬于開箱能用的基線。真正上線前一定要用真實業(yè)務(wù)問題做評測別用自己編的測試集因為自己編的問題往往和文檔表述太接近測不出真實效果。5.2 一個最小可跑的檢索代碼骨架下面這段是檢索部分的核心邏輯用偽代碼風(fēng)格寫方便你遷移到 LangChain、Spring AI 或 LangChain4j 里。重點看流程不糾結(jié)具體 API。def retrieve(query, top_k20, top_n5): # 1. 查詢改寫可選 queries rewrite_query(query) if is_complex(query) else [query] # 2. 混合檢索稠密 稀疏 dense_hits dense_index.search(embed(query), top_k) sparse_hits sparse_index.search(query, top_k) # 3. RRF 融合 fused rrf_fusion([dense_hits, sparse_hits], weights[0.5, 0.5]) # 4. 重排精排 reranked rerank_model.rank(query, fused[:top_k]) # 5. 返回 Top-N return reranked[:top_n]這段代碼里每一步都有講究。查詢改寫那步用is_complex判斷避免簡單問題也走改寫增加延遲RRF 融合那步的權(quán)重是可調(diào)的重排那步的top_k是候選集大小top_n是最終返回數(shù)。這幾個參數(shù)我建議做成配置項方便不同業(yè)務(wù)線調(diào)優(yōu)。5.3 上下文組裝別把召回的塊直接拼起來召回的塊怎么塞進 prompt也是有講究的。別簡單地把塊按順序拼起來那樣模型很難分清哪塊是重點。我的做法是給每個塊加上來源標注和序號比如[來源1: 產(chǎn)品手冊 P12] 內(nèi)容...讓模型知道信息出處。同時控制總長度別超過模型的上下文窗口超了就按相關(guān)性截斷。還有一個技巧是把最相關(guān)的塊放在最前面和最后面。有研究表明模型對上下文首尾的信息更敏感迷失在中間現(xiàn)象所以把重排后最相關(guān)的塊放兩端能提升利用效率。這個細節(jié)很小但在長上下文場景下效果明顯。6. 那些文檔不會寫的 RAG 實戰(zhàn)心得6.1 評測集比模型更重要我見過太多團隊花大力氣調(diào)模型、換框架卻從來沒建過一個像樣的評測集。沒有評測所有優(yōu)化都是盲調(diào)。我的做法是項目一開始就攢一個 50~100 條的真實問題集每條標注正確答案和應(yīng)該召回的文檔塊。每次改動管道都跑一遍評測看命中率和準確率的變化。這個習(xí)慣讓我避免了很多感覺變好了其實變差了的誤判。評測集要覆蓋不同類型的問題事實型、對比型、綜述型、否定型。尤其別漏了否定型問題比如哪些產(chǎn)品不支持退貨這類問題最容易暴露檢索的短板。評測指標我主要看兩個檢索的 RecallK 和生成的答案準確率。前者衡量管道后者衡量端到端。6.2 知識割裂是 RAG 的隱形殺手熱詞里有個詞叫解決了知識割裂這戳中了很多 RAG 項目的痛點。知識割裂指的是相關(guān)信息散落在多個塊里單個塊都不完整檢索時只召回其中一塊導(dǎo)致答案片面。比如一個產(chǎn)品的參數(shù)分散在三個章節(jié)用戶問這個產(chǎn)品的完整規(guī)格只召回一塊就答不全。解決知識割裂有幾種思路一是父子塊Parent-Child檢索用小塊保證精度返回時帶上父塊保證完整性二是圖結(jié)構(gòu)GraphRAG把實體和關(guān)系建成圖檢索時沿著關(guān)系擴展三是塊間關(guān)聯(lián)入庫時記錄塊之間的引用關(guān)系檢索時一并召回。我常用父子塊方案實現(xiàn)簡單效果明顯。GraphRAG 效果更好但成本高適合知識關(guān)系復(fù)雜的場景。6.3 別忽視檢索不到的情況很多 RAG 系統(tǒng)有個通病無論檢索到什么都硬塞給模型生成。結(jié)果用戶問一個知識庫里根本沒有的問題模型拿著無關(guān)內(nèi)容硬編輸出一堆幻覺。正確的做法是加一個相關(guān)性閾值如果重排后的最高分低于閾值就明確告訴用戶知識庫中沒有相關(guān)信息而不是硬答。這個閾值怎么定我的做法是拿一批知識庫外問題跑一遍看它們的重排分數(shù)分布取一個能過濾掉大部分外問題、又不誤傷內(nèi)問題的值。這個閾值不是固定的換嵌入模型或重排模型都要重新校準。加了這個機制之后用戶對系統(tǒng)的信任度明顯提升因為不知道就說不知道比一本正經(jīng)胡說強太多。6.4 增量更新與版本管理知識庫不是一次建好就完事的文檔會更新、會新增、會作廢。增量更新的能力必須在設(shè)計階段就考慮進去。我的做法是給每個文檔一個唯一 ID 和版本號更新時先刪舊版本再插新版本保證不重復(fù)不遺漏。同時記錄更新時間檢索時可以按時間過濾避免召回作廢的舊文檔。版本管理還有個坑是嵌入模型升級。如果換了嵌入模型全庫向量都得重新生成否則新舊向量空間不一致。這個操作成本很高所以嵌入模型選型要慎重別頻繁換。如果非要換做好灰度方案別一次性全量切換。7. 從基礎(chǔ) RAG 到 Agentic RAG 的演進方向基礎(chǔ) RAG 跑通之后你會發(fā)現(xiàn)它有幾個天然局限檢索是一次性的不會根據(jù)中間結(jié)果調(diào)整不會判斷這個問題需不需要檢索不會多輪檢索逐步逼近答案。這些局限催生了Agentic RAG——把 RAG 從一條固定流水線變成 Agent 可以自主調(diào)度的工具。Agentic RAG 的核心變化是Agent 自己決定要不要檢索、檢索什么、檢索幾次、要不要基于結(jié)果再檢索。比如用戶問一個復(fù)雜問題Agent 先檢索一次發(fā)現(xiàn)信息不夠自動改寫查詢再檢索直到信息足夠才生成答案。這種檢索—反思—再檢索的循環(huán)能顯著提升復(fù)雜問題的回答質(zhì)量。實現(xiàn) Agentic RAG 的關(guān)鍵是把檢索封裝成一個工具讓 Agent 通過工具調(diào)用來使用。同時要給 Agent 一個判斷信息是否足夠的能力這通?？恳粋€反思 prompt 或者一個專門的評估模型。我實測下來Agentic RAG 在復(fù)雜問題上的表現(xiàn)明顯優(yōu)于基礎(chǔ) RAG但延遲和成本也更高適合對質(zhì)量要求高、對延遲不敏感的場景。從基礎(chǔ) RAG 到 Agentic RAG不是推倒重來而是在基礎(chǔ)管道之上加一層調(diào)度邏輯。所以基礎(chǔ)管道一定要打扎實切分、嵌入、檢索、重排每一環(huán)都做到位Agentic 那層才有發(fā)揮空間?；A(chǔ)不牢上面蓋得越高越容易塌。我個人在實際項目里的體會是RAG 這件事沒有銀彈所有的效果都是一環(huán)一環(huán)摳出來的。別指望換個框架、換個模型就能質(zhì)變真正拉開差距的是對每個環(huán)節(jié)的理解和調(diào)優(yōu)。先把這條基礎(chǔ)管道跑通、跑穩(wěn)、跑準再去考慮 GraphRAG、Agentic RAG 這些進階玩法路會走得踏實很多。