1. 为什么“答非所问”的锅通常不在模型

做过 RAG 项目的人大概率都经历过这个场景：用户问了一个问题，系统检索回来一堆看起来相关的文档，模型也认认真真生成了一段话，但答的内容跟问题就是差着十万八千里。第一反应往往是“模型不行，换个更大的”“提示词没写好，再调调”，然后花大量时间在 prompt 上反复折腾，效果却始终不稳定。

我踩过这个坑不止一次。后来复盘发现，绝大多数“答非所问”的根因根本不在生成端，而在检索端——向量化质量、切分策略、相似度度量、索引配置这几环里，只要有一环出了问题，后面模型再强也救不回来。这个判断不是拍脑袋，而是有明确的排查路径可以验证的。

这篇文章想聊的就是这套排查思路：当 RAG 出现答非所问时，怎么系统性地先查向量链路，把问题定位清楚，再决定要不要动模型。涉及的核心技术点包括向量化模型选型、Milvus 的索引与度量方式、LangGraph 编排下的检索节点调试，以及一套可复用的排查清单。适合正在做 RAG 项目、被检索质量问题困扰的开发者，也适合刚接触向量数据库、想搞清楚“向量到底在干什么”的朋友。

2. 先搞清楚向量检索这条链路到底发生了什么

2.1 从一句话到一次检索的完整路径

很多人对 RAG 的理解停留在“把文档塞进向量库，然后搜出来给模型”。但真正跑起来，从用户输入到最终召回，中间至少经过这么几步：

1. 用户 query 经过 embedding 模型转成一个高维向量
2. 这个 query 向量去向量库里跟已存储的文档向量做相似度计算
3. 按相似度排序，取 Top-K 个结果
4. 这些结果拼进 prompt，交给 LLM 生成答案

问题就藏在这四步里。第 1 步，query 和文档是不是用了同一个 embedding 模型？第 2 步，相似度用的是余弦还是点积，两者对归一化的要求一样吗？第 3 步，Top-K 取多少合适，取少了漏召回，取多了引入噪声？第 4 步，召回的片段本身是不是完整的语义单元？

我见过一个典型案例：文档用某个中文 embedding 模型向量化，query 却用了另一个英文为主的模型，结果就是向量空间根本对不上，检索出来的东西完全是随机的。这种问题你调一万遍 prompt 都没用。

2.2 向量相似度到底在比什么

要排查向量问题，得先理解向量相似度的几何含义。这里不堆公式，用直觉解释。

一个文本被 embedding 模型转成一个高维向量，比如 768 维或 1024 维。你可以把它想象成高维空间里的一个箭头，箭头的方向代表了这段文本的语义。两段语义相近的文本，它们的箭头方向就接近。

余弦相似度衡量的是两个箭头方向的夹角，夹角越小越相似，取值范围 -1 到 1。它只关心方向，不关心长度，所以对向量做不做归一化不影响结果。

点积则同时受方向和长度影响。如果两个向量都做了 L2 归一化（长度变成 1），那点积就等于余弦相似度。但如果没归一化，点积会被向量长度带偏——一个长向量跟任何向量的点积都可能偏大，导致检索结果失真。

欧氏距离衡量的是两个箭头端点之间的直线距离，距离越小越相似。它同样受向量长度影响。

这就是为什么在 Milvus 里选度量方式时，如果你用的 embedding 模型输出没有归一化，却选了内积（IP），那检索质量很可能莫名其妙地差。这个坑非常隐蔽，因为代码不报错，只是结果不对。

2.3 为什么“先查向量”是最高效的排查顺序

从工程效率角度看，排查顺序应该遵循“从确定性高、成本低的环节往确定性低、成本高的环节走”。

向量链路里的问题大多是确定性的：模型用错、维度不匹配、度量方式选错、归一化没做，这些都能通过打印中间结果直接验证，改起来也快。而模型生成端的问题往往是概率性的：prompt 措辞、温度参数、上下文长度，调起来费时且效果不稳定。

所以正确的顺序是：先确认 query 向量和文档向量在同一个空间、度量方式匹配、召回结果确实相关，再去怀疑模型。把这条链路走通，你会发现大部分“答非所问”在向量层就已经暴露了。

3. 向量化环节：最容易被忽视的第一道关

3.1 embedding 模型选型的三个硬指标

选 embedding 模型不能只看排行榜，得结合你的实际场景。我一般看三个指标：

语言匹配度。如果你的知识库是中文为主，就必须选中文语料训练充分的模型。很多英文模型在中文上的语义区分度很差，相近的中文句子会被映射到几乎相同的向量位置，检索时根本分不开。

