LTR：应用于电商智能客服领域知识库搜索的实践

 

 

关键词：搜索、机器学习、学习排序、Learning to Rank(LTR)

 

1：背景

 

搜索引擎排序（Ranking）的优化是搜索领域中普遍遇到的问题，通常会涉及到很多的排序策略，传统的排序方法一般通过构造相关度函数，然后按照相关度进行排序。影响相关度的因素很多，也有很多经典算法模型来满足这一需求，但是对于传统的排序方法，有很多特征信息的情况下，单一的函数或者模型很难融合很多参数，也容易出现过拟合的现象，而机器学习方法很容易融合多种特征，能一定程度的解决稀疏、过拟合等问题。因此，以机器学习的理论基础来解决ranking问题便形成了Learning to Rank（学习排序、LTR）的方法。

 

Learning to Rank是在机器学习领域中有监督学习（Supervised Learning）的排序方法，如今已经被广泛应用于搜索场景、推荐场景、QA场景、情感分析场景中。比如传统的web search，文本挖掘，推荐系统，QA中的结果排序，机器翻译中排序候选翻译结果等等。

 

本文主要介绍LTR在限定领域知识库搜索的优化中的简单应用的过程。

 

2：客服智能辅助（IA）系统

 

随着互联网互越来越普及，作为电商平台，如何提供给大群体的买家，卖家以最优质的服务已经成了一个重点话题，也是一直在解决的难题。常见的人工智能（AI）客服系统，比如语聊机器人大部分智能解决用户QA类简单咨询问题。在我们的人工智能客服系统-阿里小蜜中，机器人智能问答是用户接触的第一层服务。当机器人遇到解决不了的复杂问题，比如流程性较强，个性化的问题时需要人工在线解决，此时用户会接触到在线人工客服，而非机器人。而本文的讨论的产品方寸就是一款应用于人工客服端，辅助人工解决用户各类问题的智能工具，致力于解决业务问题场景复杂，客服人员人数少且服务水平良莠不齐，但是要提供给客户统一优质的服务等一系列问题，以辅助越来越多未经过专业客服技能培训的人员快速上岗同时不降低服务质量，来满足越来越多的用户服务需求。本文介绍的就是方寸中的知识搜索功能。

 

3：LTR在限定领域知识库搜索优化的应用

 

在使用机器学习理论之前，方寸搜索使用的是比较传统的知识库检索的方式：使用常见的NLP算法组件为所有知识的标题做好分词和同义词后使用opensearch构建索引，检索过程中，先使用用户query item直接recall至多不超过500条数据，再对召回结果和query词做相似度排序。这种简单检索的方式慢慢无法满足我们的客服人员对于越来越多而且越来越复杂的业务知识的搜索。

 

一般行业内的搜索分为：检索、粗排、召回 （basic search），精排（advanced search）包括相关度打分，个性化特征精排，rerank 等等。LTR理论常用于搜索精排ranking，作为有监督的学习过程，学习数据来源最常见的还是标注，标注一般分为三级分数（相关，一般相关，不相关）或者五级分数（非常相关，相关，一般相关，不相关，非常不相关），但成本非常大。经过大量的数据分析，我们最终选择了非人工标注的方式-日志分析。在web search或者较复杂的搜索场景中，日志分析常用于basic search中召回的features，比如搜索，浏览，是否点击，点击后停留时间，是否换query，点击后的操作，收藏，转发，分享等交互行为，而个性化特征精排会比较倾向于用用户特征，比如性别，年龄，收入，身份，兴趣，群体甚至一些外界自然因素比如季节，天气，时间等等作为特征来标注数据分析。我们选择非标注的方式除了基于大量的数据分析之外，也和业务场景有关，在一个限定领域的知识库搜索这个场景下，user相关的上下文的用户信息特征几乎只和身份（客服人员所属部门，权限等等）相关，不太具有个人特征，而且document又是标准化的知识，因此最终决定使用日志分析的方式获得数据。

 

 

 

如上图所示，应用交互层发起搜索请求，经过opensearch的基本检索召回500条结果，之后进入rerank阶段，主要依赖LTR算法以用户的历史行为为重要特征做重排序，最终再将排序后的结果返回给用户端。

 

