44 篇博文 含有标签「retrieval」

当检索质量回退（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)，某些类型的查询也完全无法生效。这并非调优问题 —— 而是架构上的不匹配。向量相似度与图遍历是两种根本不同的检索机制，随着查询复杂度的增加，这种差异会变得愈发关键。

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

一个合规承包商构建了一个 RAG 系统，旨在回答有关 400 页政策文档的问题。系统通过了内部 QA，针对单主题查询的检索表现正确。然而系统上线后，在处理涉及例外条款的任何问题时，它开始返回语气自信、结构严谨但错误百出的答案。

调试过程似曾相识：更换嵌入模型、调整相似度阈值、试验分块大小、添加重排序器。几周过去了，改进微乎其微。真正的症结在于，一个关键的例外条款在段落边界处被分割到了两个分块（chunks）中 —— 这并非由于分块策略，而是因为 PDF 提取器在误读排版时，悄无声息地将该段落一分为二。孤立来看，这两个分块都无法检索或解析。系统无法通过幻觉得到正确答案，因为正确的信息从未完整地进入索引。

这就是“提取天花板”：即当下游优化再多也无法弥补受损或缺失的输入数据时，系统所面临的瓶颈。

大多数团队在构建 RAG 流水线时都会选择向量嵌入（vector embeddings）。这是一个显而易见的默认选择：嵌入文档、嵌入查询、寻找最近邻，然后将结果输入给 LLM。在演示（demo）中它的表现还不错。但当部署到合规团队或科学文献语料库时，准确率就会断崖式下跌。不是逐渐下降，而是突然暴跌。在涉及五个或更多实体的查询中，向量 RAG 在企业分析基准测试中的准确率降至零。不是 50%，也不是 20%，而是零。

这不仅是一个配置问题，而是架构上的不匹配。向量检索将文档视为语义空间中的点。知识图谱（knowledge graphs）则将它们视为关系结构中的节点。当你的查询需要遍历关系——而不仅仅是寻找相似内容时，检索架构的拓扑结构（topology）决定了你是否能得到正确答案。