1. 為什么“答非所問”的鍋通常不在模型做過 RAG 項(xiàng)目的人大概率都經(jīng)歷過這個(gè)場景用戶問了一個(gè)問題系統(tǒng)檢索回來一堆看起來相關(guān)的文檔模型也認(rèn)認(rèn)真真生成了一段話但答的內(nèi)容跟問題就是差著十萬八千里。第一反應(yīng)往往是“模型不行換個(gè)更大的”“提示詞沒寫好再調(diào)調(diào)”然后花大量時(shí)間在 prompt 上反復(fù)折騰效果卻始終不穩(wěn)定。我踩過這個(gè)坑不止一次。后來復(fù)盤發(fā)現(xiàn)絕大多數(shù)“答非所問”的根因根本不在生成端而在檢索端——向量化質(zhì)量、切分策略、相似度度量、索引配置這幾環(huán)里只要有一環(huán)出了問題后面模型再強(qiáng)也救不回來。這個(gè)判斷不是拍腦袋而是有明確的排查路徑可以驗(yàn)證的。這篇文章想聊的就是這套排查思路當(dāng) RAG 出現(xiàn)答非所問時(shí)怎么系統(tǒng)性地先查向量鏈路把問題定位清楚再?zèng)Q定要不要?jiǎng)幽Ｐ?。涉及的核心技術(shù)點(diǎn)包括向量化模型選型、Milvus 的索引與度量方式、LangGraph 編排下的檢索節(jié)點(diǎn)調(diào)試以及一套可復(fù)用的排查清單。適合正在做 RAG 項(xiàng)目、被檢索質(zhì)量問題困擾的開發(fā)者也適合剛接觸向量數(shù)據(jù)庫、想搞清楚“向量到底在干什么”的朋友。2. 先搞清楚向量檢索這條鏈路到底發(fā)生了什么2.1 從一句話到一次檢索的完整路徑很多人對(duì) RAG 的理解停留在“把文檔塞進(jìn)向量庫然后搜出來給模型”。但真正跑起來從用戶輸入到最終召回中間至少經(jīng)過這么幾步用戶 query 經(jīng)過 embedding 模型轉(zhuǎn)成一個(gè)高維向量這個(gè) query 向量去向量庫里跟已存儲(chǔ)的文檔向量做相似度計(jì)算按相似度排序取 Top-K 個(gè)結(jié)果這些結(jié)果拼進(jìn) prompt交給 LLM 生成答案問題就藏在這四步里。第 1 步query 和文檔是不是用了同一個(gè) embedding 模型第 2 步相似度用的是余弦還是點(diǎn)積兩者對(duì)歸一化的要求一樣嗎第 3 步Top-K 取多少合適取少了漏召回取多了引入噪聲第 4 步召回的片段本身是不是完整的語義單元我見過一個(gè)典型案例文檔用某個(gè)中文 embedding 模型向量化query 卻用了另一個(gè)英文為主的模型結(jié)果就是向量空間根本對(duì)不上檢索出來的東西完全是隨機(jī)的。這種問題你調(diào)一萬遍 prompt 都沒用。2.2 向量相似度到底在比什么要排查向量問題得先理解向量相似度的幾何含義。這里不堆公式用直覺解釋。一個(gè)文本被 embedding 模型轉(zhuǎn)成一個(gè)高維向量比如 768 維或 1024 維。你可以把它想象成高維空間里的一個(gè)箭頭箭頭的方向代表了這段文本的語義。兩段語義相近的文本它們的箭頭方向就接近。余弦相似度衡量的是兩個(gè)箭頭方向的夾角夾角越小越相似取值范圍 -1 到 1。它只關(guān)心方向不關(guān)心長度所以對(duì)向量做不做歸一化不影響結(jié)果。點(diǎn)積則同時(shí)受方向和長度影響。如果兩個(gè)向量都做了 L2 歸一化長度變成 1那點(diǎn)積就等于余弦相似度。但如果沒歸一化點(diǎn)積會(huì)被向量長度帶偏——一個(gè)長向量跟任何向量的點(diǎn)積都可能偏大導(dǎo)致檢索結(jié)果失真。歐氏距離衡量的是兩個(gè)箭頭端點(diǎn)之間的直線距離距離越小越相似。它同樣受向量長度影響。這就是為什么在 Milvus 里選度量方式時(shí)如果你用的 embedding 模型輸出沒有歸一化卻選了內(nèi)積IP那檢索質(zhì)量很可能莫名其妙地差。這個(gè)坑非常隱蔽因?yàn)榇a不報(bào)錯(cuò)只是結(jié)果不對(duì)。2.3 為什么“先查向量”是最高效的排查順序從工程效率角度看排查順序應(yīng)該遵循“從確定性高、成本低的環(huán)節(jié)往確定性低、成本高的環(huán)節(jié)走”。向量鏈路里的問題大多是確定性的模型用錯(cuò)、維度不匹配、度量方式選錯(cuò)、歸一化沒做這些都能通過打印中間結(jié)果直接驗(yàn)證改起來也快。而模型生成端的問題往往是概率性的prompt 措辭、溫度參數(shù)、上下文長度調(diào)起來費(fèi)時(shí)且效果不穩(wěn)定。所以正確的順序是先確認(rèn) query 向量和文檔向量在同一個(gè)空間、度量方式匹配、召回結(jié)果確實(shí)相關(guān)再去懷疑模型。把這條鏈路走通你會(huì)發(fā)現(xiàn)大部分“答非所問”在向量層就已經(jīng)暴露了。3. 向量化環(huán)節(jié)最容易被忽視的第一道關(guān)3.1 embedding 模型選型的三個(gè)硬指標(biāo)選 embedding 模型不能只看排行榜得結(jié)合你的實(shí)際場景。我一般看三個(gè)指標(biāo)語言匹配度。如果你的知識(shí)庫是中文為主就必須選中文語料訓(xùn)練充分的模型。很多英文模型在中文上的語義區(qū)分度很差相近的中文句子會(huì)被映射到幾乎相同的向量位置檢索時(shí)根本分不開。維度與性能的平衡。維度越高表達(dá)能力越強(qiáng)但存儲(chǔ)和計(jì)算成本也越高。768 維和 1024 維在多數(shù)場景下夠用1536 維以上要謹(jǐn)慎評(píng)估是否真的需要。我實(shí)測過一個(gè)場景把維度從 1536 降到 768檢索準(zhǔn)確率只掉了不到 2%但索引體積和檢索延遲都明顯改善。最大輸入長度。這個(gè)參數(shù)決定了你的切分策略。如果模型最大只支持 512 token你卻把 2000 字的段落直接塞進(jìn)去超出部分會(huì)被截?cái)嗾Z義就殘缺了。指標(biāo)常見取值選型建議語言中文/英文/多語言中文庫優(yōu)先中文模型維度384/768/1024/1536768-1024 性價(jià)比最高最大長度512/8192 token決定切分粒度上限歸一化是/否影響度量方式選擇3.2 切分策略語義完整比長度均勻更重要切分是 RAG 里最考驗(yàn)經(jīng)驗(yàn)的一環(huán)。新手常犯的錯(cuò)是按固定字符數(shù)硬切比如每 500 字切一段。這樣切出來的片段經(jīng)常在句子中間斷開語義不完整向量化后表達(dá)的意思就偏了。我的做法是按語義邊界切分優(yōu)先在段落、標(biāo)題、列表項(xiàng)這些自然邊界處斷開再控制單段長度。如果一段太長就在句子邊界處二次切分。這樣每個(gè)片段都是一個(gè)相對(duì)完整的語義單元向量質(zhì)量明顯更好。還有一個(gè)細(xì)節(jié)是重疊區(qū)。相鄰片段之間保留 10%-20% 的重疊內(nèi)容可以避免關(guān)鍵信息正好落在切分點(diǎn)上被割裂。這個(gè)比例不是拍腦袋是因?yàn)檎Z義的連續(xù)性往往跨越邊界適當(dāng)重疊能讓檢索時(shí)更容易命中完整上下文。提示切分長度要和 embedding 模型的最大輸入長度對(duì)齊。如果模型支持 512 token單段控制在 300-400 token 比較穩(wěn)妥留出余量避免截?cái)唷?.3 歸一化一個(gè)不做就出事的預(yù)處理前面提到點(diǎn)積受向量長度影響解決辦法就是在存入向量庫之前做 L2 歸一化把所有向量長度統(tǒng)一成 1。這樣無論你用余弦還是內(nèi)積結(jié)果都一致省去了很多心智負(fù)擔(dān)。歸一化的代碼很簡單但很多人會(huì)漏掉。我建議把它做成向量化流程里的固定步驟而不是依賴某個(gè)庫的默認(rèn)行為。因?yàn)椴煌?embedding 庫的默認(rèn)行為不一樣有的自動(dòng)歸一化有的不歸一化混用就會(huì)出問題。import numpy as np def normalize(vec): norm np.linalg.norm(vec) if norm 0: return vec return vec / norm這段代碼看著簡單但它能幫你排除掉一整類“檢索結(jié)果莫名其妙”的問題。我現(xiàn)在的習(xí)慣是只要向量入庫先過一遍歸一化心里踏實(shí)。4. Milvus 索引與度量配置錯(cuò)了結(jié)果全歪4.1 度量方式怎么選才不踩坑Milvus 支持多種度量方式常用的有 COSINE、IP內(nèi)積、L2歐氏距離。選哪個(gè)不是隨便挑的得跟你的 embedding 模型和歸一化策略配套。如果向量已經(jīng)做了 L2 歸一化那 COSINE 和 IP 結(jié)果等價(jià)選哪個(gè)都行。如果沒歸一化就必須用 COSINE因?yàn)橹挥兴皇荛L度影響。L2 一般用在圖像特征這類場景文本檢索里相對(duì)少用。我見過有人用未歸一化的向量配 IP檢索結(jié)果時(shí)好時(shí)壞排查了半天才發(fā)現(xiàn)是度量方式的問題。改成 COSINE 之后立刻正常。這種問題不打印向量范數(shù)是看不出來的。4.2 索引類型對(duì)召回率的影響Milvus 的索引類型直接決定了檢索速度和召回率的平衡。常用的幾種FLAT是暴力檢索召回率 100%但數(shù)據(jù)量大時(shí)慢得沒法用。適合小數(shù)據(jù)集或者做效果驗(yàn)證的基準(zhǔn)。IVF_FLAT通過聚類把向量分桶檢索時(shí)只查部分桶速度快但會(huì)損失一點(diǎn)召回率。關(guān)鍵是 nlist 參數(shù)桶分得越細(xì)召回越高但越慢。HNSW用圖結(jié)構(gòu)組織向量檢索快且召回率高是目前綜合表現(xiàn)最好的選擇。代價(jià)是內(nèi)存占用大構(gòu)建索引慢。IVF_PQ在 IVF 基礎(chǔ)上做了乘積量化壓縮內(nèi)存占用極小適合超大規(guī)模數(shù)據(jù)但召回率損失明顯。索引類型召回率速度內(nèi)存適用場景FLAT100%慢高小數(shù)據(jù)/基準(zhǔn)測試IVF_FLAT高中中中等規(guī)模通用HNSW很高快高追求效果優(yōu)先IVF_PQ中快低超大規(guī)模省內(nèi)存我的經(jīng)驗(yàn)是如果數(shù)據(jù)量在百萬級(jí)以內(nèi)直接上 HNSW省心。數(shù)據(jù)量再大再考慮 IVF 系列。4.3 在 Mac 上用 Docker 跑 Milvus Standalone本地開發(fā)調(diào)試用 Docker 跑 Milvus standalone 模式最方便。standalone 是單機(jī)版包含了所有必要組件適合開發(fā)和中小規(guī)模部署。# 下載官方 compose 文件 wget https://github.com/milvus-io/milvus/releases/download/v2.4.0/milvus-standalone-docker-compose.yml -O docker-compose.yml # 啟動(dòng) docker compose up -d # 查看狀態(tài) docker compose ps啟動(dòng)后默認(rèn)端口是 19530。Mac 上要注意 Docker 分配的內(nèi)存Milvus 至少需要 4GB建議在 Docker Desktop 里把內(nèi)存調(diào)到 8GB 以上否則容易啟動(dòng)失敗或者檢索時(shí)卡頓。連接測試from pymilvus import connections, Collection connections.connect(hostlocalhost, port19530) print(連接成功)如果連不上先檢查容器是否正常啟動(dòng)再看端口有沒有被占用。Mac 上偶爾會(huì)遇到端口沖突換個(gè)端口映射就行。5. LangGraph 編排下的檢索節(jié)點(diǎn)調(diào)試5.1 把檢索做成獨(dú)立可觀測的節(jié)點(diǎn)用 LangGraph 編排 RAG 流程的好處是每個(gè)環(huán)節(jié)都是顯式的節(jié)點(diǎn)方便單獨(dú)調(diào)試。我一般會(huì)把檢索拆成兩個(gè)節(jié)點(diǎn)一個(gè)負(fù)責(zé) query 向量化一個(gè)負(fù)責(zé)向量庫查詢。這樣出問題時(shí)能快速定位是哪一步的鍋。from langgraph.graph import StateGraph, END def embed_query(state): query state[query] vector embedding_model.encode(query) return {query_vector: normalize(vector)} def retrieve(state): vector state[query_vector] results collection.search( data[vector], anns_fieldembedding, param{metric_type: COSINE, params: {ef: 64}}, limit5, output_fields[text] ) return {docs: [hit.entity.get(text) for hit in results[0]]}把這兩個(gè)節(jié)點(diǎn)分開調(diào)試時(shí)就能分別打印 query 向量和召回結(jié)果一眼看出問題在哪。5.2 在節(jié)點(diǎn)里埋入可觀測信息光有節(jié)點(diǎn)還不夠得讓節(jié)點(diǎn)輸出足夠的信息供排查。我習(xí)慣在每個(gè)關(guān)鍵節(jié)點(diǎn)里記錄輸入是什么、輸出是什么、耗時(shí)多少、召回的相似度分?jǐn)?shù)分布。相似度分?jǐn)?shù)特別有用。如果 Top-5 的分?jǐn)?shù)都在 0.3 以下說明檢索質(zhì)量很差要么是向量化有問題要么是知識(shí)庫里根本沒有相關(guān)內(nèi)容。如果分?jǐn)?shù)都在 0.9 以上但答案還是不對(duì)那可能是召回了高度相似但實(shí)際不相關(guān)的內(nèi)容需要檢查切分和去重。def retrieve_with_debug(state): vector state[query_vector] results collection.search(...) scores [hit.score for hit in results[0]] print(f召回分?jǐn)?shù): {scores}) print(f最高分: {max(scores):.4f}, 最低分: {min(scores):.4f}) return {docs: [...], scores: scores}這個(gè)打印看著土但排查問題時(shí)比任何可視化工具都直接。5.3 用 LLM as Judge 做檢索質(zhì)量評(píng)估當(dāng)檢索結(jié)果肉眼不好判斷時(shí)可以引入 LLM as Judge讓模型來判斷召回的內(nèi)容跟 query 是否相關(guān)。這不是用來替代人工而是快速篩出明顯有問題的 case。做法是把 query 和召回的每個(gè)片段拼成一個(gè)判斷 prompt讓模型輸出“相關(guān)/不相關(guān)”。批量跑一批測試 query統(tǒng)計(jì)相關(guān)率。如果相關(guān)率低于 70%基本可以確定檢索鏈路有問題先別動(dòng)生成端。注意LLM as Judge 本身也有偏差只適合做粗篩最終判斷還是要靠人工抽查。別把它當(dāng)成絕對(duì)標(biāo)準(zhǔn)。6. 常見問題排查速查表6.1 檢索結(jié)果完全不相關(guān)這是最典型的問題。排查順序確認(rèn) query 和文檔用的是同一個(gè) embedding 模型打印兩者的向量維度對(duì)比檢查向量是否歸一化打印向量范數(shù)確認(rèn) Milvus 的度量方式跟歸一化策略匹配用一條已知答案的 query 做測試看能否召回對(duì)應(yīng)文檔如果這四步都正常再去看切分是否合理。我遇到過切分把關(guān)鍵信息切碎導(dǎo)致召不回的情況把切分粒度調(diào)大就好了。6.2 檢索結(jié)果相關(guān)但答案不對(duì)這種情況說明檢索沒問題問題在生成端或者上下文組織。檢查召回的片段是否包含了回答問題所需的完整信息prompt 里是否明確要求模型基于給定上下文回答上下文是否太長導(dǎo)致關(guān)鍵信息被淹沒有時(shí)候召回 10 個(gè)片段關(guān)鍵信息只在第 8 個(gè)里模型注意力被前面的噪聲帶偏了。這時(shí)候減少 Top-K 或者做重排序rerank會(huì)有幫助。6.3 相似度分?jǐn)?shù)普遍偏低如果所有 query 的召回分?jǐn)?shù)都低可能是embedding 模型不適合你的領(lǐng)域換一個(gè)領(lǐng)域適配更好的知識(shí)庫內(nèi)容跟 query 的表達(dá)方式差異太大考慮做 query 改寫向量維度太低表達(dá)能力不足6.4 排查速查表現(xiàn)象可能原因排查動(dòng)作完全不相關(guān)模型不一致/未歸一化打印向量維度和范數(shù)相關(guān)但答錯(cuò)上下文組織問題檢查 prompt 和 Top-K分?jǐn)?shù)普遍低模型不適配/維度低換模型或提維度時(shí)好時(shí)壞度量方式不匹配統(tǒng)一用 COSINE召回漏關(guān)鍵信息切分過碎調(diào)整切分粒度7. 幾個(gè)我踩過的坑和實(shí)操心得第一個(gè)坑是混用 embedding 模型。早期項(xiàng)目里文檔入庫用了一個(gè)模型后來換了個(gè)更新的模型做 query 向量化忘了重新索引文檔結(jié)果檢索質(zhì)量斷崖式下跌。教訓(xùn)是換 embedding 模型必須全量重建索引沒有例外。第二個(gè)坑是忽略向量維度對(duì)齊。有次從 768 維模型換到 1024 維Milvus 的 collection 還是按 768 維建的插入時(shí)報(bào)錯(cuò)才發(fā)現(xiàn)。建 collection 時(shí)一定要把維度寫死并跟模型對(duì)齊別用動(dòng)態(tài)維度。第三個(gè)心得是建立檢索質(zhì)量的回歸測試集。準(zhǔn)備 50-100 條帶標(biāo)準(zhǔn)答案的 query每次改動(dòng)檢索鏈路后跑一遍看召回率變化。這比憑感覺判斷靠譜得多。我現(xiàn)在的項(xiàng)目里這個(gè)測試集是必建的改任何檢索相關(guān)配置前先跑基線。第四個(gè)心得是別急著上復(fù)雜方案。很多人一上來就搞多路召回、重排序、query 改寫結(jié)果基礎(chǔ)鏈路都沒調(diào)通。我的建議是先把單路向量檢索調(diào)到滿意再考慮加復(fù)雜度?；A(chǔ)不牢加再多組件也是白搭。最后一個(gè)體會(huì)是關(guān)于排查心態(tài)。RAG 出問題時(shí)人容易焦慮想快速換個(gè)模型試試。但換模型是成本最高的操作而且往往治標(biāo)不治本。養(yǎng)成先查向量鏈路的習(xí)慣把確定性的問題先排除掉剩下的才是真正需要模型層面解決的。這個(gè)順序理順了排查效率能提升好幾倍。這套排查方法我在多個(gè)項(xiàng)目里驗(yàn)證過從中文知識(shí)庫到多語言場景都適用。核心就一句話向量層的問題用向量的方式查別讓模型背不該背的鍋。