为什么电商搜索需要治理

为什么电商搜索需要治理

为什么电商搜索需要治理

为什么电商搜索需要治

电子商务零售商需要在同一系统内处理多种截然不同的查询类型。比如，当购物者搜索“oranges”时，他们期待的是水果，而不是包含“orange”字样的产品，如橙汁或橘子酱，也不是语义上相关的柑橘类产品。而当购物者搜索“喜欢吃甜食的爷爷的礼物”时，他们需要的是语义发现，而不是字面上的关键词匹配。

词汇检索（文本匹配）、语义检索（概念匹配）和_混合检索_（结合词汇和语义信号）本身并不能解决这些问题。词汇检索可能会返回任何包含“oranges”这个词的内容，而单纯的语义检索可能会在高意图查询如“oranges”时扩展到相关项目，比如柠檬或葡萄柚。混合检索融合了词汇和语义信号，但仍不能确定查询是否应该被视为导航型，哪些约束应该被执行，或哪些业务政策应该适用。问题不在于检索技术本身，而在于缺乏一个治理层，该层需要理解查询的类型并在检索开始前确定应该执行哪些约束。

在这篇文章中，我们将探讨电商搜索治理的重要性，以及如何通过控制层确保检索结果的可预测性和准确性。

电商搜索中的治理是什么

在这里，_治理_意味着在用户查询和检索引擎之间引入一个决策层。该层执行以下功能：

• • 分类查询意图：这是导航型查询（如“oranges”）还是发现型查询（如“给爷爷的礼物”）？
• • 应用业务约束：哪些类别界限、资格规则、可用性约束或商品陈列政策适用？
• • 路由到适当的策略：应该使用词汇检索、语义检索还是混合检索？

治理层决定了每个查询应该使用哪种检索方法，哪些约束必须被执行，哪些业务政策在检索开始前应该适用。重要的是，不要将治理与混合检索混淆：混合检索是一种结合词汇和语义信号的检索策略，而治理是上游的决策层，它决定应该使用词汇、语义还是混合检索。

现状：应用层的“意大利面”实现

目前，许多零售商尝试通过直接在应用层添加逻辑来解决这个问题。这通常导致了“意大利面代码”，即数千行硬编码的if-then语句、正则表达式和复杂的搜索模板。

对比硬编码的应用逻辑和 Elasticsearch，展示 Elasticsearch 如何简化排名和检索而不需要复杂的 if-then 规则。

对比硬编码的应用逻辑和 Elasticsearch，展示 Elasticsearch 如何简化排名和检索而不需要复杂的 if-then 规则。

这种方法可以如上图所示提供理想的搜索结果；然而，它也带来了显著的操作摩擦：

• • 工程依赖性： 业务用户和商品经理无法在没有工程票据和常常持续数周的发布周期的情况下修改搜索行为。
• • 碎片化： 搜索逻辑在应用代码和搜索模板之间变得分散，难以解释或审计，进而使得演变变得风险很大。

即便团队认识到路由的必要性，辩论往往集中在错误的问题上：选择哪种检索方法。

错误的选择：词汇 vs. 语义 vs. 混合

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

商业搜索是不同意图的混合：

• • 确定性的、高意图导航（“oranges”，“milk”，“chocolate without peanuts”，“cheap olive oil”）。
• • 探索性发现（“适合在山里徒步的夹克”，“喜欢机器人技术的12岁孩子的礼物”）。
• • 操作约束（可用性、尺寸、价格、颜色）。
• • 商品陈列和促销活动（提升、埋没、季节性活动）。

当系统将所有这些通过同一检索策略路由时，结果常常以可预测的方式系统性错误，因为操作模型缺乏治理。当团队没有认识到这是一个治理缺口时，他们只能用唯一的手段来应对：更多的调优。

为什么“相关性调优”可能会变成循环

没有路由层，“相关性”通常会变成永无止境的积压：

• • 为什么这个查询显示配件在核心产品之上？
• • 为什么这个头部查询突然开始显示相关项目？
• • 为什么在我们添加同义词、调整分析器或启用混合后结果发生了变化？
• • 为什么业务团队需要一个工程发布来修复单个查询？

