通过打车订单识别醉酒乘客的人工智能系统和方法与流程

本申请通常涉及提供线上到线下服务的人工智能系统和方法，更具体地说，涉及识别打车订单的醉酒乘客的人工智能系统和方法。

背景技术：

随着互联网技术的发展，线上到线下(o2o)服务(如在线打车服务)在人们的日常生活中发挥着越来越重要的作用。随着在线打车订单的增加，请求在线打车服务的乘客与提供此类服务的司机之间的冲突发生得越来越频繁。大部分冲突都是由醉酒乘客引起的。因此，乘客醉酒引起的冲突需要引起重视。期望提供通过打车订单识别醉酒乘客的人工智能系统和方法。

技术实现要素：

本申请的一个方面介绍了一种识别打车订单的醉酒乘客的系统。该系统可以包括至少一个存储介质，其包括用于识别打车订单的醉酒乘客的一组指令；以及至少一个与所述存储介质通信的处理器。当执行所述指令时，所述至少一个处理器可以执行以下操作。所述至少一个处理器可以从存储在数据库中的历史打车订单中，获取至少两个样本。对于所述至少两个样本中的每一个样本，所述至少一个处理器可以使用应用程序来提取包括乘客特征集、司机特征集和订单特征集的至少两个特征。所述订单特征集可以包括与醉酒热区相关的特征；所述至少一个处理器可以基于所述至少两个特征和所述至少两个样本，训练初始分类模型以获取醉酒模型。

在一些实施例中，所述至少两个样本可以包括正样本集和负样本集。所述正样本集包括至少两个历史醉酒打车订单。所述负样本集包括至少两个历史非醉酒打车订单。

在一些实施例中，所述乘客特征集可以包括任一乘客的基本特征以及与所述任一乘客的历史订单相关的特征。所述司机特征集可以包括任一司机的基本特征以及与所述任一司机的历史订单相关的特征。所述订单特征集还可以包括任一订单的基本特征。

在一些实施例中，所述至少一个处理器还可以基于至少两个历史代驾订单，识别至少两个醉酒热区。

在一些实施例中，为了识别所述至少两个醉酒热区，所述至少一个处理器还可以从所述至少两个历史代驾订单中，获取至少两个历史醉酒代驾订单。所述至少两个历史醉酒代驾订单中的每一个历史醉酒代驾订单可以包括起始位置。所述至少一个处理器还可以基于所述至少两个历史醉酒代驾订单的所述起始位置，识别至少两个区域。对于所述至少两个区域中的每一个区域，至少一个处理器还可以确定所述区域是否满足预定条件。响应于所述区域满足所述预定条件的确定结果，所述至少一个处理器可以将所述区域指定为所述至少两个醉酒热区中的一个醉酒热区。

在一些实施例中，所述预定条件可以包括所述区域中的历史醉酒代驾订单的数量大于数量阈值，或者历史醉酒投诉打车订单的数量与历史醉酒代驾订单的数量的比率大于比率阈值。

在一些实施例中，为了提取所述至少两个特征，对于所述至少两个样本中的每一个样本，所述至少一个处理器还可以识别起始位置。所述至少一个处理器还可以将所述起始位置映射到醉酒热区。所述至少一个处理器可以基于所述醉酒热区，提取所述与醉酒热区相关的特征。

在一些实施例中，所述初始分类模型可以是梯度提升决策树(gbdt)模型。

在一些实施例中，所述至少一个处理器还可以从乘客的乘客终端获取打车订单。所述至少一个处理器可以基于所述打车订单和所述醉酒模型，确定所述乘客是否醉酒。

在一些实施例中，为了确定所述乘客是否醉酒，所述至少一个处理器还可以获取所述乘客的醉酒概率。所述打车订单是所述醉酒模型的输入，所述醉酒概率是所述醉酒模型的输出。所述至少一个处理器可以判断所述醉酒概率是否大于概率阈值。响应于所述醉酒概率大于所述概率阈值的确定结果，所述至少一个处理器可以确定所述乘客是醉酒的。

在一些实施例中，响应于所述乘客醉酒的确定结果，所述至少一个处理器还可以向所述打车订单的司机的司机终端发送提示，所述提示显示在所述司机终端的司机界面上。

根据本申请的另一方面，一种识别打车订单的醉酒乘客的方法可以包括从存储在数据库中的历史打车订单中，获取至少两个样本；对于所述至少两个样本中的每一个样本，使用应用程序，提取包括乘客特征集、司机特征集和订单特征集的至少两个特征，其中，所述订单特征集包括与醉酒热区相关的特征；以及基于所述至少两个特征和所述至少两个样本，训练初始分类模型以获取醉酒模型。

根据本申请的另一方面，一种非暂时性计算机可读介质，包括至少一组兼容用于识别打车订单的醉酒乘客的指令。当由电子设备的至少一个处理器执行时，所述至少一组指令指示所述至少一个处理器以执行方法。所述方法可以包括从存储在数据库中的历史打车订单中，获取至少两个样本；对于所述至少两个样本中的每一个样本，使用应用程序，提取包括乘客特征集、司机特征集和订单特征集的至少两个特征，其中，所述订单特征集包括与醉酒热区相关的特征；以及基于所述至少两个特征和所述至少两个样本，训练初始分类模型以获取醉酒模型。

根据本申请的又一方面，一种识别打车订单的醉酒乘客的系统可以包括模型训练模块。所述模型训练模块可以被配置为从存储在数据库中的历史打车订单中，获取至少两个样本。对于所述至少两个样本中的每一个样本，所述模型训练模块可以使用应用程序来提取至少两个特征。所述至少两个特征可以包括乘客特征集、司机特征集和订单特征集，其中，所述订单特征集可以包括与醉酒热区相关的特征。所述模型训练模块还可以基于所述至少两个特征和所述至少两个样本，训练初始分类模型以获取醉酒模型。

本申请的一部分附加特性可以在下面的描述中进行说明。通过对以下描述和相应附图的研究或者对实施例的生产或操作的了解，本申请的一部分附加特性对于本领域技术人员是明显的。本申请的特征可以通过对以下描述的具体实施例的各种方面的方法、手段和组合的实践或使用得以实现和达到。

附图说明

本申请将通过示例性实施例进行进一步描述。这些示例性实施例将通过附图进行详细描述。这些实施例是非限制性的示例性实施例，在附图多种视图下的实施例中，类似的编号代表类似的结构，其中：

图1是根据本申请一些实施例的示例性人工智能系统的示意图；

图2是根据本申请一些实施例的计算设备的示例性硬件和/或软件组件的示意图；

图3是根据本申请一些实施例的移动设备的示例性硬件和/或软件组件的示意图；

图4是根据本申请一些实施例的示例性处理引擎的框图；

图5是根据本申请一些实施例的获取醉酒模型的示例性过程的流程图

图6是根据本申请一些实施例的识别至少两个醉酒热区的示例性过程的流程图；

图7是根据本申请一些实施例的获取醉酒热区相关特征的示例性过程的流程图；

图8是根据本申请一些实施例的向司机的司机终端发送提示的示例性过程的流程图；以及

图9是根据本申请一些实施例的确定乘客是否醉酒的示例性过程的流程图。

具体实施方式

下述描述是为了使本领域技术人员能制造和使用本申请，并且该描述是在特定的应用场景及其要求的背景下提供的。对于本领域的普通技术人员来讲，显然可以对所披露的实施例做出各种改变，并且在不偏离本申请的原则和范围的情况下，本申请中所定义的普遍原则可以适用于其他实施例和应用场景。因此，本申请并不限于所描述的实施例，而应该被给予与权利要求一致的最广泛的范围。

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

