最后一篇文章提出的问题是：当输入来自 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 社区讨论。

本文介绍了两种个性化机制，它们可在不改变治理控制平面架构的前提下对其进行扩展。这两种机制与第 1 至第 5 部分的治理层叠加：策略仍会触发，约束仍会执行，冲突仍会解决，个性化信号被组合成同一治理查询，确保 Elasticsearch 返回的结果已经个性化。

第一种机制会提升购物者之前购买过的产品。第二种机制则根据购物者资料激活针对特定群组的策略。两者共同表明：个性化并非一个独立于搜索之外、或作为检索后处理来附加的系统，而是策略驱动的控制平面的一种自然扩展。

如需深入了解本文中使用的个性化技术的数学原理，请参阅《无需 ML 后处理的 Elasticsearch 个性化搜索》和《Elasticsearch 中基于群组感知的排名》。

要观看关于如何使用购买历史记录提升回头客搜索结果的现场演示，请观看视频：可解释的个性化：利用购买历史记录提升搜索结果。

个人购买历史记录提升

最简单的个性化推荐方式也是最有效的之一：如果购物者之前购买过某款产品，当他们搜索相关商品时，就提升该产品。一个经常购买某品牌巧克力曲奇的购物者，在搜索“曲奇”时，应该看到这些曲奇排名更靠前——这不是因为模型预测了偏好，而是因为有直接的行为证据。

运作方式

当搜索请求包含用户标识符（例如用户处于已开启的会话中）时，控制平面会使用线程池并行运行两个 Elasticsearch 查询：

1. 针对策略索引的 percolator 查询（即第 3 和第 4 部分中描述的治理查找）。

2. 对 user_purchases 索引进行购买历史记录查询，通过 term(user_id) 过滤到特定用户，然后将当前搜索字符串与该用户的产品标题进行匹配。

这两个查询并发执行（互不等待），因此个性化查找不会显著增加治理管道的延迟。

在将当前搜索字符串与存储的产品标题进行匹配时，购买历史记录查询使用 Elasticsearch 的文本分析（提取词干、词汇切分）。这意味着，通过标准文本分析，搜索“曲奇”时，系统会匹配到过去购买的“布朗尼曲奇”，而无需进行精确的字符串匹配。

计算提升权重

并非所有过去的购买都应获得相同的提升。权重考虑了两种直观因素：购物者购买该产品的频率，以及最近购买时间。上周购买 15 次的产品，其信号强度远高于六个月前仅购买过一次的产品。权重计算采用频率的对数缩放（避免单一高频购买产品压倒其他一切产品），以及近因的指数衰减（使较早的购买随时间自然弱化）。

有关提升公式的数学细节，请参阅《无需 ML 后处理的 Elasticsearch 个性化搜索》。

如何成为查询的一部分

购买历史记录提升作为最外层的评分层被组合到查询中，包裹了第 3 和第 4 部分的治理策略筛选器和提升，以及任何业务信号提升，例如利润和热度（我们将在第 7 部分探讨）。这意味着由治理策略移除的产品不会因购买历史记录的提升而重新出现。治理 控制结果集；个性化 调整其中的排序。没有任何购买历史记录的产品不会被降权。它们的治理排名保持不变，但在其他条件相同的情况下，具有相关购买历史记录的产品会排在它们上面。

为什么每次搜索都要查询 Elasticsearch？

每次搜索时，购买历史记录都会从 Elasticsearch 中查询，而不是缓存在应用程序层中。这是一个经过深思熟虑的设计选择。由于查询通过 Elasticsearch 的文本分析管道匹配当前的搜索字符串与产品名称，系统受益于与产品搜索本身相同的词干提取、词汇切分和语言处理。缓存内存中的查找需要重新实施该分析，或接受更粗糙的匹配。

要了解为什么这种排序很重要，可以考虑一位以前购买过橙汁但现在正在搜索“橙子”的购物者。购买历史记录查询通过文本分析将“橙汁”与搜索词“橙子”进行匹配，并为该产品计算提升。但治理层已经将“橙子”限制在农产品类别中，完全过滤掉了橙汁。查询中包含针对橙汁的购买历史记录提升，但由于受控结果集中没有匹配的文档供其作用，因此该条件无效。购物者看到的是新鲜橙子，按相关性和个性化排序。治理机制依然有效。

性能成本极低：购买历史记录索引很小（一个用户的购买历史记录通常只有几十到几百个文档，而非数百万），并且查询与 Percolator 查找并行运行，因此不会延长关键路径。

无用户历史记录时搜索“spring water”的示例

如果未登录用户或从未购买过“spring water”的用户搜索，他们可能会看到类似以下的结果：

用户购买历史记录示例

另一方面，一位名叫 Carol 的用户的购物历史包含以下产品：

使用上述购买历史记录搜索“Spring water”的示例

如果 Carol 搜索“spring water”，她将看到反映她过去购买记录的个性化结果。从上面的购买历史来看，她购买了“Carbonated Spring Water”（绿色瓶子）约 40 次，最近一次购买是两天前。如果她搜索“spring water”，我们知道她喜欢这个产品，因此该产品会被提升。请注意，在非个性化结果中，Rubicon spring water 反而成为了第一个匹配项。

群组意识策略激活

个人购买历史记录对具有既定行为的回头客很有效。但许多购物者都是新用户、匿名用户，或在常规模式之外浏览。对于这些购物者来说，群组成员身份提供了一种不同类型的个性化服务，这种服务基于购物者的身份，而不是他们过去的行为。

一个素食者搜索“巧克力”时，应该看到素食巧克力排名更高。一个清真饮食者搜索“零食”时，应该突出显示清真认证的选项。一个注重健康的购物者搜索“酸奶”时，应该提升益生菌选项。

群组作即策略，而非产品标签

产品已带有其常规属性，包括 dietary_restrictions: ["vegan"] 或 dietary_restrictions: ["halal"] 等字段。问题在于，连接购物者群组与这些产品属性的逻辑应该放在哪里。

天真的做法是在应用层或搜索模板中硬编码该映射：如果用户是素食者，则在 dietary_restrictions: "vegan" 上添加提升。但这与第 1 部分中描述的应用层杂乱无章的情况相同，也会造成同样的运营摩擦：添加新群组或更改群组的含义都需要修改代码。

受治理控制平面将群组逻辑保留在策略引擎中。群组策略将两项内容关联起来：购物者的群组成员身份（例如“素食者”）和产品属性（例如 dietary_restrictions: “vegan”）。策略定义了连接：当素食者群组中的购物者进行搜索时，提升包含 dietary_restrictions “素食者”的产品。

由于群组逻辑存在于策略引擎而非应用代码中，这意味着：

• 添加新群组只需创建新策略，无需重新索引产品。

• 群组策略使用完整的规则引擎：它们可以添加过滤器、应用软提升、扩展同义词、更改检索策略，或执行策略可以采取的任何其他操作。

• 群组行为通过与其他所有策略相同的管理界面进行管理：运营人员可以通过第 2 部分中描述的“编写 → 测试 → 推广”工作流来创建、测试和推广群组策略。

素食群体政策示例

