CN113971572A - 数据处理方法、交互方法、计算设备及计算机存储介质 - Google Patents

Abstract

本申请实施例提供了一种数据处理方法、交互方法、计算设备及计算机存储介质。其中，所述方法包括：确定用户针对订单执行目标处理操作产生的目标事件；获取目标事件的事件相关信息；其中，事件相关信息包括目标处理操作关联的用户输入文本、所述订单的订单信息以及所述用户针对所述目标事件涉及的目标对象的复购信息；从所述事件相关信息中，识别所述目标事件对应的事件申请原因。本申请实施例提供的技术方案实现了事件申请原因有效准确的确定，实现了准确的处理操作。

Description

数据处理方法、交互方法、计算设备及计算机存储介质

技术领域

本申请实施例涉及计算机技术领域，尤其涉及一种数据处理方法、交互方法、计算设备及计算机存储介质。

背景技术

目前，在数据处理系统运行过程中，由于用户相应请求操作可能会产生很多事件，这些事件会影响数据处理系统的正常运行，因此如何洞察用户触发事件的真实原因以期做出相应改进，成为保证数据处理系统正常运行的关键问题。

以网上交易系统为例，用户通过网上交易系统可进行产品或服务等对象的交易消费，在进行对象交易过程中，会生成相应订单以作为交易凭证，用于指示之后的收款、物流配送等操作。而由于订单生成之后，出于各种原因用户可能会针对订单中的部分对象或全部对象请求执行目标处理操作，如提交售后申请，从而触发目标事件。目标事件的发生会影响正常交易链路，从而影响系统正常运行，带来复杂的处理操作，如果可以洞察事件申请原因即可以据此对系统做出相应改进以减少售后事件的发生，保证系统正常运行，然而目前真实的事件申请原因并无法有效准确的确定，导致基于事件申请原因无法实现准确的处理操作。

发明内容

本申请实施例提供一种数据处理方法及计算设备移动终端，用以解决现有技术中无法有效准确确定事件申请原因，使得无法实现准确的处理操作的技术问题。

第一方面，本申请实施例中提供了一种数据处理方法，包括：

确定用户针对订单执行目标处理操作产生的目标事件；

获取所述目标事件的事件相关信息；所述事件相关信息包括所述目标处理操作关联的用户输入文本、所述订单的订单信息、以及所述用户针对所述订单涉及的目标对象的复购信息中的至少一个；

从所述事件相关信息中，识别所述目标事件对应的事件申请原因；

根据所述事件申请原因，执行相应处理操作。

可选地，所述从所述事件相关信息中，识别所述目标事件对应的事件申请原因包括：

从所述用户输入文本、所述订单信息以及所述复购信息中的至少一个中，识别获得至少一个候选原因；

从所述至少一个候选原因中，按照筛选规则确定所述目标事件对应的事件申请原因。

可选地，所述至少一个候选原因按照如下实现方式识别获得：

根据所述订单信息以及所述复购信息，查找第一判定规则中不同事件申请原因标签对应的信息特征，确定所述订单信息以及所述复购信息所对应的至少一个事件申请原因标签，并作为至少一个第一类候选原因；

利用第一识别模型以及第一判定阈值，识别所述用户输入文本对应的至少一个目标申请原因；其中，所述第一识别模型根据不同事件申请原因标签及所对应的训练文本训练获得；根据所述至少一个目标申请原因、所述订单信息以及所述复购信息，查找第二判定规则中不同事件申请原因标签对应的信息特征，确定所对应的至少一个第三类候选原因；

以及，

利用所述第一识别模型以及第二判定阈值，识别所述用户输入文本对应的至少一个第三类候选原因；其中，所述第一识别原因根据不同事件申请原因标签及所对应的训练文本训练获得，其中，所述第二判定阈值高于所述第一判定阈值。

可选地，所述第一识别模型按照如下方式训练获得：

确定事件申请原因标签库；

从多个历史目标事件关联的用户输入文本中，获取所述事件申请原因标签库中的事件申请原因标签匹配的相关文本；

将所述相关文本作为训练文本；

利用所述训练文本及对应的事件申请原因标签，训练获得第一识别模型。

可选地，所述从多个目标事件关联的用户输入文本中，获取各所述事件申请原因标签库中的事件申请原因标签匹配的相关文本之后，所述方法还包括：

对所述相关文本对应的事件申请原因标签进行修正；

根据修正结果更新所述事件申请原因标签库，返回执行从多个目标事件关联的用户输入文本中，获取所述事件申请原因标签库中的事件申请原因标签匹配的相关文本，直至获得预定数量的相关文本。

可选地，该方法还包括：

从多个历史目标事件关联的用户输入文本中，统计出现次数大于预定次数的高频文本；

确定所述高频文本对应的事件申请原因标签，并利用所述高频文本对应的事件申请原因标签更新所述事件申请原因标签库。

可选地，所述从所述至少一个候选原因中，按照筛选规则确定所述目标事件对应的事件申请原因包括：

从至少一个候选原因中，过滤掉符合过滤条件的候选原因；

从过滤之后的候选原因中，选择标签优先级最高的候选原因作为所述目标事件对应的事件申请原因。

可选地，按照如下一种或多种实现方式，从至少一个候选原因中，过滤掉符合过滤条件的候选原因：

按照不同事件申请原因标签之间的逻辑关系，过滤掉属于后续因素的候选原因；

以及，

确定所述目标事件在所述目标对象对应的交易链路中所处的目标链路节点，并根据不同事件申请原因标签与不同链路节点的匹配关系，过滤掉与所述目标链路节点不匹配的候选原因。

可选地，所述利用第一识别模型以及第一判定阈值，识别所述用户输入文本对应的至少一个目标原因包括：

若未获得所述至少一个第一类候选原因的情况下，利用第一识别模型以及第一判定阈值，识别所述用户输入文本对应的至少一个目标原因；

所述利用所述第一识别模型以及第二判定阈值，识别所述用户输入文本对应的至少一个第三类候选原因包括：

若未获得至少一个第二类候选原因的情况下，利用第一识别模型以及第二判定阈值，识别所述用户输入文本对应的至少一个第三类候选原因。

可选地，所述从所述用户输入文本、所述订单信息及所述复购信息中的至少一个中，识别所述目标事件对应的事件申请原因包括：

根据所述用户输入文本、所述订单信息以及所述复购信息，利用第二识别模型，识别获得所述目标事件对应的事件申请原因；其中，所述第二识别模型根据用户输入文本样本数据、订单信息样本数据以及复购信息样本数据构成的输入样本数据，以及所对应的事件申请原因标签训练获得。

可选地，根据所述事件申请原因，执行相应处理操作包括如下一种或多种实现方式：

统计多个目标事件的事件申请原因，确定出现次数大于目标次数的目标事件申请原因，根据所述目标事件申请原因生成提示信息，以及将所述提示信息反馈给相关人员；

