VOLVO
作者VOLVO联盟成员·2018-12-14 15:53
项目经理·省农信社

关于知识图谱在农信社风控领域的应用普遍关心的几个问题

字数 4174阅读 5052评论 0赞 5

一方面随着近年来通信技术的不断发展,黑产大行其道,银行业外部监管压力日益增加,内部风控要求也不断加强。另一方面,银行账务交易数据呈现爆发式的增长,这对数据的处理和分析能力提出了更高的要求。在这种新形势下,要求银行必须积极探索和使用新的理论技术解决新问题。

在金融交易越来越便利的背景下,仅从某个客户、某个账号或者某笔交易本身很难发现问题,必须对客户的关联人及其资金交易进行统一分析。但传统的关系型数据库在进行关系分析或资金流追踪时,受限于其设计模式,模型的开发难度和运行效率都较差。在涉及2度以上的关系分析时,难以在合理的时间内给出结果。导致大量潜在问题没有被发掘出来,给银行的资金安全和日常经营带来了较大的风险。

知识图谱是现实世界的个体和个体间关系的真实反映,提供了从“关系”的角度去分析问题的能力。将知识图谱理论、图挖掘算法、图数据库技术应用于信贷风控领域,能够很好的解决已有分析手段效率低下的问题,极大提升银行贷前、贷中、贷后的风险防控水平。常见的应用场景有担保圈分析、受托支付排查、内外利益输送排查、冒名贷款识别等。

为了帮助大家了解如何在风控领域使用知识图谱,我撰写了一篇最佳实践文章《知识图谱在农信社风控领域的应用》,并作为线上答疑活动“知识图谱在农信社风控领域的应用线上答疑”答疑嘉宾为大家解答了一些疑惑。活动结束后,我把大家提的问题以及答案梳理成本篇文章,供大家参考。

问题:知识图谱与智能客服如何对接?
解答:
我理解主要是通过api接口,在接入的同时系统自动调出客户当前的资产负债状况,最近的交易明细,购买产品的状况。在提问的时候,通过nlp系统解析问题中的关键字,识别询问的实体、关系等,找到关联的问题,引导客户按照提问已有的问题。使用知识图谱的好处在于,可以快速的查询出客户周边的所有数据。如果使用传统关系型数据库,则需要按照业务种类,逐个表进行查询,分模块展示。在图谱中则可以一起展示出来,因为是从客户出发按照关联关系进行查询的,并且可以用一张图进行直观的展示。

问题:为满足关键特性系统的架构或组件选择是怎样的?(主要针对hadoop架构)
解答:
1.可视化需要开发一个专门的知识图谱展示界面,将知识图谱中的实体、关系属性等以美观已操作的方式展示出来,因为颜值即正义。可以借用当前比较流行的bootstrap等前端开发语言。
2.为满足快速查询,可以将部分索引关键字放在索引es中,索引命中后在使用key去titian中查询。
3.多种服务方式,需要从设计时就进行考虑,至少满足三种api、可视化界面、批量文件。批量文件主要从hive中进行导出,而api接口则需要开发一个服务层,将所有图数据库的命令行操作转换为对应的api接口,轻量级的开发一个java服务放在tomcat中,有条件的可以使用微服务框架。

问题:知识图谱系统的关键特性有哪些?
解答:
1.当然是可视化展示,知识图谱的魅力之一就是让人直观的看到多实体之间的关系,能用图标示的就不要哔哔
2.多种服务提供方式,有些服务使用方,不需要图,那么可能通过api或者批量文件的方式比较合适。所以从系统建设角度来看,最好能提供多样的服务对接方式,满足前端服务使用方的不同需要,发挥系统价值,是值得考虑的地方。
3.查询速度,在用户进行图操作,例如实体查询、关系推演扩展时,系统响应时间应该较低,避免大并发情况下用户体验的降低。
数据建模、批量时间相对来说,外界感知不到,因此不那么重要。

问题:知识图谱应用时会面临哪些主要的困难,如何解决?
解答:
主要是确认需求,一方面是适不适合用知识图谱这个工具,另一方面做好与其他系统的对接工作,如何能将知识图谱这个服务以简便快捷的方式输出给其他系统。前者可以和多方面行内外专家交流,后者主要还是要与业务部门进行沟通,确认业务部门的期望,技术实现大多时候不是难点,难的是如何满足欲壑难填的需求。

问题:图形数据库应该怎么选型?选的时候需要考虑哪些问题?
解答:
从系统自身考虑的话,包括高可靠性,读写效率、扩展性,与其他系统相同。
除此之外,还应该从整体规划和这个系统所处的位置进行考虑,为了满足整体规划,牺牲一些性能或者成本也是必要的。比如为了避免海量数据的多系统存储分析,就选用了以hadoop为基础的图数据库,这样所有的数据只需一份,可以供平台上的多个子系统进行使用。

问题:部署时需要满足怎样的性能要求,qps或tps?如果建设面向外部客户的大规模知识图谱,有哪些可以优化的方向?
解答:
性能的需求应该是与业务场景强相关的,如果是面向外部客户那就要考虑扩容节点提升整体性能,明细数据可以从hbase迁移到es中,加快查询速度,限制部分查询内容或者只能查看经过分析的子图。
对于行内系统,从数据安全角度来看,只有少部分人能看到所有数据,绝大多数人只能看到部分数据,而且应该是具有特定业务含义的数据,比如某个预警模型的结果。在这种情况下,权限范围内的数据量就很小了,那么在查询的过程中,效率也会相应提升,不会全表扫描。

问题:有没有合适的企业级的分布式知识图谱技术架构?
解答:
横向涉猎不多,答错勿怪。
titian就是分布式的,因为它是基于hbase的。
Neo4j 好像就不支持,不像hbase这么简单就可以进行扩展。

