65 篇博文 含有标签「retrieval」

这是一个在生产环境中比任何人愿意承认的更频繁出现的场景。用户询问 AI 助手当前的利率政策。你的 RAG 系统获取了一份高度相关的美联储文件——语义相似度评分高达 0.91——模型自信地返回了答案。但这个答案已经过时六个月了。RAG 索引上次刷新是在十月份。参数化知识则更为陈旧。一次实时 API 调用本可在 400 毫秒内返回正确的当前数据，但没有人在路由逻辑中加入这样的判断：这个问题的答案允许有多旧？

这种失败不是检索失败，而是时序路由失败。系统在其技术栈的某处确实能够获取正确信息，只是将查询发送到了错误的层级。

一个用户问你的助手，“这季度我们的退款政策有什么变化？”系统返回了一个当前退款政策的、格式良好的自信总结。用户点点头，关闭聊天，并根据一个与他们提出的问题完全无关的信息采取行动。你的评测套件（eval suite）没有捕捉到这一点。你的忠实度指标（faithfulness metric）没有标记它。检索看起来很完美——它返回了高度相关的分块（chunks）。合成看起来也很完美——它引用了它使用的每个分块。唯一的问题是，问题是关于 变化 的，而你的索引没有变化的概念。

这是向量相似度检索无法通过调优修复的失败模式。同一文档的两个版本具有几乎相同的嵌入（embeddings）——这就是好的嵌入所 做 的，它们将语义等效的文本折叠到同一个邻域中。因此，当你问“什么改了”时，检索器返回其中一个版本，LLM 总结该版本，而答案在沉默中成为了“什么都没变”的幻觉。用户无法察觉。你的评测集可能也无法察觉，因为你的评测集是围绕“什么是 X”的问题构建的，而不是“现在 X 有什么不同”。

我建议的一个团队花了两个月时间在其 RAG 流水中不断更换 LLM。从 Claude 到 GPT，再到 Gemini，最后又换了回来。每一次更换都能让幻觉率降低几个百分点，但从未在关键指标上有所进展：他们的支持代理找到正确知识库文章的概率仍然不到 60%。他们调优的层级错了。检索器返回的是无关的文本块，而无论 LLM 多聪明，都无法根据检索器从未呈现过的文档来回答问题。

嵌入模型是 RAG 系统中决定 LLM 甚至“被允许”看到什么的部分。它描绘了语料库的几何结构——即在向量空间中，哪些文档会落在哪些查询附近。一旦这种几何结构出错，LLM 就只是一个对错误上下文侃侃而谈的自信叙述者。换一个更聪明的 LLM 通常只会让回答更显“文采”，而不会让回答更准确。

一个典型的 RAG 流水线包含两个模型，而不是一个。检索器从向量数据库中提取 50 到 100 个候选文档，而重排序器（reranker）——无论是交叉编码器（cross-encoder）、LLM-as-judge 提示词还是混合方案——都会对这些候选文档进行重新评分，并将前 5 个结果交给回答模型。你的评估套件测量端到端的回答质量，测量检索器的 recall@k，但它并不测量重排序器。因此，当重排序器发生隐性偏移（drift）时，仪表盘上显示的“回答质量下降了 4 个点”却没有任何因果线索，团队会花费三天时间去调试一个根本不是问题的提示词。

重排序器是那个隐性的第二个模型。它介于检索器和生成器之间，拥有自己的评分分布、自己的提示词（如果是基于 LLM）或自己的权重（如果是交叉编码器），并且它可以独立于其他任何组件发生性能退化（regress）。大多数团队从未单独对它进行评分。他们编写的评估套件将流水线视为一个具有长上下文窗口的单一模型，而实际上它是两个串联的模型，且其中间接口并不属于任何一个团队。

