特征存储及计算在CRM商机智能分配中的实践 AI + CRM 提高企业的 "绩" 和 "效"

Posted 2022-01-28 rsapaper

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了特征存储及计算在CRM商机智能分配中的实践 AI + CRM 提高企业的 "绩" 和 "效"相关的知识，希望对你有一定的参考价值。

AI + CRM 提高企业的 "绩" 和 "效" https://mp.weixin.qq.com/s/0b1oOvUZaEa4oLf88dfocA

58同城AI Lab产品能力介绍 https://mp.weixin.qq.com/s/sR_EedFNWrcULybxJyPJ1A

特征存储及计算在CRM商机智能分配中的实践 https://tech.58.com/article?id=145

詹坤林 58技术 2021-01-22 18:22

导读

2020年Q4，我们开展了黄页CRM商机智能分配项目，上线了机器学习分配模型，在各城市ABTest上线模型期间，将直销团队密歇根商机组的转出商机数提升了31.8%，将电销团队60秒有效通话商机数提升了 62%。

本文收益：了解58销售工作流程，了解CRM逻辑，了解个性化搜索排序、推荐、AI技术在CRM中的应用。

阅读时长：本文共7000字，阅读时长10分钟。

背景

2020年6月，我们AI Lab接手了CRM智能化算法工作。2020年9月，AI Lab、营销平台部（CRM）、LBG黄页业务方三方联合启动了商机智能分配项目，将机器学习和推荐技术应用于CRM，为每个销售人员分配适合其跟进的商机，优化成单转化，以提高销售团队业绩，进而提升业务线收入。

黄页销售团队包括直销、电销两种工作场景：

直销场景：

直销场景下销售人员会通过拨打电话、微信聊天（电话沟通后和用户加微信）、线下外访等方式持续跟进用户。在传统工作模式下，一个销售人员需要全程负责从拿到商机到成单整条链路上的所有工作。

2020年，黄页业务线对直销模式下销售人员工作流程进行了改革，打造了"密歇根"工作模式，在各个城市中将原始一个销售团队拆分成商机组、销售组两个工作组：商机组人员的任务是拨打商机电话以筛选出有可能购买58会员的用户，若用户有一定意向则这类商机被称作有效"转出"商机，"转出"的意思是指这些商机会被转给销售组工作人员，之后该商机就由销售组人员持续跟进，如电话联系、微信沟通、外访，直至成单，整个工作流程如下图所示：

图传统工作模式 vs 密歇根工作模式

在密歇根工作模式下，商机组的销售人员只会参与整条成单链路上的第一个环节，通过拨打一通电话来判断商机是否可转出，工作非常纯粹，不再需要参与后续深入的跟进、外访等，商机组需要产生更多的转出商机，每个销售人员的业绩指标是转出商机数量。经过商机组的过滤，销售组的销售人员拿到的商机都是有一定意向的用户，销售组只需做好后续的深入跟进、外访等工作，专心提高最终的成单数量。

相比传统工作模式下一个销售人员需要全程参与成单链路上的所有工作，密歇根模式将销售流程进行拆解，商机组和销售组各司其责，整个销售团队的工作效率变得更加高效。

电销场景：

电销场景下销售人员是全流程线上通过拨打电话、微信聊天等方式跟进用户，与直销的差别是无线下外访环节。电销场景下无密歇根工作模式，销售人员需全程负责从拿到商机到成单整条链路上的所有工作。

CRM商机分配逻辑

商机即潜在58会员信息，包括公司名称、行业、地址、联系人、联系电话等信息。CRM系统中包括新增商机、历史商机两类：新增商机指每日新流入的商机，销售人员从未触达过，这类商机量少，但成单可能性相对较高，成单周期相对较短；历史商机指销售人员跟进过但没有成单的商机，这类商机经过长期积累，数量巨大，但成单可能性低，成单周期较长。在日常工作中，销售人员大部分时间都是在跟进历史商机，一个商机往往需要销售人员花数月时间跟进多次才能最终成单。

在密歇根工作模式下，CRM系统设计了一系列功能模块来支持销售人员获取商机，具体如下图所示：

图密歇根模式下销售人员获取商机流程

基础概念介绍：

公海：公海库里存储的是历史存量商机，商机对所有销售都可见，系统通过商销匹配模块将公海商机推送给销售，销售通过一键申领模块从公海库搜索商机。
临时库：销售人员有一个临时库，从公海库获得的商机在销售跟进后可以绑定到个人临时库，绑定后只有销售自己可见。临时库中的商机有有效期限，一般为数天，若某条商机超过时限，会被系统释放到公海库。销售可以自己主动将临时库商机释放至公海。
私有库：销售人员有一个私有库，销售可以从公海、临时库中将商机转移至私有库，私有库也仅销售自己可见。私有库中的商机也有有效期限，时限比临时库更长。销售可以自己主动将私有库商机释放至公海。
沉寂库：若一些商机跟进多次无效果或者用户反感，质量差，系统会将其转移至沉寂库，不再可见。

功能模块介绍：

