Online car-hailing scheduling method and system based on dynamic game model

Abstract

The invention provides an online car-hailing scheduling method and system based on a dynamic game model. The invention aims to solve the problem that an existing scheduling strategy is static and cannot balance interests of multiple parties. The method comprises the following steps: acquiring contextual data such as drivers, passengers and market environments related to orders; establishing a utility function model for quantifying decision preferences for the driver and the conductor; weight parameters in the model are dynamically calculated to reflect personalized preferences of the two parties in the current situation; constructing a game model between drivers and passengers and solving an equilibrium solution of the game model so as to determine an optimal matching strategy capable of balancing the benefits of the two parties; and finally, order sending is executed according to the strategy. According to the invention, dynamic balance of driver and passenger benefits is realized through dynamic gaming, the adaptive ability of the system to the market is enhanced, and the matching success rate and rule transparency are improved.

Description

TECHNICAL FIELD

[0001] The application relates to a dynamic game model-based online car-hailing dispatching method and system, and belongs to the technical field of online car-hailing dispatching. BACKGROUND

[0002] Order dispatching of an online car-hailing platform is a core link for guaranteeing platform efficiency and user experience. Existing online car-hailing dispatching systems mostly adopt a static rule-based dispatching strategy, for example, simply taking the pickup distance or order amount as the main dispatching basis, or using a fixed weighted scoring model. Although this kind of method is simple to implement, it exposes many defects in a complex market environment. First, the static strategy cannot adapt to the dynamic changes in the market. In scenarios such as morning and evening peak, bad weather or large-scale activities, the supply and demand relationship will fluctuate dramatically, and the fixed dispatching rules cannot effectively guide the aggregation of resources to high-demand areas, often leading to long-time no one to pick up passengers in some areas, while drivers gather in other areas to make empty trips, causing serious resource mismatch and efficiency loss.

[0003] Secondly, there are also attempts to use game theory for resource dispatching in existing technologies. For example, in some resource allocation scenarios, an optimal strategy is determined by establishing an utility function for the participants, constructing a game model and solving the equilibrium solution. However, when this kind of method is applied to online car-hailing dispatching, the parameters in the utility function are usually preset or static, failing to fully consider the individualized and dynamic changes in the interests of drivers and passengers in each specific transaction. For example, taking the platform's overall revenue or passenger waiting time as a one-way optimization target will ignore the game interaction between drivers and passengers. If it is too biased towards passengers, it may force drivers to assign low-income orders, leading to a surge in driver's refusal rate; if it is too biased towards drivers, it may prioritize the assignment of long-distance high-price orders, causing short-distance passenger's travel demand to be ignored for a long time. This one-way optimization based on static parameters will eventually lead to a decline in the satisfaction of drivers and passengers and a deterioration of the platform ecosystem.

[0004] In addition, some platforms use complex deep learning models for dispatching, but the decision-making process is not transparent, like a "black box", making it difficult for drivers and passengers to understand the logic of dispatching and pricing, and easily questioning the fairness of the platform, thereby reducing user trust and loyalty. SUMMARY

[0005] The purpose of the present application is to provide a dynamic game model-based online car-hailing dispatching method and system, aiming to solve the problem that the existing online car-hailing dispatching method adopts a static, one-way optimization strategy, which cannot dynamically and transparently balance the interests of drivers, passengers and the platform in real-time changing scenarios, resulting in supply and demand imbalance, interest conflicts and low user trust.

[0006] In a first aspect, the embodiments of the present application provide a dynamic game model-based online car-hailing dispatching method, comprising: obtaining context data related to an online car-hailing order, the context data comprising driver data and passenger data; based on the driver data and passenger data, establishing utility function models for quantifying the decision preferences of the driver and the passenger, respectively; based on the context data, dynamically calculating weight parameters in the utility function models to reflect the individualized preferences of the driver and the passenger in the current situation; based on the utility function models with the weight parameters, constructing a game model between the driver and the passenger, and solving the equilibrium solution of the game model to determine the optimal driver-passenger matching strategy; according to the optimal driver-passenger matching strategy, performing a dispatch operation under the condition of meeting a preset dispatch condition.

[0007] Based on the above method, optionally, the dynamic calculation of the weight parameters based on the context data comprises: based on real-time market environment data and user portrait data contained in the driver data and passenger data, dynamically adjusting the weight parameters in the utility function models.

[0008] Based on the above method, optionally, the dynamic calculation of the weight parameters of the driver's utility function model comprises at least one of the following: combining a real-time fuel price index and a driver cost sensitivity determined according to the driver data to dynamically calculate a cost weight in the driver utility function model; combining the unit time income and the unit mileage income of the order to dynamically calculate an income weight in the driver utility function model; combining the driver's time value and the regional average hourly wage to dynamically calculate a time weight in the driver utility function model.

[0009] Based on the above method, optionally, the dynamic calculation of the weight parameters of the passenger's utility function model comprises at least one of the following: combining the urgency of the order and the real-time traffic congestion index to dynamically calculate a time sensitivity weight in the passenger utility function model; combining a passenger consumption ability index determined according to the passenger data to dynamically calculate a fee weight in the passenger utility function model; combining a passenger service preference intensity determined according to the passenger data and a driver average score to dynamically calculate a driver score weight in the passenger utility function model.

[0010] Based on the above method, optionally, The utility function model established for the driver further includes a long-term benefit dimension, which is related to whether the destination of the order is a future high-demand area. and / or, The utility function model established for the passenger further includes a comfort dimension, which is related to the vehicle type of the candidate driver.

[0011] Based on the above method, optionally, the game model is a non-cooperative game model, and the equilibrium solution is a Nash equilibrium solution of the non-cooperative game model.

