34 篇博文 含有标签「retrieval」

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

在这两种解读之间，隐藏着一个随时可能发生的生产事故。支持智能体告诉客户“我们没有你的订单记录”，因为同步延迟导致写入只读副本的时间推迟了 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 流水线与能在生产环境中稳健运行的系统的关键。

你花了数周时间调优嵌入模型。检索精度看起来不错。分块大小、重叠、元数据过滤器——一切都已调整到位。然而用户不断反映，系统"忽略"了它明明能访问的信息。相关段落每次都出现在 top-5 检索结果中，模型就是不用它。

罪魁祸首往往是位置偏差（position bias）：语言模型倾向于过度依赖上下文窗口开头和结尾的信息，而对中间内容的注意力显著不足。在受控实验中，将相关段落从 20 篇文档上下文中的第 1 位移至第 10 位，准确率会下降 30-40 个百分点。你的检索器找到了正确的内容，但排序毁了它。

大多数 RAG 流水线都有一个隐形的准确率天花板，而构建它们的工程师甚至不知道它的存在。你调整分块策略、升级嵌入模型、更换向量数据库——但系统对于某些顽固的查询，依然返回看似合理但微妙错误的文档。检索看起来很合理。LLM 听起来很自信。但下游准确率已悄然进入平台期，无论进行多少提示工程（prompt engineering）都无法突破。

这个差距几乎总能追溯到同一个缺失的部分：Reranker（重排序器）。具体来说，是在第二个检索阶段缺少了交叉编码器（cross-encoder）。这一层在技术上是可选的，但在实践中跳过它的代价很高，而且在大多数 RAG 流水线所遵循的经典“嵌入、索引、查询”教程中，它往往被系统性地忽略了。

当 RAG 系统返回错误答案时，事后分析几乎总是聚焦于同一批嫌疑人：检索查询、相似度阈值、重排序器、提示词。团队会花好几天调整这些组件，而真正的原因却静静地躺在索引流水线里无人触碰。失败早在几周前就已发生——那时有人拍板决定了分块大小。

大多数 RAG 质量问题是架构性的，而非运营性的。它们源于索引时做出的决策，这些决策会悄然塑造 LLM 最终能看到的内容。等到用户投诉时，检索系统正在做它被设计好的事——只是那个设计本身就是错的。

你的RAG管道检索了前10个文档，但LLM的答案依然有误。你将检索数量增加到50，结果还是错的。令人沮丧的是：正确的文档一直都在向量数据库里——只是排在第23位。这不是召回率的问题，而是排序的问题，而余弦相似度正是罪魁祸首。

向量搜索在找到语义相邻内容方面做得不错，但"语义相邻"和"对这个具体查询最有用"并不是一回事。余弦相似度衡量的是嵌入空间中两个向量之间的夹角，而这个夹角只能捕捉粗粒度的主题接近度。它无法捕捉查询中特定词语与文档中特定词语之间的细粒度交互——"如何防止缓冲区溢出"与"缓冲区溢出利用技术"在向量层面差异微妙，但对于你的检索系统来说却至关重要。

大多数团队发现自己需要 GraphRAG 时往往已经晚了六个月——在他们已经向用户解释了为什么 AI 搞错了关系、为什么它混淆了两个具有相似嵌入（embeddings）的实体，或者为什么它言之凿凿地引用了一份与实际答案相矛盾的文档之后。Vector RAG 在其擅长的领域确实表现出色。问题在于，团队把它当成了全能选手，并在底层架构已经达到数学上限时，仍不断堆砌检索补丁。

截至 2025 年，只有不到 15% 的企业在生产环境中部署了基于图的检索。这并不是因为技术不成熟。而是因为纯向量 RAG 的失败信号非常微妙：系统在运行，LLM 在响应，只有经过仔细检查才会发现，检索到的上下文虽然看似合理，但却是错误的。

你的 RAG 系统评估看起来还不错。NDCG 尚可接受，演示也能运行。但有一类故障是单一指标评估无法捕捉的：那些你的检索器从未接近过的查询——持续如此，因为你的整个嵌入空间从一开始就没有能力处理它们。

这就是检索单一化。一个嵌入模型、一种相似度度量、一条检索路径——因此也是一套系统性盲点，这些盲点看起来像模型错误、幻觉或用户困惑，直到你真正检查检索层才会发现真相。

解决方法不是更大的模型或更多数据，而是理解不同的查询结构需要不同的检索机制，并构建一个能够停止将一切都路由到同一漏斗中的系统。

大多数团队在起步时都会选择向量数据库 (Vector Store)，因为它们上手简单，但随后会发现即使无论如何调整分块大小 (Chunk size) 或嵌入模型 (Embedding model)，某些类型的查询也完全无法生效。这并非调优问题 —— 而是架构上的不匹配。向量相似度与图遍历是两种根本不同的检索机制，随着查询复杂度的增加，这种差异会变得愈发关键。

这不是一篇推荐“两者兼顾”的文章。在实际应用中需要进行真正的权衡，选择失误会耗费数月的工程时间。以下是这种选择在实践中的真实面貌。