新增商机分配：每日新流入的商机会由系统分配给销售人员，新流入商机质量高，为保证公平，分配方式是每个销售轮流获得一条。
商销匹配：系统会将公海库中的部分商机主动分配给不同销售人员，每天仅分配一次，在销售上班前分配好，分配数量较少，每人几十条，并且一条商机只能被分配给一个销售，该过程在产品功能中被称作"商销匹配"。
一键申领：密歇根商机组销售人员可以在系统界面上从公海库中筛选商机，销售人员可以根据商机品类、来源等属性字段做筛选，每次可以筛选出几十条，全部跟进完之后才能进行下一次筛选，该功能被称作"一键申领"，即从系统中申领商机。这里本质上是一个搜索功能，系统基于Elasticsearch（ES）构建了一套商机搜索引擎。密歇根销售组也有一键申领功能，某个销售在跟进商机（商机组转过来的商机）过程中，也可以释放、绑定商机，释放的商机会被存入一个中间库，其他销售可以通过一键申领功能从中间库筛选商机。
转出商机分配：商机组形成的转出商机会由系统随机分配给销售组的某个销售，这里后续将切换为由机器学习模型来分配。

需要说明的是，商机组的销售人员只有临时库（超时时间24小时），没有私有库。商机组每天的工作是不断打电话，为了防止骚扰用户，CRM限制了一个商机在一天只允许打通一次，打通后销售即可很快判断出是否能转出，不能则可以直接释放回公海，销售没必要将这类商机放到自己的临时库或私有库，因为第二天又有大量新的商机需要处理。这里临时库的作用是存放当前没打通的商机，销售可以选择其他时间再拨打，但若24小时内没处理，自动会释放至公海。

电销模式下销售人员获取商机流程基本和密歇根模式下的商机组一致，如下图所示，不再赘述。

图电销模式下销售人员获取商机流程

为了便于大家理解，以上描述是对实际流程进行了精简，CRM实际逻辑会更加复杂，这些内容和本文核心目的无关，未做描述。

AI助力CRM：定义问题、确定优化目标

从CRM中销售人员获取商机的流程可以看出这是一个典型的信息分发问题，CRM作为分发引擎在商销匹配模块主动给销售人员推荐商机，在一键申领模块销售人员会主动从系统中搜索商机，我们可以利用机器学习和推荐技术来提高搜索和推荐的效果，以提高最终的成单转化率。

旧系统的缺陷：

在我们接手CRM智能工作之前，CRM系统中已经运行了一个机器学习模块——商机打分。商机打分模块构建了一个以成单率为目标的机器学习排序模型，每日凌晨商机打分模块会对公海库中的每条历史商机计算一个分值，即模型预估出的商机成单率。公海库中的历史商机会按照商机分值排序，在商销匹配模块商机会由一个规则逻辑按照分值从高到低依次分配给不同销售人员，剩余未被分配的商机会进入商机搜索引擎，当销售人员在一键申领场景筛选商机时，搜索引擎会按照商机分值排序返回商机列表，销售人员可以跟进这些商机，在跟进完所有商机后可以继续筛选。

上述方法存在优化目标不直接和未充分利用销售人员特征两个问题。首先，商机成单链路长，一个历史商机从某个销售人员第一次跟进到最终成单一般要经历数月，期间会经历数十次跟进，甚至流经多名销售人员（商机被释放回公海后会分配给其他销售人员），单次跟进和最终成单难以构成直接关联关系，而且成单周期长，模型效果难以快速评价，无法进行算法模型的敏捷迭代；成单正样本少，模型正负样本极度不均衡，难以发挥效果。除此之外，在商销匹配、一键申领模块中分配出的商机仅是按照静态商机分值排序，没有使用销售人员侧的特征信息，未实现个性化排序。尽管如此，商机打分模块还是在CRM系统中起到了关键作用，并奠定了一定数据、算法基础。

我们的方案：

我们不直接优化成单率，而是关注成单链路上的数据漏斗，优化链路上各中间环节指标。直销密歇根模式下各个环节业务关注的指标是：商机组拿到商机后，需要通过一通电话来判断商机是否可以转出，关注转出商机数量；销售组拿到商机组的转出商机后，关注首次跟进形成的60秒有效电话商机数，这也很容易理解，用户愿意和销售聊更久才更有可能成单；成单是终极指标。这里的数据漏斗是：转出数 -> 60秒有效通话商机数 -> 成单数，只要提升漏斗前面的数量，成单数也会提升。电销模式下，业务关注电销人员拿到商机后首次跟进形成的60秒有效电话商机数，成单是终极指标，数据漏斗是：60秒有效通话商机数 -> 成单数。

图密歇根模式下各环节的优化目标

机器学习模型适合优化最直接的目标。在密歇根模式下，可以在商机组的商销匹配、一键申领、新增商机分配模块上线算法模型，优化转出数；在销售组的转出商机分配、一键申领模块上线算法模型，优化60秒有效通话商机数。在电销模式下，可以在商销匹配、一键申领、新增商机分配模块上线算法模型，优化60秒有效通话商机数。