将所述事件申请原因反馈至提供所述目标对象的对象提供方；

确定所述事件申请原因对应的目标处理方式，将所述目标处理方式反馈至事件处理服务人员；

确定所述事件申请原因对应的目标处理方式，按照所述目标处理方式处理所述目标事件；

以及

统计提供所述目标对象的对象提供方所对应的不同目标事件的事件申请原因，根据统计结果确定所述对象提供方是否满足考核条件。

第二方面，本申请实施例提供了一种交互方法，包括：

提供显示界面；

在所述显示界面显示产生目标事件的订单对应的事件申请原因的通知反馈信息；

响应于针对所述订单的通知反馈信息的触发操作，获取所述订单所产生的目标事件对应的事件申请原因；

在所述显示界面显示所述事件申请原因。

第三方面，本申请实施例提供了一种计算设备，包括处理组件以及存储组件；

所述存储组件存储一个或多个计算机指令；所述一个或多个计算机指令用以被所述处理组件调用执行，以实现如上述第一方面所述的数据处理方法。

第四方面，本申请实施例提供了一种计算机存储介质，存储有计算机程序，所述计算机程序被计算机执行时实现如上述第一方面所述的数据处理方法。

本申请实施例中，对于用户针对订单执行目标处理操作而产生的目标事件，确定该目标事件的事件相关信息，该事件相关信息包括所述目标处理操作关联的用户输入文本、所述订单的订单信息及用户针对所述订单涉及的目标对象的复购信息中的至少一个，从事件相关信息中，识别所述目标事件对应的事件申请原因。由于用户输入文本、订单信息或复购信息可以洞察用户对目标对象及目标对象对应的交易链路的真实感受，因此结合用户输入文本、订单信息及复购信息中的至少一个，可以有效准确确定真实的事件申请原因，从而可以保证基于事件申请原因进行的处理操作的准确性，降低了错误处理操作的概率，从而可以降低出现错误处理操作带来的一系列的与系统的复杂交互操作，保证系统运行性能。

本申请的这些方面或其他方面在以下实施例的描述中会更加简明易懂。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作一简单地介绍，显而易见地，下面描述中的附图是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1示出了本申请提供的一种数据处理方法一个实施例的流程图；

图2示出了本申请提供的一种数据处理方法又一个实施例的流程图；

图3示出了本申请实施例在一个实际应用中的交易链路节点示意图；

图4示出了本申请提供的模型训练方法一个实施例的流程图；

图5示出了本申请提供的一种数据处理方法又一个实施例的流程图；

图6示出了本申请提供的一种数据处理方法又一个实施例的流程图；

图7示出了本申请实施例在一个实际应用中的场景交易示意图；

图8示出了本申请提供的一种数据处理装置一个实施例的结构示意图；

图9示出了本申请提供的一种计算设备一个实施例的结构示意图。

具体实施方式

为了使本技术领域的人员更好地理解本申请方案，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述。

在本申请的说明书和权利要求书及上述附图中的描述的一些流程中，包含了按照特定顺序出现的多个操作，但是应该清楚了解，这些操作可以不按照其在本文中出现的顺序来执行或并行执行，操作的序号如101、102等，仅仅是用于区分开各个不同的操作，序号本身不代表任何的执行顺序。另外，这些流程可以包括更多或更少的操作，并且这些操作可以按顺序执行或并行执行。需要说明的是，本文中的“第一”、“第二”等描述，是用于区分不同的消息、设备、模块等，不代表先后顺序，也不限定“第一”和“第二”是不同的类型。

本申请的技术方案可以适用于由于用户的一些请求操作导致相应事件发生而可能影响正常数据处理流程的数据处理场景中，以网上交易系统为例，针对进行对象交易产生的订单，用户可以针对订单执行目标处理操作，如提交售后请求从而触发目标事件，目标事件会影响对象正常的交易链路而可能导致交易终止，从而影响网上交易系统的正常运行，且目标事件的发生表明用户交易体验受损，也会影响网上交易系统的用户流量，因此，如何有效准确洞察目标事件背后真实的事件申请原因，以可以做出相应改进措施，以期减少目标事件的发生成为本领域技术人员需要解决的技术问题。

而传统方式中，用户执行目标处理操作时，系统可以提供若干原因选项供用户选择事件申请原因，从而获得事件申请原因，或者采用主动调研方式询问到用户之后，用户给出的事件申请原因，这两种方式中，系统提供的原因选项有限，用户可能无法选择到真实原因，且某些用户出于方便操作等原因，会随机选择一个原因，因此采用这种方式无法获得真实客观的事件申请原因，而采用调研方式受用户主观性和表述能力的限制，也无法获得准确的事件申请原因。

据此，发明人经过一系列研究，提出了一种可以有效准确确定真实的事件申请原因的技术方案。

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

图1为本申请实施例提供的一种数据处理方法一个实施例的流程图，该方法可以包括以下几个步骤：

101：确定用户针对目标事务执行目标处理操作产生的目标事件。

102：获取目标事件的事件相关信息。

其中，事件相关信息可以包括目标事务的的事务信息、目标处理操作关联的用户输入文本以及用户针对目标事务涉及目标对象的复操作信息中的至少一个。

103：从所述事件相关信息中，识别目标事件对应的事件申请原因。

本实施例技术方案可以由数据处理系统中的服务端执行，或者可以与数据处理系统进行通信交互的其它处理端执行。

可选地，该方法还可以包括：

根据事件申请原因，执行相应处理操作。

其中，目标事务是基于用户针对目标对象执行操作而产生的目标事务。事务信息即目标事务所涉及的相关信息。复操作信息可以包括针对目标对象的重新操作信息以及目标对象的关联对象的操作信息，目标对象的关联对象可以是指与目标对象的类别相同的对象，或者目标对象对应的对象提供方所提供的其它对象等。复操作信息例如具体可以包括是否针对目标对象再次执行可以产出目标事务的操作、目标对象的复操作次数、是否针对目标对象的关联对象执行产出目标事务的操作、以及关联对象的操作次数等。用户输入文本可以包括用户触发目标事件之前以及之后以文本形式所输入的相关言论。

本实施例中结合用户输入文本、事务信息及复操作信息中的至少一个，可以识别目标事件对应的事件申请原因。从用户输入文本、事务信息及复操作信息可以洞察用户对目标对象以及目标对象对应数据处理流程的真实感受，因此结合用户输入文本、事务信息及复购信息中的至少一个，可以有效准确确定真实的事件申请原因。根据真实的事情申请原因执行的相应处理操作，可以保证处理操作的执行准确度，降低了错误处理操作的概率，从而可以降低出现错误处理操作带来的一系列的与系统的复杂交互操作，保证系统运行性能。

在网上交易场景中，目标事务意即是指用户针对目标对象进行交易而产生的订单。在下面一个或多个实施例中多以网上交易场景为例对本申请技术方案进行详细介绍。

