CN112364035A - 呼叫记录大数据的处理方法、装置、电子设备及存储介质 - Google Patents

Abstract

本申请提供一种呼叫记录大数据的处理方法、装置、电子设备及存储介质，其中，所述方法包括：获取呼叫记录数据；对所述呼叫记录数据进行文本化处理，获得对话文本数据；对所述对话文本数据进行提取，获得统一的业务数据；对所述统一的业务数据进行自我学习，获得结构化的业务数据；对所述结构化的业务数据进行合并及关联性错误验证，获得合并后的业务数据；对所述合并后的业务数据进行汇总，获得汇总后的业务数据。实施本申请实施例，能够自动、准确、统一地把呼叫记录与业务系统的数据进行结合关联，进行统一数据整合和清洗汇总。

Description

呼叫记录大数据的处理方法、装置、电子设备及存储介质

技术领域

本申请涉及大数据处理技术领域，具体而言，涉及一种呼叫记录大数据的处理方法、装置、电子设备及存储介质。

背景技术

呼叫中心是在一个相对集中的场所，由一批服务人员组成的服务机构。通常利用计算机通信技术处理来自企业、顾客的电话垂询，尤其具备同时处理大量来话的能力，还具备主叫号码显示，可将来电自动分配给具备相应技能的人员处理，并能记录和储存所有来话信息。

随着呼叫中心业务的发展，呼叫中心承载的业务量越来越大，同时也集成越来越多的业务系统与业务场景，呼叫中心的数据平台的现状一般是对呼叫数据进行汇总、统计，记录的维度注重拨打时间、拨打次数、坐席基本数据等，在多业务场景能统一输出的内容越来越少。

目前外包型呼叫中心的统计平台无法把人工对话的录音文件结合第三方业务系统有效利用起来，同时也未把机器人与客户的对话文本充分利用起来。另外，呼叫中心的大数据包含对话数据、客户数据、坐席数据、机器人数据、业务系统数据等，由于涉及的维度众多，无法进行有效分析。

发明内容

本申请实施例的目的在于提供一种呼叫记录大数据的处理方法、装置、电子设备及存储介质，能够自动、准确、统一地把呼叫记录与业务系统的数据进行结合关联，进行统一数据整合和清洗汇总。

第一方面，本申请实施例提供了一种呼叫记录大数据的处理方法，所述方法包括：

获取呼叫记录数据；

对所述呼叫记录数据进行文本化处理，获得对话文本数据；

对所述对话文本数据进行提取，获得统一的业务数据；

对所述统一的业务数据进行自我学习，获得结构化的业务数据；

对所述结构化的业务数据进行合并及关联性错误验证，获得合并后的业务数据；

对所述合并后的业务数据进行汇总，获得汇总后的业务数据。

在上述实现过程中，通过对呼叫中心的呼叫记录进行分类分析及合并，进行关联性错误验证，能够实现多种业务数据以及众多第三方业务系统数据的低成本对接，只需少量配置即可实现数据提取统一数据。

进一步地，所述对所述统一的业务数据进行自我学习，获得结构化的业务数据的步骤，包括：

通过规则引擎和自然语言处理模型对所述统一的业务数据进行结构化处理；

对结构化处理后的业务数据进行字段抽取；

将已存在的字段存储到现有数据表中；

将新的字段更新到扩展表中；

根据所述现有数据表和所述扩展表获得结构化的业务数据。

在上述实现过程中，过实时数据同步、定时数据同步、爬虫爬取同步等方式对不同的第三方业务系统的对话文本数据进行提取，获得统一的业务数据，通过规则引擎和自然语言处理模型对所述统一的业务数据进行结构化处理，可以实现将非结构化的业务数据进行结构化，方便后续进行不同维度的数据分析和汇总。

进一步地，所述对所述结构化的业务数据进行合并及关联性错误验证，获得合并后的业务数据的步骤，包括：

对所述结构化的业务数据与外呼系统的客户信息和拨打信息进行匹配，建立关联关系；

对建立关联关系失败的结构化的业务数据进行关联性错误验证处理，重新建立关联关系；

对建立关联关系的结构化业务数据进行合并，获得合并后的业务数据。

