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