图2为本申请实施例提供的一种数据处理方法又一个实施例的流程图，该方法可以包括以下几个步骤：

201：确定用户针对订单执行目标处理操作而产生的目标事件。

其中，目标处理操作可以是指用户针对订单发起的售后请求，目标事件可以是指接收到售后请求事件或者基于售后请求而执行的售后处理操作事件。也即该目标事件对应的订单可以是已执行售后处理操作的交易终止订单或需要执行售后处理操作的待处理订单。

其中，售后请求可以包括仅退款请求、退款且退货请求、或者换货请求等。

202：获取目标事件的事件相关信息。

其中，事件相关信息包括目标处理操作关联的用户输入文本、该订单的订单信息以及用户针对订单涉及的目标对象的复购信息中的至少一个。

其中，由于用户执行目标处理操作之前以及之后，可以借助于网上交易系统会与目标对象的对象提供方，意即提供对象销售的商家，或者与系统的运营方，进行在线沟通等，用户输入文本即可以包括沟通过程中用户输入的在线消息等。用户输入文本往往包含用户对目标对象或目标对象对应交易链路的真实感受，例如发货较慢情况，用户可能会询问商家“为什么发货这么慢”，收到对象之后，对质量不满意，可能会向商家陈述“质量不好”等。

此外，用户执行目标处理操作之后，系统可能提供若干原因选项供用户选择事件申请原因，用户输入文本也可以包括用户所选择的事件申请原因等；此外，用户执行目标处理操作的同时，还可以输入备注信息，以供对象提供方查看等，用户输入文本也可以包括用户输入的备注信息等。

可选地，用户输入文本可以包括至少一个。

其中，用户执行的目标处理操作可以针对订单中的一个或多个目标对象发起，根据目标事件对应的订单，可以确定目标事件所对应的订单信息。

实际应用中，订单信息例如可以包括下单信息、对象信息、物流信息、价格优惠信息、收件人信息中的一个或多个信息特征等。其中，下单信息例如可以包括支付方式(银行卡、余额、第三方支付等)、配送方式(如免邮配送、极速配送等)、是否开具发票、支付金额、是否购买运费险等特征；对象信息例如可以包括对象购买数量、对象类型、对象价格等特征；物流信息例如可以包括物流提供方、物流状态(如未发货、已发货、运输中、运输完成)、发货时长(下单时间与发货时间的时间间隔)、物流时长(运输开始与运输结束的时间间隔)等特征；价格优惠信息例如可以包括优惠金额、优惠前价格以及优惠后价格等特征；收件人信息例如可以包括收件地址、收件人联系方式、收件人姓名等特征。

其中，复购信息可以包括用户对目标事件涉及的目标对象的重新购买信息或者对目标对象的关联对象的购买信息。

例如，重购买信息可以包括同一用户是否再次购买该目标对象、目标对象的复购次数等；对关联对象的购买信息可以包括同一用户是否购买目标对象的关联对象、关联对象的复购次数等信息特征，其中，关联对象可以包括与目标对象属于同一对象类别的对象、和/或与目标对象属于同一对象提供方提供的对象等。

203：从事件相关信息中，识别目标事件对应的事件申请原因。

由上文描述可知，从用户输入文本、订单信息和复购信息中可以洞察用户对目标对象以及目标对象对应交易链路的真实感受，据此可以推出用户提交事件申请的真实原因，因此结合用户输入文本、订单信息及复购信息中的至少一个，进行识别，使得可以有效准确的获得目标事件对应的事件申请原因，以洞悉用户提交售后请求的真实原因。

此外，在某些实施例中，从事件相关信息中，识别目标事件对应的事件申请原因可以包括：

从用户输入文本、订单信息以及复购信息中的至少一个中，识别获得至少一个候选原因；从至少一个候选原因中，按照筛选规则确定目标事件对应的事件申请原因。

也即根据用户输入文本、订单信息以及复购信息中的一个或者多个组合，可以识别获得多个候选原因，从而可以再按照一定的筛选规则从中筛选出事件申请原因，下面会对详细实现方式进行介绍。

可选地，至少一个候选原因可以按照如下一种或多种实现方式识别获得：

A：根据订单信息和/或复购信息，查找第一判定规则中不同事件申请原因标签对应的信息特征，确定该订单信息和/或复购信息所对应的至少一个事件申请原因标签，并作为至少一个第一类候选原因；

B：利用第一识别模型以及第一判定阈值，识别用户输入文本对应的至少一个目标原因；其中，第一识别模型根据不同事件申请原因标签及所对应的训练文本训练获得；根据至少一个第二候选原因、以及订单信息和/或复购信息，查找第二判定规则中不同事件申请原因标签对应的信息特征，确定所对应的至少一个第三类候选原因；

以及，

C：利用第一识别模型以及第二判定阈值，识别用户输入文本对应的至少一个第三类候选原因；其中，第一识别模型根据不同事件申请原因标签及所对应的训练文本训练获得。

可以将至少一个第一类候选原因、至少一个第二类候选原因以及至少一个第三类候选原因，均作为至少一个候选原因；

或者将至少一个第一类型至少一个第二类候选原因或者至少一个第三类候选原因，作为至少一个候选原因；

也可以是将至少一个第一类候选原因、以及至少一个第二类候选原因，或者至少一个第一类候选原因、以及至少一个第三类候选原因，或者至少一个第二类候选原因、以及至少一个第二类候选原因，作为至少一个候选原因。

可选地，可以是第二判定阈值高于第一判定阈值。也即在实现方式B中，第一识别模型可以识别获得用户输入文本属于任一个事件申请原因标签的概率值，若该概率值大于第一判定阈值，则可以将该事件申请原因标签作为用户输入文本对应目标原因；在实现方式C中，第一识别模型也可以是识别获得用户输入文本属于任一个事件申请原因标签的概率值，若该概率值大于第二判定阈值，则可以将该事件申请原因标签作为用户输入文本对应第三类候选原因。而第二判定阈值高于第一判定阈值，可以使得利用第二判定阈值获得的识别结果的精确度大于利用第一判定阈值获得的识别结果的精确度。

实际应用中，用户可以通过搜索、浏览、加购(加入虚拟购物车)对象等操作，最终触发对某个目标对象的下单操作，下单操作也即是对目标对象的请求购买操作或者请求交易操作，从而可以触发生成订单，用户对该订单支付完成之后，该目标对象即可以进入等待发货节点，订单中的目标对象发货之后，目标对象即进入等待收货节点，目标对象送达至用户之后，目标对象即进入用户使用/试用节点，用户使用或试用目标对象之后，可以确认收货，交易链路即终止。因此，参加图3所示，一个订单的交易链路可以划分为下单节点、等待发货节点、等待收货节点、以及使用/试用节点等链路节点。在链路节点之间订单处于不同状态，比如下单节点之后，订单处于支付状态，用户支付成功之后，进入等待发货节点，订单处于发货状态，订单中对象发货之后，进入等待收货节点，订单处于收货状态，对象送达至用户之后，进入使用/试用节点，订单即处于确认收货状态。

