CN113408877A - 网约车信息处理方法、装置、设备和计算机存储介质 - Google Patents

网约车信息处理方法、装置、设备和计算机存储介质 Download PDF

Info

Publication number
CN113408877A
CN113408877A CN202110633451.9A CN202110633451A CN113408877A CN 113408877 A CN113408877 A CN 113408877A CN 202110633451 A CN202110633451 A CN 202110633451A CN 113408877 A CN113408877 A CN 113408877A
Authority
CN
China
Prior art keywords
time
query
recommended
destination
order
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
CN202110633451.9A
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 Baidu Netcom Science and Technology Co Ltd
Original Assignee
Beijing Baidu Netcom Science and Technology 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 Baidu Netcom Science and Technology Co Ltd filed Critical Beijing Baidu Netcom Science and Technology Co Ltd
Priority to CN202110633451.9A priority Critical patent/CN113408877A/zh
Publication of CN113408877A publication Critical patent/CN113408877A/zh
Priority to KR1020237007589A priority patent/KR20230047444A/ko
Priority to EP21916645.1A priority patent/EP4123527A4/en
Priority to PCT/CN2021/131178 priority patent/WO2022257357A1/zh
Priority to JP2023514809A priority patent/JP7460062B2/ja
Pending legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION 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
    • G06Q10/00—Administration; Management
    • G06Q10/06—Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling
    • G06Q10/063—Operations research, analysis or management
    • G06Q10/0631—Resource planning, allocation, distributing or scheduling for enterprises or organisations
    • G06Q10/06311—Scheduling, planning or task assignment for a person or group
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90—Details of database functions independent of the retrieved data types
    • G06F16/95—Retrieval from the web
    • G06F16/953—Querying, e.g. by the use of web search engines
    • G06F16/9537—Spatial or temporal dependent retrieval, e.g. spatiotemporal queries
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06N—COMPUTING ARRANGEMENTS BASED ON SPECIFIC COMPUTATIONAL MODELS
    • G06N3/00—Computing arrangements based on biological models
    • G06N3/02—Neural networks
    • G06N3/08—Learning methods
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION 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
    • G06Q10/00—Administration; Management
    • G06Q10/02—Reservations, e.g. for tickets, services or events
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION 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
    • G06Q10/00—Administration; Management
    • G06Q10/02—Reservations, e.g. for tickets, services or events
    • G06Q10/025—Coordination of plural reservations, e.g. plural trip segments, transportation combined with accommodation
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION 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
    • G06Q10/00—Administration; Management
    • G06Q10/04—Forecasting or optimisation specially adapted for administrative or management purposes, e.g. linear programming or "cutting stock problem"
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION 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/00—Commerce
    • G06Q30/02—Marketing; Price estimation or determination; Fundraising
    • G06Q30/0283—Price estimation or determination
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION 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/00—Commerce
    • G06Q30/06—Buying, selling or leasing transactions
    • G06Q30/0601—Electronic shopping [e-shopping]
    • G06Q30/0633—Lists, e.g. purchase orders, compilation or processing
    • G06Q30/0635—Processing of requisition or of purchase orders
    • G06Q50/40—

Abstract

本公开公开了一种网约车信息处理方法、装置、设备和计算机存储介质，涉及人工智能技术领域中的大数据计算和深度学习技术。具体实现方案为：获取客户端发送的网约车查询条件，查询条件包括起始地和目的地信息；依据查询条件确定查询时间区间；针对查询时间区间内的各时刻，分别计算从各时刻出发到达目的地的代价信息；依据从各时刻出发到达目的地的代价信息，确定满足查询条件的时刻作为推荐出发时刻；利用推荐出发时刻，确定推荐发单时刻；向客户端返回查询结果，查询结果包括推荐发单时刻，或者，查询结果包括推荐发单时刻和推荐发单时刻对应的代价信息。本公开能够方便用户选择代价较小的发单时间，提高用户体验，节约网络资源，降低对系统性能的影响。

Description

