向量相似度检索遇到天花板，是否我们走错了？

推荐语

向量相似度检索遇到瓶颈？DocuPanda创始人揭示RAG技术如何突破传统局限，实现精准知识增强。

核心内容：
1. 传统向量检索的根本缺陷与GPT在专业场景中的局限性
2. RAG技术原理及其在房地产客服等场景的实践验证
3. 跨行业知识增强解决方案的通用价值与实施关键

杨芳贤

53AI创始人/腾讯云(TVP)最具价值专家

本文是 DocuPanda.io 的联合创始人 Uri Merhav 在 Medium 发布的一篇博客，主要介绍向量相似度检索的问题以及他们的解决方案。

“依赖预设的相似性判断是有根本缺陷的，注定无法真正奏效。我们应当追求更智能、更精准的方式。”

大约两年前，作为一名机器学习顾问，我参与了多个项目，尝试让 GPT 更加实用和具备专业知识。在其中一些尝试中，我让 GPT 扮演了不同的角色，例如客户支持代表、销售工程师，甚至是医疗初诊的问诊助手。

在所有这些场景下，GPT 最初的表现常常令人印象深刻，因为它能够基于其通用知识快速生成答案。然而，随着交互的深入，它的局限性也逐渐显现：通用知识通常是过时的、不完整的，且模型很难区分真实信息与虚构内容。例如，在客户支持场景中，GPT 有时会编造产品功能，或者无法准确解释具体实现细节。当面对一个持续更新的产品体系时，单靠模型训练中获取的通用知识，很难提供准确且可靠的答案。

显而易见的解决方案是：RAG（Retrieval-Augmented Generation，检索增强生成）。这个名字听起来很高深，实际原理却非常直接：模型在回答问题之前，先检索相关的知识内容（如文档、文章），将这些内容与问题一起提供给语言模型，从而生成更贴切、基于事实的回答。

让我们用一个具体案例说明：假设我正在构建一个自动化的房地产客服代理。我拥有所有租客的租赁合同，而租客则通过电子邮件提交问题或投诉。

此时，如果你仅靠 ChatGPT 来回答这些问题，它是无法胜任的。模型并不了解这些租赁合同的具体内容，也不了解相关城市的租赁法规。要想获得准确回答，就必须将这些信息提供给模型——这正是 RAG 的用武之地。

我们稍后会详细探讨，为什么它会如此自信地给出一个既奇怪又错误的答案。

总之，GPT 有时就像“放飞自我”了一样。它不会诚实地承认“我不知道”，而是会试图给出一个看似合理的答案——哪怕完全不靠谱。在尝试“搜索”答案时，它可能引用一个根本无关的来源，甚至编造出听起来像那么回事的内容。而如果你禁止它联网搜索，它通常会退而求其次，生成一段典型的四段式回答，结构完整、语气自然，却实质空洞，透露出“大语言模型式”的含糊其词。

那么，如果我将租赁合同中关于宠物的条款复制粘贴进来，再提出同样的问题，会发生什么呢？我确实这么做了——先提供了合同中的相关页面，然后提问。结果非常惊喜。

模型给出了一个几乎完美的答案。如果你进一步提供相关的城市法规、建筑许可规定等，模型同样可以给出准确且权威的解答。

这正是 RAG 的强大之处：只要我们能够提供与问题高度相关的文本，像 ChatGPT 这样的语言模型就能理解、适应并基于这些信息推理出令人满意的答案。而且，这一机制并不仅仅适用于房地产客服场景。

比如：

• 如果你能提供相关设备的技术手册，GPT 就能帮助技术支持人员定位故障并给出详细的操作步骤；

• 如果你有保险条款和相关医疗发票，GPT 就可以协助理赔人员判断费用是否应当报销；

• 如果你手头有最新的研究文献，GPT 就可以辅助你制定实验方案或解释研究现象。

  
  

但这个看似“魔法般”的过程，背后仍有一个棘手问题：我们如何获取与问题真正相关的那段文本？