根据以下对附图的描述，本发明所述的这些和其他特征，特性，以及相关结构原件的操作方法和功能、部件和经济性的组合更加显而易见，所有这些构成了本规范的一部分。然而，应当理解，附图仅仅是为了说明和描述的目的，并不旨在限制本申请的范围。应当理解的是，附图并不是按比例绘制的。

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

本申请的一个方面涉及识别打车订单的醉酒乘客的人工智能系统和方法。为此，该人工智能系统和方法可以使用与醉酒热区相关的特征来训练醉酒模型，并使用醉酒模型来预测请求打车订单的乘客是否醉酒。与醉酒热区相关的特征是通过将打车订单的起始位置映射到醉酒热区来提取的，该醉酒热区有足够多的历史醉酒代驾订单和/或足够大的历史醉酒投诉打车订单数量与历史醉酒代驾订单数量的比率。通过这种方式，该人工智能系统和方法可以通过乘客的叫车订单确定乘客是否醉酒，并当预测乘客醉酒时，采取必要的预防措施，减少乘客与被分配到该打车订单的汽车司机之间的冲突。

图1是根据本申请一些实施例的示例性人工智能(ai)系统100的示意图。例如，ai系统100可以是用于提供服务的线上到线下服务平台，如出租车呼叫、司机服务、送货车、拼车、公交车服务、雇佣司机、班车服务、在线导航服务、送货服务等。ai系统100可以包括服务器110、网络120、乘客终端130、存储器140和司机终端150。该服务器110可包含处理引擎112。

服务器110可以被配置为处理与打车订单有关的信息和/或数据。例如，服务器110可以确定发送打车订单的乘客是否醉酒。又例如，服务器110可以训练醉酒模型以确定乘客是否醉酒。作为又一示例，响应于该乘客醉酒，服务器110可以向接受该打车订单的司机的司机终端发送提示。在一些实施例中，服务器110可以是单个服务器，也可以是服务器组。所述服务器组可以是集中式的，也可以是分布式的(例如，服务器110可以是分布式的系统)。在一些实施例中，服务器110可以是本地的，也可以是远程的。例如，服务器110可以通过网络120访问存储于乘客终端130和/或存储器140的信息和/或数据。又例如，服务器110可以连接到乘客终端130和/或存储器140以访问存储的信息和/或数据。在一些实施例中，服务器110可以在云平台上实施。仅作为示例，所述云平台可以包括私有云、公共云、混合云、社区云、分布云、内部云、多层云等或其任意组合。在一些实施例中，服务器110可以在本申请中的图2描述的包含了一个或以上组件的计算设备200上执行。

在一些实施例中，服务器110可以包括处理引擎112。处理引擎112可以处理与打车订单有关的信息和/或数据，以执行本申请中描述的一个或以上的功能。例如，处理引擎112可以确定请求打车订单的乘客是否醉酒。又例如，处理引擎112可以训练醉酒模型以确定乘客是否醉酒。作为又一示例，响应于该乘客醉酒，服务器110可以向接受该打车订单的司机的司机终端发送提示。在一些实施例中，所述处理引擎112可包括一个或以上处理引擎(例如，单核处理引擎或多核处理引擎)。仅作为示例，处理引擎112可以包括一个或以上硬件处理器，例如中央处理单元(cpu)、特定应用集成电路(asic)、特定应用指令集处理器(asip)、图像处理单元(gpu)、物理运算处理单元(ppu)、数字信号处理器(dsp)、现场可程序门阵列(fpga)、可程序逻辑设备(pld)、控制器、微控制器单元、精简指令集计算机(risc)、微处理器等或其任意组合。

网络120可以促进信息和/或数据的交换。在一些实施例中，ai系统100的一个或以上组件(例如，服务器110、乘客终端130、存储器140和司机终端150)可以通过网络120将信息和/或数据发送到ai系统100中的其他组件。例如，服务器110可以通过网络120从乘客的乘客终端130获取打车订单。又例如，服务器110可以通过网络120将提示发送到该打车订单的司机的司机终端150。作为又一示例，服务器110可以通过网络120从存储器140获取至少两个样本以训练醉酒模型。在一些实施例中，网络120可以为任意形式的有线或无线网络，或其任意组合。仅作为示例，网络120可以包括缆线网络、有线网络、光纤网络、远程通信网络、内部网络、互联网、局域网络(lan)、广域网络(wan)、无线局域网络(wlan)、城域网(man)、公共开关电话网络(pstn)、蓝牙网络、紫蜂网络、近场通信(nfc)网络等或上述举例的任意组合。在一些实施例中，网络120可以包括一个或以上网络接入点。例如，网络120可以包括有线或无线网络接入点，例如基站和/或互联网交换点120-1、120-2、......，ai系统100的一个或以上组件可以通过它们连接到网络120，以在它们之间交换数据和/或信息。

乘客终端130可以是线上线到下服务的服务请求者(例如，打车服务的乘客)使用的任何电子设备。在一些实施例中，乘客终端130可以是移动设备130-1、平板电脑130-2、膝上型计算机130-3、台式计算机130-4等或其任意组合。在一些实施例中，该移动设备130-1可包括可穿戴设备、智慧移动设备、虚拟现实设备、增强现实设备等或其任意组合。在一些实施例中，该可穿戴设备可包括智能手环、智能鞋袜、智能眼镜、智能头盔、智能手表、智能穿着、智能背包、智能配件等或其任意组合。在一些实施例中，智能移动设备可以包括智能电话、个人数字助理(pda)、游戏设备、导航设备、销售点(pos)设备等或其任意组合。在一些实施例中，虚拟现实设备和/或增强现实设备可以包括虚拟现实头盔、虚拟现实眼镜、虚拟现实眼罩、增强现实头盔、增强现实眼镜、增强现实眼罩等或其任意组合。例如，虚拟现实设备和/或增强现实设备可以是googleglass^tm、riftcon^tm、fragments^tm、gearvr^tm等。在一些实施例中，台式计算机130-4可以是车载计算机/车载电视等。

在一些实施例中，乘客终端130可以是具有定位技术的设备，用于定位乘客和/或乘客终端130的位置。本申请中使用的定位技术可以包括全球定位系统(gps)、全球卫星导航系统(glonass)、北斗导航系统(compass)、伽利略定位系统、准天顶卫星系统(qzss)、无线保真(wi-fi)定位技术等或其任意组合。以上定位技术中的一个或以上可以在本申请中交换使用。

在一些实施例中，乘客终端130还可包括至少一个网络端口。所述至少一个网络端口可以被配置为通过网络120向ai系统100中的一个或以上组件(例如，服务器110、存储器140、司机终端150)发送信息和/或从其接收信息。在一些实施例中，乘客终端130可以在如图2中所示的具有一个或以上组件的计算设备200上实现，或者在本申请中如图3中所示的具有一个或以上组件的移动设备300上实现。

