当相似度并不相关时：构建超越向量搜索的企业级RAG系统。

向量搜索在筛选出与问题相似的文本方面表现极为出色。不过，相似度与实用性是两回事，而企业级RAG往往正是出在两者之间的差距上。

被检索到的文档虽然可能使用与用户相同的词汇，但仍可能过时、不可用、内容不完整，或与当前业务场景无关。与此同时，真正能解答问题的文档可能表述方式不同，因此得分较低。问题通常不在于嵌入模型或向量数据库，而在于人们误以为语义相似度就等同于相关性的完整定义，但实际上并非如此。

在企业中，相关性不仅仅取决于用词。时间新近性、权威性、地理位置、文档类型、用户权限、工作流程状态、合同关系以及业务实体之间的关联等因素都会产生影响。一个可靠的系统必须综合考量这些因素，而不能将向量空间中的接近程度视为最终判定标准。

向量搜索为何成为默认选择

关键词搜索极度依赖精确的词汇。那些寻找“员工离职政策”的人可能会错过名为“员工离职流程”的文件，因为两者之间没有共同的词汇。

向量搜索正是为了解决这一缺陷而出现的。文档会被转换为嵌入向量，即代表其含义的数值，用户的查询也会被转换为同样的向量形式。系统随后会返回那些向量与查询向量最为接近的文档片段。即便查询语句和原始文档的用词不同，也能找到概念上相关的内容。

正因如此，向量检索非常适合多种应用场景：处理自然语言查询、匹配同义词和意译内容、搜索非结构化文档、支持对话式或多语言查询，以及将海量数据缩减为简短的候选列表。

这些优势使得向量数据库成为早期RAG架构的核心，其标准流程也显得十分简洁：文档被分割成多个块，每个块都会被生成嵌入向量并存储起来。在查询时，首先对问题进行嵌入处理，然后获取距离最近的块并传递给语言模型，由模型生成答案。

使用这种方案，演示场景和小型知识库可以正常运行，但在企业级环境中就开始出现性能瓶颈。

相似度只是众多信号之一

想象一下，一位采购经理输入这样的问题：“我们与Northstar Components目前的协议中适用哪些付款条款？”

一个仅基于向量的系统可能需要包含当前供应商合同、与同一供应商的过期合同、载有标准付款条款的模板、关于拟议变更的邮件、涉及供应商付款的采购政策，以及另一家Northstar子公司的合同。

这些资料每一项在语义上都与问题相关，但或许只有一两项在操作层面真正重要。做出正确选择意味着需要进一步解答问题：‘我们’所指的法律实体是哪个？涉及的是哪家Northstar公司？该协议是否仍然有效，是否有修订内容改变了原有条款？该协议受哪个司法管辖区管辖？该用户是否有权限查看？是否存在已签署的版本，以及哪个版本具有最高效力？

嵌入模型本身并不具备对这类约束条件的理解能力。它仅能在学习到的语义空间中衡量相似度，无法判断哪份文档具有法律约束力或操作有效性。

正因如此，高相似度分数会带来错误的自信感。系统检索出看似合理的文本，语言模型将其转化为流畅的答案，而这种看似自然的表达却掩盖了检索过程中的错误。

纯相似度方法的七大缺陷

几种反复出现的故障模式使得仅依赖向量的检索方式存在风险。

过时的资料。旧文件往往看起来与现行文件相似。一份已到期的政策，除了某个阈值、日期或审批规则不同外，可能与其替代版本极为相似。由于大量措辞相同，两者的评分都会很高。如果没有版本控制和生效日期管理，系统可能会提供过时的指导，这在受监管的行业尤其危险，因为细微的政策变动都可能影响合规性、报告要求或对客户的处理方式。

对权威的忽视。一份头脑风暴笔记、一封内部邮件以及一项已获批的政策都可以涉及同一主题，而那些非正式的资料可能因为表述方式与问题相似而显得更为重要。企业知识体系并非民主制。通常情况下，经过签署的合同应优于草稿，已获批的流程应优于会议记录，经过验证的监管提交材料应优于分析师的笔记。相关性需要依据证据层级来判定。