网约车信息处理方法、装置、设备和计算机存储介质
技术领域
本公开涉及计算机应用技术领域，尤其涉及人工智能技术中的大数据计算和深度学习技术。
背景技术
伴随着移动互联网的发展，网约车平台的出现极大地改变了人们的生活。网约车平台通过将有接单需求的司机和有打车需求的乘客放在了一个网络平台上。当乘客发出订单(后续简称“发单”)后，网约车平台可以将距离该乘客在一定范围内的司机进行有效配对，由配对成功的司机接单并接驾乘客到订单指定的目的地。网约车的优势是随时出发、效率高且不需要考虑停车的问题。
乘客在实际场景下不可避免地会考虑网约车的代价问题。例如，目前网约车客户端会在乘客输入起始地和目的地后，给用户预估当前时刻打车需要的费用以供乘客参考。但乘客只能据此考虑当前是否打车，如果因路况或者其他问题造成当前打车费用较高，则乘客会放弃打车或者过一段时间再尝试获取预计的打车费用。这必然给乘客带来了不便，效率低下，且用户多次尝试预估打车费用，也浪费了网络资源，给系统性能带来压力。
发明内容
有鉴于此，本公开提供了一种网约车信息处理方法、装置、设备和计算机存储介质，方便用户选择代价较小的发单时间，提高用户效率和体验，节约网络资源，降低对系统性能带来的压力。
根据本公开的第一方面，提供了一种网约车信息处理方法，包括：
获取客户端发送的网约车查询条件，所述查询条件包括起始地和目的地信息；
依据所述查询条件确定查询时间区间；
针对所述查询时间区间内的各时刻，分别计算从各时刻出发到达目的地的代价信息；
依据从各时刻出发到达目的地的代价信息，确定满足所述查询条件的时刻作为推荐出发时刻；
利用所述推荐出发时刻，确定推荐发单时刻；
向所述客户端返回查询结果，所述查询结果包括所述推荐发单时刻，或者，所述查询结果包括所述推荐发单时刻和所述推荐发单时刻对应的代价信息。
根据本公开的第二方面，提供了一种网约车信息处理方法，包括：
获取用户输入的网约车查询条件，所述查询条件包括起始地和目的地信息；
将所述查询条件发送给服务器端，并获取所述服务器端返回的查询结果，所述查询结果包括推荐发单时刻，或者所述查询结果包括推荐发单时刻和推荐发单时刻对应的代价信息；
展示所述查询结果。
根据本公开的第三方面，提供了一种网约车信息处理装置，包括：
条件接收单元，用于获取客户端发送的网约车查询条件，所述查询条件包括起始地和目的地信息；
区间确定单元，用于依据所述查询条件确定查询时间区间；
代价计算单元，用于针对所述查询时间区间内的各时刻，分别计算从各时刻出发到达目的地的代价信息；
第一推荐单元，用于依据从各时刻出发到达目的地的代价信息，确定满足所述查询条件的时刻作为推荐出发时刻；
第二推荐单元，用于利用所述推荐出发时刻，确定推荐发单时刻；
结果返回单元，用于向所述客户端返回查询结果，所述查询结果包括所述推荐发单时刻，或者，所述查询结果包括所述推荐发单时刻和所述推荐发单时刻对应的代价信息。
根据本公开的第四方面，提供了一种网约车信息处理装置，包括：
条件获取单元，用于获取用户输入的网约车查询条件，所述查询条件包括起始地和目的地信息；
服务端交互单元，用于将所述查询条件发送给服务器端，并获取所述服务器端返回的查询结果，所述查询结果包括推荐发单时刻，或者所述查询结果包括推荐发单时刻和推荐发单时刻对应的代价信息；
结果展示单元，用于展示所述查询结果。
根据本公开的第五方面，提供了一种电子设备，包括：
至少一个处理器；以及
与所述至少一个处理器通信连接的存储器；其中，
所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够执行如上所述的方法。
根据本公开的第六方面，提供了一种存储有计算机指令的非瞬时计算机可读存储介质，其中，所述计算机指令用于使所述计算机执行如上所述的方法。
根据本公开的第七方面，一种计算机程序产品，包括计算机程序，所述计算机程序在被处理器执行时实现如上所述的方法。
应当理解，本部分所描述的内容并非旨在标识本公开的实施例的关键或重要特征，也不用于限制本公开的范围。本公开的其它特征将通过以下的说明书而变得容易理解。
附图说明
附图用于更好地理解本方案，不构成对本公开的限定。其中：
图1示出了可以应用本公开实施例的示例性系统架构；
图2为本公开实施例提供的一种网约车信息处理方法的流程图；
图3为本公开实施例提供的预估接驾时长的方法流程图；
图4为本公开实施例提供的预估接单时长的方法流程图；
图5为本公开实施例提供的接驾时长预估模型的示意图；
图6为本公开实施例提供的接单时长预估模型的示意图；
图7为本公开实施例提供的多任务训练的示意图；
图8为本公开实施例提供的另一种网约车信息处理方法的流程图；
图9是本公开实施例提供的一种展示查询结果界面的实例图；
图10为本公开实施例提供的一种网约车信息处理装置结构图；
图11为本公开实施例提供的另一种网约车信息处理装置的结构示意图；
图12是用来实现本公开实施例的电子设备的框图。
具体实施方式
以下结合附图对本公开的示范性实施例做出说明，其中包括本公开实施例的各种细节以助于理解，应当将它们认为仅仅是示范性的。因此，本领域普通技术人员应当认识到，可以对这里描述的实施例做出各种改变和修改，而不会背离本公开的范围和精神。同样，为了清楚和简明，以下的描述中省略了对公知功能和结构的描述。
图1示出了可以应用本公开实施例的示例性系统架构。
如图1所示，该系统架构可以包括终端设备101和102，网络103和服务器104。网络103用以在终端设备101、102和服务器104之间提供通信链路的介质。网络103可以包括各种连接类型，例如有线、无线通信链路或者光纤电缆等等。
用户可以使用终端设备101和102通过网络103与服务器104交互。终端设备101和102上可以安装网约车应用的客户端或者可以展现网约车信息的客户端，在本申请中特别的是安装有乘客所使用的客户端。其他终端设备上也可以安装有司机所使用的客户端。
终端设备101和102可以是各种移动式电子设备。包括但不限于智能手机、平板电脑、笔记本电脑、可穿戴式设备、车载终端等等。本申请所提供的一种网约车信息处理装置可以设置并运行于上述服务器104中。本申请提供的另一种网约车信息处理装置可以设置并运行于上述终端设备101和102中。其可以实现成多个软件或软件模块(例如用来提供分布式服务)，也可以实现成单个软件或软件模块，在此不做具体限定。
服务器104可以是单一服务器，也可以是多个服务器构成的服务器群组。
应该理解，图1中的终端设备、网络和服务器的数目仅仅是示意性的。根据实现需要，可以具有任意数目的终端设备、网络和服务器。
现有的网约车服务中，用户在查询了从起始地到目的地的代价信息，例如价格或线路时长，只能选择现在打车与否。如果因为路况等因素导致代价偏高，用户可能就放弃打车。但可能路况会在短时间内改善，用户就丧失稍后改善打车体验的机会，也抑制了网约车行业的发展。还有些情况下，在一些打车高峰期有很多用户选择现在出发并非是行程的需求，而是担心运力紧张导致打不到车，所以着急排队。这就更会造成打车高峰期的代价加大，更难以打到车。有鉴于此，本公开提供了一种新的思路，能够为用户推荐发单时刻，使得希望降低代价或者不着急现在出发的用户能够依据推荐发单时刻选择稍后再发单。下面结合实施例对本公开进行详细描述。
图2为本公开实施例提供的一种网约车信息处理方法的流程图，该方法可以在服务器端执行。如图2中所示，该方法包括以下步骤：
在201中，获取客户端发送的网约车查询条件，查询条件包括起始地和目的地信息。
在202中，依据查询条件确定查询时间区间。
在203中，针对查询时间区间内的各时刻，分别计算从各时刻出发到达目的地的代价信息。
在204中，依据从各时刻出发到达目的地的代价信息，确定满足查询条件的时刻作为推荐出发时刻。
在205中，利用推荐出发时刻，确定推荐发单时刻。
在206中，向客户端返回查询结果，该查询结果包括推荐发单时刻，或者，查询结果包括推荐发单时刻和推荐发单时刻对应的代价信息。
由以上技术方案可以看出，本公开能够在查询时间区间内依据各时刻触发的代价信息，确定推荐发单时刻，并在查询结果中返回推荐发单时刻或进一步返回推荐发单时刻对应的代价信息。使得用户能够依据推荐发单时刻或进一步结合代价信息，选择代价较小的发单时间。第一方面避免了因用户发现当前时刻出发代价偏高而丧失打车体验。第二方面也避免了用户短时间内频繁尝试查询打车的代价信息，提高了用户效率和体验。第三方面也降低了用户的打车代价，为用户节约了成本。第四方面也能够缓解用户都集中在打车高峰期所带来的运力分配不合理的问题。第五方面用户能够一次性获取代价较小的发单时间，不必多次尝试，节约了网络资源，降低了对系统压力的影响。可谓是一举多得。
下面对上述实施例中的各步骤进行详细描述。首先结合实施例对上述步骤201即“获取客户端发送的网约车查询条件，查询条件包括起始地和目的地信息”进行详细描述。
上述网约车查询条件是来自客户端的，至少包括起始地和目的地信息。其中起始地信息可以是用户输入的信息，也可以是依据客户端当前定位得到的。目的地信息通常是用户输入的信息。在本实施例中涉及的“用户”指的是预使用网约车的乘客。
更进一步地，在本公开中上述查询条件还可以进一步包括查询时间区间信息，或者，进一步包括代价范围。
查询时间区间通常是用户设置的未来的一段时间，例如未来一个小时内，未来半个小时内，未来两个小时内等等，根据用户的发单需求来设置。反映了用户能够接受在多久时间内打车。如果用户对行程不着急可以设置一个较长的时间区间。如果用户对行程着急可以设置一个较短的时间区间。
代价范围可以是用户设置的能够接受的打车代价。可以体现为价格范围，例如60元以内。也可以体现为线路时长即耗时范围，例如40分钟内。等等。
上述查询时间区间信息和代价范围的具体作用将在后续步骤中体现。
下面结合实施例对上述步骤202即“依据查询条件确定查询时间区间”进行详细描述。
若查询条件中包含用户设置的查询时间区间，则在本步骤中直接采用用户设置的查询时间区间，即从查询条件中确定查询时间区间。
若查询条件中不包含用户设置的查询时间区间，则在本步骤中可以采用默认设置的查询时间区间，例如默认设置未来一个小时作为查询时间区间。
下面结合实施例对上述步骤203即“针对查询时间区间内的各时刻，分别计算从各时刻出发到达目的地的代价信息”进行详细描述。
在本公开中可以依据预设的粒度将查询时间区间划分为各个时刻。该粒度可以是设置的固定值，也可以是依据查询时间区间的长度对应的粒度。例如，如果用户设置的查询时间区间是半个小时，那么粒度为1分钟。如果用户设置的查询时间区间是24小时，那么粒度为10分钟。
作为其中一种实现方式，可以针对查询时间区间内的各时刻分别执行以下处理，从而得到各时刻出发到达目的地的代价信息：
对时刻ti而言，基于对时刻ti的路况预估结果，对起始地和目的地进行路线规划，得到该时刻ti出发到达目的地的预估时长信息作为从该时刻ti出发到达目的地的代价信息。
也就是说，首先从起始地到目的地进行路线规划，路线规划过程中会结合路况预测方法，基于对该时刻ti的路况进行预测，基于路况预测结果进行路线规划并得到该时刻ti出发到达目的地的预估时长。其中，路线规划和路况预测方法可以采用任何可实现的方式，本公开对此并不加以限制。
作为另一种实现方式，可以针对查询时间区间内的各时刻分别执行以下处理，从而得到各时刻出发到达目的地的代价信息：
对时刻ti而言，基于对时刻ti的路况预估结果，对起始地和目的地进行路线规划，得到该时刻ti出发到达目的地的路线长度和预估时长，利用网约车计价规则进行价格计算，将计算得到的价格作为从该时刻出发到达目的地的代价信息。
其中，网约车计价规则通常是比较固定的，综合考虑了司机、乘客和企业的各方利益。不同的地区或网约车平台会有一些差异，具体的计价规则可以从网约车平台预先获取并进行记录。
网约车计价规则大多是由三方面组成的：起步价、里程和时长。一般来说，起步价包含了特定的里程和时长，比如3公里和10分钟。而当驾驶里程超过3公里就会按照每公里一定费率进行累加。当驾驶时长超过了10分钟，则会按照每分钟一定费率进行累加。最后加和的结果则是计算得到的价格。其中由于驾驶时长和路况相关，不同时刻的路况各不相同，因此不同时刻出发相同起始点和目的地的价格可能是不一样的。本申请对于网约车计价规则的具体内容并不加以限制，在此仅为了方便理解而举例说明。
下面结合实施例对上述步骤204即“依据从各时刻出发到达目的地的代价信息，确定满足查询条件的时刻作为推荐出发时刻”进行详细描述。
在本步骤中，如果查询条件中包括用户设置的查询时间区间，则可以将该查询时间区间内对应代价最小的N个时刻作为推荐出发时刻。
由于在上述步骤中已经可以确定出查询时间区间中各时刻对应的代价信息，因此可以优选代价小的时刻作为推荐出发时刻。上述N可以是预设的正整数。
如果查询条件中包括用户设置的价格范围，则可以将查询时间区间内对应代价符合用户设置的价格范围的时刻作为推荐出发时刻。例如，用户设置了40元以内的价格范围，那么可以从各时刻对应的价格中筛选40元以下的时刻。
需要说明的是，本步骤中确定出的推荐出发时刻可以是一个，也可以是超过一个的数量。
下面对上述实施例中的各步骤进行详细描述。首先结合实施例对上述步骤205即“利用推荐出发时刻，确定推荐发单时刻”进行详细描述。
由于推荐出发时刻指的是推荐用户实际出发的时刻，即从路线起始点出发的时刻。但对于用户而言，更直观和更需要的是什么时刻发单，因此，需要确定推荐发单时刻。
作为一种可实现的方式，本步骤的具体实现过程可以包括以下步骤：
步骤S1：利用推荐出发时刻对网约车接驾时间进行预估，得到预估接单时刻。
步骤S2：利用预估接单时刻对接单时间进行预估，得到推荐发单时刻。
从用户发单到从路线起始点出发，中间还会存在网约车司机接单和接驾的过程。所谓网约车司机接单指的是用户发单后，网约车平台将用户的订单下发给匹配的网约车司机，再由网约车司机接受订单的过程。所谓接驾指的是网约车司机接受订单后，从司机所在位置到达乘客所在位置的过程。
上述步骤S1中是利用推荐出发时刻倒推需要的接驾时间，从而得到预估接单时刻。具体过程如图3中所示，包括以下步骤：
步骤301：获取预设的初始第一时长。
初始第一时长可以是一个预设的时间单元，例如1分钟。
步骤302：确定推荐出发时刻之前第一时长的时刻作为候选接单时刻。
假设推荐出发时刻表示为Td，推荐出发时刻之前第一时长的时刻表示为Td-n，此时候选接单时刻为Td-n。
步骤303：预估候选接单时刻所需的接驾时长。
在本步骤中对候选接单时刻Td-n所需的接驾时长(表示为Tpickup)进行预估时，可以使用接驾时长预估模型。具体实现将在后续进行详细描述。
步骤304：判断预估的接驾时长是否小于或等于第一时长，如果是，执行步骤305；否则，执行步骤306。
判断Tpickup是否小于或等于当前的第一时长，也就是说，判断是否Td-n+Tpickup≤Td。
步骤305：确定候选接单时刻为预估接单时刻，结束当前预估流程。
这种情况下，当前的Td-n就是预估接单时刻Tt。
步骤306：延长第一时长，重新转至执行步骤302。
这种情况下，可以延长第一时长，例如延长1分钟，第一时长变为2分钟，转至步骤302，此时的Td-n就是Td之前2分钟的时刻。依次类推，执行上述步骤，直至确定出预估接单时刻。
上述步骤S2中利用预估接单时刻倒推接单时间，从而得到推荐发单时刻，具体过程如图4中所示，包括以下步骤：
步骤401：获取预设的初始第二时长。
与初始第一时长类似地，初始第二时长可以是一个预设的时间单元，例如1分钟。
步骤402：确定预估接单时刻之前第二时长的时刻作为候选发单时刻。
由于预估接单时刻为Tt，预估接单时刻之前第二时长的时刻表示为Tt-m，此时候选发单时刻为Tt-m。
步骤403：预估所候选发单时刻所需的接单时长。
在本步骤中对候选发单时刻Tt-m所需的接单时长(表示为Torder)进行预估时，可以使用接单时长预估模型。具体实现将在后续进行详细描述。
步骤404：判断预估的接单时长是否小于或等于第二时长，如果是，执行步骤405；否则执行步骤406。
判断Torder是否小于或等于当前的第二时长，也就是说，判断是否Tt-m+Torder≤Tt。
步骤405：确定候选发单时刻为推荐发单时刻，结束当前预估流程。
这种情况下，当前的Tt-m就是推荐发单时刻Tc。
步骤406：延长第二时长，重新转至步骤402。
这种情况下，可以延长第二时长，例如延长1分钟，第二时长变为2分钟，转至步骤402，此时的Tt-m就是Tt之前2分钟的时刻。依次类推，执行上述步骤，直至确定出推荐发单时刻。
下面结合实施例对上述接驾时长预估模型和接单时长预估模型进行详细描述。
上述接驾时长预估模型可以采用回归模型，该模型能够在候选接单时刻Td-n输入时，输出对应的接驾时长Tpickup。
作为一种优选的实施方式，接驾时长预估模型的结构可以如图5中所示，主要包括嵌入层和全连接层。嵌入层主要用于对输入接驾时长预估模型的各特征进行嵌入处理，分别得到各特征的向量表示。各特征的向量表示进行诸如拼接等融合处理后输入全连接层，由全连接层映射得到接驾时长。
其中，输入接驾时长预估模型的特征除了候选接单时刻Td-n之外，还包括用户的位置、目的地、推荐出发时刻的代价信息、路线长度、天气信息和路况信息中的至少一种，在图5中以包括这些所有信息为例。其中的代价信息以包括价格和预估时长为例。
上述接单时长预估模型也可以用回归模型，该模型能够在候选发单时刻Tt-m输入时，输出对应的接单时长Torder。
作为一种优选的实施方式，接单时长预估模型的结构可以如图6中所示，主要包括嵌入层和全连接层。嵌入层主要用于对输入接单时长预估模型的各特征进行嵌入处理，分别得到各特征的向量表示。各特征的向量表示进行诸如拼接等融合处理后输入全连接层，由全连接层映射得到接单时长。
其中，输入接单时长预估模型的特征除了候选发单时刻Tt-m之外，还可以包括用户的位置、目的地、推荐出发时刻的代价信息、路线长度和天气信息中的至少一种，在图6中以包括这些所有信息为例。其中的代价信息以包括价格和预估时长为例。
在上述接驾时长预估模型和接单时长预估模型中，用户的位置和目的地进行嵌入处理时，采用的特征可以是POI信息。POI信息可以包括POI名称、属性、坐标信息等。嵌入处理实际上是对POI信息进行语义化表示。其中POI名称中由于可能带有POI热度、功能的特性，因此可以将POI名称进行切词后再进行向量化表示。POI的属性信息重点采用类别，例如公交枢纽、住宅区等等，可以采用离散化的数值表示。坐标信息描述的是空间热度信息，因此可以将整个区域进行区格划分后进行序列化编号，将坐标所在区格的编号作为特征表示。
关于推荐出发时刻、候选发单时刻这类时间特征，可以采用连续值表示。例如对于特定时刻可以包括小时值x，分钟值12，秒钟值z，可以定义两个特征
Figure BDA0003104624620000111
和
Figure BDA0003104624620000112
来表示，这种表示可以让取值范围局限于[-1,1]。
对于时间特征，还可以采用是否为工作日、星期几等离散信息表示。
价格、预估时长、路线长度都是离散值，可以进行归一化处理后直接输入模型。
天气特征可以采用onehot(独热)离散表示，对晴、阴、雾、雨(小雨、中雨、大雨、暴雨)、雪(小雨、中雨、大雨、暴雨)等天气进行表示和区分。
路况特征是在接驾时长预估模型中引入的，因为其对于接驾时长的影响较高，且附近路况特征在其他特征中的表达不足。用户附近的路况特征主要希望能够刻画出一定物理范围内的车流量密度。因此可以采用诸如CNN(Convolutional Neural Networks，卷积神经网络)、GCN(Graph Convolutional Network，图卷积神经网络)等神经网络进行编码。例如可以以用户的位置为中心区域向外扩展预设的范围，例如2km，得到一个4km*4km的正方形区域，然后将这个区域划分为16个1km*1km的小区域。区域内的车流量特征可以采用道路的拥堵系数加权道路长度的平均值来表示，例如：
Figure BDA0003104624620000121
其中，Ix表示区域内的车流量特征，li表示第i个小区域内的道路长度，ji表示第i个小区域的拥堵系数。
在预先训练上述接驾时长预估模型时，采用的训练数据可以从网约车平台的日志中获取。网约车平台记录有司机接单到乘客上车的时长即接驾时长，从这部分数据中抽取乘客的位置、目的地、价格、路线长度、天气信息、路况信息和司机的接单时刻作为输入，将实际接驾时长作为目标输出，训练回归模型得到接驾时长预估模型。也就是说，在设计损失函数loss时，最小化接驾时长预估模型的输出与实际接驾时长的差值绝对值。
在预先训练上述接单时长预估模型时，采用的训练数据也可以从网约车平台的日志中获取。网约车平台记录有乘客发单到司机接单的时长，即接单时长。从这部分数据中抽取乘客的位置、目的地、价格、路线长度、天气信息和乘客发单时刻作为输入，将实际接单时长作为目标输出，训练回归模型得到接单时长预估模型。也就是说，在设计loss时，最小化接单时长预估模型的输出与实际接单时长的差值绝对值。
上述的接驾时长预估模型和接单时长预估模型可以分别训练，也可以采用多任务学习的方式训练。
在进行多任务学习的方式训练时，如图7中所示，用户的位置、目的地、预估时价格、路线长度和天气信息作为共享特征，其对应的嵌入处理部分为共享层。路况特征是接驾时长预估模型独有的特征。发单时刻是接单时长预估模型的输入，接单模型输出接单时长后，接单时长与发单时刻相结合得到的就是接单时刻，其作为接驾时长预估模型的输入。在进行多任务训练时，每一轮迭代可以随机选择一个任务，计算该任务的损失函数后，采用梯度下降法更新该任务所对应的模型参数。或者，也可以采用联合训练的方式，即仅采用接驾任务的损失函数，采用梯度下降法更新所有模型参数。持续迭代直到满足预设的训练结束条件，例如损失函数收敛，或者迭代次数达到预设的迭代次数阈值，等等。
图8为本公开实施例提供的另一种网约车信息处理方法的流程图，该方法可以在客户端执行。如图8中所示，该方法包括以下步骤：
在801中，获取用户输入的网约车查询条件，该查询条件可以包括起始地和目的地信息。
在本公开实施例中，客户端可以是网约车应用的客户端，也可以是集成了网约车功能的其他应用的客户端，例如集成了网约车功能的地图类应用的客户端。
客户端可以向用户提供第一界面，供用户输入打车的起始地和目的地信息。
更进一步地，还可以向用户提供设置查询时间区间或者代价范围的组件。例如可以在第一界面上提供输入框供用户输入查询时间区间或代价范围。再例如可以在第一界面上提供诸如下拉框等选项供用户选择输入查询时间区间或代价范围。其中代价范围可以是价格范围，也可以是线路(即打车行程)的时长范围。
在802中，将查询条件发送给服务器端，并获取服务器端返回的查询结果，查询结果包括推荐发单时刻，或者查询结果包括推荐发单时刻和推荐发单时刻对应的代价信息。
客户端将上述查询条件发送给服务器端后，由服务器端执行图2所示实施例中的流程，生成查询结果后返回给客户端。服务器端执行的处理在此不做赘述。
其中，推荐发单时刻对应的代价信息可以包括该时刻出发到达目的地的预估时长信息，或者，该时刻出发到达目的地的价格信息。
在803中，展示查询结果。
客户端可以向用户提供第二界面，在该第二界面上展示查询结果。至少在该第二界面上展示推荐发单时刻，该推荐发单时刻可以是一个，也可以是多个。在展现推荐发单时刻时，可以仅展示推荐发单时刻，也可以展示查询时间区间中的各时刻，但突出显示其中的推荐发单时刻。
在展示推荐发单时刻的同时，可以展示该推荐发单时刻对应的代价信息。可以仅提供一种代价信息，也可以提供多种代价信息供用户选择。
图9是本公开实施例提供的一种展示查询结果界面的实例图，如图9中所示，可以提供两种代价信息供用户选择：按照花费(即价格)最少以及按照时间(即线路的预估时长)最少。用户选择花费最少时，向用户展现花费最少的推荐发单时刻。也可以提供多个网约车平台供用户选择查看。图9中以一个小时内的查询时间区间为例，推荐发单时刻突出显示，即16:00的时刻，并展示其对应的花费为27元。
更进一步地，可以在上述第二界面上展现设置出发时间的组件，例如图9中所示的“设置出发时间”组件。获取到该组件被触发的事件后，记录用户设置的出发时间。在用户设置的出发时间到达或者在所述用户设置的出发时间之前预设时长，向用户展示提醒消息。
更进一步地，可以在上述第二界面上展现预约发单的组件，例如图9中所示的“预约打车”组件。获取到该组件被触发的事件后，记录用户设置的发单时间；在到达用户设置的发单时间时，发送从起始地到目的地的网约车订单。
以上是对本公开所提供方法进行的详细描述，下面结合实施例对本公开提供的装置进行详细描述。
图10为本公开实施例提供的一种网约车信息处理装置结构图，设置于服务器端。该装置可以为位于服务器端的应用，或者还可以为位于服务器端的应用中的插件或软件开发工具包(Software Development Kit，SDK)等功能单元。如图10中所示，该装置1000可以包括：条件接收单元1010、区间确定单元1020、代价计算单元1030、第一推荐单元1040、第二推荐单元1050和结果返回单元1060。其中各组成单元的主要功能如下：
条件接收单元1010，用于获取客户端发送的网约车查询条件，查询条件包括起始地和目的地信息。
区间确定单元1020，用于依据查询条件确定查询时间区间。
代价计算单元1030，用于针对查询时间区间内的各时刻，分别计算从各时刻出发到达目的地的代价信息。
第一推荐单元1040，用于依据从各时刻出发到达目的地的代价信息，确定满足查询条件的时刻作为推荐出发时刻。
第二推荐单元1050，用于利用推荐出发时刻，确定推荐发单时刻。
结果返回单元1060，用于向客户端返回查询结果，查询结果包括推荐发单时刻，或者，查询结果包括推荐发单时刻和推荐发单时刻对应的代价信息。
作为其中一种实现方式，查询条件还包括查询时间区间，第一推荐单元1040具体用于将查询时间区间内对应代价最小的N个时刻作为推荐出发时刻，N为预设的正整数。
作为另一种实现方式，查询条件还包括代价范围，第一推荐单元1040具体用于将查询时间区间内对应代价符合用户设置的代价范围的时刻作为推荐出发时刻。
其中，区间确定单元1020具体用于：若查询条件包含用户设置的查询时间区间，则采用用户设置的查询时间区间；否则，采用默认设置的查询时间区间。
其中，代价计算单元1030具体用于针对各时刻分别执行：
基于对该时刻的路况预估结果，对起始地和目的地进行路线规划，得到该时刻出发到达目的地的预估时长信息作为从该时刻出发到达目的地的代价信息；或者，
基于对该时刻的路况预估结果，对起始地和目的地进行路线规划，得到该时刻出发到达目的地的路线长度和预估时长，利用网约车计价规则进行价格计算，将计算得到的价格作为从该时刻出发到达目的地的代价信息。
具体地，第二推荐单元1050可以包括：第一预估子单元1051和第二预估子单元1052。
第一预估子单元1051，用于利用推荐出发时刻对网约车接驾时间进行预估，得到预估接单时刻；
第二预估子单元1052，用于利用预估接单时刻对接单时间进行预估，得到推荐发单时刻。
其中，第一预估子单元1051具体用于：
按照预设的初始第一时长，确定推荐出发时刻之前第一时长的时刻作为候选接单时刻；
预估候选接单时刻所需的接驾时长；
若预估的接驾时长小于或等于第一时长，则确定候选接单时刻为预估接单时刻，否则，延长第一时长，重新转至确定推荐出发时刻之前第一时长的时刻作为候选接单时刻的操作。
作为一种优选的实施方式，第一预估子单元1051在预估候选接单时刻所需的接驾时长时，具体执行：将用户的位置、目的地、代价信息、路线长度、天气信息和路况信息中的至少一种以及候选接单时刻输入接驾时长预估模型，得到候选接单时刻所需的接驾时长。
其中，第二预估子单元1052具体用于：
按照预设的初始第二时长，确定预估接单时刻之前第二时长的时刻作为候选发单时刻；
预估候选发单时刻所需的接单时长；
若预估的接单时长小于或等于第二时长，则确定候选发单时刻为推荐发单时刻，否则，延长第二时长，重新转至确定预估接单时刻之前第二时长的时刻作为候选发单时刻的操作。
作为一种优选的实施方式，第二预估子单元1052在预估候选发单时刻所需的接单时长时，具体执行：将用户的位置、目的地、代价信息、路线长度和天气信息中的至少一种以及候选发单时刻输入接单时长预估模型，得到候选发单时刻所需的接单时长。
图11为本公开实施例提供的另一种网约车信息处理装置的结构示意图，设置于终端设备。该装置可以为位于终端设备的应用，或者还可以为位于终端设备的应用中的插件或软件开发工具包(Software Development Kit，SDK)等功能单元。如图11中所示，该装置可以包括：条件获取单元1101、服务端交互单元1102和结果展示单元1103，还可以进一步包括第一组件响应单元1104和第二组件响应单元1105。其中各组成单元的主要功能如下：
条件获取单元1101，用于获取用户输入的网约车查询条件，查询条件包括起始地和目的地信息；
服务端交互单元1102，用于将查询条件发送给服务器端，并获取服务器端返回的查询结果，查询结果包括推荐发单时刻，或者查询结果包括推荐发单时刻和推荐发单时刻对应的代价信息；
结果展示单元1103，用于展示查询结果。
其中，推荐发单时刻对应的代价信息可以包括：该时刻出发到达目的地的预估时长信息，或者，该时刻出发到达目的地的价格信息。
更进一步地，结果展示单元1103，还可以用于在界面上展现设置出发时间的组件。
第一组件响应单元1104，用于获取到组件被触发的事件后，记录用户设置的出发时间；在用户设置的出发时间到达或者在用户设置的出发时间之前预设时长，触发所述结果展示单元1103向用户展示提醒消息。
更进一步地，结果展示单元1103，还用于在界面上展现预约发单的组件。
第二组件响应单元1105，用于获取到组件被触发的事件后，记录用户设置的发单时间；在到达用户设置的发单时间时，通过所述服务端交互单元1102发送从起始地到目的地的网约车订单。
本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于装置实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。
根据本公开的实施例，本公开还提供了一种电子设备、一种可读存储介质和一种计算机程序产品。
如图12所示，是根据本公开实施例的网约车信息处理方法的电子设备的框图。电子设备旨在表示各种形式的数字计算机，诸如，膝上型计算机、台式计算机、工作台、个人数字助理、服务器、刀片式服务器、大型计算机、和其它适合的计算机。电子设备还可以表示各种形式的移动装置，诸如，个人数字处理、蜂窝电话、智能电话、可穿戴设备和其它类似的计算装置。本文所示的部件、它们的连接和关系、以及它们的功能仅仅作为示例，并且不意在限制本文中描述的和/或者要求的本公开的实现。
如图12所示，设备1200包括计算单元1201，其可以根据存储在只读存储器(ROM)1202中的计算机程序或者从存储单元1208加载到随机访问存储器(RAM)1203中的计算机程序，来执行各种适当的动作和处理。在RAM 1203中，还可存储设备1200操作所需的各种程序和数据。计算单元1201、ROM 1202以及RAM 1203通过总线1204彼此相连。输入/输出(I/O)接口1205也连接至总线1204。
设备1200中的多个部件连接至I/O接口1205，包括：输入单元1206，例如键盘、鼠标等；输出单元1207，例如各种类型的显示器、扬声器等；存储单元1208，例如磁盘、光盘等；以及通信单元1209，例如网卡、调制解调器、无线通信收发机等。通信单元1209允许设备1200通过诸如因特网的计算机网络和/或各种电信网络与其他设备交换信息/数据。
计算单元1201可以是各种具有处理和计算能力的通用和/或专用处理组件。计算单元1201的一些示例包括但不限于中央处理单元(CPU)、图形处理单元(GPU)、各种专用的人工智能(AI)计算芯片、各种运行机器学习模型算法的计算单元、数字信号处理器(DSP)、以及任何适当的处理器、控制器、微控制器等。计算单元1201执行上文所描述的各个方法和处理，例如网约车信息处理方法。例如，在一些实施例中，网约车信息处理方法可被实现为计算机软件程序，其被有形地包含于机器可读介质，例如存储单元1208。
在一些实施例中，计算机程序的部分或者全部可以经由ROM 802和/或通信单元1209而被载入和/或安装到设备1200上。当计算机程序加载到RAM 1203并由计算单元1201执行时，可以执行上文描述的网约车信息处理方法的一个或多个步骤。备选地，在其他实施例中，计算单元1201可以通过其他任何适当的方式(例如，借助于固件)而被配置为执行网约车信息处理方法。
此处描述的系统和技术的各种实施方式可以在数字电子电路系统、集成电路系统、场可编程门阵列(FPGA)、专用集成电路(ASIC)、专用标准产品(ASSP)、芯片上系统的系统(SOC)、负载可编程逻辑设备(CPLD)、计算机硬件、固件、软件、和/或它们的组合中实现。这些各种实施方式可以包括：实施在一个或者多个计算机程序中，该一个或者多个计算机程序可在包括至少一个可编程处理器的可编程系统上执行和/或解释，该可编程处理器可以是专用或者通用可编程处理器，可以从存储系统、至少一个输入装置、和至少一个输出装置接收数据和指令，并且将数据和指令传输至该存储系统、该至少一个输入装置、和该至少一个输出装置。
用于实施本公开的方法的程序代码可以采用一个或多个编程语言的任何组合来编写。这些程序代码可以提供给通用计算机、专用计算机或其他可编程数据处理装置的处理器或控制器，使得程序代码当由处理器或控30制器执行时使流程图和/或框图中所规定的功能/操作被实施。程序代码可完全在机器上执行、部分地在机器上执行，作为独立软件包部分地在机器上执行且部分地在远程机器上执行或完全在远程机器或服务器上执行。
在本公开的上下文中，机器可读介质可以是有形的介质，其可以包含或存储以供指令执行系统、装置或设备使用或与指令执行系统、装置或设备结合地使用的程序。机器可读介质可以是机器可读信号介质或机器可读储存介质。机器可读介质可以包括但不限于电子的、磁性的、光学的、电磁的、红外的、或半导体系统、装置或设备，或者上述内容的任何合适组合。机器可读存储介质的更具体示例会包括基于一个或多个线的电气连接、便携式计算机盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦除可编程只读存储器(EPROM或快闪存储器)、光纤、便捷式紧凑盘只读存储器(CD-ROM)、光学储存设备、磁储存设备、或上述内容的任何合适组合。
为了提供与用户的交互，可以在计算机上实施此处描述的系统和技术，该计算机具有：用于向用户显示信息的显示装置(例如，CRT(阴极射线管)或者LCD(液晶显示器)监视器)；以及键盘和指向装置(例如，鼠标或者轨迹球)，用户可以通过该键盘和该指向装置来将输入提供给计算机。其它种类的装置还可以用于提供与用户的交互；例如，提供给用户的反馈可以是任何形式的传感反馈(例如，视觉反馈、听觉反馈、或者触觉反馈)；并且可以用任何形式(包括声输入、语音输入或者、触觉输入)来接收来自用户的输入。
可以将此处描述的系统和技术实施在包括后台部件的计算系统(例如，作为数据服务器)、或者包括中间件部件的计算系统(例如，应用服务器)、或者包括前端部件的计算系统(例如，具有图形用户界面或者网络浏览器的用户计算机，用户可以通过该图形用户界面或者该网络浏览器来与此处描述的系统和技术的实施方式交互)、或者包括这种后台部件、中间件部件、或者前端部件的任何组合的计算系统中。可以通过任何形式或者介质的数字数据通信(例如，通信网络)来将系统的部件相互连接。通信网络的示例包括：局域网(LAN)、广域网(WAN)和互联网。
计算机系统可以包括客户端和服务器。客户端和服务器一般远离彼此并且通常通过通信网络进行交互。通过在相应的计算机上运行并且彼此具有客户端-服务器关系的计算机程序来产生客户端和服务器的关系。服务器可以是云服务器，又称为云计算服务器或云主机，是云计算服务体系中的一项主机产品，以解决传统物理主机与虚拟专用服务器(VPs，Ⅵirtual Private Server)服务中存在的管理难度大，业务扩展性弱的缺陷。服务器也可以为分布式系统的服务器，或者是结合了区块链的服务器。
应该理解，可以使用上面所示的各种形式的流程，重新排序、增加或删除步骤。例如，本发申请中记载的各步骤可以并行地执行也可以顺序地执行也可以不同的次序执行，只要能够实现本公开公开的技术方案所期望的结果，本文在此不进行限制。
上述具体实施方式，并不构成对本公开保护范围的限制。本领域技术人员应该明白的是，根据设计要求和其他因素，可以进行各种修改、组合、子组合和替代。任何在本公开的精神和原则之内所作的修改、等同替换和改进等，均应包含在本公开保护范围之内。

