加入收藏 | 设为首页 | 会员中心 | 我要投稿 上海站长网 (https://www.021zz.com.cn/)- 科技、建站、经验、云计算、5G、大数据,站长网!
当前位置: 首页 > 运营中心 > 搜索优化 > 正文

饿了么为啥给你推荐这个?本地生活搜索算法解密

发布时间:2022-12-10 16:34:45 所属栏目:搜索优化 来源:未知
导读:
搜索是本地业务的重要入口,切实影响着用户体验和业务效果。本文将围绕算法优化来介绍本地生活搜索该如何有效适配本地业务。
搜索是本地业务的重要入口,也是C端流量/B端供给/D端物流三端

搜索是本地业务的重要入口,切实影响着用户体验和业务效果。本文将围绕算法优化来介绍本地生活搜索该如何有效适配本地业务。

搜索是本地业务的重要入口,也是C端流量/B端供给/D端物流三端匹配的阵地。本地搜索经历过入淘升级,不管是架构体系还是模型结构,都快速和手淘搜索对齐,后面站在集团技术体系的肩膀上,本地搜索开始思考,如何在算法体系中,融入本地业务的特点,开拓本地生活搜索适配本地业务的广阔天地。

从电商业务的"人/货/场"过渡到本地业务的"人/货/场/地",本地业务的主要特点,简单总结:一是强时空感知,地理位置和时间,决定了B端商家和D端供应链,也影响C端用户的需求,时空特性贯穿在本地业务的全链路,算法优化就要考虑不同粒度的时空,最直接的就是要分城市/分商圈优化目标;二是强补贴,残酷的行业竞争,使得本地业务的参与方,习惯了补贴的交易流程,补贴业务又种类繁多,对用户/商户/骑手的影响,需要算法优化过程中,考虑补贴力度,补贴后金额对成单的影响。三是强复购,同电商业务不同,本地业务经常会很短的时间重复购买,算法在对用户行为学习时,就要考虑周期/季节/时令等复购的变化。

除了以上这些,本地业务偏局域网,业务开展边际成本非递减,电商业务属于典型的广域网,边际成本递减。本地业务的交付体验,需要同时优化C端用户选筛,B端商家配餐,D端物流履约,要保证约定时长内全链路的体验,相比于电商体验,难度更大,所以BCD三端同时优化,也是本地搜索需要关注的方向。基于以上,本地搜索从全链路流量效率和用户体验进行了大量的优化工作,截至三月底,本地搜索的效率提升15%以上,体验指标提升5%以上。

一、认知智能

餐饮、零售、医药等行业,商品的表达更为迫切,需要我们进行知识化的挖掘,进而提升在线搜索链路,承接用户的精准化的需求。

1.1 零售图谱

零售领域涉及的实体类型与商品数量庞大。

首先,我们需要从海量的商品标题和用户查询中挖掘实体与属性,先后采用模板匹配和NER的方案进行实体词的挖掘。关于NER模型,我们先后探索了基于模板的数据增强、多任务学习、迁移学习以及预训练+微调的范式,并探索出三种弱监督任务作为任务适应型预训练:Token分类任务、类目预测任务、语义一致判断任务。

除了通过NER模型进行实体词挖掘之外,我们还尝试了多种途径对词库进行扩充,例如通过统计字内部凝聚度(ngrams)+回溯的新词发现算法进行实体词挖掘以及外部知识库补充等方案。当实体挖掘完成之后需要对大量的数据进行清洗。为了减少最终人工质检的工作量,我们制定了多种自动化数据清洗途径,包括:pycorrect+kenlm词频算法过滤、LAC词性算法过滤、fasttext+annoy语义算法过滤以及有监督分类算法过滤等。最后我们再通过人工质检和例行化评估得到高质量的基础数据。

实体词库构建完成之后,我们还需要对词库进行同义词聚合。零售领域相比于医药领域有其行业特点,因此我们在之前医药同义词挖掘方案的基础上又进行了一定的方案调整和优化。

此外,我们还进行了商品的类目预测工作。首先为了解决样本人工标注成本大的问题,我们采用集成学习的思路,使用K-Fold方式将带噪样本切分为K份,然后训练K个分类器,最终通过启发式规则将不确定的数据再送给人工标注,这样迭代效率由原来的2~3周提升到了一周。在模型选型上我们先后尝试了预训练+微调的范式以及prompt learning的范式。在实际生产中我们采取了模型+规则的方案,即通过模型预测商品一二级类目,在一二级类目确定后通过实体匹配以及实体类型确定商品的三级类目。

1.2 医药图谱

医药图谱的构建流程包括:知识建模、知识挖掘、知识挂载。在知识建模阶段我们从整个零售领域出发设计了一套统一知识建模方案,然后结合医药领域的特点对医药schema给出了详细的定义。

阿里巴巴搜索优化_如何优化阿里巴巴关键词_阿里巴巴 怎么优化关键词

在知识挖掘阶段,我们以药品说明书为主要输入,对药品通用名、药品商品名、药品品牌名等实体以及药品的适用症状、疾病、功能、剂型等核心属性进行了挖掘。除此以外,我们还从搜索点击日志进行了医药领域同义词挖掘。基于医药行业的特点,我们将医药同义词挖掘任务分为药品属性同义词挖掘和药品名归一两个子任务。药品属性同义词挖掘我们基于用户搜索点击行为在一个user-session内通过互信息、频率等统计特征进行同义词粗筛,然后基于一个同义词判别模型进行过滤。药品名归一任务,我们通过药品名及其挂载属性进行实体相关性匹配,同时我们还以外部百科数据库进行补充。

在知识挂载阶段阿里巴巴搜索优化,我们在doc侧以药品spu粒度为准进行知识标签的挂载,在query侧进行实体+词双粒度的结构化理解。通过在搜索链路的召回和相关性环节引入上述结果并进行相关策略的开发和落地,最终使医药CTR

二、意图理解

搜索本质上是用户意图的表达。在意图识别方面,我们继续对类目预测提升准确率,并基于新业务融合搜索做行业识别,这是一种对流量的领域识别。在意图引导方面,我们基于SUG这种检索时形态,在用户输入过程中进行实时的意图交互。

2.1 识别式意图

类目预测是意图理解中的核心任务之一。我们的类目预测体系,包括一个基于店铺类目的类目预测模型及两个基于商品类目(餐饮+零售)的类目预测模型,产出的类目预测结果作用于相关性(类目相关性)、类目扩召回等多个下游环节。

类目预测在应用中仍然面临不少难点:

1)Query 本身一般长度较短、包含信息少,不止与一个类目相关、是一个多标签任务,意图模糊如“饭”,难以映射到三级类目的“盖浇饭”、“木桶饭”等;

