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