[0012] Based on the above method, optionally, the solving of the equilibrium solution of the game model includes: An iterative algorithm is used to start from an initial strategy combination, and the optimal reaction functions of the driver and the passenger are calculated in a loop until the strategies of both sides converge to the Nash equilibrium solution.

[0013] Based on the above method, optionally, the game model is a master-slave game model, in which the platform is a leader and the driver and the passenger are followers. The solving of the equilibrium solution includes that the platform first determines a game rule for maximizing the overall benefit or transaction rate of the platform, and then the driver and the passenger make decisions under the game rule to maximize their own interests.

[0014] Based on the above method, optionally, the preset order dispatching condition includes: The driver order acceptance willingness probability and the passenger acceptance willingness probability calculated based on the equilibrium solution are both higher than the respective preset threshold.

[0015] In a second aspect, the embodiments of the present application further provide a dynamic game model-based online car-hailing dispatching system, which includes: A data acquisition module is configured to acquire context data related to online car-hailing orders, the context data including driver data and passenger data. A utility function model establishment module is configured to establish utility function models for quantifying the decision preferences of drivers and passengers based on the driver data and the passenger data. A weight parameter calculation module is configured to dynamically calculate weight parameters in the utility function models based on the context data to reflect the individualized preferences of the drivers and the passengers in the current situation. A game solving module is configured to construct a game model between drivers and passengers based on the utility function models into which the weight parameters are substituted, and solve an equilibrium solution of the game model to determine an optimal driver-passenger matching strategy. The order dispatching execution module is configured to execute an order dispatching operation under a preset order dispatching condition according to the optimal driver-passenger matching strategy.

[0016] Compared with the prior art, the application has the following beneficial effects: 1. Dynamic interest balance is achieved: by constructing a dynamic model based on game theory, and explicitly and quantitatively expressing the interest demands of drivers and passengers, an equilibrium solution acceptable to both parties is solved, thereby achieving dynamic balance of the interests of drivers and passengers in online car-hailing dispatching, avoiding conflicts of interest caused by one-way optimization, and significantly improving the matching success rate and bilateral satisfaction.

[0017] 2. Market self-adaptability is enhanced: by dynamically calculating the utility function weight to respond to real-time market supply and demand changes, traffic conditions and individual preferences, the self-adaptability of the system to market fluctuations is enhanced, which can effectively guide the transport capacity and alleviate the problem of uneven distribution of transport capacity in peak periods or special scenarios.

[0018] 3. Rule transparency and fairness are improved: the parameters of the game model in the application have clear business meanings, and the calculation logic can be partially disclosed to users, thereby improving the transparency and explainability of the platform order dispatching rules, helping to solve the trust crisis caused by opaque algorithms, and enhancing the trust of drivers and passengers in the platform. BRIEF DESCRIPTION OF DRAWINGS

[0019] The accompanying drawings, which are incorporated into and form part of the specification, illustrate embodiments consistent with the application and, together with the description, serve to explain the principles of the application. Furthermore, the drawings and text are not intended to limit the scope of the inventive concepts in any way, but to illustrate the inventive concepts for a person skilled in the art by referring to specific embodiments.

[0020] Figure 1 An architectural diagram of an online car-hailing dispatching system according to an embodiment of the application is provided. Figure 2 A method flowchart of an online car-hailing dispatching method according to an embodiment of the application is provided. Figure 3 A signaling interaction timing diagram between a platform server, a passenger client and a driver client according to an embodiment of the application is provided. Figure 4 A schematic diagram of driver utility function weight calculation according to an embodiment of the application is provided. DETAILED DESCRIPTION

[0021] In order to make the objects, technical solutions and advantages of the present application clearer, the following will clearly and completely describe the technical solutions in the embodiments of the present application in conjunction with the embodiments of the present application. Obviously, the described embodiments are only a part of the embodiments of the present application, rather than all the embodiments of the present application. Based on the embodiments in the present application, all other embodiments obtained by a person of ordinary skill in the art without creative work fall within the protection scope of the present application. The following embodiments and features in the embodiments can be combined with each other without conflict.

[0022] Embodiment 1 The embodiment provides a specific implementation mode of a dynamic game model-based online car-hailing dispatching method and system. In an embodiment of the present application, the core of the scheme is that: through a dynamic strategy engine, multi-dimensional context data of orders, drivers, passengers and market environment are acquired in real time; based on the context data, weight parameters in utility function models of the drivers and the passengers are dynamically established and updated; then, a non-cooperative game model is constructed, and an optimal matching strategy capable of maximizing the comprehensive satisfaction of both parties is determined by solving the Nash equilibrium solution of the model, and finally, order dispatching is performed.

[0023] Referring to Figure 1 , the figure shows an architecture of an online car-hailing dispatching system provided by an embodiment of the present application. The system can be deployed in a background server of an online car-hailing platform, and takes a dynamic strategy engine 100 as the core. In logic, the dynamic strategy engine 100 can be divided into multiple functional layers or modules to cooperatively complete the entire dispatching process. Specifically, the dynamic strategy engine 100 includes a data acquisition layer 110, a parameter calculation layer 120 and a strategy execution layer 130.

[0024] The data acquisition layer 110 is responsible for acquiring all context data required for dispatching decision from various internal and external data sources. For example, it can be connected with an order processing system of the platform to receive real-time order request streams, connected with a global positioning system service of the vehicle to acquire real-time geographic positions, driving speeds and directions of the drivers, and connected with an application program interface of a third-party map service provider to acquire real-time urban traffic condition information such as road congestion indexes, expected travel times and the like, and acquire weather data through a meteorological service interface. Correspondingly, the data acquisition layer 110 also performs data interaction with a database system inside the platform to query and acquire historical data and user portrait data stored therein. These internal data can be stored in, for example, a relational database MySQL or a big data storage system HBase, Hive.