问题:知识图谱存储会不会引起数据膨胀?
解答:
图数据库本身不会,但是知识图谱这个系统会,一份数据至少存在于hive加工区和hbase查询区,还有少量的elasticsearch索引区。

问题:有没有业务场景是只能用知识图谱实现的?而其他技术方法无法实现?
解答:
从技术角度考虑,应该没有,有的是效率孰高孰低、开发成本孰高孰低。

问题:知识图谱系统的建设核心是什么?该如何选型?
解答:
建设核心是图数据的存储和分析方法。不同的核心,外围使用的方法也不同。
以titan为例,它是集成在hadoop上的。数据的分析加工主要在使用sparksql和graphx,结果会存放在titan中,数量较多的明细流水会放在hbase中,常用的查询关键字,姓名、手机号码等会放在elasticsearch中,三者通过key相互关联。
如果换一种图数据库,比如neo4j,整个外围都会跟着调整。所以图数据库的选型不能进场图数据本身考虑,而应该结合整体规划,建设成本,多系统间的关联关系层面进行统筹考虑,甚至可能会为了大局牺牲一些效率。

问题:脏数据的处理机制是什么?
解答:
知识图谱作为下游系统其实没有好的办法处理脏数据,基本上有两种策略:
第一:确定一个优先级,某个属性以哪个系统为准,当两个系统不一致时,不管对错永远以某个系统为准。
第二:前一种方法不适用的,就将这些数据打入“冷宫”,放到一张表里,定期拿出来,找原系统进行数据修正,这是一个比较漫长的过程。
不过好在,80%以上的数据是正常的,脏数据多数由于客户长期未发生业务,渠道无法强制客户更新数据。

问题:知识图谱适用场景有哪些?
解答:
主要涉及关系分析的场景,利用账户、自然人或者资金交易形成的关系来判定结果是否可用时,比如担保圈、分析实际控制人、实际受益人、识别冒名贷款。而且通常,数据分析的深度在3度到5度,才能体现出优势。
分析深度小于3度,与传统关系型数据库没有太大差别,大于5度有可能引入较多的噪音数据。当然不排除某些场景下分析5度以上数据的可能性。

问题:知识图谱的建设都有哪些重要的环节,需要注意什么?
解答:
从自身项目实施来看,有三个地方:
1.建模时多系统数据的融合,比如客户的信息存在多个系统中,核心、信贷、理财等,因为系统建设时间不一、多次升级等问题,导致数据不一致,数据质量较差,这样就需要花费很大精力去处理数据质量问题,还可能导致程序返工。
2.模型开发过中,选择那些业务场景也很重要,知识图谱不是万金油,有些场景比较费力。应该选择那些跟关联关系分析相关的,有明确结果,业务人员能够明确正确与否的应用场景,便于展示这个工具的优越性。
3.交付前的测试也很重要。因为知识图谱基本上都是需要融合各个业务系统的数据,涉及面较广。因此要给测试过程留够时间,便于测试人员发现一些数据处理上的遗漏。

问题:如何解决外部数据源准确性?
解答:
我个人无法从根本上解决,因为我们只是数据的使用方,准确性是需要从产生的根源上解决的问题。
不过在使用的时候可以进行多数据源的交叉验证,来提高准确性,完全消除是难以实现的。

问题:关于使用知识图谱进行客户分析?
在客户关系维护过程中,以姓名和手机号为节点唯一标识,节点属性为客户基本信息,,运用知识图谱对手机号,座机号的关联情况进行多维度的分析,包括不同客户手机号相同,直属亲人的手机号关联,不同客户
的公司座机号相同,住宅电话相同等;也可以用客户其他标识关联,如IP、地址、小区等。用图谱来展现客户关系,这种实现方式是否可行?
解答:
从你的描述来看,建立基础的知识图谱理论上可行,不过数据质量能不能满足要求是个大问题。
你的数据集里边公司电话、座机号准确性和覆盖度有多少,ip、小区信息会不会有重复之类的。

问题:关于实体、属性、关系的识别和存储?
目前这个系统的实施,都采用了什么数据,识别了哪些实体,属性和关系,属性是存在Titan图数据库还是哪里
解答:
大多数情况下实体关系属性都是比较明确的,因为知识图谱的建模是与现实世界相符的。
比如银行来说客户就是实体,姓名,身 份 证 号码,手机号都是属性。
关系相对稍微复杂一点,不过常见的关系也都比较明确,比如客户经理和贷款户,机构和对公客户,合同和借款人等等。
银行这边的实体基本上都是自然人、账号,机构,合同、押品等,关系就是实体之间的关系,比如账号和自然人的归属关系。
实体、关系和属性都是存在titan里的,交易明细存在hbase里。

问题:用知识图谱做信贷风控比传统的方式优势体现在哪里?
传统的风控行业,局限性在哪里
利用大数据挖掘,除知识图谱外,还有哪些比较好的风控模型。
获取数据,处理传统银行业数据源,其他关系网络数据获取途径有哪些?
解答:
1.知识图谱是一种工具,是一种与关系型数据库相对的数据组织方式,有其擅长的领域,但不能手里拿着锤子,看哪里都是钉子。知识图谱也有不擅长的领域。
2.除大数据外,基于传统的关系型数据库开发一些机器学习或深度学习模型也可以做到风控。

如果觉得我的文章对您有用,请点赞。您的支持将鼓励我继续创作!

5

添加新评论0 条评论

Ctrl+Enter 发表

本文隶属于专栏

活动总结
活动总结是社区交流活动内容的总结及延伸,为大家提供了社区专家们丰富且高水平的理论知识、实践经验以及常见问题的最佳解决方法,非常值得大家收藏学习。

作者其他文章

相关文章

相关问题

相关资料

X社区推广