RAG的失败往往源于检索层，而非大模型。所以，决策框架、混合流程和可靠的系统护栏，或许是取代“一刀切”向量搜索的正解！

　　比如，一个内部AI助手在演示时看起来非常棒。向量数据库连夜吞入数据，接入GPT-4级别的模型，向决策者展示简洁的问答效果。团队信心满满地启动了项目。然而，当真正开始提出实际业务问题时，情况就变了。

　　销售代表询问合同续签日期，却从错误的客户文件中得到了一段看似自信但完全错误的段落。合规官员询问当前的数据保留政策，得到的却是2021年的旧版本，且没有任何免责声明。开发者查询了其角色本无权访问的数据，而助手依然给出了回答。

　　这并不是模型的错。 它生成的正是它被设计用来生成的内容：基于检索层递交给它的上下文，给出一个自信且流畅的答案。问题在于检索层拿回了错误的文档、过时的数据以及未经授权的信息，而模型对此一无所知。

　　RAG的质量不是模型的问题，而是一个检索架构的问题。 大多数团队往往在进入生产阶段后才发现这一点。

　　根本原因几乎总是一样的：对所有问题都采用单一的检索方法。 向量搜索通常是默认选项，不是因为它总是对的，而是因为它被视为万 能答案。结果就是构建了一个在语义相似度上表现出色，但在精确查找、最新数据和访问控制方面表现极差的系统。

　　生产级RAG需要的是检索决策框架（RDF），而不是检索默认值。方法必须与问题的“形状”相匹配。 在企业系统中，这种路由还必须考虑实时数据源和受控访问，而不仅仅是静态索引。

　　检索决策框架，先分类、后动手

　　不同的问题有不同的形态。询问特定数字的问题与要求解释概念的问题，其检索需求截然不同。关于当前价格的问题与询问行业情绪的问题也完全不同。

　　下面的准则将查询形态映射到具体的检索方法。即在任何检索器被调用之前，应先在路由层应用此套路。

　　1. 当问题需要精确、实时、结构化数据时，请使用SQL

　　当答案是确定性的，且存在于结构化、关系型数据中时，SQL才是正确的检索路径。聚合计算、日期范围筛选、连接查询和精确记录查找都属于SQL的领域。

　　“第二季度按产品线划分的总收入是多少？”

　　“给我看所有企业合同账户的未结支持工单。”

　　“哪些客户在90天内未登录？”

　　这些问题只有一个正确答案，且它就在某张表里。无论多少语义推理，都比不上一条写得好SQL查询。答案非对即错，通往正确答案的唯一途径是结构化的真理来源。

　　SQL在数据新鲜度方面也明显胜出，因为关系型数据库在查询时反映的是当前状态，而向量索引反映的往往是上一次索引运行时的状态。对于任何需要关注时效性的问题，SQL是更安全的默认选择。没有陈旧风险，因为没有索引滞后。

　　⚠️提示： 不要将类似SQL的LIKE模糊查询作为默认的企业搜索策略。LIKE执行全表扫描，忽略语言变体和词界，并在大数据集负载下崩溃。如果你的团队考虑用LIKE作为全面文本搜索的替代方案，说明需要投资专门的搜索框架，而不是把SQL逼到极限。

　　2. 当用户措辞很重要时，请使用关键词/全文搜索

　　Elasticsearch和其他全文搜索引擎常被忽视，但实际上起着重要作用。当用户使用的确切词汇很重要、需要在文档集合中查找大量信息，或者想根据额外信息筛选结果同时匹配文本时，它非常有用。

　　“我们对国际SaaS订单的退款政策是什么？”

　　“查找所有提及v2 API弃用的文档。”

　　“给我看带有‘企业客户’标签的入职指南。”

　　BM25是大多数关键词搜索引擎使用的排名算法。它展示的是包含用户输入准确词汇的文档。它还支持提升某些字段权重、根据文档新鲜度评分以及使用元数据筛选等功能。这些功能在向量存储中要么缺失，要么做得不够好。