[0025] The parameter calculation layer 120 provides a basis for the dynamic implementation of the technical solution of the present application. This layer receives the data processed and integrated by the data acquisition layer 110, and its main function is to dynamically calculate the weight parameters in the utility function model of the driver and passenger. As an optional implementation manner, in order to realize the modularization and scalability of the function, the parameter calculation layer 120 can be further divided into a driver parameter calculator 121 and a passenger parameter calculator 122. Among them, the driver parameter calculator 121 focuses on calculating the weight affecting the driver's decision preference, and the passenger parameter calculator 122 focuses on calculating the weight affecting the passenger's decision preference.

[0026] The strategy execution layer 130 is responsible for scheduling the final formulation and execution of the decision. This layer receives the dynamic weight parameters output by the parameter calculation layer 120, and constructs and solves the game model accordingly. The strategy execution layer 130 internally contains a core component, namely the equilibrium solver 131, which has an algorithm for finding the equilibrium solution of the game model embedded therein. After the optimal matching strategy is solved, the strategy execution layer 130 will generate specific dispatching instructions according to the strategy, and send them to the dispatching gateway of the platform to complete the final dispatching operation.

[0027] The specific steps of the online car-hailing dispatching method based on the above system architecture in the present embodiment will be described below in conjunction with the method flowchart shown in Figure 2 .

[0028] Step S101: Obtain context data. When the platform server 30 (see Figure 3 ) receives a new online car-hailing order request from the passenger client 20, the data acquisition layer 110 of the dynamic strategy engine 100 starts to perform data acquisition operation. The obtained context data related to the online car-hailing order is multi-dimensional, including at least the following categories: 1. Order data: including the coordinates of the passenger's departure and destination, the expected departure time, the selected vehicle type (such as economy type, comfort type), etc.

[0029] 2. Passenger data: query the user portrait from the internal database through the user ID of the passenger. Such data can include: historical consumption habits (such as average order amount, commonly used vehicle type), historical behavior patterns (such as historical order cancellation rate, average waiting time for acceptance), user value level (such as high-frequency user, business travel label), and price and time sensitivity portrait label, etc.

[0030] 3. Driver data: The system filters out all idle or about-to-be-idle drivers within a certain geographical range as candidate drivers according to the pickup location of the order. For each candidate driver, the data acquisition layer 110 obtains relevant driver data, including: real-time location of the driver, vehicle information (such as vehicle model, vehicle age, fuel type or power), historical operation data (such as recent average hourly income, historical empty running rate, service score), and driver type (such as full-time or part-time driver determined by the platform according to their online time and order acceptance behavior), etc.

[0031] 4. Market environment data: Obtain macro-environmental information related to the current time and location, including: estimated pick-up time from the driver's current location to the passenger's departure location, estimated travel time from the passenger's departure location to the destination, real-time traffic congestion index, supply and demand heat map of the current area (i.e. the distribution density of drivers and orders), dynamic pricing coefficient or premium rate published by the platform, and external data such as fuel price index on the day, etc.

[0032] Step S102: Establish utility function model. After obtaining sufficient data, the system enters the model establishment stage. This step aims to establish a function model that can mathematically quantify the satisfaction level (i.e. utility) of both parties, i.e. the driver and the passenger, in a potential transaction, thereby providing a basis for subsequent game analysis, i.e. establishing utility function models for the driver and the passenger respectively to quantify their decision preferences based on driver data and passenger data. In this embodiment, the following utility function model can be defined: For the driver, the utility function is mainly from the dimensions of income, cost and time. A specific model can be represented as:

[0033] wherein: represents the estimated income of the order, which can be directly calculated from the pricing rules of the platform. represents the cost the driver needs to pay to complete the order, mainly including the empty running cost generated during the pick-up process (related to the pick-up distance and vehicle fuel consumption / electricity consumption) and the operation cost during the order trip. represents the time cost the driver needs to pay, which can include the estimated pick-up time and the possible waiting time for the passenger to get on the vehicle. are the income weight, cost weight and time weight respectively. These three weight parameters are dimensionless parameters, reflecting the relative importance of the driver to these three dimensions in the current situation.

[0034] For the passenger, the utility function is mainly from the dimensions of time, cost and service quality. A specific model can be represented as:

[0035] wherein: represents the expected total duration of the trip, including the expected waiting time and the expected travel time. This is a negative indicator, so its coefficient is negative. represents the order fee that the passenger needs to pay. This is also a negative indicator. represents the expected service quality, which can be quantified as the historical average service score of the candidate driver. are the time weight (or time sensitivity weight), the fee weight, and the driver score weight, respectively, reflecting the passenger’s relative preference for these three dimensions.

[0036] Step S103: dynamically calculating the weight parameters. It needs to be noted that, unlike the prior art which adopts static or fixed weights, this step is one of the key links embodying the dynamic characteristics of the present application. In the present embodiment, the parameter calculation layer 120 will dynamically calculate the above-mentioned six weight parameters for each potential match of each order based on the context data obtained in step S101. That is, the weight parameters in the utility function model are dynamically calculated based on the context data to reflect the individualized preferences of the driver and the passenger in the current situation.

[0037] In some embodiments, dynamically calculating the weight parameters based on the context data includes dynamically adjusting the weight parameters in the utility function model based on real-time market environment data and user portrait data contained in the driver data and the passenger data.

[0038] In some embodiments, the dynamic calculation of the weight parameters of the driver’s utility function model includes at least one of the following: dynamically calculating the cost weight in the driver’s utility function model in combination with the real-time fuel price index and the driver’s cost sensitivity determined according to the driver data; dynamically calculating the income weight in the driver’s utility function model in combination with the unit time income and the unit mileage income of the order; dynamically calculating the time weight in the driver’s utility function model in combination with the driver’s time value and the regional average hourly wage.