以目标处理操作为售后请求为例，由于用户可以在交易链路的不同链路节点对目标对象提交售后请求，事件申请原因可以按照交易链路进行划分，分布在不同的链路节点中。

结合在不同交易链路中可能产生的事件申请原因，可以预先设置事件申请原因标签，存储在事件申请原因标签库中。按照交易链路的不同链路节点，事件申请原因标签可以划分为六大类：价格问题、下单问题、服务问题、对象问题、物流问题以及用户主观原因，分布在交易链路的不同链路节点中。

价格问题例如可能是优惠少用了、降价、到手价格与描述不符、需要支付运费等；下单问题例如可能包括对象信息填错、收件人信息填错或者支付方式填错等；服务问题可以包括发货慢、少发或者错发等；物流问题例如可以包括物流慢、包装破损等；对象问题可以包括与描述不符、无法正常使用等；用户主观原因例如可以包括对象试用不合适、不想要了、买多了等。这些事件申请原因可能分布在交易链路的不同链路节点中。

对于实现方式A中，可以根据订单信息或者根据复购信息或者结合订单信息以及复购信息来确定事件申请原因，订单信息以及复购信息可以反映出用户对目标对象或交易链路的真实感受，因此据此可以进行事件申请原因的判定，第一判定规则可以预先设定，由于订单信息和复购信息中均可以包括多个信息特征，根据不同事件申请原因标签可以设定其对应的信息特征。例如，对于事件申请原因标签为：派送时间太久，其对应的信息特征可以包括：订单处于收货状态、且用户未确认收货、且从开始派送到用户提交事件申请的时长超过48小时、且消费者未拒收；又如：事件申请原因标签为：收件人信息错误，其对应的信息特征可以包括：该目标事件对应的目标对象存在复购行为、且复购订单与事件订单的差异为收件人信息不同等。不同事件申请原因标签对应设定的信息特征可以结合实际情况进行设定，这里不再穷举。

对于实现方式B中，对于用户输入文本可以采用模型识别方式，确定其对应的事件申请原因标签作为目标原因，比如从用户输入文本中识别获得目标对象为假货的事件申请标签。第一识别模型可以根据不同事件申请原因标签及所对应的训练文本预先训练获得，在下文会详细介绍。

可以结合至少一个目标原因和订单信息或者结合至少一个第二候选原因和复购信息或者结合至少一个第二候选原因和订单信息以及复购信息，按照第二判定规则来确定候选原因。第二判定规则可以预先设定，例如，事件申请原因标签为：发货时间长，其对应的信息特征例如可以包括：从用户输入文本中识别获得的第二候选原因中包括发货慢，且订单未延迟发货、且发货合约周期大于默认时间等。不同事件申请原因标签对应设定的信息特征可以结合实际情况进行设定，这里不再穷举。

对于实现方式C中，可以利用较高的第二判定阈值，利用该第一识别模型识别用户输入文本匹配的事件申请原因标签，并可以直接作为第三类候选原因。

由上文描述可知，第一识别模型可以预先训练获得，如图4所示的模型训练过程示意图中，第一识别模型可以具体按照如下方式训练获得：

401：确定事件申请原因标签库。

事件申请原因标签库中可以包括多个事件申请原因标签，可以结合实际应用情况，根据人工经验进行设定并存储。

402：从多个历史目标事件关联的用户输入文本中，获取与事件申请原因标签库中的事件申请原因标签匹配的相关文本。

为了方便进行匹配，事件申请原因标签可以预先设置对应的文本关键词，可以选择包含文本关键词的用户输入文本作为事件申请原因标签相匹配的相关文本。

其中，可以从多个历史目标事件关联的用户输入文本中进行匹配查找。具体选择那些历史目标事件可以结合实际情况确定，本申请对此不进行限制。

403：将相关文本作为训练文本。

404：利用训练文本及对应的事件申请原因标签，训练获得第一识别模型。

每个事件申请标签匹配的相关文本即可以作为训练文本，训练文本作为模型输入，匹配的事件申请标签作为模型输出，从而可以训练第一识别模型。

第一识别模型可以采用机器学习模型实现，如神经网络模型、分类器、支持向量机等，可选地，第一识别模型为文本识别模型，例如可以采用bert文本分类模型实现等，本申请对此不进行具体限制。

此外，为了使得事件申请原因标签更加精确，可选地，在某些实施例中，从多个历史目标事件关联的用户输入文本中，获取各事件申请原因标签库中的事件申请原因标签匹配的相关文本之后，所述方法还包括：

405：对相关文本对应的事件申请原因标签进行修正；

406：根据修正结果更新事件申请原因标签库。

其中，可以是将相关文本及其匹配的事件申请原因标签发送至相关人员，由相关人员审核事件申请标签是否准确，并对相关文本对应的事件申请原因标签进行修正。

根据修正结果更新事件申请原因标签库，例如可以包括若修正结果包括新增的事件申请原因，则还可以将新增的事件申请原因标签添加至事件申请原因标签库。

此外，为了丰富训练样本，提高训练样本的准确度，在某些实施例中，根据修正结果更新事件申请原因标签库之后，还可以返回步骤402继续执行，直至获得预定数量个相关文本。从而步骤403可以具体是将预定数量的相关文本均作为训练文本。

此外，为了减少计算量，从多个历史目标事件关联的用户输入文本中，获取与事件申请原因标签库中的事件申请原因标签匹配的相关文本可以包括：

确定多个历史目标事件关联的用户输入文本；

对用户输入文本进行过滤，筛除符合筛除条件的文本。

筛除条件例如可以包括语气词、助词、包含特定词语的文本等，以筛除无意义文本。

此外，由于随着网上交易系统的运行，可能会出现新的事件申请原因，因此，在某些实施例中，为了使得事件申请原因标签更加精确，可选地，在某些实施例中，该方法还可以包括：

407：从多个历史目标事件关联的用户输入文本中，统计出现次数大于预定次数的高频文本。

408：确定高频文本对应的事件申请原因标签；

409：利用高频文本对应的事件申请原因标签更新事件申请原因标签库。

确定出高频文本之后可以将高频文本发送至相关人员，根据相关人员的打标结果，确定高频文本所对应的事件申请原因标签。

利用高频文本对应的事件申请原因标签更新事件申请原因标签库，可以是将高频文本所对应的事件申请原因标签可以发送至审核人员，根据审核结果，确定其是否为新增的事件申请原因标签，若是，则可以添加至事件申请原因标签库中。

可选地，事件申请原因标签库更新之后，可以触发执行步骤402的操作，以可以对模型进行重训练，使得模型更加精准。