存储器140可以存储数据和/或指令。例如，存储器140可以存储历史打车订单和/或历史代驾订单。又例如，存储器140可以存储包括正样本集和负样本集的至少两个样本。作为又一个示例，存储器140可以存储用于确定乘客是否醉酒的醉酒模型。作为又一示例，存储器140可以存储服务器110可以执行或用于执行本申请中描述的示例性方法的数据和/或指令。在一些实施例中，存储器140可包括大容量存储器、可移动存储器、易失性读写存储器、只读存储器(rom)等或其任意组合。示例性的大容量存储器可以包括磁盘、光盘、固态磁盘等。示例性可移动存储器可以包括闪存驱动器、软盘、光盘、存储卡、压缩盘、磁带等。示例性易失性读写存储器可以包括随机存取内存(ram)。示例性ram可包括动态随机存取存储器(dram)、双倍数据速率同步动态随机存取存储器(ddrsdram)、静态随机存取存储器(sram)、晶闸管随机存取存储器(t-ram)和零电容随机存取存储器(z-ram)等。示例性只读存储器可以包括掩模型只读存储器(mrom)、可编程只读存储器(prom)、可擦除可编程只读存储器(perom)、电可擦除可编程只读存储器(eeprom)、光盘只读存储器(cd-rom)和数字多功能磁盘只读存储器等。在一些实施例中，所述存储器140可在云平台上实现。仅作为示例，所述云平台可以包括私有云、公共云、混合云、社区云、分布云、内部云、多层云等或其任意组合。

在一些实施例中，存储器140可以包括至少一个网络端口，以与ai系统100中的其他设备通信。例如，存储器140可以连接到网络120，以通过至少一个网络端口与ai系统100的一个或以上组件(例如，服务器110、乘客终端130)通信。ai系统100中的一个或以上组件可以通过网络120访问存储在存储器140中的数据或指令。在一些实施例中，存储器140可以直接连接到ai系统100中的一个或以上组件(例如，服务器110、乘客终端130、司机终端150)或与之通信。在一些实施例中，存储器140可以是服务器110的一部分。

司机终端150可以是线上到线下服务的服务提供者使用的任何电子设备(例如，打车服务的司机)。在一些实施例中，司机终端150可以具有与乘客终端140相同或相似的配置。

在一些实施例中，ai系统100的一个或以上组件(例如，服务器110、乘客终端130、存储器140和司机终端150)可以通过有线和/或无线通信以电子和/或电磁信号的形式彼此通信。在一些实施例中，ai系统100还可包括至少一个数据交换端口。所述至少一个交换端口可以被配置为在ai系统100中的任何电子设备之间接收和/或发送与打车服务有关的信息(例如，以电子信号和/或电磁信号的形式)。在一些实施例中，至少一个数据交换端口可以是天线、网络接口、网络端口等中的一个或以上，或其任意组合。例如，至少一个数据交换端口可以是连接到服务器110的网络端口，以向其发送信息和/或接收从其发送的信息。

图2是计算设备200的示例性硬件和软件组件的示意图，在该计算设备200上根据本申请的一些实施例可以实现服务器110和/或乘客终端130。例如，处理引擎112可以在计算设备200上实现并被配置为实现本申请中所披露的功能。

计算设备200可用于实现本申请的ai系统100。计算设备200可用于实现ai系统100的任何组件，其执行本申请中披露的一个或以上功能。例如，处理引擎112可以在计算设备200上通过其硬件、软件程序、固件或其组合实现。为了方便，尽管仅示出了一个这样的计算机，但与本文所述的线上到线下服务有关的计算机功能可以在多个类似平台上以分布式方式实现，以分配处理负荷。

例如，计算设备200可以包括连接到与之连接的网络的com端口250，以便于数据通信。com端口250可以是任何网络端口或数据交换端口，以便于数据通信。计算设备200还可以包括处理器(例如，处理器220)，其形式为一个或以上处理器(例如，逻辑电路)，用于执行程序指令。例如，处理器可以包括接口电路和其中的处理电路。接口电路可以被配置为从总线210接收电信号，其中电信号编码用于处理电路的结构化数据和/或指令。处理电路可以进行逻辑计算，然后将结论、结果和/或指令编码确定为电信号。处理电路还可以生成包括结论或结果的电子信号(例如，提醒乘客醉酒的提示)和触发代码。在一些实施例中，触发代码可以是由ai系统100中的电子设备(例如，乘客终端130)的操作系统(或其中安装的应用程序)可识别的格式。例如，触发代码可以是指令、代码、标记、符号等，或其任意组合，该触发代码可以激活移动电话的某些功能和/或操作，或者让移动电话执行预定的程序。在一些实施例中，触发代码可以被配置为更新电子设备的操作系统(或应用程序)，以在电子设备的接口上生成结论或结果(例如，预测结果)的呈现。然后，接口电路可以通过总线210从处理电路发出电信号。

示例性计算设备可以包括内部通信总线210、不同形式的程序存储器和数据存储器，该程序存储器和数据存储器包括例如，盘270和只读存储器(rom)230或者随机存取存储器(ram)240，用于由计算设备处理和/或发送的各种数据文件。示例性计算设备也可以包括储存于rom230、ram240和/或其他形式的非暂时性存储介质中的能够被处理器220执行的程序指令。本申请的方法和/或流程可以以程序指令的方式实现。示例性计算设备还可以包括存储在rom230、ram240和/或其他类型的非暂时性存储介质中的由处理器220执行的操作系统。程序指令可以与提供线上到线下服务的操作系统兼容。计算设备200还包括i/o组件260，其支持计算机和其他组件之间的输入/输出。计算设备200还可以通过网络通信接收编程和数据。

仅用于说明，图2中仅示出了一个处理器。还考虑了多个处理器；因此，由本申请中描述的一个处理器执行的操作和/或方法步骤也可以由多个处理器联合或单独执行。例如，如果在本申请中，计算设备200的处理器执行步骤a和步骤b，应当理解的是，步骤a和步骤b也可以由计算设备200的两个不同的处理器共同地或独立地执行(例如，第一处理器执行步骤a，第二处理器执行步骤b，或者第一和第二处理器共同地执行步骤a和步骤b)。

图3是示出根据本申请的一些实施例的可以在其上实现乘客终端130的示例性移动设备300的示例性硬件和/或软件组件的示意图。

如图3所示，移动设备300可以包括通信平台310、显示器320、图形处理单元(gpu)330、中央处理单元(cpu)340、i/o350、内存360和存储器390。cpu可以包括接口电路和类似于处理器220的处理电路。在一些实施例中，任何其他合适的组件，包括但不限于系统总线或控制器(未示出)，也可包括在移动设备300内。在一些实施例中，移动操作系统370(例如，ios^tm、android^tm、windowsphone^tm等)和一个或以上应用程序380可以从存储器390加载到内存360中，以便由cpu340执行。应用程序380可以包括浏览器或用于接收和呈现与打车服务有关的信息的任何其他合适的移动应用程序。用户与信息流的交互可以通过i/o设备350实现，并通过网络120提供给处理引擎112和/或系统100的其他组件。

为了实现本申请中描述的各种模块、单元及其功能，计算机硬件平台可以用作一个或以上本文所述元件的硬件平台(例如，ai系统100和/或关于图1-9描述的ai系统100的其他组件)。这种计算机的硬件元件、操作系统和编程语言本质上是传统的，并且假设本领域普通技术人员对其进行了充分的熟悉以使这些技术适应以识别如本文所述打车订单的乘客是否醉酒。一台包含用户界面元素的计算机能够被用作个人计算机(pc)或其他类型的工作站或终端设备，被适当程序化后也可以作为服务器使用。相信本领域技术人员应该熟悉该计算机设备的结构、程序设计和一般操作，因此，附图对其应是不解自明的。

