CN111598371B - 一种风险防范方法、系统、装置及存储介质 - Google Patents

Abstract

本发明提供一种风险防范方法、系统、装置及存储介质。所述方法可以包括以下至少一种操作。可以获取至少一个服务订单的相关数据；所述服务订单的相关数据至少包括以下的两种：所述服务订单特征、所述服务订单执行过程中的实时状态数据、与所述服务订单中至少一个数据相关的历史记录。可以至少基于预设的风险判定规则，对所述服务订单的相关数据进行处理以确定所述服务订单的风险判定结果。可以基于所述风险判定结果，对所述服务订单执行风险应对操作。本发明提供的技术方案可以对服务订单执行前后进行实时风险判定，更快更准确的发现存在恶性事件和/或异常情况的订单并及时对用户进行预警或救援，减少用户受到的伤害。

Description

一种风险防范方法、系统、装置及存储介质

技术领域

本申请一般涉及安全技术领域，尤其涉及一种实时风险防范方法、系统、装置及存储介质。

背景技术

随着按需服务的普及，例如，在线网约车服务，安全问题已经成为用户关注的焦点，这也是在按需服务中亟待解决的重大问题。目前，按需服务中的安全风险防范方法一般对恶性事件的发现及处置过程存在滞后。因此，希望提供一种更优的风险防范系统及方法，基于对历史以及实时数据的分析处理，将人工与机器自动处理相结合，实现对安全事件的实时且全程的分析、监控和防范，更好地保障用户安全。

发明内容

为实现上述目的，本发明提供的技术方案如下。

一种风险防范方法，所述方法由至少一个处理器执行，可以包括以下至少一种操作。可以获取至少一个服务订单的相关数据；所述服务订单的相关数据至少包括以下的两种：所述服务订单特征、所述服务订单执行过程中的实时状态数据、与所述服务订单中至少一个数据相关的历史记录。可以至少基于预设的风险判定规则，对所述服务订单的相关数据进行处理以确定所述服务订单的风险判定结果。可以基于所述风险判定结果，对所述服务订单执行风险应对操作。

在本发明中，所述服务订单特征包括以下中的至少两个：服务提供者的身份信息、与服务订单相关的车辆的标识信息、服务相关时间、服务起始点、服务目的地、服务路径、服务请求者的身份信息以及服务的预计费用。

在本发明中，所述服务订单执行过程中的实时状态数据包括以下中的至少一个：所述服务订单执行过程中外部环境的实时状态数据、与所述服务订单相关的定位数据、与所述服务订单相关的终端的状态数据、与所述服务订单相关的车辆的状态数据和所述车辆内部的环境数据。

在本发明中，所述服务订单中至少一个数据相关的历史记录包括以下中的至少三个：服务提供者其它服务订单的记录、服务提供者的征信记录、服务请求者其它服务订单的记录、服务请求者的征信记录、服务提供者其它服务订单的车辆的标识信息、服务提供者其它服务订单的服务相关时间、服务提供者其它服务订单的服务起始点、服务提供者其它服务订单的服务目的地、服务提供者其它服务订单的服务路径、服务请求者其它服务订单的车辆的标识信息、服务请求者其它服务订单的服务相关时间、服务请求者其它服务订单的服务起始点、服务请求者其它服务订单的服务目的地、服务请求者其它服务订单的服务路径、服务请求者其它服务订单的费用以及服务请求者其它服务订单的支付记录。

在本发明中，所述方法还包括至少经训练的风险判断模型，对所述服务订单的相关数据进行处理以确定所述服务订单的风险判定结果。

在本发明中，所述风险判断模型通过利用历史服务订单的相关数据训练初始的机器学习模型获得；所述历史服务订单包括发生历史恶性事件的服务订单。

在本发明中，所述风险判定规则包括判断阈值，所述判断阈值通过利用历史服务订单的相关数据训练机器学习模型获得。

在本发明中，所述风险应对操作包括以下至少一种：风险排序操作、风险确认操作、风险处置操作和持续监控操作。

在本发明中，所述风险应对操作包括风险排序操作，以及风险确认操作、风险处置操作和持续监控操作中的至少一种。

在本发明中，所述风险应对操作包括至少基于风险排序操作的结果选择部分服务订单进行以下操作中的至少一种：风险确认操作、风险处置操作和持续监控操作。

在本发明中，所述风险应对操作包括风险确认操作，以及风险处置操作和持续监控操作中的至少一种。

在本发明中，所述风险应对操作包括至少基于风险确认操作的结果选择部分服务订单进行以下操作中的一种：风险处置操作和持续监控操作。

在本发明中，所述风险应对操作包括风险处置操作和持续监控操作。

在本发明中，所述风险应对操作包括基于风险处置操作的结果选择部分服务订单进行持续监控。

在本发明中，所述风险排序操作可以包括以下至少一种操作。可以基于所述风险判定结果，确定至少一个风险参数。可以基于所述至少一个风险参数，对所述至少一个服务订单进行风险等级排序。

在本发明中，所述基于所述至少一个风险参数对所述至少一个服务订单进行风险等级排序可以包括以下操作。可以将至少一个服务订单对应的至少一个风险参数输入至经训练的风险排序模型，确定所述至少一个服务订单的风险等级排序结果，其中，所述风险排序模型为机器学习模型。

在本发明中，所述风险确认操作可以至少包括以下至少一种。通过与用户信息交互进行风险确认、通过工作人员到现场进行风险确认、获取车内音频或图像信息进行风险确认、基于交通系统播报信息确认进行风险确认；其中，所述用户为服务提供者或服务请求者。

在本发明中，所述风险处置操作可以进一步包括以下至少一种操作。可以基于待风险处置的服务订单的相关信息及风险判定结果，生成救援信息。可以将所述救援信息发送至与警方关联的处理设备、与紧急联系人相关联的终端和/或与其他服务提供者相关联的终端；所述其他服务提供者包括距离待风险处置的服务订单当前执行地点不超过设定距离阈值的服务提供者。

在本发明中，所述风险处置操作还包括风险研判，所述风险研判可以包括以下至少一种操作。可以获取待风险研判的服务订单、所述服务订单的相关数据以及所述服务订单的风险判定结果。可以向与研判人员相关联的处理设备发送待风险研判的服务订单、所述服务订单的相关数据以及所述服务订单的风险判定结果。可以通过与研判人员相关联的处理设备获取人工研判结果。

在本发明中，所述持续监控操可以包括以下至少一种操作。可以基于待持续监控的服务订单的相关信息，确定与该服务订单相关联的终端。可以通过所述终端获取反应所述服务订单执行实况的文本、声音和/或图像数据，所述终端包括服务提供者终端、服务请求者终端和/或车载终端。

在本发明中，所述方法进一步包括以下至少一种操作。可以在判定结果为存在风险的服务订单结束后，获取反映与所述服务订单相关联的用户行为的数据。可以基于反映与所述服务订单相关联的用户行为的数据，确定所述与所述服务订单相关联的用户是否执行了安全行为。响应于与所述服务订单相关联的用户执行了安全行为，可以取消所述服务订单存在风险的判定结果。

在本发明中，所述方法进一步包括以下操作。可以基于所述风险应对操作结果，更新所述风险判定规则和/或风险判定模型。

在本发明中，所述方法进一步包括以下操作。可以基于所述风险应对操作结果，更新所述风险参数和/或风险排序模型。

一种风险防范系统。所述系统包括数据获取模块、风险判定模块和风险应对模块。所述数据获取模块用于获取至少一个服务订单的相关数据；所述服务订单的相关数据至少包括以下的两种：所述服务订单特征、所述服务订单执行过程中的实时状态数据、与所述服务订单中至少一个数据相关的历史记录。所述风险判定模块用于至少基于预设的风险判定规则，对所述服务订单的相关数据进行处理以确定所述服务订单的风险判定结果。所述风险应对模块用于基于所述风险判定结果，对所述服务订单执行风险应对操作。

本发明中，所述服务订单特征包括以下中的至少两个：服务提供者的身份信息、与服务订单相关的车辆的标识信息、服务相关时间、服务起始点、服务目的地、服务路径、服务请求者的身份信息以及服务的预计费用。

在本发明中，所述服务订单执行过程中的实时状态数据包括以下中的至少一个：所述服务订单执行过程中外部环境的实时状态数据、与所述服务订单相关的定位数据、与所述服务订单相关的终端的状态数据、与所述服务订单相关的车辆的状态数据和所述车辆内部的环境数据。

在本发明中，所述服务订单中至少一个数据相关的历史记录包括以下中的至少三个：服务提供者其它服务订单的记录、服务提供者的征信记录、服务请求者其它服务订单的记录、服务请求者的征信记录、服务提供者其它服务订单的车辆的标识信息、服务提供者其它服务订单的服务相关时间、服务提供者其它服务订单的服务起始点、服务提供者其它服务订单的服务目的地、服务提供者其它服务订单的服务路径、服务请求者其它服务订单的车辆的标识信息、服务请求者其它服务订单的服务相关时间、服务请求者其它服务订单的服务起始点、服务请求者其它服务订单的服务目的地、服务请求者其它服务订单的服务路径、服务请求者其它服务订单的费用以及服务请求者其它服务订单的支付记录。

在本发明中，所述风险判断模型通过利用历史服务订单的相关数据训练初始的机器学习模型获得；所述历史服务订单包括发生历史恶性事件的服务订单。

在本发明中，所述风险判定规则包括判断阈值，所述判断阈值通过利用历史服务订单的相关数据训练机器学习模型获得。

在本发明中，所述风险应对模块包括至少一种：风险排序单元、风险确认单元、风险处置单元和持续监控单元。风险排序单元用于执行风险排序操作，风险确认单元用于执行风险确认操作，风险处置单元用于执行风险处置操作，持续监控单元用于执行持续监控操作。

在本发明中，所述风险确认单元，用于至少基于风险排序单元执行的风险排序操作的结果选择部分服务订单进行风险确认操作。或者，所述风险处置单元，用于至少基于风险排序单元执行的风险排序操作的结果选择部分服务订单进行风险处置操作。或者，所述持续监控单元，用于至少基于风险排序单元执行的风险排序操作的结果选择部分服务订单进行持续监控操作。

在本发明中，所述风险处置单元，用于至少基于风险确认单元执行的风险确认操作的结果选择部分服务订单进行风险处置操作。或者，所述持续监控单元，用于至少基于风险确认单元执行的风险确认操作的结果选择部分服务订单进行持续监控操作。

在本发明中，所述持续监控单元，用于至少基于风险处置单元执行的风险处置操作的结果选择部分服务订单进行持续监控操作。

在本发明中，所述风险排序单元可以用于执行以下至少一种操作。可以基于所述风险判定结果，确定至少一个风险参数。可以基于所述至少一个风险参数，对所述至少一个服务订单进行风险等级排序。

在本发明中，所述风险排序单元可以进一步用于执行以下操作。可以将至少一个服务订单对应的至少一个风险参数输入至经训练的风险排序模型，确定所述至少一个服务订单的风险等级排序结果，其中，所述风险排序模型为机器学习模型。

在本发明中，所述风险确认单元可以用于执行包括以下至少一种操作。通过与用户信息交互进行风险确认、通过工作人员到现场进行风险确认、获取车内音频或图像信息进行风险确认、基于交通系统播报信息确认进行风险确认；其中，所述用户为服务提供者或服务请求者。

在本发明中，所述风险处置单元可以用于执行以下至少一种操作。可以基于待风险处置的服务订单的相关信息及风险判定结果，生成救援信息。可以将所述救援信息发送至与警方关联的处理设备、与紧急联系人相关联的终端和/或与其他服务提供者相关联的终端；所述其他服务提供者包括距离待风险处置的服务订单当前执行地点不超过设定距离阈值的服务提供者。

在本发明中，所述风险处置单元可以进一步用于执行风险研判操作，所述风险研判可以包括以下至少一种操作。可以获取待风险研判的服务订单、所述服务订单的相关数据以及所述服务订单的风险判定结果。可以向与研判人员相关联的处理设备发送待风险研判的服务订单、所述服务订单的相关数据以及所述服务订单的风险判定结果。可以通过与研判人员相关联的处理设备获取人工研判结果。

在本发明中，所述持续监控单元可以用于执行包括以下至少一种操作。可以基于待持续监控的服务订单的相关信息，确定与该服务订单相关联的终端。可以通过所述终端获取反应所述服务订单执行实况的文本、声音和/或图像数据，所述终端包括服务提供者终端、服务请求者终端和/或车载终端。

在本发明中，所述风险应对模块可以进一步用于执行包括以下至少一种操作。可以在判定结果为存在风险的服务订单结束后，获取反映与所述服务订单相关联的用户行为的数据。可以基于反映与所述服务订单相关联的用户行为的数据，确定所述与所述服务订单相关联的用户是否执行了安全行为。响应于与所述服务订单相关联的用户执行了安全行为，可以取消所述服务订单存在风险的判定结果。

在本发明中，所述系统进一步包括更新模块，所述更新模块可以用于执行以下操作。可以基于所述风险应对操作结果，更新所述风险判定规则和/或风险判定模型。

在本发明中，所述系统进一步包括更新模块，所述更新模块可以用于执行以下操作。可以基于所述风险应对操作结果，更新所述风险参数和/或风险排序模型。

一种风险防范装置，所述装置包括处理器以及存储器。所述存储器用于存储指令，所述指令被所述处理器执行时，导致所述装置实现如上所述的任一项所述风险防范方法对应的操作。