运营人员制定了一项具有以下特征的群组策略：

• 队列：["vegan"]。

• 匹配标准：匹配任何查询（或特定产品类别）。

动作：对 dietary_restrictions: "vegan" 进行软提升，提升权重为 2。

群组激活的工作原理

每份策略文档都有一个 cohorts 字段。适用于所有购物者（无论群组如何）的通用策略可以将此字段留空，控制平面将在内部为其分配 "_all" 的值。群组特定策略存储其目标群组的名称，例如 ["vegan", "kosher", “sweet_tooth”]。

当搜索请求包含用户资料时，控制平面为 percolator 查询构建一个简单的 terms 筛选器：

这个单一筛选器包含所有通用策略以及用户特定群组的策略。_all 哨兵使其成为一个简洁的包含筛选器：无需 must_not 或 exists 查询来处理策略没有群组限制的情况。

然后 percolator 照常评估策略匹配。唯一的区别是候选策略集已被缩小到与该购物者的群组相关的那些策略。所有下游操作（级联转换、按字段冲突解决、消费短语跟踪）与第 3 部分和第 4 部分所描述的非个性化流程完全相同。

非素食（标准）用户搜索“巧克力”的结果

当非素食用户搜索巧克力时，搜索结果不会应用素食用户群体的推荐提升。他们经常在热门搜索结果中看到非素食巧克力，具体如下：

搜索“巧克力”时显示的素食者群组策略结果

当素食群组购物者搜索“巧克力”时，此策略会包含在 percolator 候选集中。它与之匹配，控制平面会对经过素食认证的巧克力进行软提升。该提升是乘法性的：素食巧克力排名更高，但非素食巧克力不会被完全排除，因为上述筛选器被定义为软性提升，我们在本系列的第 3 部分对此进行了详细描述。

不过，如果购物者明确搜索“好时牛奶巧克力”，素食提升效果仍然有效，但可能会被“好时牛奶巧克力”产品更强的文本相关性所抵消。

对于那些不在素食群组范围但搜索相同关键词的购物者而言，他们永远不会看到“素食群组”策略；该策略不在他们的候选集中。治理层完全相同，只是激活的策略集不同。

有购买历史记录的群组

一位拥有丰富购买历史记录的素食购物者，会同时获得针对素食者群组的策略激活以及基于其购买历史记录的产品提升。对于新用户或匿名购物者，仅隐含的群组成员资格即可提供有意义的个性化设置，无需任何行为数据（例如，一个匿名用户只搜索过素食产品，那么我们可以将其归类为素食群组成员）。一个在创建账户时自我标识为清真饮食者的购物者，在第一次搜索时就会立即获得清真定制的结果。

个性化层的组合方式

function_score层的嵌套顺序很重要。从最内到最外：

1. 基本查询：带有命名查询（fulltext_match、title_phrase_match）的关键词或语义匹配。

2. 治理政策层：硬过滤作为bool.filter 条款，软提升作为function_score 功能（第 3 和第 4 部分）。

3. 业务信号提升：利润和热度提升 （我们将在第 7 部分探讨）。

4. 购买历史记录提升：最外层的 function_score 层。

这种排序方式可确保治理层控制结果集（显示什么内部），业务信号调整该集合内的排名（从零售商角度看什么显示在前面），而购买历史记录则根据个人行为进一步调整排序（从购物者的角度看什么显示在前面）。每一层以乘法方式包裹前一层，因此效果是叠加而非冲突。

这在运营层面上意味着什么

通过受治理的控制平面进行个性化，保留了第 1 和第 2 部分中描述的所有运营属性：

• 零部署变更。群组策略通过管理界面创建、测试和推广。新增饮食偏好群组或调整提升权重，无需修改代码，也不需要工程师介入。

• 可审计性。每个群组策略都是一个离散、版本化的文档。当运营人员询问“为什么这个用户的素食产品排名更高？”时，答案是一个具有特定优先级的特定策略，可以在调试面板中与该查询触发的所有其他策略一起看到。

• 冲突解决。群组策略第 3 部分中描述的相同按字段冲突解决机制。如果群组策略的类别提升与营销活动策略的类别覆盖冲突，冲突会由相同的优先级和策略框架确定性解决，无需特殊处理。

• 可衡量性。由于群组策略是离散且可以单独切换，它们对转化率、点击率和加购率的影响可以独立衡量，就像系统中任何其他策略一样。

本系列内容预告

下一篇文章将探讨受治理控制平面的另一个维度：如何通过策略按查询调整利润和热度提升，将经济优化转变为治理决策，而非静态配置。

参见第 7 部分：查询治理的经济优化：按查询的利润与热度提升

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

本文介绍的个性化模式（个人购买历史记录提升和群组感知策略激活）由 Elastic Services Engineering 设计并构建，是我们可复用的电子商务搜索加速器的一部分。这两种机制都与本系列中描述的受治理控制平面架构集成。请联系 Elastic Professional Services。

加入讨论

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

从架构到实现

第 3 部分介绍了控制平面架构：将反向匹配作为查找原语、使用策略文档分离匹配与操作，以及通过级联转换将多个策略组合成单一执行计划。本文将通过实际操作介绍驱动策略查找的 Elasticsearch 核心功能：percolator 查询。

percolator 与治理场景天然契合，因为它正是以控制平面所需的方式反转了搜索方向。本文将逐步讲解实现过程：先清晰说明 percolator 的作用及其重要性，再介绍索引设计、策略存储、查询时评估和多策略组合。

常规搜索的工作原理

在电子商务系统中，您可能拥有数十万甚至数百万个产品文档，其中包含 title、category 和 price 等字段。当用户搜索匹配文档时，实际上是在让 Elasticsearch 将用户的搜索字符串与这些产品文档中存储的一个或多个字段进行比较。作为 Elasticsearch 的默认分析器，standard analyzer（标准分析器）会将文本转为小写，并将其拆分为词元。搜索 “oranges” 会匹配 “Oranges”，因为分析器会执行小写化处理。使用包含词干提取功能的语言感知分析器时，它也会匹配 “orange”，因为这两种形式都会归约到相同的词干。例如，以下 match 查询会返回 “title” 字段中包含 “orange” 或 “oranges” 的文档。

因此，对于上述查询，Elasticsearch 会返回 title 字段与 “oranges” 匹配的产品文档，结果可能包括 “Orange Fruit Spread”“Orange Juice”“Juicy oranges”“Orange Marmalade” 等。需要记住的关键点是：Elasticsearch 通常用于将搜索字符串与文档进行比较，并返回与该搜索字符串匹配的文档。

治理问题：搜索产品前先找到相关策略

如第 1 部分至第 3 部分所述，受治理的搜索系统不会将用户的搜索字符串直接发送到产品目录。它会先检查是否有策略适用于该搜索字符串。

一位商品经理决定，当有人精确搜索 “oranges” 时，结果应限制在 Oranges 类别中，从而排除 orange juice、orange marmalade 和 orange soda。这一业务决策会存储为一项策略。当用户输入 “oranges” 时，控制平面需要找到该策略，读取其指令，并相应修改针对产品目录的搜索。为此，控制平面需要确定哪些已存储的策略与该搜索字符串相关。

