在 Elasticsearch 中使用带有确定性护栏的 Agentic AI 搜索，以实现安全的查询执行

作者来自 Elastic Alexander Marquardt, Honza Král 及 Taylor Roy当 LLM 直接生成查询时 Agentic AI 搜索系统通常会失败。了解确定性护栏和控制平面架构如何通过 Elasticsearch 实现安全、可靠且受治理的查询执行。刚接触 Elasticsearch加入我们的 Elasticsearch 入门网络研讨会。你也可以开始免费的云试用或者现在就在你的机器上试用 Elastic。本系列的第 1 到第 7 部分描述了一个用于电商搜索的受治理控制平面。用户输入一个查询。控制平面会在真正查询商品目录之前对意图进行分类、执行业务约束、解决策略冲突并路由到合适的检索策略。整个架构都假设输入是由人类购物者输入的搜索字符串。本篇最终文章提出了一个问题当输入来自 AI agent 而不是人类时会发生什么变化答案是架构本身不会改变但风险会增加。对于人工编写查询来说重要的受治理控制平面的每一个属性当上游决策者是大型语言模型 LLM 时都会变得更加重要。确定性、可审计性、冲突解决以及约束执行将从运营便利性变成关键护栏因为生成输入的系统本质上是概率性的。Agentic 搜索问题最常见的 AI 驱动搜索方法很直接向 LLM 提供数据库 schema在提示词中提供业务规则然后让 agent 直接生成查询。对于电商聊天机器人来说这意味着将 Elasticsearch 索引映射、字段类型、分类体系、定价逻辑以及业务约束注入到 agent 的上下文窗口中然后要求 LLM 将自然语言转换为有效的 Elasticsearch Query DSL。LLM 成为了查询编写者。这种方法在演示中有效但在生产环境中会因为四个原因而失败。上下文膨胀企业级电商索引映射并不是一个简单的文档。在添加任何业务逻辑之前字段定义、嵌套对象、多字段配置以及 analyzer 设置就可能达到数千个 token。在映射之上 agent 还需要分类体系在企业级电商中可能包含数万个值、定价规则、品牌层级、资格约束以及活动逻辑。结果是上下文窗口被结构化元数据主导而不是真正的用户意图。这会增加延迟、增加 token 成本并随着上下文增长而削弱 LLM 遵循指令的能力。这是一个有充分文档记录的现象有时被称为上下文腐化 context rot 随着提示词变长模型对任何特定指令的关注都会减弱。概率性幻觉LLM 基于其训练数据中的模式以及提供的上下文来生成查询。当被要求生成 Elasticsearch Query DSL 时模型可能会幻觉出不存在的字段名、构造语法无效的查询子句、将过滤器类型错误地应用到不匹配的字段类型或者生成语法正确但语义错误的查询从而返回与用户意图不匹配的结果。Google Cloud 的 BIRD Text-to-SQL 基准测试说明了这种方法的上限。Google 最先进的单模型结果准确率约为 70% 到 80%这意味着几乎每四个生成的查询中就有一个是错误的。而这还是针对 SQL 的结果 SQL 的标准化程度远高于 Elasticsearch Query DSL。在真实生产环境中面对复杂映射和业务特定语义时由 LLM 生成 Elasticsearch 查询的错误率很可能更高。对于以收入为关键的电商系统来说四分之一的查询错误率并不是一个可以通过迭代调优解决的问题而是这种方法本身的架构性限制。安全缺口当 LLM 可以访问数据库 schema 并充当查询编写者时系统会受到间接提示词注入的攻击。与电商聊天机器人交互的用户可以精心构造输入以操控 agent 生成非预期的查询。这并不是理论风险。提示词注入是已部署 LLM 系统中研究最活跃的攻击面之一。根本问题在于当 agent 编写查询时用户意图与查询执行之间不存在结构性边界。LLM 同时负责解释用户请求以及构建数据库操作。对前者的任何操控都会直接影响后者。高基数字段的扩展失败某些电商字段具有极高的基数。一个商品目录可能包含 17,000 个分类值、数千个品牌名称以及数百种属性组合。标准的 agentic 工作流要求将这些值注入上下文中以便 LLM 在构建查询时能够选择正确的值。这会形成一个无法解决的权衡要么注入所有可能的值消耗巨大的上下文并降低性能要么只注入一个子集并接受 agent 无法引用该子集之外的值要么退回到无治理的搜索。这与第 1 部分中的核心问题直接相关如果 LLM 搜索 “oranges”而 Elasticsearch 返回的是橙子汽水那么聊天体验就会像搜索体验一样退化。缺乏治理意味着系统无法强制执行购物者期望的解析结果。基于查询动态检索相关值是一种已知的替代方案但它引入了额外的非确定性步骤因为检索本身可能会遗漏相关值。此外这还会给每个查询增加延迟和复杂性。架构替代方案将意图与执行解耦在第 1 到第 7 部分中描述的受治理控制平面提供了一种根本不同的方法。与其让LLM生成最终查询不如将 LLM 的角色缩减为一个单一且边界清晰的任务从用户的自然语言输入中提取搜索意图字符串。用户说“Im looking for cheap brown shoes.” agent 的任务不是生成 Elasticsearch 查询而是提取并传递搜索意图在这个例子中例如 “cheap brown shoes”到控制平面。然后控制平面执行其一贯的工作基于存储的策略对意图字符串进行 percolate通过级联变换组合匹配策略确定性地解决冲突并生成一个受治理的 Elasticsearch 查询。LLM 从不接触索引映射。它不知道字段类型、分类体系或价格阈值。它也不会构建任何查询子句。它只在一个架构边界的自然语言侧运行我们称之为 metadata air gap这是概率性组件LLM与结构化数据层schema、策略以及查询构建之间的严格隔离。元数据隔离层提供什么模式盲区Schema blindness。大语言模型没有访问数据库模式schema的能力因此无法生成无效查询、幻觉字段名或被操控去暴露结构信息。模式只存在于隔离层的确定性一侧。最小上下文Minimal context。相比于数千 token 的映射数据、业务规则和分类体系taxonomy大语言模型的提示词只包含一个角色设定persona和意图提取指令。这大幅降低 token 成本、延迟以及上下文退化context rot。确定性执行Deterministic execution。每一个到达弹性搜索Elasticsearch的查询都由控制平面control plane使用人工审核的策略模板policy templates构造而不是由大语言模型概率生成。语法有效性被保证语义正确性由同一套策略框架第1到第6部分所描述约束。架构即安全Security by architecture。提示注入prompt injection在结构上变得无效。即使用户操控代理agent生成一个异常的意图字符串该字符串也会与已存策略进行过滤匹配percolation matching。如果没有策略匹配则不会生成任何查询。用户无法指示代理构造查询因为代理不构造查询控制平面才构造而控制平面是确定性的。各部分如何连接下面的流程展示受治理的控制平面如何处理一个由代理agent介导的查询。步骤1用户与代理对话一个与电商聊天机器人交互的购物者说“我在找便宜巧克力不要含花生的。”步骤2代理提取意图大语言模型LLM的角色是意图提取而不是查询生成。在一个只要求识别产品意图的最小提示词下代理输出一个搜索意图字符串“便宜巧克力不含花生”。这是一个轻量级分类任务。大语言模型不需要索引映射、分类体系taxonomy或定价规则就能完成它。它只需要理解自然语言而这正是大语言模型擅长的。步骤3控制平面管理查询意图字符串 “便宜巧克力不含花生” 被传递到控制平面并与策略索引进行过滤匹配percolation matching。有三个策略命中“便宜” 策略提取 “便宜”并根据产品类别应用价格过滤。“巧克力” 策略将结果限制在巧克力类别。“不含” 否定策略提取排除目标并应用 must_not 过滤条件。控制平面通过第 3 和第 4 部分描述的级联转换来应用这些策略优先级排序、字段冲突解决、短语消耗追踪。如果同时存在“圣诞活动”策略它会与产品策略组合方式与第 3 部分描述完全一致代理的参与不会改变治理模型。步骤4受治理查询执行控制平面生成一个完全受治理的弹性搜索Elasticsearch查询对“巧克力”的搜索限制在相应类别设置由“便宜”策略导出的价格上限添加包含花生产品的排除过滤器以及任何活动提升。如果“巧克力”策略包含经济优化权重第 7 部分也会被应用。利润提升设置为3.0倍因为 “巧克力” 是浏览类查询商家更倾向于推广高利润产品。如果购物者有购买历史第 6 部分个性化信号会被叠加在上面。该查询在构造上语法必然正确在策略设计上语义正确。步骤5结果返回代理产品结果返回给代理由代理以对话形式呈现给用户。代理在返回路径中的角色是呈现格式化结果、回答后续问题、提供产品细节。检索本身是受治理、确定性且可解释的。Agent 擅长什么以及不擅长什么这个架构利用大语言模型LLM擅长的能力同时保护系统不被其弱点影响。大语言模型在理解自然语言意图方面非常擅长。“我在找便宜巧克力不要含花生的” 是一个自然语言理解任务需要解析意图、识别产品引用、理解否定关系。大语言模型在这类任务上表现可靠因为这是分类问题而不是生成复杂结构的查询。输出只是一个短的意图字符串而不是复杂的结构化查询。大语言模型在复杂约束下生成精确结构化输出方面表现较弱。生成有效的弹性搜索查询领域特定语言Elasticsearch Query DSL需要精确的字段名、正确的语句嵌套、每个字段对应合适的过滤类型以及在成千上万的边界条件中一致应用业务规则。这些正是确定性系统可以轻松保证而概率系统难以稳定保证的特性。受治理的控制平面将每个组件放在其应有的位置大语言模型负责自然语言侧确定性策略引擎负责查询构建侧两者之间由架构边界隔离。治理约束 “爆炸半径”这一点延续了第三部分的核心思想并扩展到代理系统的上下文中。在第三部分中我们观察到治理通过在检索开始前缩小候选集合使语义检索更加安全。在受治理的类别中对 500 个商品进行语义搜索与在50万库存商品上进行语义搜索是完全不同的系统问题。同样的原则也适用于由代理介导的查询。如果没有治理一个代理对“便宜巧克力”的误解可能会生成一个没有价格约束、没有类别过滤、没有排除条件的全量查询。而在有治理的情况下即使代理生成的意图字符串不完美控制平面也只会在匹配到的策略范围内构造查询。最坏情况下只是更少策略被触发而不是无约束查询直接访问整个商品库。治理缩小了概率性错误的影响范围。这一点对语义检索模型或大语言模型代理同样成立。大语言模型建议策略扩展覆盖范围第二部分提出大语言模型可以建议新的策略这些策略会进入与人工编写策略相同的 “作者→测试→发布” 流程。在代理系统中这形成一个强大的反馈闭环。大语言模型可以分析查询日志识别控制平面中没有匹配策略的模式即未被改写的直接检索查询并建议新的策略来覆盖这些空白。商品运营人员对每一条建议进行审查、测试并在结果符合预期时发布。治理模型确保任何由大语言模型建议的策略都不能在未经人工验证的情况下进入生产环境。随着时间推移这会形成良性循环控制平面的策略覆盖率不断扩大未经过治理的原始查询比例不断下降系统逐渐变得更加受控每一条策略都是可审计、可版本管理、可单独回滚的。更广泛的模式为概率系统提供确定性护栏本系列描述的架构 —— 一个位于概率输入系统与数据检索系统之间的确定性控制平面 —— 并不仅限于电商搜索。同样模式适用于任何需要人工智能代理与结构化数据交互的场景。一个查询结构化数据库的代理面临同样问题模式注入导致的上下文膨胀、列名幻觉、提示注入风险以及高基数值选择问题。一个与问题跟踪系统如 Jira、客户关系管理系统如 Salesforce或代码仓库如 GitHub交互的代理也会面临类似挑战。在所有这些场景中核心架构问题都是一致的是让大语言模型直接生成查询还是让大语言模型只负责提取意图再交给确定性层生成查询。受治理的控制平面提供了一个可复用的答案策略即数据意图提取是大语言模型的工作查询构建是控制平面的工作元数据隔离层将两者分离治理框架优先级排序、冲突解决、级联转换、可审计性确保随着策略数量增长系统仍然可运维。结论本系列描述的电商搜索治理模式策略即数据、“作者→测试→发布” 流程、级联转换、按字段冲突解决、基于过滤器的反向匹配、多层回退机制最初是为人工运营人员与购物者交互设计的但其架构可以支持更广泛的应用。当输入来源从人类购物者变为人工智能代理时受治理的控制平面成为概率系统与生产数据存储之间关键的安全层。它提供确定性保证语法有效性、语义正确性、可审计性与安全性而这些是企业级系统所必需但大语言模型本身无法提供的能力。确定性控制平面并不是替代人工智能代理而是让人工智能代理可以安全部署。将受治理的电商搜索付诸实践本系列描述的受治理控制平面架构 —— 从策略即数据范式到基于过滤器的匹配机制再到个性化、经济优化以及代理系统的隔离层设计 —— 由弹性服务工程团队设计并实现。整个系列中的所有模式都来自一个已经在企业规模商品目录上验证的真实系统。如果你的团队正在构建基于人工智能的搜索体验并需要为代理查询提供确定性护栏或者希望在弹性搜索之上实现可治理、可业务编辑的搜索架构弹性专业服务团队可以加速你的落地实现。联系 Elastic 专业服务。参与讨论如果你对搜索治理、检索策略或电商搜索架构有疑问可以加入更广泛的 Elastic 社区讨论。原文https://www.elastic.co/search-labs/blog/agentic-ai-search-deterministic-guardrail-query-execution