[0039] Please refer to Figure 4 which schematically shows the process of calculating the driver weight parameters by the driver parameter calculator 121.

[0040] For the calculation of the driver’s income weight , the income weight calculation module 121a can be used. For example, a full-time driver may pay more attention to income when completing performance targets at the end of the month. The calculation formula can be designed as:

[0041] in, Use the base weight value (e.g., 0.5). The dynamic premium rate released by the platform. and These represent the revenue per unit mileage and revenue per unit time for the order, respectively. In practice, the dynamic premium rate can be obtained in real-time from the regional premium table cached in Redis. The regional premium table is generated by taking the median premium rate of all orders placed within the same honeycomb (Uber H3 spatial index) at the order's origin coordinates during that time period (usually within a calendar hour, such as 12:00~13:00, distinguishing between weekdays and weekends). Function The function is used to evaluate the revenue efficiency of the order. If the revenue efficiency of the order is significantly higher than the historical average for the driver or the region, then... The value will be greater than 1, thus increasing the income weight. .

[0042] Furthermore, regarding the weighting of driver income... The calculation can be simplified to:

[0043] in, The driver income demand coefficient can be expressed as follows: =IPK_rate * (IPK of this order / Baseline IPK of this region) + IPH_rate * (IPH of this order / Baseline IPH of this region), where IPK_rate and IPH_rate represent the driver's emphasis on earnings per kilometer and earnings per hour, respectively. The initial settings are default (e.g., both 0.5). If drivers in this region value earnings per kilometer more, IPK_rate can be increased accordingly; if they value earnings per hour more, IPH_rate can be increased. Baseline IPK and baseline IPH are configured based on the average income per capita in the region and the income of drivers in this industry (including other platforms). For more refined operations, time-of-day configurations are needed; for example, IPK should be higher during peak hours than during off-peak hours. This indicates the degree to which driver income affects demand. A larger value indicates that the increase in driver income has a significant positive impact on demand; conversely, a smaller value indicates a smaller impact. (Under normal circumstances, driver income depends on the order price and the platform's commission rate). This indicates the degree to which the market premium (i.e., the portion of the market price that is higher than the base price) affects the quantity demanded. A relatively large premium indicates that an increase in the market premium has a significant negative impact on demand (because higher prices generally lead to lower demand). In practice, and The settings are designed for platform operators. The basis for these settings can be calculated using the least squares method based on historical platform data or obtained through linear regression using a large amount of data. If the verification is reliable, the settings can be integrated into the system.

[0044] For driver cost weighting The calculation can be performed by the cost weight calculation module 121b. For example, when oil prices rise, all drivers will be more sensitive to costs. A part-time driver operating a fuel-intensive vehicle will be even more cost-sensitive. The calculation formula can be designed as follows:

[0045] in, Weighted by the basic cost (e.g., 0.3). This is the fuel price index for the day, which can be calculated based on real-time fuel prices and vehicle fuel consumption models (e.g., if fuel prices rise by 10%, the index increases by 0.1). This is a cost sensitivity score determined based on driver data. For example, it can be achieved by using a pre-trained machine learning model, such as a logistic regression model or a gradient boosting decision tree model, taking into account features like the driver's vehicle fuel consumption, driver type (full-time / part-time), and historical empty-run rate, and outputting a sensitivity level (e.g., high, medium, low) or a continuous score. The higher the sensitivity, the better the function... The larger the value, the higher the cost weight. And it's also higher.

[0046] Furthermore, the function This can be simplified as follows:

[0047] For driver time weighting The calculation can be performed by the time weight calculation module 121c. For example, a driver with a high historical average hourly wage has a higher opportunity cost of time and is therefore more sensitive to non-commercial time (such as long-distance pick-up and drop-off). The calculation formula can be designed as follows:

[0048] in, Use the base time weight (e.g., 0.2). This represents the value of a driver's time, which can be calculated based on the driver's historical order revenue and time distribution (such as the average hourly revenue). This represents the average hourly wage for the region, obtained from internal platform data. Specifically, the median hourly wage of drivers serving on the platform can be used.

[0049] Similarly, the weight parameters of the dynamically calculated passenger utility function model include at least one of the following: By combining the urgency of the order with the real-time traffic congestion index, the time sensitivity weight in the passenger utility function model is dynamically calculated; By combining the passenger spending power index determined based on the passenger data, the cost weight in the passenger utility function model is dynamically calculated. By combining the passenger service preference intensity determined based on the passenger data and the average driver rating, the driver rating weight in the passenger utility function model is dynamically calculated.

[0050] Specifically, the passenger parameter calculator 122 also dynamically calculates the passenger's weight parameters: for passenger time weights... The calculation can combine the urgency of the order with real-time traffic conditions. For example, an order departing from an airport or train station can be classified as "high" urgency by the system. The calculation formula can be designed as follows:

[0051] in, Use the base time weight (e.g., 0.6). The urgency of an order (which can be a quantifiable score) can be categorized based on the passenger's historical behavior (such as business travel tags, frequent destination changes). The current traffic congestion index can be obtained through the real-time traffic interface of a third-party map service (such as the Gaode Map API). When the passenger's departure point is a transportation hub and traffic is congested, the function... The value will increase significantly, thereby increasing the time weight. This indicates that passengers value time highly at this moment.

[0052] Furthermore, the function This can be simplified as follows:

[0053] passenger cost weighting The calculation can be combined with passenger user profiles. For example, a user marked as "price-sensitive" or with a low average historical order spending will have a higher weighting on the cost. The calculation formula can be designed as follows:

[0054] in, Weighted by the base cost (e.g., 0.3). This is a spending power index determined based on passengers' historical consumption data, such as calculations based on the average price of historical orders. The lower the spending power index, the more effective the function... The larger the value, the higher the cost weight. And it's also higher. This indicates the current per capita income of the region, which can be obtained through publicly available data from the statistics bureau or through the platform's internal regional economic stratification.

[0055] Furthermore, the function This can be simplified as follows:

[0056] For passenger rating weighting The driver rating can be adjusted based on passenger order history preferences. The calculation formula can be designed as follows:

[0057] in, The base score weight (e.g., 0.1). This indicates the strength of a passenger's service preference and can be quantified as the average rating of the passenger's historical completed orders (user-initiated rating). This represents the average driver rating, which can be the average rating of completed orders with valid ratings within the region.

[0058] Furthermore, the function This can be simplified as follows:

[0059] Step S104: Solving for the game equilibrium. After all weight parameters have been calculated, the strategy execution layer 130 substitutes these parameters into the utility function models of both the driver and passenger to form a complete, parameterized non-cooperative game model. That is, based on the utility function model with the weight parameters substituted, a game model between the driver and passenger is constructed, and the equilibrium solution of this game model is solved to determine the optimal driver-passenger matching strategy. In this model, the driver's strategy space is {accept order, reject order}, and the passenger's strategy space is {accept matching, cancel order}.

[0060] In this embodiment, the game model is a non-cooperative game model, and the equilibrium solution is the Nash equilibrium solution of the non-cooperative game model. Specifically, the goal of the equilibrium solver 131 is to find the Nash equilibrium solution of the game. It is understood that a Nash equilibrium is a stable combination of strategies, under which neither party can obtain higher utility by unilaterally changing its own strategy. In this embodiment, since the strategies are discrete, an iterative algorithm can be used to solve the problem.

[0061] Finding the equilibrium solution of this game model involves using an iterative algorithm, starting from an initial strategy combination, and iteratively calculating the optimal response functions of the driver and passenger until their strategies converge to the Nash equilibrium solution. The specific process is as follows: 1. Initialization: Randomly select an initial strategy combination for the driver and passenger. For example, assume that the driver accepts the order with a probability of 0.5 and the passenger accepts it with a probability of 0.5.

[0062] 2. Iterative calculation: in the first... In each iteration, the passenger's policy is fixed, and the driver's optimal response function is calculated. This involves determining whether the driver, under the current passenger policy, should choose "accept the order" or "reject the order" to obtain higher expected utility, and the driver's policy probability is updated accordingly. Then, the updated driver policy is fixed, the passenger's optimal response function is calculated, and the passenger's policy probability is updated.

[0063] 3. Convergence check: Repeat step 2 until the policy probabilities of the driver and passenger converge to a stable value (e.g., the change is less than a very small threshold in multiple iterations). The convergence point is a Nash equilibrium solution for the game, which is usually represented by a set of probabilities, such as (driver's willingness to accept the order = 0.9, passenger's willingness to accept the order = 0.95).

[0064] Step S105: Dispatch Decision. After obtaining the Nash equilibrium solution (i.e., the probabilities of willingness between the driver and passenger), the system needs to make a decision based on preset dispatch conditions. This judgment process corresponds to... Figure 2 The diamond-shaped decision box S105 is used. In this embodiment, the preset dispatch conditions can be set as follows: the calculated probability of the driver's willingness to accept the order and the probability of the passenger's willingness to accept the order are both higher than their respective preset thresholds. For example, the platform can set the driver's willingness to accept the order threshold to 0.8 and the passenger's willingness to accept the order threshold to 0.8. In the above solution results, 0.9>0.8 and 0.95>0.8, both conditions are met.

[0065] Step S106: Execute dispatch. If the judgment result of step S105 is yes, then the strategy execution layer 130 determines that the matching strategy is the optimal strategy and generates a dispatch instruction. That is, according to the optimal driver-passenger matching strategy, the dispatch operation is executed under the preset dispatch conditions. Figure 3 As shown, the platform server 30 pushes order information to the candidate driver's client 40. After the driver accepts the order, the platform server 30 then returns a successful match notification to the passenger client 20, thus completing the order dispatch loop.

[0066] If the judgment result of step S105 is negative, for example, if the calculated probability of the driver's willingness to accept the order is only 0.6, which is lower than the threshold of 0.8, it indicates that the match is not a stable and mutually satisfactory choice. In this case, the system will abandon the match and can start a new matching process for the passenger. Figure 2 In step S107 (rematching), try to match other candidate drivers for the passenger and repeat steps S101 to S105 above.

[0067] With the method and system described in this embodiment, each dispatch decision is no longer based on rigid rules, but rather on a balance point of interests between drivers and passengers found through dynamic game theory. This effectively adapts to complex market environments and improves matching success rates and user satisfaction.

[0068] Example 2 This embodiment is a variant of Embodiment 1, the main difference being the specific technical means employed in the parameter calculation layer 120 to determine user personalized preferences. This embodiment aims to illustrate that the machine learning model used to predict user preferences is replaceable, thereby providing more flexible implementation options for the technical solution.

[0069] The overall system architecture is similar to that in Implementation Example 1. Figure 1 The architecture shown remains consistent, and the methodology is also followed. Figure 2 The steps are shown. The core change occurs in the specific implementation of step S103, "Dynamically calculate weight parameters".

[0070] In Example 1, a machine learning model can be used to determine the driver's cost sensitivity, and for example, the model can output a discrete level, such as "high / medium / low". As an optional implementation, this example employs a more refined implementation.

[0071] Specifically, a gradient boosting regression tree model is deployed in the driver parameter calculator 121 of the parameter calculation layer 120. This model is trained offline, and its training data includes a large amount of historical behavior data and profile data of drivers (such as vehicle energy consumption, historical empty driving rate, changes in order-taking behavior during periods of high oil prices, whether they are part-time, etc.) as features, and is fitted with the actual order-taking choices of drivers under different cost pressures as labels.