一种计算机可读存储介质，其特征在于所述存储介质存储计算机指令，当计算机读取存储介质中的计算机指令后，计算机运行如上所述的任意一项所述风险防范方法。

附加的特征将在下面的描述中部分地阐述，并且对于本领域技术人员来说，通过查阅以下内容和附图将变得显而易见，或者可以通过实例的产生或操作来了解。本发明的特征可以通过实践或使用以下详细实例中阐述的方法、工具和组合的各个方面来实现和获得。

附图说明

本申请将以示例性实施例的方式进一步说明，这些示例性实施例将通过附图进行详细描述。这些实施例并非限制性的，在这些实施例中，相同的编号表示相同的结构，其中：

图1是根据本申请的一些实施例所示的一个示例性风险防范系统的应用场景示意图；

图2是根据本申请一些实施例所示的可以在其上实现终端的移动设备的示例性硬件和/或软件组件的示意图；

图3是根据本申请一些实施例所示的示例性处理设备的框图；

图4是根据本申请一些实施例所示的风险防范方法的示例性流程图；

图5是根据本申请一些实施例所示的风险判断方法的示例性流程图；

图6是根据本申请的一些实施例所示的系统更新方法的示例性流程图。

具体实施方式

以下描述是为了使本领域的普通技术人员能够实施和利用本申请，并在特定应用及其要求的上下文中提供。对于本领域的普通技术人员来讲，对本申请披露的实施例进行的各种修改是显而易见的，并且本文中定义的通则在不背离本申请的精神及范围的情况下，可以适用于其他实施例及应用。因此，本申请不限于所示的实施例，而是符合与申请专利范围一致的最广泛范围。

本文中所使用的术语仅用于描述特定示例性实施例，并不限制本申请的范围。如本文使用的单数形式“一”、“一个”及“该”可以同样包括复数形式，除非上下文明确提示例外情形。还应当理解，如在本说明书中所示，术语“包括”、“包含”仅提示存在所述特征、整体、步骤、操作、元件和/或部件，但并不排除存在或添加一个或以上其他特征、整体、步骤、操作、元件、部件和/或其组合的情况。

在考虑了作为本申请一部分的附图的描述内容后，本申请的特征和特点以及操作方法、结构的相关元素的功能、各部分的组合、制造的经济性变得显而易见。然而，应当理解，附图仅仅是为了说明和描述的目的，并不旨在限制本申请的范围。应当理解的是附图并不是按比例的。

本申请中使用了流程图用来说明根据本申请的实施例的系统所执行的操作。应当理解的是，流程图中的操作不一定按照顺序来精确地执行。相反，可以按照倒序或同时处理各种步骤。此外，可以向流程图添加一个或以上其他操作。一个或以上操作也可以从流程图中删除。

此外，尽管本申请中的系统和方法主要是基于在线打车服务来进行描述，但是还应该理解，这仅是一个示例性实施例。本申请的系统和方法可能适用于其他任一种按需服务。例如，本申请的系统和方法可以应用于不同的运输系统，包括陆地、海洋、航空航天等或以上任意组合。该运输系统中的使用的交通工具可以包括出租车、私家车、顺风车、巴士、列车、子弹头列车、高铁、地铁、船只、飞机、热气球、无人驾驶车辆等或其任意组合。该运输系统还可以包括应用了管理和/或分配的运输系统，例如，收/送快递的系统。本申请的系统和方法的应用场景可以包括网页、浏览器插件、客户端、定制系统、企业内部分析系统、人工智能机器人等或以上任意组合。

本发明的一方面涉及一种风险防范方法。处理设备可以实时获取订单前后与行程和用户相关的数据，依据一定规则判定是否有风险，并基于判定结果采取相应的风险应对措施，处理设备还可以根据结果和反馈动态调整判定规则和算法。

图1是根据本申请的一些实施例所示的一种风险防范系统100的应用场景示意图。风险防范系统100可以判定行程中的安全事件风险，并采取应对方法以减少对用户的伤害。风险防范系统100可以用于互联网或者其它网络的服务平台。例如，风险防范系统100可以是为交通运输提供服务的线上服务平台。在一些实施例中，风险防范系统100可以应用于网约车服务，例如出租车呼叫、快车呼叫、专车呼叫、小巴呼叫、拼车、公交服务、司机雇佣和接送服务等。在一些实施例中，风险防范系统100还可以应用于代驾、快递、外卖等。在另一些实施例中，风险防范系统100还可以应用于家政服务、出行（如旅游）服务、教育（如线下教育）服务等领域。如图1所示，风险防范系统100可以包括处理设备110、一个或一个以上终端120、存储设备130、网络140以及信息源150。

在一些实施例中，处理设备110可以处理从终端120、存储设备130和/或信息源150处获得的数据和/或信息。例如，处理设备110可以获取多个终端120的定位/轨迹信息和/或与行程相关的参与方（例如，司机和乘客）的特征信息。处理设备110可以处理上述所获取的信息和/或数据以执行本申请描述的一个或多个功能。例如，处理设备110可以基于风险判定规则和/或风险判定模型对所获取的数据以进行安全风险的判定，并根据判定结果确定采取相应的应对方法，比如报警和/或提供线下支援。在一些实施例中，处理设备110可以获取至少一个服务订单的相关数据；所述服务订单的相关数据至少包括以下的两种：所述服务订单特征、所述服务订单执行过程中的实时状态数据、与所述服务订单中至少一个数据相关的历史记录。在一些实施例中，处理设备110可以至少基于预设的风险判定规则，对所述服务订单的相关数据进行处理以确定所述服务订单的风险判定结果。在一些实施例中，处理设备110可以基于所述风险判定结果，对所述服务订单执行风险应对操作。在一些实施例中，处理设备110可以是独立的服务器或者服务器组。该服务器组可以是集中式的或者分布式的（如：处理设备110可以是分布系统）。在一些实施例中，处理设备110可以是本地的或者远程的。例如，处理设备110可通过网络140访问存储于终端120、存储设备130和/或信息源150中的信息和/或资料。在一些实施例中，处理设备110可直接与终端120、存储设备130和/或信息源150连接以访问存储于其中的信息和/或资料。在一些实施例中，处理设备110可在云平台上执行。例如，该云平台可包括私有云、公共云、混合云、社区云、分散式云、内部云等中的一种或其任意组合。在另一些实施例中，处理设备110可以同时是终端120之一。

在一些实施例中，处理设备110可以包含一个或多个子处理设备（如：单核处理器或多核处理器）。仅仅作为范例，处理设备110可包含中央处理器（CPU）、专用集成电路（ASIC）、专用指令处理器（ASIP）、图形处理器（GPU）、物理处理器（PPU）、数字信号处理器（DSP）、现场可编程门阵列（FPGA）、可编辑逻辑电路（PLD）、控制器、微控制器单元、精简指令集电脑（RISC）、微处理器等或以上任意组合。

在一些实施例中，终端120可以是带有数据获取、存储和/或发送功能的设备，可以包括任一用户或者非直接参与服务的终端、服务提供者终端、服务请求者终端和/或车载终端。所述服务提供者可以是提供服务的个人、工具或者其他实体。所述服务请求者可以是需要得到或者正在接受服务的个人、工具或者其他实体。例如，针对网约车服务而言，所述服务提供者可以是司机、第三方平台，所述服务请求者可以是乘客或者其它接受类似服务的个人或者设备（例如物联网设备）。在一些实施例中，终端120可以用于采集各类数据，包括但不限于与服务相关的数据。例如，终端120所采集的数据可以包括与订单相关的数据（例如，订单请求时间、起终点、乘客信息、司机信息、车辆信息等）、与车辆行驶情况相关的数据（例如，当前速度、当前加速度、设备的姿态、路况等）、与服务行程相关的数据（例如，预设行程路径、实际行驶路径、费用等）、与服务参与方（服务提供者/服务请求者）相关的数据（例如，参与方的个人信息、服务提供者/服务请求者对于终端120的操控信息、终端设备的各种相关数据等）等或其任意组合。所采集数据可以是实时的，也可以是各类历史数据如用户过去的使用历史等等。数据可由终端120通过自身的传感器进行数据采集，也可以搜集外接传感器获取的数据，也可以读取存储在自身的存储器中的数据，还可以通过网络140读取存储在存储设备150中的数据。在一些实施例中，传感器可以包括定位装置、声音传感器、图像传感器、温湿度传感器、位置传感器、压力传感器、距离传感器、速度传感器、加速度传感器、重力传感器、位移传感器、力矩传感器、陀螺仪等或其任意组合等。终端120采集到的各类数据，可以用于判定在后续服务执行过程中所出现的恶性事件和/或异常情况。例如，可以基于轨迹数据，判定是否在某一地点存在停留异常（包括服务执行期间和/或服务完成后）、是否在某一路段丢失信号、是否在未到达服务目的地而提前结束服务、是否离预设路线、是否行驶至偏远地区、是否行程中多次停留、是否行驶速度缓慢、是否偏移路线时段、是否行驶时间超出阈值等。又例如，可以根据车辆的姿态、速度和/或加速度的变化判断车辆是否存在撞车、翻车等驾驶危险等。在一些实施例中，终端120可以包括台式电脑120-1、笔记本电脑120-2、车辆内置设备120-3、移动设备120-4等中的一种或几种的组合。在一些实施例中，移动设备120-4可以包括智能家居设备、可穿戴设备、智能移动设备、增强现实设备等或其组合。在一些实施例中，可穿戴设备可以包括智能手镯、智能鞋袜、智能眼镜、智能头盔、智能手表、智能衣物、智能背包、智能配饰等或其任意组合。在一些实施例中，智能移动设备可以包括智能手机、个人数字助理（PDA）、游戏设备、导航设备、POS机等或其组合。在一些实施例中，车辆内置设备120-3可以包括车载计算机、汽车数据记录器、车载人机交互（HCI）系统、行车记录仪、车载电视等。在一些实施例中，车载内置设备120-3可以获取车辆的各种部件数据和/或运行数据，例如，速度、加速度、行驶方向、部件状态、车辆周围环境等。所获取的数据可以用于判定是否发生行车事故（例如，翻车、撞车）、行车故障（例如，发动机或变速箱故障导致车辆无法移动）等。在一些实施例中，终端120可以是具有用于定位终端120的位置的定位技术的设备。在一些实施例中，终端120可以将采集到的数据/信息通过网络140传输至处理设备110进行后续步骤。终端120还可以将采集到的数据/信息存储至自身的存储器中，或通过网络140传输至存储设备130进行存储。终端120还可以接收和/或显示由处理设备110生成的与风险防范相关的通知。在一些实施例中，可以有多个终端相互连接，共同采集各类数据，并由一个或者多个终端对这些数据进行预处理。

存储设备130可以存储数据和/或指令。在一些实施例中，存储设备130可以存储终端120获取的数据/信息。存储设备130还可以存储历史事件的历史交通运输服务数据，例如，一些事件的历史服务订单的订单数据、服务参与方数据、车辆相关数据等，及行程数据等。所述历史事件可以是恶性事件或者其他异常事件，其中恶性事件可以包括抢劫、杀人、强奸、猥亵等危害人身安全、财产安全的事件，异常事件可以包括订单取消异常、行程中停留异常、行程结束后停留异常、位置丢失异常、未送达异常、行程异常、驾驶危险等。在一些实施例中，存储设备130可以存储处理设备110用于执行或使用来完成本申请中描述的示例性方法的数据和/或指令。例如，存储设备130可以存储风险判定模型，所述风险判定模型可以基于处理设备110所获取的与交通运输服务相关的数据/信息判定该交通运输服务是否存在风险。在一些实施例中，存储设备130可以存储用户终端的各类实时或者和历史数据，例如，与历史服务相关的用户的历史记录，比如历史评价等。在一些实施例中，存储设备130可以是处理设备110或者终端120的一部分。在一些实施例中，存储设备130可以包括大容量存储器、可移动存储器、易失性读写存储器、只读存储器( ROM)等或其任意组合。示例性的大容量储存器可以包括磁盘、光盘、固态磁盘等。示例性可移动存储器可以包括闪存驱动器、软盘、光盘、存储卡、压缩盘、磁带等。示例性的挥发性只读存储器可以包括随机存取内存（RAM）。示例性的RAM可包括动态RAM（DRAM）、双倍速率同步动态RAM（DDR SDRAM）、静态RAM（SRAM）、闸流体RAM（T-RAM）和零电容RAM（Z-RAM）等。示例性的ROM可以包括掩模ROM（MROM）、可编程ROM（PROM）、可擦除可编程ROM（PEROM）、电子可擦除可编程ROM（EEPROM）、光盘ROM（CD-ROM）和数字通用磁盘ROM等。在一些实施例中，存储设备130可以在云平台上实现。仅作为示例，所述云平台可以包括私有云、公共云、混合云、社区云、分布云、内部云、多层云等或其任意组合。例如，本发明中一些风险判断的算法或者数据可以存储在某个云平台上，定期更新，处理设备110通过网络访问这些算法或者数据，以实现整个平台的算法或者数据的统一与交互。特别的，一些历史数据可以统一存储在平台的一个云平台上，以便多个处理设备110或者终端120访问或者更新，以便保证数据的实时性和跨平台使用。例如，终端120可以随时将其速度和定位信息发布到某个云平台上，系统可以根据多个终端120的反馈判断是否出现异常状况。

