A cross-platform order matching method based on graph data federation

Abstract

This invention discloses a cross-platform order matching method based on graph data federation, belonging to the field of federated computing. First, matching is performed within each platform, where each platform matches the input order set and ride-hailing vehicle set within the current time period. Then, unmatched driver and order data are shared among the platforms, forming a new global order set and a new global ride-hailing driver set, and a global bipartite graph is established. Further matching is performed on the global bipartite graph. Simultaneously, an incentive mechanism is proposed, using transfer payment rewards to incentivize resource sharing among parties. This invention can optimize overall service quality, has good scalability, and the proposed incentive mechanism enables cross-platform ride-hailing capacity resource sharing and mutual benefit.

Description

Technical Field

[0001] This invention belongs to the field of federated computing and relates to the federated matching problem of cross-platform resource sharing among ride-hailing platforms. Specifically, it relates to a method for incentivizing ride-hailing platforms to share supply and demand resources and perform cross-platform matching. Background Technology

[0002] (I) Current Status of Ride-Hailing Platform Matching

[0003] With the continuous development of the internet, aggregated ride-hailing platforms are becoming increasingly popular, and more and more people are choosing to use online ride-hailing platforms for rentals or direct travel. For online ride-hailing platforms, a core issue is matching drivers with customers; the quality of the matching algorithm directly determines the service quality. Specifically, the matching algorithm's workflow involves modeling the user's personalized needs (including time / distance / quality / budget, location, waiting time, etc.) and then matching the platform with the driver who best meets those needs. However, due to potential resource limitations of a single platform, such as a lack of drivers with specific locations, different online ride-hailing platforms may collaborate to share data, creating a federated collaborative computing scenario. Therefore, exploring how to design a matching mechanism that incentivizes cooperation and performs well is crucial. This invention focuses on solving the problem of multi-platform ride-hailing matching and its incentives in a federated scenario.

[0004] (II) Implementation and shortcomings of mainstream solutions

[0005] Currently, there is limited research on federated matching across multiple ride-hailing platforms. The mainstream approach primarily involves a single platform providing recommendations or matching to users internally, or simply calling its dispatching interface. However, if a platform could share user requests that it cannot process internally with other collaborating platforms, it could achieve efficient resource utilization and mutual benefit among the platforms. Specifically, different platforms use different internal algorithms to perform recommendations. The most common approach within a platform is the Top-K recommendation algorithm. The principle of the Top-K algorithm is to calculate the degree of matching between all ride-hailing drivers and the user's needs, considering factors such as whether some drivers are geographically closer or farther away. Then, all drivers are sorted according to their matching degree, and the top K most matched drivers are returned.

[0006] The drawback of this type of method is:

[0007] 1. Lack of incentive mechanisms for cooperation

[0008] To achieve the aforementioned federated matching, i.e., cross-platform sharing of service resources and user demand among platforms, in the context of ride-hailing platforms, cooperation between platforms requires an effective and stable incentive mechanism. This incentive mechanism should ensure that every participant in the federation is willing to actively and honestly participate in the federated tasks. The current incentive mechanism allows different platforms to accept orders from other platforms, but this incentive mechanism is not fair enough. For platforms of unequal size, this mechanism can lead to a "winner-takes-all" situation, hindering cooperation between platforms of different sizes. Summary of the Invention

[0009] To address the shortcomings of existing technologies, this invention proposes a cross-platform order matching method based on graph data federation. This method is applicable to matching schemes and incentive mechanisms involving cooperation among multiple ride-hailing platforms. Each platform first completes a round of matching using its own algorithm, and then the remaining resources are re-matched through cooperation among the platforms to maximize the overall service quality.

[0010] This invention relates to a cross-platform mediator matching method based on graph data federation, the specific steps of which are as follows:

[0011] Step 1: During the time period Each online ride-hailing platform receives a collection of orders. , indicating the first The collection of orders received by each platform, containing an order size of Each order in the order set Represented by a vector, each bit of the vector corresponds to a specific user's demand for a ride-hailing driver; Indicates the first A set of drivers from a ride-hailing platform, where each driver b is also represented as a vector, and each bit of the vector corresponds to a service quality of a demand type.