Claims (30)

1.一种网约车信息处理方法，包括：
获取客户端发送的网约车查询条件，所述查询条件包括起始地和目的地信息；
依据所述查询条件确定查询时间区间；
针对所述查询时间区间内的各时刻，分别计算从各时刻出发到达目的地的代价信息；
依据从各时刻出发到达目的地的代价信息，确定满足所述查询条件的时刻作为推荐出发时刻；
利用所述推荐出发时刻，确定推荐发单时刻；
向所述客户端返回查询结果，所述查询结果包括所述推荐发单时刻，或者，所述查询结果包括所述推荐发单时刻和所述推荐发单时刻对应的代价信息。
2.根据权利要求1所述的方法，其中，所述查询条件还包括查询时间区间；
所述依据从各时刻出发到达目的地的代价信息，确定满足所述查询条件的时刻作为推荐出发时刻包括：将所述查询时间区间内对应代价最小的N个时刻作为推荐出发时刻，所述N为预设的正整数。
3.根据权利要求1所述的方法，其中，所述查询条件还包括代价范围；
所述依据从各时刻出发到达目的地的代价信息，确定满足所述查询条件的时刻作为推荐出发时刻包括：将所述查询时间区间内对应代价符合所述用户设置的代价范围的时刻作为推荐出发时刻。
4.根据权利要求1所述的方法，其中，依据所述查询条件确定查询时间区间包括：
若所述查询条件包含用户设置的查询时间区间，则采用用户设置的查询时间区间；否则，采用默认设置的查询时间区间。
5.根据权利要求1所述的方法，其中，所述分别计算从各时刻出发到达目的地的代价信息包括：
针对所述各时刻分别执行：基于对该时刻的路况预估结果，对所述起始地和目的地进行路线规划，得到该时刻出发到达目的地的预估时长信息作为从该时刻出发到达目的地的代价信息；或者，基于对该时刻的路况预估结果，对所述起始地和目的地进行路线规划，得到该时刻出发到达目的地的路线长度和预估时长，利用网约车计价规则进行价格计算，将计算得到的价格作为从该时刻出发到达目的地的代价信息。
6.根据权利要求1所述的方法，其中，利用所述推荐出发时刻，确定推荐发单时刻包括：
利用所述推荐出发时刻对网约车接驾时间进行预估，得到预估接单时刻；
利用所述预估接单时刻对接单时间进行预估，得到所述推荐发单时刻。
7.根据权利要求6所述的方法，其中，利用所述推荐出发时刻对网约车接驾时间进行预估，得到预估接单时刻包括：
按照预设的初始第一时长，确定所述推荐出发时刻之前第一时长的时刻作为候选接单时刻；
预估所述候选接单时刻所需的接驾时长；
若预估的接驾时长小于或等于所述第一时长，则确定所述候选接单时刻为所述预估接单时刻，否则，延长所述第一时长，重新转至所述确定所述推荐出发时刻之前第一时长的时刻作为候选接单时刻的步骤。
8.根据权利要求7所述的方法，其中，预估所述候选接单时刻所需的接驾时长包括：
将所述用户的位置、目的地、所述代价信息、路线长度、天气信息和路况信息中的至少一种以及所述候选接单时刻输入接驾时长预估模型，得到所述候选接单时刻所需的接驾时长。
9.根据权利要求6所述的方法，其中，利用所述预估接单时刻对接单时间进行预估，得到所述推荐发单时刻包括：
按照预设的初始第二时长，确定所述预估接单时刻之前第二时长的时刻作为候选发单时刻；
预估所述候选发单时刻所需的接单时长；
若预估的接单时长小于或等于所述第二时长，则确定所述候选发单时刻为所述推荐发单时刻，否则，延长所述第二时长，重新转至所述确定所述预估接单时刻之前第二时长的时刻作为候选发单时刻的步骤。
10.根据权利要求9所述的方法，其中，预估所述候选发单时刻所需的接单时长包括：
将所述用户的位置、目的地、所述代价信息、路线长度和天气信息中的至少一种以及所述候选发单时刻输入接单时长预估模型，得到所述候选发单时刻所需的接单时长。
11.一种网约车信息处理方法，包括：
获取用户输入的网约车查询条件，所述查询条件包括起始地和目的地信息；
将所述查询条件发送给服务器端，并获取所述服务器端返回的查询结果，所述查询结果包括推荐发单时刻，或者所述查询结果包括推荐发单时刻和推荐发单时刻对应的代价信息；
展示所述查询结果。
12.根据权利要求11所述的方法，其中，所述推荐发单时刻对应的代价信息包括：
该时刻出发到达目的地的预估时长信息，或者，该时刻出发到达目的地的价格信息。
13.根据权利要求11所述的方法，还包括：
在所述界面上展现设置出发时间的组件；
获取到所述组件被触发的事件后，记录用户设置的出发时间；
在所述用户设置的出发时间到达或者在所述用户设置的出发时间之前预设时长，向用户展示提醒消息。
14.根据权利要求11所述的方法，还包括：
在所述界面上展现预约发单的组件；
获取到所述组件被触发的事件后，记录所述用户设置的发单时间；
在到达所述用户设置的发单时间时，发送从所述起始地到目的地的网约车订单。
15.一种网约车信息处理装置，包括：
条件接收单元，用于获取客户端发送的网约车查询条件，所述查询条件包括起始地和目的地信息；
区间确定单元，用于依据所述查询条件确定查询时间区间；
代价计算单元，用于针对所述查询时间区间内的各时刻，分别计算从各时刻出发到达目的地的代价信息；
第一推荐单元，用于依据从各时刻出发到达目的地的代价信息，确定满足所述查询条件的时刻作为推荐出发时刻；
第二推荐单元，用于利用所述推荐出发时刻，确定推荐发单时刻；
结果返回单元，用于向所述客户端返回查询结果，所述查询结果包括所述推荐发单时刻，或者，所述查询结果包括所述推荐发单时刻和所述推荐发单时刻对应的代价信息。
16.根据权利要求15所述的装置，其中，所述查询条件还包括查询时间区间，所述第一推荐单元具体用于将所述查询时间区间内对应代价最小的N个时刻作为推荐出发时刻，所述N为预设的正整数；或者，
所述查询条件还包括代价范围，所述第一推荐单元具体用于将所述查询时间区间内对应代价符合所述用户设置的代价范围的时刻作为推荐出发时刻。
17.根据权利要求15所述的装置，其中，所述区间确定单元具体用于：若所述查询条件包含用户设置的查询时间区间，则采用用户设置的查询时间区间；否则，采用默认设置的查询时间区间。
18.根据权利要求15所述的装置，其中，所述代价计算单元具体用于针对所述各时刻分别执行：
基于对该时刻的路况预估结果，对所述起始地和目的地进行路线规划，得到该时刻出发到达目的地的预估时长信息作为从该时刻出发到达目的地的代价信息；或者，
基于对该时刻的路况预估结果，对所述起始地和目的地进行路线规划，得到该时刻出发到达目的地的路线长度和预估时长，利用网约车计价规则进行价格计算，将计算得到的价格作为从该时刻出发到达目的地的代价信息。
19.根据权利要求15所述的装置，其中，所述第二推荐单元包括：
第一预估子单元，用于利用所述推荐出发时刻对网约车接驾时间进行预估，得到预估接单时刻；
第二预估子单元，用于利用所述预估接单时刻对接单时间进行预估，得到所述推荐发单时刻。
20.根据权利要求19所述的装置，其中，所述第一预估子单元具体用于：
按照预设的初始第一时长，确定所述推荐出发时刻之前第一时长的时刻作为候选接单时刻；
预估所述候选接单时刻所需的接驾时长；
若预估的接驾时长小于或等于所述第一时长，则确定所述候选接单时刻为所述预估接单时刻，否则，延长所述第一时长，重新转至所述确定所述推荐出发时刻之前第一时长的时刻作为候选接单时刻的操作。
21.根据权利要求20所述的装置，其中，所述第一预估子单元在预估所述候选接单时刻所需的接驾时长时，具体执行：将所述用户的位置、目的地、所述代价信息、路线长度、天气信息和路况信息中的至少一种以及所述候选接单时刻输入接驾时长预估模型，得到所述候选接单时刻所需的接驾时长。
22.根据权利要求19所述的装置，其中，所述第二预估子单元具体用于：
按照预设的初始第二时长，确定所述预估接单时刻之前第二时长的时刻作为候选发单时刻；
预估所述候选发单时刻所需的接单时长；
若预估的接单时长小于或等于所述第二时长，则确定所述候选发单时刻为所述推荐发单时刻，否则，延长所述第二时长，重新转至所述确定所述预估接单时刻之前第二时长的时刻作为候选发单时刻的操作。
23.根据权利要求22所述的装置，其中，所述第二预估子单元在预估所述候选发单时刻所需的接单时长时，具体执行：将所述用户的位置、目的地、所述代价信息、路线长度和天气信息中的至少一种以及所述候选发单时刻输入接单时长预估模型，得到所述候选发单时刻所需的接单时长。
24.一种网约车信息处理装置，包括：
条件获取单元，用于获取用户输入的网约车查询条件，所述查询条件包括起始地和目的地信息；
服务端交互单元，用于将所述查询条件发送给服务器端，并获取所述服务器端返回的查询结果，所述查询结果包括推荐发单时刻，或者所述查询结果包括推荐发单时刻和推荐发单时刻对应的代价信息；
结果展示单元，用于展示所述查询结果。
25.根据权利要求24所述的装置，其中，所述推荐发单时刻对应的代价信息包括：
该时刻出发到达目的地的预估时长信息，或者，该时刻出发到达目的地的价格信息。
26.根据权利要求24所述的装置，其中，所述结果展示单元，还用于在所述界面上展现设置出发时间的组件；
该装置还包括：第一组件响应单元，用于获取到所述组件被触发的事件后，记录用户设置的出发时间；在所述用户设置的出发时间到达或者在所述用户设置的出发时间之前预设时长，通过所述结果展示单元向用户展示提醒消息。
27.根据权利要求24所述的装置，其中，所述结果展示单元，还用于在所述界面上展现预约发单的组件；
第二组件响应单元，用于获取到所述组件被触发的事件后，记录所述用户设置的发单时间；在到达所述用户设置的发单时间时，通过所述服务端交互单元发送从所述起始地到目的地的网约车订单。
28.一种电子设备，包括：
至少一个处理器；以及
与所述至少一个处理器通信连接的存储器；其中，
所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够执行权利要求1-14中任一项所述的方法。
29.一种存储有计算机指令的非瞬时计算机可读存储介质，其中，所述计算机指令用于使所述计算机执行权利要求1-14中任一项所述的方法。
30.一种计算机程序产品，包括计算机程序，所述计算机程序在被处理器执行时实现根据权利要求1-14中任一项所述的方法。
CN202110633451.9A 2021-06-07 2021-06-07 网约车信息处理方法、装置、设备和计算机存储介质 Pending CN113408877A (zh)

