为什么电子商务搜索需要治理

电子商务零售商需要在同一系统中处理各种有本质区别的查询类型。搜索“橙子”的购物者期望看到的是这种水果，而不是包含“橙色”一词的产品，例如橙汁或橙子果酱，也不是在语义上相关的柑橘类产品。搜索“送给爱吃甜食的爷爷的礼物”的购物者需要的是语义发现，而不是字面上的关键字匹配。

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

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

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

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

• 对查询意图进行分类：这是导航（“橙子”）还是发现（“送给爷爷的礼物”）？
• 适用业务限制：适用哪些类别界限、资格规则、供应限制或商品推广政策？
• 通向适当策略的路径：这应该使用词汇检索、语义检索，还是混合检索？

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

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

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

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

• 工程依赖问题：业务人员与商品运营团队若需修改搜索行为，必须通过提交工程工单并经历长达数周的部署周期，导致操作效率低下且灵活性受限。
• 碎片化：搜索逻辑分散于应用代码与搜索模板之间，难以解释或审计，导致后续迭代风险陡增。

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

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

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

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

• 确定性、高意图导航（“橙子”、“牛奶”、“不含花生的巧克力”、“廉价橄榄油”）。
• 探索发现（“山区徒步旅行夹克”，“送给喜欢机器人的 12 岁孩子的礼物”）。
• 运营限制（供应、尺寸、价格、颜色）。
• 商品推广与活动（包括流量提升、降权、季节性活动）

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

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

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

• 为何此查询结果将配件显示在核心产品之上？
• 为什么这个主查询突然开始出现相关内容？
• 为什么在我们添加同义词、调整分析器或启用混合模式后，结果发生了变化？
• 为什么业务团队需要一个工程版本来修复一个查询？

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

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

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

头部查询（确定性意图）

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

• 单项意图（“橙子”、“牛奶”、“面包”）。
• 具体品牌或产品系列（例如“iPhone 15 Pro”、“健怡可乐”）。
• SKU、型号、尺寸（“ABC123”、“air max 270”）。

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

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

尾部查询（探索性发现）

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

• “送给爱吃甜食的爷爷的礼物”
• “山区徒步旅行夹克”
• “适合全天站立的鞋子”

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

约束条件与检索方法正交

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

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

• 橙子：对“橙子”进行词汇检索，并加上类别限制，如“水果”或“农产品”，排除橙子果酱、橙汁和橙汽水。
• 价格低于 4 美元且富含维生素 C 的水果：营养意图语义检索加上限制条件，结果仅限于水果类别和 4 美元以下的产品。
• 舒适的工作鞋：针对上下文意图的语义检索加上限制结果为鞋的类别约束。

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

• 纯词汇检索在此场景下往往不足，因为“富含维生素 C”或“舒适”等短语可能并非以清晰的结构化属性形式存在。这类信息通常需从产品描述、用户评价或规格参数中推断得出。
• 纯语义检索往往也不足，因为如果没有明确限制，像“富含维生素C的水果”这样的查询可能会扩展到维生素补充剂、水果味饮料或高维生素蔬菜，超出预期类别和价格范围。

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

• 过度限制：将词汇检索用于语义请求（例如“送给爷爷的礼物”）。
• 限制不足：对高意图的头部查询使用语义查询（例如“橙子”）。

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

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

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

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

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

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

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

差距在于治理

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

• 类似或相关的项目会出现在用户实际想要的项目旁边。
• 模糊的类别界限（“饮料”与“农产品”）。
• 无法进行季节性促销或活动。
• 不可预测且无法解释的结果。

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

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

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

1. 检测意图信号

• 此查询是导航型还是发现型？
• 这是已知的头部查询（牛奶、面包、香蕉）吗？
• 是否有已知的产品、品牌或类别解释（例如，“橙子”应解析为农产品）。
• 查询是否为类似 SKU 的模式？
• 查询是否属于活动或季节性政策（例如圣诞节期间，提升与火鸡相关的结果）？
• 查询是否包含约束条件（类别、属性、排除项、价格/尺寸/颜色）？

2. 应用治理与业务政策

• 首先强制执行确定性约束（类别/属性/否定/可用性）。
• 应用当前有效的商品推广策略（提升/下调/置顶/覆盖）。
• 通过优先规则解决冲突（例如活动覆盖与全局策略）。

3. 选择合适的检索策略

• 用于导航/高意图头部查询的词汇（快速、确定性）。
• 为真正的发现查询提供语义检索。
• 在明确业务约束下，结合词汇和语义信号可增加价值的混合搜索。

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

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

与其他方法的关系

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

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

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

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

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

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

本系列内容预告

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

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

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

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

加入讨论

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