在上述实现过程中，对业务数据进行合并及关联性错误验证，清洗异常样本数据，处理格式或者内容错误，以及逻辑错误，可以解决来自不同业务系统的业务数据的信息匹配问题，能够实现多种业务数据以及众多第三方业务系统数据的低成本对接。

进一步地，所述对所述合并后的业务数据进行汇总，获得汇总后的业务数据的步骤，包括：

通过通话维度、客户维度、业务维度对所述合并后的业务数据进行分析，获得不同维度的业务数据；

对所述不同维度的业务数据进行汇总，获得汇总后的业务数据。

在上述实现过程中，通过通话维度、客户维度、业务维度分别进行分析再汇总，实现细粒度条件隔离洞察和宏观全方位汇总分析。

第二方面，本申请实施例还提供一种呼叫记录大数据的处理装置，所述装置包括：

获取模块，用于获取呼叫记录数据；

文本化处理模块，用于对所述呼叫记录数据进行文本化处理，获得对话文本数据；

数据提取模块，用于对所述对话文本数据进行提取，获得统一的业务数据；

结构化模块，用于对所述统一的业务数据进行自我学习，获得结构化的业务数据；

合并模块，用于对所述结构化的业务数据进行合并及关联性错误验证，获得合并后的业务数据；

汇总模块，用于对所述合并后的业务数据进行汇总，获得汇总后的业务数据。

在上述实现过程中，通过对呼叫中心的呼叫记录进行分类分析及合并，进行关联性错误验证，能够实现多种业务数据以及众多第三方业务系统数据的低成本对接，只需少量配置即可实现数据提取统一数据。

进一步地，所述结构化模块包括：

结构化单元，用于通过规则引擎和自然语言处理模型对所述统一的业务数据进行结构化处理；

字段抽取单元，用于对结构化处理后的业务数据进行字段抽取；

存储单元，用于将已存在的字段存储到现有数据表中；

更新单元，用于将新的字段更新到扩展表中；

获取单元，用于根据所述现有数据表和所述扩展表获得结构化的业务数据。

在上述实现过程中，过实时数据同步、定时数据同步、爬虫爬取同步等方式对不同的第三方业务系统的对话文本数据进行提取，获得统一的业务数据，通过规则引擎和自然语言处理模型对所述统一的业务数据进行结构化处理，可以实现将非结构化的业务数据进行结构化，方便后续进行不同维度的数据分析和汇总。

进一步地，所述合并模块包括：

匹配单元，用于对所述结构化的业务数据与外呼系统的客户信息和拨打信息进行匹配，建立关联关系；

建立单元，用于对建立关联关系失败的结构化的业务数据进行关联性错误验证处理，重新建立关联关系；

合并单元，用于对建立关联关系的结构化业务数据进行合并，获得合并后的业务数据。

在上述实现过程中，对业务数据进行合并及关联性错误验证，清洗异常样本数据，处理格式或者内容错误，以及逻辑错误，可以解决来自不同业务系统的业务数据的信息匹配问题，能够实现多种业务数据以及众多第三方业务系统数据的低成本对接。

进一步地，所述汇总模块包括：

分析单元，用于通过通话维度、客户维度、业务维度对所述合并后的业务数据进行分析，获得不同维度的业务数据；

汇总单元，用于对所述不同维度的业务数据进行汇总，获得汇总后的业务数据。

在上述实现过程中，通过通话维度、客户维度、业务维度分别进行分析再汇总，实现细粒度条件隔离洞察和宏观全方位汇总分析。

第三方面，本申请实施例还提供了一种电子设备，包括存储器及处理器，所述存储器用于存储计算机程序，所述处理器运行所述计算机程序以使所电子设备执行第一方面所述的呼叫记录大数据的处理方法。

第四方面，本申请实施例还提供了一种计算机可读存储介质，其存储有计算机程序，所述计算机程序被处理器执行时实现第一方面所述的呼叫记录大数据的处理方法。

第五方面，本申请实施例提供的一种计算机程序产品，所述计算机程序产品在计算机上运行时，使得计算机执行如第一方面任一项所述的方法。

本公开的其他特征和优点将在随后的说明书中阐述，或者，部分特征和优点可以从说明书推知或毫无疑义地确定，或者通过实施本公开的上述技术即可得知。

为使本申请的上述目的、特征和优点能更明显易懂，下文特举较佳实施例，并配合所附附图，作详细说明如下。