本领域的普通技术人员应当理解，当ai系统100的元件执行时，该元件可以通过电信号和/或电磁信号执行。例如，当服务器110处理任务时，例如确定打车订单的乘客是否醉酒，服务器110可以在其处理器中操作逻辑电路以处理这样的任务。当服务器110完成确定乘客醉酒时，服务器110的处理器可以产生编码提醒乘客醉酒的提示的电信号。然后，服务器110的处理器可以将电信号发送到与服务器110相关联的目标系统的至少一个数据交换端口。服务器110通过有线网络与目标系统通信，所述至少一个数据交换端口可以物理地连接到电缆，所述电缆还可以将电信号发送到乘客终端130的输入端口(例如，信息交换端口)。如果服务器110通过无线网络与目标系统通信，目标系统的至少一个数据交换端口可以是一个或以上天线，其可以将电信号转换为电磁信号。在电子设备内(例如，乘客终端130和/或服务器110)，当处理器处理指令、发出指令和/或执行动作时，指令和/或动作通过电信号进行。例如，当处理器从存储介质(例如，存储器140)中检索或保存数据时，它可以向存储介质的读/写设备发送电信号，其可以在存储介质中读取或写入结构数据。该结构数据可以通过电子设备的总线，以电信号的形式传输至处理器。这里，电信号可以是一个电信号、一系列电信号和/或至少两个分立的电信号。

图4是根据本申请的一些实施例所示的示例性处理引擎112的框图。如图4所示，处理引擎112可包括模型训练模块410、热区识别模块420、订单获取模块430、醉酒确定模块440和提示发送模块450。

模型训练模块410可以被配置为训练初始分类模型以获取醉酒模型。醉酒模型可用于预测打车订单的乘客是否醉酒。在一些实施例中，模型训练模块410可以从历史打车订单中获取至少两个样本。对于至少两个样本中的每一个，模型训练模块410可以提取包括乘客特征集、司机特征集和订单特征集中的至少两个特征。订单特征集可以包括与醉酒热区相关的特征。模型训练模块410可以进一步基于提取的特征和至少两个样本训练初始分类模型。在一些实施例中，模型训练模块410可识别至少两个样本中的每一个的起始位置。模型训练模块410可以将起始位置映射到醉酒热区，并基于醉酒热区提取与醉酒热区相关的特征。

热区识别模块420可以被配置为识别醉酒热区或非醉酒热区。醉酒热区可以指可能有大量醉酒者的区域。例如，醉酒热区可能包括比非醉酒热区更多的潜在醉酒乘客。在一些实施例中，热区识别模块420可以从至少两个历史代驾订单中获取至少两个历史醉酒代驾订单。历史代驾订单可以指历史请求者请求代驾服务的历史订单，代驾服务是指历史请求者请求代驾司机将与历史请求者相关联的车辆(例如，汽车)从起始位置驾驶到目的地的服务。历史醉酒代驾订单可以指其历史请求者是醉酒的历史代驾订单。热区识别模块420可以基于至少两个历史醉酒代驾订单的起始位置来识别至少两个区域。对于至少两个区域中的每一个，热区识别模块420可以确定该区域是否是醉酒热区，例如，根据该区域的历史醉酒代驾订单的数量，或该区域的历史醉酒投诉打车订单的数量与该区域的历史醉酒代驾订单的数量的比率。

订单获取模块430可以被配置为从乘客的乘客终端获取打车订单。打车订单可以是实时打车订单或预定时段(例如，从晚上7点到晚上11点的晚高峰)内的打车订单。

醉酒确定模块440可以被配置为基于打车订单和醉酒模型确定打车订单的乘客是否醉酒。在一些实施例中，醉酒确定模块440可以将打车订单输入到醉酒模型中，并且醉酒模型可以输出乘客的醉酒概率或醉酒类别。醉酒确定模块440可以进一步基于乘客的醉酒概率或醉酒类别来确定乘客是否醉酒。

提示发送模块450可以被配置为向打车订单的司机的司机终端发送提示。在一些实施例中，提示发送模块450可以在确定乘客醉酒时发送提示。提示可以显示在司机终端的司机界面上。在一些实施例中，提示可以包括乘客醉酒的通知，提醒司机注意避免冲突的提示等或其任意组合。

处理引擎112中的模块可以通过有线连接或无线连接以互相连接或互相通信。有线连接可以包括金属线缆、光缆、混合电缆等或其任意组合。无线连接可以包括局域网络(lan)、广域网络(wan)、蓝牙、紫蜂网络、近场通信(nfc)等或其任意组合。两个或以上模块可以被组合为单个模块，且所述模块中的任意一个模块可以被分成两个或以上单元。例如，模型训练模块410可以分成两个或以上单元，用于分别提取特征和训练模型。又如此，处理引擎112可以包括用于存储与打车服务有关的数据和/或信息的存储模块(未示出)。

图5是根据本申请的一些实施例的用于获取醉酒模型的示例性过程500的流程图。过程500可以由ai系统100执行。例如，过程500可以实现为存储在存储器rom230或ram240中的一组指令(例如，应用程序)。处理器220可以执行该组指令，并且当执行指令时，可以将其配置为执行过程500。以下所示过程的操作仅出于说明的目的。在一些实施例中，过程500可以通过未描述的一个或以上附加操作和/或去掉一个或以上所讨论的操作的来完成。另外，如图5所示和下面描述的过程操作的顺序不是限制性的。

在510中，处理引擎112(例如，处理器220、模型训练模块410)可从存储在数据库中的历史打车订单中获取至少两个样本。

如这里所使用的，所述历史打车订单中的一个历史打车订单可以指已经完成的打车订单。在一些实施例中，历史打车订单可包括与历史打车订单相关联的信息，例如与乘客相关的信息(例如，请求历史打车服务的乘客)、与司机相关的信息(例如，为乘客提供历史打车服务的司机)以及历史打车订单的信息(例如，与历史打车订单相关联的时间信息、与历史打车订单相关联的位置信息或与历史打车订单相关联的乘车共享信息等)。在一些实施例中，历史打车订单可以是在预定时间段内的历史打车订单。例如，历史打车订单可以包括一年(例如，去年、当前年份、最近一年)、半年(例如，最近六个月、当年的上半年)、四分之一年(例如，最近三个月、当年的第二季度)等或其任意组合中的订单。在一些实施例中，历史打车订单可以存储在任何数据库或存储器(例如，存储器140、rom230、ram240等)中。

在一些实施例中，至少两个样本的每个样本可以对应于一个历史打车订单。在一些实施例中，至少两个样本可以对应于存储在数据库中的历史打车订单的一部分或全部。例如，至少两个样本的数量可以等于或小于历史打车订单的数量。又例如，处理引擎112可从历史打车订单中提取特定时间段内的至少两个样本(例如，从一天的晚上8点到第二天的凌晨4点、每天晚上等)。

在一些实施例中，至少两个样本可包括正样本集和负样本集。正样本集可以包括至少两个历史醉酒打车订单，并且负样本集可以包括至少两个历史非醉酒打车订单。历史醉酒订车订单可以指其乘客为醉酒乘客的历史打车订单。历史非醉酒打车订单可以指其乘客不是醉酒乘客的历史打车订单。在一些实施例中，至少两个历史醉酒打车订单的数量可以与至少两个历史非醉酒打车订单的数量相同或不同。

