陈琳|试着读懂你的心 - 闲鱼聊天小助手的探索之路( 二 )



不同类目的商品聊天中买家关注的问题点不同 , 我们基于离线数据分析 , 回捞了一批不同类目买家最关心的问题列表 , 把这些问题首先按类目分类 , 其次按关注点(二手属性)分类 , 再加上触发规则条件、权重分 , 形成一套开场白问题库 , 可由产品运营自助添加修改 。 流程图:

如上图所示 , 当会话创建时 , 先根据类目读取问题库得到对应的问题列表 , 再根据这个商品本身的一些属性标 , 如是否包邮 , 是否全新 , 按规则筛选出符合条件的问题列表 , 再根据权重分对满足条件的问题进行加权随机 , 最终得到某个二手属性的问题项 。 为了保证问题内容的多样性 , 每个二手属性的问题项也会有不同文案但相同语义的表达 , 最后再次随机一个具体问题表达 , 即可下发建议卡片 。
3.意图识别流程框架
前面已经实现了议价意图的算法识别 , 这次又要新增一种打招呼的识别 , 是否要重新开发整个流程呢?显然不需要 , 前期议价为了快速迭代上线看效果 , 没有抽象设计成一种通用的意图识别流程 , 这次新增第二种意图识别 , 有必要还债重新设计了 , 任何优秀系统的设计都是不断迭代重构产生 , 绝不会是一蹴而就的 , 项目初期在需求不明确的情况下如果考虑的过多 , 往往会导致过度设计 , 后面如果需求变动 , 又要返工 。 故重新抽象设计一套通用的意图识别流程框架 。
流程设计:

类图:

如上图所示 , 每种意图需要实现IntentProcessor接口 , 实现自己的过滤和处理逻辑 , 不同意图有不同的初筛逻辑和扩展参数 , filterAndCompleteContext这个方法是用来过滤和补充意图识别扩展参数到流程上下文中的 , 如果满足初筛条件 , 就添加该意图类型到可能的意图列表中 , 由算法识别最终结果 , 如果一条消息存在多种意图 , 由算法根据优先级规则选出最相关的意图 。 得到意图识别结果后 , 调用对应的IntentProcessor的process方法 , 完成具体的业务逻辑处理 , 如在议价场景是根据价格规则 , 组装不同文案下发建议卡片 。
4.产品效果
开场白:

打招呼:

四、从问答中取栗 1.为什么总是问我同一个问题?
我们观察数据发现 , 聊天中商品问询场景覆盖率35%~40% , 因为闲鱼商品交易独特的二手属性 , 卖家可能会面临同一个商品同一个问题会被多个买家多次问到 , 从而重复回答的情况 , 卖家有苦说不出 , 只能内心os\"为什么总是问我同一个问题?\" 。 为了优化卖家体验 , 提高卖家回复效率 , 我们决定识别聊天中的问答对 , 然后在问答对消息后面插入引导tip , 卖家侧可以选择将问答对补充到商品详情中 , 如果问答对中含有商品结构化二手属性信息(比如成色、有无拆修、品牌等) , 也会识别并引导卖家补充商品的结构化属性 。
2.通用消息扩展属性变更
我们上面说的意图识别流程框架马上就用了起来 , 这时候只需要新增一种意图识别处理器(IntentProcessor)实现该场景的过滤和处理逻辑 , 就可以轻松实现整个功能 。 但新的问题来了 , 上面的议价、打招呼场景中我们给卖家侧的引导都是一种建议类卡片 , 这种卡片是一条新消息 , 与其他的消息一起混排 , 而且与触发源消息关联性不强 , 即使有延迟导致卡片插入到偏后的位置 , 影响也不是很大 。 但是问答这种场景 , 下发的是一条引导tip , 这个tip是与答案所属的消息强关联的 , 引导tip必须紧跟答案消息后面 , 如果对不上 , 就会非常影响体验 。 闲鱼的消息列表是按照发送时间排序的 , 如果按以往新消息的形式插入 , 无法严格保证下发时机紧跟在某条消息后面 , 如果人为的修改消息的发送时间 , 会破坏消息发送时间这个字段的语义 。 我们从另一个角度思考 , 这条tip一定是紧跟在某条消息后面 , 如影随形 , 不离不弃 , 那么为什么不合二为一呢?把这条tip看成是这条消息的一个扩展属性 , 所以我们决定引入一种通用变更消息扩展属性的能力 , 通过事件下发给客户端 , 再由客户端根据约定的协议解析并展示 , 如下图所示