在某些实施例中，从至少一个候选原因中，按照筛选规则确定目标事件对应的事件申请原因可以包括：

从至少一个候选原因中，过滤掉符合过滤条件的候选原因；

从过滤之后的候选原因中，选择标签优先级最高的候选原因作为目标事件对应的事件申请原因。

作为一种实现方式，从至少一个候选原因中，过滤掉符合过滤条件的候选原因可以包括：

按照不同事件申请原因标签之间的逻辑关系，过滤掉逻辑关系中属于后续因素的候选原因。

逻辑关系中可以包括前导因素和后续因素，前导因素会影响后续因素，逻辑关系例如可以包括因果关系，结果项为候选因素，可以过滤掉因果关系中的结果项，只保留原因项；比如，目标对象为食品类等受保质期影响而容易变质的商品时，若至少一个候选原因中包括商品变质以及物流时间过长，本质上其实还是因为物流时间过长导致的商品变质，因此，可以将商品变质过滤掉。

作为另一种实现方式，从至少一个候选原因中，过滤掉符合过滤条件的候选原因可以包括：

确定目标事件在目标对象对应的交易链路中所处的目标链路节点，并根据不同事件申请原因标签与不同链路节点的匹配关系，过滤掉与目标链路节点不匹配的候选原因。

由前文所描述的交易链路，某些事件申请原因不能出现在某些链路节点中，比如，对象问题不可能出现在等待发货节点。因此，可以过滤掉与目标链路节点不匹配的候选原因。

作为其它实现方式，可以采用同时上述两种实现方式共同对候选原因进行过滤。

其中，从过滤之后的候选原因中，可以首先确定不同事件申请原因的标签优先级，可选地，不同事件申请原因的标签优先级可以预先设定。

此外，作为另一种可选方式，可以将多个确定候选原因的实现方式均命中的候选原因设置为最高标签优先级。也即可以是将至少一个第一类候选原因、至少一个第二类候选原因以及至少一个第三类候选原因中均出现的候选原因作为事件申请原因。若均出现的候选原因包括多个时，可以再按照预先设定的标签优先级，选择标签优先级最高的候选原因作为事件申请原因。

因此，可以是从过滤之后的候选原因中，确定至少一个第一类候选原因、至少一个第二类候选原因以及至少一个第三类候选原因中均出现的候选原因；

从至少一个第一类候选原因、至少一个第二类候选原因以及至少一个第三类候选原因中均出现的候选原因中，再选择标签优先级最高的候选原因作为事件申请原因。

其中，采用多种实现方式确定至少一个候选原因的情况下，实现方式B可以是在实现方式A未获得第一类候选原因的情况下再触发执行，实现方式C可以是在实现方式B未获得第一类候选原因的情况下再触发执行，如图5所示的数据处理方法中，可以包括如下几个步骤：

501：确定用户针对订单执行目标处理操作产生的目标事件。

502：确定目标处理操作关联的用户输入文本，所述订单的订单信息以及用户针对目标事件涉及的目标对象的复购信息。

503：根据订单信息以及复购信息，查找第一判定规则中不同事件申请原因标签对应的信息特征，确定是否存在所对应的至少一个第一类候选原因，若是，执行步骤504，若否，执行步骤505。

504：将至少一个第一类候选原因作为候选原因。

505：利用第一识别模型以及第一判定阈值，识别用户输入文本对应的至少一个目标原因。

其中，第一识别模型的具体训练方式可以详见前文所述。

506：根据至少一个目标原因、订单信息以及复购信息，查找第二判定规则中不同事件申请原因标签对应的信息特征，确定是否存在对应的至少一个第第二类候选原因，若是，执行步骤507，若否执行步骤508。

507：将至少一个第二类候选原因作为候选原因。

508：利用第一识别模型以及第二判定阈值，识别用户输入文本对应的至少一个第三类候选原因。

509：将至少一个第三类候选原因作为候选原因。

510：从至少一个候选原因中，按照筛选规则确定目标事件对应的事件申请原因。

此外，作为又一个实施例，根据用户输入文本、订单信息及复购信息中的至少一个，识别目标事件对应的事件申请原因可以包括：

根据用户输入文本、订单信息以及复购信息，利用第二识别模型，识别获得事件申请原因。

其中，第二识别模块可以基于由用户输入文本的样本数据、订单信息样本数据以及复购信息样本数据构成的输入样本数据，以及所对应的事件申请原因标签预先训练获得。

第二识别模型可以采用机器学习模型实现，如神经网络模型、分类器、支持向量机等实现，本申请对此不进行具体限制。

输入样本数据以及所对应的事件申请原因标签可以采用人工打标形式获得等。

实际应用中，获取事件申请原因之后，可以基于所确定的真实的事件申请原因，执行相应的处理操作，如图6所示的数据处理方法中，该方法可以包括以下几个步骤：

601：确定用户针对订单执行目标处理操作产生的目标事件。

602：获取目标事件的事件相关信息。

所述事件相关信息包括所述目标处理操作关联的用户输入文本、所述订单的订单信息、以及所述用户针对所述订单涉及的目标对象的复购信息中的至少一个；

603：从所述事件相关信息中，识别目标事件对应的事件申请原因；

605：根据事件申请原因，执行相应处理操作。

作为一种可选方式，根据事件申请原因，执行相应处理操作可以包括：

统计多个目标事件的事件申请原因，确定出现次数大于目标次数的目标事件申请原因，根据目标事件申请原因生成提示信息，以及将提示信息反馈给相关人员。

其中，相关人员可以是系统运营方的运维人员，从而相关人员可以根据提示信息确定经常出现的目标事件申请原因，据此可以决策是否对网上交易系统的数据处理过程作为调整等，比如目标事件申请原因为收件人信息填错，则可以针对订单提供收件人信息修改功能，从而可以对已生成订单进行收件人信息进行修改，而无需终止该订单再重新下单等。

此外，相关人员也可以是指提供该订单中目标对象的对象提供方，将出现次数较多的事件申请原因告知对象提供方，以便于对象提供方改进服务质量，以期减少目标事件的发生等。

作为又一种可选方式，根据事件申请原因，执行相应处理操作可以包括：

将事件申请原因反馈至提供目标对象的对象提供方。

也可以每一笔订单的事件申请原因告知相应的对象提供方，按照本申请技术方案所确定的事件申请原因为用户提交售后申请的真实原因，将其提供给对象提供方，对象提供方可以据此进行相应的改进，如售前服务改进、商品质量改进等，以期减少目标事件的发生。

作为又一种可选方式，根据事件申请原因，执行相应处理操作可以包括：

确定事件申请原因对应的目标处理方式，将目标处理方式反馈至事件处理服务人员，以后售后服务人员按照目标处理方式对发生目标事件进行相应售后处理操作等。