附图说明

为了更清楚地说明本申请实施例的技术方案，下面将对本申请实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本申请的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。

图1为本申请实施例提供的呼叫记录大数据的处理方法的流程示意图；

图2为本申请实施例中对业务数据进行结构化处理的过程示意图；

图3为本申请实施例中对业务数据进行合并的过程示意图；

图4为本申请实施例中对业务数据进行汇总的过程示意图；

图5为本申请实施例提供的呼叫记录大数据的处理装置的结构组成示意图；

图6为本申请实施例提供的电子设备的结构组成图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行描述。

应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步定义和解释。同时，在本申请的描述中，术语“第一”、“第二”等仅用于区分描述，而不能理解为指示或暗示相对重要性。

随着呼叫中心业务的发展，呼叫中心承载的业务量越来越大，同时也集成越来越多的业务系统与业务场景，呼叫中心的数据平台的现状一般是对呼叫数据进行汇总、统计，记录的维度注重拨打时间、拨打次数、坐席基本数据等，在多业务场景能统一输出的内容越来越少。

目前外包型呼叫中心的统计平台无法把人工对话的录音文件结合第三方业务系统有效利用起来，同时也未把机器人与客户的对话文本充分利用起来。

需要说明的是，以上现有技术中的技术方案所存在的种种缺陷，均是发明人经过仔细的实践研究后得出的结果，因此，上述问题的发现过程以及下文中本申请实施例针对上述问题所提出的解决方案，都应该是发明人在实现本申请过程中对本申请做出的贡献。

针对上述现有技术中的问题，本申请提供了一种呼叫记录大数据的处理方法、装置、电子设备及存储介质。本申请的呼叫记录大数据的处理方法适用于人机协作呼叫中心、多业务系统呼叫中心、多点呼叫中心等的大数据的处理。在本申请实施例中，所涉及的呼叫记录包括但不局限于对话数据、客户数据、坐席数据、机器人数据、业务系统数据等。

实施例一

参见图1，本申请实施例提供一种呼叫记录大数据的处理方法，该方法包括：

S1，获取呼叫记录数据；

S2，对呼叫记录数据进行文本化处理，获得对话文本数据；

S3，对对话文本数据进行提取，获得统一的业务数据；

S4，对统一的业务数据进行自我学习，获得结构化的业务数据；

S5，对结构化的业务数据进行合并及关联性错误验证，获得合并后的业务数据；

S6，对合并后的业务数据进行汇总，获得汇总后的业务数据。

具体地，在S2中，通过语音识别技术把呼叫记录数据转换为对话文本数据，

如图2所示，S4进一步包括：

S41，通过规则引擎和自然语言处理模型对统一的业务数据进行结构化处理；

S42，对结构化处理后的业务数据进行字段抽取；

S43，将已存在的字段存储到现有数据表中；

S44，将新的字段更新到扩展表中；

S45，根据现有数据表和扩展表获得结构化的业务数据。

在S3中，通过实时数据同步、定时数据同步、爬虫爬取同步等方式对不同的第三方业务系统的对话文本数据进行提取，获得统一的业务数据。

在S4中，通过规则引擎和自然语言处理模型把非结构化的统一的业务数据结构化，具体地，抽取已存在的字段存储到现有数据表中，新的字段自动更新到扩展表中，其中，扩展表的结构为一张结构表和一张数据表，结构表存储新字段标识和特征，数据表存储新字段标识、数据主键和扩展字段值。

如图3所示，S5进一步包括：

S51，对结构化的业务数据与外呼系统的客户信息和拨打信息进行匹配，建立关联关系；

S52，对建立关联关系失败的结构化的业务数据进行关联性错误验证处理，重新建立关联关系；

S53，对建立关联关系的结构化业务数据进行合并，获得合并后的业务数据。

由于业务数据的来源大多数是来源于多个途径，因此需要对业务数据进行合并及关联性错误验证，清洗异常样本数据，处理格式或者内容错误，以及逻辑错误。

在业务数据合并过程中，把第三方业务系统的业务数据：三方数据主键、手机号或客户身份标识号（Identity，ID）等与外呼系统的客户信息和拨打信息进行匹配，建立关联关系。