2)类目体系设计是否科学、合理,类目间可能存在交叉,有时人工也不好区分;

3)头部&长尾,基于用户行为统计的方法会造成马太效应,长尾 Query 数量巨大但用户行为很少;

4)在准确率和召回率之间进行动态的平衡。本财年内,我们主要针对类目体系、样本构造两个角度出发,对类目预测进行了优化,解决类目体系不合理、正负类目边界学习模糊的问题。

用户在饿了么端的搜索诉求是多样化的,有“奶茶”、“米线”这样的外卖服务词,有“矿泉水”、“牛肉”这样的服务词,有“感冒药”、“阿司匹林”这样的医药服务词,也有“火锅”、“自助餐”这样的到店服务词。不同类型的query,对应到饿了么端的四大垂直行业:外卖、零售、医药、到店。去年我们发起了融合搜索这个新项目 ,借助于多Tab的形式,便于流量在多个垂直行业的精细化承接。下图是饿了么融合搜索改版后的SRP页的产品形态,每个Tab定位如下:

如何优化阿里巴巴关键词_阿里巴巴 怎么优化关键词_阿里巴巴搜索优化

这里面的核心算法逻辑,是对query进行识别,到以上几个行业(Tab)。依托于融合QP在线模块,我们打造了行业识别的算法流程。融合搜索推全后,首先是搜索用户体验取得了提升,大部分用户对新的搜索形态满意;同时在业务指标方面也取得了较为显著的收益。分行业的搜索形态对各个行业带来的提升也更加显著。