[0012] Step 2: Perform matching within each platform, i.e., the... The platform internally controls the current time period. Internal input order set Meet with ride-hailing drivers Perform a match.

[0013] Step 3: Cross-platform resource matching is performed, whereby each platform shares its unmatched driver and order data to form a global order set. Join with ride-hailing drivers across the board .

[0014] Step 4: Utilize the global order set obtained in Step 3 Join with ride-hailing drivers across the board Construct a global bipartite graph for all platforms E is the sum of edges in the global bipartite graph formed by the set of ride-hailing drivers and the set of user orders on each platform; E={(b,r,b·r)|b∈B',r∈R'}, where the edge weight between ride-hailing driver b and user order r is the same as that between a single platform, and is the inner product of vectors b and r, b·r.

[0015] Step 5: Process the global bipartite graph obtained in Step 4. Then, a second matching process is performed. The matching algorithm must satisfy the following condition: all ride-hailing platforms share all of their resources that have not been matched within the platform.

[0016] Step 6: Set up transfer payment benefits To incentivize resource sharing among all parties, the calculation method for each platform's transfer payment revenue in cross-platform matching is as follows:

[0017] 1) Record This means removing the first... The matching revenue obtained from cooperating with the remaining platforms after removing unmatched driver or order data from individual platforms is calculated using the methods in steps 4 and 5. The global revenue, constructed from the data provided by the remaining platforms using a global bipartite graph matching method, is totaled... This data further defines the proportion of transfer payment revenue. .

[0018] 2) Calculate for each platform The benefits of transfer payments in cooperation are:

[0019]

[0020] No. The final revenue of a ride-hailing platform is the sum of matching revenue and transfer payment revenue, i.e. .

[0021] Step 7: Repeat steps 2 through 6 above, and iteratively update the ride-hailing driver data. Service quality.

[0022] The advantages of this invention are:

[0023] 1. The cross-platform order matching method based on graph data federation in this invention does not directly restrict the methods used within the platform. Various different schemes can be used within the platform, such as Top-K algorithm, KM matching algorithm and greedy matching algorithm, which makes the design of this invention have good scalability.

[0024] 2. This invention proposes a cross-platform order matching method based on graph data federation, which sets requirements for the global matching algorithm. The global matching algorithm should encourage all participants to upload all data. In other words, the global benefit obtained by each platform uploading all unmatched data is higher than that obtained by using partial unmatched data for collaborative matching. This ensures the incentive compatibility of the overall mechanism.

[0025] 3. The cross-platform order matching method based on graph data federation in this invention fully considers the heterogeneous characteristics of different platforms. Different strategies can be adopted within the platform, and the added global matching can better realize resource sharing and allocation, thereby optimizing the overall service quality.

[0026] 4. This invention, based on a graph data federation-based cross-platform order matching method, encourages different ride-hailing platforms to actively and honestly participate in global matching cooperation by designing a transfer payment revenue scheme between platforms. This enables cross-platform driver and passenger resource sharing and mutual benefit. Attached Figure Description

[0028] Figure 1 This is a flowchart of the cross-platform order matching method based on graph data federation according to the present invention;

[0029] Figure 2 The matching results are shown in the figure below, which demonstrates the application of this invention to real ride-hailing data in different cities. Detailed Implementation

[0031] The present invention will now be described in further detail with reference to the accompanying drawings.

[0032] The overall process of this invention consists of the following steps, similar to those used in actual ride-hailing platforms. This dynamic matching algorithm typically selects a time window size of 1-2 minutes and divides the day into multiple equal time slots. This time slot division has two advantages: first, it reduces user waiting time; second, it reduces the amount of data that needs to be processed. Within a day, each time slot... The internal ride-hailing platform processes user order data and its driver data, and the overall algorithm steps are as follows:

[0033] Step 1: Assume there are K ride-hailing platforms cooperating, during the specified time period. Each platform within the platform will receive a collection of orders, using To indicate the first The collection of orders received by each platform, containing an order size of... Each order in the order set Represented by a vector, such as Each element of the vector corresponds to a specific user's demand for a ride-hailing driver. For example, an order. The first digit being 1 indicates a long user wait time, and the second digit being 1 indicates a high user budget. Similarly, using... Indicates the first A collection of drivers from various ride-hailing platforms, where each ride-hailing driver... It can also be represented as a vector, such as Each element of the vector corresponds to a service quality for a specific demand type. For example, driver b's first element being 0.5 represents his service quality in the travel scenario, and the second element being 0.2 represents his service price in the travel scenario. Therefore, the revenue that ride-hailing driver b receives for processing order r (i.e., the matching weight between order r and driver b) is the inner product of vector b and vector r. .