示例性地，本实施例中的拨打信息为外呼系统的规范数据，能识别客户身份的字段包括：所属租户、客户手机号、客户ID、客户身份证、客户姓名等。

第三方业务系统的数据由于数据来源比较多，包括：接口、RPA爬虫和EXCEL导入等，其中至少包含客户手机号、客户ID、客户身份证的任意一项，再通过辅助信息（所属租户或客户姓名等）确认关联关系。

在进行关联性错误验证处理中，通过规则引擎对于不同渠道的业务数据建立关联关系失败时分别做不同处理，包括创建新的客户信息、忽略新数据、添加到需人工修改队列并发邮件提醒人工处理，人工处理后再次建立关联关系；清洗异常样本数据，处理格式或者内容错误，以及逻辑错误，同样是通过规则引擎识别出进行忽略或提醒人工处理，例如客户逾期金额为负数、手机号不符合规则、还款金额为负数、销售金额为负数等情况。

示例性地，清洗异常样本数据的过程如下：

1、通过EXCEL导入等方式上传数据（还款记录、销售记录、客户信息等）；

（1）重复上传两遍: 通过客户ID或客户手机号进行判断，保留最新的信息；

（2）把第一业务系统的数据上传到了第二业务系统的账号里，不同的业务有不同的客户ID规则，如果上传的第一业务系统的数据匹配不到第一业务系统的拨打信息，但能匹配到第二业务系统的拨打信息并且客户ID规则也符合第二业务系统的规则，则自动更正为第二业务系统的数据并发送邮件通知数据管理人员，在邮件中提供回滚更正的URL链接。

2、通过RPA爬虫入库的数据；

（1）当客户手机号不符合规范时，如果客户信息可以匹配到拨打信息且核实过客户身份，则自动更正客户手机号到客户信息数据；

（2）当出现客户逾期金额、购买金额、还款金额为负数时，则根据每种业务预设好的规则进行修正、清零或定义为异常数据并删除。

其它业务的处理过程大致相同，可参见清洗异常样本数据的过程，不同的第三方系统中不同的业务类型会存在不同的处理逻辑，但原理上相近。

如图4所示，S6进一步包括：

S61，通过通话维度、客户维度、业务维度对合并后的业务数据进行分析，获得不同维度的业务数据；

S62，对不同维度的业务数据进行汇总，获得汇总后的业务数据。

通过通话维度、客户维度、业务维度对合并后的业务数据分别进行当前状态分析、历史数据分析等，全面对通话历史、客户性格、客户意图、客户态度、坐席性格、坐席态度、机器人类型、业务数据变化等汇总分析。

其中，通话维度分析的业务数据包括：通话ID、客户电话、拨打时间、接通时间、通话时长、人/机、分组、坐席标识/机器人类型、业务类型、外呼类型、收集到的标签、客户ID、实时客户信息、实时业务信息、对话结论等。

客户维度分析的业务数据包括：当前日期、客户ID、客户基本信息（姓名、性别、手机号等）、客户画像、案件负责人、批次号、逾期日期、逾期金额、案件排名、机器人拨打本人次数、总接通次数、机器人接通本人次数、机器人本人通话时长、机器人拨打三方次数、机器人接通三方次数、机器人三方通话时长、人工拨打本人次数、人工接通本人次数、人工本人通话时长、人工拨打三方次数、人工接通三方次数、人工三方通话时长、分案路径、小手机拨打次数、小手机接通次数、是否加微信成功、微信沟通次数、短信发送次数、短信回复次数、总划扣金额、购买金额等催收、电销、回访相关字段以及上一步自动学习扩展的字段等。

业务维度分析的业务数据包括：客户ID、还款信息、购买信息、反馈建议信息及相关金额和日期等。

示例性地，通话维度分析内容：客户打分（根据通话内容打分的专用模型可以忽略这一项）、通话时长、对话轮次、标签列表与去重后标签量。

客户维度分析内容:根据客户的历史拨打数据计算如下指标（每日一条）：

当日机器人与本人平均对话轮次；

当日机器人与联系人平均对话轮次；

历史机器人与本人平均对话轮次；

历史机器人与联系人平均对话轮次；

当日人工与本人平均对话轮次；

当日人工与联系人平均对话轮次；

历史人工与本人平均对话轮次；

历史人工与联系人平均对话轮次；