在CRM系统里，销售拿到一个商机列表后需要拨打跟进列表中的所有商机，用户接通后与其沟通，售卖58会员。我们可以借鉴推荐系统中用户的 "曝光 -> 点击 -> 转化" 行为路径，定义出销售人员的 "拨打商机 -> 接通商机 -> 形成转出商机"、"拨打商机 -> 接通商机 -> 形成60秒有效通话商机" 行为路径。在一个新闻推荐系统中用户是基于个人兴趣去点击新闻，若对新闻内容有更深的兴趣会在阅读完后评论、分享新闻。在我们的场景中，从商机被拨打到接通更多是取决于商机，例如商机联系人（用户）当前是否方便接电话、是否反感陌生电话、是否曾经被频繁拨打过、是否有购买会员的意愿等等，从接通到是否形成转化取决于销售个人话术经验、商机联系人的意愿等。这里的核心是对用户意愿度、销售个人经验的建模。

基于这样的定义，若要提高商机组转出商机数可以提升拨打转出率（转出商机数 / 拨打商机数）、提高60秒有效通话商机数可以提升拨打60秒有效通话商机率（60秒有效通话商机数 / 拨打商机数），这类比推荐系统中的曝光转化率（CTCVR）。此外，业务方还关心接通转出率（转出商机数 / 接通商机数）、接通60秒有效通话商机率（60秒有效通话商机数 / 接通商机数），即CVR，该指标反应了接通一个商机后形成转化的沟通成本，CVR越高成本越低，销售效率越高，工作信心也越大。这里CTCVR是主要指标，决定了最终业务结果，CVR是辅助指标，相关指标详细定义如下图。

图模型优化目标定义

技术实现

问题定义清楚后具体的技术实现就变得简单了，我们只需ABTest上线算法模型和原始逻辑做对比，持续优化算法效果即可。

我们可以看到商销匹配是系统主动推的一个过程，可以采用个性化推荐算法来实现，一键申领是销售主动搜的一个过程，可以采用个性化搜索排序算法来实现。

销售人员每天大部分时间是在一键申领场景工作，密歇根商机组的销售人员在该场景下跟进的商机数量占每天总跟进数的70%~80%，产生的转出商机数占每天所有转出商机的60%~70%，电销模式下也类似，优化一键申领场景能够更容易取得收益。因此，项目中我们首先从优化一键申领场景开始，这里大概介绍一下密歇根商机组和电销一键申领场景的技术实现。

原始逻辑是基于检索条件（由商机品类、来源等字段组成）从ES搜索引擎中搜索出满足条件的商机，并根据成单率分值从高到低返回 K 条商机给销售人员。

初期为了加快项目进度，我们直接在原始的搜索逻辑上加了一层机器学习排序模型，首先由搜索引擎召回出按成单率排序的M条商机，M要比K大，在系统性能允许的情况下越大越好，然后由一个排序模型来对这M条商机做精排，最终返回topK条给用户。

排序模型我们选择了XGBoost模型，优化目标为CTCVR，特征上使用了商机特征、销售特征、行为特征、电话语音文本内容特征等。我们最终是想优先提高CTCVR，其次再提高CVR，因此在离线模型实验中我们会关注CTCVR、CVR两个任务的AUC，这些指标的定义见前文第3节内容。通过不断优化，模型在线上ABTest期间取得了明显收益：

在密歇根商机组中CTCVR（拨打转出率）相对提升了 31.8%、CVR（接通转出率）相对提升了 13%。
在电销场景中CTCVR（拨打60秒有效通话商机率）相对提升了 62%、CVR（接通60秒有效通话商机率）相对提升了 41.2%。

目前，线上已100%流量切换至模型。这里需要注意的是，我们的场景和常见的搜索推荐场景不一样的地方是物品（商机）具有互斥性，一个商机由系统分发给了某个销售后就不能再分发给其他销售，这是为了防止多名销售同时跟进用户造成骚扰。

初期阶段的工作其实很简单，但可以看到机器学习模型发挥了巨大机制，效果提升明显。我们继续优化，升级了召回策略，增加了多路检索召回，这里以密歇根商机组一键申领场景为例做介绍，首先使用模型计算出商机的多个分值，除原始的拨打成单率外，还计算了拨打转出率、接通转出率、拨打30秒有效通话商机率（转出商机一般都满足30秒有效通话这个条件）、接通30秒有效通话商机率，然后这些分值在每天凌晨ES更新索引时写入索引，最终线上检索时，可以分别检索出按照这些分值排序的商机。我们也增加了基于FM模型、DNN双塔模型的向量召回，由于最终推出的商机要满足一键申领里销售的筛选条件，向量召回的商机需要经过一层过滤，一般过滤完后数量相对较少。我们选择部分城市ABTest上线了多路召回，上线后模型效果每日稳定提升，拨打转出率（CTCVR）相对提升了20%、接通转出率（CVR）相对提升了19%，目前多路召回在逐步扩量中。在排序模型上，近期我们在密歇根商机组一键申领场景上线了MMoE多目标模型，同时优化接通转出率（CVR）和拨打转出率（CTCVR），MMoE模型ABTest上线后相比XGBoost模型每日有稳定提升，拨打转出率（CTCVR）相对提升了11.9%、接通转出率（CVR）相对提升了10.8%。一键申领场景下个性化搜索排序系统的架构类似推荐系统，如下图所示，这里详细的模型优化细节在后续文章中再做介绍。

