闲鱼怎么和没有商品的卖家私聊闲鱼怎么私聊( 二 ) _闲鱼

前面已经实现了议价意图的算法识别，这次又要新增一种打招呼的识别，是否要重新开发整个流程呢？显然不需要，前期议价为了快速迭代上线看效果，没有抽象设计成一种通用的意图识别流程，这次新增第二种意图识别，有必要还债重新设计了，任何优秀系统的设计都是不断迭代重构产生，绝不会是一蹴而就的，项目初期在需求不明确的情况下假如考虑的过多，往往会导致过度设计，后面假如需求变动，又要返工。故重新抽象设计一套通用的意图识别流程框架。
流程设计：
类图：
如上图所示，每种意图需要实现IntentProcessor接口，实现自己的过滤和处理逻辑，不同意图有不同的初筛逻辑和扩展参数，filterAndCompleteContext这个方法是用来过滤和补充意图识别扩展参数到流程上下文中的，假如满意初筛条件，就添加该意图类型到可能的意图列表中，由算法识别最终结果，假如一条消息存在多种意图，由算法根据优先级规则选出最相关的意图。得到意图识别结果后，调用对应的IntentProcessor的process方法，完成详细的业务逻辑处理，如在议价场景是根据价格规则，组装不同文案下发建议卡片。
4.产品效果
开场白：
打招呼：
四、从问答中取栗1.为什么总是问我同一个问题？
我们观察数据发现，聊天中商品问询场景覆盖率35%～40%，因为闲鱼商品交易独特的二手属性，卖家可能会面临同一个商品同一个问题会被多个买家多次问到，从而重复回答的情况，卖家有苦说不出，只能内心os"为什么总是问我同一个问题？" 。为了优化卖家体验，提高卖家回复效率，我们决定识别聊天中的问答对，然后在问答对消息后面插入引导tip，卖家侧可以选择将问答对补充到商品详情中，假如问答对中含有商品结构化二手属性信息(比如成色、有无拆修、品牌等)，也会识别并引导卖家补充商品的结构化属性。
2.通用消息扩展属性变更
我们上面说的意图识别流程框架立刻就用了起来，这时候只需要新增一种意图识别处理器(IntentProcessor),实现该场景的过滤和处理逻辑，就可以轻松实现整个功能。但新的问题来了，上面的议价、打招呼场景中我们给卖家侧的引导都是一种建议类卡片，这种卡片是一条新消息，与其他的消息一起混排，而且与触发源消息关联性不强，即使有延迟导致卡片插入到偏后的位置，影响也不是很大。但是问答这种场景，下发的是一条引导tip，这个tip是与答案所属的消息强关联的，引导tip必须紧跟答案消息后面，假如对不上，就会非常影响体验。闲鱼的消息列表是按照发送时间排序的，假如按以往新消息的形式插入，无法严格保证下发时机紧跟在某条消息后面，假如人为的修改消息的发送时间，会破坏消息发送时间这个字段的语义。我们从另一个角度思索，这条tip一定是紧跟在某条消息后面，如影随形，不离不弃，那么为什么不合二为一呢？把这条tip看成是这条消息的一个扩展属性，所以我们决定引入一种通用变更消息扩展属性的能力，通过事件下发给客户端，再由客户端根据约定的协议解析并展示，如下图所示
由业务发起对某条消息的扩展属性变更，可选设置存储服务端消息库，更新会话视图，比如问答场景的tip，是有时效性的，只需要透传给客户端，服务端完全不需要存储。该方案也为以后消息的个性化变更及展示提供了可能。
3.产品效果
五、总结与展望至此，我们的聊天小助手沉淀出了一套通用的意图识别流程框架，实现了议价、打招呼、问答三种意图识别，引导广大个人卖家跟买家好好聊天，帮助卖家快捷补充更具体的商品信息。聊天小助手上线后，功能使用率较高，实验桶相比对照桶，回复率相对提升4%，在议价场景中，下发卡片的实验桶相比对照桶成交转化率相对提升4%，从数据来看，确实也证实了我们之前的推断，引导买卖聊天，对促成交易有正向作用，为接下来该项目的继承演进提供了可能。

闲鱼怎么和没有商品的卖家私聊 闲鱼怎么私聊( 二 )

闲鱼怎么和没有商品的卖家私聊闲鱼怎么私聊( 二 )