1. 從一個被問爛了的問題說起“為什么大廠 RAG 從不用純向量檢索”這個問題我在不同場合被問過不下十次。有剛?cè)胄械呐笥延凶隽藥啄晁阉鬓D(zhuǎn)行做 RAG 的工程師也有產(chǎn)品經(jīng)理拿著技術方案來對需求。每次我都得從頭講一遍因為這里面的坑不自己踩過一遍光看論文和博客是很難真正理解的。先說結(jié)論純向量檢索不是不能用而是在真實業(yè)務場景下它單獨用會死得很難看。大廠不用它不是因為向量檢索不好而是因為大廠的業(yè)務場景太復雜、數(shù)據(jù)量太大、用戶預期太高單一召回手段根本兜不住。這篇文章我會把這件事徹底講透。從向量檢索的本質(zhì)缺陷到混合檢索的設計思路到多路召回怎么融合到重排序怎么做再到實際落地時的參數(shù)調(diào)優(yōu)和踩坑經(jīng)驗。如果你正在做 RAG 相關的項目或者準備做這篇文章應該能幫你省下至少兩三個月的試錯時間。適合誰看做搜索的、做推薦的、做問答系統(tǒng)的、做知識庫的以及所有對 RAG 技術棧感興趣的人。不需要你精通向量數(shù)據(jù)庫但最好對 embedding 和相似度計算有基本概念。沒有也沒關系我會用生活化的例子來解釋。2. 純向量檢索到底在干什么以及它為什么不夠用2.1 向量檢索的本質(zhì)語義相似度匹配先把這個概念說清楚。向量檢索的核心邏輯是把文本通過 embedding 模型轉(zhuǎn)成一個高維向量然后通過計算向量之間的距離余弦相似度、內(nèi)積、歐氏距離等來判斷兩段文本在語義上是否相似。舉個例子?！敖裉焯鞖庹婧谩焙汀瓣柟饷髅牡囊惶臁边@兩句話字面上沒有一個詞重疊但 embedding 之后它們的向量距離會很近因為語義相近。這就是向量檢索的威力——它能捕捉到字面之外的語義關聯(lián)。但問題恰恰出在這里。語義相似不等于用戶想要的結(jié)果。這是兩碼事。我舉個真實的場景。假設你有一個企業(yè)知識庫用戶搜“報銷流程”。向量檢索可能會返回“費用申請步驟”“財務審批指南”“差旅費管理辦法”這些語義相近的文檔?？雌饋聿诲e對吧但如果用戶搜的是“差旅報銷標準是多少錢”向量檢索可能返回一堆講報銷流程的文檔卻沒有精確命中那個寫著具體金額的表格。為什么因為 embedding 模型在壓縮信息的時候把“多少錢”這個關鍵的數(shù)字信息給模糊掉了。向量檢索擅長捕捉“大概在講什么”但不擅長精確定位“具體是什么”。2.2 純向量檢索的四個致命傷我把純向量檢索在實際業(yè)務中暴露的問題歸納為四類第一精確匹配能力弱。用戶搜“ERR-4032 錯誤碼”向量檢索可能返回一堆講錯誤處理的文檔但就是找不到那個專門講 ERR-4032 的頁面。因為 embedding 模型對數(shù)字、代號、專有名詞的區(qū)分度很低。你搜“張三”它可能給你返回“李四”因為這兩個名字在語義空間里距離很近——都是人名嘛。第二對罕見詞和長尾 query 效果差。embedding 模型的訓練數(shù)據(jù)是有偏的高頻詞和常見表達學得好罕見詞和長尾表達就學得糊。用戶搜一個非常專業(yè)的術語向量檢索可能完全找不到相關文檔因為模型在訓練時就沒怎么見過這個詞。第三無法處理否定和邏輯關系。用戶搜“不含糖的飲料”向量檢索可能返回一堆含糖飲料的文檔因為“飲料”這個語義占了主導“不含糖”這個否定修飾在向量空間里幾乎體現(xiàn)不出來。類似的還有“除了A以外的所有情況”這種邏輯向量檢索基本無能為力。第四可解釋性差調(diào)優(yōu)困難。向量檢索返回的結(jié)果你很難解釋為什么這個排第一那個排第五。出了問題也不好調(diào)你只能換模型、調(diào)參數(shù)、加數(shù)據(jù)但具體哪一步起了作用很難說清楚。這在企業(yè)級應用里是個大問題因為業(yè)務方會問你“為什么這個結(jié)果排在前面”你總不能說“因為向量距離近”吧。2.3 大廠場景為什么放大了這些問題大廠的業(yè)務場景有幾個特點數(shù)據(jù)量大、用戶量大、query 分布廣、業(yè)務要求高。數(shù)據(jù)量大意味著你不能只靠一個 embedding 模型打天下不同業(yè)務線的數(shù)據(jù)特征差異很大一個模型很難在所有場景下都表現(xiàn)好。用戶量大意味著任何一個小問題都會被放大——哪怕只有 1% 的 query 效果不好在千萬級日活下就是十萬級的 bad case。query 分布廣意味著長尾 query 特別多而向量檢索恰恰在長尾上表現(xiàn)最差。業(yè)務要求高意味著你不能說“大概差不多就行”用戶要的是精確答案不是語義相近的文檔。所以大廠不是不想用純向量檢索而是純向量檢索在真實業(yè)務場景下的召回率和準確率都達不到上線標準。這不是技術好不好是場景匹不匹配的問題。3. 混合檢索大廠 RAG 的標配方案3.1 混合檢索的核心思路既然純向量檢索不夠用那怎么辦答案很簡單多種召回手段一起上各取所長。這就是混合檢索Hybrid Retrieval的核心思路。它不是用一個方法解決所有問題而是用多個方法分別解決不同類型的問題然后把結(jié)果融合起來。常見的召回手段包括召回方式擅長場景不擅長場景向量檢索語義相似、模糊匹配、跨語言精確匹配、數(shù)字代號、長尾詞關鍵詞檢索BM25精確匹配、專有名詞、數(shù)字語義泛化、同義詞、跨語言倒排索引結(jié)構(gòu)化字段過濾、范圍查詢非結(jié)構(gòu)化文本語義匹配知識圖譜實體關系推理、多跳查詢非結(jié)構(gòu)化文本、模糊語義大廠的 RAG 系統(tǒng)通常是向量檢索 關鍵詞檢索BM25作為基礎組合再根據(jù)業(yè)務需要疊加其他召回手段。3.2 為什么是 BM25而不是其他關鍵詞算法BM25 是信息檢索領域的經(jīng)典算法雖然老但在實際業(yè)務中依然是最穩(wěn)的關鍵詞召回方案。它的核心思想是一個詞在文檔中出現(xiàn)頻率越高文檔越相關但這個詞在整個語料庫中越常見它的權重就越低。用大白話說就是如果某個詞在很多文檔里都出現(xiàn)那它就不重要如果某個詞只在少數(shù)文檔里出現(xiàn)那它就很關鍵。BM25 有幾個優(yōu)點不需要訓練直接算就行可解釋性強每個詞的貢獻都能算出來對精確匹配特別有效用戶搜什么詞就匹配什么詞。這些優(yōu)點恰好補上了向量檢索的短板。當然 BM25 也有缺點它不理解語義。用戶搜“手機”它不會返回“移動電話”的文檔。但這沒關系因為向量檢索會補上這一塊。兩者結(jié)合覆蓋的場景就廣了。3.3 多路召回怎么融合從 RRF 到加權融合有了多路召回下一個問題就是怎么把不同召回源的結(jié)果合并成一個排序最簡單的方法是加權融合給每個召回源的結(jié)果打分然后加權求和。比如向量檢索的分數(shù)占 0.6BM25 的分數(shù)占 0.4。但這個方法有個問題不同召回源的分數(shù)分布不一樣直接加權可能不公平。更常用的方法是RRFReciprocal Rank Fusion倒數(shù)排名融合。它的思路是不看具體分數(shù)只看排名。每個文檔在每路召回中的排名取倒數(shù)后求和。公式很簡單RRF_score(d) Σ (1 / (k rank_i(d)))其中 k 是一個常數(shù)通常取 60rank_i(d) 是文檔 d 在第 i 路召回中的排名。RRF 的好處是不需要歸一化分數(shù)對不同召回源的分數(shù)分布不敏感實現(xiàn)簡單效果穩(wěn)定。大廠在融合多路召回時RRF 是默認方案。我實測下來RRF 的 k 值取 60 是個比較穩(wěn)的選擇。k 太小頭部結(jié)果波動大k 太大尾部結(jié)果區(qū)分度不夠。當然具體業(yè)務具體調(diào)但 60 是個不錯的起點。3.4 重排序最后一道質(zhì)量關卡多路召回融合之后通常會得到一個比較大的候選集比如 top 100。這時候還需要一個重排序Rerank步驟用更精細的模型對候選集重新打分選出最終的 top k。重排序模型通常比召回模型大計算也更慢但精度更高。常見的方案是用 Cross-Encoder 架構(gòu)的模型把 query 和文檔拼在一起輸入模型直接輸出相關性分數(shù)。為什么召回和排序要分開因為召回階段要處理海量數(shù)據(jù)必須快排序階段只處理少量候選可以慢一點但要求準。這就是所謂的漏斗模型召回粗篩排序精排。重排序這一步在實際業(yè)務中非常關鍵。我見過很多團隊在召回上花了很多功夫但忽略了重排序最后效果就是上不去。召回決定上限排序決定最終質(zhì)量。兩者都不能偏。4. 實際落地時的關鍵細節(jié)與踩坑記錄4.1 向量模型選型不是越大越好選 embedding 模型的時候很多人第一反應是選最大的、最新的。但實際業(yè)務中模型大小和推理成本是直接掛鉤的。我做過一個對比測試在一個百萬級文檔的知識庫上用不同大小的 embedding 模型做檢索。結(jié)果發(fā)現(xiàn)在 top 10 的召回率上大模型確實比小模型高 3-5 個百分點。但推理時間上大模型是小模型的 5-8 倍。如果業(yè)務對延遲敏感這個差距是不可接受的。我的建議是先用小模型跑通流程確認效果瓶頸在哪里再決定要不要換大模型。很多時候瓶頸不在 embedding 模型上而在數(shù)據(jù)質(zhì)量、切分策略、召回融合這些環(huán)節(jié)。另外embedding 模型的領域適配也很重要。通用模型在通用場景下表現(xiàn)好但在垂直領域醫(yī)療、法律、金融可能就不行了。這時候要么用領域數(shù)據(jù)微調(diào)要么選專門針對該領域訓練的模型。4.2 文檔切分最容易被忽視的環(huán)節(jié)文檔切分Chunking是 RAG 系統(tǒng)里最不起眼但影響最大的環(huán)節(jié)之一。切分策略直接決定了召回的質(zhì)量。我見過太多團隊在這個環(huán)節(jié)偷懶固定長度切分512 個 token 一刀切。結(jié)果就是有的 chunk 把一句話切成兩半語義不完整有的 chunk 包含多個主題向量表示模糊有的 chunk 太短信息量不夠。好的切分策略應該考慮語義完整性盡量在段落、章節(jié)邊界切分不要切斷完整的語義單元。重疊窗口相鄰 chunk 之間保留一定的重疊比如 10-20%避免邊界信息丟失。元數(shù)據(jù)附加每個 chunk 帶上來源、標題、時間等元數(shù)據(jù)方便后續(xù)過濾和排序。層級結(jié)構(gòu)如果文檔有層級結(jié)構(gòu)章節(jié)、小節(jié)保留這個結(jié)構(gòu)信息。我自己的經(jīng)驗是切分策略沒有標準答案必須根據(jù)業(yè)務數(shù)據(jù)特點來調(diào)。技術文檔、法律合同、客服對話這三種數(shù)據(jù)的切分策略完全不同?；〞r間在這個環(huán)節(jié)上回報率比調(diào)模型參數(shù)高得多。4.3 查詢改寫讓用戶的問題更好被理解用戶的 query 往往很短、很模糊、有歧義。直接拿去做檢索效果很難好。查詢改寫Query Rewriting就是解決這個問題的。常見的查詢改寫手段包括同義詞擴展把“手機”擴展成“手機 OR 移動電話 OR 智能手機”。拼寫糾錯把“aple”糾正成“apple”。意圖識別判斷用戶是想找文檔、找答案、還是找操作步驟。多輪改寫在多輪對話中把當前 query 和上下文結(jié)合改寫成完整的查詢。大廠的 RAG 系統(tǒng)通常會用一個小模型來做查詢改寫成本低、速度快、效果穩(wěn)定。這一步做得好召回質(zhì)量能提升 10-20%。4.4 常見問題速查表問題現(xiàn)象可能原因排查方向解決方案精確匹配搜不到純向量檢索缺少關鍵詞召回檢查是否有 BM25 召回加入關鍵詞召回用 RRF 融合長尾 query 效果差embedding 模型覆蓋不足分析 bad case 分布查詢改寫 關鍵詞召回兜底否定 query 失效向量模型不理解否定測試否定類 query查詢改寫 規(guī)則過濾召回結(jié)果重復多路召回未去重檢查融合邏輯加去重步驟按 doc_id 去重排序效果不穩(wěn)定重排序模型未調(diào)優(yōu)對比不同 rerank 模型換模型或加訓練數(shù)據(jù)延遲太高召回路數(shù)太多或模型太大分析各階段耗時減少召回路數(shù)換小模型5. 從零搭建一個混合檢索 RAG 系統(tǒng)的實操路徑5.1 整體架構(gòu)設計一個完整的混合檢索 RAG 系統(tǒng)通常包含以下模塊數(shù)據(jù)預處理文檔解析、切分、元數(shù)據(jù)提取。索引構(gòu)建向量索引 倒排索引。查詢處理查詢改寫、意圖識別。多路召回向量召回 關鍵詞召回。結(jié)果融合RRF 或加權融合。重排序Cross-Encoder 精排。答案生成LLM 基于召回結(jié)果生成答案。這個架構(gòu)不是固定的可以根據(jù)業(yè)務需要增減模塊。但核心思路是一樣的多路召回 融合 精排。5.2 關鍵參數(shù)計算與選擇向量維度取決于 embedding 模型常見的有 768、1024、1536。維度越高表達能力越強但存儲和計算成本也越高。百萬級文檔用 768 維通常夠用。索引類型HNSW 是目前最常用的向量索引查詢快、召回率高。關鍵參數(shù)是 M每個節(jié)點的連接數(shù)和 efConstruction構(gòu)建時的搜索范圍。M 通常取 16-64efConstruction 取 100-500。BM25 參數(shù)k1 和 b。k1 控制詞頻飽和點通常取 1.2-2.0b 控制文檔長度歸一化通常取 0.75。RRF 的 k 值通常取 60可根據(jù)業(yè)務調(diào)整。重排序候選數(shù)通常取 50-100太少可能漏掉好結(jié)果太多延遲高。5.3 實操步驟與代碼示例以下是一個簡化的混合檢索實現(xiàn)示例用 Python 演示核心邏輯# 偽代碼示例展示混合檢索的核心流程 def hybrid_retrieval(query, top_k10): # 第一步查詢改寫 rewritten_query query_rewrite(query) # 第二步多路召回 vector_results vector_search(rewritten_query, top_k100) bm25_results bm25_search(rewritten_query, top_k100) # 第三步RRF 融合 fused_results rrf_fusion( [vector_results, bm25_results], k60 ) # 第四步重排序 reranked_results rerank( query, fused_results[:50], top_ktop_k ) return reranked_results def rrf_fusion(result_lists, k60): scores {} for results in result_lists: for rank, doc in enumerate(results): doc_id doc[id] if doc_id not in scores: scores[doc_id] 0 scores[doc_id] 1 / (k rank 1) # 按分數(shù)排序 sorted_docs sorted( scores.items(), keylambda x: x[1], reverseTrue ) return [doc_id for doc_id, _ in sorted_docs]這個示例展示了核心流程實際生產(chǎn)中還需要考慮并發(fā)召回、超時控制、降級策略、緩存等。5.4 效果評估與迭代上線之后怎么評估效果不能只看感覺要有量化指標。常用的指標包括RecallK前 K 個結(jié)果中包含正確答案的比例。MRR第一個正確答案排名的倒數(shù)均值。NDCG考慮排序位置的加權指標。人工評估抽樣人工判斷相關性。我建議的做法是先建一個評估集包含 100-500 個 query 和對應的正確答案每次改動都跑一遍評估集看指標變化。沒有評估集調(diào)優(yōu)就是盲人摸象。6. 幾個容易被忽略但很重要的經(jīng)驗6.1 不要迷信單一指標召回率、準確率、延遲、成本這四個指標要一起看。我見過團隊為了提升 1% 的召回率把延遲從 100ms 拉到 500ms這在生產(chǎn)環(huán)境是不可接受的。技術方案的選擇永遠是權衡不是追求單點最優(yōu)。6.2 數(shù)據(jù)質(zhì)量比模型重要再好的模型喂給它垃圾數(shù)據(jù)也出不來好結(jié)果。文檔解析錯誤、切分不合理、元數(shù)據(jù)缺失這些問題比模型選型影響大得多。先把數(shù)據(jù)質(zhì)量搞上去再考慮換模型。6.3 從簡單方案開始不要一上來就搞最復雜的架構(gòu)。先用最簡單的方案跑通確認瓶頸在哪里再逐步加東西。我見過太多團隊一開始就上多路召回 重排序 查詢改寫結(jié)果每個環(huán)節(jié)都沒調(diào)好整體效果還不如單路 BM25。6.4 監(jiān)控和反饋閉環(huán)上線不是終點是起點。要有監(jiān)控看 bad case要有反饋渠道收集用戶反饋要有機制把反饋轉(zhuǎn)化成改進。沒有反饋閉環(huán)的系統(tǒng)會隨著時間推移越來越差。7. 回到最初的問題大廠 RAG 從不用純向量檢索不是因為向量檢索不好而是因為真實業(yè)務場景太復雜單一手段兜不住。混合檢索、多路召回、重排序這些不是炫技是被業(yè)務逼出來的。如果你正在做 RAG 項目我的建議是先把 BM25 跑通再加上向量檢索用 RRF 融合最后加重排序。這個路徑穩(wěn)、可控、每一步都有明確的收益。不要一上來就追求最先進的方案先把基礎打牢。我在實際項目中的體會是RAG 系統(tǒng)的效果20% 靠模型80% 靠工程。數(shù)據(jù)預處理、切分策略、召回融合、參數(shù)調(diào)優(yōu)這些臟活累活才是決定成敗的關鍵。模型選型當然重要但它不是全部。最后分享一個小技巧如果你不確定要不要上混合檢索先做個簡單測試——拿 100 個真實 query分別用純向量和混合檢索跑一遍人工對比結(jié)果。如果混合檢索明顯更好那就上如果差不多那就先別折騰。用數(shù)據(jù)說話別用感覺做決策。