探索实践—如何寻找相似问题？

见贤思齐

在有赞，技术支持日常工作中最重要的内容是快速解决商家问题，通常线上发生问题后我们将会根据影响商家数、影响范围、影响场景做级别区分。但商家在遇到问题时候，不同商家反馈的现象描述也存在区别、接待处理的人员也是来自不同业务线。这里会导致技术支持在查看问题工单，在对影响范围的判断上比较滞后，下面我们就来探索如何从不同问题中找出相似问题。首先在判断 2 个现象描述是否为同一问题时候，通过模块是没办法区分的，比如营销玩法-优惠券，关于优惠券的问题会非常多，无法具体场景的区分。不可能是优惠券场景的都有问题，那么我们只有从不同工单中的描述内容中去进行字符串匹配。通常字符串匹配有 3 种算法，1 种是场景匹配模式。通常一段现象描述中会有 X（名词）、Y（动词）、Z（形容词），其次是部分语句场景中会有副词。比如“优惠券页面访问空白”、“优惠券卡片链接打不开”、“优惠券页面点击没反应”、“优惠券领取提示失败”、“优惠券领取报错”等等，在这种现象中优惠券是名词；领取、打开、点击是动词；打不开、没反应、空白是形容词。通常这里要想更进一步区分具体现象是否为一类的话，还需要一个 β（现象近义词组），那么匹配率越高就看β的计算是否一致。如下图所示在上图中我们可以看到如果空白跟打不开是近义词那么他的匹配度就是 100% ，如果失败跟报错不是近义词那么匹配度可能只有 90% ，这里可以设定 β+、β、β- 来决定近义词的相似度。其中 X、Y 的比重可以根据每个业务不同来衡量，推荐的比重是 50%、20%、30% 。实现过程另外一种场景就是文字匹配模式，这种模式会简单的多，直接将每句描述的每个字拆单，组成 A 到 Z 的数组，2 组描述内容相互匹配时候，通过数组的长度来决定。假设 A 内容长度为 E、B 内容长度为 G ，那么匹配公式是 A:A in B+A:B in B+A:C in B+A in B+A:E in B =α ，α/E 就是相似度。还是以之前举例的场景来看。从上述匹配效果来看，场景模式算法更加精准，但是也需要更多的维护成本，在程序没有好的学习算法前只有靠人投入才能维持较高水平，并且需要时刻根据产品得带来获取更精准的学习边界。而文字匹配算法则比较简单，并且从程序性能角度来说更高效，但是在描述文字较少时候则匹配度会在较低水平，从实际的工单情况来说，文字匹配目前效率要比场景模式高很多。这2种算法可以广泛运用在金融风控、知识答疑、内容检索业务范畴，也可极大提高工作效率。