对于历史打车订单，处理引擎112可以获取与历史打车订单相关联的信息。例如，处理引擎112可以从历史打车订单的乘客和/或司机获取反馈信息。与历史打车订单相关联的反馈信息可以包括来自历史打车订单的乘客的投诉、来自历史打车订单的司机的投诉等或其任意组合。与历史打车订单相关联的反馈信息可以包括任何形式，例如文本、语音、视频等。在一些实施例中，处理引擎112可以确定与历史打车订单相关联的反馈信息是否满足预定条件。例如，处理引擎112可以根据(或匹配)预设的特定关键词，确定反馈信息是否包括关键词。预设的特定关键词可以指示历史打车订单的乘客醉酒。例如，在中文语义环境中，预设的特定关键词可以包括诸如“酒”、“醉”或“喝多”之类的单词，并且不包括诸如“酒店”、“我醉了”、“真的醉了”或“真是醉了”之类的单词。又例如，在英语语义环境中，预设的特定关键词可以包括“drunk”、“intoxication”、“ebriety”等。响应于反馈信息包括与预设的特定关键词匹配的关键词的确定结果，处理引擎112可以确定对应于反馈信息的历史打车订单是历史醉酒打车订单，并将历史醉酒打车订单标记为正样本。响应于反馈信息不包括与预设的特定关键词匹配的关键词的确定结果，处理引擎112可以确定对应于反馈信息的历史打车订单是历史非醉酒打车订单，并将历史非醉酒打车订单标记为负样本。处理引擎112可以将正样本分配给正样本集，并将负样本分配给负样本集。附加地或替代地，处理引擎112可以根据其他方法识别至少两个历史醉酒打车订单和/或至少两个历史非醉酒打车订单。例如，当乘客通过乘客的乘客终端请求打车服务时，乘客终端可以通过乘客终端的传感器(例如，乘客终端的摄像头、乘客终端的语音接收器等)记录乘客的行为。又例如，打车服务的车辆可以配备有传感器(例如，摄像机、语音接收器、酒精测试仪等)，用于检测乘客在车内时是否醉酒。

在一些实施例中，在识别正样本和/或负样本之后，处理引擎112可以将历史打车订单的全部或部分正样本(即历史醉酒打车订单)分配给正样本集，并将历史打车订单的全部或部分负样本(即历史非醉酒打车订单)指定给负样本集。例如，处理引擎112可以确定正样本的数量与负样本的数量的比率是否小于预设比率(例如，1:100)。响应于正样本的数量与负样本的数量的比率小于预设比率的确定结果，处理引擎112可以将所有正样本分配给正样本集，并将负样本的一部分分配给负样本集。负样本的一部分可以通过诸如下样本、随机森林、一类学习算法等的数据处理技术或其任意组合来确定。响应于该比率不小于预设比率的确定结果，处理引擎112可将所有正样本分配给正样本集，并将所有负样本分配给负样本集。

在520中，对于至少两个样本中的每一个样本，处理引擎112(例如，处理器220、模型训练模块410)可以使用应用程序提取至少两个特征。在一些实施例中，至少两个特征可包括乘客特征集、司机特征集和订单特征集。在一些实施例中，订单特征集可包括与醉酒热区相关的特征。

在一些实施例中，乘客特征集可以指代与至少两个样本中的每一个样本的任一乘客相关联的一组特征信息。乘客特征可以包括任一乘客的基本特征和与任一乘客的历史订单相关的特征。任一乘客的基本特征可以包括任一乘客的性别、任一乘客的年龄、登记时长(例如，任一乘客在打车服务平台上登记多长时间)、终端设备(例如，ios^tm、android^tm、windowsphone^tm等)的类型等或其任意组合。任一乘客的历史订单可以指任一乘客在历史中完成的历史打车订单。任一乘客的历史订单可以是在预定的时间段内的历史订单，例如，一年(例如，去年、当年、最近一年等)、半年(例如，最近六个月、当年的上半年等)、四分之一年(例如，最近三个月、当年的第二季度等)等或其任意组合内的历史订单。与任一乘客的历史订单相关的特征可以包括任一乘客的历史订单数量、任一乘客的投诉数、任一乘客收到的来自司机的投诉数量、任一乘客取消的取消历史订单数量等，或其任意组合。

在一些实施例中，司机特征集可以指与至少两个样本中的每一个样本的任一司机相关联的一组特征信息。司机特征可以包括任一司机的基本特征和与任一司机的历史订单相关的特征。任一司机的基本特征可以包括任一司机的性别、任一司机的年龄、登记时长(例如，任一司机在打车服务平台上登记多长时间)、驾驶体验、任一司机的车辆类型等或其任意组合。任一司机的历史订单可以指任一司机在历史上完成的历史打车订单。任一司机的历史订单可以是在预定的时间段内的历史订单，例如，一年(例如，去年、当年、最近一年等)、半年(例如，最近六个月、当年的上半年等)、四分之一年(例如，最近三个月、当年的第二季度等)等或其任意组合内的历史订单。与任一司机的历史订单相关的特征可以包括任一司机的历史订单的数量、评分(例如，服务分数、任一司机的等级)、任一司机的投诉数量、任一司机收到的投诉数量、任一司机在特定时间段(例如，一天中的晚上7点到晚上11点的晚高峰)内完成的历史订单的数量等或其任意组合。

在一些实施例中，订单特征集可以指与任一订单相关联的一组特征信息，该任一订单对应于至少两个样本中的每一个样本。订单特征可以包括任一订单的基本特征和与醉酒热区相关的特征。任一订单的基本特征可包括任一订单的位置(例如，任一订单的起始点或终点的经纬度、任一订单的兴趣点(poi)等)、订单时间(例如，任一订单启动的时间、任一订单结束的时间等)、任一订单的类型(例如，拼车订单、出租车订单、具有机场终点的订单等)等或其任意组合。与醉酒热区相关的特征可以指与醉酒热区相关联的任一订单的特征。醉酒热区可以指醉酒乘客可能比非醉酒热区多的区域或范围。在一些实施例中，可以基于至少两个历史代驾订单来确定醉酒热区，该历史代驾订单可以在本申请的其他地方找到，例如，在图6及其描述中。在一些实施例中，处理引擎112可以将任一订单映射到醉酒热区以获取与醉酒热区相关的特征。处理引擎112可基于位置信息(例如，任一订单的起点的经纬度)确定任一订单是否与醉酒热区或非醉酒热区相关联。与醉酒热区相关的特征可以包括与任一订单相关联的醉酒热区或非醉酒热区的特征，其可以在本申请的其他地方找到，例如，在图7及其描述中。在一些实施例中，与醉酒热区相关的特征可以包括醉酒热区内的历史代驾订单的数量、醉酒热区内的历史打车订单的数量、醉酒热区内的醉酒投诉打车订单数量、醉酒热区的标识(id)等或其任意组合。

在一些实施例中，处理引擎112可以处理至少两个样本中的每一个样本的信息以提取至少两个特征。例如，对于诸如任一乘客的性别的分类特征，处理引擎112可以通过one-hot编码将女性的性别指定为(0，1)，以及将男性的性别指定为(1，0)，其可以将该分类特征二值化为欧几里德空间中的向量。处理引擎112可以进一步提取表示分类特征的向量作为至少两个特征之一。又例如，对于连续特征(例如，任一乘客已经完成的历史订单的数量)，处理引擎112可以通过使用z-score标准化来对连续特征进行标准化。例如，处理引擎112可以确定连续特征的平均值和标准偏差，并且基于所确定的平均值和标准偏差来将连续特征归一化。在一些实施方案中，至少两个样本中的一个样本可包括一个或以上特征的缺失。例如，任一订单不能映射到醉酒热区，并且处理引擎112可以将醉酒热区的id填充为0。

在一些实施例中，处理引擎112可以使用用于提取特征的应用程序来提取至少两个特征。例如，该应用程序可以是编程过程、编程硬件、方法、过程等或其任意组合。

