为什么你的RAG不起作用?如何解决语义失谐

# 为什么你的RAG不起作用？如何解决语义失谐 无数企业正在尝试使用检索增强生成（RAG），但他们普遍感到失望——这些系统很难达到生产质量。RAG不仅效果不佳，而且团队往往搞不清楚问题出在哪里，更不知道下一步该怎么走。 先说一个核心判断：**语义不一致**是阻碍RAG系统的一个关键罪魁祸首。所谓语义不一致，指的是任务的预期含义、RAG对它的理解以及存储的底层知识之间的不匹配。再加上**嵌入向量**底层技术本身的不透明性，这种不一致很难诊断，直接成了生产化道路上的一大障碍。 本文的目标很明确：**揭开普通RAG失败的主要原因**，并**提供具体策略，让你的RAG更接近生产环境**。我们将从以下四个层面展开： - 区分理想RAG与现实RAG的差距 - 解释语义不一致是如何产生的 - 说明如何诊断和抑制语义失调 - 总结其他高级策略，让RAG做好生产准备 （注意：为简单起见，这里主要关注基于问答文本的示例，但核心思路可以推广到其他用例。） --- ## 1. 为什么选择RAG？ RAG（检索增强生成）是一种正在经历炒作周期的范式。它听起来很时髦，本质上就是给AI配了个搜索引擎。GPT-3大获成功后，RAG迅速跟进，原因很直接：企业构建LLM驱动的AI时面临一个现实问题——像GPT这样的模型并没有针对他们的特定数据和领域进行训练。但从业者很快发现，当提示中直接提供业务特定的上下文（比如支持文档）时，GPT的表现出乎意料地好。这就为企业提供了一个替代微调任务的可行方案。 输入RAG。从原理上讲，它就是AI的专用搜索引擎。你向它提一个问题，可能还附带用户特定的信息，它就会返回与GPT最相关的上下文。 听起来很不错，但现实中实现生产级RAG面临的挑战，远超大多数人的想象。 --- ## 2. RAG前景光明，但普通RAG才刚刚起步 RAG本质上是一个框架。一个功能完备的RAG系统——无论其后端如何——都能为大量用户提供巨大价值。但如果要理解它为什么经常失败，先得弄清楚**普通RAG是怎么工作的**。如果你已经经历过对向量嵌入从困惑、拒绝到最终接受的完整心路历程，可以**跳过这一节**。 > **普通RAG**（定义）：一种单步语义搜索引擎，使用现成的嵌入模型将业务知识（如支持文档）存入向量数据库（如Pinecone）。检索时，从问题文本生成向量嵌入，通过余弦相似度等比较指标，对前k个最相关的文档进行排序。 进一步分解这些概念：**向量嵌入模型接受任意字符串，返回固定维度的数学向量**。流行的嵌入模型包括OpenAI的*text-embedding-ada-002*及其最新模型*text-embedding-3-small*，它们将文本块转换成约1500维的向量，几乎没有人类可解释性。 向量的厉害之处在于：它能把**非定量的事物**分解成丰富的维度，然后进行定量比较。举个例子： - 调色板中的（红、绿、蓝）就是一个向量，每个值在0-255之间 - 按行业标准，股票可以表示为一个向量，量化其对经济增长、利率变化等经济因素的敏感性 - Netflix等平台可以将用户偏好分解为向量，其中包含类型偏好和其他特征 **余弦相似度**是目前语义搜索中比较向量的主流指标。它通过点积计算两个向量之间的角度，余弦值越接近1，向量越相似。（还有其他测量语义相似度的方法，但多数情况下，余弦相似度是最容易上手的。） **但这里必须强调：使用余弦相似度进行向量比较非常微妙，因为它没有绝对的意义**——结果完全取决于嵌入模型和具体文本的上下文。假设你拿问题去匹配答案，得到0.73的余弦相似度。这算匹配成功吗？简单来说，以“什么是雨？”这个问题为例，与三个相关性不同的文本进行比较，你会发现不同模型给出的范围和解释截然不同。对于第一个模型，0.73是完全不相关的匹配；对于第二个模型，0.73却意味着高度相关。这说明，任何正常运行的RAG系统，都需要校准自己对余弦相似度分数含义的理解。 > 文本1（定义）：“雨是从云中析出的水滴，当它们变得太重而无法悬浮在空中时就会落到地面。” > 文本2（提到下雨）：“风把水分吹过山上，导致西雅图下雨。” > 文本3（不相关信息）：“Stripe是一家支付基础设施公司。” --- ## 3. 语义不一致导致问题 普通RAG的几大挑战，核心都可以归结为**语义不一致**和**嵌入的可解释性差**。所谓语义不一致，就是任务的本意、RAG的理解和它背后存储的知识之间，出现了对不上的情况。 这具体是怎么引发的？ **苹果和橘子的比较**。可以大致这么说：问题在语义上并不等同于它的答案。所以直接把问题和原始知识库做比较，效果往往有限。举个例子，一位律师需要搜索数千份文件来寻找投资者欺诈证据。问题“什么证据表明鲍勃犯了金融欺诈？”和“鲍勃于3月14日购买了XYZ股票”在语义上几乎没有任何重叠（而隐含的信息是：XYZ是竞争对手，3月14日是财报发布前一周）。 **向量嵌入和余弦相似度自身的模糊性**。向量在完全捕捉任何给定语句的语义内容方面，存在固有缺陷。另一个微妙的问题是：余弦相似度不一定能产生精确的排名，因为它默认每个维度的重要性是一样的。实际中，**使用余弦相似度的语义搜索方向往往是对的，但本质上很模糊**——它能很好地预测前20个结果，但要求它把最佳答案准确排到第一位，常常是强人所难。 **嵌入模型在互联网上训练，不了解你的业务和领域**。打个比方，我在Stripe工作过的时候，有Connect、Radar、Link等产品，而Direct本身是一个常见形容词，但根据谈论的产品不同，含义千差万别。别说AI了，就算是Stripe的内部员工之间，语义不一致也随处可见。这个话题很深，值得专门写一篇博客。 总之一句话：语义不一致的来源**不断叠加，导致排名越来越不可靠**。接下来的部分，我们将演示如何诊断和解决这个问题，最后还会概述提升RAG的进阶技巧。 --- ## 4. 演示：诊断和抑制语义失调 这一节我们来诊断一种情况：当RAG的比较结果与随机噪声相差无几、完全不可靠时，该怎么办。同时也会展示，用附加结构如何显著提升性能。 这个例子来自真实的业务场景，为了说清楚关键问题，我们做了适当简化。 ### 4.1 设置 完整设置在Google Colab Notebook中。 假设一家电商初创公司，正在构建一个供内部使用的RAG，用来为给定的业务问题找到最优SQL表。步骤如下： 1. 创建两个不同的SQL表模式（用ChatGPT生成） - `events.purchase_flow`：产品流程中高度详细的原始用户事件 - `aggregates.purchases`：带摘要分析的汇总表 2. 创建一些假设性问题（用ChatGPT）用于评估 - IP地址对浏览和购买的商品类型有什么影响？ - 本季度鞋类销售的整体趋势如何？ - 每小时内的几秒钟之间有没有异常行为？ - 新年等重大事件中，用户参与度有什么变化？ 3. 生成其他元数据（用ChatGPT），包括 - 每个表的简要说明 - 每个表有唯一答案的示例问题 4. 通过将输入文本与“垃圾”比较，检查噪声余弦相似度分数 5. 比较四种不同的检索策略，看哪种类型的文本与输入“语义上最相似” - 策略1：仅用表结构 - 策略2：表结构+简要说明 - 策略3：表结构+简要说明+示例问题 - 策略4：仅用示例问题 ### 4.2 发现噪声余弦相似性 为了直观感受噪声是什么样，我们把每个问题与原始表文本以及随机文本片段的余弦相似度做了比较（见下图）。**发现垃圾输入的余弦相似度大约在0.04–0.23之间**。 从对比结果可以看出：策略4（仅把问题与示例问题比较）的语义重叠度最高，排名也最好。策略1和策略2的表现与噪声差不多——也就是说，业务问题和SQL表语句之间的语义重叠非常弱（如果有的话）。 这听起来像常识，但问题在于：我见过大量RAG开发采用的是同样的“苹果对橘子”式比较。更隐蔽的情况是：**把所有内容混在一起的策略3，表现反而不如策略4**——后者去掉了额外细节，把问题单独拿出来比较。有时候，用手术刀确实比大锤更有效。 > 噪声（随机、不相关文本）：余弦相似度0.04–0.23之间。 > 策略1（仅表结构）：0.17–0.25（与噪声一致） > 策略2（表结构+描述）：0.14–0.25（仍与噪声一致） > 策略3（表结构+描述+示例问题）：0.23–0.30（明显改善，开始从噪声中分离出信号） > 策略4（仅示例问题）：0.30–0.52（最佳策略，完全超出噪声范围，而且正确表和错误表的余弦相似度差距最大，信号更清晰） ### 4.3 要点概览 回顾一下：我们先用随机垃圾建立了一个余弦相似度基线的参考范围，然后比较了四种检索策略。借助这个基线，我们发现有两种策略的表现与噪声没有区别。而最好的策略不是把业务问题直接跟原始SQL表匹配，而是把问题跟已知表可以回答的示例业务问题做匹配。 --- ## 5. 改善RAG的进一步策略 这还只是冰山一角。以下是一些值得采用的方法，能让你的RAG实现阶跃式的改进。 ### 5.1 构建数据以进行同类比较 上面的演示已经给了提示：你**可以通过附加结构来改进RAG**。具体来说，先把问题链接到现有问题库，再由问题库导向正确答案，而不是直接链接问题到原始文本。对于基于支持文档的问答系统，你很可能会发现：问题→问题比较，比问题→支持文档的匹配效果要显著好得多。实际操作中，可以让ChatGPT为每个支持文档生成示例问题，再由人类专家进行整理。本质上，就是预先给自己造一个内部版Stack Overflow。 如果想走得更远，可以进一步优化这个“Stack Overflow”方法论： - 对每个文档，让ChatGPT生成一份它能回答的100个问题列表 - 这些问题并不完美，所以对生成的每个问题，计算与其他文档的余弦相似度 - 筛选出那些能把正确文档排在第一的问题 - 按照正确文档与排名第二的文档的余弦相似度差距大小排序，找出最高质量的问题 - 最后交给人类做进一步整理 ### 5.2 语义+相关性排名 这可能是性价比最高的方案之一，而且几乎所有主流搜索引擎都这么做。我们已经看到余弦相似度在粗略预测上很管用，但最终无力实现更高精度的排名。 **好消息是：你的企业可能拥有更多信息，能帮AI做更好的决策。** 比如，你可能已经收集了页面浏览量、点赞等指标，甚至还能按角色分开统计。你可以构建一个相关性分数，把用户/任务特征加进去，微调排名，让RAG工作得更好。具体来说，可以把排名变成线性组合： 排名 = 余弦相似度 + 权重 × 相关性分数 ### 5.3 使用AI：手术刀，而不是大锤 几十年来，软件工程实践逐步走向“大量小型、定义明确、保证可靠”的组件设计。聊天界面的热潮彻底碘伏了这个模式——五年后，这种模式很可能会被视为一种值得商榷的做法。ChatGPT和众多新兴生态系统催生了“给我任何文本，我给你任何文本”的范式，无法保证有效性，甚至无法保证成本和延迟，却承诺“我有时可能还算靠谱”。 然而，企业可以通过**提供范围更窄、更有主见的界面**，构建更强大的人工智能。以数据分析为例，到目前为止，*还没有人*真正成功兑现了“回答任意数据问题并给出准确SQL”的承诺。别灰心，你仍然可以构建非常有用的工具。比如，一个范围更窄的AI可以帮助用户从数据科学家维护的固定SQL表和模板查询中搜索。更进一步：既然大多数数据驱动的业务问题过去都已经被解答过，或许你的AI只需要一个在Slack里根据数据问题做搜索的机器人。 --- ## 6. 总结 AI的新时代正在到来。这个时代的新特点并不是NLP和语言模型的出现——谷歌在这块已经耕耘多年。真正的变化在于，现成的技术大大降低了企业用自然语言技术解决特定用例的门槛。但别忘了：这项技术目前还处于早期开发阶段。当为AI构建RAG时，你本质上是在知识库之上搭建一个复杂的搜索引擎。这件事可以实现，但了解这些挑战、解决这些局限，你就已经成功了一半。 --- *[1] 本文翻译自Medium深度文章《Why Your RAG Doesn’t Work》* *[2] OpenAI text-embedding-ada-002* *[3] Google Colab Notebook完整设置*