维度与性能的平衡。维度越高表达能力越强，但存储和计算成本也越高。768 维和 1024 维在多数场景下够用，1536 维以上要谨慎评估是否真的需要。我实测过一个场景，把维度从 1536 降到 768，检索准确率只掉了不到 2%，但索引体积和检索延迟都明显改善。

最大输入长度。这个参数决定了你的切分策略。如果模型最大只支持 512 token，你却把 2000 字的段落直接塞进去，超出部分会被截断，语义就残缺了。

3.2 切分策略：语义完整比长度均匀更重要

切分是 RAG 里最考验经验的一环。新手常犯的错是按固定字符数硬切，比如每 500 字切一段。这样切出来的片段经常在句子中间断开，语义不完整，向量化后表达的意思就偏了。

我的做法是按语义边界切分：优先在段落、标题、列表项这些自然边界处断开，再控制单段长度。如果一段太长，就在句子边界处二次切分。这样每个片段都是一个相对完整的语义单元，向量质量明显更好。

还有一个细节是重叠区。相邻片段之间保留 10%-20% 的重叠内容，可以避免关键信息正好落在切分点上被割裂。这个比例不是拍脑袋，是因为语义的连续性往往跨越边界，适当重叠能让检索时更容易命中完整上下文。

提示：切分长度要和 embedding 模型的最大输入长度对齐。如果模型支持 512 token，单段控制在 300-400 token 比较稳妥，留出余量避免截断。

3.3 归一化：一个不做就出事的预处理

前面提到点积受向量长度影响，解决办法就是在存入向量库之前做 L2 归一化，把所有向量长度统一成 1。这样无论你用余弦还是内积，结果都一致，省去了很多心智负担。

归一化的代码很简单，但很多人会漏掉。我建议把它做成向量化流程里的固定步骤，而不是依赖某个库的默认行为。因为不同 embedding 库的默认行为不一样，有的自动归一化，有的不归一化，混用就会出问题。

import numpy as np def normalize(vec): norm = np.linalg.norm(vec) if norm == 0: return vec return vec / norm

这段代码看着简单，但它能帮你排除掉一整类“检索结果莫名其妙”的问题。我现在的习惯是，只要向量入库，先过一遍归一化，心里踏实。

4. Milvus 索引与度量：配置错了结果全歪

4.1 度量方式怎么选才不踩坑

Milvus 支持多种度量方式，常用的有 COSINE、IP（内积）、L2（欧氏距离）。选哪个不是随便挑的，得跟你的 embedding 模型和归一化策略配套。

如果向量已经做了 L2 归一化，那 COSINE 和 IP 结果等价，选哪个都行。如果没归一化，就必须用 COSINE，因为只有它不受长度影响。L2 一般用在图像特征这类场景，文本检索里相对少用。

我见过有人用未归一化的向量配 IP，检索结果时好时坏，排查了半天才发现是度量方式的问题。改成 COSINE 之后立刻正常。这种问题不打印向量范数是看不出来的。

4.2 索引类型对召回率的影响

Milvus 的索引类型直接决定了检索速度和召回率的平衡。常用的几种：

FLAT是暴力检索，召回率 100%，但数据量大时慢得没法用。适合小数据集或者做效果验证的基准。

IVF_FLAT通过聚类把向量分桶，检索时只查部分桶，速度快但会损失一点召回率。关键是 nlist 参数，桶分得越细召回越高但越慢。

HNSW用图结构组织向量，检索快且召回率高，是目前综合表现最好的选择。代价是内存占用大，构建索引慢。

IVF_PQ在 IVF 基础上做了乘积量化压缩，内存占用极小，适合超大规模数据，但召回率损失明显。

我的经验是，如果数据量在百万级以内，直接上 HNSW，省心。数据量再大再考虑 IVF 系列。

4.3 在 Mac 上用 Docker 跑 Milvus Standalone

本地开发调试，用 Docker 跑 Milvus standalone 模式最方便。standalone 是单机版，包含了所有必要组件，适合开发和中小规模部署。

# 下载官方 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 # 查看状态 docker compose ps

启动后默认端口是 19530。Mac 上要注意 Docker 分配的内存，Milvus 至少需要 4GB，建议在 Docker Desktop 里把内存调到 8GB 以上，否则容易启动失败或者检索时卡顿。

连接测试：

from pymilvus import connections, Collection connections.connect(host="localhost", port="19530") print("连接成功")

如果连不上，先检查容器是否正常启动，再看端口有没有被占用。Mac 上偶尔会遇到端口冲突，换个端口映射就行。

5. LangGraph 编排下的检索节点调试

5.1 把检索做成独立可观测的节点