由于传统方式中，事件处理服务人员均是结合自己的经验提供事件处理服务，效率低且准确度也不高，通过结合事件申请原因，可以确定对应的目标处理方式，将目标处理方式通知给事件处理服务人员，事件处理服务人员可以据此提供售后服务，可以保证售后服务质量，提高售后服务效率，提高用户体验等。

其中，事件处理服务人员可以是系统运营方提供，也可以是对象提供方提供。

作为又一种可选方式，根据事件申请原因，执行相应处理操作可以包括：

确定所述事件申请原因对应的目标处理方式，按照所述目标处理方式处理所述目标事件；

目标事件具体为接收到售后请求事件时，也即可以按照事件申请原因对应的目标处理方式，自动处理该售后事件，可以提高售后处理效率。

作为又一种可选方式，根据事件申请原因，执行相应处理操作可以包括：

统计提供目标对象的对象提供方所对应的不同目标事件的事件申请原因，根据统计结果确定对象提供方是否满足考核条件。

通过识别真实的事件申请原因可以对对象提供方进行考核，以约束对象提供方提供良好的对象交易服务等，例如考核要求为：不能出现商品质量问题。考核条件即可以设定为事件申请原因中不包括商品质量问题等。

此外，本申请实施例还提供了一种交互方法，该方法可以包括以下几个步骤：

提供显示界面；

在所述显示界面显示产生目标事件的订单对应的事件申请原因的通知反馈信息；

响应于针对所述订单的申请原因提示信息的触发操作，获取所述订单所产生的目标事件对应的事件申请原因；

在所述显示界面显示所述事件申请原因。

其中，本实施例可以由对象提供方对应的客户端执行，显示界面可以是客户端所提供的。

作为一种可选方式，在所述显示界面显示产生目标事件的订单对应的事件申请原因的通知反馈信息可以包括：

在所述显示界面显示产生目标事件的订单的订单详情页面；

在所述订单详情页面中显示订单对应的事件申请原因的通知反馈信息；

其中，订单详情页面可以依据用户请求而显示。

作为另一种可选方式，在所述显示界面显示产生目标事件的订单对应的事件申请原因的通知反馈信息可以包括：

在显示界面中显示订单列表页面；

在所述订单列表页面中，产生目标事件的订单所对应显示位置显示所述订单对应的事件申请原因的通知反馈信息。

订单列表页面可以依据用户请求而确定。

订单列表页面中包括多个订单的订单提示信息，其中，产生目标事件的订单的事件申请原因的通知反馈信息可以包含在该订单提示信息中，或者在该订单提示信息所在显示位置对应显示等。

可选地，该订单列表页面可能对应多个产生目标事件的订单，因此，在该订单列表页面中，可以在多个产生目标事件的订单对应的显示位置显示事件申请原因对应通知反馈信息等。

其中，该通知反馈信息可以提示用户获取事件申请原因等。

可选地，该方法还可以包括：

响应于针对所述通知反馈信息的触发操作，获取所述订单所产生的目标事件对应的事件申请原因对应的服务改进提示信息；

在所述显示界面中显示所述服务改进提示信息，该服务改进提示信息用以提示对象提供方据此改善自己的服务质量，以减少目标事件的发生等。

此外，在显示界面还可以显示对象提供方对应的事件申请原因统计提示信息；则该方法还可以包括：响应于针对该统计提示信息的触发操作，获取所述对象提供方对应的事件申请原因的统计结果；在显示界面中显示该统计结果。

该统计结果例如可以包括对象提供方所涉及的出现次数多的若干事件申请原因等；或者可以包括按照出现次数从大到小的顺序排列的该对象提供方所涉及的事件申请原因列表等。

下面以一个实际的网上交易场景为例，结合图7所示场景示意图，对本申请技术方案进行介绍，以了解本申请技术方案的一个适用场景，当然，本申请技术方案并不仅局限于图6所示的交互场景。

为了便于说明，图7主要以一个用户角度、一个订单维度为例进行介绍，图7所示实施例中，用户执行的目标处理操作为提交售后申请，从而产生售后事件，可以理解的是，网上交易系统会面对大量用户，产生大量订单以及售后事件。

网上交易系统主要由客户端701、服务端702以及商家端703构成，商家可以利用商家端在服务端中发布商品，用户可以利用客户端购买商品，在本实现场景中，前文所涉及的对象意即是指商品，对象提供方也即提供商品的商家。

其中，服务端702可以部署在云上，可以是指云服务端，客户端701以及商家端703可以配置于手机、平板电脑、个人计算机等电子设备中，为了便于理解，图7中分别以一种电子设备形态表示客户端701以及商家端703。

用户可以通过客户端701进行商品的搜索、浏览、加购及下单等操作，基于下单操作可以触发下单请求，服务端702即可以基于所请求的目标对象生成订单，如前文所述，交易链路中可以包括多个节点，使得订单处于不同订单状态，这些节点可以包括下单节点(包含通过搜索、浏览、加购等动作最终触发的下单操作)、等待发货节点、等待收货节点、以及使用/试用节点，相应订单状态包括支付状态、发货状态、收货状态以及确认收货状态，相应的售后申请场景可以包括未发货仅退款、退货并退款等。实际应用中，用户可以在交易链路的不同节点中提出售后申请。

用户可以具体客户端701针对某个订单，向服务端702提交售后申请，本实施例中，以服务端702基于售后申请进行相应的售后处理操作，产生售后事件为例进行说明，该场景实施例中，目标事件也即具体是指售后事件。

对于该售后事件，服务端702可以按照本申请技术方案确定其真实的售后申请原因。如根据用户提交售后请求时关联的用户输入文本、该售后事件对应的订单信息、以及用户针对该收事件涉及的商品的复购信息，识别售后申请原因。

服务端702获得售后申请原因之后，可以将售后申请原因发送至商家端703以通知给商家。

当然，服务端702也可以基于售后申请原因，做出其它的处理操作，比如可以统计该商家对应的多个售后事件的售后申请原因，确定出现次数较多的目标售后申请原因，将该目标售后申请原因反馈给商家。

又如，可以统计网上交易系统中产生的多个售后事件的售后申请原因，确定出现次数较多的目标售后申请原因，可以将目标售后申请原因反馈给运维人员，由运维人员决策是否对交易链路进行调整等；

又如，售后事件为售后请求事件时，还可以确定所述事件申请原因对应的目标处理方式，将所述目标处理方式反馈至售后服务人员，以帮助售后服务人员快速确定目标处理方式，提高售后效率。

当然，也可以按照目标处理方式自动处理该售后事件，以进一步提高售后效率，比如售后请求事件的售后申请原因为商品质量问题，目标处理方式可以为退款操作，则可以自动执行退款操作。

此外，还可以对商家对应的不同售后事件的售后申请原因进行统计，根据统计结果确定商品是否满足考核条件，例如未出现由于商品质量问题导致的售后申请事件，则可以认为商家满足考核条件，否则不满足考核条件，可以对商家执行相应的惩罚措施等。