团队用更多的调优来应对：更多的同义词，更多的提升，更多的重排序实验，更多应用代码中的例外。这可以在一段时间内有效，但通常会产生脆弱的行为，因为系统仍然缺乏明确的决策层来确定查询类型并在检索之前执行正确的约束。

电商意图的结构：头部和尾部

在这一部分中，我们用“头部”和“尾部”作为电商中常见导航和探索性查询模式的实用简写。在现实世界中，许多查询包含两者的方面：

头部查询（确定性意图）

这些是直接的、导航型的查询，用户知道他们想要什么：

• • 单一商品意图（“oranges”，“milk”，“bread”）。
• • 精确的品牌或产品系列（“iPhone 15 Pro”，“Diet Coke”）。
• • SKU、型号、尺寸（“ABC123”，“air max 270”）。

对于这些查询，词汇检索可以处理词元对应（匹配单词），但业务还期望尊重约束，返回可预测的排名，并具有可控的结果。商品经理需要确保查询在正确的类别界限内解决，尊重资格，并展示特定的业务优先级。

治理是强制执行预期解决方案所必需的。例如，“oranges”应该映射到水果类别，而不是橙汁、橘子酱或橙味汽水。

尾部查询（探索性发现）

这些是描述性、意图丰富的查询，购物者在探索：

• • “喜欢吃甜食的爷爷的礼物”
• • “适合在山里徒步的夹克”
• • “适合全天站立的鞋子”

词汇检索在这里往往难以应对。语义检索表现优异，因为它可以将查询概念与产品连接起来，即使措辞不匹配。但仅仅依靠语义检索也常常不够。真实的查询通常需要在使用任何检索方法时执行约束。

约束与检索方法无关

对语义检索应用约束并不意味着混合搜索。这些是正交的概念。在 Elasticsearch 中，约束（例如过滤和提升）可以应用于任何词汇、语义或混合检索。挑战在于决定如何解释查询，必须执行哪些约束，以及应该使用哪种检索策略。

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

• • Oranges： 对“oranges”进行词汇检索，再加上类别约束，例如“Fruits”或“Produce”，以排除橘子酱、橙汁和橙味汽水。
• • 高维生素C的水果，价格低于4美元： 对营养意图进行语义检索，再加上约束，将结果限制在水果类别和价格低于4美元的产品。
• • 适合工作的舒适鞋： 对情境意图进行语义检索，再加上类别约束，将结果限制在鞋类。

这些查询不能通过单一方法处理：

• • 纯词汇检索常常不够，因为诸如“高维生素C”或“舒适”这样的短语可能不存在为清晰的结构化属性。它们可能需要从产品描述、评论或规格中推断。
• • 纯语义检索也不总是足够的，因为没有明确的约束，像“高维生素C的水果”这样的查询可能会扩展到维生素补充剂、果味饮料或高维生素的蔬菜，超出了预期的类别和价格范围。

治理层决定一个查询是否需要词汇检索、语义理解、约束执行，或这些的某种组合。没有这个层，电商团队可能会：

• • 过度约束： 使用词汇检索来响应语义请求（例如，“给爷爷的礼物”）。
• • 约束不足： 使用语义查询来响应高意图的头部查询（例如，“oranges”）。

治理的挑战是建立一个可以为每类查询做出正确判断的系统。

缺少治理会发生什么

最常见的失败模式很简单：团队将原始用户查询直接传入一个单一的检索策略（词汇、语义或混合），没有中间治理层。

词汇检索未能实现预期解决方案

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

插图显示单个“oranges”查询返回不同的相关结果，如橘子酱、新鲜橙子和橙味汽水。

插图显示单个“oranges”查询返回不同的相关结果，如橘子酱、新鲜橙子和橙味汽水。

语义检索超出预期约束

当用户搜索“oranges”时，语义系统可能会检索概念上相关的项目，跨越附近的产品概念。系统可能正确理解了更广泛的领域（水果或农产品），但没有明确的治理它仍然可能超出用户的预期约束（具体的橙子）。

