楼主: yukai08008
1074 0

[网帖精选] 复杂逻辑控制的实例 [推广有奖]

  • 2关注
  • 17粉丝

讲师

2%

还不是VIP/贵宾

-

威望
0
论坛币
2176 个
通用积分
3.0600
学术水平
10 点
热心指数
7 点
信用等级
7 点
经验
5915 点
帖子
120
精华
0
在线时间
556 小时
注册时间
2012-11-28
最后登录
2022-4-11

+2 论坛币
k人 参与回答

经管之家送您一份

应届毕业生专属福利!

求职就业群
赵安豆老师微信:zhaoandou666

经管之家联合CDA

送您一个全额奖学金名额~ !

感谢您参与论坛问题回答

经管之家送您两个论坛币!

+2 论坛币

上文介绍了复杂逻辑控制(ComplicatedLogic Control,CLC)的概念,这里以线上信贷审批场景为例,通过CLC实现针对性的审批控制。

       线上信贷审批的业务流程包括进件、审批、放款三大步骤,这里主要利用CLC实现较为复杂的审批要求。审批需要对进件进行判断,得出接受、拒绝或者调整的审批结论;进一步地,在审批过程中还可以提高进件的批复条件,例如提高15%的首付可以批复贷款。

表1 CLC框架设计

Table1 Framework design of CLC

  

逻辑块

  

子逻辑快

功能

内容

R0

R0.1

客户画像

聚类算法

R1

R1.1

基本信息核查

身份证三要素、银行卡三要素

R1.2

名单类核查

黑名单、涉诉、失信

R1.3

策略性检查

指定地区拒绝

R2

R2.1

大数据信息筛选

多次、多头借贷,手机入网时长

R2.2

机器学习筛查

信用评分、欺诈模式识别

R2.3

营销方案匹配

产品推荐或调整审批条件

R3

R3.1

汇总的规则

对规则标签进行统计的规则

R3.2

推过规则

根据公司策略决定促销的规则

R3.3

拉回规则

对推过规则的补充

R4

R4.1

策略控制

决定是否切换策略

R4.2

全局控制

宏观数据统计监控及控制

表1是一个可用于实际业务的CLC框架设计。首先由R0对数据库中的客户进行聚类算法,根据客户的特征将客户分为不同的群体,这部分工作需要不定期的进行迭代,由数据分析人员确认聚类结果的合理性。

R1是强规则集,也是最简单的规则集,通常直接产生接受/拒绝的审批结论。

