作者：来自 Elastic Alexander Marquardt, Honza Král 及 Taylor Roy
了解为什么在缺乏治理的情况下 ecommerce search 会表现不佳，以及控制层如何确保可预测且以意图驱动的结果，从而提升检索效果。
刚接触 Elasticsearch？加入我们的 Elasticsearch 入门网络会议。你也可以开始免费的 cloud 试用，或立即在你的本地机器上尝试 Elastic。
电子商务零售商需要在同一个系统中处理多种本质上不同的查询类型。搜索 “oranges” 的购物者期望得到水果，而不是包含 “ orange ” 这个词的产品，例如 orange juice 或 orange marmalade，也不是语义上相关的柑橘类产品。搜索 “gift for grandpa who has a sweet tooth” 的购物者需要语义发现，而不是字面关键词匹配。
词法检索（文本匹配）、 语义检索 （概念匹配）以及混合检索（结合词法和语义信号）本身都无法解决这些问题。词法检索可能返回任何包含 “oranges” 的内容，而在像 “oranges” 这样的高意图查询中，纯语义检索可能会扩展到相关项目，例如 lemons 或 grapefruits。混合检索结合了词法和语义信号，但它仍然无法判断该查询是否应被视为导航型查询、应施加哪些约束，或应应用哪些业务策略。问题的关键不在于检索技术本身，而在于缺少一个治理层，该层能够理解查询类型，并在检索开始之前确定应施加的约束。
在这篇博客中，我们探讨 电子商务 搜索治理、其重要性，以及控制层如何确保可预测且准确的检索。
电子商务 搜索中的治理意味着什么
在这个上下文中，治理指的是在用户查询和检索引擎之间引入一个决策层。该层执行以下功能：
- 分类查询意图：这是导航型（“oranges”）还是发现型（“gift for grandpa”）？
- 应用业务约束：适用哪些类别边界、资格规则、可用性约束或商品策略？
- 路由到合适的策略：应使用词法检索、语义检索还是混合检索？
治理层决定每个查询应使用哪种检索方法、必须执行哪些约束，以及在检索开始之前应应用哪些业务策略。需要注意的是，不要将治理与混合检索混为一谈：混合检索是一种结合词法和语义信号的检索策略，而治理是上游的决策层，用于决定应使用词法、语义还是混合检索。
现状：应用层的 “spaghetti” 实现
目前，许多零售商尝试通过直接在应用层添加逻辑来解决这一问题。这通常会导致 spaghetti code，也就是成千上万行硬编码的 if-then 语句、 regex 和复杂的搜索模板。
这种方法可以提供如上所示的理想搜索结果；然而，它会带来显著的运维摩擦：
- 工程依赖：业务用户和商品运营人员无法在没有工程工单和较长部署周期的情况下修改搜索行为，这些周期通常会持续数周。
- 碎片化：搜索逻辑分散在应用代码和搜索模板之间，难以解释或审计，使演进变得有风险。
即使团队意识到需要进行路由，讨论往往集中在错误的问题上：选择哪种检索方法。
错误的选择：词法 vs. 语义 vs. 混合
搜索团队通常将问题框定为检索策略的选择：词法 / BM25、语义 / 向量或混合。这种框架是可以理解的（检索方法确实重要），但它忽略了实际 部署 中最常见的失败模式，即对所有查询使用单一检索方法会导致次优结果。
电子商务 搜索是多种本质不同意图的组合：
- 确定性、高意图导航（“oranges”、“milk”、“chocolate without peanuts”、“cheap olive oil”）。
- 探索式发现（“jacket for hiking in the mountains”、“gift for a 12-year-old who likes robotics”）。
- 操作约束（可用性、尺寸、价格、颜色）。
- 商品运营和营销活动（提升、下调、季节性活动）。
当系统将所有这些通过同一种检索策略处理时，由于缺乏治理，结果往往会以可预测的方式系统性出错。当团队没有意识到这是治理缺口时，他们只能使用唯一的手段来应对：更多调优。
为什么“relevance tuning” 会变成循环问题
在没有路由层的情况下，“relevance” 往往变成一个永无止境的待办事项：
- 为什么这个查询把配件排在核心产品之上？
- 为什么这个头部查询突然开始展示相关商品？
- 为什么在我们添加 synonyms、调整 analyzers 或启用 hybrid 后结果发生变化？
- 为什么业务团队需要通过工程发布来修复单个查询？
团队通常通过更多调优来应对：更多 synonyms、更多 boost、更多 reranking 实验，以及在应用代码中增加更多例外。这种方法在一段时间内有效，但通常会产生脆弱的行为，因为系统仍然缺乏一个明确的决策层，用于在检索前确定查询类型并施加正确的约束。
电子商务意图的结构：Head 和 Tail
在本节中，我们使用 “head” 和 “tail” 作为 电子商务 中常见导航型和探索型查询模式的简化表达。在现实中，许多查询同时包含两者的特征：
Head 查询（确定性意图）
这些是直接的导航型查询，用户明确知道自己想要什么：
- 单一商品意图（“oranges”、“milk”、“bread”）。
- 明确品牌或产品系列（“iPhone 15 Pro”、“Diet Coke”）。
- SKU、型号、尺寸（“ABC123”、“air max 270”）。
对于这些查询，词法检索可以处理 token 对应（词匹配），但业务还期望满足约束、返回可预测的排序，并具备可控的结果。商品运营人员需要确保查询在正确的类别边界内解析，满足资格要求，并突出特定的业务优先级。
需要治理来确保按预期解析。例如，“oranges” 应该映射到农产品类别，而不是 orange juice、orange marmalade 或 orange soda。
Tail 查询（探索式发现）
这些是描述性强、意图丰富的查询，用户处于探索阶段：
- “Gift for grandpa who has a sweet tooth”
- “Jacket for hiking in the mountains”
- “Shoes for standing all day”
词法检索在这里通常表现不佳。语义检索更擅长，因为它可以将查询概念与产品关联起来，即使措辞不匹配。但仅靠语义检索通常也不够。实际查询往往需要施加约束，无论使用哪种检索方法。
约束与检索方法是正交的
将约束应用于语义检索并不等同于 hybrid search。这是两个正交的概念。约束（例如 Elasticsearch 中的 filters 和 boosts）可以应用于任何词法、语义或混合检索。真正的挑战在于决定如何解释查询、必须施加哪些约束，以及应使用哪种检索策略。
以下是一些将检索与硬性约束结合的查询示例：
- Oranges：对 “oranges” 进行词汇检索，并加上类别约束，例如 “Fruits” 或 “Produce”，从而排除 orange marmalade、orange juice 和 orange soda。
- **Fruits high in vitamin C under 4。
- Comfortable shoes for work：针对上下文意图进行语义检索，同时施加类别约束，将结果限制为鞋类。
这些查询无法通过单一方法处理：
- 纯词汇检索通常不足，因为像 “high in vitamin C” 或 “comfortable” 这样的表达可能并不存在为清晰的结构化属性，它们可能需要从产品描述、评论或规格中推断。
- 纯语义检索也并不总是足够，因为如果没有显式约束，像 “fruits high in vitamin C” 这样的查询可能会扩展到维生素补充剂、水果味饮料，或超出预期类别和价格范围的高维生素蔬菜。
治理层决定一个查询是否需要词法检索、 语义理解 、约束执行，或这些方法的组合。如果缺少这一层，电子商务 团队可能会：
- 过度约束：对语义型请求使用词法检索（例如 “gift for grandpa”）。
- 约束不足：对高意图 head 查询使用语义查询（例如 “oranges”）。
治理的挑战在于构建一个系统，能够为每一类查询做出正确的判断。
没有治理会发生什么
最常见的失败模式很直接：团队将用户的原始查询直接交给单一检索策略（词法、语义或混合），而没有中间的治理层。
词汇检索无法正确解析意图
当用户搜索 “oranges” 时，词法检索策略可能会返回任何包含该 token 的内容：orange juice、orange marmalade 或 orange soda。系统虽然正确匹配了该词，但由于缺乏治理，它可能无法解析用户真正的购物意图（水果本身）。
语义检索会超出预期约束
当用户搜索 “oranges” 时，语义系统可能会检索到概念上相关的、属于相近产品概念的内容。系统可能正确理解更广泛的领域（水果或农产品），但由于缺乏显式治理，它仍然可能过度扩展，超出用户的预期约束（特指 oranges）。
差距在于治理
真正需要的是一个上游决策层，在检索开始之前就确定查询意图并施加正确的约束。这个机制可以解决以下问题：
- 类似或相关的商品与用户真正想要的内容一起出现。
- 类别边界变得模糊（“beverages” vs. “produce”）。
- 无法实现季节性提升或营销活动。
- 结果不可预测且无法解释。
意图理解与路由：必要的控制平面
一个受治理的搜索系统会在检索之前（在 Elasticsearch 执行查询之前）引入一个轻量级控制平面。这个控制层将在本系列博客的第 3 和第 4 部分详细讨论；目前我们只讨论它能做什么，而不讨论其实现方式：
控制平面可以检测意图、应用业务策略，并确保采用合适的检索策略，具体如下：
1）检测意图信号
- 这个查询更可能是导航型还是发现型？
- 是否为已知 head 查询（milk、bread、bananas）？
- 是否存在已知的产品、品牌或类别解释（例如 “oranges” 应解析为 produce）？
- 是否为类似 SKU 的模式？
- 该查询是否属于某个活动或季节性策略（例如在圣诞节期间提升 turkey 相关结果）？
- 该查询是否隐含约束（类别、属性、排除条件、价格/尺寸/颜色）？
2）应用治理与业务策略
- 优先执行确定性约束（类别 / 属性 / 否定 / 可用性）。
- 应用当前的商品运营策略（boost / bury / pin / override）。
- 通过优先级规则解决冲突（例如活动策略 vs 全局策略）。
3）路由到合适的检索策略
- 词法（快速、确定性）：用于导航型 / 高意图 head 查询。
- 语义检索：用于真正的探索型查询。
- 混合检索：当词法与语义信号在明确业务约束下共同有价值时使用。
在实践中，控制平面的输出并不是简单的 “使用 hybrid” 或 “使用 semantic”。它是一个受治理的检索计划：对用户意图的解释、应应用的约束与策略，以及将要执行的检索策略。以下是一些具体示例：
| 购物者查询 | 治理后的解释 | 示例检索计划 |
|---|---|---|
| “chocolate without peanuts” | 带有硬性排除约束的产品导向查询 | 对 chocolate 进行词法检索，并对含 peanuts 的产品添加排除过滤 |
| “cheap olive oil” | 带价格约束的产品/类别查询 | 对 olive oil 进行词法检索，并施加价格过滤（上限为零售商定义的 cheap 阈值） |
| “fruit high in vitamin C under $4” | 需要语义理解并结合硬性约束的探索型查询 | 对营养意图进行语义检索，并限制在 fruit 类别，同时过滤价格低于 $4 的产品 |
控制平面会为每个查询一致、可预测且可扩展地选择合适的策略与检索方法。这使得生产环境中的高级检索方法更加可控，因为与意图对齐的约束会被优先执行，并且路由决策是显式的，而不是隐式的。
与其他方法的关系
一些团队使用更好的 embedding 模型来更准确地捕捉商品语义，从而显著提升语义检索质量。另一些团队使用 reranking 方法，例如 Learning To Rank (LTR)，在检索之后基于用户行为或业务信号优化结果排序。这两者都很有价值，并且通常是互补的：更好的 embeddings 改善相似度匹配，reranking 改善候选结果的排序。
治理解决的是不同层面的问题：它位于检索之前的上游层。它决定使用哪种检索策略（例如 lexical、semantic 或 hybrid），需要哪些确定性约束，以及哪些查询需要结合多种业务策略。
治理控制平面带来的能力
一旦引入治理层，整个运行模型会发生根本变化。收入关键型查询变得可预测。业务团队可以在不依赖工程发布周期的情况下更新搜索行为。而像语义检索和混合检索这样的高级方法，也可以逐步采用，在路由与安全机制之下运行，而不是作为全局开关直接启用。
本系列下一篇文章将探讨这种运行模型在实践中的样子，以及为什么它与底层检索技术同样重要。
如果商品运营人员需要提交 Jira 工单并等待发布才能修复一个影响收入的查询，那么瓶颈不在引擎，而在运行模型本身。现代电子商务搜索需要一种机制，将业务意图快速、安全且可审计地转化为受控的搜索行为，同时仍然在有价值的地方使用高级检索技术。
本系列的下一部分内容
本系列中探讨的模式都位于检索的上游：在查询生成之前，将业务意图转化为正确的查询策略。在下一篇文章中，我们将从技术问题转向运营问题：当业务团队可以在不依赖工程部署的情况下更改搜索行为时会发生什么，以及为什么治理机制能够确保这种变化是安全的。
将受治理的 电子商务 搜索落地实践
工程瓶颈、脆弱的应用层逻辑以及不可预测的搜索结果，都是 Elastic Services 在企业级 电子商务 服务项目中可以帮助解决的问题。本系列中描述的受治理控制平面架构由 Elastic Services Engineering 构建。
如果你的团队正在不断使用工程资源来将商品运营需求转化为代码变更，或者你的搜索相关性待办事项始终无法减少，我们可以帮助你评估当前架构，并构建通往可治理、业务可编辑搜索的路径。联系 Elastic Services。
参与讨论
如果你对搜索治理、检索策略或 电子商务 搜索架构有疑问，欢迎加入更广泛的 Elastic 社区讨论。