图示展示了“oranges”查询如何路由到不同的水果类别，包括苹果、橙子和混合水果。

图示展示了“oranges”查询如何路由到不同的水果类别，包括苹果、橙子和混合水果。

缺口是治理

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

• • 类似或相关项目与用户实际想要的项目一起出现。
• • 模糊的类别界限（“饮料”与“农产品”）。
• • 无法实施季节性提升或活动。
• • 不可预测和无法解释的结果。

意图理解和路由：必要的控制平面

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

图示展示不同查询如何通过控制平面路由到 BM25 或语义搜索结果。

图示展示不同查询如何通过控制平面路由到 BM25 或语义搜索结果。

一个控制平面可以检测意图，应用业务政策，并确保适当的检索策略如下：

1. 检测意图信号

• • 这个查询是可能的导航还是发现？
• • 它是已知的头部查询（milk, bread, bananas）吗？
• • 是否存在已知的产品、品牌或类别解释（例如，“oranges”应该解决为农产品）。
• • 查询是 SKU 样式的模式吗？
• • 查询是否属于一个活动的活动或季节性政策（例如，在圣诞节期间，提升与火鸡相关的结果）？
• • 查询是否暗示约束（类别、属性、排除、价格/尺寸/颜色）？

2. 应用治理和业务政策

• • 首先执行确定性的约束（类别/属性/否定/可用性）。
• • 应用活动的商品陈列政策（提升/埋没/固定/覆盖）。
• • 使用优先级规则解决冲突（例如，活动覆盖与全局政策）。

3. 路由到适当的检索策略

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

在实践中，控制平面的输出不仅仅是“使用混合”或“使用语义”。它是一个治理的检索计划：对购物者意图的解释，应该应用的约束和政策，以及应该执行的检索策略。几个简单的例子使这一点具体化：

一个控制平面为每个查询选择正确的政策和检索策略，一致、可预测并可扩展。这使得高级检索方法在生产中更加可预测，因为首先执行了与意图一致的约束，并且路由决策是明确的而不是隐含的。

这与其他方法的关系

一些团队使用改进的嵌入模型来更好地捕捉产品语义，这可以实质性地提高语义检索的质量。其他团队使用重排序方法，如学习排序（LTR），在检索之后根据参与或业务信号优化结果排序。这两者都很有价值，往往是互补的。更好的嵌入改善了相似性匹配。重排序改善了检索候选者之间的排序。

治理解决的是问题的不同层次：它位于检索的上游。它决定应该使用哪种检索策略（例如，词汇、语义或混合），需要哪些确定性的约束，哪些查询应该结合多个业务政策。

一个治理的控制平面能够实现什么

一旦建立了治理层，操作模型就会发生根本变化。收入关键的查询变得可预测。业务团队可以在不等待工程发布周期的情况下更新搜索行为。而高级检索方法，如语义和混合，可以在路由和护栏的情况下逐步采用，而不是作为全局开关。

本系列的下一篇文章探讨了这种操作模型在实践中的样子，以及为什么它可能和底层的检索技术一样重要。

如果商品经理必须打开一个 Jira 工单并等待部署来修复一个收入关键的查询，那么瓶颈不是引擎；而是操作模型。现代电商搜索需要一种方法，将业务意图快速、安全地转化为可控、可审计的搜索行为，同时在增加可测量价值的地方仍然使用高级检索。

本系列的下一步

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

实践中的治理电商搜索

工程瓶颈、脆弱的应用层逻辑和不可预测的搜索结果是 Elastic Services 可以帮助您在企业电商服务中解决的问题。本系列描述的治理控制平面架构由 Elastic Services Engineering 构建。

如果您的团队花费工程周期将商品陈列请求转化为代码更改，或者您的搜索相关性积压似乎永远无法缩减，我们可以帮助您评估当前架构并构建通往治理、业务可编辑搜索的路径。请联系 Elastic Services。

加入讨论

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

📡 更多 Elastic & AI 可观测性干货

关注「点火三周」，第一时间获取最新技术文章