2.1 搜索式意图

下拉SUG,是搜索链路中的重要一环。它在用户有部分输入的情况下进行query补全,可以帮助用户明确搜索意图,减少用户搜索时间,快速引导用户进入SRP搜索列表页。下拉搜索是本地生活到家搜索最重要的搜索场景应用。

在体验方面,我们首次定义了SUG的相关性体验标准,分为三大档、11个小档;然后从候选+相关性+供给判断三个点进行优化。

在效率方面,一期迭代从日志、特征、样本、模型层面对下拉排序进行了升级,构建了SUG特征体系,并升级至DNN模型;二期迭代,我们基于esmm+mmoe架构,从以点击为目标到对整体净G为目标的全空间建模,上线后访购率有所提升。

在行业方面,实现了全城购、新零售等多场景的接入,并针对零售、医药等多个频道页进行升级,统一主suggest和频道/行业suggest架构,取得了较为明显的业务收益。

三、导搜推荐

对于本地生活,导搜推荐是一个非常年轻的业务,也是一个在快速进化过程中的业务,到了去年中旬产品形态才稳定下来(主要包括首页底纹、首页热词、首页信息流风向标【在建】、中间页搜索发现、中间页主题热榜、中间页猜你想搜等业务模块)。导搜推荐的算法和服务能力亟待升级,提效的同时也为更加长远的突破,我们也与算法工程、端工程、特征工程、产品等团队一起协作,将一些明显的短板补齐,实现了端智能的升级。

3.1 导搜推荐算法提效

导搜推荐算法提效核心围绕这几点展开:

一是基于业务交互的样本策略优化,解决样本有效性问题,导搜推荐区别于首页商户推荐和SRP结果排序等终末流量,属于过程流量。由于产品交互以及用户注意力等方面原因,存在大量伪负样本,部分业务模块伪负样本量甚至要高于直接行为正样本,我们根据启发式方法进行了负样本筛减和伪负样本增选,上线后模块效果提升显著;

二是词推荐模型优化,聚焦于词排序用户异构行为认知缺失问题,基准GBDT模型用户行为认知能力有限,构建Deep&Wide+Attention+GNN模型,基于用户的商户行为对词偏好理解强化,取得了不错的线上收益;

三是强化特征体系建设,解决特征缺失和质量问题;

四是优化线上策略,解决模块之间词分配策略滞后、实时召回缺失等存在的机制缺陷带来的模块提效约束。

3.2 基础AI链路升级

导搜推荐的基础AI链路包括算法词库、召回引擎、分发服务。算法主导了词库的重构,标准化处理链路、结构化落库、词源扩展并结合图谱进行新词生产;与算法工程团队协作实现词、商户召回引擎的线上主体业务BE迁移,并扩展构建商品召回引擎BE,实现词店品召回引擎的统一;在算法工程的大力支持下,完成了分发服务的全图化升级并全量上线。

3.3 导搜推荐端智能升级

端智能已经普遍应用在淘宝、支付宝等各个BU的业务场景,其比较核心的应用就是能够基于用户行为来进行决策支持。导搜推荐的业务模块处在流量的最前沿,需要借助端智能的能力来感知用户需求的变化,并触达用户。虽然端刷新、端重排已经在集团广泛应用,然而导搜场景的成熟先例较少,我们首先以首页底纹为标杆场景,与客户端团队、特征工程团队、算法工程团队、产品团队探索打造一套相对通用的端智能能力。核心包括触发时机、用户行为特征、端运算与业务的触发机制。

四、召回&相关性

在搜索系统中召回阶段是整个搜索的基础,召回深度与质量决定了排序以及整个搜索引擎的上限。饿了搜索主要包含三个召回阶段:文本匹配、实体匹配和语义匹配。第一阶段基于文本的匹配,就是对Query及其改写词进行一个切词或是切字,然后从ha3倒排索引做一个字面的匹配。在这阶段我们进行了从切字召回到分词召回的架构升级。第二阶段是开发新增了基于品牌、类目、TAG以及知识推理的带有一定语义引申的标签匹配召回,解决那些抽象概念词的召回。在这阶段我们主要针对Query的Tag识别模块做了优化。第三阶段是基于向量的召回方式,打破文本匹配的限制、简化掉标签挂载工作,解决语义鸿沟问题,通过端到端的语义向量的方式去表征我们的query和商户商品。在这阶段我们尝试了多种模型迭代升级的方案。

