CN111275507A - 一种订单异常识别和订单风险管控的方法及其*** - Google Patents

一种订单异常识别和订单风险管控的方法及其*** Download PDF

Info

Publication number
CN111275507A
CN111275507A CN201811471339.4A CN201811471339A CN111275507A CN 111275507 A CN111275507 A CN 111275507A CN 201811471339 A CN201811471339 A CN 201811471339A CN 111275507 A CN111275507 A CN 111275507A
Authority
CN
China
Prior art keywords
order
service
service provider
service requester
model
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN201811471339.4A
Other languages
English (en)
Inventor
韩福波
张谷超
韩戈阳
刘亚书
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Beijing Didi Infinity Technology and Development Co Ltd
Original Assignee
Beijing Didi Infinity Technology and Development Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Beijing Didi Infinity Technology and Development Co Ltd filed Critical Beijing Didi Infinity Technology and Development Co Ltd
Priority to CN201811471339.4A priority Critical patent/CN111275507A/zh
Publication of CN111275507A publication Critical patent/CN111275507A/zh
Pending legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00Commerce
    • G06Q30/06Buying, selling or leasing transactions
    • G06Q30/0601Electronic shopping [e-shopping]
    • G06Q30/0633Lists, e.g. purchase orders, compilation or processing
    • G06Q30/0635Processing of requisition or of purchase orders
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q50/00Information and communication technology [ICT] specially adapted for implementation of business processes of specific business sectors, e.g. utilities or tourism
    • G06Q50/10Services
    • G06Q50/26Government or public services
    • G06Q50/265Personal security, identity or safety