在一些实施例中，存储设备130可以连接到网络140以与风险防范系统100中的一个或以上组件（例如，处理设备110、终端120、信息源150）通信。风险防范系统100中的一个或以上组件可以通过网络140访问存储设备130中存储的数据或指令。在一些实施例中，存储设备130可以与风险防范系统100中的一个或以上组件（例如，处理设备110、终端120、信息源150）直接连接或通信。在一些实施例中，存储设备130可以是处理设备110的一部分。

网络140可以促进信息和/或数据的交换。在一些实施例中，风险防范系统100中的一个或以上组件（例如，处理设备110、终端120、存储设备130和信息源150）可以通过网络140向/从风险防范系统100中的其他组件发送和/或接收信息和/或数据。例如，处理设备110可以通过网络140从终端120和/或信息源150获取与交通运输服务相关的数据/信息。又例如，终端120可以通过网络140从处理设备110或存储设备130处获取用于判定交通运输服务是否具有风险的判定模型。获取的判定模型可以以终端120的应用软件实现。终端120在获取与交通运输服务相关的数据/信息后，可以自行判定该交通运输服务是否具有风险，并执行风险应对操作，比如，启动电话报警。在一些实施例中，网络140可以为任意形式的有线或无线网络或其任意组合。仅作为示例，网络140可以包括缆线网络、有线网络、光纤网络、远程通信网络、内部网络、互联网、局域网（LAN）、广域网（WAN）、无线局域网（WLAN）、城域网（MAN）、广域网（WAN）、公共交换电话网络（PSTN）、蓝牙网络、紫蜂网络、近场通讯（NFC）网络、全球移动通讯系统（GSM）网络、码分多址（CDMA）网络、时分多址（TDMA）网络、通用分组无线服务（GPRS）网络、增强数据速率GSM演进（EDGE）网络、宽带码分多址接入（WCDMA）网络、高速下行分组接入（HSDPA）网络、长期演进（LTE）网络、用户数据报协议（UDP）网络、传输控制协议/互联网协议（TCP/IP）网络、短讯息服务（SMS）网络、无线应用协议（WAP）网络、超宽带（UWB）网络、移动通信（1G、2G、3G、4G、5G）网络、Wi-Fi、Li-Fi、窄带物联网（NB-IoT）等或其任意组合。在一些实施例中，风险防范系统100可以包括一个或以上网络接入点。例如，险防范系统110可以包括有线或无线网络接入点，例如基站和/或无线接入点140-1、140-2、...，风险防范系统100的一个或以上组件可以通过其连接到网络140以交换数据和/或信息。

信息源150可以用于为风险防范系统100提供信息的来源。在一些实施例中，信息源150可以用于为风险防范系统100提供与交通运输服务相关的信息，例如，天气情况、交通信息、地理信息、法律法规信息、新闻事件、生活资讯、生活指南信息等。在一些实施例中，信息源150还可以是其他第三方平台，可以提供服务请求方和/或服务提供方的征信记录，如信贷记录等。在一些实施例中，信息源150可以用于为风险防范系统100提供与风险防范相关的信息，例如，驾驶安全提示信息、人身安全提示信息、财产安全提示信息等。信息源150可以在单个中央服务器、通过通信链路连接的多个服务器或多个个人设备中实现。当信息源150在多个个人设备中实现时，个人设备可以生成内容（例如，被称为“用户生成内容”），例如，通过将文本、语音、图像和视频上载到云服务器。信息源可以由多个个人设备和云服务器生成。存储设备130、处理设备110以及终端120同时也可以是信息源。例如，终端120实时反馈的速度和定位信息，可以作为信息源提供交通状况信息供其他设备获取使用。

图2是根据本申请一些实施例所示的可以在其上实现终端120的移动设备200的示例性硬件和/或软件组件的示意图。如图2所示，移动设备200可以包括通信单元210、显示单元220、图形处理单元（GPU）230、中央处理单元（CPU）240、输入/输出250、内存260、存储器270和传感器280。在一些实施例中，任何其他合适的组件，包括但不限于系统总线或控制器（未显示），亦可包括于移动设备200内。

在一些实施例中，移动操作系统262（例如，IOS™、Android™、Windows Phone™等）和一个或多个应用程序264可以从存储器290加载到内存260中以便由CPU240执行。应用程序264可以包括浏览器或任何其他合适的移动应用程序，用于发送与交通运输服务相关联的数据/信息，并接收和呈现来自风险防范系统100的处理或其他相关的信息。例如，应用程序264可以是在线网约车出行平台（例如，滴滴出行™），用户（例如，服务请求者）可以通过应用程序264请求交通运输服务，并将请求信息发送至后台服务器端。用户与信息流的交互可以经由输入/输出250来实现并且经由网络140被提供给处理设备110和/或风险防范系统100的其他组件。

在一些实施例中，移动设备200还可以包括多个传感器280。传感器280可以获取与服务参与方（例如，司机/乘客）、车辆和/或行程等相关的数据。在一些实施例中，所述传感器可以包括声音传感器、图像传感器、温湿度传感器、位置传感器、压力传感器、距离传感器、速度传感器、加速度传感器、重力传感器、位移传感器、力矩传感器、陀螺仪等或其任意组合。在一些实施例中，由所述传感器所获取的数据可以用于后续判定是否发生风险和/或发生何种风险。例如，声音传感器和图像传感器可以采集服务参与方之间的对话以及车内的实时场景，以供判断是否发生司乘冲突或财产/人身安全事件，比如，肢体冲突、酒驾、抢劫、性侵犯、性骚扰等。又例如，位置传感器和位移传感器可以采集车辆的实时位置和/或车辆的行驶轨迹数据，以供判断是否发生行程异常，比如，异常停留、行程偏离、行驶时间异常等。还例如，速度传感器、加速度传感器和陀螺仪可以采集车辆的实时速度、实时加速度、终端120的偏转量、偏转频率等，以供判断车辆是否发生行车安全事故，比如，撞车、翻车等。

在一些实施例中，移动设备200还可以与车辆进行通信，例如，蓝牙通信，以获取安装在车辆内部或外部的车载传感器所采集的数据，比如，车辆当前状态数据和行驶数据，并将通过自身传感器获取的数据和通过车载传感器获取的数据进行合并，以用于后续的风险判定。

在一些实施例中，移动设备200可以将所获取的数据/信息，包括通过自身传感器获取的数据和通过车载传感器获取的数据，通过网络140发送到风险防范系统100的处理设备110以进行风险判定及处置。在一些实施例中，移动设备200可以直接进行风险判定及处置。例如，应用程序264中可以内置有进行风险判定的代码或模块，可以直接进行风险判定及处置。在一些实施例中，风险防范系统100的处理设备110和/或移动设备200还可以根据风险判定和/或处置结果生成安全通知指令。移动设备200可以通过接收并执行上述安全通知指令，提醒使用者当前所处的安全状态。例如，移动设备200可以通过语音（例如，通过扬声器）、振动（例如，通过振动器）、文字（通过短信或社交应用程序）、灯光闪烁（例如，通过闪光灯或显示单元220）等或其组合的方式实现该安全通知达到提醒使用者的目的。

在一些实施例中，移动设备200的使用者，例如，司机和/或乘客，可以自行执行风险判定过程。具体地，司机和/或乘客可以通过移动设备200中的应用程序264主动上报风险。例如，对移动设备200执行特定操作，比如摇晃或摔掷，可以启动报警程序。又例如，应用程序264的界面中可以包括直接与后端安全平台通信的快速入口（例如，报警按钮、求助按钮），在判断自身处于危险情况时，用户可以通过该点击报警按钮向警方报警。在报警后，应用程序264还可以进行报警的用户的当前位置和行程信息发送至警方以辅助救援。

为了实现本申请描述的各种模块、单元及其功能，计算机硬件平台可用作本文中描述之一个或以上组件的硬件平台。具有用户接口组件的计算机可用于实施个人计算机（PC）或任何其他类型的工作站或终端装置。若计算机被适当的程序化，计算机亦可充当系统。

图3是根据本申请一些实施例所示的示例性处理设备110的框图。处理设备110可以获取与交通运输服务相关的数据进行处理以确定对交通运输服务的风险判定，并进一步根据风险判定结果确定风险应对方法。在一些实施例中，处理设备110还可以根据风险确认和应对结果对在风险判定及应对过程中所使用的方法，例如，规则、算法、模型等，进行更新，以使达到最优的风险防范和应对效果。如图3所示，处理设备110可以包括数据获取模块310、风险判定模块320、风险应对模块330以及更新模块340。

数据获取模块310可以用于获取数据。在一些实施例中，数据获取模块310可以获取至少一个服务订单的相关数据。所述服务订单可以是当前时刻被请求、被执行、和/或已被完成的交通运输服务订单，例如，货物运输订单、出行服务订单等。所述服务订单的相关数据可以包括该服务订单的订单特征、订单执行过程中的实时状态数据、与所述服务订单中至少一个数据相关的历史记录。所述订单特征可以是服务订单中直接记载的信息，包括但不限于服务提供者的身份信息、与服务订单相关的车辆的标识信息、服务时间、行程起始点、行程目的地、行程路径和服务请求者的身份信息等或其任意组合。所述订单执行过程中的状态数据可以指服务订单执行过程中与订单相关的设备的状态数据和/或订单执行过程中用户或车辆周边的环境数据，包括但不限于与服务订单相关的终端的定位数据、与服务订单相关的终端的状态数据、车辆的状态数据、车辆内部的环境数据和订单执行过程中的外部环境的实时状态数据，例如车辆位置周围的环境数据，等或其任意组合。所述与所述服务订单中至少一个数据相关的历史记录可理解为当前服务订单中某个数据对应的历史记录，例如服务提供者的执行历史服务订单的记录、服务提供者的征信记录、服务请求者的参与历史服务订单的记录、服务请求者的征信记录等或其任意组合。在一些实施例中，数据获取模块310可以通过网络140与终端120、存储设备130和/或信息源150进行通信以获取上述数据。在获取后，数据获取模块310可以将上述数据传输至风险判定模块320进行多种类型的风险判定。

在一些实施例中，数据获取模块310还可以获取历史订单数据，所述历史订单数据可以包括发生过风险事件的交通运输服务相关的数据。所述历史数据可以与上述实时数据类似，同时还包括了对应于某一交通运输服务所发生的具体的风险事件类型。风险事件类型可以包括人身安全事件（包括抢劫、杀人、强奸、猥亵等）、服务取消异常、行程中停留异常、行程结束后停留异常、丢失异常、未送达异常、行程异常、驾驶危险等或其任意组合。在一些实施例中，所述历史订单数据可以作为训练数据训练风险判定模型或确定风险判定规则。所得到的风险判定模型或风险判定规则可以用于对服务订单数据进行判定以确定是否存在风险。在一些实施例中，所述历史订单数据可以存储在存储设备130中，数据获取模块310可以通过网络140与存储设备130进行通信，读取存储在其中的历史订单数据。

风险判定模块320可以基于所获取的数据进行风险判定。在一些实施例中，风险判定模块320可以使用判定规则对服务订单的当前状态进行风险判定。在一些实施例中，判定规则可以是根据所述历史订单数据和/或经验设定的条件/或阈值。所述判定规则的阈值设置可以依据数据统计确定，还可以使用风险判定模型的训练过程中获得的中间结果作为判定阈值。例如，可以基于预设条件例如发单时间是否为深夜、起终点是否偏僻、司机和/或乘客是否有相关历史记录、感测数据中敏感词汇出现次数是否超出预设值等设定判定规则以判定抢劫风险和/或女性安全事件风险。又例如，可以根据传感器数据（例如，重力加速度）超出预设阈值判断车辆是否存在撞车、翻车等驾驶危险。

在一些实施例中，风险判定模块320可以使用风险判定模型对交通运输服务的当前状态进行风险判定。所述风险判定模型可以是机器学习模型，例如，决策树，经由所获取的历史订单数据进行训练后得到。例如，可以利用历史订单数据中，与交通运输服务相关联的数据作为输入，以该交通运输服务发生的风险类型作为正确标准（Ground Truth）对模型进行训练。在一些实施例中，所述风险判定模型可以是一个单一的整体判定模型，用以判定是否存在一种或多种类型的风险，包括抢劫、人身安全事件、取消异常、行程中停留异常、行程结束后停留异常、丢失异常、未送达异常、行程异常、驾驶危险等或其任意组合。在一些实施例中，所述风险判定模型可以包括分别针对于某一种具体的风险事件的多个模型。例如，针对抢劫风险的判定，可以有专门的抢劫判定模型来对交通运输服务的当前状态进行判定。类似地，其他风险的判定也可以有专门对应的模型来执行。风险判定模块320可以利用多个模型中的组合，来判定一个或以上的风险。模型的组合方式可以根据实际需求确定。例如，在治安较差的区域，可以重点针对抢劫以及人身安全事件进行判定。而在市中心等人流车流密集区域，则可以重点针对行程异常进行判定。

在一些实施例中，风险判定模块320的判定结果可以包括有无风险以及对风险的量化表示。仅作为示例，判定结果可以是无风险。或者，判定结果可以是存在风险以及风险类型、表示风险等级的数值、风险概率等，比如，判定结果是（有风险、抢劫-5级）或（有风险、抢劫-56%、异常停留-87%）。在一些实施例中，风险判定模块320可以综合判定全部风险的等级和/或概率，并输出一个对应于综合风险判定的判定结果，例如，判定结果为（有风险、74%）。应当注意的是，以上描述的判定结果的形式只是为了说明的目的，本申请不对判定结果的形式进行限制。