这种模式太熟悉了，以至于被视而不见。模型幻觉出了一个事实，于是团队增加了一个检索步骤。三周后，模型从不断增加的工具库中选错了工具，于是他们在工具目录上增加了一个检索步骤。模型的回答感觉太笼统，于是他们在过去的高质量回答上增加了一个检索步骤。一个季度过去了，系统现在变成了一堆检索器拼接在一起的提示词，而本质上，最初的问题依然存在。

改变的不是失败率 —— 而是失败模式的名称。“模型出错了”变成了“检索未命中”，这听起来更易处理，但事实并非如此。评估套件的分数更高了，因为从构造上讲，检索到的上下文对于测试集来说是分布内（in-distribution）的。生产环境的情况则截然不同，但到那时，架构已经有了三个检索层，每一层都有自己的嵌入模型、索引刷新频率和值班轮换，而且没有人想成为那个提议拆除它们的工程师。

这就是检索膨胀（retrieval sprawl）。这是一种架构上的分心：一种将难题（提示词设计、模型能力、模糊的规范）转移到更舒适的问题（信息检索工程）上，而实际上没有解决任何问题的方式。

你团队选择的向量索引是在一个生产环境中根本不存在的工作负载上进行基准测试的。每一个公开的 ANN（近似最近邻）基准测试 —— VIBE、ann-benchmarks、数据库厂商落地页上的对比表 —— 都是从语料库中均匀采样查询的，因此每个邻居查找的成本大致相同，每个分片承受的负载也大致相等。真实的检索流量并非如此。它呈现出齐普夫分布（Zipfian）：极小部分的查询（今日新闻、趋势产品、循环的支持意图、客服团队整天收到的那几百个问题）命中的一小部分嵌入，其频率比中位数高出百倍。基准测试显示 HNSW 在 50ms p99 下的召回率为 0.97。而生产环境则显示一个分片正在熔化，其余的却闲得发慌。

这种不匹配并不是调优问题。而是向量检索继承了所有其他数据库工作负载的访问倾斜特性，而该领域标准化的索引在设计时并未考虑到这种特性。你的 KV 存储免费获得的缓存层 —— 预热你最常读取的行的操作系统页面缓存（OS page cache），针对热点 Key 的 LRU —— 在 ANN 中并不存在，因为图是按图结构顺序遍历的，而不是按访问顺序。热门嵌入在内存中依然是“冷的”，因为搜索算法的遍历模式在页面缓存看来是随机的，而你的“热门”集群位于单个分片上，其 CPU 运行火热，而集群的其他部分却在闲置。

当 RAG 系统回答错误时，大多数团队的第一反应是归咎于编码器（encoder）。更换更大的嵌入模型（embedding model）。尝试针对特定领域微调过的模型。增加维度。三个迭代周期（sprint）后，召回率曲线只提升了几个百分点，而用户的投诉看起来还是老样子。

诊断错了。大多数检索失败并非嵌入失败。它们是查询形状（query-shape）失败——在编码器运行之前就存在的词汇不匹配，无论如何调整向量都无法修复。

用户输入“如何取消”。相关的文档标题却是“订阅生命周期管理”，并使用了“终止”、“计费周期结束”和“服务停用”等词汇。世界上没有任何编码器能靠词汇运气将这两个字符串拉入同一个邻域。余弦相似度（cosine similarity）的差距是真实存在的，它存在于输入中，而非模型中。位于检索之前的查询重写层是大多数流水线跳过的步骤，随后他们却要花一个季度的时间试图在下游进行补偿。

智能体对话记录中最危险的一句话不是幻觉。而是四个冷静的词：“我没有找到。”智能体听起来在认知上表现出谦逊。听起来像是完成了尽职调查。对于任何下游读者或调用者来说，这听起来完全像是一个事实。然而，这句话并没有提供关于该事物是否存在的信息。它只提供了关于特定工具在使用特定查询、咨询特定索引（而智能体恰好在那个时刻有权访问该索引）时发生了什么的信息。