企业部署中可能有数百甚至数千项此类策略。使用 if/else 逻辑逐一检查这些策略，正是第 2 部分所述的应用层反模式。我们需要一种方法，将所有策略存储在一个索引中，并即时找到与给定搜索字符串匹配的策略。这正是 percolator 发挥作用的地方。

反转方向：percolator

我们之前提到，在常规搜索中，Elasticsearch 通常用于将搜索字符串与文档进行比较，并返回包含该搜索字符串的文档。

percolator 会反转这一过程。使用 percolator 时，您会拥有一个索引，其中每个文档都存储一个查询模式。随后，系统会将传入的搜索字符串与这些已存储的查询进行比对，以确定哪些已存储的查询模式被触发。

在治理场景中，“已存储的查询模式”就是策略。每项策略都包含一个模式，用于描述它应匹配哪类搜索字符串。例如，搜索字符串是精确匹配 “oranges”，还是包含 “olive oil”？传入字符串是用户的搜索文本，它会在查询时到达，并需要与所有已存储的策略模式进行比对。相关 PRISM 视频的 4:09 处对此进行了介绍。

逐步解析：搜索 “oranges” 如何找到对应策略

策略

一位商品经理编写了一项策略，用于在用户仅搜索 “oranges” 且不包含任何其他词时触发匹配。percolator 匹配后，文档的其余部分会包含控制平面用于构建产品查询的规则；在本例中，其中一条规则是将结果限制（过滤）到 Fruits 类别。

percolator 字段包含用于定义该策略何时触发的模式。在这种情况下，它会匹配短语 "START oranges END"。rule_type 和 rule_args 字段定义该策略触发时应执行的操作。START 和 END 令牌是边界标记，我们稍后会对此进行说明。

您可以在 PRISM Studio UI 中查看策略的创建方式，详情请参阅相关 PRISM 视频的 2:52 处。

用户发起搜索

购物者在搜索栏中输入 “oranges”。

控制平面检查是否存在匹配策略

在搜索产品目录之前，控制平面会拦截用户搜索字符串，用边界标记将其包裹起来，并将其发送到 percolator：

字符串 "START oranges END" 会与所有已存储的策略模式进行比对。Elasticsearch 会在内部针对此字符串运行已存储的策略模式，并返回匹配项。这就是 percolator 的运行机制。系统将用户的搜索字符串与所有已存储的策略模式进行匹配，并返回匹配项。无需 if/else 语句链。无需顺序评估。匹配由索引处理。

控制平面应用策略

控制平面读取匹配策略的操作。上述策略指示控制平面将结果限制为水果类别。控制平面按如下方式构建针对产品目录的最终 Elasticsearch 查询：

用户搜索的是 “oranges”。产品目录收到一个受 Fruits 类别约束的 “oranges” 查询。由于这一约束，Orange Juice、Orange Marmalade 和 Orange Soda 会被排除。

为什么 “orange marmalade” 不会触发 oranges 策略

假设另一位用户搜索 “orange marmalade”。控制平面会包裹该字符串并执行 percolator 匹配："START orange marmalade END"。oranges 策略的模式是 match_phrase: "START oranges END"。oranges 策略不匹配，因此不会应用该策略，结果也不会限制在 Fruits 类别中。

这就是 START 和 END 边界标记的作用。没有这些标记时，匹配 “oranges” 一词的策略可能会被 “orange marmalade” 这样的查询意外触发。通过使用 START 和 END 包裹用户的搜索字符串，并在策略模式中包含这些标记，我们可以确保该策略仅在 “oranges” 是完整搜索字符串且不包含其他词时触发。这同时符合购物者和商品经理的意图。

第二项策略：基于词干化字段的 “olive oil”

并非每项策略都需要精确字符串匹配。“olive oil” 策略会在词干化字段上匹配，因此即使存在轻微词形变化，也会触发：

此策略的模式会匹配 query.stemmed，而不是 query。当用户的搜索字符串到达时，它会同时存储在 query 字段（精确文本）和 query.stemmed 字段中（使用词干提取分析器进行分析，该分析器会将单词归约到词干，因此 “olives” 和 “olive” 会归约为相同词干，“oils” 和 “oil” 也是如此）。该策略的模式会与字符串的词干化版本进行比对，因此即使存在轻微词形变化，也会触发。

START 和 END 边界标记同样适用于词干化字段，确保该策略仅在 “olive oil” 是完整搜索字符串时触发，而不会在它作为较长搜索字符串的一部分出现时触发。

本文其余部分将介绍让该方案可用于生产环境的实现细节：支持两种匹配模式的索引映射、高亮如何驱动短语移除和已消耗短语跟踪，以及多个冲突策略如何组合成单一执行计划。

策略索引映射

策略索引需要一个 percolator 字段来保存已存储的查询模式，还需要一个文本字段，其结构与传入搜索字符串保持一致，供 percolator 匹配。为便于理解，以下映射经过简化。生产部署更加复杂，会使用自定义分析器来处理边界标记、可变模式匹配（例如识别 “under $4” 包含货币值）以及其他类型的分析。

该索引命名为 policies，因为每个文档都代表第 2 部分中定义的一项完整受治理策略，其中包括匹配条件、操作、优先级和元数据。rule_type 和 rule_args 字段包含策略的操作组件，其中的指令将由控制平面用来组合查询，并针对产品目录执行该查询。

query 字段是 percolator 用于匹配的字符串。它有两个变体：精确版本和词干化版本。当用户的搜索字符串到达时，它会被放入临时内存索引中的这个字段。匹配 query 的策略会看到精确字符串；匹配 query.stemmed 的策略会看到词干化版本。

结合高亮、筛选和排序进行 percolator 匹配

上述简单示例展示的是最简 percolation 请求。在实际应用中，控制平面会添加高亮、过滤已禁用策略，并按优先级排序：

高亮配置使用 "query" 作为字段键，并在 matched_fields 中包含 "query.stemmed"。这会告诉 Elasticsearch 的 unified highlighter 在父 query 字段上返回高亮，同时在确定要高亮哪些词元时，也考虑来自 query.stemmed 子字段的匹配项。这样一来，基于词干化字段匹配的策略仍能在原始文本上生成准确的高亮片段；控制平面需要这些片段来执行短语移除和已消耗短语跟踪。

enabled: true 筛选器可确保跳过已禁用的策略。基于优先级的 sort 可确保优先级较高的策略先返回，使控制平面能够按照正确顺序处理它们，以执行级联转换。highlight 字段是最重要的新增内容；它能准确告诉我们用户搜索字符串中的哪些词触发了每次匹配。

“olive oil” 搜索的响应可能如下所示：

高亮为何重要

请注意响应中的高亮："<em>START olive oil END</em>"。Elasticsearch 正在准确告诉我们，用户搜索字符串中的哪些词导致了策略匹配。这并不是为了美观。高亮元数据会驱动两个关键的下游行为：

短语移除。有些策略需要在构建产品目录查询之前，从搜索字符串中移除匹配文本。例如，匹配 “cheap” 的策略会移除该词，并将其转换为价格过滤器。高亮会准确标识搜索字符串中与策略匹配的区间，因此系统知道要移除哪些内容。