Priority Applications (5)

Application Number Priority Date Filing Date Title
CN202110633451.9A CN113408877A (zh) 2021-06-07 2021-06-07 网约车信息处理方法、装置、设备和计算机存储介质
KR1020237007589A KR20230047444A (ko) 2021-06-07 2021-11-17 온라인 카헤일링 정보 처리 방법, 장치, 기기 및 컴퓨터 기록 매체
EP21916645.1A EP4123527A4 (en) 2021-06-07 2021-11-17 ONLINE CAR CALL INFORMATION PROCESSING METHOD AND APPARATUS AND COMPUTER STORAGE DEVICE AND MEDIUM
PCT/CN2021/131178 WO2022257357A1 (zh) 2021-06-07 2021-11-17 网约车信息处理方法、装置、设备和计算机存储介质
JP2023514809A JP7460062B2 (ja) 2021-06-07 2021-11-17 オンライン予約車両情報処理方法、装置、機器、及びコンピュータ記憶媒体

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202110633451.9A CN113408877A (zh) 2021-06-07 2021-06-07 网约车信息处理方法、装置、设备和计算机存储介质

Publications (1)

Publication Number Publication Date
CN113408877A true CN113408877A (zh) 2021-09-17

Family

ID=77676784

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202110633451.9A Pending CN113408877A (zh) 2021-06-07 2021-06-07 网约车信息处理方法、装置、设备和计算机存储介质