图密歇根商机组一键申领个性化搜索排序

这里需要注意的是ABTest实验的设计，由于销售人员（用户）数量有限且不同销售人员的经验有很大差别，我们不能根据用户来分流，只能采用随机分流的方式，以消除用户经验差异对效果对比的影响。当销售人员在一键申领场景下点击筛选按钮请求后端系统时，系统会将请求随机分发至算法模型或原始逻辑。另外，在销售作业场景下，由于影响因素多，相关指标在不同日期并不会稳定，在对比模型效果时，我们需要看当日ABTest的数据，不同日期前后对比基本无效。下图是线上真实的每日拨打转出率趋势图，可以看到不同日期波动很大。

总结和展望

从我们在一键申领场景取得明显收益可以看出定义机器学习模型优化目标的重要性，机器学习模型适合优化最直接的目标，并需要能快速获得反馈评价，这样才能持续优化。当前，我们主要优化了一键申领场景下的效果，未来将在其余各个模块上线算法模型，提升效果，同时我们也会关注成单数据，由于成单周期一般为2~3个月，当前由于上线时间短，在成单数据上还没看到稳定数据。此外，CRM产品层也会考虑引入推荐功能，当前商销匹配每天仅分配一次商机，不能起到决定性作用，而一键申领本质是一个搜索系统，当销售人员不清楚自己到底该搜索哪些品类的商机时，系统推荐的方式可能是更好的选择。往往一个信息分发系统同时会有搜索、推荐功能，可以由用户自由选择，最大化分发效率。

回到本文的标题《AI + CRM 提高企业的“绩”和“效”》上来，我把标题起得很大，是为了吸引大家的阅读，但本质上前面所讲的技术内容仅为个性化搜索排序，实现方式类似推荐系统，但取得了不错的收益。个人认为发展了数十年的搜索、推荐技术并不能算作AI，因为搜索、推荐系统几乎不需要人工介入，所有评价数据都可以自动获取得到，然而近几年AI浪潮的火热让大家把各类传统的机器学习系统都归类为AI。而基于语音、NLP、图像技术打造的各类感知类、认知类应用可以算作AI，这些应用都需要人工标注训练数据，机器去学习人的经验。

在CRM中我们也应用了语音质检、语音对话这些AI技术：

密歇根商机组销售人员可能会产生不合规的转出商机，我们需要对形成转出商机的电话做语音质检，这里可以使用语音识别技术将录音转译为文本，并使用NLP技术挖掘出语义标签，由机器来自动质检。除了密歇根转出商机质检外，我们还上线了销售高危行为质检，可参考《AI技术如何打造智能语音质检系统》。
销售和用户的沟通录音可以转译为文本，然后挖掘各类语义标签，形成通话摘要，提升销售工作效率。
密歇根商机组的销售人员的工作是通过拨打一通电话来判断商机是否可转出，工作很标准化，机器人在标准化流程中能发挥作用，这里可以使用智能外呼机器人来辅助销售外呼，当前该项工作正在开展中，待后续文章详细介绍。

未来，我们还将探索销售话术学习系统、话术陪练机器人的落地。

个人感想

本节纯为个人观点，从黄页商机智能分配项目中谈自己的两点看法：

保持开放协作的精神。"开放协作"是58企业文化价值观中的一条。本次项目由AI、CRM、黄页业务方三个团队共同完成，这样的项目组里大家必须保持开放协作的精神，为同一个目标而努力。首先本项目是对CRM历史旧逻辑的升级，CRM中相关的规则逻辑代码需要升级去请求AI侧提供的排序服务来完成，这是AI在植入CRM，CRM团队有一个开放的心态来和AI团队合作。其次，商机在CRM展示后，销售在后续具体跟进中所有的数据埋点需要CRM团队去开发，两个团队需要紧密配合。再者，AI团队迭代算法模型产生的阶段性效果需要及时传递。AI和CRM尽管是两个团队，但在项目中需要当做一个团队，相互信任、协同合作。当然，这里最重要的黄页业务需求方，相信AI和CRM的技术实力，支持对CRM做技术升级，愿意付出时间去配合落地。本次项目里，项目组成员很好的践行了开放协作，最终取得了不错的效果，感谢项目组里的每位成员。
坚持长期主义，积累总会有爆发点。这是去年在参加一门培训课程时，一位大咖所说的话，在本次项目中深有体会。本次项目我们使用搜索个性化排序（类似推荐排序）技术解决了问题，对于项目组同学来说是一个新项目，而对于我个人来说这是一件很熟悉的事情。本人自12年参加工作至2019年3月一直从事推荐系统方面的研发，19年3月团队架构调整，主要从事NLP、语音方面的工作。个人对推荐仍保持着较浓厚的兴趣，一直坚持跟进推荐领域的进展，这让我再次开展推荐相关工作得心应手。我们做技术的需要坚持长期主义，持续沉淀，我们积累的技术经验在未来某个时间点可能就会有一个爆发点。