从实际的业务上看,触发这类规则的数据通常来自不同的数据源(数据商),可能由不同的IT人员负责,因此可以进一步把R1逻辑块分成三个子逻辑块。R1.1进行基本信息核查,一般会要求客户拍照上传身份证、银行卡等信息,系统调用OCR接口将数据上传到公安系统、银行系统进行身份验证,确认申请人的真实身份。R1.2进行信用核查,排除信用瑕疵的用户。目前有较多的数据商都提供了黑名单查询,通常的来源是其他平台上报的申请人失信信息;此外还有法院公布的涉诉和失信信息,都可视为申请人的信用瑕疵,应该设立规则予以限制和拒绝。R1.3则是公司根据业务的特性设置的特殊判断规则。例如某地区长期存在诈骗集团,业务部门希望排除这个地区的申请。

       R2是弱规则集,存在许多需要量化调整的规则,更进一步地,R2还可以应用机器学习算法进行信用评级、反欺诈以及个性化的营销推荐。例如R2.1中设置了多头借贷、多次借贷和手机在网时长(多短拒绝)的规则,这些规则更多地起到了反欺诈的作用。在用户允许访问社交信息的情况下,R2.1还可以设置许多规则验证用户身份的(社交)真实性和稳定性等关键信息。R2.2则使用了更多的“弱变量”进行信用评分和欺诈模式识别。弱变量是指能够提供一些关于用户信用的信息,但是又不足以做出审批判断的信息,例如年龄,职业等。但是许多的弱变量综合在一起通常可以揭示用户的贷款意愿、还款能力、还款习惯等信息。因此在这一步可以使用信用评分模型建立用户的信用评级,也可以应用模式识别的算法判断用户的欺诈倾向。从某种程度上,这些模型产生的结果可以视为某种特别复杂的规则。如果对应的信贷产品允许定制化,那么在R2.3中可以进一步设置更多产品推荐和审批条件调整的规则。在R2.2中产生的信用评级可以作为一个筛选条件,为客户推荐不同的产品,例如为信用较好的客户提供较低的利率。

       R3是关于规则的规则集,在这里实现CLC的简单应用。在R3.1中需要先对之前执行的规则进行汇总,以汇总的结果指定规则。例如某个申请触发了5个信用类规则的调整(弱规则,并没有直接拒绝),可以在这里设定规则拒绝此类的申请。这种类型规则符合审批人员的实际操作需求,但是在过去规则没有区分逻辑块和标签,应用起来比较困难。R3.2的规则会将一些有瑕疵的申请的审批结果修改为通过。有时公司为了开拓某些地区或者某些渠道会对审批的通过率有所要求,甚至有可能把原本拒绝的申请也改为通过,可以称之为规则覆盖。规则覆盖的种类通常非常多,变化非常快,而且有时会存在漏洞,这对规则的管理提出很大的挑战,因此在R3.3中,一般需要增加对应R3.2的拉回规则,作为其补充。在R3.3中还可以根据规则的优先级设置统一的拉回规则,例如如果申请人匹配到公安的在逃通缉名单,强制拉回(无论之前申请处于何种状态)。总之,R3中增加了关于规则的规则,利用了规则的汇总信息进行控制,另外对应业务的覆盖规则要求(推过)和拉回(反对推过)这类看起来有些矛盾的审批需求也进行了支持。

       R4负责策略调整,属于更深层次的CLC。R4.1对于本次审批的结果进行评估,可以实时切换另一套策略(规则集)重新判断达到更好的结果。例如申请人在交互过程中信息的录入间隔非常短,有可能是使用程序填报申请的,此时R4.1将策略切换为针对人机识别的策略,例如要求用户做活体识别等。最后在R4.2还设置了宏观的数据监控规则。例如某渠道的申报量明显高于其历史值,或者明显高于市场平均值,则会触发针对渠道的审批控制规则,使该渠道申请转向人工审批并发出警报。

       使用CLC可能会使得自动审批的时间稍长,但能够带来三方面的好处。首先是数据成本节约。CLC是按照子逻辑块为单元顺序执行的,如果在某个子逻辑块被拒绝,后续的逻辑块可以不必向数据商请求数据。其次,审批结果清晰。对于某次申请,很快可以知道是由哪个子逻辑块做出的审批决定,而每个子逻辑块的规则虽然不同,但起到的逻辑作用是确定的,方便审批人员快速理解结果。最后,CLC可以方便地和各种机器学习模型(R2)和人工智能算法(R4)融合,这会极大的提高效率,并使得管理庞大而复杂的规则成为可能。

引自:

https://mp.weixin.qq.com/s__biz=MzI4MTAwMTY2MA==&mid=2247484040&idx=2&sn=d970919c3f9cbc9bef9f35e8f0bf2da0&chksm=ebaea95bdcd9204dd177c26a6f221559e7af74594fe0adbe8bf8848de6f56f075d5cca8c927f&mpshare=1&scene=1&srcid=0702sjAgP6ye25lsHGyyMGkH&pass_ticket=E%2BFTf%2BWVLRYr2YjQUPH%2BysYD8q51r7nr2JBOmj7pk6jxIFyZuvE7fqg6%2Fe%2BWzLMJ#rd


二维码

扫码加我 拉你入群

请注明:姓名-公司-职位

以便审核进群资格,未注明则拒绝


您需要登录后才可以回帖 登录 | 我要注册

本版微信群
加好友,备注cda
拉您进交流群

京ICP备16021002-2号 京B2-20170662号 京公网安备 11010802022788号 论坛法律顾问:王进律师 知识产权保护声明   免责及隐私声明

GMT+8, 2024-4-26 10:54