Country Status (5)

Country Link
EP (1) EP4123527A4 (zh)
JP (1) JP7460062B2 (zh)
KR (1) KR20230047444A (zh)
CN (1) CN113408877A (zh)
WO (1) WO2022257357A1 (zh)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2022257357A1 (zh) * 2021-06-07 2022-12-15 北京百度网讯科技有限公司 网约车信息处理方法、装置、设备和计算机存储介质
CN116383368A (zh) * 2023-04-25 2023-07-04 武汉维序科技有限公司 一种基于大数据的智能信息推送方法及系统

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107844853A (zh) * 2017-10-23 2018-03-27 重庆大学 一种利用动态价格预测减少网约车费用的乘车推荐系统
CN109146280A (zh) * 2018-08-14 2019-01-04 北京三快在线科技有限公司 一种推送信息的方法、装置及系统
CN110737849A (zh) * 2019-10-10 2020-01-31 北京百度网讯科技有限公司 出行方案的推荐方法、装置、设备及存储介质
US20210201393A1 (en) * 2019-12-31 2021-07-01 Beijing Didi Infinity Technology And Development Co., Ltd. System and method for bidding-based ridesharing

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP5777373B2 (ja) 2011-03-31 2015-09-09 株式会社日本総合研究所 カーステーション負荷分散システム
JP6478082B2 (ja) 2013-11-13 2019-03-06 三菱重工機械システム株式会社 経路案内装置、経路案内方法、およびプログラム
KR20170016537A (ko) * 2015-08-03 2017-02-14 엔에이치엔엔터테인먼트 주식회사 콜택시 서비스 서버, 이를 갖는 콜택시 서비스 시스템 및 이를 이용한 콜택시 서비스 방법
CN111178558B (zh) * 2018-11-09 2021-03-12 北京嘀嘀无限科技发展有限公司 网约车订单处理方法及装置、计算机设备和可读存储介质
CN111369025A (zh) * 2020-03-03 2020-07-03 北京嘀嘀无限科技发展有限公司 一种信息显示方法、装置、存储介质以及电子设备
CN111667083B (zh) * 2020-06-11 2023-07-14 北京白龙马云行科技有限公司 网约车预估价确定方法和装置
CN113408877A (zh) * 2021-06-07 2021-09-17 北京百度网讯科技有限公司 网约车信息处理方法、装置、设备和计算机存储介质

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107844853A (zh) * 2017-10-23 2018-03-27 重庆大学 一种利用动态价格预测减少网约车费用的乘车推荐系统
CN109146280A (zh) * 2018-08-14 2019-01-04 北京三快在线科技有限公司 一种推送信息的方法、装置及系统
CN110737849A (zh) * 2019-10-10 2020-01-31 北京百度网讯科技有限公司 出行方案的推荐方法、装置、设备及存储介质
US20210201393A1 (en) * 2019-12-31 2021-07-01 Beijing Didi Infinity Technology And Development Co., Ltd. System and method for bidding-based ridesharing

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2022257357A1 (zh) * 2021-06-07 2022-12-15 北京百度网讯科技有限公司 网约车信息处理方法、装置、设备和计算机存储介质
CN116383368A (zh) * 2023-04-25 2023-07-04 武汉维序科技有限公司 一种基于大数据的智能信息推送方法及系统
CN116383368B (zh) * 2023-04-25 2023-10-03 武汉维序科技有限公司 一种基于大数据的智能信息推送方法及系统