作者简介

詹坤林，58同城AI Lab负责人、算法资深架构师、技术委员会AI分会主席，目前主要负责AI相关产品规划和技术研发，致力于推动AI技术在58同城的落地，打造AI中台能力，以提高前台业务人效、收入和用户体验。目前负责的主要产品包括智能客服、语音机器人、语音分析平台、语音识别、智能写稿、AI算法平台、CRM商机智能分配系统等。曾任腾讯高级工程师，从事推荐算法研发。硕士毕业于中国科学院大学。

部门简介

58同城AI Lab隶属TEG技术工程平台群，成立于2018年5月，部门前身为智能推荐部，目前部门规模为60~70人，包括产品经理、后端、数据、算法开发人员。

AI Lab旨在推动AI技术在58同城的落地，打造AI中台能力，以提高前台业务人效、收入和用户体验。部门介绍，具体见：58同城AI Lab部门介绍持续招聘，具体见：58同城AI Lab招聘产品经理、开发工程师

58同城AI Lab产品能力介绍

原创 58AILab 58AILab 2021-11-18 12:36

58同城AI Lab隶属于TEG技术工程平台群，成立于2018年5月21日，旨在推动AI技术在58同城的落地，打造AI中台能力，以提高前台业务人效、收入和用户体验。AI Lab目前负责的产品包括WPAI机器学习平台、灵犀智能语音语义平台、MAI智能营销引擎、智能写稿，未来将持续加速创新，拓展AI应用。

WPAI机器学习平台

AI正在驱动行业变革，为加速58同城AI应用的落地，我们自2017年9月开始构建机器学习平台WPAI（Wuba Platform of AI），支持机器学习算法一站式开发，以提高AI工程师的研发效率。

WPAI包括基础计算平台、算法应用平台两部分：

基础计算平台集中管理GPU、CPU、NPU硬件资源，集成TensorFlow、PyTorch、Caffe、PaddlePaddle等机器学习框架，支持机器学习模型离线训练和在线推理，在线推理服务支持自动扩缩容（弹性推理服务），离线训练作业和在线推理服务支持混合部署（离在线混布）。开发者可以向平台申请离线、在线资源，使用机器学习框架开发模型，打造自己的机器学习服务。
为了进一步提高AI工程效率，我们在基础计算平台之上继续打造了算法应用平台，包括NLP算法平台WubaNLP、图像算法平台凤凰（由58技术委员会AI分会基于WPAI基础计算平台协同共建）、排序学习平台（应用于搜索、推荐、广告系统）等。算法应用平台直接集成了相应领域下的常用模型，以Web的方式提供应用，开发者只需要在Web界面做相应配置即可完成训练和推理，大大提高开发效率。
、AB实验平台日晷，以进一步提高AI工程效率。

WPAI机器学习平台是AI应用的底座，我们基于WPAI打造了灵犀智能语音语义平台、MAI智能营销引擎、智能写稿。

WPAI目前已发展成为58同城各AI团队日常算法研发工具，支撑了58同城在图像、NLP、语音、搜索、推荐、广告、风控领域内的各类AI应用。相关技术介绍见文章：

灵犀智能语音语义平台

近年来，我们一直聚焦在对话式AI（Conversational AI）领域，自2017年9月研发智能客服开始，我们先后打造了智能外呼、语音质检、智能呼入、语音识别、语音合成等产品和能力。对话式AI的核心是智能语音语义技术，包括语音识别、语义理解、语音合成。我们对这些产品能力进行归拢，统一升级为"灵犀"智能语音语义平台。

灵犀智能语音语义平台由底层基础服务平台和上层AI应用平台组成：

基础服务平台包括语音处理引擎、NLP算法平台（WubaNLP）。语音处理引擎的核心是我们基于58业务场景下海量语音数据自主研发的语音识别引擎，效果优于第三方引擎，并支持离线和实时转写功能。NLP算法平台可以实现对文本的语义理解，支持文本分类、语义匹配、序列标注、文本生成等各类NLP算法模型，支持数据标注、模型训练和模型推理一站式NLP算法研发。
在底层基础服务平台之上我们构建了两大AI应用平台——人机对话平台和对话分析平台，均支持对语音、文本两种媒介的处理。人机对话平台实现了人与机器之间的语音对话、文本对话，支持智能外呼、智能呼入。对话分析平台可以挖掘分析人与人之间的语音对话内容、文本对话内容，提取关键语义信息。

我们基于灵犀平台打造了众多AI应用，可以分为智能客服、智能外呼、智能呼入、智能质检、用户画像几大类，在业务场景下的典型代表应用有：

智能客服类（文本对话）：帮帮智能客服、黄页商家智能聊天助手。
智能外呼类（语音对话）：黄页销售智能外呼助手、通知助手。
智能呼入类（语音对话）：招聘面试机器人、58到家客服接电助手。
智能质检类（对话分析）：销售客服语音质检系统、巧房经纪人通话质检。
用户画像类（对话分析）：房产语音画像、招聘语音画像。