因分块而割裂的关系。为提高精确度并适应上下文窗口限制，RAG系统会将文档拆分成小片段，这可能导致事实与其赋予意义的关系被分开。一个片段可能规定付款义务，另一个片段可能标注供应商名称，还有一个片段可能包含修改原有条款的补充内容。每个片段单独来看都是不完整的，仅获取最相似的段落也无法保证能重新构建出完整的整体图像。

精确标识符带来的问题。嵌入模型是为语义优化而设计的，往往无法很好地表示字面字符串。零件编号、账户号码、条款引用、药品代码、设备标识以及版本号都是常见的受影响对象。搜索“Model AX-1047”时不应出现“AX-1041”的结果，因为这两者的描述过于相似。商业检索通常既需要语义上的匹配，也需要字面意义上的精确对应。

负面约束条件。人们常常会询问哪些内容缺失：哪些客户尚未完成验证，哪些设备不在当前的维护协议范围内，哪些发票在60天后仍未支付，哪些试用站点尚未提交所需文件。这类问题都基于记录中的缺失项、排除项或对比关系。相似度搜索虽然能检索到与某个概念相关的文本，但无法准确判断究竟缺少了什么。

缺乏业务状态概念。企业对象会经历草稿、已提交、已批准、暂停、过期和归档等状态。关于同一对象的两份文档即便处于不同状态，内容也可能几乎完全一致，而当前状态则决定了该文档是否具有相关性。

仅凭授权并不够。语义上最相关的文档可能正是用户无权查看的文件。访问控制不能仅仅依赖于提示语中的指令，必须在受限内容进入模型上下文之前将其移除，否则系统要么会直接泄露敏感信息，要么会让模型间接推断出这些信息。

相关性具有多重维度

在企业级RAG系统中，相关性应被视为多种信号的综合体现：语义相似度、关键词或精确匹配相关性、来源权威性、时间有效性、与业务规则的契合度、权限合规性，以及关系或图结构相关性。排名公式可以将这些因素按各自权重进行加权求和。

权重取决于具体应用场景。内部研究助理可能会赋予语义相似度较高的权重，而合同问答工具则可能更关注生效日期和信息来源的权威性，调查平台则可能以人物、事件、地点和资产之间的关系为核心。

这并不意味着每个组织都需要复杂的数学排序模型，而是说明相关性应当被有意识地定义，而非直接沿用向量数据库的默认评分。

更稳健的检索架构应具备哪些特点

可靠的RAG系统通常会经历多个检索与验证阶段。

1. 理解查询意图

在开始搜索之前，系统会先分析用户的查询意图。这包括提取查询目的、各类命名实体、时间范围、文档类型、管辖区域、客户或产品标识符、业务单元以及所需的权限级别，进而判断该查询是需要搜索、计算、比较还是图遍历。

以“今年我们的欧洲数据保留政策有哪些变化？”为例，这类查询不应通过普通的语义搜索来处理。它涉及特定的地区、文档类别、时间范围以及版本对比。查询理解功能会将这种较为模糊的句子转化为结构化的检索计划。

2. 元数据过滤

元数据在检索之前或检索过程中能够缩小搜索范围。有效的字段包括地区、所有者、业务部门、文档生效与失效日期、审批状态及版本、文档类型、数据分类、产品系列、客户或供应商编号，以及用于访问控制的属性。

应用过滤器可以避免明显不符合条件的候选项与符合条件的候选项竞争。同时，元数据的质量也成为了RAG质量的重要组成部分：如果导入的文档缺乏可靠的日期、所有者信息、版本状态或访问标签，那么无论使用何种嵌入模型，检索效果都会很不稳定。

3. 混合检索