今年,我们对饿了么搜索引擎进行了系统化的改进,重点包括四个项目:

1)分词索引:由单字索引切换到分词索引,提升系统相关性。

2)query tagging:结构化理解query,为后续query智能筛选和query推理提供基础。

3)向量召回:升级向量召回模型模型,提升召回深度和搜索提效。

4)top query白盒化:保证头部query的体验和效率。

下面详细介绍下各个模块的优化工作。

4.1 分词索引

饿了么搜索引擎之前一直是按照单字进行匹配召回,这种方式能保证召回的覆盖率,但会引发大量召回不相关的问题。例如用户搜索"一点点"会被拆字为"一"和"点"去进行匹配,那么就会召回名字为"一点方糕"的店铺。为了解决这类拆字召回产生的问题,我们联合工程的同学,重新构建了基于分词召回的链路。然后利用线上的用户搜索日志,挖掘本地特色的分词词典。分词词典挖掘方式是通过统计有订单的query和item对,query被item完整包含的占比高的时候,query有可能是一个整词。这种情况也可能会产生冲突词,例如,query“猪五”和“五花”都被item“猪五花”完整包含,都是潜在的词,但这个时候“猪五花”可能分词为“猪五|花”或是“猪|五花”,这说明“猪五”和“五花”是可能造成冲突的,这时候可以通过统计两种情况的比例分布,结合人工审核,来筛选出可靠的词“五花”,抛弃不合理的“猪五”。通过挖掘的本地侧的词典,结合alinlp的分词工具,作为最终的分词手段。而在建立索引的时候,我们还需要挖掘上位词典。根据用户下单数据,用户搜索"蛋",下单"鸡蛋",那么就会在物品侧添加上位词索引,物品鸡蛋的索引为["鸡蛋","蛋"],这样用户无法通过搜"鸡" 召回 "鸡蛋" 但是可以通过搜 "鸡蛋" 或者 "蛋" 来召回名字为"鸡蛋"的品。最终线上的实现方式是以离线做好分词缓存,线上query查表的方式全量上线,当前走分词通路的query占总流量的一半以上;效率指标不降,相关性评测分+2.5%的效果。后续我们将继续挖掘分词词典,并实现线上实时分词通路,保证全流量走分词索引。

4.2 Query Tagging

搜索query是用户表达自己意图的重要媒介,对query进行tagging是NLP中一项基本且具有挑战性的任务,query tagging的结果可以作为中间层, 用于下游任务,包括召回和意图识别等。我们重新调整了Tagging模块的架构,通过词库匹配策略与离线、在线NER模型结合的方式完成Tagging。对于头腰部Query,采用大模型离线识别Query中的tag并存储于ODPS表,线上通过查表获取tag;对于长尾Query,采用在线匹配与模型预测相结合的方式识别tag。具体流程如下图所示:

阿里巴巴搜索优化_如何优化阿里巴巴关键词_阿里巴巴 怎么优化关键词

Tagging流程图

缓存表:

包括实体词库和头腰部Query的BERT离线预测结果,存储于ODPS表,主要是为了减少模型调用次数,降低线上时间开销。

正则匹配:

主要是通过正则匹配类似url这种无意义Query以及像“外卖/预定”等这种泛意图Query。

N-gram递归匹配:

主要分为2个子模块:Query切分、N-gram最大匹配。

N-gram最大匹配:

字符级N-gram匹配实体词库,取所有匹配上的N-gram中最长的作为实体。

Query切分:

是指将Query串按照匹配到的n-gram实体串进行切分。例如:Query为“好喝的星巴克咖啡”,N-gram最大匹配得到实体“星巴克”,则Query被切分成SubQuery1=“好喝的”,SubQuery2=“咖啡”,然后对SubQuery1和SubQuery2再迭代进行N-gram最大匹配,直到子串长度

(编辑:上海站长网)

【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容!