171 篇博文 含有标签「rag」

大多数 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 名称或任何词汇特定而非语义通用内容的用户，悄悄给出了错误的回答。

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

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

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

一家金融科技团队花了三个月时间，根据其内部合规文档（数千份监管 PDF、政策更新和程序指南）对模型进行了微调。结果差强人意。模型仍然会对具体的规则编号产生幻觉。它忘记了最近的政策变化。而唯一真正重要的指标（即顾问是否足够信任它的答案从而停止反复核对）几乎没有变化。两周后，另一个团队在同样的文档语料库上构建了一个 RAG 流水线。顾问们在一周内就开始信任它了。

微调团队并没有犯技术错误。他们犯了一个定义性错误：他们试图用一种行为修改工具来解决知识检索问题。

一个客户服务智能体知道用户偏好在早晨送货。它还知道用户的主要地址在西雅图。但它无法理解的是，西雅图的地址是一个仅在工作日使用的办公地址，而且由于用户三个月前提到的一项大楼限制，早晨送货窗口期在周一并不适用。每个事实都可以被单独检索，但它们之间的关系却不能。

这就是在基于扁平向量库（flat vector stores）运行的生产级智能体中常见的故障模式。每一条信息都像是一个漂浮在高维空间中的嵌入（embedding）。相似性搜索检索与查询匹配的事实，但它无法恢复事实之间的结构化连接——即在组合中赋予它们意义的“边”（edges）。

大多数智能体记忆架构是围绕向量数据库构建的，因为它们速度快、设置简单，且适用于大多数检索任务。这些失败案例非常微妙，以至于在有人注意到这种模式之前，它们往往已经出现在生产环境中了。

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

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

大多数构建 RAG 系统的团队认为他们只有两种失败模式：检索未能找到相关文档，或者 LLM 在拥有文档的情况下产生了幻觉。第一种模式被强迫症般地衡量着 —— Recall@K、MRR、NDCG。第二种模式则被视为模型本身的问题。然而，这两种定义都不完整。

存在第三种介于两者之间的失败模式：检索成功（相关文档排在 Top-K 中），但检索到的上下文实际上并不包含足以正确回答问题的足够信息。模型变得非常自信，生成一个看似合理的答案，但结果却是错误的。对包括 GPT-4o、Gemini 1.5 Pro 和 Claude 3.5 在内的前沿模型的研究表明，这种情况在多步查询中的发生率超过 50% —— 而大多数生产系统都没有任何监测手段来检测它。

你的 RAG 系统在三个月前上线，检索准确度令人印象深刻。如今，它对用户提问中三分之一的内容都给出了“自信的错误”回答——而你的监控系统完全没有察觉到这种变化。没有错误日志，没有延迟激增。语义相似度得分看起来很正常。但检索到的文档已经过时，而模型却充满了信心地回答，因为检索到的上下文看起来非常权威。

这就是 RAG 的新鲜度问题：语义相似度并不关心时间。一个已弃用的 API 参考文档的 Embedding 得分可能与当前最新的文档一样高。上个季度的政策文档可能会排在更新版本之前被检索到。系统不知道，也无法分辨。大多数团队只有在收到用户投诉后，才发现他们的索引已经过时了数周甚至数月——而到那时，用户已经悄然失去了对系统的信任。