灵犀智能语音语义平台获得了2021大数据科技传播奖：

MAI智能营销引擎

58同城有大量的销售人员，销售人员的职责是向客户售卖会员，并维系客户关系以促进会员续费、充值等，从而提高公司收入，销售人员会使用CRM系统（客户关系管理系统）进行作业。我们基于大数据、机器学习、个性化推荐等技术打造了MAI智能营销引擎（MAI，Marketing AI，发音"mai"，有买卖之意），应用于CRM销售作业全流程，在营销场景下发挥价值，可以有效提高销售人员的人效和业绩。

我们基于MAI智能营销引擎打造了商机智能分配系统、客户续费模型、客户续充模型、线索打分模型等应用。

商机智能分配系统。销售人员日常需要从CRM海量商机库中筛选出商机（潜在客户信息）并进行持续跟进，售卖会员套餐，可以利用MAI智能营销引擎从海量商机库中给销售人员推荐适合其跟进的商机，类似"千人千面"的方式提高商机转化率。
客户续费模型。当客户（会员用户）快到期，销售人员会联系客户，让其续费，可以利用MAI智能营销引擎向销售人员推荐一批续费概率高的客户，以提高续费率。
客户续充模型。当客户账户额度快消耗完，销售人员会联系客户，让其继续充值，可以利用MAI智能营销引擎向销售人员推荐一批充值概率高的客户，以提高续充率。
线索打分。在某些场景，销售人员会直接跟进线索，可以利用MAI智能营销引擎对线索进行打分，提高线索转化率。

特征存储及计算在CRM商机智能分配中的实践

周磊

2021-08-01 19:25

15人已读

特征存储及计算在CRM商机智能分配中的实践

作者：周磊，58同城 AI Lab 大数据开发工程师

导读：本文介绍的是在CRM智能推荐场景中，所用到的机器学习和推荐技术的模型训练及线上预测的特征数据推送部分，我们应用此套特征推送流程而上线的模型多达几十种，获得了可观的收益。目前特征自动化推送广泛应用于黄页、招聘、创新、转转等业务场景中。

本文收益：了解58CRM商机智能分配场景中的个性化推荐/搜索所采用的特征来源，即特征存储、计算及后续处理方式。

内容如下：

一. 背景介绍

二. 数据流程

三. 特征仓库

四. 特征计算

五. 特征聚合

六. 总结规划

七. 部门简介

【一. 背景介绍】

CRM系统是服务于我们58销售团队的一个重要系统。面对庞大的历史商机库，我们AI Lab开展了商机智能分配项目。该项目旨在将机器学习和推荐技术应用于CRM，为每个销售人员分配适合其跟进的商机，优化成单转化，以提高销售团队业绩，进而提升业务线收入。

58黄页(本地生活)直销业务线采用的是密歇根营销模式。具体是将销售团队分为商机组和销售组，商机组的职能是商机意向初筛，过滤出有成单意向的商机后转出到销售组的转出商机库，销售组的职能是从转出商机库中进行跟进最终成单。两个团队的销售跟进单位都是商机，即对58潜在会员抽象出来的实体。项目详细介绍请参考公众号文章《AI+CRM提高企业的绩与效》。

我们从相应的商机库中挖掘出不同维度的特征，进行计算及转换后输出到模型中进行训练和预测。本文介绍的就是服务于CRM系统中的个性化推荐/搜索排序等相关模型的特征数据推送部分。

上图是我们AI接入CRM系统的架构图。应用层中的一键申领和商销匹配是密歇根模式引入CRM系统的两个场景，通过引入不同的场景，可以切分成单链路，让销售的目标更加明确，同时我们可以接入更多的AI模型去提升销售的工作效率。一键申领场景即销售主动从商机库中拉取商机，商销匹配场景即系统主动给销售分配到最适合该销售的商机。搜索服务层就是我们场景相关的模型，这里后续会有其他文章进行介绍。数据计算层中的特征计算及处理，和基础数据层中的业务核心数据建设即特征仓库，是我们今天分享的重点。场景的多元化与模型的丰富性加大了我们特征推送的难度，下面介绍一下特征推送自动化流程的具体实践。

【二. 数据流程】

需求分析：为了能满足下游模型迭代的特征需求，并且快速推送出相应特征数据。基于此，我们梳理了数据流程，大体可划分为以下几个模块。

正负样本标识会根据业务线和场景的变化而变化，即和目标提升业务指标高度相关，这里很难做到抽象出公用框架。而对于特征仓库、特征计算和特征聚合，可以做出通用流程，节省人力和效率。最后的预测集和训练集可以基于前两步的数据升级进行通用化。所以这里核心是特征存储和特征计算及其处理。下文将从特征仓库、特征计算、特征聚合三方面叙述自动化特征数据推送的业务点和技术点。

【三. 特征仓库】