[0034] Step 2: Perform matching within each platform. The platform internally controls the current time period. Internal input order set Meet with ride-hailing drivers The matching process is performed. This patent does not limit the matching algorithm used within the platform; for example, platform A can use the classic KM matching algorithm, while platform B can use a greedy matching algorithm.

[0035] Step 3: During the time period Within a single platform, after the matching process is completed, each platform may have unmatched resources, which could be orders or ride-hailing drivers. Therefore, cross-platform resource matching can be enabled, whereby each platform shares its unmatched driver and order data to form a new global order set. And a new global ride-hailing driver aggregation , and Includes unmatched resources from all platforms.

[0036] Step 4: Utilize the global order set obtained in Step 3 Join with ride-hailing drivers across the board To construct a global bipartite graph for all platforms Let E be the sum of the edges in the global bipartite graph formed by the sets of ride-hailing drivers and user orders on each platform. Specifically, E = {(b, r, b·r) | b ∈ B', r ∈ R'}, where the edge weight between ride-hailing driver b and user order r is the same as that between a single platform, and is the inner product of vectors b and r, b·r.

[0037] Step 5: For the global bipartite graph obtained in Step 4 The matching process is repeated, but unlike the intra-platform matching in step 2, this matching algorithm must satisfy the following condition: only when all ride-hailing platforms share all their resources not matched within their platforms can the sum of the matching weights be maximized. The same matching algorithm used within a single platform can be employed here, such as a greedy algorithm or the KM algorithm. In practical applications, the revenue of each ride-hailing platform is generally defined as the sum of the matching weights. Since the global bipartite graph involves cross-platform resource matching, the revenue of a match is shared by the two ride-hailing platforms involved. For example, if an order from platform A is assigned to a driver from platform B in the matching result, then platform A and platform B share this revenue equally, and the global revenue is the sum of the revenues of all matching results. Clearly, the sum of the revenues of all platforms is the global revenue. For each matching algorithm, the corresponding global revenue can be calculated. and the Individual revenue of each platform .

[0038] Step 6: Set up transfer payment benefits Using incentives to encourage resource sharing among all parties is an important incentive-compatible approach. -VCG). For example, the transfer payment revenue of ride-hailing platform o. This indicates that the platform should receive an additional 10 units of revenue after participating in resource sharing; if This means that the ride-hailing platform, as a beneficiary in resource sharing, needs to pay 5 units of revenue to other ride-hailing platforms. Specifically, the calculation method for each platform's transfer payment revenue in cross-platform matching is as follows:

[0039] 1) Record This means removing the first... The matching revenue obtained from cooperating with the remaining platforms after removing unmatched driver or order data from individual platforms is calculated using the methods in steps 4 and 5. The global revenue, constructed from the data provided by the remaining platforms using a global bipartite graph matching method, is totaled... Data ( (Based on the number of platforms), this data can be used to define the proportion of transfer payment revenue. .

[0040] 2) Calculate for each platform The transfer payment income in the cooperation is In this case, the first The final revenue of a ride-hailing platform is the sum of matching revenue and transfer payment revenue, i.e. Under this ultimate benefit, resource sharing among platforms satisfies the incentive compatibility property, meaning that each ride-hailing platform can obtain the maximum ultimate benefit when sharing all its resources. This implies that this incentive scheme can encourage every honest and active participant to cooperate between platforms. The incentive compatibility of this mechanism is proven below:

[0041] The algorithm refers to the matching algorithm used when various ride-hailing platforms cooperate. Indicates the first The matching revenue that each platform obtains during the matching process. This is the incentive mechanism compensation. Transfer payment revenue from each platform Indicates except the first A bipartite graph constructed from unmatched data shared by one platform and other platforms. Then it means the first A graph composed of unmatched data from each platform. This represents a bipartite graph constructed from unmatched data shared across all platforms.

