65 篇博文 含有标签「retrieval」

你花了数周时间调优嵌入模型。检索精度看起来不错。分块大小、重叠、元数据过滤器——一切都已调整到位。然而用户不断反映，系统"忽略"了它明明能访问的信息。相关段落每次都出现在 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）决定了你是否能得到正确答案。

大多数 RAG 实现都以同样的方式开始：启动一个向量数据库，使用一个不错的模型嵌入文档，在查询时运行余弦相似度，然后发布。演示效果看起来很棒。相关性感觉出奇地好。然后你将其部署到生产环境，发现“Error 221”检索到了关于“Error 222”的文档，搜索特定的产品 SKU 会出现语义相似但错误的条目，而添加日期过滤器会导致检索质量大幅下降。

向量搜索是一个真正强大的工具。但在大多数生产环境的检索工作负载中，仅靠它是不够的。在 2025 年，通过 RAG 获胜的团队并不会在稠密嵌入（dense embeddings）和关键词搜索之间做选择——他们会刻意同时使用两者。

这是一个决策框架，用于判断混合检索何时值得增加复杂性，以及如何在不破坏延迟预算的情况下构建每一层。

一个团队为内部文档构建了 RAG 流水线。检索效果看起来不错——相关段落都被召回了。但在生产环境中，用户持续收到过时的答案。深入查看日志后他们发现，模型返回的是训练数据中的事实，而非它被给予的文档内容。检索成功了，但模型就是没用上它。

这就是知识污染问题：模型的参数记忆——训练期间编码进权重的知识——压制了检索到的上下文。这种失败悄无声息、表现自信，也是生产环境 RAG 系统中最常见的故障模式之一。

你的 RAG 系统在上线时运行良好。三个月后，它在三分之一的用户查询中自信地给出了错误答案——而你的追踪日志显示一切正常。检索器在抓取文档，模型在生成回复，整个流水线看起来健康运转。问题是不可见的：向量存储中的每个向量依然有相似度分数，但其中一半已经指向了不再存在的事实。

这就是语料库衰减。它不会抛出异常，不会触发告警，而是在后台悄无声息地积累。等你通过用户投诉或质量下滑察觉到时，你的向量存储已经变成了一个负担。