已消耗短语跟踪。如第 3 部分所述，当多个策略匹配同一搜索字符串时，优先级较高的策略可能会移除优先级较低的策略也匹配到的词。通过将每项策略的高亮与当前（不断演变的）搜索字符串进行比较，系统可以检测到某个短语已被消耗，从而跳过优先级较低的策略。这样可以防止重复处理，并确保行为具有确定性。

您可以在这篇文章中详细了解高亮的工作原理。

从 percolator 匹配到执行计划

percolator 会返回一组匹配的策略。但如第 3 部分所述，查找只完成了一半。另一半是将这些匹配项组合成一个连贯的执行计划。下面以一个具体查询为例说明。

示例：圣诞活动期间的 “Cheap chocolate”

假设系统有两个有效策略：“Cheap chocolate” 策略（优先级 210）和 “Christmas chocolates” 策略（优先级 300），这两个策略均已在第 3 部分中详细介绍。

第 1 步：执行 percolator 匹配。用户搜索 “cheap chocolate”。控制平面将搜索字符串包装为 "START cheap chocolate END"，并将其发送到 percolator。有两项策略匹配：“Cheap chocolate” 策略的模式匹配短语 “cheap chocolate”；“Christmas chocolates” 策略的模式则通过词干化字段匹配 “chocolate”。

第 2 步：按优先级排序。percolator 返回两个策略，并按优先级降序排序。系统会先处理 “Christmas chocolates” 策略（300），再处理 “Cheap chocolate” 策略（210）。

第 3 步：应用级联转换。这就是第 3 部分中的 initial state → [Policy A] → state' → [Policy B] → state'' → execution plan 模型。

“Christmas chocolates” 策略（优先级 300）首先应用：

• 添加类别硬性过滤器：“Christmas foods and drinks”、“Christmas sweets”。

• 添加价格过滤器：低于 $7。

• 添加类别软性提升：“Advent calendars” (3x)。

接下来，“Cheap chocolate” 策略（优先级 210）会应用于修改后的状态：

• 尝试添加硬性类别过滤器：“Chocolates”、“Milk chocolates”；但 Christmas 策略已使用 on_conflict: override 设置该字段，因此 Cheap chocolate 类别会被丢弃。

• 尝试添加价格过滤器：$2，圣诞节政策将价格设置为 on_conflict: restrict，而 $2 比 $7 更严格，因此 $2 获胜。

• 从搜索字符串中移除 “cheap”。

第 4 步：构建 Elasticsearch 查询。控制平面将执行计划组装为针对产品目录的单个 Elasticsearch 查询：

原始搜索字符串是 “cheap chocolate”。到达产品目录的查询是一个受治理且具备意图感知能力的检索计划：“cheap” 一词已被消耗并转换为价格约束，结果限制在圣诞季节性类别中，Advent calendar 产品获得排名提升，价格上限则采用较低优先级策略中更严格的值。每一次转换都是确定性的、可追溯且可解释的。

如需快速了解这些乘数如何与 BM25 基础分数相互作用，请参阅相关 PRISM 视频的 8:45 处，其中简要讨论了乘法提升（multiplicative boosts）。

为何具备扩展性

由于这种不对称性，percolator 在此用例中非常高效：企业电子商务系统可能拥有数百万个产品，但只有数百或数千项治理策略。percolator 会将一个传入搜索字符串与那组已存储的策略模式进行比对，而不是扫描完整产品目录。开销与策略数量成正比；同时，Elasticsearch 会应用内部优化（例如从已存储的查询模式中索引词项、对布尔逻辑进行短路处理），以保持快速匹配。

添加新策略只是为一个新文档建立索引。禁用策略只是更新一个字段。无需修改代码，无需部署，无需重启。

从查找到受控检索

percolator 提供了快速反向匹配原语，让第 3 部分介绍的控制平面架构在规模化场景中切实可行。策略是一种数据，会被存储和索引，并能与传入的搜索字符串进行高效匹配。控制平面通过第 3 部分所述的级联转换和逐字段冲突解决，将匹配策略组合成受治理的执行计划。随后，检索引擎会针对产品目录执行该受治理的执行计划。

由此形成的系统可让商品经理在不改动应用程序代码的情况下创建新策略，针对代表性查询进行测试，将其推广到生产环境，并立即看到效果。percolator 让策略查找更快速；控制平面让策略组合具有确定性；受治理的工作流则让整个流程更加安全可靠。

本系列内容预告

本系列的下一篇文章会将受治理的控制平面拓展到新领域。文中将介绍一种多层搜索架构，说明如何在保持稳定分页和分面的同时，编排严格检索、宽松检索和语义检索。

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

本文介绍的基于 percolator 的控制平面，从索引映射和边界标记，到由高亮驱动的短语跟踪和级联策略组合，均由 Elastic Services Engineering 构建，是我们可复用电子商务搜索加速器的一部分。本文展示的每个查询示例和策略结构，均来自一个已针对企业级产品目录完成验证的实际运行系统。

如果您希望在 Elasticsearch 上实现一个受治理、由策略驱动的控制平面，Elastic Services 可以帮助您更快达成目标。请联系 Elastic Professional Services。

加入讨论

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

为何查询解释常常是一个挑战

将策略作为代码存储（应用层中的 if/else 块）会产生成千上万行脆弱逻辑，而且没有任何索引可用于在查询时高效检索策略。迭代速度很慢（单个查询行为变更可能需要 6 周的部署周期），责任归属不清（为什么结果会发生变化？），并且业务用户无法在没有工程团队介入的情况下修改搜索行为。下图左侧展示了这一点：

上图右侧展示了将策略作为数据存储在 Elasticsearch 索引中的方式。这种方法解决了硬编码查询求解逻辑所带来的所有问题。然而，要使其奏效，您需要一种方法来快速确定哪些策略适用于用户查询，以及应如何解决冲突。这正是治理型控制平面发挥作用的场合。

控制平面模式

受治理的控制平面位于原始用户查询和 Elasticsearch 检索之间。它接收用户文本作为输入，输出一个包含筛选器、提升规则和检索路由决策的执行计划。

控制平面流水线包括：

1. 用户查询：用户输入表示自己要查找内容的字符串，例如 “oranges” 或 “gift for grandpa”。

2. 策略查找：将用户查询与策略索引进行匹配。

3. 返回匹配策略：从策略索引中返回与用户查询匹配的策略。

4. 策略应用：控制平面分析这些返回的策略，并将匹配策略组合成一个单一、连贯的执行计划。该计划包括筛选器、提升规则、覆盖规则和护栏，并会应用适当的检索方法（例如词汇检索、语义检索或混合检索）。

5. 执行：修改后的意图感知型 Elasticsearch 查询会传递给应用程序，并针对产品目录索引执行。

6. 解释（可选）：除了创建能够提供与业务和意图一致结果的查询外，控制平面还会提供一个可选的可解释性数据载荷，用于显示触发了哪些策略，以及这些策略如何组合。