[0042] The proof is made by contradiction. Assume that the first... Some platforms choose not to upload all of their unmatched data, but only a portion of it. However, this increases one's own profit, meaning the following equation holds true, which is the assumption of proof by contradiction:

[0043]

[0044] Using the formula for calculating transfer payment benefits in section 6.2, the transfer payment benefits in the two cases are obtained as follows:

[0045]

[0046]

[0047] Subtract (D.2) from (D.1)

[0048]

[0049]

[0050]

[0051] Substituting (D.3) into the null hypothesis, the following equation holds:

[0052]

[0053] Please note, A subgraph, therefore a matching algorithm that satisfies the conditions given in step 5. exist The revenue generated on is no less than that in The revenue generated above, i.e. This leads to a contradiction, therefore the original hypothesis is false, and the proof is complete.

[0054] Therefore, ride-hailing platforms share all their resource information. It is Other ride-hailing platforms share all resources. The best response strategy at that time is - The VCG mechanism satisfies the incentive compatibility property.

[0055] Step 7: Repeat steps 2 through 6 above, and iteratively update the ride-hailing driver data. Service quality.

[0056] like Figure 2 The figure shows the matching results of applying the present invention to ride-hailing data in different cities. It can be seen that the incentive mechanism of the cross-platform order matching method based on graph data federation proposed in this invention has a significant improvement in revenue compared with other methods. KM-Local-Sum and LACB-Local-Sum refer to the sum of revenue obtained by each platform only performing internal matching. The algorithms used internally are the KM algorithm and the LACB algorithm, respectively. Fed-LTD-KM and Fed-LTD-LACB refer to the fact that in addition to internal matching, each platform also needs to share resources and perform global rematching.

Claims

1. A cross-platform order matching method based on graph data federation, characterized in that: The specific steps are as follows: Step 1: During the time period Each online ride-hailing platform receives a collection of orders. , indicating the first The collection of orders received by each platform, containing an order size of Each order in the order set Represented by a vector, each bit of the vector corresponds to a specific user's demand for a ride-hailing driver; Indicates the first A set of drivers from a ride-hailing platform, where each driver b is also represented as a vector, and each bit of the vector corresponds to a service quality of a demand type; Step 2: Perform matching within each platform, i.e., the... The platform internally controls the current time period. Internal input order set Meet with ride-hailing drivers Perform a match; Step 3: Cross-platform resource matching is performed, whereby each platform shares its unmatched driver and order data to form a global order set. Join with ride-hailing drivers across the board ; Step 4: Utilize the global order set obtained in Step 3 Join with ride-hailing drivers across the board Construct a global bipartite graph for all platforms E is the sum of edges in the global bipartite graph formed by the set of ride-hailing drivers and the set of user orders on each platform; E={(b,r,b·r)|b∈B',r∈R'}, where the edge weight between ride-hailing driver b and user order r is the same as that between a single platform, and is the inner product of vectors b and r, b·r; Step 5: Process the global bipartite graph obtained in Step 4. Then, a second matching process is performed. The matching algorithm must satisfy the following condition: all ride-hailing platforms share all of their resources that have not been matched within the platform. Step 6: Set up transfer payment benefits To incentivize resource sharing among all parties, the calculation method for each platform's transfer payment revenue in cross-platform matching is as follows: 1) Record This means removing the first... The matching revenue obtained from cooperating with the remaining platforms after removing unmatched driver or order data from individual platforms is calculated using the methods in steps 4 and 5. The global revenue, constructed from the data provided by the remaining platforms using a global bipartite graph matching method, is totaled... This data further defines the proportion of transfer payment revenue. ; 2) Calculate each platform The transfer payment benefit in cooperation is: No. The final revenue of a ride-hailing platform is the sum of matching revenue and transfer payment revenue, i.e. ; Step 7: Repeat steps 2-6 above and iteratively update the ride-hailing driver data. Service quality.

2. The cross-platform order matching method based on graph data federation as described in claim 1, characterized in that: dividing a day into a plurality of time periods T, for each time period The user order data received by the inner network car-hailing platform and the driver data held by the inner network car-hailing platform are processed by steps 1-7. 3.The cross-platform order matching method based on graph data federation according to claim 1, wherein: In step 2, the matching algorithm adopts a KM matching algorithm or a greedy matching algorithm.

Images