图8为本申请提供的一种数据处理装置一个实施例的结构示意图，该装置可以包括：

第一确定模块801，用于确定用户针对订单执行目标处理操作产生的目标事件；

获取模块802，用于获取所述目标事件的事件相关信息；所述事件相关信息包括所述目标处理操作关联的用户输入文本、所述订单的订单信息、以及所述用户针对所述订单涉及的目标对象的复购信息中的至少一个。

识别模块803，用于从事件相关信息中，识别目标事件对应的事件申请原因。

处理模块804，根据事件申请原因，执行相应处理操作。

在某些实施例中，识别模块可以具体用于从用户输入文本、订单信息以及复购信息中的至少一个中，识别获得至少一个候选原因；从至少一个候选原因中，按照筛选规则确定目标事件对应的事件申请原因。

在某些实施例中，识别模型可以具体按照如下一种或多种实现方式识别获得至少一个候选原因：

根据订单信息以及复购信息，查找第一判定规则中不同事件申请原因标签对应的信息特征，确定所述订单信息以及所述复购信息所对应的至少一个事件申请原因标签，并作为至少一个第一类候选原因；

利用第一识别模型以及第一判定阈值，识别用户输入文本对应的至少一个目标原因；其中，第一识别模型根据不同事件申请原因标签及所对应的训练文本训练获得；根据至少一个目标原因、订单信息以及复购信息，查找第二判定规则中不同事件申请原因标签对应的信息特征，确定所对应的至少一个第三类候选原因；

以及，

利用第一识别模型以及第二判定阈值，识别用户输入文本对应的至少一个第三类候选原因；其中，第一识别原因根据不同事件申请原因标签及所对应的训练文本训练获得。

在某些实施例中，该装置还可以包括：

模型训练模块，用于确定事件申请原因标签库；从多个历史目标事件关联的用户输入文本中，获取事件申请原因标签库中的事件申请原因标签匹配的相关文本；将相关文本作为训练文本；利用训练文本及对应的事件申请原因标签，训练获得第一识别模型。

在某些实施例中，模型训练模块还可以用于对相关文本对应的事件申请原因标签进行修正；根据修正结果更新事件申请原因标签库，返回执行从多个目标事件关联的用户输入文本中，获取事件申请原因标签库中的事件申请原因标签匹配的相关文本，直至获得预定数量的相关文本。

在某些实施例中，模型训练模块还可以用于从多个历史目标事件关联的用户输入文本中，统计出现次数大于预定次数的高频文本；确定高频文本对应的事件申请原因标签，并利用高频文本对应的事件申请原因标签更新事件申请原因标签库。

在某些实施例中，识别模块从至少一个候选原因中，按照筛选规则确定目标事件对应的事件申请原因可以包括从至少一个候选原因中，过滤掉符合过滤条件的候选原因；从过滤之后的候选原因中，选择标签优先级最高的候选原因作为目标事件对应的事件申请原因。

在模型实施例中，识别模块可以按照如下一种或多种实现方式，从至少一个候选原因中，过滤掉符合过滤条件的候选原因：

按照不同事件申请原因标签之间的逻辑关系，过滤掉属于后续因素的候选原因；

以及，

确定目标事件在目标对象对应的交易链路中所处的目标链路节点，并根据不同事件申请原因标签与不同链路节点的匹配关系，过滤掉与目标链路节点不匹配的候选原因。

在某些实施例中，识别模块利用第一识别模型以及第一判定阈值，识别用户输入文本对应的至少一个目标原因可以是若未获得至少一个第一类候选原因的情况下，利用第一识别模型以及第一判定阈值，识别用户输入文本对应的至少一个目标原因；

识别模块利用第一识别模型以及第二判定阈值，识别用户输入文本对应的至少一个第三类候选原因可以是若未获得至少一个第二类候选原因的情况下，利用第一识别模型以及第二判定阈值，识别用户输入文本对应的至少一个第三类候选原因。

在某些实施例中，识别模块可以具体用于根据用户输入文本、订单信息以及复购信息，利用第二识别模型，识别获得目标事件对应的事件申请原因；其中，第二识别模型根据用户输入文本样本数据、订单信息样本数据以及复购信息样本数据构成的输入样本数据，以及所对应的事件申请原因标签训练获得。

在某些实施例中，处理模块根据事件申请原因，执行相应处理操作包括如下一种或多种实现方式：

统计多个目标事件的事件申请原因，确定出现次数大于目标次数的目标事件申请原因，根据目标事件申请原因生成提示信息，以及将提示信息反馈给相关人员；

将事件申请原因反馈至提供目标对象的对象提供方；

确定事件申请原因对应的目标处理方式，将目标处理方式反馈至事件服务人员；

以及

统计提供目标对象的对象提供方所对应的不同目标事件的事件申请原因，根据统计结果确定对象提供方是否满足考核条件。

图8所述的数据处理装置可以执行图2所示实施例所述的数据处理方法，其实现原理和技术效果不再赘述。对于上述实施例中的X装置其中各个模块、单元执行操作的具体方式已经在有关该方法的实施例中进行了详细描述，此处将不做详细阐述说明。

在一个可能的设计中，图8所示实施例的数据同步装置可以实现为计算设备，如图9所示，该计算设备可以包括存储组件901以及处理组件902；

存储组件901存储一条或多条计算机指令，其中，一条或多条计算机指令供所述处理组件902调用执行，用于实现前文任一实施例所述的数据处理方法。

其中，处理组件902可以包括一个或多个处理器来执行计算机指令，以完成上述的方法中的全部或部分步骤。当然处理组件也可以为一个或多个应用专用集成电路(ASIC)、数字信号处理器(DSP)、数字信号处理设备(DSPD)、可编程逻辑器件(PLD)、现场可编程门阵列(FPGA)、控制器、微控制器、微处理器或其他电子元件实现，用于执行上述方法。

存储组件901被配置为存储各种类型的数据以支持在终端的操作。存储组件可以由任何类型的易失性或非易失性存储设备或者它们的组合实现，如静态随机存取存储器(SRAM)，电可擦除可编程只读存储器(EEPROM)，可擦除可编程只读存储器(EPROM)，可编程只读存储器(PROM)，只读存储器(ROM)，磁存储器，快闪存储器，磁盘或光盘。

当然，计算设备必然还可以包括其他部件，例如输入/输出接口、通信组件等。输入/输出接口为处理组件和外围接口模块之间提供接口，上述外围接口模块可以是输出设备、输入设备等。通信组件被配置为便于计算设备和其他设备之间有线或无线方式的通信等。

其中，该计算设备可以为物理设备或者云计算平台提供的弹性计算主机等，此时计算设备即可以是指云服务器，上述处理组件、存储组件等可以是从云计算平台租用或购买的基础服务器资源。