用 LangGraph 编排 RAG 流程的好处是，每个环节都是显式的节点，方便单独调试。我一般会把检索拆成两个节点：一个负责 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_field="embedding", param={"metric_type": "COSINE", "params": {"ef": 64}}, limit=5, output_fields=["text"] ) return {"docs": [hit.entity.get("text") for hit in results[0]]}

把这两个节点分开，调试时就能分别打印 query 向量和召回结果，一眼看出问题在哪。

5.2 在节点里埋入可观测信息

光有节点还不够，得让节点输出足够的信息供排查。我习惯在每个关键节点里记录：输入是什么、输出是什么、耗时多少、召回的相似度分数分布。

相似度分数特别有用。如果 Top-5 的分数都在 0.3 以下，说明检索质量很差，要么是向量化有问题，要么是知识库里根本没有相关内容。如果分数都在 0.9 以上但答案还是不对，那可能是召回了高度相似但实际不相关的内容，需要检查切分和去重。

def retrieve_with_debug(state): vector = state["query_vector"] results = collection.search(...) scores = [hit.score for hit in results[0]] print(f"召回分数: {scores}") print(f"最高分: {max(scores):.4f}, 最低分: {min(scores):.4f}") return {"docs": [...], "scores": scores}

这个打印看着土，但排查问题时比任何可视化工具都直接。

5.3 用 LLM as Judge 做检索质量评估

当检索结果肉眼不好判断时，可以引入 LLM as Judge，让模型来判断召回的内容跟 query 是否相关。这不是用来替代人工，而是快速筛出明显有问题的 case。

做法是把 query 和召回的每个片段拼成一个判断 prompt，让模型输出“相关/不相关”。批量跑一批测试 query，统计相关率。如果相关率低于 70%，基本可以确定检索链路有问题，先别动生成端。

注意：LLM as Judge 本身也有偏差，只适合做粗筛，最终判断还是要靠人工抽查。别把它当成绝对标准。

6. 常见问题排查速查表

6.1 检索结果完全不相关

这是最典型的问题。排查顺序：

1. 确认 query 和文档用的是同一个 embedding 模型，打印两者的向量维度对比
2. 检查向量是否归一化，打印向量范数
3. 确认 Milvus 的度量方式跟归一化策略匹配
4. 用一条已知答案的 query 做测试，看能否召回对应文档

如果这四步都正常，再去看切分是否合理。我遇到过切分把关键信息切碎导致召不回的情况，把切分粒度调大就好了。

6.2 检索结果相关但答案不对

这种情况说明检索没问题，问题在生成端或者上下文组织。检查：

• 召回的片段是否包含了回答问题所需的完整信息
• prompt 里是否明确要求模型基于给定上下文回答
• 上下文是否太长导致关键信息被淹没

有时候召回 10 个片段，关键信息只在第 8 个里，模型注意力被前面的噪声带偏了。这时候减少 Top-K 或者做重排序（rerank）会有帮助。

6.3 相似度分数普遍偏低

如果所有 query 的召回分数都低，可能是：

• embedding 模型不适合你的领域，换一个领域适配更好的
• 知识库内容跟 query 的表达方式差异太大，考虑做 query 改写
• 向量维度太低，表达能力不足

6.4 排查速查表

7. 几个我踩过的坑和实操心得

第一个坑是混用 embedding 模型。早期项目里文档入库用了一个模型，后来换了个更新的模型做 query 向量化，忘了重新索引文档，结果检索质量断崖式下跌。教训是：换 embedding 模型必须全量重建索引，没有例外。

第二个坑是忽略向量维度对齐。有次从 768 维模型换到 1024 维，Milvus 的 collection 还是按 768 维建的，插入时报错才发现。建 collection 时一定要把维度写死并跟模型对齐，别用动态维度。

第三个心得是建立检索质量的回归测试集。准备 50-100 条带标准答案的 query，每次改动检索链路后跑一遍，看召回率变化。这比凭感觉判断靠谱得多。我现在的项目里，这个测试集是必建的，改任何检索相关配置前先跑基线。

第四个心得是别急着上复杂方案。很多人一上来就搞多路召回、重排序、query 改写，结果基础链路都没调通。我的建议是先把单路向量检索调到满意，再考虑加复杂度。基础不牢，加再多组件也是白搭。

最后一个体会是关于排查心态。RAG 出问题时，人容易焦虑，想快速换个模型试试。但换模型是成本最高的操作，而且往往治标不治本。养成先查向量链路的习惯，把确定性的问题先排除掉，剩下的才是真正需要模型层面解决的。这个顺序理顺了，排查效率能提升好几倍。

这套排查方法我在多个项目里验证过，从中文知识库到多语言场景都适用。核心就一句话：向量层的问题用向量的方式查，别让模型背不该背的锅。