在这两种解读之间，隐藏着一个随时可能发生的生产事故。支持智能体告诉客户“我们没有你的订单记录”，因为同步延迟导致写入只读副本的时间推迟了 90 秒。编码智能体声明“该模块没有测试”，因为它搜索了一个不包含测试文件夹的目录。合规智能体回答“档案中没有先前的违规记录”，因为审计索引尚未摄取上周的报告。在每种情况下，智能体的输出在语法上都是一种否定，但在认知上，它只是一个被重新表述为断言的“耸肩”。

从任何成熟的 RAG 系统中提取一周的检索日志，并按分块（chunks）被返回的频率进行排序。其分布形态几乎总是相同的：一小部分分块出现在数千次查询中，而语料库中的绝大多数内容仅出现几次，甚至从未出现过。系统没有故障。它正在精准地执行索引构建时的预期功能 —— 而这恰恰是问题所在。

这就是向量检索中的流行度偏差（popularity bias），而且随着语料库的增长，这种情况会变得更加严重。少数分块变成了“引力井”，在互不相关的查询中频频胜出，而长尾内容则悄然消失在 top-k 截断值之下。你的 RAG 系统开始让人感觉“平庸” —— 用户提出具体问题，得到的回答听起来却像是为别人写的一样。等到产品部门开始投诉时，这种分布不均的情况往往已经持续数周了。

当检索质量回退（retrieval quality regression）第一次出现在你的值班频道（on-call channel）时，调试路径几乎总是指向一些令人意外的地方。不是嵌入模型（embedding model），不是重排序器（reranker），也不是提示词（prompt）。罪魁祸首通常是对分块器（chunker）的一行改动——比如更换了分词器、调整了边界规则或步幅（stride）——而这行代码是三个冲刺（sprint）前有人合并进预处理 notebook 的。这次修复没有触及任何生产代码。它在夜间重建了索引。而现在，所有租户的准确率都下降了四个百分点。

分块器就是数据库 Schema。你提取的每个字段、划定的每个边界、选择的每个步幅，都定义了存入向量索引的“行”的形状。修改其中任何一项，你就在改变索引的 Schema。而你系统的其他部分——检索逻辑、重排序特征、评估框架、下游提示词——都依赖于这个索引，并假设它是稳定的。但由于分块器通常存在于 notebook 或一个没人将其视为“基础设施”的小型 Python 模块中，这些改动在上线时往往只被当作配置微调，但其爆炸半径却相当于执行了一次 ALTER TABLE。

大多数关于 RAG 质量的讨论都聚焦在错误的地方。团队在争论嵌入模型的选择、微调检索的 top-K、以及尝试各种提示词模板——然而在数据摄取阶段做出的一个架构决策，却悄然决定了系统能力的上限。这个决策就是分块策略（chunking strategy）：即在索引之前，你如何将文档切分成片段。

一项 2025 年的基准研究发现，分块配置对检索质量的影响，甚至比嵌入模型的选择还要大。然而，团队通常会选择默认配置——通常是 512 个 token 的 RecursiveCharacterTextSplitter——然后花上几个月的时间去思考，为什么他们的检索精度总是差强人意。问题在索引时就已经埋下了。更换模型无法解决这个问题。

向量搜索已成为 RAG 系统的默认检索原语。嵌入你的文档，嵌入查询，查找最近邻 —— 这一过程简单、快速，且对于大多数问题效果惊人。但在生产环境部署中，开发者往往会遇到同样的瓶颈：某些查询尽管相似度得分很高，返回的却是垃圾结果；某些多文档推理任务会无声无息地失败；随着复杂度的增加，某些实体密集型查询会退化为随机噪声。

问题不在于嵌入质量或索引大小，而在于语义相似性对于一大部分检索问题来说是错误的抽象方式。知识图谱并不是向量搜索的替代品 —— 它们解决的是结构完全不同的问题。理解哪些问题属于哪种工具，是区分脆弱的 RAG 流水线与能在生产环境中稳健运行的系统的关键。