写点什么

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

作者:阿里技术
  • 2022 年 7 月 21 日
  • 本文字数:9628 字

    阅读完需:约 32 分钟

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

作者:玄东、王喆、采英、格鸣


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


搜索是本地业务的重要入口,也是 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<0.6 的 query 流量占比下降 -25.5%,同时优化了一批搜索体验较差的流量。


二、意图理解


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


2.1 识别式意图


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



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


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


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


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


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


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


  • “点外卖”:承载普通的外卖配送门店,主要为餐饮相关的外卖店;


  • “超市便利”:承载超市、便利店等零售类门店;


  • “买药”:承载药店,提供药品配送;


  • “去店里”:则非外卖配送类服务,而为到店的消费。


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


2.1 搜索式意图


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


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


  • 候选优化,经历了两次迭代,包括多源候选挖掘流程 + 候选质量控制模型,保证 sug 候选的覆盖率及质量。


  • 相关性优化,针对 suggest 中短文本、拼音破碎等特点,结合原有店铺搜文本相关性,进行 sug-文本相关性的升级。


  • 供给判断,作为本地生活场景的 sug 的特有环节,我们需要确保 suggest 引导词条在 srp 中有结果。因此针对 sug 中的供给判断逻辑进行了优化,优化前后 suggest 引导的 srp 零结果率降低明显。



在效率方面,一期迭代从日志、特征、样本、模型层面对下拉排序进行了升级,构建了 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 最大匹配,直到子串长度<=1 或子串没有匹配到实体停止。


实体合并:

是指对上一步中递归得到的所有实体进行合并。


实体集覆盖 Query:

是指各个实体中的字符并集与 Query 相同。例如:“星巴克咖啡”识别出 2 个实体:星巴克:商户、咖啡:商品,并且“星巴克”+“咖啡” == “星巴克咖啡”,则实体集覆盖 Query。“无糖的咖啡”识别出 2 个实体:无糖:修饰、咖啡:商品,但是“无糖”+“咖啡” != “无糖的咖啡”,则实体集未覆盖 Query。


IDCNN+CRF 预测:

主要是针对长尾 Query 实时预测其中的实体 tag。最终应用于品牌词下召回展示策略调整,无少结果列表排序优化实验,同时解决了 DCG 评测品牌词类的体验问题。


4.3 向量召回


基于向量的召回方式,能打破文本匹配的限制、简化掉标签挂载工作,解决语义鸿沟问题,通过端到端的语义向量的方式去表征我们的 query 和商户商品。同时引入用户画像、用户行为日志,让模型能捕捉用户静态特征和动态行为特征中的个性化信息,生成个性化召回能力。本年度,我们尝试了多种向量召回的模型方案,包括基于图注意力方案,基于多模态的 FashionBert 模型,阿里达摩院的 M6 模型,取得了不错的线上效果。


4.4 Top Query 白盒化


根据用户搜索频次高低,我们可以对 query 划分为头部 query、腰部 query、长尾 query。其中,头部 query 数量较少却占据了搜索的大部分流量,通过统计可以看到头部 2000 的 query 就能覆盖到相当一部分搜索 pv 流量。今年我们针对性的对这部分 query 进行白盒化的召回,这样可以解决了大部分的流量产生的搜索问题。处理流程可以分为三个阶段:问题归因、数据定制、线上召回链路分层改造。


首先是问题归因。针对用户搜索频次很高的 query,通过线上日志统计高曝光无点击的召回品和在手机上实际模拟搜索两种方式搜集到对应的体验问题,进行分类、定制对应的数据解法。例如:如果是换词召回带来的 badcase,就去掉这个换词条件。


其次是数据定制。针对这些 query 设计一个数据宽表,字段包括这个 query 能产生的各种召回条件以及类目限制等。对应的内容都是经过问题归因后人工审核生成的数据。生成流程如下图所示。


最后是召回链路的分层改造。通过改造线上代码框架,支持头部 Query 线上分层召回,改造后的 QP 线上处理流程如下图,主要是在各个召回模块嵌入了 Top Query 的处理。


五、排序智能