机器人拨打本人次数；

机器人拨打本人接通次数；

机器人拨打本人接通时长；

机器人拨打联系人次数；

机器人拨打联系人接通次数；

机器人拨打联系人时长；

人工拨打本人次数；

人工拨打本人接通次数；

人工拨打本人接通时长；

人工拨打联系人次数；

人工拨打联系人接通次数；

人工拨打联系人时长；

本人有效通话时长；

联系人有效通话时长；

机器人拨打本人有效时长；

机器人拨打三方有效时长；

人工拨打本人有效时长；

人工拨打三方有效时长；

微信沟通次数；

短信发送次数；

短信回复次数；

客户排名；

去重后的历史标签。

业务维度分析内容：根据客户的历史拨打数据计算当客户购买或还款时的如下指标：

客户排名；

机器人与本人平均对话轮次；

机器人与本人平均标签收集量；

人工与本人平均对话轮次；

人工与本人平均标签收集量；

机器人与本人最近沟通时间；

人工与本人最近沟通时间；

机器人与联系人最近沟通时间；

人工与联系人最近沟通时间；

最近机器人与本人沟通机器人类型；

最近人工与联系人沟通坐席类型；

最近机器人与联系人沟通机器人类型；

最近人工与联系人沟通坐席类型；

机器人拨打本人次数；

机器人拨打本人接通次数；

机器人拨打本人接通时长；

机器人拨打联系人次数；

机器人拨打联系人接通次数；

机器人拨打联系人时长、

人工拨打本人次数；

人工拨打本人接通次数；

人工拨打本人接通时长；

人工拨打联系人次数；

人工拨打联系人接通次数；

人工拨打联系人时长；

本人有效通话时长；

联系人有效通话时长；

机器人拨打本人有效时长；

机器人拨打三方有效时长；

人工拨打本人有效时长；

人工拨打三方有效时长；

去重后的历史标签。

在S62中，对三个不同维度的业务数据再次汇总：每天的客户维度数据副本记录、当天的业务记录、当天的拨打汇总合为一条记录，记录当天的拨打信息（机器人类型、坐席画像、客户标签）、历史拨打信息、当天的客户信息、当天的业务变化信息等，汇总后的数据能用于决策和挖掘深层次的机器人类型、坐席画像、客户画像、业务变化之间的隐含规律。

最终，汇总后的业务数据实现数据输出和图形输出，进一步地，可将汇总后的业务数据图形化进行展示。

在本申请实施例方法中，能够自动、准确、统一地把呼叫记录与业务系统的数据进行结合关联，进行统一数据整合和清洗汇总，能够实现多种业务数据以及众多第三方业务系统数据的低成本对接，只需少量配置即可实现数据提取统一数据；在呼叫中心的应用场景下，充分利用呼叫记录、对话内容、客户历史数据、第三方业务系统数据，实现多系统多平台统一指标汇总分析，同时，通过通话维度、客户维度、业务维度分别进行分析再汇总，实现细粒度条件隔离洞察和宏观全方位汇总分析。

实施例二

为了执行上述实施例一对应的方法，以实现相应的功能和技术效果，下面提供一种呼叫记录大数据的处理装置。

参见图5，本申请实施例的呼叫记录大数据的处理装置，该装置包括：

获取模块1，用于获取呼叫记录数据；

文本化处理模块2，用于对呼叫记录数据进行文本化处理，获得对话文本数据；

数据提取模块3，用于对对话文本数据进行提取，获得统一的业务数据；

结构化模块4，用于对统一的业务数据进行自我学习，获得结构化的业务数据；

合并模块5，用于对结构化的业务数据进行合并及关联性错误验证，获得合并后的业务数据；

汇总模块6，用于对合并后的业务数据进行汇总，获得汇总后的业务数据。

进一步地，结构化模块4包括：

结构化单元，用于通过规则引擎和自然语言处理模型对统一的业务数据进行结构化处理；

字段抽取单元，用于对结构化处理后的业务数据进行字段抽取；

存储单元，用于将已存在的字段存储到现有数据表中；

更新单元，用于将新的字段更新到扩展表中；

获取单元，用于根据现有数据表和扩展表获得结构化的业务数据。

进一步地，合并模块5包括：

匹配单元，用于对结构化的业务数据与外呼系统的客户信息和拨打信息进行匹配，建立关联关系；