特征仓库可以类比于数据仓库，区别是数仓是为了建设各项数据指标服务，而特征仓库是为了建设基础特征服务。经过探索和积累，我们主要基于HBase的特征仓库业务架构如下：

上述架构中的部分表来源于数仓，基于底层数据可以开展各类基础数据计算统计。整体也参考了经典的数仓分层架构，实用性优点这里不予介绍。值得一提的是，由于hive不满足我们的特征仓库的建设，所以hbase的选型在我们的场景里至关重要。

需求分析：

由于特征库的要求是表里需要存放至少一年半的特征数据并每日更新当日特征数据，有数据量大及缓慢变化的特性，后续存储也是用了拉链表的思想，可以大幅减少存储内存占用。
随着特征更新，需要对特征进行版本管理，如在帖子维度中，我们场景存放的是最近三年下的最近三万条帖子。
特征存储要具有灵活性和扩展性，因为算法迭代经常需要尝试不同的特征组合，可能需要新增特征维度，并对特征进行选择及补充相应历史数据。
一方面维度分支多，需要聚合成主题大宽表。另一方面，我们部分主题接入了实时，需要对离线和实时融合做兼容。

解决方案：上述分析具体可以概括为三个特性：存储性、扩展性及更新融合性。相应解决办法如下：

作为一种可以高并发和随机读写的K-V数据库，Qualifier-Value可以很好的存储结构化的特征。这里特征仓库ETL的过程应用了很多HBase的特性。

比如对于DWD层的话务表存放的一条数据的例子是：RowKey为电话散列后的电话ID，其中的一对K-V明细数据为：call_01_20210508101358_108：json_feature。相应含义是该电话在01业务线下于2021-05-08 10:13:58秒时接通了108秒，json_value可以存放具体的明细字段。这样当离线数据以同样的逻辑写入(二者时间戳设置相同，可以为拨打时间等)，可以直接覆盖该条明细数据，达到实时和离线的融合。然后下游读取时设置TimeStamp为日期，就可以过滤出天维度的特征，然后解析相应json得到的特征经过加工就可以导入到MID层中天维度的HBase特征表中，方便后续进行天粒度的特征计算。同时，结合HBase TTL和Cell多版本特性可以达到特征的自动化管理。

随着维度和新特征的不断增加，基于此种特征仓库建设可以覆盖现有后续几十种的模型特征需求。

【四. 特征计算】

本场景的特征计算是在内存中进行大量的离线计算，主要指上述特征仓库中的MID层->APP层的计算，即从维度大宽表中的海量数据及基础特征中，过滤出指定的样本集和特征集来缩减计算量，再采用特征字典+特征矩阵(下文会具体介绍)完成高效计算，输出为深度学习可以直接使用的特征，或者输出后进行特征聚合再输出到机器学习使用的特征。具体内容及实现如下：

计算逻辑：基于商机、电话、用户和销售四个粒度，对其进行基础特征+产品线+计算函数+时间窗进行组合衍生计算，最后输出特征。

上图中输出特征的含义为某用户在01业务线下7天内登录总次数为15次。

其中，login_01是基础特征，01就是业务线，这里把业务线也作为一个维度，是因为取了不同业务线的特征；然后，SUM是指该特征的计算函数是求和，我们特征衍生计算的计算函数包含了十多种类型，分别是：COUNT(),SUM(),MAX(),MIN(),MAXPARTITION(),MEAN(),MEDIAN(),STD(),RANGE(),MODE()等，这里具体函数含义即为其中文含义，当然对于每一种基础指标，我们会采取其适合的统计方式；最后，时间窗可以自由定义且窗口不交叉，比如时间窗可以是3,7,15,30,90,180。

业务痛点：由于承接的业务线多，每条业务线又有不同的场景，这里的目标是：打造一套剥离出业务逻辑又适用于各种场景的高效特征计算架构。具体梳理来看，主要需要考虑到以下六个问题：

可以抽象出三类问题：

特征管理：主要包含图中左半部分的第1,5,6三个问题。目前我们线上有几十个模型，部分模型采用的特征不同，这就对统一的特征计算架构提出兼容不同模型特征的要求，且要提供模型特征选择种类及相应说明给算法、产品及负责人。
计算高效：主要是指图中第2个问题。从数据推送流程中可以看到，除了负责离线提供训练集，每日凌晨还需要推送全量数据的预测集到各业务线，以供相关模型进行预测打分，之后推送给CRM端。由于我们的特征的来源有部分是基础数仓，且数仓计算耗时较长，所以留给特征计算的时间很有限，必须高效的完成计算且推送数据出去。
数据升级：主要包含图中第3,4个问题。真实的线上运行时，一方面，算法迭代需求会涉及到尝试新老特征组合效果，以及同一场景下不同模型间也会有特征调整的问题；另一方面，对于后续输出特征要兼容到机器学习及相关推荐模型，还需要对特征进行进一步处理加工。

对于上述三类问题，解决方案分别是：特征字典，特征矩阵，聚合存储。其中，聚合存储为数据升级后的结果，放在下部分介绍。先介绍这里的架构设计及其他两项。