要确定应对用户的搜索字符串应用哪些策略，需要一个快速反向匹配原语；我们使用 percolator 查询来解决这个问题。检索到相关策略后，要将多个匹配策略组合成统一的执行计划，还需要一个判断框架：优先级、冲突策略、已消耗短语跟踪，以及按顺序而非独立地应用策略的级联转换。此外，还需要选择最合适的检索技术（例如针对 “oranges” 使用 BM25，针对 “gift for grandpa” 使用语义搜索）。

策略查找：搜索产品前检查查询语句

当购物者输入查询时，带有受治理控制平面的搜索系统不会直接将该查询发送到产品目录执行。系统会先将查询与一组已存储的策略进行比对，然后根据查询意图和业务优先级对其进行修改。

政策结构

每项策略都是一个简单文档，用于定义两件事：

• 匹配条件：哪些查询文本会触发此策略。它可以是精确短语、单个词、某种模式，或以上内容的组合。

• 操作：策略触发时应执行什么操作。这可以是应用类别筛选器、排除产品、提取价格约束，或更改检索策略。

系统会找到所有匹配的策略，将它们组合成一个执行计划，然后才运行产品搜索。综合来看，各项策略就像一位知识渊博的店员，了解您想要什么，并引导您找到正确的货架。

策略模式

本系列前几篇文章介绍了策略应用的示例：将 “oranges” 限制在蔬果类别，将 “without peanuts” 视为排除条件，并将 “gift for grandpa” 路由到语义检索。关键的架构要点是，在每种情况下，都会先将查询与已存储的策略进行比对，然后才开始产品搜索。这些策略决定要应用哪些约束、修改哪些文本，以及使用哪种检索策略。只有在策略应用完成并创建新的重写查询之后，才会针对产品目录执行查询。

为何它如此快速

企业电子商务系统可能有数百万种产品，但只有数百或数千项策略。策略查找步骤是在一个经过整理的小型索引中搜索，而不是搜索完整产品目录，因此速度很快。此外，由于策略作为数据存储在自己的索引中，商品经理添加新策略时无需改动应用程序代码，工程师优化产品搜索时也无需改动策略索引。这两项职责可以独立演进。

以上例子从概念上描述了所发生的情况。在底层，策略查找是通过 Elasticsearchpercolator 查询类型实现的，该类型专为这种模式设计：将传入文本与一组存储的查询进行匹配。本系列的第 4 部分深入探讨了 percolator 的实现，包括索引映射、边界标记和高亮驱动的短语跟踪。在第 4 部分深入介绍了查找机制之后，我们来探讨策略文档的实际内容，以及控制平面如何将多个策略组合成单一的执行计划。

策略示例

既然我们已经从概念上了解了策略的作用，接下来看看它们实际包含哪些内容。以下两项策略有意设计为相互冲突，用于演示后续章节介绍的冲突解决系统。

廉价巧克力

下面显示的策略会检测用户提交的搜索是否包含短语 “cheap chocolate”。如果包含，则将结果限制在 “Chocolates” 和 “Milk chocolates” 类别中。该策略还会应用 $2 的价格筛选器。此外，请注意，该策略的优先级为 210；我们会在更详细讨论冲突解决时回到这一点。

此处显示的筛选器模式和冲突策略设置（hard_filter、soft_boost、restrict、override）将在下方的冲突解决部分详细说明。

启用上述策略后，搜索 “cheap chocolate” 会遵循 $2 的价格筛选条件，并将结果限制在 “Chocolates” 和 “Milk chocolates” 类别中。示例结果如下所示：

圣诞巧克力

下面显示的策略示例适用于圣诞节场景。此示例会将结果限制在 “Christmas foods and drinks” 和 “Christmas sweets” 类别中，提升同时属于 “Advent calendars” 类别的所有产品，并应用低于 $7 的价格筛选器，以重点展示价格适中的季节性商品。此外，请注意，该策略的优先级为 300。我们会在更详细讨论冲突解决时回到这一点。

在没有任何冲突策略的情况下启用上述策略时，搜索 “chocolate” 会遵循 $7 的价格筛选器，将结果限制在 “Christmas food and drinks” 和 “Christmas sweets” 类别中，并提升任何标记为 “Advent calendars” 的产品。示例结果如下所示：

组合匹配策略

上文所述的策略查找只完成了一半。另一半是当多个策略匹配同一个查询时会发生什么。

在任何较为复杂的部署中，单个查询通常会同时触发多项策略。“Cheap chocolate” 会同时匹配我们在上文演示的两项策略。每项策略单独来看都是正确的。真正的挑战在于将它们组合成一个单一、连贯的执行计划，避免矛盾、重复计算，也避免某项策略悄然抵消另一项策略的作用。

这不是查找问题，而是判断问题。系统必须做出决定：

• 应用顺序：如果否定策略从查询中移除了 “without peanuts”，那么价格策略看到的还是原始文本，还是修改后的文本？

• 筛选器冲突：如果两项策略设置了不同的价格上限，哪一个会生效？未生效的一方会被静默丢弃，还是会平滑降级为软性提升？

• 短语归属权：如果两项策略都匹配同一个词，而第一项策略已经消耗了该词，第二项策略是否仍应触发？

一种朴素实现方式（独立应用所有匹配策略，然后合并结果）会在策略发生交互时失效。该架构需要一个显式模型来描述策略如何组合。接下来的两节将介绍这个模型：优先级和冲突解决框架，以及让策略交互具有确定性的级联转换模型。

核心在于，策略应用不是一组独立操作，而是一个级联转换。每项策略都会接收由所有更高优先级策略生成的重写状态，并在此基础上继续转换：

初始状态 → [策略 A] → 状态' → [策略 B] → 状态'' → … → 执行计划

状态会携带重写后的查询文本、累积的筛选器、当前意图以及所有同义词扩展。高优先级策略可以从查询中移除文本，而每项后续策略看到的都是修改后的查询，而不是原始查询。上下文会不断累积。顺序至关重要。

优先级与冲突解决：确定性至关重要

具体采用哪些冲突策略属于设计选择。不同组织可能会根据自身业务需求，以不同方式解决冲突。下面的方法展示了控制平面所需的一类判断框架。关键不在于这些具体策略本身，而在于系统需要具备明确、确定性的策略，而不是让冲突通过不可预测的交互自行解决。

优先级排序

策略按优先级排序（优先级最高的在前）。当多个策略匹配同一查询时，它们会按优先级顺序应用。如果两个策略尝试设置同一个过滤字段，则优先级更高的策略对该字段声明的策略优先。如果触发了多个具有相同优先级的策略，则优先级最高的策略（ID 最大）将优先；这种选择确保了冲突发生时的确定性行为。

按字段解决，而非按策略

一个关键设计原则是：冲突解决按字段（例如品牌、类别或描述）进行，而不是按策略进行。当两项策略生成的筛选器在特定字段上重叠时，只有这些特定字段会受冲突解决策略影响，并且解决策略由优先级最高的匹配策略定义。两个策略中未发生冲突的字段会完整保留。

这一点很重要，因为如果采用按策略处理的方法，那么即使只有某一个字段发生冲突，系统也必须接受或拒绝整项策略。

按字段解决可以最大限度保留有用的约束信息。

