在 Elasticsearch 中使用确定性防护措施实现智能 AI 搜索，以确保查询安全执行

本系列第 1 至第 7 部分介绍了用于电子商务搜索的受治理控制平面。用户输入查询。控制平面在查询产品目录之前，先进行意图分类、执行业务约束、解决策略冲突，并路由到合适的检索策略。整个架构的假设前提是，输入是由人类购物者键入的搜索字符串。

最后一篇文章提出的问题是：当输入来自 AI 智能体时，会发生什么变化？

答案是架构本身不需要改变，但风险等级发生了变化。当上游决策者是大型语言模型 (LLM) 时，受治理的控制平面中那些对人工编写的查询至关重要的每一个属性，都会变得更加重要。确定性、可审计性、冲突解决和约束执行，从操作便利性变成了关键的防护措施，因为产生输入的系统本质上是概率性的。

智能体搜索问题

目前实现 AI 驱动搜索的最常见方法非常直接：给 LLM 提供数据库模式，在提示中提供业务规则，然后让智能体直接生成查询。

对于电子商务聊天机器人，这意味着将 Elasticsearch 索引映射、字段类型、类别分类法、定价逻辑和业务约束注入智能体的上下文窗口，然后要求 LLM 将自然语言转换为有效的 Elasticsearch 查询 DSL。此时，LLM 扮演了查询作者的角色。

这种方法在演示环境中可行，但在生产环境中会因以下四个原因而失败。

上下文膨胀

企业电子商务索引映射绝非小文档。字段定义、嵌套对象、多字段配置以及分析器设置，在尚未加入任何业务逻辑之前，就可能已经消耗数千个词元。除了映射之外，智能体还需要类别分类法（在企业电子商务中可能包含数万个值）、定价规则、品牌层级、资格约束以及促销活动逻辑。

其结果是，上下文窗口被结构化的元数据所占据，而非用户的实际意图。这会增加延迟，增加词元成本，并随着上下文的增加而降低 LLM 遵循指令的能力。这是一种有据可查的现象，有时被称为上下文腐烂）：提示越长，模型对任何特定指令的关注度就越弱。

概率性幻觉

LLM 基于其训练数据中的模式以及提供的上下文来生成查询。当要求生成 Elasticsearch Query DSL 时，模型可能会幻觉出不存在的字段名、构造出语法无效的查询子句、将过滤器类型误用于不匹配的字段类型，或者生成语法正确但语义错误的查询，最终返回与用户意图不符的结果。

Google Cloud 的 Text-to-SQL 任务的 BIRD 基准测试展示了这种方法的极限。Google 最先进的单模型结果达到了 70% 至 80% 的准确率，意味着将近四分之一的生成查询是错误的。这针对的是 SQL，它远比 Elasticsearch Query DSL 更加标准化。在真实生产环境中，面对复杂的映射和业务特定的语义，LLM 生成 Elasticsearch 查询的错误率很可能会更高。

对于一个收入至关重要的电子商务系统来说，四分之一查询出错率并非可以迭代解决的调优问题，而是该方法本身的架构性局限。

安全差距

当 LLM 能够访问数据库模式并充当查询作者时，系统就容易遭受间接提示注入攻击。与电子商务聊天机器人交互的用户可以精心构造输入，诱导智能体生成非预期的查询。

这并非理论上的风险。在已部署的 LLM 系统中，提示注入是研究最活跃的攻击面之一。根本问题在于，当智能体编写查询时，用户意图与查询执行之间不存在结构性边界。LLM 同时解释用户请求和构建数据库操作。任何对前者的操纵都会直接影响后者。

高基数扩展失败

某些电子商务字段具有极高的基数。一个产品目录可能包含 17,000 个类别值、数千个品牌名称和数百种属性组合。标准智能体工作流需要将这些值注入上下文，以便LLM在构建查询时能够选择正确的值。

这就产生了一个不可能的选择：要么注入所有可能的值（消耗巨大上下文并降低性能），要么注入一个子集（并接受智能体无法引用该子集之外的值），要么退回到无治理的搜索。这与第 1 部分的核心问题直接相关：如果 LLM 搜索“橙子”而 Elasticsearch 返回橙味苏打水，聊天体验就会像搜索体验一样降级。缺乏治理意味着系统无法强制执行购物者的预期解析结果。

一种已知的替代方案是根据查询动态检索相关值，但这会增加一个非确定性步骤，且检索过程本身可能遗漏相关值。此外，这还会为每一次查询增加延迟和复杂度。

架构替代方案：将意图与执行解耦