在530中，处理引擎112(例如，处理器220、模型训练模块410)可基于至少两个特征和至少两个样本来训练初始分类模型以获取醉酒模型。

在一些实施例中，初始分类模型可以包括用于预测订单分类的机器学习模型。例如，初始分类模型可以包括梯度提升决策树(gbdt)模型、极端梯度提升(xgboost)模型、随机森林模型等或其任意组合。在一些实施例中，初始分类模型可以具有默认设置(例如，一个或以上初始参数)或者可以在不同情况下调整。以xgboost模型为初始分类模型为例，初始分类模型可包括一个或以上的初始参数，例如，booster类型(例如，基于树的模型或线性模型)、booster参数(例如，最大深度、叶节点的最大数量)、学习任务参数(例如，训练的目标函数)等或其任意组合。醉酒模型可以是基于初始分类模型的训练模型(例如，通过调整初始分类模型的一个或以上初始参数来训练)。醉酒模型可以被配置用于确定或预测乘客的醉酒概率和/或指示乘客是否醉酒的类别。

在一些实施例中，在初始分类模型的训练中，正样本集中的正样本和负样本集中的负样本可以被指定为指示历史打车订单的历史乘客是否醉酒的不同概率。例如，可以将与正样本集中的历史醉酒打车订单相对应的概率指定为第一概率，以及在负样本集中对应于历史非醉酒打车订单的概率可以被指定为第二概率。第一概率可以小于第二概率。仅作为示例，第一概率可以是0，第二概率可以是1。又例如，第一概率可以是0.3，第二概率可以是0.7。或者，可以将至少两个样本的正样本集和负样本集指定为两个单独的类别。例如，正样本集中的正样本和负样本集中的负样本可以被标记为醉酒类别和非醉酒类别。

处理引擎112可以将至少两个样本中的每一个样本的至少两个特征输入到初始模型中以训练初始分类模型。指示历史打车订单的历史乘客是否醉酒和/或相应的醉酒/非醉酒类别的相应概率可以是标签(即，预期输出)。可以调整初始分类模型的初始参数以获取醉酒模型的更新参数。

在一些实施例中，调整的初始分类模型还可以通过至少两个测试样本来测试。至少两个测试样本可以与至少两个样本或至少两个样本的一部分相同。例如，可以将至少两个样本划分为用于训练初始分类模型的训练集和用于测试调整后的初始分类模型的测试集。可以将至少两个测试样本中的每一个样本的至少两个特征输入到调整后的初始分类模型，以输出对应的预测概率(或预测类别)。处理引擎112可以进一步确定至少两个测试样本的预测概率与已知概率之间的差异(或预测类别与已知类别之间的差异)。如果该差异满足预定条件，则处理引擎112可以将调整后的初始分类模型指定为醉酒模型。如果该差异不满足预定条件，处理引擎112可以用额外的至少两个样本进一步训练调整的初始分类模型，直到差异满足预定条件，以获取醉酒模型。预定条件可以是存储在系统100中的默认值，或者由用户和/或系统100根据不同情况确定。

应该注意的是，上述仅出于说明性目的而提供，并不旨在限制本申请的范围。对本领域普通术人员而言，在本申请的指导下可以进行各种变化和修改。例如，操作510和操作520可以集成到一个步骤中。然而，这些变化和修改不会背离本申请的范围。

图6示出了根据本申请的一些实施例的识别至少两个醉酒热区的示例性过程600的流程图。过程600可以由ai系统100执行。例如，过程600可以实现为存储在存储器rom230或ram240中的一组指令(例如，应用程序)。处理器220可以执行该组指令，并且当执行该指令时，可以将其配置为执行该过程600。以下所示过程的操作仅出于说明的目的。在一些实施例中，过程600可以通过未描述的一个或以上附加操作和/或去掉一个或以上所讨论的操作来完成。另外，如图6所示和下面描述的过程操作的顺序不是限制性的。

在610中，处理引擎112(例如，处理器220、热区识别模块420)可以从至少两个历史代驾订单中获取至少两个历史醉酒代驾订单。在一些实施例中，至少两个历史醉酒代驾订单中的每一个历史醉酒代驾订单可以包括起始位置。

在一些实施例中，历史代驾订单可以指历史请求者请求代驾服务的历史订单，代驾服务是指历史请求者请求代驾司机将与历史请求者相关联的车辆(例如，汽车)从起始位置驾驶到目的地的服务。起始位置可以指代驾司机接载历史请求者或者拿到车辆开始代驾服务的位置。历史代驾订单可根据历史请求者是否醉酒而被确定或标记为历史醉酒代驾订单或历史非醉酒代驾订单。例如，当历史请求者通过安装在其用户终端中的服务应用程序请求代驾服务时，历史请求者可以输入历史请求者是否醉酒以启动代驾服务的信息。又例如，在代驾司机接载历史请求者时或之后，代驾司机可以评价历史请求者是否醉酒或提供反馈。处理引擎112可以基于历史请求者的输入信息、代驾司机的评价和/或代驾司机的反馈，将历史代驾订单标记或确定为历史醉酒代驾订单或历史非醉酒代驾订单。在一些实施例中，至少两个历史醉酒代驾订单中的每一个订单还可包括与历史请求者相关联的信息、与历史代驾司机相关的信息、历史代驾订单的信息(例如，与历史代驾订单相关的时间信息、与历史代驾订单等相关的位置信息等)等或其任意组合。

在一些实施例中，至少两个历史代驾订单可以是同一区域内(例如，同一城市、同一地区等)的历史代驾订单。在一些实施例中，至少两个历史代驾订单可以是预定时间段内的历史代驾订单，例如，一年(例如，去年、当前年、最近一年)、半年(例如，最近六个月、当年的上半年)、四分之一年(例如，最近三个月、当年的第二季度)等或其任意组合内的历史代驾订单。在一些实施例中，至少两个历史代驾订单可以存储在数据库(例如，存储器140)中。

在620中，处理引擎112(例如，处理器220、热区识别模块420)可以基于至少两个历史醉酒代驾订单的起始位置来识别至少两个区域。

在一些实施例中，处理引擎112可以识别至少两个历史醉酒代驾订单的起始位置的经纬度。以一个城市内的至少两个历史代驾订单为例，处理引擎112可以将城市划分为至少两个网格(例如，方格网格、六边形网格)。至少两个网格中的每个网格可以包括预定尺寸。例如，至少两个方形网格中的每一个方形网格可以是3千米×3千米的区域。处理引擎112还可以基于起始位置的经纬度将至少两个历史醉酒代驾订单的起始位置映射到一个或以上划分的网格。例如，如果起始位置的经纬度在至少两个网格中的一个网格内，则处理引擎112可以识别网格所在的区域。

在630中，对于至少两个区域中的每一个区域，处理引擎112(例如，处理器220、热区识别模块420)可以确定该区域是否满足预定条件。

在一些实施例中，预定条件可以是确定该区域是否是醉酒热区的标准，醉酒热区中存在大量醉酒的人。例如，预定条件可以包括该区域中的历史醉酒代驾订单数量大于数量阈值、历史醉酒投诉打车订单的数量与历史醉酒代驾订单的数量的比率大于比率阈值等或其任何组合。该区域的历史醉酒代驾订单可以指其起始位置在该区域内的历史醉酒代驾订单。历史醉酒投诉打车订单可以指其起始位置在该区域内的历史醉酒打车订单。该区域的历史醉酒代驾订单和历史醉酒投诉打车订单可以是在相同的预定时间段(例如，最近一个月)内的订单。数量阈值和/或比率阈值可以由操作员设置(例如，基于操作员的经验)或者根据ai系统100的默认设置。