架构设计：基于特征仓库设计的特征计算的架构如下，设计为HBase+Spark技术实现，其中也用到了许多HBase的生态组件。

基础特征和衍生特征分别对应的特征仓库的MID层，APP层，中间层引入特征字典+特征矩阵的概念实现高效的计算方式。具体流程大致为：每日凌晨数据运行时，每个维度起一个计算任务进行并行计算。

首先，每个任务内先过滤出相应产品线的不同维度的全量ID，通过对HBase的一个列族打上目标计算群体的标签，然后根据标签用Filter Api过滤出样本集；然后，根据TimeStamp读取初所需要计算的时间跨度内的特征，并读取特征字典表来告诉程序需要计算的具体特征；最后，在内存中每个用户都转化为一个特征矩阵(只存储有效特征)，根据计算类型并发计算各个ID的特征，写入衍生特征层。

特征字典：特征字典可类比维度字典表，存放的是特征仓库MID层各个宽表中的基础特征。为了解决以上特征管理的问题，这里我们设计了具体字段，部分字段展示如下：

dim存放的是基础特征的维度，id是基础特征对应的特征编码，name是特征名称，explain是对应的中文含义，cal_sort是具体的计算类型，times是衍生逻辑里的时间窗，data_src是基础特征对应的数据源HBase表。

特征矩阵：在计算内存中，每个ID都会转化为一个特征矩阵，之后的计算函数会全部基于这个特征矩阵进行计算。其中，矩阵的行定义为用户维度的特征个数，列定义为时间窗跨度。当计算时，通过查询特征字典表告诉程序所需要计算的特征及类型，然后在特征矩阵中找到相应特征具体的坐标：X(特征ID)和Y(时间窗)的非0有效特征值。最后传入有效值的坐标进行计算。这样可以极大程度上减少存储、简化计算，提高计算效率。具体计算效果如下：

表格中阴影部分就是特征矩阵，因为用户的特征都是稀疏的，所以利用稀疏矩阵的存储方式，只存储有效数据。假设A用户是一个100*365的稀疏矩阵，则对应转换示意图如下：

每个用户在内存中转换为二维数组之后，然后根据计算类型和时间窗就可以并发计算出衍生特征。

下面是结合上文的特征仓库从DWD->特征计算->APP层全局展示的一个例子。如用户A有三个分支的行为，先聚合到MID层日维度HBase，这里login_01_20210502的设计方式可以很好的管理特征版本，并利用HBase根据RowKey进行聚合成一行，最后在计算内存中形成特征矩阵，衍生出结果保存到APP层。

计算优势：

新增特征时只需要更改字典表即可，可以实现特征计算的代码0修改，维护起来也简单。
特征个数提高为原来的5倍，通过不同维度直接衍生，统计出相应组合效果的特征。
通过Filter过滤器减少数据集计算量，不同维度并行计算以及基于特征矩阵的并发计算，可以极大的提高计算效率。
全计算任务无具体业务逻辑，可以提升复用至多个产品线。

实际上这里的特征数据可以输入深度学习进行模型训练，但是考虑到兼容机器学习(Libsvm数据格式)，后续还需要进行特征聚合，并且对数据进行升级，兼容二者。

【五. 聚合存储】

聚合存储分为以下两方面介绍：特征聚合和升级存储。

特征聚合：基于特征计算的逻辑聚合，也就是根据产品线、计算函数、时间窗的组合进行聚合。一个商机下可能关联多个用户ID和电话ID，根据关联的ID把同种组合特征按照该特征的相应计算逻辑(求和，最大值等)聚合到一条商机下。

维度转换是根据不同场景的业务需求时常变更的，这里复用了上文的特征计算的衍生逻辑，只需要根据相应的特征进行Groupbykey指定维度就能快速聚合，输出最终特征。

升级存储：兼容下游机器学习和推荐技术的众多模型时，不同模型使用的特征会有不同，所以数据存储及如何对接模型需要做一个统一的管理。相关设计如下：

这里的方案是每个业务线计算出全量的特征后，采用Libsvm的方式进行数据存储，下一步相关模型会进行训练而选择出需要使用的高收益特征列表并保存在Hdfs上，然后根据不同模型选择的特征子集进行映射输出到预测集。以这种维护一套总特征的方式来兼容机器学习和深度学习的不同模型，相比Json存储可以降低约70%的存储容量，并且很好的管理不同模型需要的特征。

【六. 总结规划】

当前，我们已经打造出一套相对自动化特征推送体系，覆盖了下游现有AI模型的基本特征需求，推动了个性化搜索/推荐技术应用于CRM系统，为58升级收入增长引擎贡献一份力量。未来，我们会持续优化当前AI模型的数据及效果，加入基于NLP生成的文本特征，再引入实时特征数据，用更多数据思维成果来推动AI赋能落地及升级。

以上是关于特征存储及计算在CRM商机智能分配中的实践 AI + CRM 提高企业的 "绩" 和 "效"的主要内容，如果未能解决你的问题，请参考以下文章

密码学与隐私计算在人工智能行业中的实践：学习