我通常也把相关query称为相似query,搜索日志中一个用户在短时间内的一系列搜索词被称为相关query。
相关就是两个query间有一定的关系,反映了用户在当时的需求。
本文就以应用搜索为背景来介绍相关query。
相关query的作用就很多了:
- 错词纠正:输入一个错误的词找不到应用,然后输入一个正确的词
- 同名互换:和错词纠正是一个场景,如中英文名称(cytus和音乐世界),别名(艾达的梦和纪念碑谷)等
- 同义词:对战和对打;台球和桌球等
- 同类型应用:如微信和QQ,美团和糯米等
- 内容补充:如ttkp和天天酷跑,土和土豆,天之痕和轩辕剑等
当用户输入一个query时,后台加入其相关query一起搜索,就可以更好的理解用户,返回更多、更准确的结果,减少搜索次数,提高下载次数,提高转化率。
候选数据
分析每天的用户日志,从搜索日志中提取短时间(15分钟或30分钟)内的搜索词组成候选相关query对<a, b>。
最后分析的日志天数越多越好,数据越多挖掘出的相关query对越多,结果也越准确。
特征抽取
- 共现相似度:条件概率的变体,增加了对大query的惩罚(出现频率比较高的top query,如微信,大query和其他query共现的可能性更大)
- 编辑距离:反映两个query词在内容上的相似程度,如天天赛车和天天飞车,它们都有天天,有一定的加分贡献,但应该以共现相似度为
模型训练
- 人工标注样本数据,指出一定量的query对(query pair)是相关query或者不是
- 确定候选机器学习算法,如逻辑回归、SVM或者决策树等,用样本数据训练模型
- 用训练好的模型预测原始数据,根据实际效果最终确定一个算法
补招漏选数据
最终结果的多少的主要影响因素有用户搜索日志间隔、日志天数。
具体实现过程中发现和大query相关的小众query招不回来,因为其本身搜索次数太多。
但我们需要大query来为小query导流。
<纪念碑谷(44736次),天空迷宫(200次)>,共现次数是89次,相似度是0.004,相似度太低,导致纪念碑谷无法召回天空迷宫。
<天空迷宫,纪念碑谷>其相似度是0.069,被认为是相关query。
所以我们会反向找一次,对于相关query对<天空迷宫,纪念碑谷>会判断下其反向对<纪念碑谷,天空迷宫>的情况,如果发现纪念碑谷是大query(超过一定次数如1w)且其自身相似度超过一定域值(如0.003),我们也会把<纪念碑谷,天空迷宫>给招回来。
线上反馈
在线系统使用离线数据(相关查询对)进行了线上搜索结果的补充或召回,将相关query对应的应用展示给了用户,用户会选择下载与不下载。
我们就获得这些数据来重新训练算法模型。
queryA的下载列表<appIds>
从appIds中找到queryA的相关queryB召回的应用:app应用名与queryB的编辑距离超过一定值,就认为该app是由queryB召回
如果queryB召回的应用下载数超过一定域值,我们就认为这是一个正向case,queryB是queryA的相关query
如果queryB召回的应用没有下载或下载小于一定数目,就认为是一个负向case,queryB不是queryA的相关query
这样我们就可以通过线上展示结果获取一份真实的标注数据,用该数据去重新训练算法,获得一个新模型来重新预测原始数据。
线上反馈的作用就是找到真实标注数据,替换旧样本获得新模型,从而不断提高模型的准确度
持久化good case,避免回退
最初<queryA, queryB>是相关query对,每当用户搜索queryA时,就会出来queryB的结果。
时间久了,用户输入queryA后就不会再输入queryB,那就导致可能在某段时间后挖掘不出该相似对,那queryA下就无法显示queryB对应的应用;用户又会渐渐的在输入queryA后再次输入queryB才能获得想要的结果。
这样就导致效果起伏,我们需要避免这种情况。
所以对每次线上反馈中的正向case,我们都做持久化,以白名单的形式强制加到最终的相关query中。
以此来积累正向case,减少效果回退的情况。
到现在为止,我们就拥有了一个动态、完整、可持续的离线在线相互反馈促进的系统了。
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)