　　Elasticsearch不仅仅是一个备用选项，也不是等待被新方法取代的旧技术。其文本分析工具、专用分词器以及加权不同字段的能力，使团队能比基于嵌入的系统更好地控制信息检索。完全从关键词搜索转向向量检索的团队，常在发现结果准确性存在问题后，又不得不回归关键词搜索。

　　⚠️提示： 在向语言模型提供搜索结果前，确保搜索结果是最新的、经过用户授权的，并且来源可信，因为这些检查应在生成前进行。

　　3. 当意图比准确词语更重要时，请使用向量检索

　　当用户意图优先于精确措辞时，带有文本嵌入的密集向量检索是理想的选择，因为它能有效处理同义词、释义、跨语言查询和概念性问题。

　　“这个季度客户最不满意的是什么？”

　　“总结上个月支持工单升级的主要问题。”

　　“数据库连接超时有已知问题吗？”

　　这些问题没有特定的关键词，因为它们可以用多种方式表达；向量检索通过嵌入模型与语义相似的内容进行匹配，从而有效地捕捉意图。选择合适的嵌入模型至关重要，尤其是在法律或医疗等特定领域，经过微调的嵌入模型相比通用模型能显著提升检索性能。

　　⚠️ 提示： 向量相似度不等于正确性。仅仅因为一个文本块的余弦相似度为0.87，并不意味着它准确、最新或与你的问题相关。高相似度表明文本在概念上相关，但这并不保证信息是真实的、最新的或经过验证的。在与语言模型分享前，务必验证任何检索到的上下文。

　　什么时候SQL、全文搜索和向量检索？

　　大多数生产查询并不完全属于单一检索类别。“过去30天内影响企业账户的主要问题有哪些？”这个问题需要结构化过滤（企业账户，30天窗口）、关键词检索（工单描述、问题类别）和语义分组（聚类类似投诉）。没有一种检索器能同时应对这三种情况。

　　解决方案是一个带有显式路由逻辑的混合流水线，建议采用以下7步流程：

　　步骤1：对用户意图进行分类在路由到任何检索器之前，先对查询进行分类。轻量级分类器（无论是微调的模型还是快速大模型的结构化提示）将问题分为结构化、主题性、语义性或混合型。这种分类驱动着所有后续决策。跳过它意味着盲目路由。

　　步骤2：选择正确的检索路径根据分类将查询发送给其主检索器。结构化查询用SQL处理；关键词和主题查询发送到Elasticsearch；概念性查询发送到向量数据库；混合查询则并行运行多个检索器。路由不是性能优化，而是正确性的决策。

　　步骤3：排名前应用元数据过滤器在评分或合并结果之前，应用日期范围、文档类型、访问权限、租户ID和文档分类的硬性筛选。排名前进行筛选更高效，更重要的是，可以防止未经授权或无关的文件进入候选库。不应被看到的文件绝不能送到排名器手中。

　　步骤4：合并多个检索路径中的候选项当多个检索器并行运行时，将所有候选项收集到一个统一的池中。你现在会看到SQL行、关键词匹配的文档和向量检索的文本块并排出现。下一步决定如何将它们排在一起。

　　步骤5：重排序（Re-ranking）当你收集了来自不同搜索路径的结果后，你需要重新排序，看看哪些结果真正能更好地回答用户的问题。

　　最实用的方法是使用倒数秩融合（RRF）。它是极好的默认选择，因为它简单，不需要复杂的数学来比较不同系统（如SQL和向量库）的结果。它遵循一个简单的原理：如果两个不同的搜索工具一致认为某文档是#1结果，那么该文档的得分远高于仅由单一工具找到的文档。

　　对于高精度至关重要的高风险查询，可以使用交叉编码器（Cross-encoder）重排序器。这比RRF更准确，虽然会增加一些处理延迟。

　　步骤6：仅从批准的证据生成只把排名最高的、经过筛选和验证的文本块传递给语言模型。明确指示模型仅从所提供的上下文中回答，并在上下文不支持自信答案时予以承认。这是一个硬性的架构约束（而不是提示工程的技巧），限制模型可以生成什么。