[0072] During online computation, for a candidate driver, the system inputs their latest feature data into the pre-trained gradient boosting regression tree model. Unlike the classification model in Example 1, which outputs discrete levels, this regression model outputs a continuous value between 0 and 1, which directly represents the driver's cost sensitivity score. For example, a driver with a score of 0.85 indicates that their behavior pattern shows high cost sensitivity, while a driver with a score of 0.4 is less cost-sensitive.

[0073] This continuous cost sensitivity score will be directly used for cost weighting. In the calculation formula. For example, the formula in Example 1 can be specified as:

[0074] in, This refers to the continuous values ​​output by the gradient boosting regression tree model.

[0075] Similarly, in the passenger parameter calculator 122, a regression model can be used instead of a classification model. For example, the urgency of a passenger's order can be predicted by a regression model that takes into account the context of the order (such as whether the departure point is a transportation hub, whether the order time is during weekday morning rush hour, whether the user noted "catching a flight," etc.) and outputs a continuous urgency score. This score can also more smoothly influence the time weights. The calculation.

[0076] Compared to Example 1, the advantages of this example are: using a regression model instead of a classification model allows for a more accurate and finer-grained quantification of users' personalized preferences. It avoids information loss and the "ladder effect" (where users with scores borderline on a rank are treated equally) caused by discrete grading (e.g., "high / medium / low"). This smoother and more precise parameter input allows the final utility calculation and game-theoretic solution to better reflect the subtle differences in the real world, potentially leading to further improvements in matching quality. The solution in this example also supports the limitations regarding the dynamically calculated weight parameters in the claims.

[0077] Example 3 This embodiment is another variant of Embodiment 1, the main difference being the specific form of the game model constructed and solved in the strategy execution layer 130. This embodiment aims to illustrate that the specific form of the game model is variable; in addition to non-cooperative game models, other game theory models, such as master-slave game models, can be used to adapt to different platform operation strategies and market regulation needs.

[0078] The general framework of the system architecture and methodology is similar to that of Example 1, but the core change occurs in the logic of step S104, "solving the game equilibrium." In Example 1, the driver and passenger are considered equal participants who make decisions simultaneously. In this example, however, the role of the platform is introduced, and a two-stage master-slave game model is constructed.

[0079] In this model, ride-hailing platforms play the role of "leaders," while drivers and passengers act as "followers." The leader acts first, setting the rules of the game; followers observe the leader's actions and then make the most advantageous responses for themselves.

[0080] That is, the process of finding the equilibrium solution includes: the platform first determines the game rules for maximizing the platform's overall revenue or transaction rate, and then the drivers and passengers make decisions under the game rules to maximize their own interests.

[0081] The specific work process is as follows: 1. Data Acquisition and Utility Function Establishment (Same as Example 1): Steps S101 and S102 are exactly the same as in Example 1. The system still needs to acquire comprehensive contextual data and establish a utility function model containing dynamic weights for both the driver and passenger.

[0082] 2. Game Model Construction and Solution (Variant Step S104): This step is executed by the equilibrium solver 131 in the strategy execution layer 130, but its internal logic changes to solving the subgame perfect Nash equilibrium of the master-slave game. First Stage (Platform Decision): As the leader, the platform's goal is to maximize a certain macroeconomic indicator, such as the platform's overall revenue (total commission), total transaction volume, or the supply-demand balance index of a specific region. The platform can control one or more key game rule parameters. In this embodiment, it is assumed that the platform can set the dynamic pricing coefficient for the current region. The platform needs to determine an optimal solution. Phase Two (Driver-Passenger Response): As followers, drivers and passengers use the pricing coefficients given by the platform. Next, they make their own decisions. Their goal remains to maximize their own utility function. At this point, the cost item in the passenger's utility function... Income term in the driver utility function All of these will be set by the platform. Their functions. They will decide whether to accept an order or a match based on their own utility function.

[0083] 3. Equilibrium Solution Process: The equilibrium solver 131 uses backward induction to solve the problem. First, for any platform, the possible pricing coefficients are... The solver needs to predict how the driver and passenger will react under this rule. This is essentially given... Below, we solve for the equilibrium of a subgame between a driver and a passenger, and the result corresponds to this. The platform calculates the expected order acceptance rate and rate. Then, it substitutes this expected result into its objective function. Finally, the platform uses optimization algorithms (such as gradient descent or simple grid search) to find the value that maximizes the objective function. .this This refers to the pricing strategy that the platform will ultimately implement.

[0084] 4. Order Dispatch Execution (same as Example 1): After determining the optimal pricing coefficient... Then, the system dispatches orders to the best-matched driver calculated based on this price. The subsequent order dispatch decision and execution process (steps S105 and S106) is the same as in Example 1.

[0085] Compared to the non-cooperative game model in Example 1, the master-slave game model in this example endows the platform with stronger initiative and market regulation capabilities. For example, in areas with severe capacity shortages, the platform can proactively set a higher premium coefficient by solving the model. This price is not only acceptable to passengers who need transportation most, but also effectively incentivizes more drivers to provide services in the area, thereby providing stronger macro-level intervention and guidance to the market and achieving supply and demand balance. The solution in this embodiment effectively supports the requirement in the claims that the game model is an active game model.

[0086] Example 4 This embodiment is another variation of Embodiment 1, the main difference being the quantitative dimensions included in the utility function model established for both drivers and passengers. This embodiment aims to illustrate that the utility function model is scalable; in addition to basic dimensions such as revenue, cost, time, and expenses, more dimensions can be added based on actual business needs to capture the more complex and comprehensive interests of both drivers and passengers.

