作者来自 Elastic Alexander Marquardt, Honza Král 及 Taylor Roy学习如何构建用于执行电商治理型搜索计划的多层级检索策略并提升召回率管理。我们将介绍如何编排语义匹配同时保持结果稳定性、分面facets和分页能力。如果你刚接触 Elasticsearch可以参加我们的 Elasticsearch 入门网络研讨会。你也可以开始免费的云试用或者现在就在你的本地机器上体验 Elastic。电商搜索中一个常见问题是召回率较低。这通常发生在系统缺乏有治理的回退策略时。解决方法是采用多层级执行模型。本文介绍了一种用于执行治理型搜索计划的多层级检索策略说明如何在保持结果稳定性、分面facets和分页的同时编排严格匹配、宽松匹配以及语义匹配。从策略逻辑到检索架构第 3 部分和第 4 部分深入讲解了受治理控制平面及其基于 Elasticsearch percolator 的实现。一旦逻辑层确定了需要应用哪些策略系统就必须处理用于执行搜索的检索策略。在任何电商搜索引擎中从精确性向召回率的过渡管理都是关键能力。例如一个基础搜索实现通常默认使用宽泛的关键词匹配。如果购物者搜索 “有机 Pink Lady 苹果”可能会返回无关结果例如苹果味洗洁精、苹果汁或有机粉红葡萄柚仅仅因为它们共享 “苹果” 或相关词项。虽然这些结果在技术上是匹配的但并不符合用户意图通常会导致较高的跳出率。然而“无结果”页面同样会严重影响转化率。这种冲突可以通过引入三层执行模型来解决该模型利用受治理的控制平面来编排一个有原则的回退策略。三层执行模型该架构按顺序执行最多三个检索层级每一层都有特定的匹配逻辑。最高层严格匹配严格匹配是一种词汇匹配要求查询中的所有词项都必须出现在商品元数据中。逻辑搜索 “organic navel oranges有机脐橙” 只返回同时包含这三个词的商品。应用这一层提供最高精度。当用户输入如 “organic navel oranges” 这样精确的商品名称时通常是在寻找该确切商品而不是替代品。中间层宽松匹配如果严格匹配层未返回足够结果系统会扩展搜索参数。逻辑该层允许部分词项匹配使用 Elasticsearch 的 minimum_should_match 逻辑。应用宽松匹配仍然保持词法基础。例如搜索 “organic navel oranges” 可能返回 “navel oranges”缺少 “organic”或 “organic oranges”缺少 “navel”。这些都是基于关键词的直观替代结果。最低层语义匹配逻辑该层使用向量/语义嵌入例如 Elastic Learned Sparse EncodeR [ELSER]、E5 或 Jina在没有直接关键词重叠的情况下检索语义相关的商品。应用搜索 “organic navel oranges” 可能返回 “mandarins柑橘”或 “clementines小柑橘”。这是最终检索层用于在字面关键词匹配不可用时提供相关选项。要查看该多层编排的实际运行方式以及引擎如何从词法匹配逐步降级到语义匹配可以观看视频《消除零结果页面PRISM 的多层搜索回退》。分层编排“填桶逻辑”虽然受治理的控制平面提供了每个层级的逻辑和查询但执行由应用层负责。应用层会按顺序执行这些层级并在第一屏的累计结果数量达到或超过 10 条或你希望在首页展示的任意数量时排除后续更低层级的执行。这个阈值确保首页始终有足够的结果同时优先使用最精确的检索方式。场景 1高意图搜索“oranges橙子”第一层返回 15 个结果。由于 15 大于 10当前结果集将被锁定为仅严格匹配结果这些结果仍可分页浏览并且不会执行后续层级。Strict tier: [##########]##### ( 10 found: Exact matches) Relaxed tier: [ ] (Tier bypassed) Semantic tier: [ ] (Tier bypassed)场景 2具体但结果有限“organic blood oranges有机血橙”严格匹配层仅找到 4 个商品。由于少于 10 个系统会触发宽松匹配层该层又找到 12 个相关商品。合并后的总数16已达到 10 的阈值因此当前结果集被锁定为严格层和宽松层的结果。后续分页只会在这两个层级中返回结果从而防止低质量的语义匹配结果出现在后续页面中。Strict tier: [#### ] (4 found) Relaxed tier: [ ######]###### ( 6 found) Semantic tier: [ ] (Tier bypassed)场景 3抽象或意图型搜索“high vitamin C snacks高维生素C零食”关键词匹配结果有限在第 1 层和第 2 层之间仅有 5 个命中。系统随后触发语义层以查找概念上相关的商品例如猕猴桃、番石榴或红椒用于填充结果集。该查询的结果集包含来自所有层级的商品。Strict tier: [## ] (2 found) Relaxed tier: [ ### ] (3 found) Semantic tier: [ #####]######################...这种编排优化了延迟因为语义层的计算成本只有在关键词层不足时才会产生。此外这种方式允许先快速展示关键词结果而语义结果在稍后逐步补充从而保持用户界面的响应性。通过分层激活判断意图用于填充第一页的逻辑还承担一个关键的二级作用它作为用户意图的诊断信号。应用层使用受治理控制平面返回的逻辑来判断当前结果集与分页中哪些层级仍然处于激活状态。如果严格层与宽松层合计仍少于 10 个结果那么查询很可能是探索型或抽象型。在这种情况下激活语义层是有价值的。由于查询被判定为探索型系统允许用户在完整的语义结果深度中分页浏览。这提供了词法匹配无法覆盖的概念相关替代结果这对于抽象搜索是合适的。相反如果严格层已经返回了足够多的结果例如 30 个命中则说明系统已经找到了高精度匹配结果。用户可以在这 30 个结果中继续分页并很可能找到所需内容。在这种情况下没有必要再提供额外的、相关性较低的探索性结果。通过在高精度查询中禁用低层级结果可以避免用户在深入浏览特定结果时被不相关的语义回退内容干扰。跨层级治理该架构的一个关键点是策略会全局作用于所有层级。如果用户有 “vegan纯素” 偏好配置受治理控制平面会将该约束注入严格、宽松和语义查询中。这确保即使语义回退返回 “mandarins橘子” 用于 “orange橙子” 搜索结果仍然符合用户更广泛的饮食或业务约束。分面不稳定问题多层级搜索的一个挑战是如何保持分面导航侧边栏过滤器的稳定性。如果 “chocolate巧克力” 搜索返回 12 个严格匹配结果侧边栏可能显示 “dark黑巧” 和 “milk牛奶巧克力”。如果用户选择 “dark”结果数量下降一个简单系统可能会触发语义层来补充页面从而可能因为语义关联突然在过滤器中引入 “red wine红酒”。受治理控制平面会识别哪些层级参与了初始搜索并将分面锁定在这些层级上。这可以防止在过滤过程中侧边栏发生意外变化从而确保一致且稳定的用户体验。分页挑战无缝多层级分页在分层系统中实现分页需要精确的状态管理。如前所述第一页决定当前结果集的范围。如果第一页需要语义结果用户可以在所有三个层级的结果中分页浏览。另一方面如果第一页已由高意图的关键词匹配满足则针对该结果集不会再检索语义层。受治理控制平面通过以下方式管理这一过程层级锁定响应中包含一个数组用于标识参与本次结果的层级。前端在后续请求中返回该信息以确保跨所有页面的层级组成保持一致。动态偏移计算后端会根据请求的页码以及前序各层级返回的商品总数来计算 offset。例如如果第一页返回了 7 个严格匹配结果和 3 个宽松匹配结果那么第 2 页请求从索引 10 开始将会在宽松层查询中使用 offset 为 3。低层级 ID 排除系统会从高层级结果中获取 ID由于其数量通常小于页面大小阈值并在低层级查询中通过仅 ID 查询显式排除这些结果从而避免对被排除项执行完整 fetch 阶段的开销。总结多层级方法确保在数据充足时搜索结果保持高精度在数据不足时仍然提供有用结果。通过为应用层提供一个有治理的回退执行序列该架构在保持高相关性的同时消除了 “无结果” 场景。本系列下一篇本系列后续文章将把受治理控制平面扩展到新的领域。第 6 部分将探讨个性化使用购买历史加权和人群感知策略第 7 部分将展示按查询的经济优化。敬请关注将受治理的电商搜索落地实践本文所描述的搜索架构检索层级、经济权重与治理约束组合成单一请求由 Elastic Services Engineering 设计并实现作为可复用的电商搜索加速方案的一部分。如需了解如何将这些模式应用到你的业务中请联系 Elastic 专业服务团队。原文https://www.elastic.co/search-labs/blog/multi-tier-search-ecommerce-governance