每个过滤器字段有三种设置

每个策略中的筛选字段都有三个独立的设置：

筛选器模式：没有冲突时如何应用筛选器。

• hard_filter （默认）：作为 Elasticsearch bool.filter 子句应用。这适用于完全排除无关产品。例如，将 “oranges” 的搜索范围限制在 produce 类别中，可以排除 orange juice 和 orange marmalade 等搜索结果。不匹配的文档会从结果中完全排除。

• soft_boost作为 Elasticsearch function_score 权重应用，并可配置 boost_weight。匹配的文档会获得排名提升，但不匹配的文档不会被排除。这适用于提升某个品牌的排名，同时又不排除其他品牌的场景。

冲突策略

当较低优先级的策略设置相同字段时会发生什么：

• override：此高优先级策略的值会生效；较低优先级的值会被完全丢弃。适用于所有字段类型。

• restrict：取限制性更强的数值（例如，price_max 取较低上限，price_min 取较高下限）。仅适用于数值范围字段。

• merge：将两个值合并为并集。仅适用于非数值字段。

• soft_boost：将冲突的筛选器转换为具有可配置 boost_weight 的 function_score 权重，而不是硬性筛选器。有关 function_score 提升的更多详情，请参阅《在 Elasticsearch 中使用乘法提升影响 BM25 排名》。这仅适用于非否定字段。

值：实际筛选值（例如，类别列表、价格阈值）。

按字段类型划分的策略：并非所有策略都适用于所有字段类型。例如，排除本质上是二元决策，因此不能进行软性提升。下表显示了每种字段类型可用的策略：

字段类型

可用策略

默认值

否定字段 (__not, __match__not)

override、merge

覆盖

数值范围字段 (__max, __min, __gt, __lt)

限制、覆盖、软提升

限制

所有其他字段（关键词、文本）

soft_boost、override、merge

soft_boost

否定字段不能进行软性提升，因为排除逻辑本质上是二元决策。将 “never show canned foods” 转换为 “slightly prefer not-canned-foods” 会从根本上改变语义；来自 “canned foods” 的产品仍然会出现，只是排名略低，这违背了排除的初衷。

具体示例：圣诞活动期间搜索 “cheap chocolate”

假设商品经理已经创建了我们之前演示的两项巧克力策略：一项是针对 “cheap chocolate” 的较低优先级策略，另一项是在圣诞节期间启用的较高优先级巧克力相关策略。如果这两项策略都已启用，那么它们的组合方式取决于优先级更高策略的筛选器模式和冲突策略。如果前面讨论的两项策略都已启用，它们将按如下方式组合：

这里显示了两个冲突：一个发生在类别上，另一个发生在价格上。值得注意的是，此次转换之后将要执行的查询具有以下特征：

• 仅展示属于 “Christmas foods and drinks” 和 “Christmas sweets” 类别的产品。

• 在这些类别中，如果产品还被标记为 “Advent calendars” 类别，则会获得 3 倍排名提升。

• 应用了 $2 的价格筛选器，该筛选器来自较低优先级策略（因为较高优先级策略指定在发生冲突时使用 “Restrict”）。

• 移除 “cheap” 一词，仅返回与 “chocolate” 匹配的产品。

启用这两项策略后，“cheap chocolate” 返回的结果类似于下图所示：

放宽限制

也许零售商并不希望在圣诞节期间排除 “Chocolates” 和 “Milk chocolates” 类别中的产品。Christmas 策略的设置可能过于强势，无意中移除了 “cheap chocolate” 策略应用的类别。这个示例说明，在某些情况下，将较低优先级策略与存在冲突的较高优先级策略组合起来，可能更符合业务需求。例如，我们可以修改 Christmas chocolates 促销策略，使其在发生冲突时不使用 “Override”，而是采用软性提升。该策略的变更如下：

完成此修改后，“cheap chocolate” 的查询重写转换流水线如下所示：

通过对冲突的软提升，冲突的筛选器被转换为软提升，而不是被丢弃。在此转换之后将在商品目录上执行的查询具有以下特征：

• 由于较高优先级策略的 “On conflict” 设置为 “Soft boost”，冲突将按如下方式转换为提升：

  • “圣诞食品和饮料”以及“圣诞甜点”类别的产品将会获得 1 倍的提升。

  • “Chocolates” 和 “Milk chocolates” 类别中的产品会获得 3 倍提升。

• 与前面的示例一样，如果产品还被标记为 “Advent calendars” 类别，则会获得 3 倍提升。

• 与前例相同，会应用 $2 的价格筛选器。

• 移除 “cheap” 一词，仅返回与 “chocolate” 匹配的产品。

放宽筛选条件后，结果如下所示：

使用高优先级策略中的价格覆盖原有价格

或者，零售商可能希望通过将最高价格提高到 $7，允许在圣诞节期间展示价格稍高的巧克力。为了确保有人搜索 “cheap chocolates” 时，Christmas chocolates 策略中的最高价格不会被覆盖，我们可以将价格的冲突模式设置为 “override”，而不是 “restrict”，如下所示：

通过这种覆盖，“廉价巧克力”查询忽略了“廉价巧克力政策”中定义的最高价格，仅应用“圣诞巧克力”政策中规定的价格，具体如下：

这与上一个示例类似，不同之处在于最高价格会设置为较高优先级策略中的 $7，因为该策略指定在发生冲突时使用 “Override”。当 Christmas 价格筛选器优先生效时，结果如下所示：

这三种变体（override、soft_boost 和价格覆盖）展示了该系统的一项关键特性：商品经理只需修改单一策略中某个字段的设置，即可改变两项策略的交互方式，而无需部署任何代码。冲突策略是控制业务行为的杠杆。

已消耗短语跟踪

还有一种更微妙的冲突形式：两项策略匹配同一个短语。如果优先级较高的策略从查询中移除了 “without peanuts”，那么同样匹配 “without” 的较低优先级策略就没有可作用的内容。系统会检测重写后的查询中是否已不再存在该匹配短语，并跳过优先级较低的策略。

意图策略不受已消耗短语跟踪影响：它们会根据原始查询匹配结果设置检索策略，而不考虑更高优先级策略移除了哪些文本。

优先级排序、每字段冲突解决以及消耗短语跟踪共同为控制平面提供了一个确定性组合模型。有了这个基础，系统可以做出在没有它的情况下可能存在风险的路由决策。

治理让检索策略更安全

关于路由到正确检索方法（文本、语义或混合），一个重要见解是：这一过程发生在治理之后。如果您的策略已经强制应用 “produce category”，那么语义检索的风险会低得多，因为候选集已经受到约束。对 500 个产品项执行语义搜索，与对 500,000 个 SKU 执行语义搜索，完全是两种不同的情况。治理会在检索开始前缩小爆炸半径，从而降低风险影响范围。

例如，如果没有治理，对 “Fruit high in vitamin C under $4” 进行语义查询时，除了水果之外，可能还会返回瓶装维生素、胡萝卜和青椒。控制平面会确保这些不需要的结果甚至不会被纳入语义扩展的考虑范围。

在该约束生效后，控制平面会应用务实的路由逻辑：