风险应对模块330可以基于风险判定结果执行风险应对操作。在一些实施例中，风险应对模块330可以进一步包括风险排序单元332、风险确认单元334、风险处置单元336已经持续监控单元338。风险排序单元332可以基于排序规则对风险判定结果进行排序。所述排序规则可以是根据不同风险中的一个或以上风险参数（例如，停留异常风险中的停留时间等特征值）进行排序。所述排序规则也可以是根据判定结果中针对风险概率和/或等级的大小进行排序。所述排序规则还可以是设置排序结果阈值（例如，等级阈值、概率阈值等），对满足不同阈值的风险判定结果分别进行排序。所述排序规则也可以是基于多个风险参数的某种运算结果（如加权均值）的大小进行排序。在一些实施例中，风险排序单元332可以使用排序模型对风险判定结果进行排序。所述排序模型可以是数学模型，可以分别基于不同风险种类中的特征值和/或全部风险的特征值通过公式计算（例如，权重计算）得出风险排序结果。所述排序模型还可以是机器学习模型，该模型可以基于触发风险的特征数据进行训练后得到。风险确认单元332可以将交通运输服务订单对应的风险判定结果输入至训练好的风险排序模型，确定排序结果。在一些实施例中，排序结果可以表示服务订单的风险等级排序。在一些实施例中，排序结果可以表示服务订单的风险概率等级排序。在一些实施例中，排序结果决定着后续的应对措施。

在一些实施例中，风险排序单元332可以对不同风险分别进行排序。例如，对于存在同一种风险的全部订单进行排序，分别得到不同风险的排序结果。在一些实施例中，风险排序单元332还可以对全部风险进行综合排序。例如，可以对不同风险分别设置权重，结合权重对不同风险的订单进行综合排序。

风险确认单元334可以进行风险确认。在一些实施例中，风险确认单元334可以基于风险排序单元332的排序结果确认风险。例如，可以在风险排序较高的订单中选择预设数量的订单进行风险确认。在一些实施例中，风险确认单元334可以直接基于风险判定模块320的判定结果确认风险。例如，对于风险判定模块320判定结果（例如，风险等级、风险概率等）在预设范围内的订单进行风险确认。在一些实施例中，风险确认单元334可以直接对所有的服务订单进行风险确认。

在一些实施例中，风险确认操作可以包括通过与用户信息交互进行风险确认、通过工作人员到现场进行风险确认、获取车内音频或图像信息进行风险确认、基于交通系统播报信息确认进行风险确认等或其任意组合。风险确认单元334可以通过人工的方式进行风险确认。对于存在潜在风险的订单，风险防范系统100可以展示与该风险订单相关的信息，并通过人工的方式（例如，人工客服）进一步确定相关风险信息。在一些实施例中，风险确认单元334可以通过自动的方式进行风险确认。对于存在潜在风险的订单，自动风险确认单元334可以通过包括互动式语音应答（Interactive Voice Response, IVR）外呼、终端显示屏弹窗、应用文字、语音询问或语音监控车内司机和/或乘客、车内录音上报等的方式确认风险。在一些实施例中，风险确认单元334还可以通过人工与自动交互的方式进行风险确认。对于存在潜在风险的订单，风险确认单元334可以通过电话交互的方式进行风险确认。

风险处置单元336可以执行风险处置操作。所述风险处置操作可以包括通知紧急联系人、启动司机端和/或乘客端数据上报、专人跟进报警等或其任意组合。在一些实施例中，风险处置单元336可以直接基于风险判定结果确定风险处置操作。例如，风险处置单元336可以对高风险订单执行风险处置，并根据风险概率采取不同的行动。例如，根据算法，当风险概率超过20%时即采取某一行动，例如向用户终端发送提示信息，以提醒用户（司机或乘客）有一定风险，要求用户注意。当风险概率更高时（例如90%），可以直接要求终止服务。在一些实施例中，风险处置单元336可以基于系统多个风险排序结果确定风险处置操作。例如，风险处置单元336可以对风险排序序位处于前30%的订单执行风险处置，例如派专人跟进等。在一些实施例中，风险处置单元336还可以基于风险确认结果确定风险处置操作。例如，风险处置单元336可以对经过确认后存在风险的订单执行风险处置操作。系统风险处置的判据和阈值可以与更新单元结合，根据实时情况和历史数据与反馈动态调整。

在一些实施例中，风险处置单元336可以通过风险研判的方法进行风险处置。风险处置单元336可以获取满足风险研判条件的服务订单及其相关的服务订单数据，并获取服务订单的风险判定结果以及与服务订单的各方面相关的风险信息，并基于风险判定结果以及风险信息判定服务订单是否发生风险事件。

在一些实施例中，风险处置单元336可以通过风险救援的方法进行风险处置。风险处置单元336可以基于风险判定结果确定服务订单是否满足风险救援条件，对满足风险救援条件生成救援信息并发送。例如，对于被判定为存在风险的订单，可以获取其风险信息（例如，风险类型、风险等级等），对于风险等级满足预设阈值的订单，可以生成救援信息以通知周围司机前往求援或查看。

持续监控单元338可以对服务订单进行持续监控。所述持续监控可以是针对在风险判定中被判定为无风险的服务订单进行，也可以是针对风险排序中处于末尾的部分服务订单，还可以是针对经过风险确认后为无风险的服务订单。在一些实施例中，持续监控单元338可以基于待持续监控的服务订单的相关信息，确定与该服务订单相关联的终端。所述终端可以是服务提供者终端、服务请求者终端、车载终端等。持续监控单元338可以通过所述终端获取反应所述服务订单执行实况的文本、声音和/或图像数据。数据获取可以是通过所述终端上安装的各类传感器实现的。例如，可以通过声音传感器（比如，麦克风）获取音频数据，通过图像传感器（比如，摄像头）获取视频数据。所获取的数据，可用于下一时刻，例如，10s后，的风险判定及处置。

更新模块340可以基于风险应对操作结果更新规则和/或模型。更新的规则可以包括风险判定规则、风险排序规则等。更新的模型可以包括风险判定模型、风险排序模型等。在一些实施例中，更新模块340可以根据风险确认结果和/或风险处置结果与风险判定结果/风险排序结果进行比较，获取其中的差异。并根据所述差异更新判定/排序规则中风险参数和/或风险参数值。在一些实施例中，更新模块340可以将风险确认操作和/或风险处置操作中确定为发生风险事件的订单，作为新的样本数据重新对风险判定模型进行训练，以更新模型中的参数。同时，更新模块340可以根据风险确认或风险应对得到的实际排序结果的各个订单的特征数据重新训练风险排序模型。在一些实施例中，对于规则和模型的更新可以以预定的间隔进行，例如，一天、一星期、一个月、一个季度等。在一些实施例中，更新模块340可以采用主动推送方式强制系统进行更新。

应当理解，图3所示的系统及其模块可以利用各种方式来实现。例如，在一些实施例中，系统及其模块可以通过硬件、软件或者软件和硬件的结合来实现。其中，硬件部分可以利用专用逻辑来实现；软件部分则可以存储在存储器中，由适当的指令执行系统，例如微处理器或者专用设计硬件来执行。本领域技术人员可以理解上述的方法和系统可以使用计算机可执行指令和/或包含在处理器控制代码中来实现，例如在诸如磁盘、CD或DVD-ROM的载体介质、诸如只读存储器（固件）的可编程的存储器或者诸如光学或电子信号载体的数据载体上提供了这样的代码。本申请的系统及其模块不仅可以有诸如超大规模集成电路或门阵列、诸如逻辑芯片、晶体管等的半导体、或者诸如现场可编程门阵列、可编程逻辑设备等的可编程硬件设备的硬件电路实现，也可以用例如由各种类型的处理器所执行的软件实现，还可以由上述硬件电路和软件的结合（例如，固件）来实现。

需要注意的是，以上描述，仅为描述方便，并不能把本申请限制在所举实施例范围之内。可以理解，对于本领域的技术人员来说，在了解该系统的原理后，可以在不背离这一原理的情况下，对实施上述方法和系统的应用领域进行形式和细节上的各种修正和改变。

图4是根据本申请一些实施例所示的风险防范方法400的示例性流程图。在一些实施例中，方法400中的一个或以上步骤可以在图1所示的系统100中实现。例如，方法400中的一个或以上步骤可以作为指令的形式存储在存储设备130和/或存储器270中，并被处理设备110调用和/或执行。

步骤410，获取至少一个服务订单的相关数据。步骤410可以由数据获取模块310执行。在一些实施例中，所述服务订单可以是当前时刻被请求、被执行、和/或已被完成的交通运输服务订单，例如，货物运输订单、出行服务订单等。所述服务订单的相关数据可以包括所述服务订单的服务订单特征、所述服务订单执行过程中的实时状态数据、与所述服务订单中至少一个数据相关的历史记录。在一些实施例中，所述服务订单特征进一步可以包括服务提供者的身份信息、与服务订单相关的车辆的标识信息、服务相关时间、服务起始点、服务目的地、服务路径、服务请求者的身份信息以及服务的预估费用。所述服务提供者信息可以包括年龄、性别、脸部画像、联系方式、受教育程度、身份证号、驾驶证号等。所述与服务订单相关的车辆的标识信息可以包括车牌号码、车辆类型、车辆品牌、车身颜色、车龄、负载容量等。所述服务相关时间可以包括服务订单请求时间和/或服务订单执行时间。所述服务订单请求时间可以是服务请求者发出订单请求的时间，所述服务订单执行时间可以是服务提供者开始执行服务订单的时间。所述服务请求者的身份信息可以包括年龄、性别、脸部画像、联系方式、受教育程度、身份证号等。所述订单特征还可以包括预估订单完成时长、预估订单完成时刻、预估服务费用等。在一些实施例中，订单执行过程中的实时状态数据进一步可以包括所述服务订单执行过程中外部环境的实时状态数据、与服务订单相关的定位数据、与服务订单相关的状态数据、与服务订单相关的车辆的状态数据和所述车辆内部的环境数据。所述服务订单执行过程中外部环境的实时状态数据可以包括实时路况、车流量、道路类型、道路事件信息、当前所在位置地点特征等。所述订单执行过程中的状态数据还可以包括终端的用户（例如，服务请求者和/或服务提供者）对于终端的操作内容等所述与服务订单相关的定位数据可以包括与服务参与方相关的终端（例如，服务提供者/服务请求者所使用的终端设备）的定位位置、移动路径等。所述与服务订单相关的状态数据可以包括终端的电量、通信信号强度、传感器工作状态、终端上应用程序的运行状态等。所述与服务订单相关的车辆的状态数据可以包括车辆位置、车辆速度、车辆加速度、车辆姿态、行驶轨迹、运动状态（例如，是否停车不动）等。所述车辆内部环境数据可以包括车内音频数据、车内图像数据等。。在一些实施例中，与所述服务订单中至少一个数据相关的历史记录进一步可以包括服务提供者其他服务订单的记录、服务提供者的征信记录、服务请求者其他服务订单的记录、服务请求者的征信记录、服务提供者其它服务订单的车辆的标识信息、服务提供者其它服务订单的服务相关时间、服务提供者其它服务订单的服务起始点、服务提供者其它服务订单的服务目的地、服务提供者其它服务订单的服务路径、服务请求者其它服务订单的车辆的标识信息、服务请求者其它服务订单的服务相关时间、服务请求者其它服务订单的服务起始点、服务请求者其它服务订单的服务目的地、服务请求者其它服务订单的服务路径、服务请求者其它服务订单的费用以及服务请求者其它服务订单的支付记录等中的一种或多种。所述服务提供者其他服务订单的记录可以包括累计服务完成次数、累计服务取消次数、被投诉次数、被封禁次数、信誉分值、评价等级、历史评价内容等。所述服务请求者其他服务订单的记录可以包括累计服务请求次数、累计服务取消次数、累计服务完成次数、服务费用支付情况、信誉分值、评价等级、历史评价内容等。所述服务提供者/服务请求者的征信记录可以包括与借贷、信用卡消费等相关的信用记录。在一些实施例中，数据获取模块210可以通过与终端120、存储设备130和/或信息源150进行通讯以获取所述服务订单数据。例如，终端120可以通过其上安装的各类传感器实时获取感测数据以及用户对于终端120的操作内容。数据获取模块410可以与终端120进行通信后进行数据获取。又例如，数据获取模块410可以访问读取存储在终端120或存储设备130上的用户特征数据。还例如，数据获取模块410可以与信息源150进行通信以获取外部关联数据。

应当注意的是，所获取的服务订单数据是针对一个特定的时间点而言的。对于同一个交通运输服务订单，数据获取模块410可以持续获取与其相关的实时数据，并且所获取的数据在不同的时间点可以是不同的。同时，数据获取模块410可以将所获取的交通运输服务订单的数据实时传送至处理设备110的其他模块，例如，风险判定模块220，以执行风险判定操作，对订单的所有不同的阶段进行风险监控。