本系列第 1 至第 7 部分所描述的受治理控制平面提供了一种根本不同的方法。LLM 的角色不再是为最终查询执笔，而是被缩减为一个边界清晰的任务：从用户的自然语言输入中提取一个搜索意图字符串。

用户说：“我在找便宜的棕色鞋子。”智能体的任务不是生成 Elasticsearch 查询，而是提取搜索意图（在此例中类似“便宜的棕色鞋子”）并将其传递给控制平面。控制平面随后执行其既定功能：根据存储的策略过滤意图字符串，通过级联转换组合匹配的策略，以确定性方式解决冲突，并最终生成一个受治理的 Elasticsearch 查询。

LLM 永远看不到索引映射。它从未了解字段类型、类别分类法或价格阈值。它永远不会构造查询子句。它运行在一个架构边界的自然语言侧，我们称之为元数据隔离层，即概率性组件 (LLM) 和结构化数据层（架构、策略和查询构造）之间的严格分离。

元数据隔离层的作用

• 模式盲性。LLM 无法访问数据库模式，因此无法生成无效查询、幻觉字段名，或被操纵而暴露结构信息。模式仅存在于隔离层的确定性一侧。
• 极简上下文。LLM 的提示中不再包含数千词元的映射数据、业务规则和类别分类法，而仅包含角色设定和意图提取指令。这显著降低了词元成本、延迟和上下文腐化。
• 确定性执行。每个到达 Elasticsearch 的查询都由控制平面使用经过人工验证的策略模板来构建，而非由 LLM 概率性地生成。句法有效性得到保证。语义正确性由第 1 至第 6 部分所述的同一策略框架强制执行。
• 架构性安全。提示注入在结构上失效。即使用户操纵智能体产生一个异常的意图字符串，该字符串也会与存储的策略进行反向匹配。如果没有策略匹配，就不会生成任何查询。用户无法指示智能体构造查询，因为智能体根本就不构造查询。控制平面负责构造，而控制平面是确定性的。

各组件如何连接

以下演练展示了受治理的控制平面如何处理代理介导的查询。

第 1 步：用户与智能体对话

一位与电子商务聊天机器人交互的购物者说：“我想买便宜的巧克力，不要含花生的。”

第 2 步：智能体提取意图

LLM 的角色是意图提取，而不是查询生成。通过一个极简的提示，指示它识别产品意图，智能体输出搜索意图字符串：“便宜的巧克力，不含花生”。

这是一个轻量级的分类任务。LLM 不需要索引映射、类别分类法或定价规则来执行此任务。它只需要理解自然语言，而这正是 LLM 所擅长的。

第 3 步：控制平面治理查询

意图字符串“便宜的巧克力，不含花生”被传递给控制平面，控制平面将根据策略索引进行过滤。匹配到三条策略：

• “便宜”策略（提取“便宜”，并根据产品类别应用价格过滤）。
• “巧克力”策略（将结果限制在巧克力类别）。
• “不含”否定策略（提取排除目标，并应用 must_not 过滤器）

控制平面按照第 3 部分和第 4 部分所述的级联转换来应用这些策略：优先级排序、按字段冲突解决、已消耗短语跟踪。如果“圣诞活动”策略也同时激活，它会与产品策略按第 3 部分所述方式组合——智能体的介入丝毫不改变治理模型。

第 4 步：受治理的查询执行

控制平面生成一个完全受治理的 Elasticsearch 查询：搜索“巧克力”，限制在适当的类别内，带有由“便宜”策略导出的价格上限，包含针对含花生制品的排除过滤器，并应用任何生效的促销活动加权。如果“巧克力”策略还包含了经济优化权重（第 7 部分），这些权重也会被应用。由于“巧克力”属于浏览型查询，零售商希望推广利润率更高的产品，因此利润率提升系数被设为 3.0 倍。如果购物者拥有历史购买记录（第 6 部分），个性化信号也会叠加其上。该查询在结构上天生合法，在语义上通过策略设计而保证正确。

步骤5：结果通过代理返回

产品结果返回给智能体，智能体以对话方式呈现给用户。在返回路径中，智能体的角色是呈现：格式化结果、回答追问、提供产品详情。检索过程本身是受治理的、确定性的、可解释的。

智能体的优势（与劣势）

这种架构充分发挥了 LLM 的优势，同时保护系统免受其劣势的影响。

LLM 擅长理解自然语言意图。“我想买便宜的巧克力，不要含花生的”是一个自然语言理解任务：解析意图、识别产品指代、识别否定。LLM 能够可靠地处理这一任务，因为它本质上是一个分类问题，而非生成问题。输出是一个简短的意图字符串，而不是复杂的结构化查询。