混合检索将语义搜索与词汇搜索相结合。向量方法处理含义和同义表达，而BM25之类的词汇方法则处理精确的术语、标识符以及罕见词汇。混合系统能够理解“终止程序”与“离职政策”之间存在关联，同时仍要求“HR-OPS-204”这一标识必须实现精确匹配。

可通过互反排名融合或领域特定的评分函数来合并检索结果。对许多企业而言，这是对仅基于向量的处理流程最实用的升级方式之一。

4. 结构化数据检索

对于某些查询而言，文档片段并非合适的数据来源。涉及数量、总计、阈值、状态或比较的内容，通常更适合通过SQL查询、搜索索引、API、数据仓库、知识库、主数据系统或规则引擎来处理。

如果有人询问“本季度有多少笔未结索赔金额超过50万卢比？”，正确的做法是查询存储有索赔记录的结构化数据源。仅通过文字描述索赔情况是无法得出具体数字的。成熟的设计会将每个问题交给最适合处理它的机制来解答。

5. 知识图谱与基于关系的检索

有些问题本质上是与关系相关的。知识图谱能够建模客户、供应商、产品、合同、地点、事件及法规，以及它们之间的关联关系。

假设某风险分析人员想了解哪些在册供应商通过实际受益人关系与受制裁实体存在关联。单段文字很可能无法提供足够证据。要找到答案，就需要通过供应商记录、企业所有权数据、筛查结果以及合同状态等线索进行追踪。图检索可以定位涉及的实体网络，而向量搜索则能找出与这些实体相关的支持性内容以及由此发现的关联关系。

这种技术的组合通常被称为GraphRAG，不过具体实现方式各有不同。它的优势并不在于图结构比向量更先进，而在于图结构能够清晰呈现各种关系，而嵌入模型则往往将这些关系简化为统计上的相近性。

6. 重新排序

初次检索时应以召回率为优先：收集尽可能多的潜在相关候选内容。随后通过重排模型结合完整查询内容对它们进行更细致的评估。交叉编码器、专用排序模型或基于大语言模型的评估工具可用于判断某段文字是否真正能回答问题。

可作为评估依据的信号包括文字对问题的回答直接程度、实体匹配度、权威性、时效性、完整性、具体性、矛盾点以及业务规则。其目的是区分那些“与主题相关”的段落与那些“对当前问题有用”的段落。

7. 上下文整合

将前五部分内容传递给大型语言模型并非一种上下文处理策略。相关证据可能需要按文档分组、按时间顺序排列、与相邻部分结合扩展、链接到定义或表格、去重、与修订内容合并、跨版本对比、标注来源与权威性，同时进行不会丢弃异常值的压缩处理。

其目的是保留结构化信息以满足推理需求。对于合同条款而言，这意味着要附带其定义、例外条款以及修订历史；对于临床操作流程，则可能需要相关的警示信息；而对于财务数据，则需要说明报告期和会计基准。

8. 证据验证

在给出最终答案之前，系统应先判断现有证据是否足够。这些来源是否直接支持该答案，且信息是否最新？是否有权威来源持不同意见？是否缺少必要的文档？该答案是否基于未经证实的推论？用户是否真的能够查看所有被引用的内容？

当证据不足时，最稳妥的回应可能是说明这一点，请求进一步澄清或上报处理。企业级RAG系统应当设计为能够拒绝回答，而不仅仅是给出答案。

业务规则具有实际约束力

相当一部分检索错误即便使用更优的嵌入模型也无法解决，因为相关性是由数据组织方式决定的。相关准则包括：除非有地区性规定，否则采用最新获批的政策；按合同修订的顺序应用这些修订；优先使用经审计的财务数据而非管理层的估算值；排除草拟中的监管文件；以法律实体而非商号来识别客户；仅返回用户有权访问的区域的记录。

这些准则应当纳入检索、排序或协调处理代码中。期望大型语言模型能从上下文中推断出这些准则是不可靠的，而且也无法进行任何审计。在此情况下，企业级RAG就变成了系统工程任务，而非单纯选择模型的问题。