步骤420，对服务订单的相关数据进行处理，对所述服务订单进行风险判定。步骤420可以由风险判定模块320执行。在一些实施例中，所述风险判定可以是对所述服务订单在当前时刻是否存在发生恶性事件和/或异常情况的判定。所述恶性事件和/或异常情况可以包括抢劫、人身安全事件、订单取消异常、行程中停留异常、行程结束后停留异常、位置丢失异常、未送达异常、行程异常、驾驶危险等或其任意组合。在一些实施例中，风险判定模块320可以基于判定规则对所述服务订单进行风险判定。所述判定规则可以是根据历史订单数据和/或经验设定的条件/或阈值。所述历史订单数据可以包括发生过恶性事件和/或异常情况的历史交通运输服务的订单数据。所述历史订单数据种类可以与上述服务订单数据相同或类似，同时还包括了对应于某一交通运输服务订单所发生的具体的恶性事件和/或异常情况类型。在一些实施例中，通过对所述历史订单数据的统计分析，可以确定针对于某一特定的恶性事件和/或异常情况的判定规则。例如，对于发生过抢劫恶性事件的历史订单数据进行统计分析，可以得到服务参与方（比如，乘客）评价低、订单发单时间处于深夜、订单起始点位置偏僻等特征。那么，对于抢劫恶性事件的判定，可以设置评价阈值、发单时间阈值、起始点位置范围阈值等判定规则。在一些实施例中，所述判定规则的阈值设置可以依据数据统计确定。仍然参考上述示例，假定经过统计分析，发生抢劫恶性事件的历史服务订单，发单时间集中在凌晨1点以后。那么发单时间阈值可以被设置为凌晨1点。风险判定模块320可以利用所获取的服务订单的相对应的数据，与所述判定规则进行比较，并将超过阈值的订单判定为风险订单。在一些实施例中，对于每一类恶性事件或异常情况，可以有一个或多个判定规则。风险判定模块320在利用规则进行判定时，可以使用某一单独规则进行判定，也可以使用多个规则的组合进行判定，还可以使用全部的规则进行判定，在本申请中不做具体限定。

在一些实施例中，风险判定模块320可以基于风险判定模型对所述服务订单进行风险判定。所述风险判定模型可以是机器学习模型，包括但不限于分类与逻辑回归（Logistic Regression）模型、k-最近邻算法（K-Nearest Neighbor，kNN）模型、朴素贝叶斯（Naive Bayes，NB）模型、支持向量机（Support Vector Machine，SVM）、决策树（DecisionTree，DT）模型、随机森林（Random Forests，RF）模型、回归树（Classification andRegression Trees，CART）模型、梯度提升决策树（Gradient Boosting Decision Tree，GBDT）模型、xgboost（eXtreme Gradient Boosting）、轻量级梯度提升机器（LightGradient Boosting Machine，LightGBM）、梯度提升机（Gradient Boosting Machines，GBM）、LASSO（Least Absolute Shrinkage and Selection Operator，LASSO）、人工神经网络（Artificial Neural Networks，ANN）模型等。所述风险判定模型可以由所述历史服务订单的相关数据进行训练后得到。仅作为示例，可以以历史服务订单的相关数据作为输入，以对应的具体恶性事件或异常情况的类别作为正确标准（Ground Truth）对模型进行训练。同时可以根据模型的预测输出（例如，预测的风险类别）与正确标准之间的差异反向调整模型参数。当满足某一预设条件时，例如，训练样本数达到预定的数量，模型的预测正确率大于某一预定正确率阈值，或损失函数（Loss Function）的值小于某一预设值，训练过程将停止，并将训练后的模型指定为所述风险判定模型。在一些实施例中，所述风险判定模型可以是针对所有的恶性事件或异常情况类型的判定模型。风险判定模块320可以利用所述风险判定模型处理服务订单以确定是否存在一种或多种类型的恶性事件或异常情况。在一些实施例中，针对每一类恶性事件或异常情况，都可以对应有一个风险判定模型。例如，针对抢劫风险的判定，可以有专门的抢劫判定模型来判定。类似地，其他风险的判定也可以有专门对应的模型来执行。风险判定模块320可以利用多个模型中的组合，来判定一个或以上的风险。模型的组合方式可以根据实际需求确定。例如，在治安较差的区域，可以重点针对抢劫以及人身安全事件进行判定。而在市中心等人流车流密集区域，则可以重点针对行程异常进行判定。关于风险判定规则及风险判定模型的更多内容可以参见图5及其描述，此处不再赘述。

在一些实施例中，对于风险判定模型的训练过程中，所产生的中间结果可以作为判定规则所使用的判定阈值。例如，以训练判定抢劫事件的决策树模型为例，在对根节点进行分叉时选择的发单时间作为最优特征进行分叉。发单时间节点的分叉阈值，在经过多次训练的反复更正后达到的稳定值（即，可以将根节点的数据分为正确的两类）时，该稳定的分叉阈值可以作为判定模型的判定阈值。在一些实施例中，也可以专门训练用于规则判断中特征判断的机器学习模型，协助规则判端。如可以使用大量犯罪嫌疑人的面部特征值及正常人的面部特征值训练一个人脸特征识别模型，以协助风险判定过程中对服务参与人员的面部特征进行处理，获得规则风险判定需要的参与人员面相善或恶识别结果，以进一步进行后续的规则判定。

在一些实施例中，对于服务订单的风险判定的判定结果可以包括有无风险以及对风险的量化表示。仅作为示例，判定结果可以是无风险。或者，判定结果可以是存在风险以及表示风险等级的数值、风险概率等，比如，判定结果是（有风险、抢劫-5级）或（有风险、抢劫-56%、异常停留-87%）。在一些实施例中，风险判定模块320可以综合判定全部风险的等级和/或概率，并输出一个对应于综合风险判定的判定结果，例如，判定结果为（有风险、74%）。应当注意的是，以上描述的判定结果的形式只是为了说明的目的，本申请不对判定结果的形式进行限制。

步骤430，基于风险判定结果，对每一个服务订单执行风险应对操作。步骤430可以由风险应对模块330执行。在一些实施例中，风险应对模块330可以根据步骤420中或得到风险判定结果，执行不同的风险应对操作，可以包括风险排序操作、风险确认操作、风险处置操作、持续监控或其任意组合。

处理设备110需要在同一时刻处理多条服务订单，在待处理订单数量较大的情况下，需要对多条订单进行排序，以保证风险程度较高的订单得到及时处理。在一些实施例中，可以对服务订单的风险判定结果进行排序，具体的，可以基于风险判定结果确定一个或以上风险参数，基于风险参数进行排序。所述风险参数可以是服务订单的相关数据中的某一数据（例如，停留异常风险中的停留时间等特征值，停留时间越长，则越危险），也可以是风险判定结果中的风险类型、风险等级或者风险概率。

在一些实施例中，风险排序操作可以基于排序规则进行。所述排序规则也可以是根据判定结果中针对风险概率和/或等级的大小进行排序。所述排序规则还可以是设置排序结果阈值（例如，等级阈值、概率阈值等），对满足不同阈值的风险判定结果分别进行排序。所述排序规则可以是直接根据所述风险判定结果中所包含的风险概率的大小进行排序。所述排序规则也可以是基于多个风险参数的某种运算结果（如加权均值）的大小进行排序。

在一些实施例中，风险排序操作可以基于排序模型进行。所述排序模型可以是数学统计模型，可以分别基于不同风险种类中的特征值和/或全部风险的特征值通过公式计算（例如，权重计算）得出风险排序结果。所述排序模型还可以是机器学习模型，包括但不限于分类与逻辑回归（Logistic Regression）模型、k-最近邻算法（K-Nearest Neighbor，kNN）模型、朴素贝叶斯（Naive Bayes，NB）模型、支持向量机（Support Vector Machine，SVM）、决策树（Decision Tree，DT）模型、随机森林（Random Forests，RF）模型、回归树（Classification and Regression Trees，CART）模型、梯度提升决策树（GradientBoosting Decision Tree，GBDT）模型、xgboost（eXtreme Gradient Boosting）、轻量级梯度提升机器（Light Gradient Boosting Machine，LightGBM）、梯度提升机（GradientBoosting Machines，GBM）、LASSO（Least Absolute Shrinkage and Selection Operator，LASSO）、人工神经网络（Artificial Neural Networks，ANN）模型等。模型可以基于触发风险的特征数据进行训练后得到。风险应对模块330可以将多个服务订单的风险判定结果输入至训练好的风险排序模型，确定排序结果。在一些实施例中，风险应对模块330可以将风险判定结果为存在风险的多个服务订单的部分或全部相关数据输入至训练好的风险排序模型，确定排序结果。这取决于模型训练的样本数据形式。

在一些实施例中，风险应对模块330可以针对每种类型的风险分别进行排序，得到不同风险类型下的排序结果。在一些实施例中，风险应对模块330可以针对全部风险进行综合排序。例如，可以对不同风险类别分别设置权重，结合权重对不同风险的订单进行综合排序，确定一个全部服务订单的风险排序结果。在一些实施例中，风险应对模块330可以对风险判定结果属于某一风险类型组合的服务订单进行排序。例如，可以对风险判定结果为抢劫和人身安全事件的服务订单进行综合排序。

在一些实施例中，风险应对模块330可以跳过风险排序操作，直接对每个服务订单进行处理，包括风险确认、风险处置和/或持续监控。应当注意的是，针对不同风险判定结果的服务订单，风险应对模型330执行的操作可以不同。例如，针对高风险订单（例如，风险概率大于50%），风险应对模块330可以执行风险处置操作，对用户进行提醒和/或直接报警。又例如，风险应对模型330可以对除高风险订单以外的服务订单先进行风险确认，在确认真的有危险时，立即进行报警和/或救援应对。而对于无风险的服务订单，或经过风险确认后无风险的订单，风险应对模型330可以进行持续监控，以在第一时间发现风险。在一些实施例中，风险应对模型330对于所有的订单的处理方式也可以是相同的。例如，对所有的服务订单先进行风险确认后再执行后续操作，或直接进行处置。

在一些实施例中，风险确认的目的可以是确定服务订单的实际情况，和/或确定是否与经过风险判定操作得到的判定结果一致。在一些实施例中，风险确认操作可以包括通过与用户信息交互进行风险确认、通过工作人员到现场进行风险确认、获取车内音频或图像信息进行风险确认、基于交通系统播报信息确认进行风险确认等或其任意组合。所述用户可以是指服务订单的参与方，包括服务提供者和/或服务请求者。所述通过与用户信息交互进行风险确认可以是通过包括互动式语音应答（Interactive Voice Response，IVR）外呼、终端显示屏弹窗、应用程序文字/语音询问、电话交互等方式确认风险。例如，可以通过IVR外呼让用户在用户终端（例如，终端120）上输入信息，比如，手机号码，以确认用户为安全状态。所述电话交互可以是通过向用户拨打电话进行交流以确认风险。风险应对模块330可以获取电话交互内容，通过语音识别、语义识别、语气识别等方式，确认电话接听人是否为本人、接听人的语气电话交互内容中是否出现危险词等，进行风险确认。例如，可以通过与司机和/或乘客进行电话沟通，以确认司机或乘客是否处于风险中。又例如，可以通过拨打匿名电话（例如，保险推销、楼盘推销、电话购物等）采集司乘语音信息，通过对对方语气（例如，是否愤怒）、背景声、本人声纹识别等方式进行风险确认。还例如，还可以对非风险一方进行电话沟通（例如，在判定乘客有危险时可以考虑对司机进行电话交互）以确认风险。所述通过工作人员到现场进行风险确认可以是基于服务订单的参与方或车辆的位置，通知该位置附近的工作人员前往确认。所述获取车内音频或图像信息进行风险确认可以是通过终端（包括服务提供者终端、服务请求者终端和车载终端等）上安装的传感器（例如，图像传感器、声音传感器等）获取车内音视频后，通过自动或人工的方式确认风险。所述基于交通系统播报信息确认进行风险确认可以是通过交通系统播报信息中的事件发生地点、时间以及事件类型确认待风险确认的服务订单发生风险真实性。在一些实施例中，所述风险确认操作还可以包括通过人工确认。。所述人工风险确认可以是向后台安全确认人员展示需要进行风险确认的服务订单的各种信息，比如，行驶轨迹、车内视频及录音、用户当前位置、用户历史风险数据、历史风险起因等，由安全确认人员确定相关风险信息，例如，车辆在哪里停留过、停留过多次时间、行驶轨迹是否消失、用户之间是否发生肢体和/或语言冲突等。

在一些实施例中，风险处置操作可以包括通知紧急联系人、启动司机端和/或乘客端数据上报、专人跟进报警等或其任意组合。紧急联系人可以是乘客和/或司机在注册和/或使用按需服务过程中（例如，通过乘客和/或司机终端、移动应用程序等）添加的，若自身遇到危险时的第一顺位联系人的联系人信息（例如，手机号码）。例如，可以在用户终端上设置与后端安全平台通信的快速入口（例如，联系紧急联系人按钮、报警按钮、求助按钮）。在判断自身处于危险情况时，用户可以通过点击紧急联系人按钮，终端检测到该按钮被触发后可以自动向紧急联系人发送求助语音或文字信息，信息中可以自动添加终端的当前定位信息。或者用户可以通过该点击报警按钮向警方报警。在报警后，终端还可以将报警的用户的当前位置和行程信息发送至警方以辅助救援。司机端和/或乘客端数据可以是通过司机和/或乘客的移动设备，例如，终端120或移动设备200，上安装的各类传感器获取的音频、视频、图像等数据。处理设备110可以自动获取该数据。用户也可以主动上报该数据。专人跟进报警可以是通过专人（例如，人工客服）跟进的方式进行报警等的处理。在一些实施例中，风险应对模块330还可以对进行过风险确认的服务订单执行风险处置操作。例如，假定某一订单被确认为存在风险，风险应对模块330可以执行报警这一风险处置操作。