例如，处理引擎112可以确定该区域中的历史醉酒代驾订单的数量是否大于数量阈值。响应于该区域内的历史醉酒代驾订单的数量大于数量阈值的确定结果，处理引擎112可以进行到640。响应于该区域内的历史醉酒代驾订单的数量不大于数量阈值的确定结果，处理引擎112可以确定历史醉酒投诉打车订单的数量与历史醉酒代驾订单的数量的比率是否大于比率阈值。响应于历史醉酒投诉打车订单的数量与历史醉酒代驾订单的数量的比率大于比率阈值的确定结果，处理引擎112可以进行到640。响应于历史醉酒投诉打车订单的数量与历史醉酒代驾订单的数量的比率不大于比率阈值，处理引擎112可以进行到650。

在640中，响应于该区域满足预定条件的确定结果，处理引擎112(例如，处理器220、热区识别模块420)可以将该区域指定为至少两个醉酒热区中的一个醉酒热区。

在一些实施例中，醉酒热区可以指可能存在大量醉酒者的区域。例如，在醉酒热区中的醉酒历史请求者或历史乘客，可能会比非醉酒热区的多。醉酒热区可以表示该区域可能有比非醉酒热区更多的潜在乘客。

在650中，响应于该区域不满足预定条件的确定结果，处理引擎112(例如，处理器220、热区识别模块420)可以确定该区域不是至少两个醉酒热区中的一个醉酒热区。在一些实施例中，处理引擎112可以确定该区域是非醉酒热区。

应该注意的是，上述仅出于说明性目的而提供，并不旨在限制本申请的范围。对本领域普通术人员而言，在本申请的指导下可以进行各种变化和修改。然而，这些变化和修改不会背离本申请的范围。在一些实施例中，可以在示例性过程600中的其他地方添加一个或以上其他可选操作(例如，存储操作)。例如，过程600还可以包括在识别至少两个醉酒热区之后存储该至少两个醉酒热区。

图7是示出根据本申请的一些实施例的获取与热区相关的特征的示例性过程700的流程图。过程700可以由ai系统100执行。例如，过程700可以实现为存储在存储器rom230或ram240中的一组指令(例如，应用程序)。处理器220可以执行该组指令，并且当执行该指令时，可以将其配置为执行该过程700。以下所示过程的操作仅出于说明的目的。在一些实施例中，过程700可以通过未描述的一个或多个以上附加操作和/或去掉所讨论的操作的一个或以上来完成。另外，如图7所示和下面描述的过程操作的顺序不是限制性的。

在710中，对于至少两个样本中的每一个样本，处理引擎112(例如，处理器220、模型训练模块410)可以识别起始位置。

在一些实施例中，起始位置可以指代上车位置，该位置是司机接载与历史打车订单相关联的乘客，该历史打车订单对应于至少两个样本中的每一个样本。在一些实施例中，处理引擎112还可以获取起始位置的经纬度或兴趣点(例如，位置名称或位置地址)。

在720中，处理引擎112(例如，处理器220、模型训练模块410)可以将起始位置映射到醉酒热区。

在一些实施例中，处理引擎112可以基于起始位置的经纬度，将起始位置映射到醉酒热区。例如，处理引擎112可以将起始位置的经纬度与对应于至少两个醉酒热区的区域的经纬度匹配，来确定起始位置的经纬度是否与对应于至少两个醉酒热区的区域的经纬度之一匹配(例如，在其内)。响应于起始位置的经纬度与对应于至少两个醉酒热区的区域之一的经纬度匹配的确定结果，处理引擎112可以确定起始位置在醉酒热区内。醉酒热区可包括起始位置的经纬度。响应于起始位置的经纬度与对应于至少两个醉酒热区的区域的经纬度都不匹配的确定结果，处理引擎112可以确定起始位置不在醉酒热区内。在一些实施例中，处理引擎112还可以将起始位置映射到非醉酒热区。非醉酒热区可包括起始位置的经纬度。

在730中，处理引擎112(例如，处理器220、模型训练模块410)可以基于醉酒热区提取与醉酒热区相关的特征。

在一些实施例中，如果起始位置能被映射到醉酒热区，则处理引擎112可以提取与该醉酒热区相关联的特征。例如，与醉酒热区相关的特征可以包括醉酒热区内的历史代驾订单数、醉酒热区内的历史打车订单数、醉酒热区内的醉酒投诉打车订单数量、醉酒热区的标识(id)、起始位置是否位于醉酒热区内等或其任意组合。醉酒热区的id可以指用于标记醉酒热区以区分醉酒热区与至少两个醉酒热区中的其他醉酒热区的名称或编号。

在一些实施例中，如果起始位置被映射到非醉酒热区，则处理引擎112不能提取与任何醉酒热区相关的特征。处理引擎112可以将与醉酒热区相关的特征填充为0。例如，如果起始位置映射到非醉酒热区，醉酒热区内的历史代驾订单数、醉酒热区内的历史打车订单数、醉酒热区内的醉酒投诉打车订单数、起始位置是否位于醉酒热区和/或醉酒热区的标识(id)均为0。

应该注意的是，上述仅出于说明性目的而提供，并不旨在限制本申请的范围。对本领域普通术人员而言，在本申请的指导下可以进行各种变化和修改。然而，变化和修改不会背离本申请的范围。在一些实施例中，可以在示例性过程700中的其他地方添加一个或以上其他可选操作(例如，存储操作)。例如，过程700还可以包括在提取与醉酒热区相关的特征之后，存储与醉酒热区相关的特征。

图8是示出根据本申请的一些实施例的向司机的司机终端发送提示的示例性过程800的流程图。过程800可以由ai系统100执行。例如，过程800可以实现为存储在存储器rom230或ram240中的一组指令(例如，应用程序)。处理器220可以执行该组指令，并且当执行指令时，可以将其配置为执行过程800。以下所示过程的操作仅出于说明的目的。在一些实施例中，过程800可以通过未描述的一个或多个以上附加操作和/或去掉所讨论的操作的一个或以上来完成。另外，如图8所示和下面描述的过程操作的顺序不是限制性的。

在810中，处理引擎112(例如，处理器220、订单获取模块430)可以从乘客的乘客终端获取打车订单。

在一些实施例中，打车订单可以是实时打车订单、预定时段(例如，从晚上7点到晚上11点的晚高峰)内的打车订单等。

在820中，处理引擎112(例如，处理器220、醉酒确定模块440)可以基于打车订单和醉酒模型，确定乘客是否醉酒。

在一些实施例中，处理引擎112可以从打车订单中提取至少两个特征。至少两个特征可包括乘客特征集、司机特征集、订单特征集等或其任意组合。诸如乘客特征集、司机特征集和/或订单特征集的特征的描述可以在本申请的其他地方找到(例如，图5及其描述)。用于提取特征的方法和/或过程可以在本申请的其他地方找到(例如，图5及其描述)。处理引擎112可以将从打车订单提取的至少两个特征输入到醉酒模型中。醉酒模型可以输出打车订单的乘客是否醉酒的预测概率或预测类别。处理引擎112可以进一步基于预测概率或预测类别确定乘客是否醉酒。例如，如果预测的类别指示乘客醉酒，则处理引擎112可以确定乘客是醉酒的。基于预测概率确定乘客是否醉酒的细节可以在本申请的其他地方找到(例如，在图9及其描述中)。响应于乘客醉酒的确定结果，处理引擎112可以进行到830。响应于乘客没有醉酒的确定结果，处理引擎112可以进行到840。

