61 篇博文 含有标签「retrieval」

大多数团队在调优 RAG 系统时关注两个杠杆：分块策略和嵌入模型选择。当检索质量下降时，他们重新分块；当召回率数据不好看时，他们升级嵌入模型。这两步都合理——但它们在优化流水线的中间环节，却让最高杠杆点一直没有触及。

用户的查询几乎从来不是向量检索的理想形式。它简短、口语化、模糊，或者假设了索引中并不存在的上下文。无论你的嵌入有多好，如果你用一个表述糟糕的查询来搜索，检索结果就会很差。解决方法不在下游——而是在查询命中向量索引之前对其进行变换。

向生产环境中的 RAG 系统提一个你的语料库无法回答的问题，看看会发生什么。它很少会说“我没有那方面的信息”。相反，它会检索出五个排名最高的片段——由于没有更好的匹配项，这五个片段其实是五个最不糟糕的无关内容——然后将它们交给模型，并配上类似“请使用以下上下文回答用户的问题”的提示词。模型在被训练为要乐于助人的同时，手中握着与主题有几分相似的文本，于是产生了一个自信的回答。这个答案的错误在架构上是不可见的：检索成功了，生成也成功了，每个片段都在检索到的文档中有据可查，但用户却被误导了。

这就是检索空洞问题。它不是任何单一层级的 bug。它是一个流水线的涌现行为，该流水线将 “top-k” 视为一种契约，却从不询问 top-k 的质量如何。ICLR 2025 上发表的一项关于“充分上下文”（sufficient context）的研究量化了这一影响：当 Gemma 获得充分的上下文时，其在事实性问答上的幻觉率约为 10%。当它收到的上下文不足时——即检索到的文档实际上并不包含答案——该比率会飙升至 66%。向描述不足的查询中添加检索到的文档会让模型错得更自信，而不是更少。

你的 RAG 系统正在向你撒谎。当用户询问当前价格、有效安全策略或上季度发布的功能时，检索管道返回的是索引中语义最相似的文档——而不是最新鲜的文档。一份 18 个月前的定价页面和今天早上的更新，对余弦相似度来说看起来毫无差异。标准 RAG 架构中没有任何组件能判断所检索的文档是否仍然正确。

这就是过时检索，它的失败方式与幻觉截然不同。模型没有凭空捏造任何内容，它准确地概括了真实存在过的内容。标准评估指标——忠实度、有根据性、上下文精确度——全部通过。系统对一个几个月前就已失效的事实表现出充分的自信。

你的 RAG 管道在回答单一事实问题时表现出色。问它"我们的退款政策是什么？"它每次都能准确回答。但如果问"哪些企业版客户在合同续签后 30 天内提交了关于计费 API 的工单？"它就无能为力了。答案确实存在于你的数据中——分散在三种不同的文档类型中，通过余弦相似度无法捕捉的关系连接在一起。

这就是多跳推理问题，也是越来越多的生产级 RAG 团队在向量检索管道上嫁接知识图谱的原因。不是因为图谱又流行了，而是因为他们遇到了一个具体的准确率天花板——无论怎么调整分块大小或重新排序都无法突破。

当一个团队在系统提示开头硬编码三个示例输入输出对时，这看起来是合理的工程决策。这些示例经过人工验证，格式统一，模型行为也可预期地有所改善。六个月后，同样这三个示例还在那里——能很好地覆盖 30% 的输入查询，其余的则是敷衍了事，而且没有人去统计到底哪些是哪些。

静态少样本提示是生产 LLM 系统中最被忽视的性能黑洞。另一种方案——根据查询的语义相似度按需选择示例——在各类任务中的质量表现持续优于固定示例，差距往往达到两位数百分比。但这个迁移过程既不免费，也不无风险，而且动态方案的失败模式比静态方案更难察觉。

本文将介绍研究数据的实际结论、生产中检索栈的工作方式、大多数从业者忽视的排序和投毒风险，以及静态示例应该获胜的具体场景。

BM25 发表于 1994 年，其数学原理简单到可以写在白板上。然而在 2025 年的生产检索基准测试中，它在真实世界查询的相当一部分场景中，依然超越了数十亿参数规模的稠密嵌入模型。那些在部署纯向量检索后才发现这一问题的团队，往往是以最糟糕的方式发现的：用户反馈幻觉，而他们在评估集中却无法复现——因为评估集是从那些已经能正常工作的查询中构建的。

这是检索领域的抽样偏差。稠密检索在特定且可预测的查询形式上会失败。这种失败是无声的——大语言模型仍会从检索到的任何片段中生成流畅、自信的答案。没有错误日志，没有延迟异常，只是对查询产品 SKU、错误码、API 名称或任何词汇特定而非语义通用内容的用户，悄悄给出了错误的回答。

解决方案是混合检索。但"混合检索"作为一个工程决策，本身定义不够充分。本文将介绍实际的失败模式、如何正确融合检索信号、重排序层的位置，以及——最关键的——如何在用户发现之前，找到当前流水线正在悄悄失败的查询类型。