建立单元，用于对建立关联关系失败的结构化的业务数据进行关联性错误验证处理，重新建立关联关系；

合并单元，用于对建立关联关系的结构化业务数据进行合并，获得合并后的业务数据。

进一步地，汇总模块6包括：

分析单元，用于通过通话维度、客户维度、业务维度对合并后的业务数据进行分析，获得不同维度的业务数据；

汇总单元，用于对不同维度的业务数据进行汇总，获得汇总后的业务数据。

上述的呼叫记录大数据的处理装置可实施上述实施例一的呼叫记录大数据的处理方法。上述实施例一中的可选项也适用于本实施例，这里不再详述。

本申请实施例的其余内容可参照上述实施例一的内容，在本实施例中，不再进行赘述。

实施例三

本申请实施例提供一种电子设备，包括存储器及处理器，该存储器用于存储计算机程序，该处理器运行计算机程序以使电子设备执行实施例一的呼叫记录大数据的处理方法。

可选地，上述电子设备可以是服务器。

请参见图6，图6为本申请实施例提供的电子设备的结构组成示意图。该电子设备可以包括处理器61、通信接口62、存储器63和至少一个通信总线64。其中，通信总线64用于实现这些组件直接的连接通信。其中，本申请实施例中设备的通信接口62用于与其他节点设备进行信令或数据的通信。处理器61可以是一种集成电路芯片，具有信号的处理能力。

上述的处理器61可以是通用处理器，包括中央处理器（Central ProcessingUnit，CPU）、网络处理器（Network Processor，NP）等；还可以是数字信号处理器（DSP）、专用集成电路（ASIC）、现成可编程门阵列（FPGA）或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以实现或者执行本申请实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器61也可以是任何常规的处理器等。

存储器63可以是，但不限于，随机存取存储器（Random Access Memory，RAM），只读存储器（Read Only Memory，ROM），可编程只读存储器（Programmable Read-Only Memory，PROM），可擦除只读存储器（Erasable Programmable Read-Only Memory，EPROM），电可擦除只读存储器（Electric Erasable Programmable Read-Only Memory，EEPROM）等。存储器63中存储有计算机可读取指令，当所述计算机可读取指令由所述处理器61执行时，设备可以执行上述图1至图4中方法实施例涉及的各个步骤。

可选地，电子设备还可以包括存储控制器、输入输出单元。

存储器63、存储控制器、处理器61、外设接口、输入输出单元各元件相互之间直接或间接地电性连接，以实现数据的传输或交互。例如，这些元件相互之间可通过一条或多条通信总线64实现电性连接。处理器61用于执行存储器63中存储的可执行模块，例如设备包括的软件功能模块或计算机程序。

输入输出单元用于提供给用户创建任务以及为该任务创建启动可选时段或预设执行时间以实现用户与服务器的交互。输入输出单元可以是，但不限于，鼠标和键盘等。

可以理解，图6所示的结构仅为示意，电子设备还可包括比图6中所示更多或者更少的组件，或者具有与图6所示不同的配置。图6中所示的各组件可以采用硬件、软件或其组合实现。

另外，本申请实施例还提供一种计算机可读存储介质，其存储有计算机程序，该计算机程序被处理器执行时实现实施例一的呼叫记录大数据的处理方法。

本申请实施例还提供一种计算机程序产品，该计算机程序产品在计算机上运行时，使得计算机执行方法实施例所述的方法。

在本申请所提供的几个实施例中，应该理解到，所揭露的装置和方法，也可以通过其它的方式实现。以上所描述的装置实施例仅仅是示意性的，例如，附图中的流程图和框图显示了根据本申请的多个实施例的装置、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段或代码的一部分，所述模块、程序段或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现方式中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个连续的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行规定的功能或动作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

另外，在本申请各个实施例中的各功能模块可以集成在一起形成一个独立的部分，也可以是各个模块单独存在，也可以两个或两个以上模块集成形成一个独立的部分。

所述功能如果以软件功能模块的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备（可以是个人计算机，服务器，或者网络设备等）执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器（ROM，Read-Only Memory）、随机存取存储器（RAM，Random Access Memory）、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述仅为本申请的实施例而已，并不用于限制本申请的保护范围，对于本领域的技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步定义和解释。