• 词汇检索用于导航型查询和高频头部查询，即确定性精度至关重要的场景。

• 语义检索用于描述性发现查询，即概念匹配能够发挥作用的场景。

• 在约束已执行且业务接受更广泛召回的情况下，选择性使用混合检索。

从架构到实施

受治理的控制平面会将业务意图转化为确定性、可组合的执行计划，而无需将该逻辑嵌入应用代码。策略就是数据：在查询时进行匹配，通过显式的逐字段冲突策略解决冲突，并作为级联转换应用，从而生成可解释的结果。Elastic Services Engineering 已为企业电子商务团队构建并部署了这种架构，并使用可复用的模式和加速器，缩短从概念到生产落地的路径。您可以在 YouTube 上观看我们控制平面实现的演示：在数秒内修复搜索相关性：PRISM 简介。

本系列内容预告

下一篇文章将通过实际操作介绍实现过程：Elasticsearch percolator 如何驱动策略查找，包括索引映射、边界标记、高亮驱动的短语跟踪，以及具体查询示例。

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

本文介绍的控制平面架构（逐字段冲突解决、级联策略转换和受治理约束的检索路由）由 Elastic Services Engineering 设计并构建。本系列展示的每个模式、截图和转换流水线，均来自由 Elastic Services Engineering 构建，并已针对企业级产品目录完成验证的实际运行系统。

如果您希望在 Elasticsearch 上实现一个受治理、由策略驱动的控制平面，Elastic Services 可以帮助您更快达成目标。

加入讨论

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

词汇检索（文本匹配）、语义检索（概念匹配）和混合检索（结合词汇和语义信号）本身并不能解决这些问题。词汇检索可能返回所有包含“橙子”的结果，而针对“橙子”这类高意图查询的纯语义检索，则可能扩展至相关商品（如柠檬或葡萄柚）。混合检索虽能融合词汇与语义信号，但仍无法判定该查询应被视为导航型搜索、需应用哪些约束条件，或应遵循何种业务规则。问题根源不在于检索技术本身，而在于缺乏治理层。该层级需在检索启动前，识别查询类型并确定需执行的约束规则。

在这篇博文中，我们将探讨电子商务搜索管理、其重要性以及控制层如何确保可预测的准确检索。

电子商务搜索中的治理含义

在此语境下，治理意味着在用户查询与检索引擎之间引入决策层。该层执行以下功能：

• 对查询意图进行分类：这是导航（“橙子”）还是发现（“送给爷爷的礼物”）？

• 适用业务限制：适用哪些类别界限、资格规则、供应限制或商品推广政策？

• 通向适当策略的路径：这应该使用词汇检索、语义检索，还是混合检索？

治理层决定每次查询应使用哪种检索方法，必须执行哪些限制条件，以及在检索开始前应适用哪些业务策略。重要的是不要将治理层与混合检索混为一谈：混合检索是一种结合了词汇和语义信号的检索策略，而治理层是决定应使用词汇检索、语义检索还是混合检索的上游决策层。

现状：应用层“spaghetti”的实现

当前，许多零售商试图通过直接在应用层添加逻辑来解决这一问题，但这往往导致“意大利面代码”，即由数千行硬编码的条件语句、正则表达式和复杂搜索模板堆砌而成的代码结构。

这种方法可以提供如上所示的期望搜索结果；然而，它会产生很大的操作障碍：

• 工程依赖问题：业务人员与商品运营团队若需修改搜索行为，必须通过提交工程工单并经历长达数周的部署周期，导致操作效率低下且灵活性受限。

• 碎片化：搜索逻辑分散于应用代码与搜索模板之间，难以解释或审计，导致后续迭代风险陡增。

即使团队认识到路由规则的必要性，争论也常常集中在错误的问题上：选择哪种检索方法。

错误的选择：词汇、语义与混合

搜索团队经常将挑战描述为检索策略的选择：词法/BM25、语义/向量和混合。这种框架是可以理解的（检索方法很重要），但它忽略了实际部署中最常见的失败模式，即对所有查询使用单一检索方法会导致次优结果。

商业搜索融合了几种截然不同的意图：

• 确定性、高意图导航（“橙子”、“牛奶”、“不含花生的巧克力”、“廉价橄榄油”）。

• 探索发现（“山区徒步旅行夹克”，“送给喜欢机器人的 12 岁孩子的礼物”）。

• 运营限制（供应、尺寸、价格、颜色）。

• 商品推广与活动（包括流量提升、降权、季节性活动）

当系统通过相同的检索策略来处理所有这些问题时，由于运行模式缺乏管理，结果往往会以可预见的方式出现系统性错误。当团队没有意识到这是一个治理缺口时，他们会用他们唯一掌握的手段来应对，那就是进行更多的调整。

为何“相关性调整”会周而复始

如果没有路由层，“相关性”通常会变成永无止境的待办事项：

• 为何此查询结果将配件显示在核心产品之上？

• 为什么这个主查询突然开始出现相关内容？

• 为什么在我们添加同义词、调整分析器或启用混合模式后，结果发生了变化？

• 为什么业务团队需要一个工程版本来修复一个查询？

团队的回应是更多的调整：更多的同义词，更多的提升，更多的重新排名的实验，更多的应用程序代码中的异常。这种方法可以维持一段时间，但常常导致脆弱行为，因为系统仍缺乏明确的决策层来确定查询类型并在检索前强制执行正确的约束。

剖析电子商务意图：“头部”与“尾部”

在本节中，我们采用“头部”与“尾部”作为电商领域中常见导航与探索性查询模式的实用简称。实际上，许多查询都同时包含这两方面的特征：

头部查询（确定性意图）

这些是直接的导航查询，用户清楚地知道自己想要什么：

• 单项意图（“橙子”、“牛奶”、“面包”）。

• 具体品牌或产品系列（例如“iPhone 15 Pro”、“健怡可乐”）。

• SKU、型号、尺寸（“ABC123”、“air max 270”）。

对于这些查询而言，词汇检索能够处理词元对应关系（即匹配单词），但业务层面还期望能够遵循相关限制条件、返回可预测的排序结果，并确保结果可控。商品运营人员需要确保查询在正确的类别范围内得到解析，遵循适用性规则，并凸显特定的业务优先级。

需要建立治理机制以确保查询按预期分类解析。例如，“橙子”应归类至生鲜蔬果类别，而非橙汁、橙酱或橙味汽水等细分品类。

尾部查询（探索性发现）

这些是描述性强、意图明确的查询，购物者通过此类查询进行探索性搜索：

• “送给爱吃甜食的爷爷的礼物”

• “山区徒步旅行夹克”

• “适合全天站立的鞋子”

在这方面，词汇检索往往会遇到问题。语义检索之所以出色，是因为它能将查询概念与产品联系起来，即使在措辞不匹配的情况下也是如此。但仅靠语义检索也很少能达到要求。无论使用哪种检索方法，实际查询通常都需要执行限制条件。

约束条件与检索方法正交

对语义检索进行约束并不意味着混合搜索。这些都是正交的概念。诸如 Elasticsearch 中的过滤器和增强等约束条件可以应用于任何词汇、语义或混合检索。所面临的挑战是决定如何解释查询、必须执行哪些约束条件以及使用哪种检索策略。