毕竟，语言模型有上下文长度限制——我们不能简单地把世界上的所有文档都扔进去。

这时候，向量嵌入（Vector Embedding）就派上用场了。

向量嵌入听起来高深，但原理其实很直观：语言模型可以将一段文本转换为一个“向量”，也就是一组数字。这组数字是该文本的抽象语义表示。无论是一句话、一个段落，甚至一整篇 50 页的文档，都可以被映射成一个定长的向量。

举个例子，你可以把这篇博客文章输入到 OpenAI 的 text-embedding-ada-002 模型中，它会返回一个由 1536 个浮点数组成的向量。这些数字在某种意义上表示了文章的“语义坐标”，可以用于与其他文章进行语义比较。也就是说，两篇谈论相似主题的文章，它们的向量会在同一个“语义空间”中彼此靠近。

如果你想知道两个向量的相似程度，只需要计算它们之间的“距离”即可——通常采用余弦相似度或欧几里得距离。

有了向量嵌入，搜索的方式就完全改变了。你可以将所有租赁合同、城市条例、建筑许可等文档预处理，拆分成段落甚至句子，并将它们转换成向量存入数据库。当用户提出问题时，将问题也转换成向量，在嵌入空间中找到“最相近”的文档片段，并将它们作为上下文传递给语言模型。

你甚至可以通过更精细的切分方式（比如按段落或小节嵌入）来实现更精准的匹配。这就好比从“全文搜索”跃迁到“语义定位”——不仅知道哪里提到了关键词，更知道哪里真的讲到了你关心的意思。

这个方法确实非常神奇。它赋予了语言模型真正的“检索能力”，从毫无背景知识的状态跃升为拥有定制知识库的智能体。比如：

你可以嵌入一个问题：“你好，我住在 31A 室，我能带一条鳄鱼（alligator）吗？”
接着将你的 52 页租赁合同按段落切分、逐段嵌入，然后匹配问题的向量。你会立刻看到返回的匹配结果中，宠物相关条款位列前茅。

你也可以尝试提出有关押金的问题。确实，有一段内容被识别为高度相关，并准确地回答了押金的金额。

但当我们开始提出更细致的问题时，系统的局限性就开始显现了。例如，如果我问：“你们在什么情况下可以动用我的押金？我是否可以主动申请使用押金？整个流程是怎样的？”——这时，搜索返回的前几段内容可能并没有明确地解答这些问题。

不过，如果你深入查看搜索结果中的第二和第三项，最终还是能找到与问题相关的那段文本。我就不展开了——它既冗长又枯燥。

问题在于：为什么模型没能第一时间找到它？

答案其实很简单：向量嵌入的方式并不能预知回答问题时真正需要的上下文是什么。

向量搜索只是衡量语义相似性，但它无法判断哪种相似性才真正重要。这就导致了一个很现实的问题：

假设我有多个关于同一租户的租赁合同，其中一些已经过期。语义上，它们的内容可能非常相似，因此向量搜索很容易返回来自“错误合同”的“正确段落”。

你可以尝试一些技巧，比如在问题中加上一句话：“The question is being asked on December 2nd, 2024.” 但这并不能显著提高准确性。

为什么？因为某个旧合同的条款可能提到它在 2024 年 12 月 1 日到期，而在向量空间中，12 月 1 日和 12 月 2 日之间的“距离”几乎为零。但从法律角度来看，这种距离其实是无限大的：那份合同已经无效了。但嵌入模型不理解这种业务语义，它只看语义相似性。

这种情况正是优秀 RAG 系统中最常见的失败模式之一：你检索到的是“正确内容，但来自错误来源”。还记得我们开头提到的那个例子吗？ChatGPT 自信地回答了一个问题，但答案基于一个完全无关的网络搜索结果。其实，这种“幻觉”在 RAG 系统中也很常见：

你可能会从错误合同中提取出正确条款、从错误手册中获取看似正确的操作步骤，结果误导用户，造成严重后果。

好的检索 = 有业务逻辑支持的检索