Learning to Rank一般有三种常见方式：Pointwise、Pairwise 和 Listwise。Pointwise是对每一个query和document的打分排序，是比较常用的方法，优点是简单，缺点是出现mismatch的时候是无法找到退而求其次的选择的。于是就有了Pairwise作为现在比较流行的一种方式，Pairwise其实并不针对用户输入，而是比较备选谁更好，不关心绝对值的得分，能有效的缩短绝对信息。但是标注的工作是比较多的，假如同一个query有A ，B，C三个备选目标，标注A比B好就是AB1，B不如C就是BC0，类似这样。目前流行的Pairwise的算法和paper还是比较多的，比如Ranking SVM，RankNet，RankBoost等等。Listwise相较于上面两类是比较不同的，个人感觉更适合作为推荐系统中的ranking，具体过程是将每个query对应的全部搜索结果作为一个训练sample，根据这个sample训练得到最优评分函数f，ranking的时候对于新的query，f对每个文档打分，然后根据得分高低排序为最终结果，本质上是学习排列组合中最高概率的方法。除了这三种主流的方式，针对不同的需求和调整，也有很多通过这三类衍生出来的方法，思路大致一致就不再一一列举。

 

通过以上简单的基础知识介绍和我们所面临的业务场景的分析，我们尝试了将Pointwise的思路运用到上文提到的限定领域的知识库搜索中。我理解的在我们应用场景中的Pointwise更像把搜索的ranking成了用户点击/没点的一个分类问题。而其他重要特征主要分为3类：1. Relevance Feature：query词的match或者overlap简单理解成字面相关性；2. 语义相关性； 3. 搜索目标本身的特性，类似于web search的page rank。因此，除了基于日志数据的是否点击，我们也做了TF-IDF的计算作为排序依据。下面举一个非常简单的例子来说明（非线上真实数据）： 

 

 

上图列举了两组query和两个标题为例，第一组query词是【苹果】按照tfidf相似度得分来看应该是问题【苹果是水果吗】作为ranking第一位的，但是由于训练数据中搜索过【苹果】的点击了问题。所以最终的ranking顺序会受到点击数据的影响，如何购买苹果手机将排在第一位。当然这个结果也会有一些陷阱，用户对于排在前面的搜索结果会带有天然好感，因此交互影响会造成数据影响，日志又来自于上一次模型，因此引导用户的bias的独立分桶实验也是十分重要的。

 

4：结论

 

Learning to Rank应用于方寸搜索场景上线后，随着数据的积累和学习，搜索转化率最终提升了10%左右，因此印证了在限定领域的知识库搜索场景中，机器学习理论对于ranking有着非常有益的帮助。下图为8月到12月的搜索点击转化率和Top5点击转化率值，从9月底上线后的数据变化。

 

 

综上，搜索的本质其实就是，user的特征（当然其中最重要的是输入query）和目标列表中的值（也包含自身特征）的match过程，而我们基于用户过去的历史行为来做ranking就是基于机器学习的理论基础。ranking problem 目标排序，期望在过去的历史数据建立学习系统得到排序方式。

 

这次实践过程总结了一些解决此类问题的经验：最重要的是分析数据，tips具体有以下几点：

 

1.   选择合适当前业务场景的模型，流行的算法或者高大上的paper不见得真的合适，学习其中的理论和思路，实际落地的过程最重要的是对业务和对数据的理解基础上找到适合自己的方法。

 

2.   Leaning中选择合适的损失函数（Loss Function）有很多解决不平滑无法求导的方式。另外像随机梯度下降，并行计算等可以在leaning中根据情况考虑。笔者本身是开发，所以也会在架构和实现方面会多考虑一些。

 

3.   根据业务场景科学的选择合适的Evaluation方案，同时考虑建立标准测试集和自动回归测试方案。

 

5：未来和探索

 

关于机器学习在ranking的应用，本文想分享的并不是理论上的知识，是应对不同的场景的实践过程。首先，解决此类问题最重要的日志分析，要对自己的业务有足够的理解。比如，在特定的搜索场景中，转化率的概念，如何评估满足了用户。比如搜索点击转化 、停留时间是否足够衡量搜索是否优秀。同时，需要注意的是点击浏览之后的行为链更为重要，但是在我们的业务场景下，受干扰的影响条件太过复杂暂时没有使用。但在其他典型搜索场景中，浏览后的分享，收藏行为也是LTR的重要特征。比如在电商的商品搜索中，点击后加购，下单，或者分享除了用户特征也可能受目标特征影响，比如价格，甚至受环境比如大促期间等等影响。第二，学习的特征来自与数据挖掘：用户信息做个性化query-term信息，转化后点击位置，timing时序概念，时间串联的用户行为链以及用户历史行为的捕捉。同时不能忽略交互带来的数据影响，最好做独立分桶实验。最后，本文没有涉及的是用户个体个性化的搜索探索，主要原因前文也有提到，业务场景并不是刚需，不过业界很多做个性化用户兴趣来影响ranking的方法也在实践过程中给到了很多思路。

 

本文介绍的是搜索中query full场景，是有用户主动输入query的，同时未来还会将这套理论结合深度学习应用于query less场景即无用户输入主动推荐知识，敬请期待。

 

6：References

 

 

 

以上，一个java开发工程师在做搜索优化过程中的一次简单探索算法之路，不专业之处还请大家批评指教~