大多数团队在意识到他们的语料库中很大一部分内容——产品截图、演示录制、架构图、客服通话录音——对于纯文本检索系统是不可见的之后，会将多模态 RAG 加入到他们的路线图中。在生产环境中令他们感到惊讶的并不是嵌入模型的选择或向量数据库的选择，而是模态之间的差距：同一个语义概念，当被编码为图像和句子时，会落在向量空间中完全不同的区域，而搜索引擎根本不知道它们是相关的。

这篇文章涵盖了多模态嵌入对齐的技术原理、在大规模场景下真正有效的跨模态重排序策略、相对于纯文本 RAG 的成本和延迟状况，以及多模态检索特有的失效模式。

大多数 RAG 教程都将分块（chunking）视为一个注脚：将你的文档切分为 512 个 token 的块，对它们进行嵌入（embed），存储在向量数据库中，然后继续研究有趣的部分。这在演示示例（如维基百科文章、干净的 markdown 文档、短 PDF）中表现良好。但在生产环境中，它会分崩离析。

最近一项将 RAG 应用于临床决策支持的研究发现，在 30 个临床问题中，固定大小的基准方案仅实现了 13% 的完全准确率。在同一语料库上采用自适应分块方法：完全准确率为 50% (p=0.001)。文档是相同的。LLM 是相同的。只有分块方式改变了。这种差距不是微调问题，也不是提示词工程问题。它是大多数团队在切分文档方式上的结构性失败。

你的向量搜索在基准测试中表现出色，但用户依然感到沮丧。

失败模式非常微妙：用户询问“我们的哪些供应商卷入了影响与 Martinez 账户所在地区相同客户的事件？”你的嵌入模型检索到了事故记录。它们检索到了供应商合同。它们检索到了客户账户。但它们是以相互孤立的文档形式检索出来的，LLM 必须在上下文中理清这些关系——而这些关系横跨了实体图（entity graph）中的三个跳数（hops）。当每个查询涉及五个或更多实体时，如果没有关系结构，准确性会降至接近零。而有了关系结构，性能则保持稳定。

这正是知识图谱增强检索——GraphRAG——旨在解决的瓶颈。它不是向量搜索的直接替代品。它是一个具有不同成本结构、不同失败模式、以及在特定类别查询中具有压倒性优势的不同系统。

当 Gemini 1.5 Pro 发布并具备 1M token 的上下文窗口时，一波工程师宣布 RAG 已死。这种论点看似无懈可击：既然你可以把整个知识库直接丢进提示词（Prompt）中让模型自己去处理，为什么还要构建一个包含分块器（chunkers）、嵌入（embeddings）、向量数据库和重排序器（re-rankers）的检索流水线呢？

这种论点在生产负载下会分崩离析。Gemini 1.5 Pro 在“大海捞针”（needle in a haystack）基准测试（即隐藏在文档中的单个事实）中实现了 99.7% 的召回率。但在现实的多事实检索场景中，平均召回率在 60% 左右。这 40% 的遗漏率并非基准测试的偏差；而是你的系统在静默状态下未能向用户展示的事实。而且，一个 1M token 请求的延迟比 RAG 流水线慢 30–60 倍，而单次查询成本约为其 1,250 倍。

长上下文模型是强大的工具。它们只是不适合大多数生产环境的检索工作负载。

大多数 RAG 系统在部署时都配备了向量数据库、几千个 embeddings，并假设语义相似度已经足够接近正确性。事实并非如此。这种“语义相似”与“实际正确”之间的差距，正是 73% 的 RAG 系统在生产环境中失败的原因，而且几乎所有这些失败都发生在检索阶段 —— 甚至在 LLM 生成任何文字之前。

“对文档进行嵌入、使用余弦相似度查询、将 top-k 传递给 LLM”的 standard playbook 在演示中有效，是因为演示查询是经过设计的。生产环境的查询则不然。用户搜索的是产品 ID、发票号码、监管代码、拼错的竞争对手名称，以及单个 embedding 向量在几何上无法满足的多重约束问题。稠密向量搜索并没有错 —— 只是它并不完整。构建一个在生产环境中真正起作用的检索栈，需要理解其中的原因，并层层加入能够弥补这些缺陷的组件。

大多数 Agent 演示仅使用 5 个工具，而生产系统通常拥有 50 个。这两个数字之间的差距，正是大多数 Agent 架构分崩离析的地方。

当你给一个 LLM 4 个工具和一个明确的任务时，它通常能选对。但当你给它 50 个工具时，更有趣的事情发生了：准确率大幅下降，Token 成本激增，且失败模式通常表现为模型幻觉出一个工具调用，而不是承认它不知道该用哪一个。来自 Berkeley Function Calling Leaderboard 的研究发现，在跨多个领域的日历调度任务中，当工具数量从 4 个扩展到 51 个时，准确率从 43% 骤降至仅 2%。这绝不是一个平滑的性能退化曲线。