现实中的文档往往伴随着明确的业务逻辑。比如租赁合同，通常包含签署日期、起止时间、房间号等关键信息。
因此，与其单纯依赖语义搜索，我们不妨先使用结构化方式索引文档 —— 不仅可以更高效地筛选出当前有效的合同，还能预提取出常见问题的答案，比如：

• 租金金额

• 押金金额

• 宠物政策的摘要

• 合同是否仍在有效期内

  
  

你甚至可以让语言模型提前处理整个合同，在索引阶段就抽取出这些字段。

我们来举个具体例子。我可以将整份 53 页的租赁合同粘贴给 GPT，并提示它提取我关心的字段信息。这样不仅提高了检索精度，也减少了推理时出错的可能性。

如果我们将这些关键信息提取为统一的 JSON 格式，并在所有文档中保持一致的字段结构，那么将会带来一系列显著的优势：

首先，我们可以实现一致且可预测的检索。比如，你可以对所有文档基于相同字段（如“入住日期”、“租金金额”、“宠物政策”等）建立索引，然后通过 SQL、MongoDB 等方式高效查询这些结构化数据。

更进一步，我们可以将这些字段结构暴露给 AI，告诉它我们是如何组织和索引这些文档的。于是，AI 就能够自动构造出恰当的查询语句，从而检索到真正相关的文档片段，而不是依赖模糊的向量搜索。

实际上，有时候我们甚至无需再读取原始文档内容。因为答案早已通过结构化索引预先提取并存储好了。例如，租赁类问题往往聚焦于少数几个常见领域：租金金额、付款安排、押金条款、入住日期、宠物政策等。在这种情况下，我们只需引用索引中的结构化答案，无需再调入 LLM 分析整份合同。

这让整个系统更加高效——调用更少、更快、更便宜，而且错误率更低。

我坚信这种范式拥有巨大的潜力。事实上，我对它的未来充满信心，以至于我专门创立了一家公司来推动这一理念 —— DocuPanda.io。

DocuPanda 的目标是让结构化信息提取变得简单、一致、可扩展。无论你的文档规模是几十份还是数百万份，无论它们包含表格、手写体、打钩标记，还是复杂的版式，我们都能支持。

在 DocuPanda 中，结构化输出大致如下所示（以下示例省略部分字段以节省空间）：

一旦你对大量文档完成了结构化与标准化处理，就可以自然地提出自由形式的问题，而 AI 会负责将其自动转化为查询，并检索相关信息。

这个过程会引发一个链式反应式推理流程。模型会首先理解你的问题，并结合我们预定义的 Schema，例如：

• tenant_name（租户姓名）

• pets_allowed（是否允许养宠物，布尔值）

• pet_policy_details（宠物相关说明，短文本段落）

  
  

接着，AI 会生成一个数据库查询，比如根据 tenant_name = "Meital Bendet" 获取相应记录。它会读取返回的数据，对其进行分析与推理，必要时还会参考原始文档内容以获取更精确的上下文。

最终，这种流程能够提供清晰、可靠且高度上下文相关的答案 —— 而你只需问一个简单自然的问题。

我希望你能理解这里一个至关重要的观点：花时间思考你的业务是如何理解其文档的，并据此设计一套与你的搜索需求一致的索引结构，是构建强大信息处理流程的关键。

这不仅仅是构建技术系统，更是将你的业务知识、流程语义与文档内容有机结合的过程。通过系统化、结构化的索引方式，你能够显著提高 AI 的准确性、效率与可信度。

如果你正在考虑构建类似系统，欢迎尝试一下 DocuPanda。它是我们在这个领域多年探索、试错与实践的成果，可能会帮助你更快地落地，并少走一些弯路。

祝你索引愉快！

我们确实已经为文档索引了“几个千年”——从泥板到图书馆卡片，再到全文搜索引擎，如今我们终于进入了 语义索引 + AI 理解 的时代。现在不是停下来的时候，而是我们终于能让文档“开口说话”的时刻。

继续往前走，不只是存储信息，更是理解信息、运用信息，让每一份文档真正成为可对话的知识单元。