在一些实施例中，所述风险处置可以包括风险研判。风险应对模块330可以获取满足风险研判条件的服务订单及其相关的服务订单数据，同时获取服务订单的风险判定结果以及与服务订单的各方面相关的风险信息。风险应对模块330可以向与研判人员相关联的处理设备发送上述数据，并通过与研判人员相关联的处理设备获取人工研判结果。。所述风险研判条件可以包括服务订单的风险判定结果为存在风险、风险等级或风险概率超出研判阈值、服务订单未经过风险确认、服务订单在在先时间经过风险确认后的结果为不存在风险（例如，“暂时安全”或“暂不报警”）但当前时刻被判定为存在风险等。对于满足风险研判条件的服务订单，风险应对模块330可以获取该服务订单的风险判定结果（例如，基于步骤420）以及与服务订单的各方面相关的风险信息，包括用户信息（比如，当前位置、用户被投诉次数等）、车辆位置（比如，所处环境为偏僻地区等）、轨迹数据（比如，路径偏离常用路径、在某一位置停留时间过长等）、车内环境提取信息（比如，录音、视频、通话、影像等）、外部关联信息（比如，车流量等）。在获取上述信息后，风险应对模块330可以向与研判人员相关联的处理设备发送上述数据。所述与研判人员相关联的处理设备在接收到数据后，可以自动地对服务订单进行研判以确定是否发生恶性事件和/或异常情况，或研判人员通过操控所述处理设备以进行判定。在一些实施例中，风险应对模块330可以生成研判工单，并将工单分配给多个与研判人员相关联的处理设备进行研判，以确定研判结果。所述研判工单可以以预设形式（例如，列表）展示在界面中（例如，与研判人员相关联的处理设备的处理界面中），后台安全研判人员可以通过选取或点击列表以查看研判工单中所包含的信息，比如，生成研判工单的服务订单的风险判定结果以及与服务订单的各方面相关的风险信息，并判断是否发生恶性事件和/或异常情况。同时，上述信息还可以以突出显示的形式，例如，字体颜色、粗细的改变。在一些实施例中，风险应对模块330可以首先对满足研判条件的服务订单进行判定，并将判定结果以系统意见的形式连同研判工单一起发送至与研判人员相关联的处理设备以辅助判定。

在一些实施例中，所述风险处置还可以包括风险救援。风险应对模块330可以基于待风险处置的服务订单的相关信息及风险判定结果，生成救援信息。具体的，风险应对模块330可以基于风险判定结果确定服务订单是否满足风险救援条件。风险应对模块330可以将风险判定结果中，风险等级和/或风险概率超过救援阈值，比如，80%、85%、或90%，的服务订单确认为满足风险救援条件。对于满足救援条件的服务订单，风险应对模块330可以基于服务订单的相关信息生成救援信息。例如，风险应对模块330可以基于车辆的位置、车辆信息、判定所发生的风险类型等，生成救援信息，比如，当前位置位于中央公园东门附近，车牌号为京A12345的白色车辆，发生异常停车情况，疑似发生抢劫事件，请您前往查看救援。在生成救援信息后，风险应对模块330将所述救援信息发送至与警方关联的处理设备、与紧急联系人相关联的终端和/或与其他服务提供者相关联的终端。在与警方关联的处理设备发送救援信息时，可以同时向警方报警。在向与紧急联系人相关联的终端发送救援信息时，可以同时发送提醒信息，提醒紧急联系人向警方报警，或在进行查看和/或救援时保证人身安全。所述其他服务提供者包括距离待风险处置的服务订单当前执行地点不超过设定距离阈值的服务提供者。所述当前执行地点可以指当前时刻，所述待风险处置的服务订单的相关方，包括用户、车辆的位置。。在一些实施例中，在发送救援信息的同时，还可以发送补助或奖励信息，提示服务提供者（例如，司机）若前往查看和/或救援，可以获得补助或奖励。在一些实施例中，可以针对不同的风险事件通知不同数量、不同类型的司机。例如，因异常停留事件而通知救援查看的司机个数要远远小于抢劫事件。同时通知前往查看救援抢劫事件的司机可以是年轻的司机。在一些实施例中，可以综合考虑其他司机距离发生风险事件的位置的距离和顺路情况而发送救援信息。

在一些实施例中，所述风险应对过程可以延迟处理。通过对延迟时间内收集用户的安全行为，可以减少给风险处理设备（例如，处理设备110）带来的压力和影响。因为同一时刻处理设备110需要处理多个服务订单，延时处理可以降低处理设备110的负荷，加快订单的处理速度。在一些实施例中，在判定结果为存在风险的服务订单结束后，风险应对模块330可以获取反映与所述服务订单相关联的用户行为的数据，并基于反映与所述服务订单相关联的用户行为的数据，确定所述与所述服务订单相关联的用户是否执行了安全行为。如果与服务订单相关联的用户发生安全行为，则取消服务订单存在风险的判定结果。例如，在步骤420中判定为存在异常停留风险的服务订单，该异常停留风险为一般危险程度（例如，风险等级、风险概率在预设阈值范围内），则可以继续监控该订单，如果在该订单结束后，司机继续正常接单和/或乘客继续正常发单，则可以取消存在异常停留风险的判定，判断该司机和/或乘客安全。在一些实施例中，在延迟阶段还可以对判定为高风险的订单进行验证。例如，可以通过人工验证、自动验证、基于电话交互验证等方法进行验证，例如，引导乘客在乘客终端上确认是否存在安全风险（例如，在APP中发送待应答信息、发起抢红包活动等）、自动拨打服务电话、间接拨打打电话（例如，通过拨打金融服务电话等方式获取相关信息）、联系亲友验证等。

在一些实施例中，用户可以自主判定并上报安全风险。例如，应用程序380的界面中可以包括直接与按需服务平台通信的快速入口（例如，报警按钮、求助按钮），用户可以通过该应用入口上报风险。又例如，用户可以通过对移动设备200执行特定操作，比如按压、摇晃或摔掷。安装在移动设备200中的传感器（例如，声音传感器、图像传感器、压力传感器、速度传感器、加速度传感器、重力传感器、位移传感器、陀螺仪等或其任意组合。）检测到上述特定操作是，可以启动报警程序，上报安全风险。风险应对模块330在接收到上报后，可以判定上报安全风险的准确性（例如，是否存在噪音等）进行风险确认和风险处置。

在一些实施例中，所述风险处置还可以包括持续监控。所述持续监控可以是针对在步骤420中被判定为无风险的服务订单进行，也可以是针对风险排序中处于末尾的部分服务订单，还可以是针对经过风险确认后为无风险的服务订单。在一些实施例中，风险应对模块330可以基于待持续监控的服务订单的相关信息，确定与该服务订单相关联的终端。所述终端可以是服务提供者终端、服务请求者终端、车载终端等。风险应对模块330可以通过所述终端获取反应所述服务订单执行实况的文本、声音和/或图像数据。数据获取可以是通过所述终端上安装的各类传感器实现的。例如，可以通过声音传感器（比如，麦克风）获取音频数据，通过图像传感器（比如，摄像头）获取视频数据。所获取的数据，可用于下一时刻，例如，10s后，的风险判定及处置。

应当注意的是，对于订单的风险判定及应对是一个持续的过程。当一个特定的订单在当前时刻被判定为安全时，或在风险应对操作中（例如，风险确认操作）被确认为安全时，仍然会进行持续监控，并重复进行风险判定及应对以确定后续是否会发生风险事件，例如，每隔一个预设时间（比如，10秒）进行一次风险判定及其后续步骤。直到达到所述特定的订单结束后的阈值时间后，例如，订单结束10分钟后、20分钟后、30分钟后，对于该订单的风险判定及应对过程可以结束。同时，对于步骤420中得到的风险判定结果为无风险的服务订单，风险应对模块330可以对其进行持续监控。

同样的，可以理解，风险应对中的处理操作可以选择性的进行。在一些实施例中，风险应对模块330可以对所有的服务订单基于风险判定结果排序后，按照排序结果选择性的进行后续操作。例如，风险应对模块330可以选择排序中靠前的服务订单执行风险处置操作，对处于中等序位的服务订单执行风险处置操作，对于处于排序靠后的服务订单执行持续监控操作。在一些实施例中，风险应对模块330可以跳过排序步骤，直接对所有服务订单进行风险确认并基于确认结果进行后续处置操作。例如，对于经过风险确认后无风险的服务订单可以持续监控，而对应有风险的订单，可以根据风险大小选择提醒用户（比如车辆的异常停留）或直接报警（比如抢劫）。在一些实施例中，风险应对模块330可以直接基于风险判定结果对所有服务订单进行处置。例如，风险应对模块330可以向风险判定结果为低风险的服务订单的相关联用户发送提醒。对于风险判定结果为高风险的服务订单，风险应对模块330可以直接通知警方。而对于没有风险的服务订单，风险应对模块330可以持续监控以防止在后续有风险发生时能够在最短的时间内发现。在一些实施例中，风险应对模块330可以基于风险判定结果对服务订单进行排序，并基于排序结果直接对服务订单进行处置。例如，风险处置模块330可以首先处理排序靠前的服务订单（例如，风险高的订单），完成后再继续处理排序靠后的订单（例如，风险低的订单）。在一些实施例中，风险处置模块330可以基于风险判定结果，对服务订单进行延时处理。例如，风险处置模块330对于判定结果为存在风险的服务订单进行监控。在其结束后，风险处置模块330可以获取与订单相关的用户的行为数据。若用户出现安全行为，比如，与高风险订单相关的用户在订单结束后继续请求了交通运输服务，则风险处置模块330可以确认该存在风险的服务订单为安全订单。

步骤440，基于风险应对操作结果更新规则和/或模型。步骤440可以由更新模块340执行。在一些实施例中，更新的规则可以包括风险判定规则、风险排序规则等，更新的模型可以包括风险判定模型、风险排序模型等。在一些实施例中，更新模块340可以根据风险确认结果和/或风险处置结果与风险判定结果进行比较，获取其中的差异。并根据所述差异更新判定规则中风险参数值。例如，判定抢劫事件的判定规则可以是根据发单时间及起始地点进行判定，设置为发单时间超过晚上12点、行程终点位于邻近市县则有可能发生抢劫风险。若对于判定具有抢劫风险的订单进行风险确认后，发现发单时间在晚上12点至12点半之间的订单，并未发生抢劫事件。则更新模块可以将判定抢劫时间的判定规则更改为发单时间超过晚上12点半、行程终点位于邻近市县则有可能发生抢劫风险。在一些实施例中，更新模块340可以将风险确认操作和/或风险处置操作中确定为发生风险事件的订单，作为新的样本数据重新对风险判定模型进行训练，以更新模型中的参数。类似的，对于风险排序规则和风险排序模型的训练，更新模块340同样可以根据风险确认结果和/或风险处置结果与风险排序结果进行比较以获取差异并更新。例如，排序中在序位前列的高风险订单在后续风险确认操作中被确定为不存在风险，则更新模块340可以更新排序所使用的风险参数。而对于风险排序模型的更新，更新模块340可以根据风险确认或风险应对得到的实际排序结果的各个订单的特征数据重新训练风险排序模型，以达到更新的目的。在一些实施例中，对于规则和模型的更新可以以预定的间隔进行，例如，一天、一星期、一个月、一个季度等。

需要注意的是，上述描述仅出于说明性目的而提供，并不旨在限制本申请的范围。对于本领域的普通技术人员来说，根据本发明的教导可以做出多种变化和修改。凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。在一些实施例中，在示例性方法400中可以省略一个或多个其他可选操作。例如，对于风险判定结果为风险较高（例如，风险等级、风险概率等高于预设阈值）的服务订单，可以省略风险排序操作以及步风险确认操作，直接进行风险处置操作（例如，报警或转入安全人员研判）。又例如，对于风险判定结果为低风险（例如，风险等级、风险概率等低于预设阈值）的服务订单，可以进行监控等待处理（例如，继续执行数据获取，并在预设时间后后再次执行风险判定）。

图5是根据本申请一些实施例所示的风险判断方法500的示例性流程图。在一些实施例中，方法500中的一个或以上步骤可以在图1所示的系统100中实现。例如，方法500中的一个或以上步骤可以作为指令的形式存储在存储设备110和/或存储器270中，并被处理设备110调用和/或执行。

步骤510，获取与至少一个服务订单中的每一个相关的服务订单数据。步骤510可以由数据获取模块310执行。在一些实施例中，步骤510可以与方法400中的步骤410相同和/或类似，在此不再赘述。

