65 篇博文 含有标签「retrieval」

RAG 系统中存在一种常见的失败模式，数月内都不会被察觉：你的检索器（retriever）返回了错误的文档，但你的生成器（generator）足够擅长即兴发挥，以至于端到端的质量分数依然保持绿色。你不断调整提示词（prompt）。你升级模型。但都无济于事。这个 Bug 存在于上游三层，而你的指标对其视而不见。

这就是检索器评估反模式（retriever eval antipattern）——将整个 RAG 流水线作为一个整体进行评估，这让生成器吸收并隐藏了检索失败。其结果是，你无法区分是“生成器失败”还是“检索器失败”，从而使得系统性的改进几乎变得不可能。

向量搜索正在吞噬世界。基于嵌入（Embedding）的检索现在为各大电商平台的商品搜索提供动力，驱动着 RAG 系统的检索层，并处于大多数 AI 驱动的搜索重写（search rewrites）的核心。但有一类用户，这些系统一直在默默且持续地令其失望：即“浏览型用户”（browsing user）。这并不是因为嵌入模型不好，而是因为它们被设计用来解决一个完全不同的问题。

语义搜索背后的基本假设是：用户带着一个与其需求相近的查询（query）而来。只要在嵌入空间中优化与该查询的邻近度（proximity），你就赢了。但很大一部分真实用户带来的更像是“好奇心”而非具体的查询——对于他们来说，向量空间中的最近邻（nearest neighbors）恰恰是错误的答案。

大多数构建语义搜索的团队都从 RAG 概念验证出发：对文档分块、生成嵌入向量、存储到向量库、用余弦相似度查询。在演示中效果不错。然后他们把它发布给用户，结果有一半的查询以与检索质量毫无关系的方式失败了。

原因在于 RAG 和面向用户的语义搜索解决的是不同的问题。RAG 在问"给定一个问题，检索上下文供 LLM 回答"。语义搜索在问"给定用户的查询，呈现真正符合其需求的结果"。第二个问题有一层 RAG 基准系统性忽视的复杂性——而这种复杂性几乎完全存在于检索开始之前。

Most RAG 的实现都以同样的方式失败：向量搜索检索到了看起来合理但并非用户真正需要的内容，LLM 用自信的辞令对其进行包装，最终用户得到一个大体正确但细节错误的答案。令人沮丧的是，这种失败模式是隐形的 —— 余弦相似度分数看起来很正常，检索到的片段也提到了正确的主题，但答案仍然是错的，因为问题需要跨关系进行推理，而不仅仅是语义上的接近。

向量嵌入 (Vector embeddings) 擅长一件事：找到听起来 像 你查询内容的文本。这是一种强大的能力，涵盖了极广的生产用例。但当问题取决于实体之间如何 连接（而非它们的描述有多匹配）时，这种方式就会出现可预见的失效。对于这类查询，知识图谱 —— 一种你可以通过 Cypher 或 SPARQL 遍历的属性图 —— 不仅仅是一种优化。它是一种从根本上不同的检索方式，解决的是另一类问题。

大多数团队在调优 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 是相同的。只有分块方式改变了。这种差距不是微调问题，也不是提示词工程问题。它是大多数团队在切分文档方式上的结构性失败。