超越答案准确率的评估标准

一个系统可能会因为错误的原因得出正确答案，这可能是由于检索到了力度不足的证据，或是依赖了模型先前的知识。它在测试中可能看起来准确无误，但一旦文档内容发生变化就会出错。因此，评估必须检查整个流程的每一层。

检索。需检查是否找到了必要的证据：召回率@k、精确率@k、平均互反排名以及标准化折现累积增益，此外还要了解精确标识符出现的频率，以及结果更新及时且具有权威性的频率。

上下文。需检查整合后的材料是否可用：证据的完整性、冗余程度、矛盾率、上下文相关性、表格与章节关系的保持情况，以及版本一致性。

生成质量。需检查最终结果：对证据的忠实度、引用是否正确、内容是否完整、无依据主张的占比、是否适当回避争议，以及是否遵守相关许可与政策。

业务成效。需追踪运营价值：节省的时间、案例升级的频率、剩余的审核工作量、错误的严重程度、问题解决的速度、用户对工具的信任度、任何合规问题，以及工作流程采用该工具的广泛程度。即便语义检索效果更好，但如果过期的合同或无法访问的记录依然出现，那也意义不大。

团队在放弃向量搜索时常犯的错误

许多机构在意识到仅依赖向量技术的RAG存在局限后，便在不明确相关性判断标准的情况下增加了系统复杂性。

一个错误是试图一次性采用所有技术。知识图谱、重排序工具以及智能工作流都无法解决缺失的元数据或糟糕的文档管理问题。

另一个错误是将大语言模型视为万能的裁决者。虽然这些模型擅长解读查询并对证据进行排序，但那些必须精确无误的规则，比如访问控制、日期和实体ID，通常仍应由确定性代码来处理。

第三个错误是仅针对基准测试问题进行优化。真实用户提出的查询往往模糊、不完整且依赖大量上下文，因此测试数据需要包含真实的边缘情况、过时的文档、相互矛盾的来源以及权限边界问题。

最后，有些团队将检索视为一种基础设施采购行为。选择向量数据库只是众多决策之一，因为相关性的体现还取决于文档的导入与结构方式、附加的元数据、身份识别的方法，以及排名、协调和管理机制的设置。

实际可行的改进路径

无需直接替换现有的RAG平台即可提升相关性，可以逐步进行优化。

首先从出错的查询入手，对每一种检索错误进行分类。是因为缺少正确的证据、相关度评分过低、被错误过滤、内容分散在多个片段中，还是被过时的信息源所掩盖？

接着，通过确定哪些信息源具有权威性、哪些元数据字段重要，以及哪些业务规则决定有效性，来明确特定工作流程中相关性的含义。

接着为每种故障添加最简单的处理机制。精确的标识符需要通过词汇搜索来定位；日期、地区和文档类型则需借助元数据过滤器；对于模糊的查询与文档匹配情况，则需使用重排算法；缺乏上下文的片段则需检索相邻内容；分析性问题适合用结构化数据库处理；依赖实体关系的答案则需要通过图遍历来获取。在检索之前应确定性地检查权限，而不完整的证据则应触发回避规则。

最后，利用真实用户问题与实际故障构建评估集，并分别测试检索与生成功能，以避免某一环节的改进掩盖另一环节存在的问题。

选择正确的证据而非相似文本

向量搜索依然具有价值，它擅长定位主题相似的段落。但它无法自行判断哪段内容是最新的、最具权威性的、被允许使用的、完整的，或是适用于特定业务场景的。

需要一种更完善的相关性架构，将语义检索与精确匹配搜索、元数据、业务规则、结构化数据源、图关系、重新排序以及证据验证相结合。

下一代的RAG系统不会通过获取更多相似文本来取胜，真正的赢家能够在恰当的时机、为恰当的用户、在恰当的上下文中提供正确的证据。