排序效果对用户搜索体验和成单都起关键的作用。用户在首页定位后,然后在搜索框中输入想要的商品名字,就会返回符合用户搜索词的附近商品。在搜索返回过程中,搜索排序模型会对相关商品进行排序。排序模型升级是到家搜索技术团队的持续探索方向,从 17 年至今,到家搜索排序模型经历二次较大的升级,从非线性信息组合的 GBDT+LR 模型升级到自动特征组合的深度模型 DeepFm,再到本地生活全面入淘后,升级为关注用户行为建模的 CTR、CVR 多目标联合训练模型。


今年,搜索排序模块主要迭代包括:


1) LOGAN 模型:结合本地生活场景特殊性,优化位置信息的试用,提出位置门控注意力网络的到家排序(Logan)。


2) 结合新的业务特殊性:GMV 预估,新客场景优化。


3) 分场景优化:多域信息模型。


4) 科学高效验证实验的有效性:我们设计了主搜 ABtest 假设检验。


5.1 LOGAN


到家搜索场景是一个基于 Location Based Services(LBS)的特殊场景,用户所在空间不同,会影响用户的行为和决策,充分利用空间信息可以帮助我们更好理解用户的需求。通过分析,我们发现到家搜索场景有二种特殊性:


1)需求的空间差异性:用户的需求会根据位置的不同而变化。


2)场景的空间有界性:用户在不同位置下可以购买到的商品集合是不一样的。


用户在不同位置,所能购买的商户范围主要受到两种情况的影响:结合到家场景的特殊性,我们提出 LOcation Gate Attenion Netwok(Logan)模型,Logan 模型的核心思想:


  • 基于空间特征自动筛选:结合空间信息,让模型学习到不同空间需求,并能自动筛选与当前空间上下文相关的重要模型特征。


  • 基于空间的知识学习:把场景的空间信息传授给模型,引导模型学习和理解空间信息,加强模型各模块对空间信息更合理的捕捉。


5.2 新客场景优化


新客场景特殊性:平台订单以中高频用户为主;中高频用户订单行为受其历史行为影响较大,而新用户没有历史行为或较少。所以我们通过构建无用户行为的辅助网络(Shop2User),通过 query 和店的特征去匹配人,同时根据用户等级和行为构建 Gate,用于融合主网络和新客网络作为最后输出。最终取得了一定的优化效果。


5.3 多域信息模型


随着搜索业务在不同场景以及不同地域做特殊优化需要,我们在多场景方面进行一定的探索。期初我们也采用 MMOE、PLE 等模型,但是一直没有取到特别好的效果。经过分析,我们得出结论,我们场景之间的差异不足以支持我们做通用的分场景建模。但是我们借鉴 mmoe、gateNet 等模型的思想,构建多域信息模型精细化学习时间、空间、类目等维度的场景信息,取得净 UV、访购率提升的效果。


5.4 主搜 ABtest 假设检验


我们本地生活的场景里有着大量的 AB 实验。在 AB 实验过程中,比较两个类似版本的问题包含“运气”因素。由于测试是在统计基础上制定的,因此存在一定的误差范围,可能会影响 A/B 测试活动的结果。如何减少随机因素(所谓的“运气”)使结果偏斜的风险,是我们必须要面对的问题。为了科学有效的管理我们的实验,我们采用两总体比例差的区间估计来检验我们的线上实验的有效性。基于假设检验,我们的 AB 实现流程如下图,采用此流程后极大的提高了我们的工作效率,避免不必要的线上实验。


主搜实验流程图


六、内容智能

6.1 多模内容搜


内容搜面临的物料有图文帖子、短视频等,我们的搜索理解也从结构化文本的理解拓展到了非结构化文本、图片、视频。


图文帖子是目前应用物料的大头。除了标题、类目等构化的短文本,对于帖子的长文本内容进行理解,是今年工作的挑战。我们在关键词抽取、实体抽取的同时也对帖子的 body 字段进行了摘要抽取,作为内容帖子的核心检索内容,我们探索了两类方法,分别是基于 Bert+CRF 的模式序列标注进行摘要抽取、基于 Bert 阅读理解方式的摘要抽取,这使得我们拥有了长文本的理解能力。