步骤520，基于获取的服务订单数据，对所述服务订单进行风险判定。步骤420可以由风险判定模块320执行。在一些实施例中，所述风险判定可以是对所述服务订单在当前时刻是否存在发生恶性事件和/或异常情况的判定。所述恶性事件和/或异常情况可以包括抢劫、人身安全事件、订单取消异常、行程中停留异常、行程结束后停留异常、位置丢失异常、未送达异常、行程异常、驾驶危险等或其任意组合。在一些实施例中，风险判定模块320可以使用判定规则对服务订单进行风险判定。所述判定规则可以是风险参数阈值。风险判定模块320可以针对不同的恶性事件和/或异常情况，确定不同的风险参数。对于抢劫事件和/或女性安全事件，可以基于司机/乘客特征、订单特征、感测数据等确定判定规则以判定风险。例如，可以基于发单时间是否为深夜、起终点是否偏僻、司机和/或乘客的年龄性别、司机和/或乘客是否有相关历史记录、感测数据中敏感词汇出现次数是否超出预设值等设定判定规则。对于异常取消事件，可以根据司机在行程中（例如，在计费开始且未到达目的地的行程阶段）取消订单后是否长时间内未继续接单或不再接单、订单取消后司机和/或乘客的行为数据（例如，位置、路径等）设定判定规则。对于行程中停留异常，可以基于停留时长、停留环境（时间段、路况、车流量、道路信息、POI信息、周围环境等）、停留点的停留频率（例如，存在多人当前停留点停留）、停留点发单密度等设定判定规则已进行风险判定。对于行程结束后停留异常，可以分为目的地结束后异常以及非目的地结束后异常。对于目的地结束后停留异常，可以基于司机在目的地附近停留时长时间内是否继续接单、司机和/或乘客位置在行程结束地点停留、停留环境（时间段、路况、车流量、道路信息、POI信息、周围环境等）、停留点的停留频率（例如，存在多人当前停留点停留）、停留点发单密度等设定判定规则。对于非目的地（例如，与订单终点的距离超出阈值）结束后停留异常，可以基于司机是否继续接单、司机和/或乘客位置在行程结束地点停留、结束地点信息、行驶时间、预估时间等设定判定规则。对于位置丢失异常，可以基于位置丢失时长、位置丢失环境（例如，丢失点位置、丢失点的路径、是否是高频丢失点）、司机情况（手机电量、是否未及时关单）等设定判定规则。对于未送达异常，可以基于订单结束点是否位于目的地、结束地点信息（例如，POI信息、里程、下车点车流量、距离目的地位置等）、司机行为和/或乘客行为、司机是否继续接单、行驶时间、预估时间等设定判定规则。对于行程异常风险，可以结合上述的一个或以上异常情况，基于路线偏离情况（例如，偏离时间、偏离距离）、是否行驶到偏远地区、行程中停留次数、行驶速度、行驶时间等设定判定规则。对于驾驶危险风险，可以基于传感器数据（例如，速度、加速度等）超出预设阈值设定判定规则，判定车辆是否存在撞车、翻车等驾驶危险。

在一些实施例中，风险判定模块320使用风险判定模型对服务订单进行风险判定。所述风险判定模型可以是机器学习模型，包括但不限于分类与逻辑回归（LogisticRegression）模型、k-最近邻算法（K-Nearest Neighbor，kNN）模型、朴素贝叶斯（NaiveBayes，NB）模型、支持向量机（Support Vector Machine，SVM）、决策树（Decision Tree，DT）模型、随机森林（Random Forests，RF）模型、回归树（Classification and RegressionTrees，CART）模型、梯度提升决策树（Gradient Boosting Decision Tree，GBDT）模型、xgboost（eXtreme Gradient Boosting）、轻量级梯度提升机器（Light Gradient BoostingMachine，LightGBM）、梯度提升机（Gradient Boosting Machines，GBM）、LASSO（LeastAbsolute Shrinkage and Selection Operator，LASSO）、人工神经网络（ArtificialNeural Networks，ANN）模型等。

在一些实施例中，所述风险判定模型可以是针对所有的恶性事件或异常情况类型的判定模型。风险判定模块320可以利用所述风险判定模型处理服务订单以确定是否存在一种或多种类型的恶性事件或异常情况。例如，风险判定模型可以具有分类功能，可以分类处理和/或判定输入数据，以判定不同类型的风险及其相关风险信息（例如，风险等级、风险概率等）。在一些实施例中，针对每一类恶性事件或异常情况，都可以对应有一个风险判定模型。例如，针对抢劫风险的判定，可以有专门的抢劫判定模型来判定。类似地，其他风险的判定也可以有专门对应的模型来执行。

在一些实施例中，所述风险判定模型可以由所述历史订单数据进行训练后得到。仅作为示例，以训练判定抢劫事件的决策树模型为例，简要说明模型构建及训练过程。针对发生过抢劫时间的历史订单的分析结果，可以确定触发事件的多个特征，例如，年龄、性别、发单时间、起终点位置、历史风险记录等。在构建决策树的根节点后，可以选择一个最优特征将训练数据分割成多个子集。继续为每个子集选择新的最优特征，继续进行分割直至得到多个具有明确分类的叶子结点。例如，在根节点时可以选择发单时间（比如，凌晨1点）这一个特征对训练数据进行分割。发单时间早于凌晨1点的训练数据将被分为一类，发单时间晚于凌晨一点的训练数据将被分为另一类。然后可以继续选择起终点位置（比如，终点位于邻近市县）继续分割，直到所有训练数据都被正确的分类。训练至此完成。

在一些实施例中，对于服务订单的风险判定的判定结果可以包括有无风险以及对风险的量化表示。仅作为示例，判定结果可以是无风险。或者，判定结果可以是存在风险以及表示风险等级的数值、风险概率等，比如，判定结果是（有风险、抢劫-5级）或（有风险、抢劫-56%、异常停留-87%）。在一些实施例中，风险判定模块320可以综合判定全部风险的等级和/或概率，并输出一个对应于综合风险判定的判定结果，例如，判定结果为（有风险、74%）。应当注意的是，以上描述的判定结果的形式只是为了说明的目的，本申请不对判定结果的形式进行限制。

需要注意的是，上述描述仅出于说明性目的而提供，并不旨在限制本申请的范围。对于本领域的普通技术人员来说，根据本发明的教导可以做出多种变化和修改。凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。在一些实施例中，在示例性方法400中可以省略一个或多个其他可选操作。

图6是根据本申请的一些实施例所示的系统更新方法600的示例性流程图。在一些实施例中，方法600中的一个或以上步骤可以在图1所示的系统100中实现。例如，方法600中的一个或以上步骤可以作为指令的形式存储在存储设备110和/或存储器270中，并被处理设备110调用和/或执行。

步骤610，获取服务订单的风险应对操作结果。步骤610可以由数据获取模块310执行。在一些实施例中，服务订单的风险应对操作结果可以包括风险排序结果、风险确认结果和/或风险处置结果。所述风险排序结果可以反应服务订单的风险高低程度，比如，若存在的风险高则排序位置高，反之则排序位置低。所述风险确认结果可以反应服务订单的真实情况，比如，是否实际存在风险、存在的风险大小。所述风险处置结果可以反应服务订单最终的处理结果，比如直接进行处置的高风险的服务订单经过警察和/或其他服务提供者的处理或查看后的真实结果。在一些实施例中，获取模块310可以与风险应对模块330进行通信，以获取上述风险应对操作结果。

步骤620，基于所述风险应对操作结果，更新规则和/或模型。步骤620可以由数据更新模块340执行。在一些实施例中，所述规则和/或模型可以包括风险判定规则和/或模型、风险排序规则和/或模型等或其任意组合。在整个风险防范流程中，对于服务订单的风险判定，以及风险排序的准确性，很大程度上影响着后续风险应对操作的处理方式。不准确的风险判定/排序结果会影响整个系统的运力，损失时间精力，甚至造成社会资源的浪费。例如，将一个不存在风险的服务订单判定为存在高风险抢劫事件的服务订单而直接进行报警处置从而造成资源浪费。因此有必要将在风险防范流程中所使用的规则和/模型保持在最佳的状态。

在一些实施例中，更新模块340可以根据风险确认结果和/或风险处置结果与风险判定结果/风险排序结果进行比较，获取其中的差异。并根据所述差异更新判定/排序规则中风险参数和/或风险参数值。例如，判定抢劫事件的判定规则可以是根据发单时间及起始地点进行判定，设置为发单时间超过晚上12点、行程终端位于邻近市县则有可能发生抢劫风险。若对于判定具有抢劫风险的订单进行风险确认后，发现发单时间在晚上12点至12点半之间的订单，并未发生抢劫事件。则更新模块可以将判定抢劫时间的判定规则更改为发单时间超过晚上12点半、行程终端位于邻近市县则有可能发生抢劫风险。又例如，排序中在序位前列的高风险订单在后续风险确认操作或风险处置操作中被确定为不存在风险，则可以更新排序所使用的风险参数或改变风险参数的权重。

在一些实施例中，更新模块340可以将风险确认操作和/或风险处置操作中确定为发生风险事件的订单，作为新的样本数据重新对风险判定模型进行训练，以更新模型中的参数。类似的，更新模块340可以根据风险确认或风险处置得到的实际排序结果的各个订单的特征数据重新训练风险排序模型。在一些实施例中，对于规则和模型的更新可以以预定的间隔进行，例如，一天、一星期、一个月、一个季度等。在一些实施例中，更新模块340可以采用主动推送方式强制系统进行更新。

在一些实施例中，在完成规则和/或模型的更新后，更新模块340可以使用测试集中的数据对规则和/或模型进行检测。所述测试集中的数据包括了已知的服务订单向关联的数据以及已知的对应与服务订单的风险结果，比如有无风险、风险大小、风险类型等。更新模块340可以利用更新后的规则/模型对测试集中的数据进行处理，以确定预测的风险判定结果和预测的风险排序结果。对比已知结果和预测结果，当准确率达到预定的值时，比如98%，可以认为更新完毕。

需要注意的是，上述描述仅出于说明性目的而提供，并不旨在限制本申请的范围。对于本领域的普通技术人员来说，根据本发明的教导可以做出多种变化和修改。凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。在一些实施例中，在示例性方法400中可以省略一个或多个其他可选操作。

本申请实施例可能带来的有益效果包括但不限于：（1）更快的发现存在恶性事件和/或异常情况的订单并及时对用户进行预警。（2）具有更准确的风险事件判定率，能够节省风险判定及处理时间，减少用户受到的伤害。需要说明的是，不同实施例可能产生的有益效果不同，在不同的实施例里，可能产生的有益效果可以是以上任意一种或几种的组合，也可以是其他任何可能获得的有益效果。

上文已对基本概念做了描述，显然，对于本领域技术人员来说，上述详细披露仅仅作为示例，而并不构成对本申请的限定。虽然此处并没有明确说明，本领域技术人员可能会对本申请进行各种修改、改进和修正。该类修改、改进和修正在本申请中被建议，所以该类修改、改进、修正仍属于本申请示范实施例的精神和范围。

同时，本申请使用了特定词语来描述本申请的实施例。如“一个实施例”、“一实施例”、和/或“一些实施例”意指与本申请至少一个实施例相关的某一特征、结构或特点。因此，应强调并注意的是，本说明书中在不同位置两次或多次提及的“一实施例”或“一个实施例”或“一替代性实施例”并不一定是指同一实施例。此外，本申请的一个或多个实施例中的某些特征、结构或特点可以进行适当的组合。

此外，本领域技术人员可以理解，本申请的各方面可以通过若干具有可专利性的种类或情况进行说明和描述，包括任何新的和有用的工序、机器、产品或物质的组合，或对他们的任何新的和有用的改进。相应地，本申请的各个方面可以完全由硬件执行、可以完全由软件（包括固件、常驻软件、微码等）执行、也可以由硬件和软件组合执行。以上硬件或软件均可被称为“数据块”、“模块”、“引擎”、“单元”、“组件”或“系统”。此外，本申请的各方面可能表现为位于一个或多个计算机可读介质中的计算机产品，该产品包括计算机可读程序编码。

计算机存储介质可能包含一个内含有计算机程序编码的传播数据信号，例如在基带上或作为载波的一部分。该传播信号可能有多种表现形式，包括电磁形式、光形式等，或合适的组合形式。计算机存储介质可以是除计算机可读存储介质之外的任何计算机可读介质，该介质可以通过连接至一个指令执行系统、装置或设备以实现通讯、传播或传输供使用的程序。位于计算机存储介质上的程序编码可以通过任何合适的介质进行传播，包括无线电、电缆、光纤电缆、RF、或类似介质，或任何上述介质的组合。

本申请各部分操作所需的计算机程序编码可以用任意一种或多种程序语言编写，包括面向对象编程语言如Java、Scala、Smalltalk、Eiffel、JADE、Emerald、C++、C#、VB.NET、Python等，常规程序化编程语言如C语言、Visual Basic、Fortran 2003、Perl、COBOL 2002、PHP、ABAP，动态编程语言如Python、Ruby和Groovy，或其他编程语言等。该程序编码可以完全在用户计算机上运行、或作为独立的软件包在用户计算机上运行、或部分在用户计算机上运行部分在远程计算机运行、或完全在远程计算机或服务器上运行。在后种情况下，远程计算机可以通过任何网络形式与用户计算机连接，比如局域网（LAN）或广域网（WAN），或连接至外部计算机（例如通过因特网），或在云计算环境中，或作为服务使用如软件即服务（SaaS）。

此外，除非权利要求中明确说明，本申请所述处理元素和序列的顺序、数字字母的使用、或其他名称的使用，并非用于限定本申请流程和方法的顺序。尽管上述披露中通过各种示例讨论了一些目前认为有用的实施例，但应当理解的是，该类细节仅起到说明的目的，附加的权利要求并不仅限于披露的实施例，相反，权利要求旨在覆盖所有符合本申请实施例实质和范围的修正和等价组合。例如，虽然以上所描述的系统组件可以通过硬件设备实现，但是也可以只通过软件的解决方案得以实现，如在现有的服务器或移动设备上安装所描述的系统。