本申请实施例还提供了一种计算机可读存储介质，存储有计算机程序，所述计算机程序被计算机执行时可以实现上述任一实施例所述的数据处理方法。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统，装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性的劳动的情况下，即可以理解并实施。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到各实施方式可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件。基于这样的理解，上述技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在计算机可读存储介质中，如ROM/RAM、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行各个实施例或者实施例的某些部分所述的方法。

最后应说明的是：以上实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的精神和范围。

Claims (14)

1.一种数据处理方法，其特征在于，包括：

确定用户针对订单执行目标处理操作产生的目标事件；

获取所述目标事件的事件相关信息；所述事件相关信息包括所述目标处理操作关联的用户输入文本、所述订单的订单信息、以及所述用户针对所述订单涉及的目标对象的复购信息中的至少一个；

从所述事件相关信息中，识别所述目标事件对应的事件申请原因；

根据所述事件申请原因，执行相应处理操作。

2.根据权利要求1所述的方法，其特征在于，所述从所述事件相关信息中，识别所述目标事件对应的事件申请原因包括：

从所述用户输入文本、所述订单信息以及所述复购信息中的至少一个中，识别获得至少一个候选原因；

从所述至少一个候选原因中，按照筛选规则确定所述目标事件对应的事件申请原因。

3.根据权利要求2所述的方法，其特征在于，所述至少一个候选原因按照如下实现方式识别获得：

根据所述订单信息以及所述复购信息，查找第一判定规则中不同事件申请原因标签对应的信息特征，确定所述订单信息以及所述复购信息所对应的至少一个事件申请原因标签，并作为至少一个第一类候选原因；

利用第一识别模型以及第一判定阈值，识别所述用户输入文本对应的至少一个目标申请原因；其中，所述第一识别模型根据不同事件申请原因标签及所对应的训练文本训练获得；根据所述至少一个目标申请原因、所述订单信息以及所述复购信息，查找第二判定规则中不同事件申请原因标签对应的信息特征，确定所对应的至少一个第三类候选原因；

以及，

利用所述第一识别模型以及第二判定阈值，识别所述用户输入文本对应的至少一个第三类候选原因；其中，所述第一识别原因根据不同事件申请原因标签及所对应的训练文本训练获得，其中，所述第二判定阈值高于所述第一判定阈值。

4.根据权利要求3所述的方法，其特征在于，所述第一识别模型按照如下方式训练获得：

确定事件申请原因标签库；

从多个历史目标事件关联的用户输入文本中，获取所述事件申请原因标签库中的事件申请原因标签匹配的相关文本；

将所述相关文本作为训练文本；

利用所述训练文本及对应的事件申请原因标签，训练获得第一识别模型。

5.根据权利要求4所述的方法，其特征在于，所述从多个目标事件关联的用户输入文本中，获取各所述事件申请原因标签库中的事件申请原因标签匹配的相关文本之后，所述方法还包括：

对所述相关文本对应的事件申请原因标签进行修正；

根据修正结果更新所述事件申请原因标签库，返回执行从多个目标事件关联的用户输入文本中，获取所述事件申请原因标签库中的事件申请原因标签匹配的相关文本，直至获得预定数量的相关文本。

6.根据权利要求4所述的方法，其特征在于，还包括：

从多个历史目标事件关联的用户输入文本中，统计出现次数大于预定次数的高频文本；

确定所述高频文本对应的事件申请原因标签，并利用所述高频文本对应的事件申请原因标签更新所述事件申请原因标签库。

7.根据权利要求2所述的方法，其特征在于，所述从所述至少一个候选原因中，按照筛选规则确定所述目标事件对应的事件申请原因包括：

从至少一个候选原因中，过滤掉符合过滤条件的候选原因；

从过滤之后的候选原因中，选择标签优先级最高的候选原因作为所述目标事件对应的事件申请原因。

8.根据权利要求7所述的方法，其特征在于，按照如下一种或多种实现方式，从至少一个候选原因中，过滤掉符合过滤条件的候选原因：

按照不同事件申请原因标签之间的逻辑关系，过滤掉属于后续因素的候选原因；

以及，

确定所述目标事件在所述目标对象对应的交易链路中所处的目标链路节点，并根据不同事件申请原因标签与不同链路节点的匹配关系，过滤掉与所述目标链路节点不匹配的候选原因。

9.根据权利要求3所述的方法，其特征在于，所述利用第一识别模型以及第一判定阈值，识别所述用户输入文本对应的至少一个目标原因包括：

若未获得所述至少一个第一类候选原因的情况下，利用第一识别模型以及第一判定阈值，识别所述用户输入文本对应的至少一个目标原因；

所述利用所述第一识别模型以及第二判定阈值，识别所述用户输入文本对应的至少一个第三类候选原因包括：

若未获得至少一个第二类候选原因的情况下，利用第一识别模型以及第二判定阈值，识别所述用户输入文本对应的至少一个第三类候选原因。

10.根据权利要求1所述的方法，其特征在于，所述从所述用户输入文本、所述订单信息及所述复购信息中的至少一个中，识别所述目标事件对应的事件申请原因包括：

根据所述用户输入文本、所述订单信息以及所述复购信息，利用第二识别模型，识别获得所述目标事件对应的事件申请原因；其中，所述第二识别模型根据用户输入文本样本数据、订单信息样本数据以及复购信息样本数据构成的输入样本数据，以及所对应的事件申请原因标签训练获得。

11.根据权利要求1所述的方法，其特征在于，根据所述事件申请原因，执行相应处理操作包括如下一种或多种实现方式：

统计多个目标事件的事件申请原因，确定出现次数大于目标次数的目标事件申请原因，根据所述目标事件申请原因生成提示信息，以及将所述提示信息反馈给相关人员；

将所述事件申请原因反馈至提供所述目标对象的对象提供方；

确定所述事件申请原因对应的目标处理方式，将所述目标处理方式反馈至事件处理服务人员；

确定所述事件申请原因对应的目标处理方式，按照所述目标处理方式处理所述目标事件；

以及

统计提供所述目标对象的对象提供方所对应的不同目标事件的事件申请原因，根据统计结果确定所述对象提供方是否满足考核条件。

12.一种交互方法，其特征在于，包括：

提供显示界面；

在所述显示界面显示产生目标事件的订单对应的事件申请原因的通知反馈信息；

响应于针对所述订单的通知反馈信息的触发操作，获取所述订单所产生的目标事件对应的事件申请原因；

在所述显示界面显示所述事件申请原因。

13.一种计算设备，其特征在于，包括处理组件以及存储组件；

所述存储组件存储一个或多个计算机指令；所述一个或多个计算机指令用以被所述处理组件调用执行，以实现如权利要求1～11任一项所述的数据处理方法。

14.一种计算机存储介质，其特征在于，存储有计算机程序，所述计算机程序被计算机执行时实现如权利要求1～11任一项所述的数据处理方法。

Images