在复杂的约束条件下，LLM 难以实现精确的结构化输出。生成有效的 Elasticsearch Query DSL 需要精确的字段名称、正确的子句嵌套、适用于每个字段的恰当过滤器类型，以及跨数千个边缘情况统一应用的业务规则。这些正是确定性系统可以轻松保证，而概率性系统却难以稳定实现的属性。

受治理的控制平面将每个组件置于其应属的位置：LLM 负责自然语言侧，确定性策略引擎负责查询构建侧，二者之间由架构边界隔开。

治理约束影响范围

这正是第 3 部分的相同见解，扩展到了智能体上下文。在第 3 部分中，我们观察到治理通过在检索开始之前缩小候选集，使语义检索更加安全。在受治理的类别中对 500 个产品进行语义搜索，与对 500,000 个 SKU 进行语义搜索，本质上是不同的命题。

同样的原则也适用于智能体介导的查询。如果没有治理，当智能体错误解读“便宜的巧克力”时，可能生成一个全目录搜索的查询，不带任何价格约束、类别过滤或排除条件。有了治理之后，即使智能体产生了一个不完美的意图字符串，控制平面也会将查询限制在匹配的策略范围内。最坏的情况是触发的策略更少，而不是无限查询会影响产品目录。

治理缩小了概率性错误的影响范围。无论概率性组件是语义检索模型还是 LLM 智能体，这一点都成立。

LLM 建议的政策：扩大覆盖范围

第 2 部分提出了一个想法：LLM 可以建议新的策略，这些策略会进入与人工编写策略相同的“编写 → 测试 → 上线”管道。在智能体上下文中，这形成了一个强大的反馈循环。

LLM 可以分析查询日志，识别出控制平面没有匹配策略（即直接落到未修改检索上的查询）的模式，并建议新的策略来填补这些空白。运营人员会审查每条建议，进行测试，如果产生预期行为则将其上线。治理模型确保任何由 LLM 建议的策略都必须经过人工验证才能进入生产环境。

随着时间的推移，这会形成一个良性循环：控制平面的策略覆盖范围不断扩大，需要未修改检索的查询比例不断缩小，系统变得越来越受治理，每一条策略都是可审计、可版本控制和可单独反转。

更广泛的模式：概率系统的确定性防护措施

本系列所描述的架构——位于概率性输入源与数据检索系统之间的确定性控制平面——并不仅限于电子商务搜索。凡是 AI 智能体需要与结构化数据交互的场景，都可以应用同样的模式。

智能体查询 SQL 数据库时面临同样的挑战：因注入模式导致的上下文膨胀、幻觉出的列名、提示注入风险，以及高基数值的选择问题。智能体与 Jira 等工单系统、Salesforce 等客户关系管理 (CRM) 系统或 GitHub 等代码存储库交互时，也会遇到类似的问题。在每种情况下，核心架构问题都是相同的：应该让 LLM 来编写查询，还是让 LLM 提取意图并将其传递给一个确定性层来编写查询？

受治理的控制平面为该问题提供了一个可复现的答案。策略即数据。意图提取是 LLM 的工作。查询构建是控制平面的工作。元数据隔离层使它们保持分离。治理框架（优先级排序、冲突解决、级联转换、可审计性）确保随着策略数量的增长，确定性层在操作上是可管理的。

结论

本系列所描述的电商搜索治理模式（策略即数据，编写 → 测试 → 上线的流程，级联转换，按字段冲突解决，基于反向匹配的逆向匹配，以及多层降级）最初设计用于运营人员编写策略、购物者键入查询的场景。但该架构的潜力远不止于其初始用例。

当输入源是 AI 智能体而非人类购物者时，受治理的控制平面就成为概率性系统与生产数据存储之间的关键安全层。它提供了企业系统所必需的、而 LLM 自身无法提供的确定性保障：语法合法性、语义正确性、可审计性和安全性。

确定性控制平面并非要替代 AI 智能体。它使 AI 智能体可以安全部署。

将受治理的电子商务搜索付诸实践

本系列所描述的受治理控制平面架构（从“策略即数据”范式，到基于反向匹配的查找，再到个性化、经济优化以及智能体隔离层）均由 Elastic 服务工程团队设计并构建。本系列中描述的每一种模式都源自一个在实际企业级产品目录上构建并验证过的生产系统。

如果您的团队正在构建 AI 驱动的搜索体验，并需要为智能体介导的查询设置确定性的防护措施，或者您希望在 Elasticsearch 上实现一个受治理、可由业务编辑的搜索架构，Elastic 专业服务团队可以加速您的实施。请联系 Elastic 专业服务团队。

加入讨论

对搜索治理、检索策略或电子商务搜索架构有疑问？加入更广泛的 Elastic 社区讨论。