[0087] The general framework of the system architecture and methodology is the same as that of Example 1. The core changes occur in step S102, “Establishing the utility function model”, and the associated step S103, “Dynamically calculating the weight parameters”.

[0088] In this embodiment, the utility function defined in Embodiment 1 is extended.

[0089] 1. Expansion of the Passenger Utility Function: In addition to the existing dimensions of time, cost, and driver rating, a new dimension of "comfort" is added to the passenger utility function. This dimension quantifies the passenger's riding experience during the trip, and its value can be quantified based on the candidate driver's vehicle information. For example, a basic quantification rule can be set: economy cars get 1 point, comfort cars get 3 points, and business MPVs or luxury cars get 5 points. Therefore, the expanded passenger utility function model becomes:

[0090] in, This is the comfort score mentioned above. Accordingly, a new comfort weight has been added to the model. This weight is also dynamically calculated by the passenger parameter calculator 122, and its calculation can be based on the passenger's user profile. For example, a business user who frequently books comfort or higher-level vehicles will have a higher comfort weight. The result will be calculated at a higher value; while for a price-sensitive user, their... The value will be lower.

[0091] 2. Extension of the Driver Utility Function: In addition to the existing income, cost, and time dimensions, a new "long-term benefit" dimension is added to the driver utility function. This dimension quantifies the positive impact of completing the current order on the driver's future income, and its value is primarily related to the order's destination. If an order's destination is a high-demand hotspot area predicted by the system within the next 1-2 hours based on historical data and real-time event information (such as the end time of concerts or sporting events), then the long-term benefit value of this order is higher because the driver does not need to drive a long distance empty after completing the order to immediately receive new, high-quality orders. Therefore, the extended driver utility function model becomes:

[0092] in, It is a score based on the potential order value predicted by the destination. A new forward revenue weight has also been added to the model. This weight is dynamically calculated by the driver parameter calculator 121, and its calculation can be based on the driver's type or experience level. For example, an experienced full-time driver is usually better at planning routes and utilizing heatmaps, and the system can assign him a higher weight for long-term benefits. A part-time new driver who accepts orders randomly might be more focused on the direct income from the current order. The value will be lower.

[0093] After expanding the utility function, the subsequent weight calculation (step S103), game solving (step S104), and order dispatch decision (step S105) processes remain consistent with those in Example 1, except that two more dimensions and two more weight parameters need to be processed in the calculation.