Landscapes

  • Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • Marketing (AREA)
  • Theoretical Computer Science (AREA)
  • Economics (AREA)
  • Finance (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Accounting & Taxation (AREA)
  • Development Economics (AREA)
  • Tourism & Hospitality (AREA)
  • Educational Administration (AREA)
  • Computer Security & Cryptography (AREA)
  • Health & Medical Sciences (AREA)
  • General Health & Medical Sciences (AREA)
  • Human Resources & Organizations (AREA)
  • Primary Health Care (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

本申请实施例公开了一种订单异常识别和订单风险管控的方法及其***。其中,订单异常识别方法包括:获取待测订单;获取与待测订单相关的特征参数;利用第一订单异常识别模型处理特征参数中的至少一部分,获得第一识别结果;利用第二订单异常识别模型处理特征参数中的至少一部分,获得第二识别结果;联合第一识别结果及所述第二识别结果确定待测订单的异常识别结果。订单风险管控方法包括:获取服务请求者的服务请求;基于服务请求生成服务订单并发送给服务器;接收服务器发送的对服务订单的异常识别结果或者与异常识别结果相关的风险管控指示。本申请可以防止在线服务平台的中的恶性事件的发生,保证人们的生命和财产的安全。

Description

一种订单异常识别和订单风险管控的方法及其***
技术领域
本申请涉及互联网技术领域,更具体的,涉及一种订单异常识别和订单风险管控的方法、***、装置及存储介质。
背景技术
目前,在线服务平台的发展越来越迅速。出现了包括网约车服务、外卖服务、家政服务等各种在线服务的平台。这些在线服务平台给人们的生活带来便捷的同时,也出现了一些利用平台对他人的生命和财产进行伤害的恶性事件。以网约车服务为例,出现了司机借机伤害乘客或是乘客伤害司机生命的恶性事件。为保证人们的安全,并保证在线服务平台能够健康的发展,需要防止恶性事件的发生。因此,需要一种方法来识别出潜在的服务订单中的异常,并对订单进行管控,以达到预防恶性事件发生的目的。
发明内容
本申请提供一种订单异常的识别方法以及对订单的风险管控的方法,以防止在线服务平台的中的恶性事件的发生,保证人们的生命和财产的安全。
为了达到上述发明的目的,本发明提供的技术方案如下:一种订单异常识别方法,包括:获取待测订单;获取与所述待测订单相关的特征参数;利用第一订单异常识别模型处理所述特征参数中的至少一部分,获得第一识别结果;利用第二订单异常识别模型处理所述特征参数中的至少一部分,获得第二识别结果;联合所述第一识别结果及所述第二识别结果确定所述待测订单的异常识别结果;其中,与所述待测订单相关的特征参数至少反映以下多种信息中的至少一个:服务时间、服务地点、服务请求者或服务提供者在平台上的操作行为、服务请求者或服务提供者的个人信息或服务请求者者对服务的订制要求。
一种订单异常识别***,包括:第一获取模块,包括待测订单获取单元和特征参数获取单元;所述待测订单获取单元用于获取待测订单,所述特征参数获取单元用于获取与所述待测订单相关的特征参数;订单异常识别模块,用于利用第一订单异常识别模型处理所述特征参数中的至少一部分,获得第一识别结果;利用第二订单异常识别模型处理所述特征参数中的至少一部分,获得第二识别结果;联合所述第一识别结果及所述第二识别结果确定所述待测订单的异常识别结果;其中,与所述待测订单相关的特征参数至少反映以下多种信息中的至少一个:服务时间、服务地点、服务请求者或服务提供者在平台上的操作行为、服务请求者或服务提供者的个人信息或服务请求者对服务的订制要求。
一种订单异常识别装置,其特征在于,包括至少一个处理器以及至少一个存储器;所述至少一个存储器用于存储指令;所述处理器用于执行所述指令,实现如前所述方法。
一种计算机可读存储介质,其特征在于,所述存储介质存储计算机指令,当计算机读取存储介质中的计算机指令后,计算机运行如前所述方法。
一种订单风险管控方法,包括:获取服务请求者的服务请求;所述服务请求至少包括服务时间与服务地点;基于所述服务请求生成服务订单并发送给服务器;接收服务器发送的对所述服务订单的异常识别结果或者与所述异常识别结果相关的风险管控指示。
一种订单风险管控***,包括:第二获取模块,用于获取服务请求者的服务请求;所述服务请求至少包括服务时间与服务地点;服务订单生成模块,用于基于所述服务请求生成服务订单并发送给服务器;风险管控接收模块,用于接收服务器发送的对所述服务订单的异常识别结果或者与所述异常识别结果相关的风险管控指示。
一种订单风险管控装置,包括至少一个处理器以及至少一个存储器;所述至少一个存储器用于存储指令;所述处理器用于执行所述指令,实现如前所述方法。
一种计算机可读存储介质,其特征在于,所述存储介质存储计算机指令,当计算机读取存储介质中的计算机指令后,计算机运行如前所述方法。
附图说明
本申请将以示例性实施例的方式进一步说明,这些示例性实施例将通过附图进行详细描述。这些实施例并非限制性的,在这些实施例中,相同的编号表示相同的结构,其中:
图1是根据本申请一些实施例所示的一个示例性订单异常识别***的示意图;
图2是根据本发明的一些实施例所示的一个示例性计算设备的示例性硬件组件和/或软件组件的示意图;
图3是根据本发明的一些实施例所示的一个示例性移动设备的示例性硬件组件和/或软件组件的示意图;
图4是根据本发明的一些实施例所示的一个订单异常识别***的框图;
图5根据本发明的一些实施例所示的一个订单风险管控***的框图;
图6是根据本发明的一些实施例所示的订单异常识别方法的示例性流程图;
图7是根据本发明的一些实施例所示的确定第一订单异常识别模型的示例性流程图;
图8是根据本发明的一些实施例所示的确定第二订单异常识别模型的示例性流程图;
图9是根据本发明的一些实施例所示的订单风险管控的示例性流程图。
具体实施方式
为了更清楚地说明本申请的实施例的技术方案,下面将对实施例描述中所需要使用的附图作简单的介绍。显而易见地,下面描述中的附图仅仅是本申请的一些示例或实施例,对于本领域的普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图将本申请应用于其他类似情景。除非从语言环境中显而易见或另做说明,图中相同标号代表相同结构或操作。
如本申请和权利要求书中所示,除非上下文明确提示例外情形,
“一”、“一个”、“一种”和/或“该”等词并非特指单数,也可包括复数。一般说来,术语“包括”与“包含”仅提示包括已明确标识的步骤和元素,而这些步骤和元素不构成一个排它性的罗列,方法或者设备也可能包含其他的步骤或元素。术语“基于”是“至少部分地基于”。术语“一个实施例”表示“至少一个实施例”;术语“另一实施例”表示“至少一个另外的实施例”。其他术语的相关定义将在下文描述中给出。
本申请的实施例可以应用于不同的交通***和/或移动设备,不同的交通***包括但不限于陆地、水面航行、航空、航天等中的一种或几种的组合。例如,人力车、代步工具、汽车(例如,小型车、巴士、大型运输车等)、轨道交通(例如,火车、动车、高铁、地铁等)、船舶、飞机、飞船、卫星、热气球、无人驾驶的交通工具等。不同的移动终端包括但不限于智能手机、智能手表、摄像机、照相机、笔记本、平板电脑、个人数码助理(PDA)、车载电脑等移动设备。本申请的不同实施例应用场景包括但不限于运输业、仓储物流业、农业作业***、城市公交***、商业运营车辆等中的一种或几种的组合。应当理解的是,本申请的***及方法的应用场景仅仅是本申请的一些示例或实施例,对于本领域的普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图将本申请应用于其他类似情景。
图1是根据本发明的一些实施例所示的一种订单异常识别***100的示意图。例如,订单异常识别***100可以是用于多种服务的线上服务平台。在一些实施例中,该订单异常识别***100可以用于识别网约车服务中的异常,例如,识别出租车订单的异常、识别快车订单的异常、识别专车订单的异常、识别小巴订单的异常、拼车订单的异常、识别公交服务中的异常、和识别接送服务过程中的异常等。在一些实施例中,该订单异常识别***100还可以用于家政服务、快递、外卖等。例如,识别清洁服务订单的异常或其他家政服务订单的异常、识别上门寄件订单或上门收件订单的异常、识别外卖订单的异常等。订单异常识别***100可以包括一个服务器110、一个或一个以上服务请求者终端120、存储设备130、一个或一个以上服务提供者终端140、网络150和信息源160。服务器110可以包括处理引擎112。
在一些实施例中,服务器110可以是一个单个的服务器或者一个服务器群组。所述服务器群可以是集中式的或分布式的(例如,服务器110可以是一个分布式的***)。在一些实施例中,服务器110可以是本地的或远程的。例如,服务器110可以通过网络150访问存储在存储设备130、服务请求者终端120中的信息和/或数据。再例如,服务器110可以直接连接到存储设备130、服务请求者终端120以访问存储的信息和/或数据。在一些实施例中,服务器110可以在一个云平台上实现。仅仅举个例子,所述云平台可以包括私有云、公共云、混合云、社区云、分布云、云之间、多重云等或上述举例的任意组合。在一些实施例中,服务器110可以在与本申请图2或图3所示的计算设备上实现。例如,服务器110可以在如图2所示的一个计算设备200上实现,包括计算设备200中的一个或多个部件。再例如,服务器110可以在如图3所示的一个移动设备300上实现,包括计算设备300中的一个或多个部件。在一些实施例中,处理引擎112可处理与服务请求有关的数据和/或信息以执行一个或多个本申请中描述的功能。以网约车服务为例,处理引擎112可基于从服务请求者终端130获取的网约车订单请求,为该网约车订单匹配一个服务车辆,或者处理引擎112可基于从服务请求者终端120获取的网约车订单请求,识别网约车订单请求的异常。在一些实施例中,处理引擎112可以对订单异常进行特别处理。例如,针对订单异常,处理引擎112可以确定并向服务请求者终端120和/或服务提供者终端140发出提示信息。又例如,针对订单异常,处理引擎112可以向平台工作人员发出警报,平台工作人员对订单异常进行人工处理(如取消该订单、与服务请求者/提供者联系、跟踪该订单、报警等);或者,处理引擎112可以自动向第三方机构(如公安部门、服务请求者/提供者的紧急联系人等)报警。再例如,处理引擎112可以自动取消订单异常,不进行派单。
在一些实施例中,服务请求者终端120的使用者可以是服务请求者本人。在一些实施例中,服务请求者终端120的使用者可以是除服务请求者以外的其他人。例如,在网约车服务中,服务请求者终端120的使用者可以是乘车人本人,也可以是乘车人的亲戚、朋友等帮乘车人下单的人。又例如,在外卖服务中,服务请求者终端120的使用者可以是外卖送达的目标对象,也可以是帮助目标对象点外卖的人。再例如,在家政服务中,服务请求者终端120的使用者可以是家政服务的实际需求人,也可以是帮助该需求人购买家政服务的人。
在一些实施例中,服务提供者终端140的使用者可以是服务提供者本人。在一些实施例中,服务提供者终端140的使用者可以是除服务提供者以外的其他人。例如,在网约车服务中,服务提供者终端140的使用者可以是司机本人,也可以是帮助司机接单的人。又例如,在外卖服务中,服务提供者终端140的使用者可以是外卖派送员本人,也可以是帮助派送员接单的人。再例如,在家政服务中,服务提供者终端140的使用者可以是家政服务的实际服务人员(如维修员、清洁员等),也可以是帮助服务人员接单的人。
在一些实施例中,服务请求者终端120可以包括但不限于台式电脑120-1、笔记本电脑120-2,车载内置设备120-3、移动设备120-4等或其任意组合。在一些实施例中,车载内置设备120-3可以包括但不限于个车载电脑、车载抬头显示(HUD)、车载自动诊断***(OBD)等或其任意组合。在一些实施例中,移动设备120-4可以包括但不限于智能手机、个人数码助理(Personal Digital Assistance,PDA)、平板电脑、掌上游戏机、智能眼镜、智能手表、可穿戴设备、虚拟显示设备、显示增强设备等或其任意组合。在一些实施例中,服务请求者终端120可以将运输服务需求发送至订单异常识别***100中的一个或多个设备中。例如,服务请求者终端120可以将运输服务需求发送至服务器110进行处理。
在一些实施例中,服务提供者终端140可以是与服务请求者终端130类似或相同的装置。在一些实施例中,服务提供者终端140可以是一带有定位技术的装置,以确定服务提供者和/或服务提供者终端140的位置。在一些实施例中,服务请求者终端120和/或服务提供者终端140可与其他定位装置通讯以确定服务请求者、服务请求者终端120、服务提供者、或服务提供者终端140的位置。在一些实施例中,服务请求者终端120和/或服务提供者终端140可将定位信息发送至服务器110。
存储设备130可以存储数据和/或指令。在一些实施例中,存储设备130可以存储从数据采集端获得的数据。在一些实施例中,存储设备130可以存储供服务器110执行或使用的数据和/或指令,服务器110可以通过执行或使用所述数据和/或指令以实现本申请描述的示例性方法。在一些实施例中,存储设备130可以与网络150连接以实现与订单异常识别***100中的一个或多个部件(例如,服务器110、服务请求者终端120等)之间的通信。订单异常识别***100的一个或多个部件可以通过网络150访问存储在存储设备130中的数据或指令。在一些实施例中,存储设备130可以直接与订单异常识别***100的一个或多个部件(例如,服务器110、服务请求者终端120等)连接或通信。在一些实施例中,存储设备130可以是服务器110的一部分。
网络150可以促进信息和/或数据的交换。在一些实施例中,订单异常识别***100中的一个或多个部件(例如,服务器110、存储设备130、和服务请求者终端120等)可以通过网络150向订单异常识别***100中的其他部件发送信息和/或数据。例如,服务器110可以通过网络150从服务请求者终端120获取/得到数据信息。在一些实施例中,网络150可以是有线网络或无线网络中的任意一种,或其组合。例如,网络150可以包括电缆网络、有线网络、光纤网络、远程通信网络、内联网、互联网、局域网(LAN)、广域网(WAN)、无线局域网(WLAN)、城域网(MAN)、公共开关电话网络(PSTN)、蓝牙网络、ZigBee网络、近场通讯(NFC)网络等或上述举例的任意组合。在一些实施例中,网络150可以包括一个或多个网络接入点。例如,网络150可能包括有线或无线网络接入点,如基站和/或互联网交换点150-1、150-2等等。通过接入点,订单异常识别***100的一个或多个部件可能连接到网络150以交换数据和/或信息。
信息源160是为订单异常识别***100提供其他信息的一个源。信息源160可以用于为***提供与订单信息相关的信息,例如,服务时间、服务地点、法律法规信息、新闻信息、生活资讯、生活指南信息等。信息源160可以是一个单独的中央服务器的形式存在,也可以是以多个通过网络连接的服务器的形式存在,还可以是以大量的个人设备形式存在。当信息源160以大量个人设备形式存在时,这些设备可以通过一种用户生成内容(user-generated contents)的方式,例如向云端服务器上传文字、语音、图像、视频等,从而是云端服务器连通与其连接的众多个人设备一起组成信息源160。
图2是根据本发明的一些实施例所示的一种示例性计算设备200的示意图。服务器110和存储设备130可以在计算设备200上实现。例如,处理引擎112可以在计算设备200上实现并被配置为实现本申请中所披露的功能。
计算设备200可以包括用来实现本申请所描述的***的任意部件。例如,处理引擎112可以在计算设备200上通过其硬件、软件程序、固件或其组合实现。为了方便起见图中仅绘制了一台计算机,但是本申请所描述的与订单异常识别***100相关的计算功能可以以分布的方式、由一组相似的平台所实施,以分散***的处理负荷。
计算设备200可以包括与网络连接的通信端口250,用于实现数据通信。计算设备200可以包括一个处理器(例如,CPU)220,可以以一个或多个处理器的形式执行程序指令。示例性的电脑平台可以包括一个内部总线210、不同形式的程序存储器和数据存储器包括,例如,硬盘270、和只读存储器(ROM)230或随机存储器(RAM)240,用于存储由计算机处理和/或传输的各种各样的数据文件。示例性的计算设备可以包括存储在只读存储器230、随机存储器240和/或其他类型的非暂时性存储介质中的由处理器220执行的程序指令。本申请的方法和/或流程可以以程序指令的方式实现。计算设备200也包括输入/输出部件260,用于支持电脑与其他部件之间的输入/输出。计算设备200也可以通过网络通讯接收本披露中的程序和数据。
为理解方便,图2中仅示例性绘制了一个处理器。然而,需要注意的是,本申请中的计算设备200可以包括多个处理器,因此本申请中描述的由一个处理器实现的操作和/或方法也可以共同地或独立地由多个处理器实现。例如,如果在本申请中,计算设备200的处理器执行步骤1和步骤2,应当理解的是,步骤1和步骤2也可以由计算设备200的两个不同的处理器共同地或独立地执行(例如,第一处理器执行步骤1,第二处理器执行步骤2,或者第一和第二处理器共同地执行步骤1和步骤2)。
图3是根据本发明的一些实施例所示的一个示例性的移动设备300的示例性硬件和/或软件的示意图。如图3所示,移动设备300可以包括一个通信单元310、一个显示单元320、一个图形处理器330、一个处理器340、一个输入/输出单元350、一个内存360和一个存储单元390。移动设备300中还可以包括一个总线或者一个控制器。在一些实施例中,移动操作***370和一个或多个应用程序380可以从存储单元390加载到内存360中,并由处理器340执行。在一些实施例中,应用程序380可以接收和显示与处理引擎112有关的图像处理或其他信息的信息。输入/输出单元350可以实现将数据信息与订单异常识别***100的交互,并将交互相关信息通过网络150提供给订单异常识别***100中的其他部件,如服务器110。
为了实现本申请中描述的各种模块、单元及其功能,计算机硬件平台可以用作这里提到的一个或多个元件的硬件平台。一个拥有用户界面元件的计算机可以用于实现个人计算机(PC)或者其它任何形式的工作站或终端设备。通过合适的编程,一个计算机也可以充当一台服务器。
图4是根据本发明的一些实施例所示的订单异常识别***的模块图。如图4所示,该***可以包括第一获取模块410、订单异常识别模块420、第一订单异常识别模型训练模块430、第二订单异常识别模型训练模块440和管控策略执行模块450。在一些实施例中,第一获取模块410、订单异常识别模块420、第一订单异常识别模型训练模块430、第二订单异常识别模型训练模块440和管控策略执行模块450可以包含在图1所示的处理引擎112中。
第一获取模块410可以用于获取待测订单。在一些实施例中,待测订单包括网约车服务订单、家政服务订单、快递订单、外卖订单等服务型订单。在一些实施例中,待测订单可以是一段时间内的历史订单或当前正在执行的订单。在一些实施例中,待测订单可以是服务提供者完成服务的订单、或是中途取消的订单、或是服务请求者仅提交了服务需求的订单、或是服务提供者仅提交了可提供服务的订单。在一些实施例中,待测订单信息可以包括服务请求者信息、服务请求者提出服务需求的时间、服务地点、服务提供者信息等。在一些实施例中,可以从网络150、存储设备130、服务器110、服务请求者终端120、信息源160等设备中获取历史待测订单或当前待测订单。
在一些实施例,第一获取模块410还可以用于获取与所述待测订单相关的特征参数。在一些实施例中,与所述待测订单相关的特征参数至少反映以下多种信息中的至少一个:服务时间、服务地点、服务请求者或服务提供者在平台上的操作行为、服务请求者或服务提供者的个人信息或服务请求者对服务的订制要求。在一些实施例中,服务时间可以包括下单时间、订单执行时间。在一些实施例中,服务地点可以包括行驶路线相关地点及其偏僻度、行程长度等信息。在一些实施例中,行驶路线相关地点可以包括约车的起点、终点以及起点和终点之间的行驶路径上的途径地点。在一些实施例中,行驶路线相关地点的偏僻度可以与一定时间内距离该地点一定范围内的订单数量负相关。例如,如果一个星期内,起点在订单中出现的次数较多,可以判断该地点的偏僻度较低,则该订单的行驶路线相关地点的偏僻度较低。在一些实施例中,服务请求者或服务提供者在平台上的操作行为可以包括一定时间范围内服务请求者或服务提供者的取消订单频率、取消订单的时机、修改订单等操作。在一些实施例中,可以将一定时间范围内服务请求者或服务提供者的取消订单频率确定为相关特征值。例如,乘客或是司机在一天内取消订单的频率。在一些实施例中,可以将一定时间范围内服务请求者或服务提供者的完单量确定为特征参数。例如,乘客或司机在一个月内完成订单的数量。在一些实施例中,服务请求者或服务提供者的个人信息可以包括服务请求者或服务提供者的性别、服务请求者或服务提供者的注册时间、服务请求者或服务提供者的住址置信度、服务请求者或服务提供者的工作地点置信度、服务请求者或服务提供者的借贷情况、服务请求者或服务提供者的受教育程度、一定时间范围内服务请求者或服务提供者被投诉次数、一定时间范围内服务请求者或服务提供者的被评价情况。
订单异常识别模块420用于利用第一订单异常识别模型处理所述特征参数中的至少一部分,获得第一识别结果;利用第二订单异常识别模型处理所述特征参数中的至少一部分,获得第二识别结果;联合所述第一识别结果及所述第二识别结果确定所述待测订单的异常识别结果。
在一些实施例中,第一订单异常识别模型可以是分类模型。例如,决策树模型、贝叶斯分类法、随机森林、支持向量机、神经网络等模型。在一些实施例中,可以获取上述反映服务时间、服务地点、服务请求者或服务提供者在平台上的操作行为、服务请求者或服务提供者的个人信息或服务请求者对服务的订制要求的特征参数,并确定每一个特征参数对应的分类阈值。以网约车服务为例,特征参数为订单执行时间时,对应的分类阈值可以是“22:00-05:00”,将订单执行时间分为“夜间订单”和“非夜间订单”。又例如,特征参数为行驶路线相关地点的偏僻度,偏僻度为0-10排序的十个等级,对应的分类阈值可以是“大于5”。又例如,特征参数为一定时间内服务请求者或服务提供者的取消订单频率,对应的分类阈值可以是“30分钟内取消订单5次”。在一些实施例中,分类阈值的确定可以通过人为设定、统计计算、机器训练等方式确定。在一些实施例中,将待测订单中的特征参数,根据对应的分类阈值,一一比较分类后,可得到最终的识别结果,可以是“异常订单”或“正常订单”的结果。
在一些实施例中,第二订单异常识别模型可以是回归模型。例如:线性回归、逻辑回归、多项式回归、逐步回归、岭回归、Lasso回归、ElasticNet回归等。在一些实施例中,第二订单异常识别模型中的特征参数与第一订单异常识别模型中的特征参数可以相同,也可以不同,也可以有重叠。在一些实施例中,第二订单异常识别模型中的特征参数与第一订单异常识别模型中特征参数是独立获取的。在一些实施例中,第二订单异常识别模型和第一订单异常识别模型是独立训练或建立的。例如,当第一订单异常识别模型为决策树模型,第二订单异常识别模型为回归模型,可以独立获取样本及其特征参数,训练得到决策树中的特征参数对应的分类阈值,和特征参数***的次序,训练得到决策树模型,可以另外获取训练样本及其特征参数,训练得到回归模型。在一些实施例中,训练第一订单异常识别模型和第二订单异常识别模型的样本可以是来自同一样本集合。
在一些实施例中,回归模型可以输出订单异常的概率值。在一些实施例中,可以确定概率值的阈值,根据异常订单的概率值和阈值的比较,得到待测订单是否是异常订单的识别结果。在一些实施例中,可以根据概率值进一步确定异常订单的异常度,以确定异常订单的危险程度。例如异常度可以通过建立的关系函数得到的连续性数值,也可以将不同区间的数值分类为不同等级,等级越高,异常度越大,订单存在的潜在危险性越大。在一些实施例中,当所述第一识别结果为所述待测订单是异常订单,可以再利用所述第二订单异常识别模型确定所述待测订单的异常度。并将所述异常度作为所述待测订单的异常识别结果。
第一订单异常识别模型训练模块430可以用于获取历史订单。在一些实施例中,可以获取一段时间内的历史订单作为训练样本。例如,一个星期的历史订单、一个月的历史订单等。在一些实施例中,订单可以包括是完成的订单、中途取消的订单等已提交了服务请求在***100中有记录的订单。在一些实施例中,可以获取包括订单异常的一段时间内的历史订单。例如,在2017年2月8日出现了订单异常,可以获取包括这一天的一个星期的内的历史订单作为训练样本。如果在2017年2月8日和2017年10月5日分别出现了订单异常,可以获取2017年2月8日所在星期内的历史订单和2017年10月5日所在星期内的历史订单。由于订单异常的数量通常是很少的,有可能一年内也只有几个,因此这样获取训练样本,可以保证获取到订单异常的样本,并不会导致正常订单的样本量太大,影响训练结果和处理速度。
在一些实施例中,第一订单异常识别模型训练模块430可以用于获取与历史订单相关的特征参数。在一些实施例中,特征参数可以包括上述服务时间、服务地点、服务请求者或服务提供者在平台上的操作行为、服务请求者或服务提供者的个人信息或服务请求者对服务的订制要求等与订单相关的特征参数。
在一些实施例中,第一订单异常识别模型训练模块430可以用于将所述历史订单中的订单异常标记为正样本,所述历史订单中的正常订单标记为负样本。在一些实施例中,可以人为对历史订单进行标记。例如,在训练样本中,2017年2月8日当天发生了一起订单异常,已获取了2017年2月8日当天的所有历史订单作为样本,可以将2017年2月8日当天的订单异常标记为正样本,将当天的其他正常订单标记为负样本。
在一些实施例中,第一订单异常识别模型训练模块430可以用于基于所述历史订单中的所述特征参数及标记结果训练第一初始模型得到所述第一订单异常识别模型。在一些实施例中,第一订单异常识别模型可以是决策树模型,包括但不限于分类及回归树(Classification And Regression Tree,CART)、迭代二叉树三代(IterativeDichotomiser 3,ID3)、C4.5算法、随机森林(Random Forest)、卡方自动交互检测(Chisquared Automatic Interaction Detection,CHAID)、多元自适应回归样条(Multivariate Adaptive Regression Splines,MARS)以及梯度推进机(GradientBoosting Machine,GBM)等或其任意组合。
在一些实施例中,第一订单异常识别模型训练模块430可以用于验证第一订单异常识别模型中某节点处的判断条件及划分结果是否与所述样本的分布一致。在一些实施例中,模型中的节点与所述特征参数一一对应。训练样本在节点处,根据特征参数对应的判断条件将样本划分成两类样本子集(正样本和负样本),可以验证某节点处的划分结果与实际正负样本的分布是否一致。例如,训练得到的第一订单异常识别模型中,特征参数“服务请求者的完单量”对应的判断条件是“大于X阈值”,将满足服务请求者的完单量大于X阈值的样本划分到正样本中。但是实际上,在正样本中,特征参数“服务请求者的完单量”是远远小于X阈值。那么该节点不符合样本的分布,会导致该模型过拟合。若节点处的判断条件及划分结果与所述样本的实际分布不一致,可以使用其他节点替换该节点。在一些实施例中,可以利用该节点处的所有样本以及该节点的所有下层节点进行决策树训练获得新的子树。用所述新的子树代替原第一订单异常识别模型中的该节点及其下层节点组成的子树。例如,第一订单异常识别模型中的某节点的特征参数是“服务请求者的完单量”,该节点的下一级节点的特征参数是“服务请求者的被投诉次数”。验证发现,特征参数“服务请求者的完单量”对应的判断条件划分的结果与正样本的分布不一致,则将该特征参数对应的节点删除,将原下一级节点的特征参数是“服务请求者的被投诉次数”代替删除的节点。又例如,第一订单异常识别模型中的某节点的特征参数是“服务请求者的完单量”,该节点的下一级节点的特征参数是“服务请求者的被投诉次数”,再以下的节点包括“服务请求者或服务提供者的住址置信度”、“服务请求者或服务提供者的工作地点置信度”、“服务请求者或服务提供者的借贷情况”、“服务请求者或服务提供者的受教育程度”。可以理解为,特征参数“服务请求者的被投诉次数”、“服务请求者或服务提供者的住址置信度”、“服务请求者或服务提供者的工作地点置信度”、“服务请求者或服务提供者的借贷情况”、“服务请求者或服务提供者的受教育程度”对应的节点组成一棵子树。验证发现,特征参数“服务请求者的完单量”对应的判断条件划分的结果与正样本的分布不一致,则将该特征参数对应的节点删除,并且将特征参数“服务请求者的完单量”对应的原节点处的所有样本作为训练样本,对特征参数是“服务请求者的被投诉次数”、“服务请求者或服务提供者的住址置信度”、“服务请求者或服务提供者的工作地点置信度”、“服务请求者或服务提供者的借贷情况”、“服务请求者或服务提供者的受教育程度”对应的节点重新进行训练,获得新的子树。并将所述新的子树代替原来以特征参数“服务请求者的完单量”对应的节点开始的子树。得到新的第一订单异常识别模型。在一些实施例中,可以对第一订单异常识别模型中的每一个节点进行验证并优化,最终得到所有节点上的特征参数都符合样本实际分布的第一订单异常识别模型。
第二订单异常识别模型训练模块440可以用于获取历史订单和获取与历史订单相关的特征参数。在一些实施例中,第二订单异常识别模型可以获取和第一订单异常识别模型同样的历史订单作为训练样本。在一些实施例中,第二订单异常识别模型可以获取和第一订单异常识别模型不同的历史订单作为训练样本。在一些实施例中,第二订单异常识别模型的训练样本可以和第一订单异常识别模型的训练样本有重叠。在一些实施例中,第二订单异常识别模型的特征参数可以和第一订单异常识别的特征参数相同。在一些实施例中,第二订单异常识别模型的特征参数可以和第一订单异常识别的特征参数不同。在一些实施例中,第二订单异常识别模型的特征参数可以和第一订单异常识别模型的特征参数有重叠。
第二订单异常识别模型训练模块440可以用于将所述历史订单中的订单异常标记为正样本,所述历史订单中的正常订单标记为负样本。第二订单异常识别模型训练模块440可以用于基于所述历史订单中的所述特征参数及标记结果训练第二初始模型获得所述第二订单异常识别模型。在一些实施例中,第二订单异常识别模型可以是逻辑回归模型。在一些实施例中,可以采用贪心算法对模型进行优化。在一些实施例中,可以通过极大似然估计法确定模型中的特征参数。在一些实施例中,可以采用对数似然函数,即
Figure BDA0001891020080000171
计算。
管控策略执行模块450用于基于所述待测订单的异常识别结果确定并执行风险管控策略。在一些实施例中,风险管控策略可以是向服务请求者和/或服务提供者发出警示信息。以网约车服务为例,当待测订单的识别结果为“订单异常”,可以向乘客和/司机的用户终端发出指令,在用户终端发出语音提示“请您注意乘车安全”。在一些实施例中,风险管控策略可以是对服务请求者和/或服务提供者进行身份验证。在一些实施例中,可以在异常度较高时,对服务请求者和/或服务提供者进行身份验证。在一些实施例中,身份验证的方式可以是通过服务请求者和/或服务提供者的用户终端发出请求,请求服务请求者和/或服务提供者上传身份证件、进行人脸识别、服务请求者和/或服务提供者语音识别、车辆证明证件、车辆信息识别等方式中的一种或多种的组合。在一些实施例中,如果服务请求者和/或服务提供者没有通过身份验证或拒绝身份验证,可以终止待测订单的执行。在一些实施例中,可以先进行实名认证,对服务请求者和/或服务提供者的身份证件进行核实,实名认证通过,再进行人脸识别,如果人脸识别和实名认证结果相同,则通过认证,继续订单,否则认证不通过,订单结束。在一些实施例中,风险管控策略可以是在订单被执行时对服务请求者和/或服务提供者的行为进行监控。在一些实施例中,风险管控策略可以是直接终止待测订单,不将订单指派给服务提供者或是派单后直接取消订单等。例如,在网约车服务中,在乘客提交请求后,如果识别结果是待测订单为异常订单,并且异常度极高,服务器可以直接停止派单,以保护服务提供者安全。如果在***派单后,识别结果是待测订单为异常订单,并且异常度极高,服务器可以直接取消派单后的订单,并告知乘客取消原因,以保护乘客安全。
应当理解,图4所示的***及其模块可以利用各种方式来实现。例如,在一些实施例中,***及其模块可以通过硬件、软件或者软件和硬件的结合来实现。其中,硬件部分可以利用专用逻辑来实现;软件部分则可以存储在存储器中,由适当的指令执行***,例如微处理器或者专用设计硬件来执行。本领域技术人员可以理解上述的方法和***可以使用计算机可执行指令和/或包含在处理器控制代码中来实现,例如在诸如磁盘、CD或DVD-ROM的载体介质、诸如只读存储器(固件)的可编程的存储器或者诸如光学或电子信号载体的数据载体上提供了这样的代码。本申请的***及其模块不仅可以有诸如超大规模集成电路或门阵列、诸如逻辑芯片、晶体管等的半导体、或者诸如现场可编程门阵列、可编程逻辑设备等的可编程硬件设备的硬件电路实现,也可以用例如由各种类型的处理器所执行的软件实现,还可以由上述硬件电路和软件的结合(例如,固件)来实现。
需要注意的是,以上描述,仅为描述方便,并不能把本申请限制在所举实施例范围之内。可以理解,对于本领域的技术人员来说,在了解该***的原理后,可以在不背离这一原理的情况下,对实施上述方法和***的应用领域进行形式和细节上的各种修正和改变。例如,第一获取模块410和订单异常识别模块420可以集成在一起成为一个模块,同时实现数据获取以及模型训练的功能。然而,这些变化和修改不脱离本申请的范围。
图5是根据本发明的一些实施例所示的订单风险管控***的模块图。如图5所示,该***可以包括第二获取模块510、服务订单生成模块520、风险管控接收模块530。在一些实施例中,第二获取模块510、服务订单生成模块520、风险管控接收模块530可以包含在图1所示的服务请求者终端120或服务提供者终端140中。
第二获取模块510可以用于获取服务请求者的服务请求。在一些实施例中,所述服务请求至少包括服务时间与服务地点。在一些实施例中,服务时间可以是服务请求者下单的时间。在一些实施例中,服务时间可以是所述订单执行的时间。在一些实施例中,服务地点可以是服务开始的地点、服务终止的地点、服务执行过程的地点。以网约车为例,服务地点可以是起点、终点、行驶路径的途径地点、行程长度等信息。在一些实施例中,服务地点可以是相关地点的偏僻度。
服务订单生成模块520可以用于基于所述服务请求生成服务订单并发送给服务器。在一些实施例中,可以根据服务时间、服务地点等信息生成服务订单。在一些实施例中,服务器接收到服务订单后,可以将该服务订单作为待测订单进行订单异常的识别。
风险管控接收模块530可以用于接收服务器发送的对所述服务订单的异常识别结果或者与所述异常识别结果相关的风险管控指示。在一些实施例中,异常识别结果相关的风险管控指示可以包括警示信息。以网约车服务为例,在乘客端,可以发出警示信息“滴滴提醒您,当前订单疑似异常,为保障夜间行车安全,滴滴平台将携手警方,全程保护您和司机的安全!”在一些实施例中,不同的警示信息可以表示订单异常的异常度不同。在一些实施中,与所述异常识别结果相关的风险管控指示可以是身份验证请求。在一些实施例中,身份验证请求可以是要求服务请求者和/或服务提供者上传身份证件、进行人脸识别、服务请求者和/或服务提供者语音识别、车辆证明证件、车辆信息识别等方式中的一种或多种的组合。在一些实施例中,服务请求者和/或服务提供者履行身份验证后,可以收到验证通过的信息,或是验证没有通过的信息。还可以是直接收到订单进行的信息或是订单已终止的信息。在一些实施例中,服务请求者和/或服务提供者没有履行身份验证的请求,可以收到订单已终止的信息。在一些实施例中,与所述异常识别结果相关的风险管控指示可以包括在订单被执行时服务请求者和/或服务提供者的行为信息传输请求。以网约车服务为例,可以在行驶过程中,要求实时传输行驶路径和车辆的当前位置,传输行驶路径是否意外中断或停止的信息,传输订单修改信息,传输订单意外中断或取消信息等。还可以要求全程传输车辆内的乘客和司机的行为信息、意外求救信息等。在一些实施例中,用户终端可以直接接收订单终止的信息。例如,在网约车服务中,如果识别结果是待测订单为订单异常,并且异常度极高,服务器可以直接停止派单,并向用户终端发出订单终止的信息。在一些实施例中,用户终端收到的警示信息可以对服务请求者进行震慑,对服务提供者进行安全提醒。也可以是对服务提供者进行震慑,对服务请求者进行安全提醒。
应当理解,图5所示的***及其模块可以利用各种方式来实现。例如,在一些实施例中,***及其模块可以通过硬件、软件或者软件和硬件的结合来实现。其中,硬件部分可以利用专用逻辑来实现;软件部分则可以存储在存储器中,由适当的指令执行***,例如微处理器或者专用设计硬件来执行。本领域技术人员可以理解上述的方法和***可以使用计算机可执行指令和/或包含在处理器控制代码中来实现,例如在诸如磁盘、CD或DVD-ROM的载体介质、诸如只读存储器(固件)的可编程的存储器或者诸如光学或电子信号载体的数据载体上提供了这样的代码。本申请的***及其模块不仅可以有诸如超大规模集成电路或门阵列、诸如逻辑芯片、晶体管等的半导体、或者诸如现场可编程门阵列、可编程逻辑设备等的可编程硬件设备的硬件电路实现,也可以用例如由各种类型的处理器所执行的软件实现,还可以由上述硬件电路和软件的结合(例如,固件)来实现。
需要注意的是,以上描述,仅为描述方便,并不能把本申请限制在所举实施例范围之内。可以理解,对于本领域的技术人员来说,在了解该***的原理后,可以在不背离这一原理的情况下,对实施上述方法和***的应用领域进行形式和细节上的各种修正和改变。例如,第二获取模块510和服务订单生成模块520可以集成在一起成为一个模块,同时实现数据获取以及模型训练的功能。然而,这些变化和修改不脱离本申请的范围。
图6是根据本发明的一种实施例所示的订单异常识别的示例性流程图。在一些实施例中,流程600可以通过处理逻辑来执行,该处理逻辑可以包括硬件(例如,电路、专用逻辑、可编程逻辑、微代码等)、软件(运行在处理设备上以执行硬件模拟的指令)等或其任意组合。图6所示的用于识别订单异常的流程600中的一个或多个操作可以通过图1所示的道路信息***100实现。例如,流程600可以以指令的形式存储在存储设备130中,并由处理引擎112执行调用和/或执行(例如,图2所示的计算设备200的处理器220、图3所示的移动设备300的中央处理器340)。
在610中,可以获取待测订单。操作610可以由第一获取模块410执行。在一些实施例中,待测订单包括网约车服务订单、家政服务订单、快递订单、外卖订单等服务型订单。在一些实施例中,待测订单可以是一段时间内的历史订单或当前正在执行的订单。在一些实施例中,一段时间可以是一个星期、一个月、一个季度、半年、一年或几年。在一些实施例中,待测订单可以是服务提供者完成服务的订单、或是中途取消的订单、或是服务请求者仅提交了服务需求的订单、或是服务提供者仅提交了可提供服务的订单。以网约车服务订单为例,待测订单可以是乘客已提交了约车需求的订单,待测订单可以是服务器已匹配司机的订单,待测订单可以是司机已接单的订单、待测订单可以是司机已完成服务的订单,待测订单可以是中途任意时刻由乘客取消的订单。在一些实施例中,待测订单信息可以包括服务请求者信息、服务请求者提出服务需求的时间、服务地点、服务提供者信息等。以网约车为例,待测订单信息可以包括乘客的个人信息、乘客的信用信息、乘客约车的时间、乘客上车的地点、终点、行车轨迹、司机的信息、司机的信息、司机的信用信息、订单完成时间等信息。在一些实施例中,可以从网络150、存储设备130、服务器110、服务请求者终端120、信息源160等设备中获取历史待测订单或当前待测订单。
在620中,可以获取与所述待测订单相关的特征参数。操作620可以由第一获取模块410执行。在一些实施例中,与所述待测订单相关的特征参数至少反映以下多种信息中的至少一个:服务时间、服务地点、服务请求者或服务提供者在平台上的操作行为、服务请求者或服务提供者的个人信息或服务请求者对服务的订制要求。在一些实施例中,服务时间可以包括下单时间、订单执行时间。在一些实施例中,下单时间可以是乘客向服务器提交服务请求的时间,订单执行时间可以是司机接上乘客后,按照订单的要求将乘客由起点送至终点花费的时间。例如,乘客的下单时间是下午14:00点,订单执行时间为下午17:30到18:40。
在一些实施例中,服务地点可以包括行驶路线相关地点的偏僻度、行程长度等信息。在一些实施例中,行驶路线相关地点可以包括约车的起点、终点以及起点和终点之间的行驶路径上的途径地点。在一些实施例中,行驶路线相关地点的偏僻度可以与一定时间内距离该地点一定范围内的订单数量负相关。例如,如果一个星期内,起点在订单中出现的次数较多,可以判断该地点的偏僻度较低,则该订单的行驶路线相关地点的偏僻度较低。又例如,如果一个月内,终点在订单中出现的次数很少,或是没有出现过,可以判断该地点的偏僻度较高,则该订单的行驶路线相关地点的偏僻度较高。又例如,如果一个星期内,行驶路径上的某一途径地点,在订单中出现的次数很少或是没有出现过,可以判断该订单的行驶路线相关地点的偏僻度较高。在一些实施例中,查找某地点在订单中出现的次数可以利用Geohash编码算法确定。可以将地理空间划分为矩形区域,对每个矩形区域进行编码,编码长度越长,表示划分的矩形区域越细。在一些实施例中,Geohash编码长度可以选1位到12位之间。例如,可以选择使用6位的编码,一个矩形区域可以表示大约600*600米范围的区域。在一些实施例中,可以将行驶路线相关地点投影到对应的矩形区域内,统计每个矩形区域内的订单次数,从而得到该地点的偏僻度。例如,某订单的起点为北海公园,可以统计表示北海公园的矩形区域内的订单在一个星期内出现的次数,如果次数较多,说明该地点的偏僻度较低。在一些实施例中,确定行驶路线的偏僻度可以先在行驶路线上等距的采集样点作为沿途样点,例如,在行驶路线上等距的采集5个样点作为沿途样点,分布统计5个沿途样点对应的矩形区域内的订单数量,根据5个沿途样点出现的订单次数确定该行驶路线的偏僻度。在一些实施例中,还可以先在行驶路线上等距的采集样点作为沿途样点,再在沿途样点的基础上得到扩散样点,例如,可以在每个沿途样点的两侧各采集一个样点作为扩散样点,如果有5个沿途样点,可以得到相应的10个扩散样点,统计沿途样点和扩散样点对应的订单数量,确定该行驶路线的偏僻度。如果有一个沿途样点或扩散样点的订单数量很少或没有,可以认为该行驶路线的偏僻度较高。如果有半数的沿途样点或扩散样点的订单数量很少或没有,可以认为该行驶路线的偏僻度很高。在一些实施例中,偏僻度可以表现为连续数值。例如,建立与行驶路径相关地点的订单量的关系方程,通过关系方程直接得到的计算数值。在一些实施例中,偏僻度可以表现为离散数值。例如,偏僻度可以是0、1、2-10的等级分类,数字越大代表偏僻度越高,不同订单数量的区间对应一个等级,根据相关地点的订单数量可得到对应等级的偏僻度。在一些实施例中,行程长度可以是行驶路线的公里数。例如,起点和终点之间的行驶路线为45公里,行程长度是45公里。
在一些实施例中,服务请求者或服务提供者在平台上的操作行为可以包括一定时间范围内服务请求者或服务提供者的取消订单频率、取消订单的时机、修改订单等操作。在一些实施例中,可以将一定时间范围内服务请求者或服务提供者的取消订单频率确定为相关特征值。例如,乘客或是司机在一天内取消订单的频率。或是乘客或司机在10分钟内连续抢单后又取消订单的频率。在一些实施例中,可以将一定时间范围内服务请求者或服务提供者的完单量确定为特征参数。例如,乘客或司机在一个月内完成订单的数量。
在一些实施例中,服务请求者或服务提供者的个人信息可以包括服务请求者或服务提供者的性别、服务请求者或服务提供者的注册时间、服务请求者或服务提供者的住址置信度、服务请求者或服务提供者的工作地点置信度、服务请求者或服务提供者的借贷情况、服务请求者或服务提供者的受教育程度、一定时间范围内服务请求者或服务提供者被投诉次数、一定时间范围内服务请求者或服务提供者的被评价情况。在一些实施例中,服务请求者或服务提供者的住址置信度、服务请求者或服务提供者的工作地点置信度可以根据用户常去地点的置信度确定。以网约车服务为例,可以通过已有的算法分析一名乘客(即订单发起者)一段时间内每个历史订单的起始点或终点的经纬度和该经纬度对应的兴趣点(Point of Interest,POI),识别出兴趣点的类型(住宅或商业区),预测该乘客的住址和/或公司地址,并确定所预测的住址和/或公司地址的置信度。例如,可以将一段时间内(一月、三月、半年等)出现次数最多的住宅类兴趣点确定为该乘客的住址,将出现次数最多的商业区类兴趣点确定为该乘客的公司地址。在一些实施例中,可以根据如下公式计算所预测的住址和/或公司地址的置信度:
Figure BDA0001891020080000251
其中α为所预测的住址和/或公司地址(即历史订单中出现次数最多的住址和/或公司地址)的置信度,Nmax为所预测的住址和/或公司地址的出现次数。在一些实施例中,如果置信度超过预设阈值,则确定该用户有固定居住地点和/或固定工作地点。
在一些实施例中,借贷情况可以包括但不限于借贷次数、借款数额、借款期限、还款情况。在一些实施例中,特征值获取模块420可以从第三方数据库中获取该订单发起者的借贷情况。第三方数据库包括但不限于银行数据库、社保机构数据库、信用评估机构数据库、p2p网络借贷平台数据库。
在一些实施例中,个人信息可以包括受教育程度。在一些实施例中,受教育程度可以用离散数值表示。例如小学文化表示为0,初中文化表示为1,高中文化表示为2,本科及以上表示为3。在一些实施例中,受教育程度可以用二值表示,如受教育程度的学历为本科以上,则受教育程度用1表示,本科以下,则受教育程度用0表示。
在一些实施例中,特征参数可以是一定时间范围内服务请求者或服务提供者被投诉次数和/或一定时间范围内服务请求者或服务提供者的被评价情况。例如,统计一个月内,服务请求者或服务提供者被投诉的次数。在一些实施例中,服务请求者或服务提供者之间可以进行互评,满分为五个星,最差可以没有星或一颗星。或是直接给好评或差评进行互评。例如,可以统计一个月内,服务请求者或服务提供者收到的差评的数量,服务请求者或服务提供者收到的好评的数量。或是一个月内收到的一颗星评价的订单数量,收到五星评价的订单数量。
在一些实施例中,特征参数可以是服务请求者对服务工具的订制要求或对服务提供者的订制要求。例如,对司机的性别的要求、司机好评数量的要求、车辆的品牌的要求、车型的要求、车辆价格的要求等定制要求。
在630中,可以利用第一订单异常识别模型处理所述特征参数中的至少一部分,获得第一识别结果。在一些实施例中,630可以由订单异常识别模块420执行。在一些实施例中,第一订单异常识别模型可以是分类模型。例如,决策树模型、贝叶斯分类法、随机森林、支持向量机、神经网络等模型。在一些实施例中,可以获取上述反映服务时间、服务地点、服务请求者或服务提供者在平台上的操作行为、服务请求者或服务提供者的个人信息或服务请求者对服务的订制要求的特征参数,并确定每一个特征参数对应的分类阈值。以网约车服务为例,特征参数为订单执行时间时,对应的分类阈值可以是“22:00-05:00”,将订单执行时间分为“夜间订单”和“非夜间订单”。又例如,特征参数为行驶路线相关地点的偏僻度,偏僻度为0-10排序的十个等级,对应的分类阈值可以是“大于5”。又例如,特征参数为一定时间内服务请求者或服务提供者的取消订单频率,对应的分类阈值可以是“30分钟内取消订单5次”。在一些实施例中,分类阈值的确定可以通过人为设定、统计计算、机器训练等方式确定。在一些实施例中,将待测订单中的特征参数,根据对应的分类阈值,一一比较分类后,可得到最终的识别结果,可以是“异常订单”或“正常订单”的结果。在一些实施例中,识别结果可以是输出不同的数字,例如,“0”代表“正常订单”,“1”代表“异常订单”。
在640中,可以利用第二订单异常识别模型处理所述特征参数中的至少一部分,获得第二识别结果。在一些实施例中,640可以由订单异常识别模块420执行。在一些实施例中,第二订单异常识别模型可以是回归模型。例如:线性回归、逻辑回归、多项式回归、逐步回归、岭回归、Lasso回归、Elastic Net回归等。在一些实施例中,第二订单异常识别模型中的特征参数与第一订单异常识别模型中的特征参数可以相同,也可以不同,也可以有重叠。在一些实施例中,第二订单异常识别模型中的特征参数与第一订单异常识别模型中特征参数是独立获取的。在一些实施例中,第二订单异常识别模型和第一订单异常识别模型是独立训练或建立的。例如,当第一订单异常识别模型为决策树模型,第二订单异常识别模型为回归模型。可以独立获取样本及其特征参数,训练得到决策树中的特征参数对应的分类阈值,和特征参数***的次序,训练得到决策树模型,可以另外获取样本及其特征参数,训练得到回归模型。在一些实施例中,训练第一订单异常识别模型和第二订单异常识别模型的样本可以是来自同一样本集合。在一些实施例中,回归模型可以输出订单异常的概率值。在一些实施例中,可以确定概率值的阈值,根据异常订单的概率值和阈值的比较,得到待测订单是否是异常订单的识别结果。在一些实施例中,可以根据概率值进一步确定异常订单的异常度,以确定异常订单的危险程度。例如异常度可以通过建立的关系函数得到的连续性数值,也可以将不同区间的数值分类为不同等级,等级越高,异常度越大,订单存在的潜在危险性越大。
在一些实施例中,第一订单异常识别模型和第二订单异常识别模型可以独立进行订单异常的识别,分别输出是否是订单异常的识别结果。在一些实施例中,可以只使用第一订单异常识别模型或第二订单异常识别模型进行订单异常的识别,输出是否是订单异常的识别结果。在一些实施例中,可以在不同的情况下,选择使用第一订单异常识别模型或第一订单异常识别模型进行订单异常的识别,也可以选择使用第一订单异常识别模型和第一订单异常识别模型独立进行订单异常的识别,分别输出识别结果。
在650中,可以联合所述第一识别结果及所述第二识别结果确定所述待测订单的异常识别结果。在一些实施例中,步骤650可以由订单异常识别模块420执行。在一些实施例中,当所述第一识别结果为所述待测订单是异常订单,可以再利用所述第二订单异常识别模型确定所述待测订单的异常度。并将所述异常度作为所述待测订单的异常识别结果。在一些实施例中,可以当第一识别结果为所述待测订单是异常订单,并且第二识别结果也为异常订单时,认为所述待测订单的识别结果为异常订单。在一些实施例中,如果第一识别结果或第二识别结果中有一个识别结果为异常订单,可以认为所述待测订单的识别结果为异常订单。在一些实施例中,当所述第一识别结果为所述待测订单不是异常订单,可以将所述待测订单为正常订单作为所述待测订单的异常识别结果。在一些实施例中,当所述第二识别结果为所述待测订单不是异常订单,可以将所述待测订单为正常订单作为所述待测订单的异常识别结果。在一些实施例中,当所述第一识别结果和所述第二识别结果都为所述待测订单不是异常订单时,可以将所述待测订单为正常订单作为所述待测订单的异常识别结果。在一些实施例中,识别结果可以是待测订单是否是异常订单的判断结果,例如,识别结果可以是“异常订单”或“正常订单”。在一些实施例中,如果识别结果是异常订单,最终的待测订单的异常识别结果可以是异常度。例如,输出识别结果是异常度较高、或异常度为7(1-10等级)。在一些实施例中,识别结果可以包括是否是异常订单以及异常度。例如,识别结果可以是“异常订单”,异常度为8级。或者识别结果为“正常订单”,异常度为4级。在一些实施例中,如果识别结果为待测订单为正常订单,可以仅输出待测订单的异常识别结果为正常订单。
在660中,可以基于所述待测订单的异常识别结果确定并执行风险管控策略。在一些实施例中,可以由管控策略执行模块450执行该步骤。在一些实施例中,风险管控策略可以是向服务请求者和/或服务提供者发出警示信息。以网约车服务为例,当待测订单的识别结果为“订单异常”,可以向乘客和/司机的用户终端发出指令,在用户终端发出语音提示“请您注意乘车安全”。在一些实施例中,警示信息可以是声音提示、语音提示、灯光提示、用户终端振动提示等中的一种或多种方式的组合。在一些实施例中,可以根据异常度发出不同的警示信息。例如,以网约车服务为例,异常度较低时,可以发出警示信息“滴滴提醒您,当前订单疑似异常,为保障夜间行车安全,滴滴平台将携手警方,全程保护您和司机的安全!”。当异常度较高时,可以发出警示信息“滴滴携手警方提醒您:由于您的行程短期内存在异常,触发滴滴安全守护!***会全程关您和司机的安全,如有异常情况,会及时同步公安机关,100%快速定位寻踪!滴滴权利配合警方,共同守护出行安全!”。在一些实施例中,乘客端和司机端的警示信息不同。例如,司机端的警示信息为“滴滴提醒您,为保障夜间行车安全,滴滴平台将携手警方,全程保护您和乘客的安全”。在一些实施例中,风险管控策略可以是对服务请求者和/或服务提供者进行身份验证。在一些实施例中,可以在异常度较高时,对服务请求者和/或服务提供者进行身份验证。在一些实施例中,身份验证的方式可以是通过服务请求者和/或服务提供者的用户终端发出请求,请求服务请求者和/或服务提供者上传身份证件、进行人脸识别、服务请求者和/或服务提供者语音识别、车辆证明证件、车辆信息识别等方式中的一种或多种的组合。在一些实施例中,如果服务请求者和/或服务提供者没有通过身份验证或拒绝身份验证,可以终止待测订单的执行。在一些实施例中,可以先进行实名认证,对服务请求者和/或服务提供者的身份证件进行核实,实名认证通过,再进行人脸识别,如果人脸识别和实名认证结果相同,则通过认证,继续订单,否则认证不通过,订单结束。在一些实施例中,风险管控策略可以是在订单被执行时对服务请求者和/或服务提供者的行为进行监控。以网约车服务为例,可以在行驶过程中,全程监控行驶路径是否有大的偏差,行驶路径是否意外中断或停止,订单是否出现较大修改,订单是否意外中断或取消,全程监控车辆内的乘客和司机的行为,全程监控是否有来自乘客或司机的意外求救信息等。在一些实施例中,风险管控策略可以是直接终止待测订单,不将订单指派给服务提供者或是派单后直接取消订单等。例如,在网约车服务中,在乘客提交请求后,如果识别结果是待测订单为异常订单,并且异常度极高,服务器可以直接停止派单,以保护服务提供者安全。如果在***派单后,识别结果是待测订单为异常订单,并且异常度极高,服务器可以直接取消派单后的订单,并告知乘客取消原因,以保护乘客安全。在一些实施例中,风险管控策略可以在服务请求者提交服务请求后执行。例如,以网约车为例,乘客提交约车请求后,***100可以对待测订单进行识别,如果识别结果是该订单为异常订单,可以要求该乘客进行身份验证。在一些实施例中,风险管控策略可以在订单分配后执行。例如,以网约车为例,乘客提交约车请求后,***100进行订单分配,司机确定后,***100可以对待测订单进行识别,如果识别结果是该订单为异常订单,可以对乘客或司机发出警示信息。在一些实施例中,风险管控策略可以对服务请求者进行管控,保护服务提供者安全。例如,以网约车为例,如果特征参数是与服务请求者(乘客)相关,并且识别结果是异常订单,则对乘客进行管控,对乘客发出警示信息或要求乘客进行身份验证。在一些实施例中,风险管控策略可以对服务提供者进行管控,保护服务请求者安全。例如,以网约车为例,如果特征参数是与服务提供者(司机)相关,并且识别结果是订单异常,则对司机进行管控,对司机发出警示信息或要求司机进行身份验证。在一些实施例中,风险管控策略可以同时对服务请求者和服务提供者进行管控。例如,以网约车为例,可以对乘客和司机都发出警示信息。
需要注意的是,以上描述,仅为描述方便,并不能把本申请限制在所举实施例范围之内。可以理解,对于本领域的技术人员来说,在了解该***的原理后,可以在不背离这一原理的情况下,对实施上述方法和***的应用领域进行形式和细节上的各种修正和改变。
图7是根据本发明的一种实施例所示的确定第一订单异常识别模型的示例性流程图。在一些实施例中,流程700可以通过处理逻辑来执行,该处理逻辑可以包括硬件(例如,电路、专用逻辑、可编程逻辑、微代码等)、软件(运行在处理设备上以执行硬件模拟的指令)等或其任意组合。图7所示的用于识别订单异常的流程700中的一个或多个操作可以通过图1所示的道路信息***100实现。例如,流程700可以以指令的形式存储在存储设备130中,并由处理引擎112执行调用和/或执行(例如,图2所示的计算设备200的处理器220、图3所示的移动设备300的中央处理器340)。
在710中,可以获取历史订单。在一些实施例中,步骤710可以由第一订单异常识别模型训练模块430执行。在一些实施例中,可以获取一段时间内的历史订单作为训练样本。例如,一个星期的历史订单、一个月的历史订单等。在一些实施例中,订单可以包括是完成的订单、中途取消的订单等已提交了服务请求在***100中有记录的订单。在一些实施例中,历史订单可以从***100中获取,例如网络150、存储设备130、服务器110、服务请求者终端120、信息源160等设备中获取。在一些实施例中,可以获取包括订单异常的一段时间内的历史订单。例如,在2017年2月8日出现了订单异常,可以获取包括只一天的一个星期的内的历史订单作为训练样本。如果在2017年2月8日和2017年10月5日分别出现了订单异常,可以获取2017年2月8日所在星期内的历史订单和2017年10月5日所在星期内的历史订单。在一些实施例中,也可以获取具有订单异常的当天的历史订单作为训练样本。例如,如果2017年2月8日当天发生了一起订单异常,获取2017年2月8日当天的所有历史订单作为样本订单。如果2017年2月8日、2017年4月15日、2017年7月8日、2017年11月6日等日期的当天发生了订单异常。获取2017年2月8日、2017年4月15日、2017年7月8日、2017年11月6日等当天的所有历史订单作为训练样本。由于订单异常的数量通常是很少的,有可能一年内也只有几个,因此这样获取训练样本,可以保证获取到订单异常的样本,并不会导致正常订单的样本量太大,影响训练结果和处理速度。
在720中,可以获取与历史订单相关的特征参数。在一些实施例中,步骤720可以由第一订单异常识别模型训练模块430执行。在一些实施例中,特征参数可以包括上述服务时间、服务地点、服务请求者或服务提供者在平台上的操作行为、服务请求者或服务提供者的个人信息或服务请求者对服务的订制要求等与订单相关的特征参数。例如,下单时间、订单执行时间、行驶路线相关地点的偏僻度、行程长度、一定时间范围内服务请求者或服务提供者的取消订单频率、一定时间范围内服务请求者或服务提供者的完单量、服务请求者或服务提供者的性别、服务请求者或服务提供者的注册时间、服务请求者或服务提供者的住址置信度、服务请求者或服务提供者的工作地点置信度、服务请求者或服务提供者的借贷情况、服务请求者或服务提供者的受教育程度、一定时间范围内服务请求者或服务提供者被投诉次数、一定时间范围内服务请求者或服务提供者的被评价情况、服务请求者对服务工具的订制要求或对服务提供者的订制要求等。
在步骤730中,可以将所述历史订单中的订单异常标记为正样本,所述历史订单中的正常订单标记为负样本。在一些实施例中,步骤720可以由第一订单异常识别模型训练模块430执行。在一些实施例中,可以人为对历史订单进行标记。例如,在训练样本中,2017年2月8日当天发生了一起订单异常,已获取了2017年2月8日当天的所有历史订单作为样本,可以将2017年2月8日当天的订单异常标记为正样本,将当天的其他正常订单标记为负样本。在一些实施例中,可以根据***100中的记录结果进行标记,将记录中出现恶性事件的历史订单标记为正样本。将记录中正常的订单标记为负样本。在一些实施例中,可以将正样本用数字“1”表示,将负样本用数字“0”表示。
在步骤740中,可以基于所述历史订单中的所述特征参数及标记结果训练第一初始模型得到所述第一订单异常识别模型。在一些实施例中,步骤720可以由第一订单异常识别模型训练模块430执行。在一些实施例中,可以将历史订单中的特征参数以及标记的结果,通过机器学习的方式进行训练,得到每一个特征参数的分类阈值,以及特征参数的分类次序,最终得到第一订单异常识别模型。在一些实施例中,第一订单异常识别模型可以是决策树模型,包括但不限于分类及回归树(Classification And Regression Tree,CART)、迭代二叉树三代(Iterative Dichotomiser 3,ID3)、C4.5算法、随机森林(Random Forest)、卡方自动交互检测(Chisquared Automatic Interaction Detection,CHAID)、多元自适应回归样条(Multivariate Adaptive Regression Splines,MARS)以及梯度推进机(Gradient Boosting Machine,GBM)等或其任意组合。在一些实施例中,可以利用信息增益作为决策树中的节点选择的标准。每次选择最大化信息增益的条件对节点进行选择。在一些实施例中,决策树中的节点与特征参数对应。在一些实施例中,第一订单异常识别模型上,每个节点上选择一个信息增益最大的特征参数,每个节点上的判断的条件,为节点上的特征参数对应的分类阈值。在一些实施例中,可以将待测订单的特征参数作为输入,利用训练好的第一订单异常识别模型,按照每个节点上特征参数的判断条件进行划分,最终得到最后的识别结果。在一些实施例中,可以将训练得到的模型作为第一初始模型,进一步优化验证后,确定第一订单异常识别模型。优化的方法可以参考如下的750中的描述。
在750中,可以验证第一订单异常识别模型中某节点处的判断条件及划分结果是否与所述正样本的分布一致。在一些实施例中,步骤720可以由第一订单异常识别模型训练模块430执行。在一些实施例中,模型中的节点与所述特征参数对应。训练样本在节点处,根据特征参数对应的判断条件将样本划分成两类样本子集(正样本和负样本),可以验证某节点处的划分结果与实际正样本的分布是否一致。例如,训练得到的第一订单异常识别模型中,特征参数“服务请求者的完单量”对应的判断条件是“大于X阈值”,将满足服务请求者的完单量大于X阈值的样本划分到正样本中。但是实际上,在正样本中,特征参数“服务请求者的完单量”是远远小于X阈值。那么该节点不符合样本的分布,会导致该模型过拟合。在一些实施例中,可以人工对训练得到的第一订单异常识别模型中的某节点进行验证。在一些实施例中,可以对训练得到的第一订单异常识别模型中的每一节点进行验证。
在760中,若节点处的判断条件及划分结果与所述样本的实际分布不一致,可以使用其他节点替换该节点。在一些实施例中,步骤720可以由第一订单异常识别模型训练模块430执行。在一些实施例中,可以利用该节点处的所有样本以及该节点的所有下层节点进行决策树训练获得新的子树。用所述新的子树代替原第一订单异常识别模型中的该节点及其下层节点组成的子树。例如,第一订单异常识别模型中的某节点的特征参数是“服务请求者的完单量”,该节点的下一级节点的特征参数是“服务请求者的被投诉次数”。验证发现,特征参数“服务请求者的完单量”对应的判断条件划分的结果与正样本的分布不一致,则将改特征参数对应的节点删除,将原下一级节点的特征参数是“服务请求者的被投诉次数”代替删除的节点。又例如,第一订单异常识别模型中的某节点的特征参数是“服务请求者的完单量”,该节点的下一级节点的特征参数是“服务请求者的被投诉次数”,再以下的节点包括“服务请求者或服务提供者的住址置信度”、“服务请求者或服务提供者的工作地点置信度”、“服务请求者或服务提供者的借贷情况”、“服务请求者或服务提供者的受教育程度”。可以理解为,特征参数“服务请求者的被投诉次数”、“服务请求者或服务提供者的住址置信度”、“服务请求者或服务提供者的工作地点置信度”、“服务请求者或服务提供者的借贷情况”、“服务请求者或服务提供者的受教育程度”对应的节点组成一棵子树。验证发现,特征参数“服务请求者的完单量”对应的判断条件划分的结果与正样本的分布不一致,则将该特征参数对应的节点删除,并且将特征参数“服务请求者的完单量”对应的原节点处的所有样本作为训练样本,对特征参数是“服务请求者的被投诉次数”、“服务请求者或服务提供者的住址置信度”、“服务请求者或服务提供者的工作地点置信度”、“服务请求者或服务提供者的借贷情况”、“服务请求者或服务提供者的受教育程度”对应的节点重新进行训练,获得新的子树。并将所述新子树作为模型中的新的子树代替原来以特征参数“服务请求者的完单量”对应的节点开始的子树。得到新的第一订单异常识别模型。
在一些实施例中,对第一订单异常识别模型中的每一个节点进行验证并优化,最终得到所有节点上的特征参数都符合样本实际分布的第一订单异常识别模型。在770中,第一订单异常识别模型验证完成后,训练结束。
需要注意的是,以上描述,仅为描述方便,并不能把本申请限制在所举实施例范围之内。可以理解,对于本领域的技术人员来说,在了解该***的原理后,可以在不背离这一原理的情况下,对实施上述方法和***的应用领域进行形式和细节上的各种修正和改变。
图8是根据本发明的一种实施例所示的确定第二订单异常识别模型的示例性流程图。在一些实施例中,流程800可以通过处理逻辑来执行,该处理逻辑可以包括硬件(例如,电路、专用逻辑、可编程逻辑、微代码等)、软件(运行在处理设备上以执行硬件模拟的指令)等或其任意组合。图7所示的用于识别订单异常的流程800中的一个或多个操作可以通过图1所示的道路信息***100实现。例如,流程800可以以指令的形式存储在存储设备130中,并由处理引擎112执行调用和/或执行(例如,图2所示的计算设备200的处理器220、图3所示的移动设备300的中央处理器340)。
在810中,可以获取历史订单。在一些实施例中,步骤810可以由第二订单异常识别模型训练模块440执行。在一些实施例中,第二订单异常识别模型可以获取和第一订单异常识别模型同样的历史订单作为训练样本。在一些实施例中,第二订单异常识别模型可以获取和第一订单异常识别模型不同的历史订单作为训练样本。在一些实施例中,第二订单异常识别模型的训练样本可以和第一订单异常识别模型的训练样本有重叠。在一些实施例中,第二订单异常识别模型训练模块440可以和第一订单异常识别模型训练模块430分别获取历史订单。在一些实施例中,第二订单异常识别模型训练模块440可以直接获取第一订单异常识别模型训练模块430获取的历史订单。
在820中,可以获取与历史订单相关的特征参数。在一些实施例中,步骤810可以由第二订单异常识别模型训练模块440执行。在一些实施例中特征参数可以包括上述服务时间、服务地点、服务请求者或服务提供者在平台上的操作行为、服务请求者或服务提供者的个人信息或服务请求者者对服务的订制要求等与订单相关的特征参数。例如,下单时间、订单执行时间、行驶路线相关地点的偏僻度、行程长度、一定时间范围内服务请求者或服务提供者的取消订单频率、一定时间范围内服务请求者或服务提供者的完单量、服务请求者或服务提供者的性别、服务请求者或服务提供者的注册时间、服务请求者或服务提供者的住址置信度、服务请求者或服务提供者的工作地点置信度、服务请求者或服务提供者的借贷情况、服务请求者或服务提供者的受教育程度、一定时间范围内服务请求者或服务提供者被投诉次数、一定时间范围内服务请求者或服务提供者的被评价情况、服务请求者对服务工具的订制要求或对服务提供者的订制要求等。在一些实施例中,第二订单异常识别模型的特征参数可以和第一订单异常识别的特征参数相同。在一些实施例中,第二订单异常识别模型的特征参数可以和第一订单异常识别的特征参数不同。在一些实施例中,第二订单异常识别模型的特征参数可以和第一订单异常识别模型的特征参数有重叠。
在830中,可以将所述历史订单中的订单异常标记为正样本,所述历史订单中的正常订单标记为负样本。在一些实施例中,步骤810可以由第二订单异常识别模型训练模块440执行。在一些实施例中,可以人为对历史订单进行标记。例如,在训练样本中,2017年2月8日当天发生了一起订单异常,已获取了2017年2月8日当天的所有历史订单作为样本,可以将2017年2月8日当天的订单异常标记为正样本,将当天的其他正常订单标记为负样本。在一些实施例中,可以根据***100中的记录结果进行标记,将记录中出现恶性事件的历史订单标记为正样本。将记录中正常的订单标记为负样本。在一些实施例中,可以将正样本用数字“1”表示,将负样本用数字“0”表示。
在840中,可以基于所述历史订单中的所述特征参数及标记结果训练第二初始模型获得所述第二订单异常识别模型。在一些实施例中,步骤810可以由第二订单异常识别模型训练模块440执行。在一些实施例中,第二订单异常识别模型可以是逻辑回归模型。在一些实施例中,在训练过程中,可以利用验证集对模型进行验证,并根据验证结果(例如,模型处于欠拟合和/或过拟合状态)对模型参数进行调整以使模型达到最佳状态。所述验证集中的数据与所述第二初始模型的训练数据独立同分布,且没有交集。在一些实施例中,当满足预设条件时,可以停止模型训练,并将最终的模型作为所述第二订单异常识别模型输出。在一些实施例中,可以采用贪心算法对模型进行优化。在一些实施例中,可以通过极大似然估计法确定模型中的特征参数。在一些实施例中,可以采用对数似然函数,即
Figure BDA0001891020080000391
计算。
需要注意的是,以上描述,仅为描述方便,并不能把本申请限制在所举实施例范围之内。可以理解,对于本领域的技术人员来说,在了解该***的原理后,可以在不背离这一原理的情况下,对实施上述方法和***的应用领域进行形式和细节上的各种修正和改变。
图9是根据本发明的一种实施例所示的订单风险管控的示例性流程图。在一些实施例中,流程900可以通过处理逻辑来执行,该处理逻辑可以包括硬件(例如,电路、专用逻辑、可编程逻辑、微代码等)、软件(运行在处理设备上以执行硬件模拟的指令)等或其任意组合。图9所示的用于识别订单异常的流程900中的一个或多个操作可以通过图1所示的道路信息***100实现。例如,流程900可以以指令的形式存储在存储设备130中,并由处理引擎112执行调用和/或执行(例如,图2所示的计算设备200的处理器220、图3所示的移动设备300的中央处理器340)。
在910中,可以获取服务请求者的服务请求。在一些实施例中,可以由第二获取模块510执行该步骤。在一些实施例中,所述服务请求至少包括服务时间与服务地点。在一些实施例中,服务时间可以是服务请求者下单的时间。在一些实施例中,服务时间可以是所述订单执行的时间。在一些实施例中,服务地点可以是服务开始的地点、服务终止的地点、服务执行过程的地点。以网约车为例,服务地点可以是起点、终点、行驶路径的途径地点、行程长度等信息。在一些实施例中,还可以获取服务请求者或服务提供者在平台上的操作行为、服务请求者或服务提供者的个人信息或服务请求者对服务的订制要求等信息。
在920中,可以基于所述服务请求生成服务订单并发送给服务器。在一些实施例中,920可以由服务订单生成模块520执行。在一些实施例中,可以根据服务时间、服务地点等信息生成服务订单。在一些实施例中,服务器接收到服务订单后,可以将该服务订单作为待测订单进行订单异常的识别。
在930中,可以接收服务器发送的对所述服务订单的异常识别结果或者与所述异常识别结果相关的风险管控指示。在一些实施例中,930可以由风险管控接收模块530执行。在一些实施例中,异常识别结果相关的风险管控指示可以包括警示信息。以网约车服务为例,在乘客端,可以发出警示信息“滴滴提醒您,当前订单疑似异常,为保障夜间行车安全,滴滴平台将携手警方,全程保护您和司机的安全!”或“滴滴携手警方提醒您:由于您的行程短期内存在异常,触发滴滴安全守护!***会全程关您和司机的安全,如有异常情况,会及时同步公安机关,100%快速定位寻踪!滴滴权利配合警方,共同守护出行安全!”。在司机端,警示信息可以为“滴滴提醒您,为保障夜间行车安全,滴滴平台将携手警方,全程保护您和乘客的安全”。在一些实施例中,不同的警示信息可以表示订单异常的异常度不同。在一些实施例中,警示信息可以是声音提示、语音提示、灯光提示、用户终端振动提示等中的一种或多种方式的组合。在一些实施中,与所述异常识别结果相关的风险管控指示可以是身份验证请求。在一些实施例中,身份验证请求可以是要求服务请求者和/或服务提供者上传身份证件、进行人脸识别、服务请求者和/或服务提供者语音识别、车辆证明证件、车辆信息识别等方式中的一种或多种的组合。以网约车为例,可以在乘客端要求乘客上传身份证件进行实名认证,还可以要求乘客进行人脸识别。可以在司机端要求司机上传身份证件进行实名认证,还可以要求司机进行人脸识别。或是要求司机上传车辆证明证件。在一些实施例中,服务请求者和/或服务提供者履行身份验证后,可以收到验证通过的信息,或是验证没有通过的信息。还可以是直接收到订单进行的信息或是订单已终止的信息。在一些实施例中,服务请求者和/或服务提供者没有履行身份验证的请求,可以收到订单已终止的信息。在一些实施例中,与所述异常识别结果相关的风险管控指示可以包括在订单被执行时服务请求者和/或服务提供者的行为信息传输请求。以网约车服务为例,可以在行驶过程中,要求实时传输行驶路径和车辆的当前位置,传输行驶路径是否意外中断或停止的信息,传输订单修改信息,传输订单意外中断或取消信息等。还可以要求全程传输车辆内的乘客和司机的行为信息、意外求救信息等。在一些实施例中,用户终端可以直接接收订单终止的信息。例如,在网约车服务中,如果识别结果是待测订单为订单异常,并且异常度极高,服务器可以直接停止派单,并向用户终端发出订单终止的信息。在一些实施例中,用户终端收到的警示信息可以对服务请求者进行震慑,对服务提供者进行安全提醒。也可以是对服务提供者进行震慑,对服务请求者进行安全提醒。
需要注意的是,以上描述,仅为描述方便,并不能把本申请限制在所举实施例范围之内。可以理解,对于本领域的技术人员来说,在了解该***的原理后,可以在不背离这一原理的情况下,对实施上述方法和***的应用领域进行形式和细节上的各种修正和改变。
本申请实施例可能带来的有益效果包括但不限于:(1)本申请中采用两种模型进行订单异常的识别,并在确定第一订单异常识别模型的过程中,进行了人工验证和优化,提高了识别的准确性,改善了因正样本数量很少导致的模型的过拟合问题。(2)本申请还提供了根据不同的异常识别结果进行不同的风险管控策略,对异常订单进行控制管理,进一步防止恶性事件的发生。需要说明的是,不同实施例可能产生的有益效果不同,在不同的实施例里,可能产生的有益效果可以是以上任意一种或几种的组合,也可以是其他任何可能获得的有益效果。
上文已对基本概念做了描述,显然,对于本领域技术人员来说,上述发明披露仅仅作为示例,而并不构成对本申请的限定。虽然此处并没有明确说明,本领域技术人员可能会对本申请进行各种修改、改进和修正。该类修改、改进和修正在本申请中被建议,所以该类修改、改进、修正仍属于本申请示范实施例的精神和范围。
同时,本申请使用了特定词语来描述本申请的实施例。如“一个实施例”、“一实施例”和/或“一些实施例”意指与本申请至少一个实施例相关的某一特征、结构或特点。因此,应强调并注意的是,本说明书中在不同位置两次或多次提及的“一实施例”或“一个实施例”或“一替代性实施例”并不一定是指同一实施例。此外,本申请的一个或多个实施例中的某些特征、结构或特点可以进行适当的组合。此外,除非权利要求中明确说明,本申请所述处理元素和序列的顺序、数字字母的使用或其他名称的使用,并非用于限定本申请流程和方法的顺序。尽管上述披露中通过各种示例讨论了一些目前认为有用的发明实施例,但应当理解的是,该类细节仅起到说明的目的,附加的权利要求并不仅限于披露的实施例,相反,权利要求旨在覆盖所有符合本申请实施例实质和范围的修正和等价组合。例如,虽然以上所描述的***组件可以通过硬件设备实现,但是也可以只通过软件的解决方案得以实现,如在现有的服务器或移动设备上安装所描述的***。
同理,应当注意的是,为了简化本申请披露的表述,从而帮助对一个或多个发明实施例的理解,前文对本申请实施例的描述中,有时会将多种特征归并至一个实施例、附图或对其的描述中。但是,这种披露方法并不意味着本申请对象所需要的特征比权利要求中提及的特征多。实际上,实施例的特征要少于上述披露的单个实施例的全部特征。
一些实施例中使用了描述成分、属性数量的数字,应当理解的是,此类用于实施例描述的数字,在一些示例中使用了修饰词“大约”、“近似”或“大体上”等来修饰。除非另外说明,“大约”、“近似”或“大体上”表明所述数字允许有±20%的变化。相应地,在一些实施例中,说明书和权利要求中使用的数值数据均为近似值,该近似值根据个别实施例所需特点可以发生改变。在一些实施例中,数值数据应考虑规定的有效数位并采用一般位数保留的方法。尽管本申请一些实施例中用于确认其范围广度的数值域和数据为近似值,在具体实施例中,此类数值的设定在可行范围内尽可能精确。
最后,应当理解的是,本申请中所述实施例仅用以说明本申请实施例的原则。其他的变形也可能属于本申请的范围。因此,作为示例而非限制,本申请实施例的替代配置可视为与本申请的教导一致。相应地,本申请的实施例不仅限于本申请明确介绍和描述的实施例。

Claims (34)

1.一种订单异常识别方法,其特征在于,包括:
获取待测订单;
获取与所述待测订单相关的特征参数;
利用第一订单异常识别模型处理所述特征参数中的至少一部分,获得第一识别结果;
利用第二订单异常识别模型处理所述特征参数中的至少一部分,获得第二识别结果;
联合所述第一识别结果及所述第二识别结果确定所述待测订单的异常识别结果;
其中,与所述待测订单相关的特征参数至少反映以下多种信息中的至少一个:服务时间、服务地点、服务请求者或服务提供者在平台上的操作行为、服务请求者或服务提供者的个人信息、或服务请求者对服务的订制要求。
2.根据权利要求1所述的方法,其特征在于,所述第一订单异常识别模型为分类模型,所述第二订单异常识别模型为回归模型。
3.根据权利要求1所述的方法,其特征在于,
当所述第一识别结果为所述待测订单是异常订单,则利用所述第二订单异常识别模型确定所述待测订单的异常度,并将所述异常度作为所述待测订单的异常识别结果;
当所述第一识别结果为所述待测订单不是异常订单,则将所述待测订单为正常订单作为所述待测订单的异常识别结果。
4.根据权利要求1所述的方法,其特征在于,还包括:
基于所述待测订单的异常识别结果确定并执行风险管控策略。
5.根据权利要求4所述的方法,其特征在于,
所述风险管控策略至少包括以下策略中的一种或多种的组合:向服务请求者和/或服务提供者发出警示信息,对服务请求者和/或服务提供者进行身份验证,在订单被执行时对服务请求者和/或服务提供者的行为进行监控,或不将订单指派给服务提供者。
6.根据权利要求1所述的方法,其特征在于,所述特征参数包括以下至少一个:
下单时间、订单执行时间、行驶路线相关地点的偏僻度、行程长度、一定时间范围内服务请求者或服务提供者的取消订单频率、一定时间范围内服务请求者或服务提供者的完单量、服务请求者或服务提供者的性别、服务请求者或服务提供者的注册时间、服务请求者或服务提供者的住址置信度、服务请求者或服务提供者的工作地点置信度、服务请求者或服务提供者的借贷情况、服务请求者或服务提供者的受教育程度、一定时间范围内服务请求者或服务提供者被投诉次数、一定时间范围内服务请求者或服务提供者的被评价情况、服务请求者对服务工具的订制要求或对服务提供者的订制要求。
7.根据权利要求6所述的方法,其特征在于,
行驶路线相关地点的偏僻度与一定时间内距离该地点一定范围内的订单数量负相关;所述行驶路线相关地点包括以下中的至少一个:起点、终点或途径地点。
8.根据权利要求1所述的方法,其特征在于,所述第一订单异常识别模型通过以下方法获得:
获取历史订单;
获取与所述历史订单相关的所述特征参数;
将所述历史订单中的异常订单标记为正样本,所述历史订单中的正常订单标记为负样本;
基于所述历史订单中的所述特征参数及标记结果训练第一初始模型得到所述第一订单异常识别模型。
9.根据权利要求8所述的方法,其特征在于,
所述第一订单异常识别模型为决策树模型。
10.根据权利要求9所述的方法,其特征在于,还包括第一订单异常识别模型优化过程,其包括:
验证第一订单异常识别模型中某节点处的判断条件及划分结果是否与所述样本的分布一致;所述第一订单异常识别模型中的节点与所述特征参数对应;
若不一致,则使用其他节点替换该节点。
11.根据权利要求10所述的方法,其特征在于,所述使用其他节点替换该节点还包括:
利用该节点处的所有样本以及该节点的所有下层节点进行决策树训练获得新的子树;
用所述新的子树代替原第一订单异常识别模型中的该节点及其下层节点组成的子树。
12.根据权利要求1所述的方法,其特征在于,所述第二订单异常识别模型通过以下方法获得,包括:
获取历史订单;
获取与历史订单相关的所述特征参数;
将所述历史订单中的订单异常标记为正样本,所述历史订单中的正常订单标记为负样本;
基于所述历史订单中的所述特征参数及标记结果训练第二初始模型获得所述第二订单异常识别模型。
13.根据权利要求12所述的方法,其特征在于,
所述第二订单异常识别模型为逻辑回归模型。
14.一种订单异常识别***,其特征在于,包括:
第一获取模块,包括待测订单获取单元和特征参数获取单元;所述待测订单获取单元用于获取待测订单,所述特征参数获取单元用于获取与所述待测订单相关的特征参数;
订单异常识别模块,用于利用第一订单异常识别模型处理所述特征参数中的至少一部分,获得第一识别结果;利用第二订单异常识别模型处理所述特征参数中的至少一部分,获得第二识别结果;联合所述第一识别结果及所述第二识别结果确定所述待测订单的异常识别结果;
其中,与所述待测订单相关的特征参数至少反映以下多种信息中的至少一个:服务时间、服务地点、服务请求者或服务提供者在平台上的操作行为、服务请求者或服务提供者的个人信息、或服务请求者对服务的订制要求。
15.根据权利要求14所述的***,其特征在于,所述第一订单异常识别模型为分类模型,所述第二订单异常识别模型为回归模型。
16.根据权利要求14所述的***,其特征在于,所述订单异常识别模块,还用于:
当所述第一识别结果为所述待测订单是异常订单,则利用所述第二订单异常识别模型确定所述待测订单的异常度,并将所述异常度作为所述待测订单的异常识别结果;
当所述第一识别结果为所述待测订单不是异常订单,则将所述待测订单为正常订单作为所述待测订单的异常识别结果。
17.根据权利要求14所述的***,其特征在于,
还包括管控策略执行模块,所述管控策略执行模块用于基于所述待测订单的异常识别结果确定并执行风险管控策略。
18.根据权利要求17所述的***,其特征在于,
所述风险管控策略至少包括以下策略中的一种或多种的组合:向服务请求者和/或服务提供者发出警示信息,对服务请求者和/或服务提供者进行身份验证,在订单被执行时对服务请求者和/或服务提供者的行为进行监控,或不将订单指派给服务提供者。
19.根据权利要求14所述的***,其特征在于,所述特征参数包括以下至少一个:
下单时间、订单执行时间、行驶路线相关地点的偏僻度、行程长度、一定时间范围内服务请求者或服务提供者的取消订单频率、一定时间范围内服务请求者或服务提供者的完单量、服务请求者或服务提供者的性别、服务请求者或服务提供者的注册时间、服务请求者或服务提供者的住址置信度、服务请求者或服务提供者的工作地点置信度、服务请求者或服务提供者的借贷情况、服务请求者或服务提供者的受教育程度、一定时间范围内服务请求者或服务提供者被投诉次数、一定时间范围内服务请求者或服务提供者的被评价情况、服务请求者对服务工具的订制要求或对服务提供者的订制要求。
20.根据权利要求19所述的***,其特征在于,
行驶路线相关地点的偏僻度与一定时间内距离该地点一定范围内的订单数量负相关;所述行驶路线相关地点包括以下中的至少一个:起点、终点或途径地点。
21.根据权利要求14所述的***,其特征在于,还包括第一订单异常识别模型训练模块,所述第一订单异常识别模型训练模块用于:
获取历史订单;
获取与所述历史订单相关的所述特征参数;
将所述历史订单中的异常订单标记为正样本,所述历史订单中的正常订单标记为负样本;
基于所述历史订单中的所述特征参数及标记结果训练第一初始模型得到所述第一订单异常识别模型。
22.根据权利要求21所述的***,其特征在于,
所述第一订单异常识别模型为决策树模型。
23.根据权利要求22所述的***,其特征在于,所述第一订单异常识别模型训练模块还用于:
验证第一订单异常识别模型中某节点处的判断条件及划分结果是否与所述样本的分布一致;所述第一订单异常识别模型中的节点与所述特征参数对应;
若不一致,则使用其他节点替换该节点。
24.根据权利要求23所述的***,其特征在于,所述第一订单异常识别模型训练模块还用于:
利用该节点处的所有样本以及该节点的所有下层节点进行决策树训练获得新的子树;
用所述新的子树代替原第一订单异常识别模型中的该节点及其下层节点组成的子树。
25.根据权利要求14所述的***,其特征在于,还包括第二订单异常识别模型训练模块,所述第二订单异常识别模型训练模块用于:
获取历史订单;
获取与历史订单相关的所述特征参数;
将所述历史订单中的异常订单标记为正样本,所述历史订单中的正常订单标记为负样本;
基于所述历史订单中的所述特征参数及标记结果训练第二初始模型获得所述第二订单异常识别模型。
26.根据权利要求25所述的***,其特征在于,
所述第二订单异常识别模型为逻辑回归模型。
27.一种订单异常识别装置,其特征在于,包括至少一个处理器以及至少一个存储器;
所述至少一个存储器用于存储指令;
所述处理器用于执行所述指令,实现如权利要求1至13中任一项所述方法。
28.一种计算机可读存储介质,其特征在于,所述存储介质存储计算机指令,当计算机读取存储介质中的计算机指令后,计算机运行如权利要求1至13中任意一项所述方法。
29.一种订单风险管控方法,其特征在于,包括:
获取服务请求者的服务请求;所述服务请求至少包括服务时间与服务地点;
基于所述服务请求生成服务订单并发送给服务器;
接收服务器发送的对所述服务订单的异常识别结果或者与所述异常识别结果相关的风险管控指示。
30.根据权利要求29所述的方法,其特征在于,与所述异常识别结果相关的风险管控指示包括警示信息、身份验证请求或在订单被执行时服务请求者和/或服务提供者的行为信息传输请求中的一种或多种的组合。
31.一种订单风险管控***,其特征在于,包括:
第二获取模块,用于获取服务请求者的服务请求;所述服务请求至少包括服务时间与服务地点;
服务订单生成模块,用于基于所述服务请求生成服务订单并发送给服务器;
风险管控接收模块,用于接收服务器发送的对所述服务订单的异常识别结果或者与所述异常识别结果相关的风险管控指示。
32.根据权利要求31所述的***,其特征在于,与所述异常识别结果相关的风险管控指示包括警示信息、身份验证请求或在订单被执行时服务请求者和/或服务提供者的行为信息传输请求中的一种或多种的组合。
33.一种订单风险管控装置,其特征在于,包括至少一个处理器以及至少一个存储器;
所述至少一个存储器用于存储指令;
所述处理器用于执行所述指令,实现如权利要求29至30中任一项所述方法。
34.一种计算机可读存储介质,其特征在于,所述存储介质存储计算机指令,当计算机读取存储介质中的计算机指令后,计算机运行如权利要求29至30中任意一项所述方法。
CN201811471339.4A 2018-12-04 2018-12-04 一种订单异常识别和订单风险管控的方法及其*** Pending CN111275507A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201811471339.4A CN111275507A (zh) 2018-12-04 2018-12-04 一种订单异常识别和订单风险管控的方法及其***

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201811471339.4A CN111275507A (zh) 2018-12-04 2018-12-04 一种订单异常识别和订单风险管控的方法及其***

Publications (1)

Publication Number Publication Date
CN111275507A true CN111275507A (zh) 2020-06-12

Family

ID=70999971

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201811471339.4A Pending CN111275507A (zh) 2018-12-04 2018-12-04 一种订单异常识别和订单风险管控的方法及其***

Country Status (1)

Country Link
CN (1) CN111275507A (zh)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112966838A (zh) * 2021-03-03 2021-06-15 中国联合网络通信集团有限公司 灾害智能运维派单方法、装置及设备
CN113379497A (zh) * 2021-06-11 2021-09-10 口碑(上海)信息技术有限公司 订单调控方法、装置、计算机设备及计算机可读存储介质
CN117575546A (zh) * 2024-01-17 2024-02-20 北京白龙马云行科技有限公司 一种网约车平台用后台管理***

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105243838A (zh) * 2015-11-09 2016-01-13 北京奇虎科技有限公司 车辆行驶安全监控方法和装置、***
CN106503562A (zh) * 2015-09-06 2017-03-15 阿里巴巴集团控股有限公司 一种风险识别方法及装置
US20170234689A1 (en) * 2016-02-15 2017-08-17 Allstate Insurance Company Real Time Risk Assessment and Operational Changes with Semi-Autonomous Vehicles
CN107301433A (zh) * 2017-07-14 2017-10-27 南京华苏科技有限公司 基于聚类判别模型的网约车鉴别方法和***
CN107391569A (zh) * 2017-06-16 2017-11-24 阿里巴巴集团控股有限公司 数据类型的识别、模型训练、风险识别方法、装置及设备
CN108810804A (zh) * 2018-06-13 2018-11-13 陈磊 一种基于网约车平台的智能防护方法及其***
CN108877146A (zh) * 2018-09-03 2018-11-23 深圳市尼欧科技有限公司 一种基于智能语音识别的乘驾安全自动报警装置及其方法

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106503562A (zh) * 2015-09-06 2017-03-15 阿里巴巴集团控股有限公司 一种风险识别方法及装置
CN105243838A (zh) * 2015-11-09 2016-01-13 北京奇虎科技有限公司 车辆行驶安全监控方法和装置、***
US20170234689A1 (en) * 2016-02-15 2017-08-17 Allstate Insurance Company Real Time Risk Assessment and Operational Changes with Semi-Autonomous Vehicles
CN107391569A (zh) * 2017-06-16 2017-11-24 阿里巴巴集团控股有限公司 数据类型的识别、模型训练、风险识别方法、装置及设备
CN107301433A (zh) * 2017-07-14 2017-10-27 南京华苏科技有限公司 基于聚类判别模型的网约车鉴别方法和***
CN108810804A (zh) * 2018-06-13 2018-11-13 陈磊 一种基于网约车平台的智能防护方法及其***
CN108877146A (zh) * 2018-09-03 2018-11-23 深圳市尼欧科技有限公司 一种基于智能语音识别的乘驾安全自动报警装置及其方法

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
冷婷;闫兴秀;余健;谈炜;孙娴;: "基于聚类判别模型的网约车鉴别研究" *

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112966838A (zh) * 2021-03-03 2021-06-15 中国联合网络通信集团有限公司 灾害智能运维派单方法、装置及设备
CN112966838B (zh) * 2021-03-03 2024-02-20 中国联合网络通信集团有限公司 灾害智能运维派单方法、装置及设备
CN113379497A (zh) * 2021-06-11 2021-09-10 口碑(上海)信息技术有限公司 订单调控方法、装置、计算机设备及计算机可读存储介质
CN113379497B (zh) * 2021-06-11 2023-12-26 口碑(上海)信息技术有限公司 订单调控方法、装置、计算机设备及计算机可读存储介质
CN117575546A (zh) * 2024-01-17 2024-02-20 北京白龙马云行科技有限公司 一种网约车平台用后台管理***
CN117575546B (zh) * 2024-01-17 2024-04-05 北京白龙马云行科技有限公司 一种网约车平台用后台管理***

Similar Documents

Publication Publication Date Title
US10518655B2 (en) System and method for electric vehicle mobile payment
US20220114894A1 (en) Tracking and analysis of drivers within a fleet of vehicles
US9959505B1 (en) High value information alert and reporting system and method
US9558520B2 (en) System and method for geocoded insurance processing using mobile devices
US20160358129A1 (en) Methods and systems for fleet management
US10217169B2 (en) Computer system for determining geographic-location associated conditions
US8788375B2 (en) Method and system for pre-populating job assignment submissions
US20110213628A1 (en) Systems and methods for providing a safety score associated with a user location
JP6058139B2 (ja) 公共輸送機関ナビゲータ
US20100030582A1 (en) Centrally maintained portable driving score
CN110992072A (zh) 异常订单预测方法和***
Jamil Uber and the making of an Algopticon-Insights from the daily life of Montreal drivers
Zhang et al. Traveler information tool with integrated real-time transit information and multimodal trip planning: Design and implementation
US20200118444A1 (en) Roadside assistance program
CN111275507A (zh) 一种订单异常识别和订单风险管控的方法及其***
CN110782111A (zh) 一种风险评估方法和***
CN111598371A (zh) 一种风险防范方法、***、装置及存储介质
CN111598641A (zh) 一种订单风险验证方法和***
CN110992119A (zh) 一种对风险订单进行排序的方法和***
US20190265054A1 (en) Passenger transport route management system and method
CN111598642A (zh) 一种风险判定方法、***、装置及存储介质
Sun et al. On the tradeoff between sensitivity and specificity in bus bunching prediction
CN111598370A (zh) 一种女性安全风险防范方法和***
JP2022040045A (ja) 輸送機への電力割り当て
CN102880943A (zh) 校车运营管理方法及***

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
RJ01 Rejection of invention patent application after publication

Application publication date: 20200612