共计 8807 个字符,预计需要花费 23 分钟才能阅读完成。
本文首发于微信公众号“Shopee 技术团队”。
摘要
在支流的搜索引擎、购物 App 和 Chatbot 等利用中,下拉举荐能够无效地帮忙用户疾速检索所须要的内容,曾经成为一项必须且标配的性能。本文将介绍 Shopee Chatbot 团队在 Chatbot 中从 0 到 1 构建下拉举荐性能的过程,并分享模型迭代优化的教训。
特地地,针对东南亚市场语种繁多的挑战,咱们摸索了多语言和多任务的预训练语言模型,并将其利用于下拉举荐中的向量召回,以优化召回成果。另一方面,为了使下拉举荐尽可能帮忙用户,并解决用户的问题,咱们针对用户点击与问题解决这两个指标进行了同时建模,在多指标优化方面也做了摸索。
1. 业务背景
1.1 Shopee Chatbot
随着 Shopee 业务的扩张,消费者对客服征询的需要一直攀升。Shopee Chatbot 团队致力于基于人工智能技术打造 Chatbot 与人工客服 Agent 的有机联合,通过 Chatbot 来解决用户日常的征询诉求,给用户提供更好的体验,缓解和加重人工客服的压力,也帮忙公司节俭大量人力资源老本。目前,咱们曾经在多个市场上线了 Chatbot。如上图所示,用户能够通过 Shopee App 中的 Mepage 体验咱们的 Chatbot 产品。
咱们也在继续一直地打磨 Shopee Chatbot 产品,加强其性能,给用户提供更好的体验,帮忙用户解决购物过程中所遇到的问题。在 Shopee Chatbot 的泛滥性能中,下拉举荐是其中一个重要的性能。
1.2 下拉举荐
下拉举荐,又名输出倡议、搜寻倡议、主动补全或问题举荐等,曾经成为支流搜索引擎、购物 App 和 Chatbot 等泛滥产品里的一项必须且标配的性能。其大抵性能为:在用户输出查问词的时候,显示与输出 query 语义相干的举荐 suggestion,供用户抉择。通过这种形式,它能够帮助用户更快地表白其想要检索的内容,进而帮忙用户疾速检索到所须要的内容。
在 Shopee Chatbot 中,咱们也心愿 Chatbot 具备下拉举荐的性能,从而能更快更好的解决用户的问题,晋升用户的购物体验。
2. 整体计划
针对目前 Chatbot 的场景,为了使它具备下拉举荐的性能,咱们借鉴搜寻和举荐的场景,应用召回 + 排序的流程,如下图所示。针对用户以后的搜寻输出,找到最类似和最相干的 suggesiton,作为举荐倡议。为此,咱们须要搭建举荐候选池、多路召回以及排序模块。
2.1 举荐候选池
2.1.1 构建流程
目前,咱们构建举荐候选池的形式比较简单,包含 3 个步骤:
- 应用多种起源的数据,包含解决方案的题目、用于用意辨认的标注数据以及大量的聊天日志;
- 而后进行一些预处理,例如删除太短或太长的音讯,并应用编辑间隔或聚类删除一些反复的 query;
- 最初,为了管制倡议的品质,咱们要求各市场当地的业务审查这些 query,或将它们改写为标准化的 query。譬如,咱们会进行纠错,并删除脏字。
2.1.2 举荐样例
以下是咱们举荐候选池中的一些举荐样例。对于每一个 suggestion,咱们也有相应的解决方案。当用户点击该举荐 suggestion 时,咱们会给用户相应的解决方案作为答案。
举荐 suggestion | 解决方案 |
---|---|
May I know the status of my order? | 解决方案 1 |
I have not received my order yet. | 解决方案 1 |
Why is my order not delivered yet? | 解决方案 1 |
Why i cannot activate my shopeepay? | 解决方案 2 |
Why am I unable to set up my shopeepay account for my refund? | 解决方案 2 |
What is shopeepay? | 解决方案 3 |
I would like to check on my shopeepay status. | 解决方案 4 |
Why is my order cancelled? | 解决方案 5 |
When is the delivery time for my order? | 解决方案 6 |
2.2 多路召回
对于召回,咱们采纳了多路召回再合并的形式,目前包含文本召回和向量召回两种形式。
2.2.1 文本召回
对于文本召回,咱们采纳了业界规范的计划,应用 Elasticsearch (ES) 来进行关键词匹配召回。除了基于 ES 的 BM25 分数 [1] 进行排序外,咱们还用解决方案的 CTR 来作为加权因子,以进一步晋升召回的成果。
2.2.2 向量召回
文本召回容易了解和实现,但其成果依赖于 query 跟 suggestion 是否有匹配的关键词。为了召回和 query 用词不同然而表白语义雷同的 suggestion,往往须要对 query 进行纠错、丢词、同义词替换和改写等解决,尤其是当字面齐全匹配的 suggestion 不多的时候。
在咱们的场景中,用户输出 query 较长,表述偏口语化,因而开掘停词和同义词老本较高。另外,Shopee Chatbot 面向不同的地区和不同的语种,场景和数据的多样性也减少了算法工作的老本。
思考到这点,咱们采纳了向量召回 [2] 的形式,从大量的弱监督、用户行为日志来训练向量召回模型,用 query 向量和 suggestion 向量来掂量两者的语义相似性,以隐式的同义改写召回来作为文本召回的补充,在肯定水平上缓解这种问题。
向量召回的计划对于多地区和多语言均实用,升高了适配老本。另外也能进行跨语言召回,譬如输出 query 是中文,召回英文的 suggestion。
因为目前的举荐候选池都是繁多语种的,例如英文,如果用户输出中文,仅依附文本召回,无奈返回适合的举荐 suggestion 给用户。而依附跨语言的向量召回,则也能举荐语义相干的 suggestion,如“where to use my voucher”和“哪里能够用优惠券”,具备类似的语义。
另外,对于某些多语言市场,例如 MY 和 PH,咱们也只需筹备一个多语言的向量召回模型,就能实现不同语言的了解和召回,而无需针对各繁多语种别离训练召回模型。
为了实现向量召回,咱们须要有一个文本编码器,能对文本进行编码,失去对应的向量,再进行向量召回。通常有以下两种办法:
1)基于双塔模型
在双塔模型 [2] 中,咱们别离有 query 塔和 suggestion 塔别离对用户输出 query 和举荐 suggestion 进行编码,映射到浓密向量。基于 query 和 suggestion 的向量,能够计算两者的类似度,如余弦类似度。对于相干的 query 和 suggestion,咱们心愿两者的类似度越大,反之心愿其类似度越小。因而依据该类似度与 query 和 suggestion 是否相干,能够计算损失,训练模型。
2)基于预训练语言模型
另一种办法是应用一些预训练的模型作为文本编码器,例如预训练的语言模型。该办法当初被广泛应用在诸多 NLP 场景,并且是目前许多 NLP 利用中的 state-of-the-art 办法。具体在咱们的利用中,咱们应用 Facebook 的跨语言预训练语言模型 XLM[3],联合对应的分词器,它能够解决 100 多种语言。
2.2.3 基于多语言和多任务预训练的向量召回
1)持续预训练(Continue Pre-train)
因为 Facebook 的 XLM 基于公开数据进行训练,为了使其能更好地适配咱们的场景和数据,咱们通过持续应用畛域内和工作内的语料库进行持续预训练(continue pre-train)来晋升模型性能。具体来说,参考文献 [4],咱们应用 3 阶段办法:
- 阶段一 :应用来自不同市场、不同语言的大量聊天日志作为无标注数据,训练多语言的 Masked Language Modelling 工作(M-MLM)[3];
- 阶段二 :应用来自用意辨认模块的点击日志作为弱标注数据(结构形式如下图所示),训练多语言的用意分类工作(M-CLS)。跟阶段一相似,咱们也采纳不同市场的数据来进行多任务训练;
- 阶段三 :应用来自用意辨认模型的标注数据,应用用意分类工作(CLS)来进一步微调 XLM。对于不同市场的用意分类工作,咱们别离应用相应的语料进行独自微调。
2)常识蒸馏(Knowledge Distillation)
为了使大型预训练语言模型可用于在线服务,咱们进一步对其进行常识蒸馏 [5],将大模型(teacher)变成更小的模型(student),如 TextCNN,示意图如上图所示。
在实践中,咱们应用了以下 3 项技术来晋升蒸馏的成果:
- 引入 noise:参考文献 [6],咱们在蒸馏的过程中,引入 noise 来晋升模型学习特色示意的鲁棒性,同时也晋升样本的利用效率,使得其能笼罩更全面的数据输出散布;
- 利用大量的半监督数据 :参考文献 [6],咱们利用聊天记录的无标注数据以及点击日志的弱标注数据等大量的半监督数据,充沛学习 teacher 大模型 XLM 在更全面的数据输出散布上的特色示意散布;
- 2 阶段蒸馏 :为了最大限度保留和学习 teacher 大模型 XLM 的常识,咱们也采纳了和畛域预训练相似的 2 阶段的办法进行蒸馏,别离从畛域预训练的第二阶段和第三阶段的所失去的 teacher 大模型 XLM 顺次蒸馏。
下图所示为残缺的持续预训练和蒸馏过程。
2.2.4 试验成果
1)试验一:用意辨认工作
模型 | 准确率 |
---|---|
TextCNN (Baseline) | 0.64287 |
XLM | 0.63125 |
+ 聊天日志持续预训练 | 0.66556 |
+ 点击日志持续预训练 | 0.67346 |
+ 蒸馏 | 0.66400 |
因为咱们的 XLM 模型是基于用意辨认的数据和工作进行训练的,咱们首先在用意辨认的工作中比照不同办法的成果。其中,TextCNN (Baseline) 示意采纳 FastText 预训练词向量和 TextCNN 的基准模型,XLM 为应用公开的 XLM 进行微调失去的用意辨认模型。
如上表所示,基于畛域内和工作内数据进行持续预训练,能够晋升预训练模型的成果 3%~4%,而通过蒸馏之后,模型成果只有 1% 的降落。
2)试验二:下拉举荐工作
模型 | 召回率 |
---|---|
文本召回 | 0.83443 |
向量召回(SentBERT) | 0.84129 |
向量召回(TextCNN) | 0.88071 |
接着,在下拉举荐中,进一步验证预训练模型利用于向量召回的成果。基于离线数据集,咱们比拟了文本召回和向量召回的成果。对于向量召回,咱们别离应用了基于公开的 SentBERT[7] 的文本编码器以及对 teacher 大模型 XLM 蒸馏失去的 TextCNN。
如上表所示,向量召回整体成果比文本召回要好,而且应用畛域预训练和蒸馏的 TextCNN,相比 SentBERT 有 4% 的晋升。
3)蒸馏前后比照
模型 | 模型大小 | 计算工夫 |
---|---|---|
XLM | 1064MB | 150ms |
TextCNN | 180MB | 1.5ms |
优化比例 | 83% | 99% |
由试验一能够看到,XLM 模型通过蒸馏之后,成果只有 1% 的降落。上表进一步了展现蒸馏前后的模型大小以及计算工夫。能够看到,两者别离有较大幅度的降落,尤其是计算工夫的缩减,使得蒸馏之后的 TextCNN 模型能够利用于在线推理。
2.3 排序模块
2.3.1 问题背景
基于多路召回,咱们能对召回的 suggestion 有一个初步的排序。在此基础上,个别也会须要一个排序的环节,起因如下:
- 召回分数,例如 BM25 或者向量类似度,不足以取得更好的性能;
- 除了输出 query 和举荐 suggestion 之外,咱们还心愿蕴含其余特色(例如,用户特色)以取得更好的排序成果;
- 咱们还想针对多种指标进行联结优化,例如点击率(CTR)或解决率(相似于转化率 CVR)。
2.3.2 基于 DeepFM 的 CTR 预估模型
基于下拉举荐积攒的曝光和点击数据,咱们构建了 CTR 预估模型用于对下拉举荐进行排序。具体而言,咱们采纳了被宽泛应用的 DeepFM[8]。
在上图底部所示的输出层中,咱们有各种类型的特色,包含输出 query 和举荐 suggestion 等文本特色,解决方案的 id 等类别型特色,以及解决方案的一些统计信息等数值型特色。在中间层,咱们为每种类型的输出设计了不同的处理单元,如针对文本输出的 CrossEncoder(例如 ALBERT[9]、RE2[10] 和 ESIM[11] 等)。
2.3.3 基于 ESMM 的多指标排序模型
同时,咱们也进行了多指标的优化尝试。具体到 Chatbot 的场景,咱们心愿用户能点击 suggestion,也心愿该 suggestion 所对应的解决方案可能解决用户的问题。对于是否解决用户的问题,咱们的定义是,如果该用户没有转人工 & 没有掉线 & 没有差评,就认为是解决,用户门路如下图所示。
借鉴搜寻举荐广告场景,能够将解决率预估类比成转化率预估(CVR)问题。因而,咱们尝试了基于 DeepFM 的多指标优化模型 ESMM[12],并进一步摸索采纳 MMoE[14] 和注意力机制的 ESMM 模型,两个模型构造别离如下图所示。
上图中的概率存在以下关系:
P(resolved=1,click=1|q,s)=P(click=1|q,s)*P(resolved=1|click=1,q,s)
其中,q 代表输出 query,s 代表举荐 suggestion,并且
pCTCVR=P(resolved=1,click=1|q,s)
pCTR=P(click=1|q,s)
pCVR=P(resolved=1|click=1,q,s)
最终模型的损失蕴含 CTR 和 CTCVR 两个工作在整体数据样本上的损失。
2.3.4 试验成果
1)试验一:CTR 预估
模型 | NDCG@5 |
---|---|
BM25 (baseline) | 0.66515 |
LR | 0.73303 |
XGBoost[13] | 0.75931 |
DeepFM+ALBERT[9] | 0.77874 |
DeepFM+RE2[10] | 0.77118 |
DeepFM+ESIM[11] | 0.79288 |
基于下拉举荐积攒的曝光和点击数据,咱们比拟了不同 CTR 预估模型的性能。如上表所示,带有不同 CrossEncoder 的 DeepFM 具备最优的成果。
2)试验二:多指标优化
模型 | AUC on CTR Task | AUC on CVR Task | AUC on CTCVR Task |
---|---|---|---|
DeepFM (CTR Task) | 0.85500 | 0.52100 | 0.77470 |
ESMM NS | 0.85342 | 0.66379 | 0.79534 |
ESMM | 0.85110 | 0.58316 | 0.78895 |
ESMM+MMoE | 0.85410 | 0.65215 | 0.79532 |
基于下拉举荐积攒的曝光、点击以及解决数据,咱们比拟了不同多指标排序模型的成果,其中 ESMM 为共享 DeepFM 的模型(Shared-Bottom),ESMM NS 为不共享 DeepFM 的模型。如上表所示,基于 ESMM 的多指标模型相比纯 CTR 模型,在 CTR 和 CVR(在咱们的场景中,对应解决率)两个工作中,均有较好的成果。
咱们还能够看到,ESMM NS 的成果比 ESMM 要好,这个跟 ESMM 原论文 [12] 的后果刚好相同。
对于这个后果,咱们的猜测是:在咱们的场景中,解决率个别都比拟高(如 70% 以上),因而对于解决率预估工作,其样本数量不会像 CVR 工作那么稠密,在这种状况下,Shared-Bottom 模型不肯定能带来成果晋升。反而各工作应用不同的 DeepFM,能够学习不同工作之间不同的个性,获得更好的成果。然而 ESMM NS 的内存占用和计算工夫也比 ESMM 要高。
咱们进一步尝试在 ESMM 的框架中融入 MMoE 和注意力机制,学习工作之间的特异性,性能有进一步晋升,而其相比 ESMM NS,在 CVR 工作下面只有 1% 的升高。因为 ESMM+MMoE 具备共享的 DeepFM,因而其在内存占用 / 计算工夫与成果之间,获得了较好的均衡。
3. 零碎实现
在第 2 章中,咱们介绍了 Shopee Chatbot 下拉举荐的整体计划。在本章中,咱们再介绍下整体的零碎架构(如上图所示),包含离线局部和在线局部。
3.1 离线局部
3.1.1 模型训练
针对其中的两个外围模型,即向量召回中的文本编码器以及排序模型,咱们会应用曝光和点击日志,定期训练和更新模型,以使模型能放弃较好的成果。其流程如下图所示。
3.2 在线局部
3.2.1 模型推理
模型推理局部就是把多个环节串接起来。对于用户的输出 query,先调用文本编码器失去其文本向量,再并行申请文本召回和向量召回,而后对召回后果进行合并,最初调用排序模型,输入排序的 Top5 举荐作为 suggestion 展现给用户。
为了放慢模型推理速度,咱们应用 ONNX 来部署文本编码器以及排序模型(均应用 PyTorch 训练)。同时,应用 Redis 来缓存高频输出 query 的多路召回的后果,缩小反复计算和召回申请。因为后续排序模型会应用用户和场景等的特色,咱们目前并不间接缓存最终的 Top5 举荐后果,而由排序模型动静决定最终排序输入。
3.2.2 召回服务
在取得举荐候选池后,或者举荐候选池产生更新后,咱们基于 Elasticsearch 构建文本召回服务。
对于向量召回,咱们应用 Shopee Chatbot 工程团队基于 Faiss 搭建的向量召回服务,流程如下图所示。
因为目前下拉举荐的候选池依赖于人工标注产生,数量还比拟小,在万级左右,因而咱们抉择了 HNSW 的形式 [15]。对于 5W 左右的 suggestion,512 维度向量,整体索引占内存大小为 800M 左右。
同时,咱们比照了 IndexIVFFlat 和 HNSW 两种索引的在线检索成果,HNSW 在 CPU 资源耗费更低的状况下,可能提供更快的检索成果,满足下拉举荐在线服务的需要。
3.2.3 模型试验
为了不便 AB 试验,咱们在设计和实现该下拉举荐零碎的时候,使得其外部能够轻松组装不同的模块来构建可用的在线服务,譬如组合不同的召回和排序模型。此外,联合日志数据和试验报表,咱们能够进一步剖析试验成果。
4. 业务成果
通过业务、产品、工程和算法等多个团队的通力合作,咱们于 2021 年 6 月首次上线了下拉举荐性能,并于 2021 年 9 月推广到目前 Shopee Chatbot 所笼罩的所有市场上,并且带来了不错的业务成绩。截至目前,咱们大略有 3 个次要的版本,成果别离如下:
- 性能上线 :在 Shopee Chatbot 笼罩的所有市场上线,整体解决率晋升 1%;
- 召回优化 :上线基于文本召回和向量召回的多路召回,线上 CTR 晋升 2%;
- 排序优化 :上线基于 LR 和 DeepFM+ESIM 的 CTR 预估模型,线上 CTR 别离晋升 2% 和 6%。
5. 将来瞻望
通过一段时间的优化,Shopee Chatbot 下拉举荐获得了初步的成绩。将来,咱们心愿能够从以下几方面来进一步晋升其成果,以帮忙用户能更好地应用 Chatbot 产品。
1)数据方面
- 扩充举荐池的数量,笼罩更多的用户问法;
- 进步举荐池的品质,提供更好的用户体验。
2)召回方面
- 利用下拉举荐自身积攒的曝光和点击数据优化目前向量召回模型;
- 摸索多语言召回,解决多语言场景下的下拉举荐问题 [16]。
3)排序方面
- 引入更多的用户和场景特色,晋升排序成果,摸索个性化用户举荐;
- 评估多指标排序模型上线成果,同时也尝试其余的多任务和多指标优化办法 [17]。
4)产品方面
- 引入摸索和利用机制,解决知识点冷启动问题,继续优化成果;
- 摸索新的产品状态,如主动补全机制等。
6. 参考文献
[1] https://en.wikipedia.org/wiki/Okapi_BM25
[2] Embedding-based Retrieval in Facebook Search
[3] Unsupervised Cross-lingual Representation Learning at Scale
[4] Named Entity Recognition with Small Strongly Labeled and Large Weakly Labeled Data
[5] Distilling the Knowledge in a Neural Network
[6] Self-training with Noisy Student improves ImageNet classification
[7] Sentence-BERT: Sentence Embeddings using Siamese BERT-Networks
[8] DeepFM: A Factorization-Machine based Neural Network for CTR Prediction
[9] ALBERT: A Lite BERT for Self-supervised Learning of Language Representations
[10] Simple and Effective Text Matching with Richer Alignment Features
[11] Enhanced LSTM for Natural Language Inference
[12] Entire Space Multi-Task Model: An Effective Approach for Estimating Post-Click Conversion Rate
[13] XGBoost: A Scalable Tree Boosting System
[14] Modeling Task Relationships in Multi-task Learning with Multi-gate Mixture-of-Experts
[15] https://github.com/facebookresearch/faiss/wiki/Guidelines-to-choose-an-index
[16] Making Monolingual Sentence Embeddings Multilingual using Knowledge Distillation
[17] Progressive Layered Extraction (PLE): A Novel Multi-Task Learning (MTL) Model for Personalized Recommendations
本文作者
Qinxing、Yihong、Yiming、Chenglong,来自 Shopee Chatbot 团队。
致谢
Lennard、Hengjie,来自 Shopee Chatbot 团队。