叫車訂單的分配方法和裝置的制造方法
【技術領域】
[0001] 本發明的實施例一般涉及在打車軟件平臺中使用的方法和裝置，并且更特別地涉 及叫車訂單的分配方法和裝置。
【背景技術】
[0002] 隨著打車軟件的普及，人們的打車習慣已經被深刻的改變。以某打車軟件為例，乘 客打開軟件發出叫車需求，該軟件的服務器接收到叫車請求后，自動匹配該乘客周圍的多 個司機，并利用大數據計算出與該訂單最為匹配的若干司機，將該訂單推送給相關司機。司 機端收到訂單并將其展現，由司機決定發起搶單行為決定接受或不接受。
[0003] 打車軟件作為連接乘客和出租車司機的平臺，如何對司機和訂單進行匹配，也就 是如何選擇"哪些訂單播給哪些司機，哪些司機聽哪些訂單"，是平臺的核心體驗。
[0004] 首先，對乘客而言，當然希望其訂單有較高的概率被司機應答；對司機而言，希望 自己愿意接受的訂單有較大概率能搶到；對于打車軟件平臺而言，希望每個乘客的訂單都 能成交，同時大多數司機都能搶到訂單。
[0005] 目前大多數的聯系司機和訂單的交易平臺的打車軟件，在訂單分配方面大多采用 如下兩種方式進行分配。
[0006] 其一，以訂單為中心，通過為訂單尋找合適司機的方式進行分配。在這種分配方式 下，訂單分配系統的觸發方式為單個訂單觸發，某一乘客發起打車請求，訂單分配系統收到 訂單請求后，在待接單司機里為該訂單尋找合適司機，進行推送；司機收到該訂單推送，根 據自己的意愿決定是否接單，而是否能夠成功接單，還要看其他司機對該訂單的搶單情況。
[0007] 其二，以司機為中心，通過為司機尋找合適訂單的方式進行分配。這種分配方式較 上面的分配方式而言在系統實現上相對簡單，直接以單個司機觸發，比如，某一司機當前一 個訂單推送完后，客戶端就不斷給服務端發起推送訂單請求，服務端接到司機客戶端的請 求后，將該司機轉發給訂單分配系統，訂單分配系統拿到該司機后，在訂單數據庫中搜尋未 成交訂單，計算該司機與每個訂單的相關性，選擇N個（比如N = 2)最匹配的推送給司機， 由司機決定是否響應。若司機未響應且訂單推送完后，司機客戶端再次向服務器發起推送 訂單請求，繼續下一輪訂單推送。
[0008] 然而，無論是訂單-司機一對多的訂單分配系統還是訂單-司機多對一的訂單分 配系統，都無法確保準確找到最優的匹配方式，因此給平臺的整體效果帶來損失。
[0009] 從上面的分析可以看出，無論是訂單-司機一對多的訂單分配系統還是訂單-司 機多對一的訂單分配系統，都無法確保準確找到最優的匹配方式，因此給平臺的整體效果 帶來一定的損失。而產生這個問題的根本原因在于：其一，對于一對多的分配方式，始終有 一方（訂單或司機）以個體為中心，無法兼顧到其他個體；其二，該分配機制不滿足機制設 計中的激勵相容原理，即個體的目標與整體平臺目標不完全一致。
【發明內容】
[0010] 鑒于現有技術中存在的上述問題，本發明的實施例的目的之一在于：提供一種在 分配過程中以訂單群和司機群作為分配基礎的訂單-司機多對多的訂單分配系統模型，從 而解決現有技術中所存在的上述技術問題。
[0011] 根據本發明的第一方面，提供了一種叫車訂單的分配方法，包括：確定包括多個待 分配訂單的訂單群和包括多個待接單用戶的用戶群；基于所述訂單群和所述用戶群來確定 訂單分配方式；以及根據所確定的訂單分配方式，向所述用戶群中的用戶推送所述訂單群 中的訂單。
[0012] 根據本發明的一些實施例，其中確定包括多個待分配訂單的訂單群和包括多個待 接單用戶的用戶群包括：基于一個地理區域來確定所述訂單群和所述用戶群。
[0013] 根據本發明的一些實施例，其中基于一個地理區域來確定所述訂單群和所述用戶 群包括：將所述地理區域中的當前所有訂單確定為所述訂單群，并且將所述地理區域中的 當前所有待接單用戶確定為所述用戶群。
[0014] 根據本發明的一些實施例，其中所述地理區域包括城市。
[0015] 根據本發明的一些實施例，其中基于所述訂單群和所述用戶群來確定訂單分配方 式包括：基于所述訂單群和所述用戶群，并且根據訂單成交率、搶單成功率以及聽單搶單率 中的至少一項來確定所述訂單分配方式。
[0016] 根據本發明的一些實施例，其中根據訂單成交率、搶單成功率以及聽單搶單率中 的至少一項來確定所述訂單分配方式包括：計算所述訂單成交率、搶單成功率以及聽單搶 單率的加權和；以及確定使得所述加權和最大的訂單分配方式，作為所確定的訂單分配方 式。
[0017] 根據本發明的一些實施例，其中基于所述用戶群中的任一用戶對所述訂單群中的 任一訂單的搶單概率，分別計算所述訂單成交率、所述搶單成功率以及所述聽單搶單率。
[0018] 根據本發明的一些實施例，其中基于與待接單用戶和發出訂單的乘客有關的狀態 特征來計算所述搶單概率。
[0019] 根據本發明的一些實施例，其中所述狀態特征包括以下各項中的至少一項：待接 單用戶與乘客之間的距離、訂單預期收入、乘客加價、乘客的目的地方向是否與待接單用戶 的預期行駛方向一致。
[0020] 根據本發明的一些實施例，其中使用以下算法中的至少一種來確定使得所述加權 和最大的訂單分配方式：窮舉法、遺傳算法、蟻群算法、禁忌搜索算法、模擬退火算法、以及 基于貪心的爬山算法。
[0021] 根據本發明的一些實施例，其中確定使得所述加權和最大的訂單分配方式包括： 基于預定規則來生成初始的訂單分配方式；以及使用基于貪心的爬山算法對所述初始的訂 單分配方式進行優化，從而確定使得所述加權和最大的訂單分配方式。
[0022] 根據本發明的一些實施例，其中使用訂單緩存區和用戶緩存區分別存儲所述訂單 群和所述用戶群，并且定期地讀取所述訂單緩存區和所述用戶緩存區以確定訂單分配方 式。
[0023] 根據本發明的一些實施例，其中在訂單被創建時或者被推送但是在一段時間之后 未被搶單，將該訂單添加到所述訂單緩存區中；并且在訂單被推送給用戶之后，從所述訂單 緩存區刪除該訂單。
[0024] 根據本發明的一些實施例，其中當用戶處于待接單狀態時，將該用戶添加到所述 用戶緩存區中；并且當用戶搶單成功之后，從所述用戶緩存區刪除該用戶。
[0025] 根據本發明的第二方面，提供了一種叫車訂單的分配裝置，包括：第一確定單元， 被配置為確定包括多個待分配訂單的訂單群和包括多個待接單用戶的用戶群；第二確定單 元，被配置為基于所述訂單群和所述用戶群來確定訂單分配方式；以及推送單元，被配置為 根據所確定的訂單分配方式，向所述用戶群中的用戶推送所述訂單群中的訂單。
[0026] 通過采用本發明的實施例的叫車訂單的分配方法和裝置，實現了以訂單群和司機 群作為分配基礎的訂單-司機多對多的訂單分配系統模型，并且確定全局期望目標和個體 期望目標，建立全局目標和個體目標間的聯系，從而可以獲得對于平臺的整體效果而言的 最優的訂單匹配方式。
【附圖說明】
[0027] 通過參考附圖閱讀下文的詳細描述，本發明的實施例的上述以及其他目的、特征 和優點將變得容易理解。在附圖中，以示例性而非限制性的方式示出了本發明的若干實施 例，其中：
[0028] 圖1示意性地示出了根據本發明的一個實施例的一種叫車訂單的分配方法；
[0029] 圖2示意性地示出了叫車訂單的分配方法的一種在工程上的實施方式；以及 [0030] 圖3示意性地示出了根據本發明的一個實施例的一種叫車訂單的分配裝置。
【具體實施方式】
[0031] 下面將參考附圖來描述本發明的實施例的原理和精神。應當理解，描述這些實施 例僅是為了使本領域的技術人員能夠更好地理解并實施本發明，而并非以任何方式限制本 發明的范圍。
[0032] 參考圖1，圖1示意性地示出了根據本發明的一個實施例的一種叫車訂單的分配 方法100。方法100在開始之后進入步驟101。在步驟101中，確定包括多個待分配訂單的 訂單群和包括多個待接單用戶的用戶群。
[0033] 本領域的技術人員可以理解，待分配訂單可以包括乘客通過打車軟件平臺創建但 是尚未推送給司機的打車訂單。本領域的技術人員還可以理解，待分配訂單也可以包括乘 客通過打車軟件平臺所創建并且已經向司機推送但是在一段時間之后沒有被搶單的打車 訂單。本領域的技術人員可以進一步理解，只要是在某一時間需要向司機推送的訂單都可 以屬于這里的待分配訂單，本發明在這個方面不受限制。
[0034] 本領域的技術人員可以理解，待接單用戶可以包括打車平臺的司機用戶。本領域 的技術人員還可以理解，如果根據本發明的實施例的打車軟件運用至其他的類型的運輸場 景中，待接單用戶還可以包括各種其他交通工具的各種操作人員。本領域的技術人員將進 一步理解，只要是在某一時間處于可以接受訂單狀態的打車軟件平臺的用戶都可以屬于這 里的待接單用戶，本發明在這個方面不受限制。
[0035] 應當注意，在步驟101中，多個待分配訂單也包括兩個待分配訂單，并且多個待接 單用戶也包括兩個待接單用戶。換句話說，盡管根據本發明的實施例的叫車訂單的分配方 法100通常使用在大量待分配訂單和大量待接單用戶的場景中，但是方法100也能夠應用 在只有兩個訂單和兩個司機的場景中。
[0036] 根據本發明的一些實施例，在步驟101中，可以基于一個地理區域來確定訂單群 和用戶群。具體而言，可以將某個地理區域中的當前所有訂單確定為訂單群，并且將該地理 區域中的當前所有待接單用戶確定為用戶群。例如，該地理區域可以包括省、城市、縣市等 通過行政區劃來劃分的地理區域，也可以是通過地理上的經度和