[0094] Through the solution in this embodiment, the dispatching system can capture and quantify the deeper, more personalized needs of both drivers and passengers. For example, the system can accommodate passengers willing to pay a higher price for a more comfortable vehicle (whose...) and The weighting (which determines the user's willingness to pay) accurately matches drivers with suitable vehicles, improving the experience for high-end users. Simultaneously, the system can guide drivers towards areas expected to generate a large number of orders through the "long-term benefit" dimension, achieving predictive and global optimization of transportation resources, rather than simply processing individual orders. The solution in this embodiment effectively supports the relevant limitations regarding the extended dimensions of the utility function model in the claims.

[0095] In summary, the ride-hailing dispatching method and system based on a dynamic game theory model provided in this application significantly improves upon traditional dispatching strategies by dynamically acquiring multi-dimensional data, establishing scalable utility functions for both drivers and passengers, dynamically calculating the weight parameters within these functions, and then constructing and solving a game theory model to find the equilibrium point of interest. This solution can match drivers and passengers more intelligently, fairly, and efficiently in complex and ever-changing market environments, improving the overall operational efficiency of the platform and the user experience.

[0096] Example 5 This embodiment provides a specific implementation method for a ride-hailing dispatch system based on a dynamic game model, which includes: The data acquisition module is used to acquire contextual data related to ride-hailing orders, including driver data and passenger data. The utility function model building module is used to build utility function models for drivers and passengers respectively to quantify their decision preferences based on the driver data and passenger data. The weight parameter calculation module is used to dynamically calculate the weight parameters in the utility function model based on the context data, so as to reflect the personalized preferences of the driver and passengers in the current situation. The game-solving module is used to construct a game model between the driver and the passenger based on the utility function model with the weight parameters substituted, and to solve the equilibrium solution of the game model in order to determine the optimal driver-passenger matching strategy. The dispatch execution module is used to perform dispatch operations based on the optimal driver-passenger matching strategy and under preset dispatch conditions.

[0097] The ride-hailing dispatch system based on the dynamic game model in this embodiment is used to implement the dispatch methods of the aforementioned embodiments. The specific implementation process can be referred to the description of the aforementioned embodiments, and will not be repeated here.

[0098] In summary, compared with the prior art, this application has the following beneficial effects: 1. Achieving dynamic balance of interests: By constructing a dynamic model based on game theory and making the interests of both drivers and passengers explicit and quantifiable, and solving for an equilibrium solution acceptable to both parties, a dynamic balance of interests between drivers and passengers in ride-hailing dispatch is achieved, avoiding conflicts of interest caused by unidirectional optimization and significantly improving the matching success rate and bilateral satisfaction.

[0099] 2. Enhanced market adaptability: By dynamically calculating the utility function weights to respond to real-time changes in market supply and demand, traffic conditions, and individual preferences, the system's adaptability to market fluctuations is enhanced, which can effectively guide transport capacity and alleviate the problem of uneven distribution of transport capacity during peak periods or special scenarios.

[0100] 3. Enhance the transparency and fairness of the rules: The parameters of the game model in this application have clear business meanings, and their calculation logic can be partially disclosed to users, thereby improving the transparency and interpretability of the platform's order dispatch rules. This helps to resolve the trust crisis caused by opaque algorithms and enhance the trust of both drivers and passengers in the platform.

[0101] It is understood that the same or similar parts in the above embodiments can be referred to each other, and the contents not described in detail in some embodiments can be referred to the same or similar contents in other embodiments.

[0102] It should be noted that in the description of this invention, the terms "first," "second," etc., are used for descriptive purposes only and should not be construed as indicating or implying relative importance. Furthermore, in the description of this invention, unless otherwise stated, "a plurality of" means at least two.

[0103] It should be understood that various parts of the present invention can be implemented in hardware, software, firmware, or a combination thereof. In the above embodiments, multiple steps or methods can be implemented in software or firmware stored in memory and executed by a suitable instruction execution system. For example, if implemented in hardware, as in another embodiment, it can be implemented using any one or a combination of the following techniques known in the art: discrete logic circuits having logic gates for implementing logical functions on data signals, application-specific integrated circuits (ASICs) having suitable combinational logic gates, programmable gate arrays (PGAs), field-programmable gate arrays (FPGAs), etc.

[0104] Those skilled in the art will understand that all or part of the steps of the methods implementing the above embodiments can be implemented by a program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, the program includes one or a combination of the steps of the method embodiments.

[0105] Furthermore, the functional units in the various embodiments of this invention can be integrated into a single processing module, or each unit can exist physically separately, or two or more units can be integrated into a single module. The integrated module can be implemented in hardware or as a software functional module. If the integrated module is implemented as a software functional module and sold or used as an independent product, it can also be stored in a computer-readable storage medium. The aforementioned storage medium can be a read-only memory, a disk, or an optical disk, etc.

[0106] In the description of this specification, references to terms such as "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of the invention. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples.

[0107] Although embodiments of the present invention have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting the present invention. Those skilled in the art can make changes, modifications, substitutions and variations to the above embodiments within the scope of the present invention.

Claims

1. A ride-hailing dispatching method based on a dynamic game theory model, characterized in that, Includes the following steps: Obtain contextual data related to ride-hailing orders, including driver data and passenger data; Based on the driver and passenger data, utility function models for quantifying the decision preferences of drivers and passengers are established respectively. Based on the context data, the weight parameters in the utility function model are dynamically calculated to reflect the personalized preferences of the driver and passengers in the current situation. Based on the utility function model with the weight parameters substituted, a game model between the driver and the passenger is constructed, and the equilibrium solution of the game model is solved to determine the optimal driver-passenger matching strategy. Based on the optimal driver-passenger matching strategy, and under the preset dispatch conditions, the dispatch operation is executed.

2. The method according to claim 1, characterized in that, The dynamic calculation of the weight parameters based on the context data includes: Based on real-time market environment data and user profile data contained in the driver and passenger data, the weight parameters in the utility function model are dynamically adjusted.

3. The method according to claim 2, characterized in that, The weight parameters of the dynamically calculated driver's utility function model include at least one of the following: By combining the real-time fuel price index and the driver cost sensitivity determined based on the driver data, the cost weight in the driver utility function model is dynamically calculated. By combining the revenue per unit time and revenue per unit mileage of the order, the revenue weight in the driver utility function model is dynamically calculated; By combining the driver's time value and the regional average hourly wage, the time weight in the driver utility function model is dynamically calculated.

4. The method according to claim 2, characterized in that, The weight parameters of the dynamically calculated passenger utility function model include at least one of the following: By combining the urgency of the order with the real-time traffic congestion index, the time sensitivity weight in the passenger utility function model is dynamically calculated; By combining the passenger spending power index determined based on the passenger data, the cost weight in the passenger utility function model is dynamically calculated. By combining the passenger service preference intensity determined based on the passenger data and the average driver rating, the driver rating weight in the passenger utility function model is dynamically calculated.

5. The method according to claim 1, characterized in that, The utility function model established for drivers also includes a forward benefit dimension in its quantification dimension, which is related to whether the destination of the order is a region with high future demand. And / or, The utility function model established for passengers also includes a comfort dimension in its quantification dimension, which is related to the vehicle type of the candidate driver.

6. The method according to claim 1, characterized in that, The game model is a non-cooperative game model, and the equilibrium solution is the Nash equilibrium solution of the non-cooperative game model.

7. The method according to claim 6, characterized in that, The process of finding the equilibrium solution for this game model includes: An iterative algorithm is used to calculate the optimal response functions of the driver and passenger, starting from an initial strategy combination, until the strategies of both parties converge to the Nash equilibrium solution.

8. The method according to claim 1, characterized in that, The game model described is a master-follower game model, in which the platform acts as the leader and the drivers and passengers act as followers. The process of finding the equilibrium solution involves the platform first determining a game rule to maximize the platform's overall revenue or transaction rate, and then the drivers and passengers making decisions under the game rule to maximize their own interests.

9. The method according to claim 1, characterized in that, The preset dispatch conditions include: The probabilities of drivers' willingness to accept orders and passengers' willingness to accept orders, calculated based on the equilibrium solution, are both higher than their respective preset thresholds.

10. A ride-hailing dispatch system based on a dynamic game theory model, characterized in that, include: The data acquisition module is used to acquire contextual data related to ride-hailing orders, including driver data and passenger data. The utility function model building module is used to build utility function models for drivers and passengers respectively to quantify their decision preferences based on the driver data and passenger data. The weight parameter calculation module is used to dynamically calculate the weight parameters in the utility function model based on the context data, so as to reflect the personalized preferences of the driver and passengers in the current situation. The game-solving module is used to construct a game model between the driver and the passenger based on the utility function model with the weight parameters substituted, and to solve the equilibrium solution of the game model in order to determine the optimal driver-passenger matching strategy. The dispatch execution module is used to perform dispatch operations based on the optimal driver-passenger matching strategy and under preset dispatch conditions.

Images