141 篇博文 含有标签「rag」

大多数团队在意识到他们的语料库中很大一部分内容——产品截图、演示录制、架构图、客服通话录音——对于纯文本检索系统是不可见的之后，会将多模态 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 得分可能与当前最新的文档一样高。上个季度的政策文档可能会排在更新版本之前被检索到。系统不知道，也无法分辨。大多数团队只有在收到用户投诉后，才发现他们的索引已经过时了数周甚至数月——而到那时，用户已经悄然失去了对系统的信任。

当 100 万 Token 的上下文窗口发布时，许多团队认为这相当于拿到了可以停止思考上下文设计的“许可”。逻辑很直观：如果模型能看到一切，那就把一切都给它。丢进整个文档。传递完整的对话历史。将每一个工具输出都转发给下一个 Agent 调用。让模型自己去处理。

这就是“上下文堆砌 (Context Stuffing)”反模式。它会产生一种典型的故障模式：系统在早期演示中运行良好，但在生产环境中会遇到可靠性瓶颈，无论如何调整提示词都无法修复。在原本应该很简单的问题上，准确率反而下降。回答变得模棱两可、含糊其辞。Agent 开始在互不相关的文档之间产生幻觉性的关联。模型“看到”了所有正确的信息 —— 它只是找不到。

你的 RAG 昨天回答得还很正确。今天它却自相矛盾了。看起来什么都没变 —— 除非你的嵌入模型（Embedding）提供商悄悄更新了模型，导致你的索引现在成了一个混合了不同向量空间的“科学怪人”（Frankenstein）。

嵌入模型是每个检索增强系统（RAG）中不起眼的基石，而且它们的失效方式通常极其难以诊断。与提示词（Prompt）更改或模型参数微调不同，嵌入模型的问题往往出现得非常缓慢，表现为一种无声的质量下降，在用户开始投诉之前，你的评估系统（Evals）甚至都察觉不到。本文涵盖三个方面：如何为你的领域选择合适的嵌入模型（MTEB 评分的误导性往往大于帮助）、升级模型时究竟会发生什么，以及无需从头重建即可更换模型的版本控制模式。

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

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

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

大多数构建 LLM 应用的团队都将隐私视为一个模型问题。他们担心模型知道什么——它的训练数据、它的记忆——却在模型周围的流水线中留下了巨大的漏洞。令人尴尬的事实是，生产环境 LLM 系统中绝大多数的数据泄露根本不是来自模型。它们来自你未经脱敏就索引的 RAG 分块、你逐字写入磁盘的提示词日志、包含数据库凭据的系统提示词，以及被投毒文档劫持以窃取知识库中所有内容的检索步骤。

Gartner 估计，到 2025 年底，30% 的生成式 AI 项目将因为风险控制不足而被放弃。这些失败中的大多数并不是因为模型幻觉——而是源于工程师本以为在掌控之中的系统隐私和合规性故障。

当 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 向量在几何上无法满足的多重约束问题。稠密向量搜索并没有错 —— 只是它并不完整。构建一个在生产环境中真正起作用的检索栈，需要理解其中的原因，并层层加入能够弥补这些缺陷的组件。