Also Published As

Publication number Publication date
EP4123527A4 (en) 2023-08-30
EP4123527A1 (en) 2023-01-25
JP2023540731A (ja) 2023-09-26
WO2022257357A1 (zh) 2022-12-15
JP7460062B2 (ja) 2024-04-02
KR20230047444A (ko) 2023-04-07

Similar Documents

Publication Publication Date Title
JP6568240B2 (ja) 運輸サービスの料金を求める方法及びシステム
US9377319B2 (en) Estimating times to leave and to travel
CN101622653B (zh) 适应于用户旅行的交通信息
US8738289B2 (en) Advanced routing of vehicle fleets
CN110869953A (zh) 推荐交通出行服务的系统和方法
US20200005420A1 (en) Systems and methods for transportation capacity dispatch
US9959339B2 (en) Journey time estimation
CN113408877A (zh) 网约车信息处理方法、装置、设备和计算机存储介质
TWI703526B (zh) 使用機器學習技術來估價的系統和方法
CN114581180A (zh) 一种充电站推荐方法、充电桩状态的确定方法及装置
JP7078357B2 (ja) 配信装置、配信方法および配信プログラム
US20140343974A1 (en) Selecting a Subset of Transit Trips Based on Time and Duration
AU2018217973A1 (en) Dynamic selection of geo-based service options in a network system
CN111476389A (zh) 一种预估接单等待时长的方法及装置
CN111859172A (zh) 信息推送方法、装置、电子设备和计算机可读存储介质
CN114254784A (zh) 信息推送方法、信息推送装置和存储介质
CN111667083B (zh) 网约车预估价确定方法和装置
CN113761398B (zh) 信息推荐方法、装置、电子设备以及存储介质
CN111369025A (zh) 一种信息显示方法、装置、存储介质以及电子设备
CN111798283A (zh) 订单派发方法、装置、电子设备及计算机可读存储介质
CN114692968A (zh) 取号处理方法、装置以及电子设备
CN112529338A (zh) 一种顺路程度计算方法
CN112258270A (zh) 一种拼车行程生成的方法及装置
CN113407839B (zh) 出行方式的确定方法、装置、设备和存储介质
CN111523802B (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: 20210917

RJ01 Rejection of invention patent application after publication