以下是一些结合检索与硬约束的查询示例：

• 橙子：对“橙子”进行词汇检索，并加上类别限制，如“水果”或“农产品”，排除橙子果酱、橙汁和橙汽水。

• 价格低于 4 美元且富含维生素 C 的水果：营养意图语义检索加上限制条件，结果仅限于水果类别和 4 美元以下的产品。

• 舒适的工作鞋：针对上下文意图的语义检索加上限制结果为鞋的类别约束。

这些查询无法通过单一方法来处理：

• 纯词汇检索在此场景下往往不足，因为“富含维生素 C”或“舒适”等短语可能并非以清晰的结构化属性形式存在。这类信息通常需从产品描述、用户评价或规格参数中推断得出。

• 纯语义检索往往也不足，因为如果没有明确限制，像“富含维生素C的水果”这样的查询可能会扩展到维生素补充剂、水果味饮料或高维生素蔬菜，超出预期类别和价格范围。

治理层决定查询是否需要词汇检索、语义理解、约束执行或这些方面的组合。如果没有这一层，电子商务团队可能会最终：

• 过度限制：将词汇检索用于语义请求（例如“送给爷爷的礼物”）。

• 限制不足：对高意图的头部查询使用语义查询（例如“橙子”）。

治理挑战在于构建一个能够针对每类查询做出正确判断的系统。

在没有治理的情况下会发生什么

最常见的故障模式很简单：团队直接获取原始用户查询并将其传递给单一检索策略（词汇、语义或混合），而没有中间治理层。

词汇检索未能达到预期的解析效果

当用户搜索“橙子”时，词汇检索策略可能会返回任何包含该词项的内容：橙汁、橙子果酱或橙子汽水。系统正确匹配了该术语，但如果没有治理，它可能无法解析预期的购物上下文（水果）。

语义检索的范围已超出预期限制

当用户搜索“橙子”时，语义系统可能会检索邻近产品概念中与概念相关的项目。系统可能会正确理解更宽泛的领域（水果或农产品），但如果没有明确的治理，它仍然会超出用户的预期限制（具体来说就是橘子）。

差距在于治理

所需的是一个上游决策层，该层在检索开始之前确定查询意图并强制执行正确的约束条件。这解决了以下问题：

• 类似或相关的项目会出现在用户实际想要的项目旁边。

• 模糊的类别界限（“饮料”与“农产品”）。

• 无法进行季节性促销或活动。

• 不可预测且无法解释的结果。

意图理解与路由规则：必要的控制平面

治理型搜索系统在检索前（在 Elasticsearch 中执行查询之前）引入了一个轻量级控制平面。控制机制将在本博客系列的第 3 部分和第 4 部分中详细讨论。目前，我们只讨论它能做什么，而不谈具体工作原理：

控制平面可以理解意图、应用业务策略，并确保采用适当的检索策略，具体如下：

1. 检测意图信号

• 此查询是导航型还是发现型？

• 这是已知的头部查询（牛奶、面包、香蕉）吗？

• 是否有已知的产品、品牌或类别解释（例如，“橙子”应解析为农产品）。

• 查询是否为类似 SKU 的模式？

• 查询是否属于活动或季节性政策（例如圣诞节期间，提升与火鸡相关的结果）？

• 查询是否包含约束条件（类别、属性、排除项、价格/尺寸/颜色）？

2. 应用治理与业务政策

• 首先强制执行确定性约束（类别/属性/否定/可用性）。

• 应用当前有效的商品推广策略（提升/下调/置顶/覆盖）。

• 通过优先规则解决冲突（例如活动覆盖与全局策略）。

3. 选择合适的检索策略

• 用于导航/高意图头部查询的词汇（快速、确定性）。

• 为真正的发现查询提供语义检索。

• 在明确业务约束下，结合词汇和语义信号可增加价值的混合搜索。

实际上，控制平面的输出并不只是“使用混合检索”或“使用语义检索”。这是一个受治理的检索方案：对购物者意图的解读、应适用的约束和政策，以及应执行的检索策略。以下几个简单示例可以具体说明这一点：

购物者查询

受治理的解释

检索方案示例

“不含花生的巧克力”

具有硬性排除约束的产品导向查询

巧克力的词义检索以及含有花生的产品的排除过滤器

“廉价橄榄油”

有价格限制的产品/类别查询

针对橄榄油且价格筛选上限设为零售商“低价”阈值的词汇检索

“价格低于 4 美元且富含维生素 C 的水果”

需要语义理解和硬约束的发现查询

营养意图语义检索，限于水果类别，筛选价格低于 4 美元的产品

控制平面会为每个查询选择合适的策略和检索策略，且能够一致、可预测且可扩展。这使得高级检索方法在生产中的可预测性更高，因为首先执行的是意图一致性约束，路由决策为显式而非隐式。

与其他方法的关系

有些团队使用改进的嵌入模型来更好地捕捉产品语义，这可以大大提高语义检索的质量。其他方法则使用重新排序方法（如学习排序 (LTR)），在检索结果生成后基于用户交互或业务指标优化结果排序。这两种方法均有价值且常互为补充。更优质的嵌入向量能提升相似度匹配精度，而重排序可优化候选结果间的排序质量。

治理解决了问题的另一层：它位于检索的上游。它决定应使用哪种检索策略（例如，词汇检索、语义检索或混合检索）、需要哪些确定性约束，以及哪些查询应结合多项业务策略。

受治理控制平面可实现哪些功能

一旦治理层就位，运营模式将发生根本性变革。与收入紧密相关的查询将具备可预测性。业务团队无需等待工程团队的发布周期，即可自主更新搜索行为，而语义检索、混合检索等高级方法，则可通过路由规则和管控机制逐步部署，而非直接全局启用或禁用。

本系列的下一篇文章将探讨该操作模型在实践中的具体表现，以及为什么它可能与其背后的检索技术同等重要。

如果商户必须打开一个 Jira 工单并等待部署来修复一个关键的收入查询，瓶颈不在于引擎；而在于运营模式。现代电子商务搜索需要一种方式，能够快速安全地将业务意图转化为受控、可审计的搜索行为，同时在可测量增值的地方使用高级检索。

本系列内容预告

本系列探讨的模式在检索的上游运行：在查询生成开始之前，将业务意图转化为正确的查询策略。在下一篇文章中，我们将从技术问题转向运营问题：当业务团队无需工程部署即可更改搜索行为时会发生什么，以及为什么治理可以确保安全。

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

在企业级电商服务场景中，工程瓶颈、应用层逻辑脆弱性以及搜索结果不可预测性等问题，均可通过 Elastic Services 的专业服务得以解决。本系列所述的受治理控制平面架构，正是由 Elastic Services 工程团队精心打造。

若您的团队仍在耗费大量工程资源将商品运营需求转化为代码修改，或搜索相关性优化任务积压始终难以缩减，我们可协助评估现有技术架构，并规划一条实现搜索配置业务化、可治理的转型路径。请联系 Elastic Services。

加入讨论

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