以上所述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应所述以权利要求的保护范围为准。

需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

Claims (10)

1.一种呼叫记录大数据的处理方法，其特征在于，所述方法包括：

获取呼叫记录数据；

对所述呼叫记录数据进行文本化处理，获得对话文本数据；

对所述对话文本数据进行提取，获得统一的业务数据；

对所述统一的业务数据进行自我学习，获得结构化的业务数据；

对所述结构化的业务数据进行合并及关联性错误验证，获得合并后的业务数据；

对所述合并后的业务数据进行汇总，获得汇总后的业务数据。

2.根据权利要求1所述的呼叫记录大数据的处理方法，其特征在于，所述对所述统一的业务数据进行自我学习，获得结构化的业务数据的步骤，包括：

通过规则引擎和自然语言处理模型对所述统一的业务数据进行结构化处理；

对结构化处理后的业务数据进行字段抽取；

将已存在的字段存储到现有数据表中；

将新的字段更新到扩展表中；

根据所述现有数据表和所述扩展表获得结构化的业务数据。

3.根据权利要求1所述的呼叫记录大数据的处理方法，其特征在于，所述对所述结构化的业务数据进行合并及关联性错误验证，获得合并后的业务数据的步骤，包括：

对所述结构化的业务数据与外呼系统的客户信息和拨打信息进行匹配，建立关联关系；

对建立关联关系失败的结构化的业务数据进行关联性错误验证处理，重新建立关联关系；

对建立关联关系的结构化业务数据进行合并，获得合并后的业务数据。

4.根据权利要求1所述的呼叫记录大数据的处理方法，其特征在于，所述对所述合并后的业务数据进行汇总，获得汇总后的业务数据的步骤，包括：

通过通话维度、客户维度、业务维度对所述合并后的业务数据进行分析，获得不同维度的业务数据；

对所述不同维度的业务数据进行汇总，获得汇总后的业务数据。

5.一种呼叫记录大数据的处理装置，其特征在于，所述装置包括：

获取模块，用于获取呼叫记录数据；

文本化处理模块，用于对所述呼叫记录数据进行文本化处理，获得对话文本数据；

数据提取模块，用于对所述对话文本数据进行提取，获得统一的业务数据；

结构化模块，用于对所述统一的业务数据进行自我学习，获得结构化的业务数据；

合并模块，用于对所述结构化的业务数据进行合并及关联性错误验证，获得合并后的业务数据；

汇总模块，用于对所述合并后的业务数据进行汇总，获得汇总后的业务数据。

6.根据权利要求5所述的呼叫记录大数据的处理装置，其特征在于，所述结构化模块包括：

结构化单元，用于通过规则引擎和自然语言处理模型对所述统一的业务数据进行结构化处理；

字段抽取单元，用于对结构化处理后的业务数据进行字段抽取；

存储单元，用于将已存在的字段存储到现有数据表中；

更新单元，用于将新的字段更新到扩展表中；

获取单元，用于根据所述现有数据表和所述扩展表获得结构化的业务数据。

7.根据权利要求5所述的呼叫记录大数据的处理装置，其特征在于，所述合并模块包括：

匹配单元，用于对所述结构化的业务数据与外呼系统的客户信息和拨打信息进行匹配，建立关联关系；

建立单元，用于对建立关联关系失败的结构化的业务数据进行关联性错误验证处理，重新建立关联关系；

合并单元，用于对建立关联关系的结构化业务数据进行合并，获得合并后的业务数据。

8.根据权利要求5所述的呼叫记录大数据的处理装置，其特征在于，所述汇总模块包括：

分析单元，用于通过通话维度、客户维度、业务维度对所述合并后的业务数据进行分析，获得不同维度的业务数据；

汇总单元，用于对所述不同维度的业务数据进行汇总，获得汇总后的业务数据。

9.一种电子设备，其特征在于，包括存储器及处理器，所述存储器用于存储计算机程序，所述处理器运行所述计算机程序以使所述电子设备执行根据权利要求1至4中任一项所述的呼叫记录大数据的处理方法。

10.一种计算机可读存储介质，其特征在于，其存储有计算机程序，所述计算机程序被处理器执行时实现如权利要求1至4中任一项所述的呼叫记录大数据的处理方法。

Images