基于抽取的知识词,建立了起了一套长文本知识挖掘流程,与知识图谱联动,通过知识词库、TextRank、NER 方法进行候选生成,通过基于 Bert 语义化表征的 DNN 模型进行知识关键词的提纯抽取,通过知识上下位关系实现知识结构化以及线上知识推理,这是一条知识化的检索链路。


在图片方面,我们通过数据达标、数据增广的方式进行数据增强,图文的内容表征采用的是模型方法是 FahsionBert,并对双塔模型结构进行了一定的改造优化,用于多模态的向量召回。此时,链路升级到文+图的多模态匹配。


同时,多模态的建模思路,继续延伸到原有的店铺搜上。首先,我们在排序模型中也探索了多模态展现信息的建模。在模型信息理解方面,文本采用 bert 预训练向量,图片采用了 VGG16 预训练模型作为特征提取器,在模态特征融合方面,结合当前 context 信息、query 信息做 Attention,多不同模态的特征有所侧重,落地了我们第一版 Multimodal Representation 模型。其次,围绕着多模+图的思路,我们探索了异构图表征 GNN。在 GNN 预训练方案探索中,我们尝试了三种不同的图神经网络模型对用户-商铺图进行预训练,以 GraphSage 为基础,在此基础上进行了 Multi_Edge GraphSage、Dual_Channel GraphSage 的探索,GNN 模型的结果通过预训练 embedding 的方式接入到排序模型中使用。


6.2 智能 UI


本地生活搜索业务进行智能 UI 探索,如下图所示,一个商家卡片划分为图片、基础信息、辅助决策、商品等区域,对其分区域做素材生产,对多区域做组合优选,基于用户偏好进行个性化的匹配组合。当前重点工作是素材的建设,主要包括:推荐理由生成、商品标题改写、商品图片动效展示。


6.2.1 推荐理由


推荐理由是一种信息抓手,有助于消除平台与用户间信息的不对称性,常见的表现形式如:商家商品榜单、实时行为统计、用户评论、权益优惠等。参照 FABE 理论,用户决策取决于客观属性(Feature)、主观属性(Advantages & Benefits)、权威认证(Evidence)。推荐理由可以承载主观属性与权威认证的表现形式,源于用户评论与商品描述挖掘的推荐理由可以表达商家商品的优点与益处,基于大量用户在平台的榜单统计等推荐理由可以更好地为商家商品背书。


推荐理由生产主要分为文本生成与文本质量俩个模块,其中文本生成历经了模版式、抽取式与生成式三个阶段。因为生产出的的推荐理由是要直接展示给用户,内容质量需要保证,所以建立推荐理由文本质量模块,主要包含情感极性、语义流畅判定与文本优美。


6.2.2 标题改写


商品标题主要有商家编辑,为了提高召回率促成成交,商家会在标题中加入营销词和冗余词,由于展示标题有限制,尤其在手机端进行浏览时过长的标题展示不全,超出长度限制的部分智能用省略号代替,这样会导致一些重要信息无法展示。针对本地生活餐饮和零售场景下商品标题关键信息得不到曝光的问题,我们通过 NLP 手段对展示的商品标题进行优化改写精简,在有限的长度中展示核心关键信息。


​长标题改写流程图


6.2.3 商品动效


考虑到动态展示相对于静态图片,更容易吸引用户,进入转化漏斗。我们尝试展示商品动态图片,现已经选定中式热菜+热气腾腾动效,已批量产出离线数据,同时动图 OSS 存储 → 线上透传 URL → 端上消费。

发布于: 刚刚阅读数: 4
用户头像

阿里技术

关注

还未添加个人签名 2022.05.24 加入

阿里技术的官方号,专注分享阿里技术的丰富实践、前沿洞察、技术创新、技术人成长经验。阿里技术,与技术人一起创造成长与成就。

评论

发布
暂无评论
饿了么为啥给你推荐这个?本地生活搜索算法解密_算法_阿里技术_InfoQ写作社区