　　步骤7：返回引用、来源或可追溯证据每个生成的答案都必须可追溯/可审计，指向特定的检索来源。显示文档标题、最后更新日期、源系统和检索方法。引用是用户验证答案并在检索失败演变为决策错误前发现问题的方法。

　　挡住陈旧、越权、胡说的的护栏

　　护栏不是事后考虑的，它们从一开始就内置在设计中。没有这些护栏的RAG流程不过是带有一些文件的“自信幻觉生成器”。以下列出的四类护栏对企业使用至关重要。

　　1. 新鲜度护栏 (Freshness)

　　检索索引中的每个文本块都必须带有最后更新的时间戳。在将检索到的内容传递给语言模型之前，确认源文档是否处于查询类型的可接受新鲜度窗口内。

　　价格数据的TTL（生存时间）可能为24小时；

　　法律和合规政策可能要求30天内更新；

　　内部知识库条目可能容忍90天。

　　如果检索到的文档已经过时，不要静默使用。要么返回警告，要么触发源系统实时重新获取，要么诚实地回复当前数据不可用。

　　2. 权限护栏 (Permissions)

　　每次检索调用都必须强制执行请求用户的访问权限。在文档进入候选池之前，按租户、角色、团队、文档分类以及组织使用的其他访问控制维度进行筛选。

　　权限必须在检索层执行，而非呈现层。 检索文档后决定不显示，已经是失败了。因为该文件已被读取、处理，并可能影响生成，最终才被压制。

　　3. 正确性护栏 (Correctness)

　　如果顶层检索的文本块得分低于定义的置信阈值，流水线不得从中生成答案。返回“我找不到这个问题的可靠答案”，比从一个边缘相关的部分生成流畅权威的答案要好得多。前者会削弱信心，而后者会破坏信任，而信任更难重建。

　　当从不同来源检索到的文本块相互矛盾时，应明确标记矛盾，而不是让语言模型默默选择一方。

　　4. 行动护栏 (Action)

　　在代理（Agent）工作流中，检索往往先于操作。行动护栏确保代理无法对已检索到的陈旧、模糊、超出范围或未经授权的信息采取行动。

　　代理系统采取的每一个操作都必须可追溯到特定的检索事件、证据和用户授权。如果无法形成该链条，行动就不能继续。

　　MCP：当 Agent 需要动真格的时候

　　在智能系统中，检索更进一步。客服不仅仅是搜索信息，它使用工具从实时系统中提取数据，启动业务工作流程，查询外部API，并代表用户行动。

　　模型上下文协议（MCP）正逐渐成为这些工具集成检索的首选标准。它为代理提供了跨平台访问结构化工具（如数据库、CRM和日历API）的可靠方式，使语言模型能够有效推理交互。每个MCP工具调用都作为读取动作运行，遵循前面提到的四个护栏。

　　像OutSystems这样的企业平台，提供一个AI工作台，用来从企业数据创建受控的AI应用，非常适合这个领域。这里讨论的检索架构选择不仅仅是理论，它们决定了企业级AI功能在实际应用中是否可靠，或者仅仅在演示中看起来好看。

　　当检索通过受控工具调用从实时企业系统中提取数据时，保持数据的新鲜性变得更容易。没有过时索引的风险，因为数据在需要时直接从源头获取。

　　结论：RAG架构即检索治理

　　企业级 RAG 最大的误区，就是把检索当成一个“已解决的问题”——以为向量数据库往里一放，万事大吉。事实上，真正的生产级 RAG，是一个检索治理问题。

　　你需要一个架构，使工具与问题相匹配，比如：用SQL处理数字、用搜索匹配精确术语、用向量理解概念意义……你必须强制执行权限并检查数据新鲜度，才能让数据进入模型。

　　RAG部署成功与否，不是看你是否拥有最流行的模型，而是从第一天起就把检索视为一个关键且受控的架构层次来设计。 如果你在关键时刻构建检索系统，你的生产系统实际上会变得值得信赖。