在830中，响应于乘客醉酒的确定结果，处理引擎112(例如，处理器220、提示发送模块450)可以向打车订单的司机的司机终端发送提示。在一些实施例中，提示可以显示在司机终端的司机界面上。

在一些实施例中，提示可以包括乘客可能醉酒的通知、提醒司机努力避免冲突的提示等或其任意组合。在一些实施例中，提示还可以包括向司机询问，以在乘客实际上醉酒时生成反馈。反馈可用于更新醉酒模型。提示可以以文本、语音、图像(或视频)等形式或其任何组合来呈现。

在一些实施例中，响应于乘客醉酒的确定结果，处理引擎112可以为乘客重新分配另一个司机。重新分配的司机可能是一个高等级的司机。根据重新分配的司机提供的服务，醉酒乘客与重新分配的司机之间发生冲突的可能性可能很小。在一些实施例中，响应于乘客醉酒的确定结果，处理引擎112可以向乘客收取额外费用以减轻冲突。例如，在醉酒乘客在车内呕吐的情况下，额外费用可能是清洁汽车的费用。又例如，额外费用可能是鼓励司机接载醉酒乘客的小费。

在830中，响应于乘客没有醉酒的确定结果，处理引擎112(例如，处理器220、提示发送模块450)可将打车订单确定为正常订单。

在一些实施例中，响应于乘客未醉酒的确定结果，处理引擎112可以为乘客提供正常服务(例如，将打车订单作为正常订单推送到司机)。

应该注意的是，上述仅出于说明性目的而提供，并不旨在限制本申请的范围。对本领域普通术人员而言，在本申请的指导下可以进行各种变化和修改。然而，变化和修改不会背离本申请的范围。例如，可以在示例性过程800中的其他地方添加一个或以上其他可选操作(例如，存储操作)。例如，过程800可以进一步包括在确定其乘客醉酒之后存储该打车订单。

图9是示出根据本申请的一些实施例的确定乘客是否醉酒的示例性过程900的流程图。过程900可以由ai系统100执行。例如，过程900可以实现为存储在存储器rom230或ram240中的一组指令(例如，应用程序)。处理器220可以执行该组指令，并且当执行该指令时，可以将其配置为执行该过程900。以下所示过程的操作仅出于说明的目的。在一些实施例中，过程900可以通过未描述的一个或多个以上附加操作和/或去掉一个或以上所讨论的操作来完成。另外，如图9所示和下面描述的过程操作的顺序不是限制性的。

在910中，处理引擎112(例如，处理器220、醉酒确定模块440)可以获取乘客的醉酒概率。在一些实施例中，打车订单可以是醉酒模型的输入，以及醉酒概率可以是醉酒模型的输出。

在一些实施例中，醉酒概率可以指示乘客的醉酒可能性。具有较高醉酒概率的乘客可以表示该乘客比具有较低醉酒概率的乘客更可能醉酒。例如，乘客的醉酒概率范围可以从0到1。醉酒概率0.7可以表示该乘客比醉酒概率为0.3的乘客更可能醉酒。

在一些实施例中，处理引擎112可以将打车订单输入到醉酒模型中。醉酒模式可以通过分析输入(例如，通过从打车订单中提取至少两个特征)来输出乘客的醉酒概率。

在920中，处理引擎112(例如，处理器220、醉酒确定模块440)可以确定醉酒概率是否大于概率阈值。

在一些实施例中，概率阈值可以是用于评估乘客是否醉酒的阈值指数。如果醉酒概率大于概率阈值，则乘客更可能醉酒。或者，如果醉酒概率不大于概率阈值，则乘客更可能没有醉酒。在一些实施例中，概率阈值可以由操作员设置(例如，基于操作员的经验)或者根据ai系统100的默认设置。例如，当乘客的醉酒概率在0到1的范围内时，概率阈值可以被设置为从0到1的任何值(例如，0.6、0.85、0.9等)。

在930中，响应于醉酒概率大于概率阈值的确定结果，处理引擎112(例如，处理器220、醉酒确定模块440)可确定乘客醉酒。

在940中，响应于醉酒概率不大于概率阈值的确定结果，处理引擎112(例如，处理器220、醉酒确定模块440)可确定乘客没有醉酒。

应该注意的是，上述仅出于说明性目的而提供，并不旨在限制本申请的范围。对本领域普通术人员而言，在本申请的指导下可以进行各种变化和修改。然而，变化和修改不会背离本申请的范围。在一些实施例中，可以在示例性过程900中的其他地方添加一个或以上其他可选操作(例如，存储操作)。例如，过程900可以进一步包括在识别乘客醉酒之后存储该醉酒乘客。

本实施例至少具备以下之一的技术效果：根据乘客、司机和订单三个维度的特征，识别打车订单中的乘客是否醉酒。其中，订单的特征引入了醉酒代驾热区的概念，进一步提升了乘客醉酒预测的准确率。当预测打车订单中的乘客醉酒时，向接单的司机发送乘客醉酒的提示，提醒司机注意，以避免或减少司乘冲突。

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

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

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

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

本申请各部分操作所需的计算机程序代码可以用任意一种或以上程序设计语言编写，包括面向对象程序设计语言如java、scala、smalltalk、eiffel、jade、emerald、c++、c#、vb.net、python等，常规程序化程序设计语言如c程序设计语言、visualbasic、fortran1703、perl、cobol1702、php、abap，动态程序设计语言如python、ruby,和groovy，或其他程序设计语言等。该程序代码可以完全在用户计算机上运行、或作为独立的软件包在用户计算机上运行、或部分在用户计算机上运行部分在远程计算机运行、或完全在远程计算机或服务器上运行。在后种情况下，远程计算机可以通过任何网络形式与用户计算机连接，比如局域网络(lan)或广域网络(wan)，或连接至外部计算机(例如通过因特网)，或在云计算环境中，或作为服务使用如软件即服务(saas)。

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

同理，应当注意的是，为了简化本申请披露的表述，从而帮助对一个或以上发明实施例的理解，前文对本申请实施例的描述中，有时会将多种特征归并至一个实施例、附图或对其的描述中。然而，本申请的该方法不应被解释为反映所声称的待扫描对象物质需要比每个权利要求中明确记载的更多特征的意图。实际上，实施例的特征要少于上述披露的单个实施例的全部特征。

相应地，在一些实施例中，说明书和权利要求中使用的数值参数均为近似值，该近似值根据个别实施例所需特点可以发生改变。在一些实施例中，数值参数应考虑规定的有效数位并采用一般位数保留的方法。尽管本申请一些实施例中用于确认其范围广度的数值域和参数为近似值，在具体实施例中，此类数值的设定在可行范围内尽可能精确。

本文中提及的所有专利、专利申请、专利申请公布和其他材料(如论文、书籍、说明书、出版物、记录、事物和/或类似的东西)均在此通过引用的方式全部并入本文以达到所有目的，与上述文件相关的任何起诉文档记录、与本文件不一致或冲突的任何上述文件或对迟早与本文件相关的权利要求书的广泛范畴有限定作用的任何上述文件除外。举例来说，如果任何并入材料相关的与本文件相关的描述、定义和/或术语使用之间有任何不一致或冲突，那么本文件中的描述、定义和/或术语使用应当优先。

最后，应当理解的是，本申请中所述实施例仅用以说明本申请实施例的原则。其他的变形也可能属于本申请的范围。因此，作为示例而非限制，本申请实施例的替代配置可视为与本申请的教导一致。因此，本申请的实施例不限于精确地如所示和所述的那些。