141 篇博文 含有标签「rag」

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

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

大多数关于 RAG 安全的讨论都集中在生成层 —— 越狱、系统提示词泄露、输出过滤。从业者花费数周时间在模型端调整护栏，却忽视了为其提供数据的摄入管道。一个令人不安的现实是：你的管道摄入的每一份文档都是一个潜在的指令面。一个 PDF 文件就能覆盖你的系统提示词、窃取用户数据，或在你的日志基础设施没有发现任何异常的情况下操纵决策。

这并非理论推测。在过去的两年里，Microsoft 365 Copilot、Slack AI 和商业 HR 筛选工具都曾通过这种向量被攻击。同样的攻击模式也出现在 arXiv 上的 18 篇学术论文中，研究人员通过嵌入隐藏提示词，使 AI 同行评审系统做出有利于他们的偏向性评价。

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

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

在大多数 RAG 架构中都存在这样一种信念：如果检索返回了正确的区块（chunks），LLM 就会生成正确的答案。团队在嵌入模型选择、混合检索策略和重排序流水线方面投入了巨资。然而，在部署到生产环境三个月后，回答质量悄然下降——这不是因为模型变了，也不是因为查询模式发生了剧变，而是因为底层的语料库腐烂了。

企业级 RAG 的实施失败率约为 40%，而从业者最容易低估的失败模式既不是幻觉，也不是检索召回率低，而是文档质量。一项分析发现，通过引入文档质量评分，一个实施方案在不改变嵌入模型或检索算法的情况下，将搜索准确率从 62% 提高到了 89%。语料库是唯一的变量。语料库一直都是变量。

生产环境中的 LLM 给出了一个错误的答案。一张支持工单到来。你翻查日志，只看到提示词、补全内容和延迟指标——却没有任何信息说明检索系统到底拉取了哪些文档、哪些块进入了上下文窗口，或者模型在综合答案时最依赖的是哪段内容。你只能像做考古一样：重新对一个已经更新过的语料库跑一次查询，祈祷结果还和之前一样，同时不知道问题究竟出在检索、分块、文档本身还是模型推理上。

这就是数据溯源的缺口，而大多数 AI 团队直到掉进去才意识到它的存在。

你的 AI 系统正在自信地回答关于一个已经不存在的世界的问题。不是因为模型坏了，不是因为检索失败了，而是因为每个生产环境的 AI 应用内部都有三个独立的时钟在以不同的速率运转——而没有人把它们同步起来。

这就是三时钟问题：墙上时钟（wall clock）、模型时钟（model clock）和数据时钟（data clock）各自运行在自己的时间线上。当它们发生偏移时，你得到的系统在技术上正常运行，但在实质内容上以错误日志永远无法捕捉的方式出错。

大多数 RAG 架构长得都一样：你的应用从 Postgres 读取数据，将文本发送到嵌入 API，将向量写入 Pinecone 或 Weaviate，并在读取时查询两个系统。你维护着两个数据存储、两套一致性模型、两套备份策略，以及一条同步管道——这条管道总是离让你的向量索引落后源数据数周只差一个边缘情况。

如果数据库自己就能搞定一切呢？这已经不再是假设。PostgreSQL 扩展如 pgvector、pgai 和 pgvectorscale——以及 AlloyDB AI 等托管服务——正在将整个嵌入与检索堆栈折叠进数据库本身。结果不仅仅是减少了活动部件，而是一种根本不同的运维模型：你的向量始终与其所代表的数据保持事务一致。

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

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

传统的标准 LLM 在没有迭代检索的情况下，在多步网络研究基准测试中的得分低于 10%。深度研究代理（Deep research agents）——即在循环中进行搜索、阅读、综合和重新查询的系统 —— 得分则超过 50%。这种五倍的提升解释了为什么每个严肃的 AI 产品团队都在构建此类工具。但这无法解释为什么大多数实现要么在追逐无关的细枝末节时耗费 $15 的账单，要么在两次肤浅的搜索后就宣布胜利。

核心问题不在于构建循环，而在于知道循环何时应该停止。事实证明，这是一个出人意料的深度系统设计挑战，涉及收敛检测（convergence detection）、成本经济学、来源可靠性和多代理协作。

大多数团队把 embedding 生成当作一次性的 ETL 任务：跑一个脚本、填充向量数据库、然后就不管了。这在演示中行得通，在生产环境中却是慢动作式的灾难。你的向量索引不是一个静态的产物——它是一条持续运行的流水线，有自己的故障模式、数据新鲜度保证和运维手册。与主数据库不同的是，它出问题时没有任何异常会被抛出。系统照样返回结果，只是这些结果悄悄地、自信地错了。

如果你在运行一个检索增强生成（RAG）系统、语义搜索功能，或任何依赖 embedding 的产品，你的向量索引值得获得与 PostgreSQL 集群同等的严谨对待。以下是大多数团队在这件事上犯错的原因，以及生产级 embedding 基础设施究竟应该是什么样子。

你的 RAG 流水线返回了措辞自信、格式规整的答案。Embedding 已经过调优，分块大小也经过优化，检索评分看起来很漂亮。然后，用户突然问道："哪些受港口罢工影响的供应商，今季合同也即将到期？"系统却返回了关于港口物流和合同管理的零散片段——各自独立，从未将它们关联起来。这就是多跳推理的鸿沟，也是向量检索悄然失效之处。

这不是调参问题，而是架构层面的缺陷。向量相似度能找到看起来像查询的文档，却无法穿越散落在不同文档中的实体关系。GraphRAG——以知识图谱为后盾的检索增强生成——通过将实体关系提升为一等检索对象来解决这个问题。但将其真正推向生产环境，远比演示视频展示的更加复杂。

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

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

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