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