同理，应当注意的是，为了简化本申请披露的表述，从而帮助对一个或多个实施例的理解，前文对本申请实施例的描述中，有时会将多种特征归并至一个实施例、附图或对其的描述中。但是，这种披露方法并不意味着本申请对象所需要的特征比权利要求中提及的特征多。实际上，实施例的特征要少于上述披露的单个实施例的全部特征。

Claims (32)

1.一种风险防范方法，所述方法由至少一个处理器执行，其特征在于，所述方法包括：

获取至少一个服务订单的相关数据；所述服务订单的相关数据至少包括以下的两种：所述服务订单特征、所述服务订单执行过程中的实时状态数据、与所述服务订单中至少一个数据相关的历史记录；

至少基于预设的风险判定规则，通过经训练的风险判断模型对所述服务订单的相关数据进行处理以确定所述服务订单的风险判定结果，所述风险判断模型包括多个，其中每一个都针对于某一种具体的风险事件；

基于所述风险判定结果，对所述服务订单执行风险应对操作；所述风险应对操作包括风险排序操作，以及风险确认操作、风险处置操作和持续监控操作中的至少一种；所述风险应对操作包括至少基于所述风险排序操作的结果选择部分服务订单进行以下操作中的至少一种：风险确认操作、风险处置操作和持续监控操作；所述风险确认操作至少包括通过与用户信息交互进行风险确认，其中，所述用户为服务提供者或服务请求者，所述与用户信息交互进行风险确认至少包括通过向所述用户拨打电话进行交流以确认风险；所述风险处置操作至少包括通过在用户终端上设置的与后端安全平台通信的快速入口通知紧急联系人和/或报警求助；当所述风险判定结果为所述服务订单存在风险时，所述方法进一步包括：

在所述风险判定结果为存在风险的所述服务订单结束后，获取反映与所述服务订单相关联的用户行为的数据；

基于反映与所述服务订单相关联的用户行为的数据，确定所述与所述服务订单相关联的用户是否执行了安全行为；

响应于与所述服务订单相关联的用户执行了安全行为，取消所述服务订单存在风险的判定结果；以及

基于所述风险应对操作结果，更新所述风险判定规则和/或风险判定模型。

2.根据权利要求1所述的方法，其特征在于，所述服务订单特征包括以下中的至少两个：服务提供者的身份信息、与服务订单相关的车辆的标识信息、服务相关时间、服务起始点、服务目的地、服务路径、服务请求者的身份信息以及服务的预计费用。

3.根据权利要求1所述的方法，其特征在于，所述服务订单执行过程中的实时状态数据包括以下中的至少一个：所述服务订单执行过程中外部环境的实时状态数据、与所述服务订单相关的定位数据、与所述服务订单相关的终端的状态数据、与所述服务订单相关的车辆的状态数据和所述车辆内部的环境数据。

4.根据权利要求1所述的方法，其特征在于，所述服务订单中至少一个数据相关的历史记录包括以下中的至少三个：服务提供者其它服务订单的记录、服务提供者的征信记录、服务请求者其它服务订单的记录、服务请求者的征信记录、服务提供者其它服务订单的车辆的标识信息、服务提供者其它服务订单的服务相关时间、服务提供者其它服务订单的服务起始点、服务提供者其它服务订单的服务目的地、服务提供者其它服务订单的服务路径、服务请求者其它服务订单的车辆的标识信息、服务请求者其它服务订单的服务相关时间、服务请求者其它服务订单的服务起始点、服务请求者其它服务订单的服务目的地、服务请求者其它服务订单的服务路径、服务请求者其它服务订单的费用以及服务请求者其它服务订单的支付记录。

5.根据权利要求1所述的方法，其特征在于，所述风险判断模型通过利用历史服务订单的相关数据训练初始的机器学习模型获得；所述历史服务订单包括发生历史事件的服务订单。

6.根据权利要求1所述的方法，其特征在于，所述风险判定规则包括判断阈值，所述判断阈值通过利用历史服务订单的相关数据训练机器学习模型获得。

7.根据权利要求1所述的方法，其特征在于，所述风险应对操作包括至少基于风险确认操作的结果选择部分服务订单进行以下操作中的一种：风险处置操作和持续监控操作。

8.根据权利要求1所述的方法，其特征在于，所述持续监控操作至少基于风险处置操作的结果选择部分服务订单进行持续监控。

9.根据权利要求1所述的方法，其特征在于，所述风险排序操作包括：

基于所述风险判定结果，确定至少一个风险参数；

基于所述至少一个风险参数，对所述至少一个服务订单进行风险等级排序。

10.根据权利要求9所述的方法，其特征在于，所述基于所述至少一个风险参数，对所述至少一个服务订单进行风险等级排序包括：

将至少一个服务订单对应的至少一个风险参数输入至经训练的风险排序模型，确定所述至少一个服务订单的风险等级排序结果，其中，所述风险排序模型为机器学习模型。

11.根据权利要求1所述的方法，其特征在于，所述风险确认操作还包括以下至少一种：

通过工作人员到现场进行风险确认、获取车内音频或图像信息进行风险确认、基于交通系统播报信息确认进行风险确认。

12.根据权利要求1所述的方法，其特征在于，所述风险处置操进一步包括：

基于待风险处置的服务订单的相关信息及风险判定结果，生成救援信息；

将所述救援信息发送至与警方关联的处理设备、与所述紧急联系人相关联的终端和/或与其他服务提供者相关联的终端；所述其他服务提供者包括距离待风险处置的服务订单当前执行地点不超过设定距离阈值的服务提供者。

13.根据权利要求1所述的方法，其特征在于，所述风险处置操作还包括风险研判，所述风险研判包括：

获取待风险研判的服务订单、所述服务订单的相关数据以及所述服务订单的风险判定结果；

向与研判人员相关联的处理设备发送待风险研判的服务订单、所述服务订单的相关数据以及所述服务订单的风险判定结果；

通过与研判人员相关联的处理设备获取人工研判结果。

14.根据权利要求1所述的方法，其特征在于，所述持续监控操进一步包括：

基于待持续监控的服务订单的相关信息，确定与该服务订单相关联的终端；

通过所述终端获取反应所述服务订单执行实况的文本、声音和/或图像数据；

所述终端包括服务提供者终端、服务请求者终端和/或车载终端。

15.根据权利要求10所述的方法，其特征在于，所述方法进一步包括：

基于所述风险应对操作结果，更新所述风险参数和/或风险排序模型。

16.一种风险防范系统，其特征在于，所述系统包括数据获取模块、风险判定模块、风险应对模块和更新模块，

所述数据获取模块，用于获取至少一个服务订单的相关数据；所述服务订单的相关数据至少包括以下的两种：所述服务订单特征、所述服务订单执行过程中的实时状态数据、与所述服务订单中至少一个数据相关的历史记录；

所述风险判定模块，用于至少基于预设的风险判定规则，通过经训练的风险判断模型对所述服务订单的相关数据进行处理以确定所述服务订单的风险判定结果，所述风险判断模型包括多个，其中每一个都针对于某一种具体的风险事件；

所述风险应对模块，用于基于所述风险判定结果，对所述服务订单执行风险应对操作；所述风险应对模块包括风险排序单元，以及风险确认单元、风险处置单元和持续监控单元中的至少一种；所述风险排序单元用于执行风险排序操作，所述风险确认单元用于执行风险确认操作，所述风险处置单元用于执行风险处置操作，所述持续监控单元用于执行持续监控操作；其中，

所述风险确认单元用于至少基于风险排序单元执行的风险排序操作的结果选择部分服务订单进行风险确认操作；所述风险确认操作至少包括通过与用户信息交互进行风险确认，其中，所述用户为服务提供者或服务请求者，所述与用户信息交互进行风险确认至少包括通过向所述用户拨打电话进行交流以确认风险；

或者，所述风险处置单元，用于至少基于风险排序单元执行的风险排序操作的结果选择部分服务订单进行风险处置操作，所述风险处置操作至少包括通过在用户终端上设置的与后端安全平台通信的快速入口通知紧急联系人和/或报警求助；

或者，所述持续监控单元，用于至少基于风险排序单元执行的风险排序操作的结果选择部分服务订单进行持续监控操作；

当所述风险判定结果为所述服务订单存在风险时，所述风险应对模块还用于：

在所述风险判定结果为存在风险的所述服务订单结束后，获取反映与所述服务订单相关联的用户行为的数据；

基于反映与所述服务订单相关联的用户行为的数据，确定所述与所述服务订单相关联的用户是否执行了安全行为；

响应于与所述服务订单相关联的用户执行了安全行为，取消所述服务订单存在风险的判定结果；

所述更新模块用于基于所述风险应对操作结果，更新所述风险判定规则和/或风险判定模型。

17.根据权利要求16所述的系统，其特征在于，所述服务订单特征包括以下中的至少两个：服务提供者的身份信息、与服务订单相关的车辆的标识信息、服务相关时间、服务起始点、服务目的地、服务路径、服务请求者的身份信息以及服务的预计费用。

18.根据权利要求16所述的系统，其特征在于，所述服务订单执行过程中的实时状态数据包括以下中的至少一个：所述服务订单执行过程中外部环境的实时状态数据、与所述服务订单相关的定位数据、与所述服务订单相关的终端的状态数据、与所述服务订单相关的车辆的状态数据和所述车辆内部的环境数据。

19.根据权利要求16所述的系统，其特征在于，所述服务订单中至少一个数据相关的历史记录包括以下中的至少三个：服务提供者其它服务订单的记录、服务提供者的征信记录、服务请求者其它服务订单的记录、服务请求者的征信记录、服务提供者其它服务订单的车辆的标识信息、服务提供者其它服务订单的服务相关时间、服务提供者其它服务订单的服务起始点、服务提供者其它服务订单的服务目的地、服务提供者其它服务订单的服务路径、服务请求者其它服务订单的车辆的标识信息、服务请求者其它服务订单的服务相关时间、服务请求者其它服务订单的服务起始点、服务请求者其它服务订单的服务目的地、服务请求者其它服务订单的服务路径、服务请求者其它服务订单的费用以及服务请求者其它服务订单的支付记录。

20.根据权利要求16所述的系统，其特征在于，所述风险判断模型通过利用历史服务订单的相关数据训练初始的机器学习模型获得；所述历史服务订单包括发生历史事件的服务订单。

21.根据权利要求16所述的系统，其特征在于，所述风险判定规则包括判断阈值，所述判断阈值通过利用历史服务订单的相关数据训练机器学习模型获得。

22.根据权利要求16所述的系统，其特征在于，所述风险处置单元，用于至少基于风险确认单元执行的风险确认操作的结果选择部分服务订单进行风险处置操作；

或者，所述持续监控单元，用于至少基于风险确认单元执行的风险确认操作的结果选择部分服务订单进行持续监控操作。

23.根据权利要求16所述的系统，其特征在于，所述持续监控单元，用于至少基于风险处置单元执行的风险处置操作的结果选择部分服务订单进行持续监控操作。

24.根据权利要求16所述的系统，其特征在于，所述风险排序单元用于：

基于所述风险判定结果，确定至少一个风险参数；

基于所述至少一个风险参数，对所述至少一个服务订单进行风险等级排序。

25.根据权利要求24所述的系统，其特征在于，所述风险排序单元进一步用于：

将至少一个服务订单对应的至少一个风险参数输入至经训练的风险排序模型，确定所述至少一个服务订单的风险等级排序结果，其中，所述风险排序模型为机器学习模型。

26.根据权利要求16所述的系统，其特征在于，所述风险确认单元还用于执行包括以下至少一种操作：

通过工作人员到现场进行风险确认、获取车内音频或图像信息进行风险确认、基于交通系统播报信息确认进行风险确认。

27.根据权利要求16所述的系统，其特征在于，所述风险处置单元用于：

基于待风险处置的服务订单的相关信息及风险判定结果，生成救援信息；

将所述救援信息发送至与警方关联的处理设备、与所述紧急联系人相关联的终端和/或与其他服务提供者相关联的终端；所述其他服务提供者包括距离待风险处置的服务订单当前执行地点不超过设定距离阈值的服务提供者。

28.根据权利要求16所述的系统，其特征在于，所述风险处置单元进一步用于：

获取待风险研判的服务订单、所述服务订单的相关数据以及所述服务订单的风险判定结果；

向与研判人员相关联的处理设备发送待风险研判的服务订单、所述服务订单的相关数据以及所述服务订单的风险判定结果；

通过与研判人员相关联的处理设备获取人工研判结果。

29.根据权利要求16所述的系统，其特征在于，所述持续监控单元用于：

基于待持续监控的服务订单的相关信息，确定与该服务订单相关联的终端；

通过所述终端获取反应所述服务订单执行实况的文本、声音和/或图像数据。

30.根据权利要求25所述的系统，其特征在于，所述系统进一步包括更新模块，所述更新模块用于基于所述风险应对操作结果，更新所述风险参数和/或风险排序模型。

31.一种风险防范装置，所述装置包括处理器以及存储器；所述存储器用于存储指令，所述指令被所述处理器执行时，导致所述装置实现如权利要求1至15中任一项所述风险防范方法对应的操作。

32.一种计算机可读存储介质，其特征在于所述存储介质存储计算机指令，当计算机读取存储介质中的计算机指令后，计算机运行如权利要求1至15中任意一项所述风险防范方法。