Intelligent matching-based online carpooling dispatching management method and system

Abstract

The application discloses a kind of based on intelligent matching's net booking carpooling scheduling management method and system, it is related to dispatching management technical field, it first utilizes historical log data deep mining driver behavior characteristics and system operation law, respectively constructs and trains the dual model of accurately depicting driver preference and evaluating system income. Subsequently, with this dual model as the basis, global matching evaluation is carried out on real-time supply and demand, and the maximum boundary correlation strategy is used to optimize distribution, to generate a recommended list that takes into account driver willingness and diversity. Further, the recommended list is pushed to the driver end to receive autonomous selection feedback, and based on the feedback, conflicts are resolved, and the final matching solution is dynamically derived. In this way, the problem of low dispatch success rate and driver turnover caused by ignoring the heterogeneous preferences of drivers in traditional scheduling can be effectively solved, thereby achieving a coordinated improvement in the satisfaction of both supply and demand and the overall scheduling efficiency of the system in the context of net booking carpooling.

Description

Technical Field

[0001] This application relates to the field of dispatch management technology, and more specifically, to a method and system for dispatch management of ride-hailing based on intelligent matching. Background Technology

[0002] With the booming development of the sharing economy and the increasing prominence of urban traffic congestion, ride-hailing, as an efficient and economical mode of transportation, is playing an increasingly important role in alleviating traffic pressure, reducing carbon emissions, and improving vehicle utilization. By aggregating passengers with similar routes and matching times into the same vehicle, ride-hailing services can not only significantly reduce passengers' travel costs but also significantly improve drivers' operating income, becoming an indispensable part of the modern urban transportation system. However, the core of ride-hailing systems lies in dispatch management, namely, how to establish an efficient and accurate matching relationship between massive real-time orders and widely distributed transportation resources. An excellent dispatch management system needs to simultaneously consider both passengers' travel experience (such as waiting time and detour distance) and drivers' operational efficiency, making the ride-hailing dispatch problem essentially an extremely complex dynamic optimization problem, urgently requiring the construction of more intelligent matching and dispatch management solutions to meet the ever-growing market demand.

[0003] In existing ride-hailing dispatch practices, although various matching algorithms based on operations research or machine learning have emerged, they typically analyze the compatibility between passenger requests by constructing spatiotemporal network graphs and then perform global optimization based on this, aiming to maximize the overall service completion rate or total revenue of the system. While these solutions have achieved some success in handling large-scale order matching, they still reveal significant limitations in practical applications. Specifically, existing mainstream dispatch strategies mainly focus on the route compatibility between passengers and maximizing the overall utility at the system level, but largely ignore the heterogeneous characteristics of individual drivers as service providers. This technical approach fails to fully consider the subjective intentions and behavioral preferences of drivers during the order-accepting process, such as different drivers' preferences for long and short-distance orders, their familiarity with specific service areas, and their different expectations for income stability. This neglect of personalized factors on the supply side can easily lead to orders forcibly assigned by the system that do not match the drivers' psychological expectations, resulting in problems such as increased order rejection rates, decreased service quality, and driver turnover, ultimately weakening the overall capacity stability and dispatch success rate of the ride-hailing platform.

[0004] Therefore, there is an urgent need for an optimized ride-hailing dispatch management method and system based on intelligent matching. Summary of the Invention

[0005] This application is made in order to solve the above-mentioned technical problems.

[0006] According to one aspect of this application, a ride-hailing dispatch management method based on intelligent matching is provided, comprising: The driver preference model and system utility model are trained based on historical log data to obtain the trained driver preference model and system utility model. Based on the trained driver preference model and the trained system utility model, a global candidate matching pool is generated and scored for the real-time driver pool and the real-time order queue to obtain a scored candidate pool. The maximize boundary relevance module is used to assign candidate matches from the scored candidate pool to each target driver in the target driver set to be recommended, so as to obtain the recommendation list set at the current time. Push the current recommendation list to the driver's device, and receive the current driver selection list from the driver's device; Conflict resolution is performed on the driver selection set at the current moment to obtain the final matching scheme and scheduling instructions.

[0007] According to another aspect of this application, a ride-hailing dispatch and management system based on intelligent matching is provided, comprising: The model training module is used to train the driver preference model and the system utility model based on historical log data to obtain the trained driver preference model and the trained system utility model. The candidate matching scoring module is used to generate and score a global candidate matching pool for the real-time driver pool and the real-time order queue based on the trained driver preference model and the trained system utility model, so as to obtain a scored candidate pool. The recommendation allocation module is used to allocate candidate matches from the scored candidate pool to each target driver in the target driver set to be recommended using the maximized boundary correlation module to obtain the recommendation list set at the current time. The push response module is used to push the current recommendation list to the driver's end and receive the current driver selection set from the driver's end; The conflict resolution module is used to resolve conflicts in the driver selection set at the current moment to obtain the final matching scheme and scheduling instructions.

[0008] Compared with existing technologies, this application provides a ride-hailing dispatch management method and system based on intelligent matching. First, it utilizes historical log data to deeply mine driver behavior characteristics and system operational patterns, constructing and training dual models to accurately characterize driver preferences and evaluate system benefits. Then, based on these dual models, it performs a global matching evaluation of real-time supply and demand, and optimizes allocation using a strategy that maximizes boundary correlation, generating a recommendation list that considers both driver preferences and diversity. Next, the recommendation list is pushed to drivers to receive feedback on their choices, and conflict resolution is performed based on this feedback, dynamically deriving the final matching solution. This effectively solves the problems of low dispatch success rates and driver churn caused by traditional dispatching methods that ignore heterogeneous driver preferences, thereby achieving a synergistic improvement in the satisfaction of both supply and demand sides and the overall dispatch efficiency of the system in ride-hailing scenarios. Attached Figure Description

[0009] The above and other objects, features, and advantages of this application will become more apparent from the more detailed description of the embodiments of this application in conjunction with the accompanying drawings. The drawings are provided to further illustrate the embodiments of this application and form part of the specification. They are used together with the embodiments of this application to explain this application and do not constitute a limitation thereof. In the drawings, the same reference numerals generally represent the same components or steps.

[0010] Figure 1 This is a flowchart of a ride-hailing dispatch management method based on intelligent matching according to an embodiment of this application.

[0011] Figure 2 This is a data flow diagram of a ride-hailing dispatch management method based on intelligent matching according to an embodiment of this application.

[0012] Figure 3 This is a flowchart of sub-step S2 of the ride-hailing dispatch management method based on intelligent matching according to an embodiment of this application.

[0013] Figure 4 This is a flowchart of sub-step S21 of the ride-hailing dispatch management method based on intelligent matching according to an embodiment of this application.

[0014] Figure 5 This is a flowchart of sub-step S22 of the ride-hailing dispatch management method based on intelligent matching according to an embodiment of this application.

[0015] Figure 6 This is a flowchart of sub-step S3 of the ride-hailing dispatch management method based on intelligent matching according to an embodiment of this application.

[0016] Figure 7 This is a flowchart of sub-step S5 of the ride-hailing dispatch management method based on intelligent matching according to an embodiment of this application.

[0017] Figure 8 This is a block diagram of a ride-hailing dispatch and management system based on intelligent matching according to an embodiment of this application. Detailed Implementation

[0018] Embodiments of this disclosure will now be described in more detail with reference to the accompanying drawings. While some embodiments of this disclosure are shown in the drawings, it should be understood that this disclosure can be implemented in various forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided to provide a more thorough and complete understanding of this disclosure. It should be understood that the accompanying drawings and embodiments of this disclosure are for illustrative purposes only and are not intended to limit the scope of protection of this disclosure.

[0019] To address the problems mentioned above in the background technology, this application proposes a ride-hailing dispatch management method based on intelligent matching. Figure 1 This is a flowchart of a ride-hailing dispatch management method based on intelligent matching according to an embodiment of this application. Figure 2 This is a data flow diagram of a ride-hailing dispatch management method based on intelligent matching according to an embodiment of this application. For example... Figure 1 and Figure 2 As shown, the ride-hailing dispatch management method based on intelligent matching includes the following steps: S1, training a driver preference model and a system utility model based on historical log data to obtain a trained driver preference model and a trained system utility model; S2, generating and scoring a global candidate matching pool for the real-time driver pool and the real-time order queue based on the trained driver preference model and the trained system utility model to obtain a scored candidate pool; S3, assigning candidate matches from the scored candidate pool to each target driver in the target driver set to be recommended using the maximize boundary relevance module to obtain a recommendation list set at the current time; S4, pushing the recommendation list set at the current time to the driver end and receiving the driver selection set at the current time from the driver end; S5, resolving conflicts in the driver selection set at the current time to obtain the final matching scheme and dispatch instructions.

[0020] In the aforementioned intelligent matching-based ride-hailing dispatch management method, step S1 involves training a driver preference model and a system utility model based on historical log data to obtain the trained driver preference model and system utility model. It should be understood that existing ride-hailing dispatch methods tend to overlook heterogeneous driver preferences, focusing only on overall system efficiency, leading to problems such as low dispatch success rates and driver churn. Historical log data contains key information such as driver behavior, order characteristics, and system operation, serving as the core basis for mining preferences and system patterns. Therefore, this application conducts dual-model training based on historical log data, deeply analyzing behavioral patterns and operational indicators in the data to construct a model that accurately portrays driver subjective preferences and quantifies the overall system benefits. This provides a reliable evaluation basis for subsequent real-time matching, fundamentally solving the supply-demand imbalance problem and laying the foundation for improving dispatch accuracy and mutual satisfaction.

[0021] Specifically, in one possible embodiment, step S1 is implemented as follows: First, the historical log data is preprocessed, including data cleaning to remove outliers and feature extraction to transform it into structured data that the model can recognize, covering dimensions such as driver order acceptance and rejection records, order spatiotemporal features, and system supply and demand status. Then, a suitable model architecture is selected: For the driver preference model, a deep interest network is used, constructing an embedding layer to transform driver ID, historical order acceptance sequences, and current candidate orders into low-dimensional dense vectors, and using local activation units to calculate the attention weights between the current candidate order and historical order acceptance behavior. A weighted pooling layer captures the driver's dynamic interest preferences for the current specific order. For the system utility model, a multilayer perceptron is used, concatenating features such as order amount, platform supply-demand ratio, and capacity distribution as input. Through a nonlinear combination of fully connected layers and the ReLU activation function, the mapping relationship between system revenue and matching success rate is fitted. Finally, by dividing the training set and validation set, the model parameters are iteratively adjusted with the goal of minimizing the loss function. After training, the model accuracy is evaluated using the validation set to ensure that the model has stable predictive capabilities.

[0022] In the aforementioned intelligent matching-based ride-hailing dispatch management method, step S2 involves generating and scoring a global candidate matching pool for the real-time driver pool and real-time order queue based on a trained driver preference model and a trained system utility model to obtain a scored candidate pool. In a specific example of this application, the data for each driver object in the real-time driver pool includes driver ID, GPS coordinates, vehicle status, and remaining capacity; the data for each order object in the real-time order queue includes order ID, origin coordinates, destination coordinates, number of passengers, and submission time. It should be understood that since real-time ride-hailing dispatch requires accurate matching in dynamic supply and demand, relying solely on a single dimension can easily lead to matching imbalances. Furthermore, the core attributes (location, capacity, and trip information) of the real-time driver pool and order queue are the basis for assessing the feasibility and value of matching. Therefore, this application further utilizes the trained dual models to generate and score a global candidate matching pool for real-time supply and demand data containing explicit attributes, thereby filtering feasible matches and quantifying their dual value to both driver subjective intentions and system operation. This provides accurate data support for subsequent personalized recommendations, avoids the increase in rejection rates caused by indiscriminate matching, and ensures that the matching scheme takes into account both driver satisfaction and overall system efficiency.

[0023] In particular, in one specific embodiment, Figure 3 This is a flowchart of sub-step S2 of the ride-hailing dispatch management method based on intelligent matching according to an embodiment of this application. Figure 3 As shown, step S2 includes: S21, generating candidate matching pairs under spatiotemporal constraints for the real-time driver pool and the real-time order queue to obtain an unrated original candidate set; S22, based on the trained driver preference model and the trained system utility model, performing parallel scoring and pooling based on the dual models on each candidate match in the unrated original candidate set to obtain a scored candidate pool.

[0024] Specifically, step S21 involves generating candidate matching pairs for the real-time driver pool and real-time order queue under spatiotemporal constraints to obtain an unscored original candidate set. It should be understood that due to the large number of drivers and orders in real-time scenarios, full-scale matching would generate a significant amount of invalid computation, and matching that does not conform to the basic spatiotemporal and capacity constraints has no practical significance. Therefore, this application further imposes spatiotemporal constraints on the real-time driver pool and order queue to generate an unscored original candidate set, thereby filtering out matching pairs that meet basic feasibility and eliminating invalid combinations such as those with excessive spatial distance or capacity mismatch. This significantly reduces the computational load of subsequent scoring stages, improves the real-time response speed of the scheduling system, and ensures that all subsequent candidate matching has practical feasibility, avoiding waste of computing power and time resources.

[0025] In particular, in one specific embodiment, Figure 4This is a flowchart of sub-step S21 of the ride-hailing dispatch management method based on intelligent matching according to an embodiment of this application. Figure 4 As shown, step S21 includes: S211, performing preliminary pruning based on spatial index on the real-time driver pool and real-time order queue based on search radius and maximum estimated pick-up time to obtain an independent candidate set; S212, performing route-based search for nearby ride-sharing orders on the independent candidate set and real-time order queue to obtain potential ride-sharing pairs; S213, performing multi-constraint precise verification of ride-sharing feasibility on potential ride-sharing pairs based on the real-time driver pool, real-time order queue, maximum detour rate, and maximum passenger waiting time to obtain an unrated original candidate set.

[0026] More specifically, in step S211, based on the search radius and the maximum estimated pick-up time, preliminary pruning of the real-time driver pool and real-time order queue using spatial indexing is performed to obtain an independent candidate set. It should be understood that directly traversing all drivers and orders for spatial matching in real-time scenarios is extremely inefficient, and relying solely on spatial distance for filtering may result in excessively long pick-up times, leading to a poor passenger experience. Therefore, this application further combines the search radius and the maximum estimated pick-up time, using spatial indexing to perform preliminary pruning of real-time supply and demand data, thereby quickly filtering out independent orders that are spatially adjacent and meet the pick-up time requirement. This improves search efficiency through spatial indexing, while ensuring a good passenger waiting experience through pick-up time constraints, avoiding the generation of invalid independent candidates, and laying an efficient foundation for subsequent carpooling combination generation.

[0027] Specifically, in one possible embodiment, step S211 is implemented as follows: First, a spatial index, such as a Geohash index, is constructed for the real-time order queue, mapping orders to corresponding spatial grids based on their origin coordinates. Then, the idle drivers in the real-time driver pool are traversed, and orders within the search radius are queried based on the spatial index, centered on the driver's GPS coordinates. Next, the route planning service is called to calculate the estimated pick-up time from the driver to the origin of each candidate order, and orders whose pick-up time does not exceed the maximum estimated pick-up time are filtered out. Finally, the compatibility between the driver's remaining capacity and the number of passengers in the order is verified, and the qualified orders are retained to form an independent candidate set.

[0028] More specifically, step S212 involves searching for nearby ride-sharing orders based on routes in the independent candidate set and the real-time order queue to obtain potential ride-sharing pairs. It should be understood that since the independent candidate set only contains a single order, matching based solely on independent orders would reduce vehicle utilization, while ride-sharing requires filtering orders with adjacent routes to ensure efficiency. Therefore, this application further uses the order routes in the independent candidate set as a basis to search for nearby ride-sharing orders in the real-time order queue to generate potential ride-sharing pairs. This allows for the discovery of order combinations with matching routes, improving vehicle capacity utilization, and providing drivers with more profitable ride-sharing options, balancing system efficiency and driver income.

[0029] Specifically, in one possible embodiment, step S212 is implemented as follows: First, each order in the independent candidate set is traversed, and the route planning service is invoked to generate the complete route for the driver to pick up the order, i.e., a sequence of discrete coordinate points of the driver's current location, the order's starting point, and the order's ending point. Then, based on the coordinate point sequence of the route, a geometric buffer algorithm, such as the Minkowski Sum, is used to extend a preset distance threshold, such as 500 meters, to both sides of the route, thereby generating a polygonal area covering the perimeter of the route, i.e., a dynamic spatial corridor. Other orders whose starting or ending point coordinates fall within this polygonal area are then filtered in the real-time order queue. Next, orders that have been included in other independent candidates are excluded, and unmatched orders are retained. Finally, the independent candidate orders are combined with the filtered neighboring orders to generate potential carpooling pairs containing two orders, and all potential carpooling pairs are aggregated to form a set.

[0030] More specifically, step S213 involves performing a multi-constraint precise verification of the carpooling feasibility of potential carpooling pairs based on the real-time driver pool, real-time order queue, maximum detour rate, and maximum passenger waiting time to obtain an unrated original candidate set. It should be understood that since potential carpooling pairs are only screened based on route proximity, there may be issues such as insufficient capacity, excessive detours, or excessive passenger waiting times, which could affect service quality if used directly. Therefore, this application further combines real-time supply and demand data with multiple constraints to precisely verify potential carpooling pairs, thereby ensuring the feasibility of the carpooling scheme. This avoids service failures due to capacity mismatch, ensures passenger experience through detour rate and waiting time constraints, and ultimately forms an unrated original candidate set that is both feasible and reasonable, providing reliable input for subsequent scoring processes.

[0031] Specifically, in one possible embodiment, step S213 is implemented as follows: First, the remaining capacity of the corresponding driver is extracted from the real-time driver pool, and it is verified whether the sum of the number of passengers in the two orders of the potential carpooling pair does not exceed the remaining capacity. Then, the route planning service is called to calculate the time of the carpooling route and the route for picking up the two orders separately, ensuring that the detour rate does not exceed the maximum detour rate. Next, the estimated pick-up time of the passengers in the two orders is calculated, and it is verified whether it does not exceed the maximum waiting time of the passengers. Finally, the verified potential carpooling pairs are integrated with the original independent candidate set to form the unrated original candidate set.

[0032] Specifically, in step S22, based on the trained driver preference model and the trained system utility model, parallel scoring and pooling of each candidate match in the unscored original candidate set are performed using the dual models to obtain a scored candidate pool. It should be understood that since the unscored original candidate set only possesses basic feasibility and lacks a quantitative assessment of driver preference fit and system value, and real-time scheduling requires rapid scoring to meet millisecond-level response requirements, this application further employs a dual-model parallel scoring method to evaluate and pool the matches in the original candidate set. This simultaneously obtains the personalized preference score and system utility score for each candidate, forming a structured scoring result. This efficiently quantifies the dual value of candidate matches, providing a clear decision-making basis for subsequent diversified recommendations. Simultaneously, the parallel processing architecture ensures the time requirements of real-time scheduling, avoiding user experience impacted by scoring delays.

[0033] In particular, in one specific embodiment, Figure 5 This is a flowchart of sub-step S22 of the ride-hailing dispatch management method based on intelligent matching according to an embodiment of this application. Figure 5 As shown, step S22 includes: S221, characterizing each candidate match in the unrated original candidate set to obtain a candidate match feature vector set; S222, inputting each candidate match feature vector in the candidate match feature vector set into the trained driver preference model and the trained system utility model respectively to obtain a set of rating tuples; S223, performing structured pooling on the unrated original candidate set based on the set of rating tuples to obtain a rated candidate pool.

[0034] More specifically, step S221 involves characterizing each candidate match in the unrated original candidate set to obtain a set of candidate match feature vectors. It should be understood that since the matching information in the unrated original candidate set exists in an unstructured form, such as driver IDs and order IDs, it cannot be directly input into a machine learning model for inference, and the model needs to standardize features to ensure evaluation accuracy. Therefore, this application further characterizes each match in the original candidate set to extract and integrate key information from the driver, order, and context dimensions, transforming it into a vector form recognizable by the model. This provides suitable input data for dual-model inference, ensuring the accuracy of model evaluation, while standardized feature formats avoid inference errors caused by data format differences, laying the foundation for subsequent parallel scoring.

[0035] Specifically, in one possible embodiment, step S221 is implemented as follows: First, each match in the unrated original candidate set is traversed, and the corresponding driver's static profile features (driving experience, place of residence, etc.) and the driver's historical behavior sequence features adapted to the input of the deep interest network are extracted, such as the order type, price, and route sequence of the past N orders. Simultaneously, the aggregate features (total mileage, estimated revenue) and contextual features (time segments, weather) of the current order combination are extracted. Then, the categorical features are one-hot encoded, and the continuous features are normalized. Finally, the above features are constructed into the input format required by the model, i.e., a combination vector containing variable-length sequence features and fixed-dimensional features, and each input is associated with a corresponding candidate match identifier, summarizing to form a candidate match feature vector set.

[0036] More specifically, in step S222, each candidate matching feature vector in the candidate matching feature vector set is input into the trained driver preference model and the trained system utility model respectively to obtain a set of score tuples. It should be understood that since the candidate matching feature vectors are only structured data, they need to be transformed into quantitative value assessment results through model inference. Furthermore, a single model cannot simultaneously characterize both the driver's subjective preferences and the system's objective utility; separate evaluation can easily lead to data fragmentation. Therefore, this application further inputs each feature vector into the dual models for inference, thereby simultaneously obtaining the personalized preference score and system utility score for each candidate match, forming a tuple containing dual scores. This allows for accurate quantification of the dual value of candidate matches to both the driver and the system, avoiding matching imbalance caused by single-dimensional evaluation, while simultaneously improving efficiency through synchronous inference and providing complete score data for subsequent pooling.

[0037] Specifically, in one possible embodiment, step S222 is implemented as follows: First, a feature vector input pipeline is constructed, and vectors from the candidate matching feature vector set are input into the model service in batches. Then, the trained driver preference model is invoked to infer driver-related features in the vectors and output a preference score in the 0-1 range. Simultaneously, the system utility model is invoked to infer order and context features in the vectors and output a system utility score. Next, each input vector is associated with a corresponding candidate identifier, and the identifier and dual score are integrated into a tuple of "candidate ID - preference score - utility score". Finally, all tuples are summarized to form a set of score tuples.

[0038] More specifically, step S223 involves structured pooling of the unrated original candidate set based on the score tuple set to obtain a scored candidate pool. It should be understood that since the score tuple set only contains candidate identifiers and dual scores, and does not associate with core information of the original candidate matching, such as driver IDs and order combinations, it cannot be directly used for subsequent recommendation decisions, and the fragmented data format is not conducive to rapid querying and use by the scheduling system. Therefore, this application further performs structured pooling based on the score tuple set and the original candidate set to integrate the score data and original matching information, forming a complete and standardized candidate pool structure. This provides complete data containing matching information and dual scores for subsequent recommendation stages, facilitating rapid filtering and sorting. Simultaneously, structured storage improves data query efficiency and ensures the smoothness of real-time scheduling.

[0039] Specifically, in one possible embodiment, step S223 is implemented as follows: First, an index table of the unrated original candidate set is constructed, using the candidate matching identifier as the key, and storing information such as driver ID, order combination, and combination type. Then, each tuple in the set of rated tuples is traversed, and the corresponding original matching information is queried in the index table using the candidate identifier. Next, the dual ratings in the tuples are integrated with the original information to form a complete record of candidate ID, driver ID, order combination, preference score, and utility score. Finally, all complete records are validated to ensure field integrity and consistency, and grouped and stored by driver ID to form a rated candidate pool.

[0040] In the aforementioned intelligent matching-based ride-hailing dispatch management method, step S3 involves using a maximized boundary relevance module to assign candidate matches from the scored candidate pool to each target driver in the target driver set to obtain the current recommendation list set. It should be understood that while the scored candidate pool contains a large number of candidate matches, directly assigning them by score can easily lead to homogenization of the recommendation list, failing to meet drivers' heterogeneous preferences, and lacking consideration for recommendation diversity will reduce drivers' choice space. Therefore, this application further utilizes a maximized boundary relevance module to assign suitable candidate matches from the candidate pool to target drivers, thereby improving the diversity of the recommendation list while ensuring the relevance of candidate matches. This provides drivers with attractive and differentiated choices, avoiding an increase in order rejection rates due to homogenized recommendations, while also meeting drivers' personalized needs and improving driver satisfaction and order acceptance success rates.

[0041] In particular, in one specific embodiment, Figure 6 This is a flowchart of sub-step S3 of the ride-hailing dispatch management method based on intelligent matching according to an embodiment of this application. Figure 6 As shown, step S3 includes: S31, for each target driver in the target driver set to be recommended, grouping and sorting the scored candidate pool by driver to obtain a grouped and sorted candidate set; S32, dynamically adjusting the opportunity cost based on the competition degree based on the grouped and sorted candidate set to obtain a candidate set with adjusted relevance scores; S33, inputting the candidate set with adjusted relevance scores into the maximize boundary relevance module to obtain the recommendation list set at the current time.

[0042] Specifically, in step S31, for each target driver in the target driver set to be recommended, the rated candidate pool is grouped and sorted by driver to obtain a grouped and sorted candidate set. It should be understood that since the rated candidate pool is globally aggregated structured data, not divided by driver dimension, directly filtering target driver candidates from it is inefficient, and the lack of initial sorting increases the computational complexity of subsequent modules. Therefore, this application further groups and sorts the rated candidate pool by driver for the target driver set, thereby selecting exclusive candidate matches for each target driver and sorting them according to comprehensive value. This allows for rapid identification of suitable candidates for each target driver, reducing the data processing volume of subsequent modules, while the initial sorting provides a foundation for diversity optimization and improves overall recommendation efficiency.

[0043] Specifically, in one possible embodiment, step S31 is implemented as follows: First, the scored candidate pool is traversed, and the driver ID in each record is extracted. Then, using the driver ID in the target driver set as the key, the candidate matches corresponding to the driver in the candidate pool are categorized to form candidate groups divided by driver. Next, a comprehensive relevance score (combining preference score and utility score according to preset weights) is calculated for the candidate matches in each candidate group. Finally, the candidate matches in each candidate group are sorted from high to low according to the comprehensive relevance score to obtain the grouped and sorted candidate set.

[0044] Specifically, step S32 involves dynamically adjusting the candidate set based on opportunity cost and competition level after grouping and ranking to obtain a candidate set with adjusted relevance scores. It should be understood that since the candidate set after grouping and ranking only considers the candidate value of a single driver and does not take into account the overall order competition, popular orders may be included in the candidate sets of multiple drivers, leading to multiple drivers competing for the same order during recommendation and increasing the probability of conflict. Therefore, this application further dynamically adjusts the candidate set based on order competition level to reduce the score of popular orders in the non-optimally matched driver candidate set. This reduces conflicts caused by global order competition, guides popular orders to be recommended to more suitable drivers, balances global supply and demand, and improves order completion rate and system scheduling efficiency.

[0045] Specifically, in one possible embodiment, step S32 is implemented as follows: First, the frequency of occurrence of each order combination in the candidate set after grouping and sorting is counted to determine the competitiveness of each order; the more times an order appears, the higher its competitiveness. Then, a corresponding competition attenuation coefficient is set for different competitiveness levels, with a value range of 0 to 1. The higher the competitiveness, the smaller the corresponding attenuation coefficient; for example, 1.0 for no competition and 0.8 for high competition. Next, the candidate groups of each driver are traversed, and the comprehensive relevance score of the candidate matches within the group is multiplied by the competition attenuation coefficient of the corresponding order combination to dynamically adjust the score. Finally, candidate matches with non-negative adjusted scores are retained, and they are re-sorted according to the adjusted scores to form a candidate set after adjusting the relevance scores.

[0046] Specifically, in step S33, the candidate set after adjusting the relevance scores is input into the maximum boundary relevance module to obtain the recommendation list set at the current moment. It should be understood that while the candidate set after adjusting the relevance scores balances global competition, sorting solely by score still leads to a lack of diversity in the recommendation list, potentially leaving drivers with multiple similar candidates and failing to reflect the value of personalized choices. Therefore, this application further inputs the adjusted candidate set into the maximum boundary relevance module to filter out candidates with low similarity while maintaining candidate scores. This generates a recommendation list with both high value and differentiation for each driver, ensuring drivers have meaningful choices, reducing decision-making hesitation or order rejection due to candidate similarity, and improving driver experience and order-accepting efficiency.

[0047] Specifically, in one possible embodiment, step S33 is implemented as follows: First, an empty recommendation list is initialized for each target driver's adjusted candidate set. Then, the candidate with the highest adjusted score is selected from the candidate set and added to the recommendation list. Next, the similarity between the remaining candidates and the existing candidates in the recommendation list is iteratively calculated, and candidates with high adjusted scores and low similarity are selected and added to the list. This iteration is repeated until the recommendation list reaches a preset number, such as 3. Finally, the recommendation lists of all target drivers are summarized to form the recommendation list set at the current moment.

[0048] In particular, in another preferred embodiment, the diversity adjustment parameter is used to maximize boundary correlation. In other words, setting it as a global static hyperparameter means that regardless of the driver's environment (abundance or scarcity of orders) or the scarcity of candidate orders, the same standard is used to weigh relevance and diversity, which clearly ignores the context of the decision-making process. Specifically, balancing weights The penalty factor is used to balance driver satisfaction and system efficiency in response platforms. The application of this technology can adjust the relevance score to reflect the scarcity or demand of a candidate match in the current market competition landscape. Therefore, if the diversity adjustment parameter... By improving the parameters to be context-aware and dynamically calculated based on the context of the current decision, the diversity strategy can become more intelligent and adaptive. Specifically, step S33 includes: for each candidate match and its corresponding target driver in the candidate set after adjusting the relevance score, calculating the context pressure based on the intensity of competition for the candidate match and the scarcity of the opportunity set for the target driver; calculating the context-aware dynamic diversity adjustment parameter for the candidate match based on the context pressure; and applying the dynamic diversity adjustment parameter in the maximum boundary relevance module to adaptively balance relevance and diversity, thereby generating the recommendation list set at the current moment.

[0049] In other words, when drivers have few high-quality candidates (those with high adjusted relevance scores), or when a particular order is extremely important and highly competitive, the system should reduce its focus on diversity and instead emphasize relevance, ensuring that the best and most critical options are prioritized. Conversely, when drivers have many opportunities, the system can encourage diversity, providing more differentiated choices to improve the user experience. Therefore, dynamic diversity adjustment parameters are crucial. It should be positively correlated with the following two factors: competitive pressure of candidate orders, i.e., the more drivers consider a combination of orders as candidates ( The larger the value, the more important it is to the system (it may be a long-haul order in a critical region). To ensure this order is filled, the system should increase its diversity adjustment parameters. This allows the driver to rely more on its own relevance score in MMR calculations, reducing the risk of being squeezed out by less important but highly differentiated options. The scarcity of the driver opportunity set—meaning that if drivers have few high-scoring candidates to choose from—means that forcibly pursuing diversity may recommend some poor candidates, leading to a poor experience. In this case, the diversity adjustment parameter should be increased. This allows drivers to focus on the few best options available.

[0050] Based on this, for each candidate match and its corresponding target driver in the candidate set after adjusting the relevance score, the context pressure is calculated based on the competitiveness of the candidate matches and the scarcity of the opportunity set of the target drivers. This is defined as the context pressure function, which quantifies the recommendation process. For the driver At that time, the system faces the pressure of needing to succeed:

[0051] in, Candidate The level of competition, i.e., how many drivers can match this order combination; He is the driver An opportunity set quality score can be measured, for example, by the average of the adjusted relevance scores of all his candidates (adjusted) or the average of the top-5. The higher the score, the more and better his current opportunities are. It is a normalization function used to normalize the input value (i.e., the competitiveness). and average score Linearly scaled to the [0,1] interval so that features of different dimensions can be added together; and These are weights representing the degree of competition and the scarcity of opportunity, respectively, satisfying... Furthermore, these two weights can be dynamically adjusted based on the global supply and demand ratio; It is the context pressure function.

[0052] Then, based on context pressure, context-aware dynamic diversity adjustment parameters are calculated for candidate matches. Specifically, this is achieved by adjusting the context pressure... Mapping to the (0,1) interval using the Sigmoid function, and combining it with the fundamental values To generate the final dynamic Here, the Sigmoid function is used to provide a smooth transition, making the pressure smaller. When the value is close to the baseline, and the pressure is high. Rapidly approaching 1:

[0053] in, It is a global, basic diversity parameter (e.g., 0.5), representing the tendency towards diversity under normal circumstances without any pressure; It is the slope of the sigmoid function, which controls... from The degree of drastic change to 1; This is used to achieve centralized processing, so that when the pressure is at a moderate level (0.5), the Sigmoid function value is 0.5; It is a dynamic diversity adjustment parameter.

[0054] Therefore, in the module for maximizing boundary correlation, a dynamic diversity adjustment parameter is applied to adaptively balance correlation and diversity, thereby generating a recommendation list set for the current moment, which is crucial for the platform's capacity scheduling for orders that are contested by multiple drivers. high), This will significantly improve the system's liquidity and order fulfillment rate in key areas, increasing the completion rate of key orders. Furthermore, for drivers located in areas with scarce orders... (Low), the system no longer blindly pursues differentiation in recommended options. The improvement in MMR (Mean Ranking) will make the MMR algorithm more inclined to recommend the few best orders available, even if they may have some similarities in route. This avoids recommending low-quality options to drivers just to fill the quota, ensuring the effectiveness of the recommendations, increasing drivers' willingness to accept orders and their income, and improving the experience for drivers in peripheral areas. Additionally, for drivers in order-intensive areas (…), (High), the system also has ample options to provide diverse choices, at this time It will remain at a low level In terms of level, the MMR algorithm will more actively seek out orders that are not only highly rated but also diverse in type (such as long / short distance, different directions), giving drivers truly meaningful choices, avoiding homogenization of recommendation lists, improving driver satisfaction and sense of control, and optimizing the experience for drivers in order-rich areas.

[0055] In the aforementioned intelligent matching-based ride-hailing dispatch management method, step S4 involves pushing the current recommendation list set to the driver's end and receiving the current driver selection set from the driver's end. It should be understood that since the recommendation list set is only a system-generated candidate solution, it needs to be transmitted to the driver's end so that the driver can make a choice based on their own preferences. Furthermore, the lack of driver feedback would result in dispatch remaining in a one-way decision-making state, failing to reflect the driver's subjective will. Therefore, this application further pushes the recommendation list set to the driver's end and receives the driver's selection feedback, thereby empowering the driver to choose a solution that meets their needs from the suitable candidates. This fully respects the heterogeneous preferences of drivers, reduces order rejections caused by forced dispatch, and enhances driver acceptance of dispatch through proactive driver selection, thereby increasing driver retention and service enthusiasm.

[0056] Specifically, in one possible embodiment, step S4 is implemented as follows: First, the recommendation list for each target driver is structured according to a preset format, clearly displaying the core information of each candidate match, such as the trip route, estimated income, and duration. Then, the structured recommendation list is pushed to the corresponding driver's mobile app via the platform API interface. Simultaneously, a fixed-duration decision countdown, such as 30 seconds, is started to remind the driver to complete the selection. After the driver clicks to select a candidate match within the countdown, the mobile app uploads the selection result (driver ID, selected candidate ID, selection time) to the system. The system receives and aggregates the selection results of all drivers, forming the driver selection set for the current moment.

[0057] In the aforementioned intelligent matching-based ride-hailing dispatch management method, step S5 involves resolving conflicts in the current driver selection set to obtain the final matching scheme and dispatch instructions. It should be understood that multiple drivers may select candidate matches containing the same order, leading to order resource competition conflicts. If these conflicts are not resolved, the same order may be repeatedly assigned, preventing the formation of an executable dispatch scheme. Therefore, this application further resolves conflicts in the driver selection set to identify and resolve order resource competition issues, determining a uniquely suitable driver-order matching relationship. This avoids resource allocation contradictions, ensures the uniqueness and feasibility of the dispatch scheme, and transforms the conflict-resolved matches into specific dispatch instructions, ensuring drivers can efficiently execute pick-up tasks according to the instructions, thus improving overall dispatch implementation efficiency.

[0058] In particular, in one specific embodiment, Figure 7 This is a flowchart of sub-step S5 of the ride-hailing dispatch management method based on intelligent matching according to an embodiment of this application. Figure 7 As shown, step S5 includes: S51, performing a conflict graph-based competitive selection set parsing on the driver selection set at the current moment to obtain the winning selection set; S52, solidifying the matching scheme of the winning selection set to obtain the final matching scheme and scheduling instructions.

[0059] Specifically, step S51 involves performing a conflict graph-based competitive selection set analysis on the current driver selection set to obtain the winning selection set. It should be understood that directly traversing and identifying conflicts cannot intuitively demonstrate the relationship between orders and driver selections, easily overlooking implicit conflicts, such as selections indirectly sharing order resources, leading to incomplete conflict analysis. Therefore, this application further uses a conflict graph to perform competitive selection set analysis on the driver selection set, thereby visually presenting the relationship network between orders and driver selections and accurately locating all conflict nodes and competitive relationships. This comprehensively identifies explicit and implicit conflicts, avoiding subsequent scheduling problems caused by missed conflicts. Simultaneously, the structured analysis based on the conflict graph makes the determination of the winning selection more evidence-based, improving the fairness and rationality of conflict resolution.

[0060] Specifically, in one possible embodiment, step S51 is implemented as follows: First, a conflict graph is constructed, with driver selections as nodes and shared orders as edges. If two selections contain the same order, an edge is established between the corresponding nodes to form an association network. Then, the conflict graph is traversed to identify all node clusters with connected edges; each cluster is a set of competing choices. Next, comprehensive information about the corresponding driver selections is extracted from each set of competing choices, such as preference scores and utility scores for candidate matches. A unique optimal choice is selected as the winning choice from each set of competing choices according to a preset evaluation rule (such as sorting by comprehensive score). Finally, the winning choices and conflict-free choices from all sets of competing choices are aggregated to form a set of winning choices.

[0061] Specifically, step S52 involves solidifying the matching scheme of the winning selection set to obtain the final matching scheme and scheduling instructions. It should be understood that since the winning selection set is only a filtered set of valid choices, it does not form a standardized scheduling scheme and lacks specific execution guidelines for drivers, making it unsuitable for direct use in actual pick-up operations. Therefore, this application further solidifies the matching scheme of the winning selection set to transform the discrete winning choices into a structured matching scheme and generate executable scheduling instructions. This allows the scheduling scheme to have clear execution logic, ensuring drivers understand the details of the pick-up task. Simultaneously, standardized schemes and instructions reduce the driver's understanding cost, improve pick-up efficiency, and avoid service delays caused by ambiguous information.

[0062] Specifically, in one possible embodiment, step S52 is implemented as follows: First, the winning selection set is traversed, and each winning selection is associated with corresponding driver information (ID, contact information, current location) and order information (order ID, passenger contact information, origin and destination). Then, the information is integrated according to the format of driver ID, order combination, pick-up time window, and estimated trip duration to form a structured final matching scheme. Next, based on the final matching scheme, a unique dispatch instruction is generated for each driver, which includes details such as the pick-up location navigation link, number of passengers, luggage reminders, and special needs (such as children, the elderly). Finally, the dispatch instruction is pushed to the corresponding driver through a mobile app, and the delivery status of the instruction is recorded to ensure that the driver can view and execute it in real time.

[0063] In summary, the intelligent matching-based ride-hailing dispatch management method based on the embodiments of this application is explained. First, it utilizes historical log data to deeply mine driver behavioral characteristics and system operational patterns, constructing and training dual models to accurately characterize driver preferences and evaluate system benefits. Then, based on these dual models, a global matching evaluation of real-time supply and demand is performed, and a strategy to maximize boundary correlation is used to optimize allocation, generating a recommendation list that considers both driver preferences and diversity. Next, the recommendation list is pushed to the driver's end to receive feedback on their choices, and conflict resolution is performed based on this feedback, dynamically deriving the final matching solution. This effectively solves the problems of low dispatch success rate and driver churn caused by traditional dispatching methods that ignore heterogeneous driver preferences, thereby achieving a synergistic improvement in the satisfaction of both supply and demand sides and the overall dispatch efficiency of the system in ride-hailing scenarios.

[0064] Figure 8 This is a block diagram of a ride-hailing dispatch and management system based on intelligent matching according to an embodiment of this application. Figure 8 As shown, the ride-hailing dispatch management system 100 based on intelligent matching according to an embodiment of this application includes: a model training module 110, used to train a driver preference model and a system utility model based on historical log data to obtain a trained driver preference model and a trained system utility model; a candidate matching scoring module 120, used to generate and score a global candidate matching pool for a real-time driver pool and a real-time order queue based on the trained driver preference model and the trained system utility model to obtain a scored candidate pool; a recommendation allocation module 130, used to allocate candidate matches from the scored candidate pool to each target driver in the target driver set to be recommended using a maximized boundary correlation module to obtain a recommendation list set at the current time; a push response module 140, used to push the recommendation list set at the current time to the driver end and receive the driver selection set at the current time from the driver end; and a conflict resolution module 150, used to resolve conflicts in the driver selection set at the current time to obtain a final matching scheme and dispatch instructions.

[0065] As described above, the intelligent matching-based ride-hailing dispatch management system 100 according to the embodiments of this application can be implemented in various wireless terminals, such as servers with intelligent matching-based ride-hailing dispatch management algorithms. In one possible implementation, the intelligent matching-based ride-hailing dispatch management system 100 according to the embodiments of this application can be integrated into the wireless terminal as a software module and / or hardware module. For example, the intelligent matching-based ride-hailing dispatch management system 100 can be a software module in the operating system of the wireless terminal, or it can be an application developed for the wireless terminal; of course, the intelligent matching-based ride-hailing dispatch management system 100 can also be one of many hardware modules of the wireless terminal.

[0066] Alternatively, in another example, the intelligent matching-based ride-hailing dispatch management system 100 and the wireless terminal can also be separate devices, and the intelligent matching-based ride-hailing dispatch management system 100 can connect to the wireless terminal via wired and / or wireless networks and transmit interactive information in accordance with an agreed data format.

[0067] Here, those skilled in the art will understand that the specific operations of each step in the above-described intelligent matching-based ride-hailing dispatch and management system have been referenced above. Figures 1 to 7 The method for managing ride-hailing dispatch based on intelligent matching has been described in detail, and therefore, its repeated description will be omitted.

Claims

1. A ride-hailing dispatch management method based on intelligent matching, characterized in that, include: The driver preference model and system utility model are trained based on historical log data to obtain the trained driver preference model and system utility model. Based on the trained driver preference model and the trained system utility model, a global candidate matching pool is generated and scored for the real-time driver pool and the real-time order queue to obtain a scored candidate pool. The maximize boundary relevance module is used to assign candidate matches from the scored candidate pool to each target driver in the target driver set to be recommended, so as to obtain the recommendation list set at the current time. Push the current recommendation list to the driver's device, and receive the current driver selection list from the driver's device; Conflict resolution is performed on the driver selection set at the current moment to obtain the final matching scheme and scheduling instructions.

2. The ride-hailing dispatch management method based on intelligent matching according to claim 1, characterized in that, The data for each driver object in the real-time driver pool includes driver ID, GPS coordinates, vehicle status, and remaining capacity. The data for each order object in the real-time order queue includes order ID, origin coordinates, destination coordinates, number of passengers, and submission time.

3. The ride-hailing dispatch management method based on intelligent matching according to claim 2, characterized in that, Based on the trained driver preference model and the trained system utility model, a global candidate matching pool is generated and scored for the real-time driver pool and the real-time order queue to obtain a scored candidate pool, including: Candidate matching pairs under spatiotemporal constraints are generated for the real-time driver pool and the real-time order queue to obtain the unscored original candidate set; Based on the trained driver preference model and the trained system utility model, parallel scoring and pooling based on the dual models are performed on each candidate match in the unscored original candidate set to obtain a scored candidate pool.

4. The ride-hailing dispatch management method based on intelligent matching according to claim 3, characterized in that, Candidate matching pairs under spatiotemporal constraints are generated from the real-time driver pool and the real-time order queue to obtain the unscored original candidate set, including: Based on the search radius and the maximum estimated pick-up time, the real-time driver pool and real-time order queue are initially pruned using spatial indexing to obtain an independent candidate set; Perform route-based search of nearby ride-sharing orders on the independent candidate set and real-time order queue to obtain potential ride-sharing pairs; The feasibility of potential carpooling pairs is precisely verified by multiple constraints based on the real-time driver pool, real-time order queue, maximum detour rate, and maximum passenger waiting time to obtain the original candidate set without scoring.

5. The ride-hailing dispatch management method based on intelligent matching according to claim 3, characterized in that, Based on the trained driver preference model and the trained system utility model, parallel scoring and pooling based on a dual model are performed on each candidate match in the unscored original candidate set to obtain a scored candidate pool, including: Each candidate match in the unscored original candidate set is characterized to obtain a set of candidate match feature vectors; Each candidate matching feature vector in the candidate matching feature vector set is input into the trained driver preference model and the trained system utility model to obtain a set of score tuples; Based on the set of score tuples, the unscored original candidate set is structured pooled to obtain the scored candidate pool.

6. The ride-hailing dispatch management method based on intelligent matching according to claim 1, characterized in that, The maximize boundary relevance module is used to assign candidate matches from the scored candidate pool to each target driver in the target driver set to be recommended, in order to obtain the recommendation list set at the current time, including: For each target driver in the target driver set to be recommended, the already rated candidate pool is grouped and sorted by driver to obtain the grouped and sorted candidate set; Based on the grouped and sorted candidate set, the opportunity cost based on the degree of competition is dynamically adjusted to obtain the candidate set after adjusting the relevance score; The candidate set after adjusting the relevance score is input into the maximum boundary relevance module to obtain the recommendation list set at the current moment.

7. The ride-hailing dispatch management method based on intelligent matching according to claim 1, characterized in that, Conflict resolution is performed on the current set of driver choices to obtain the final matching scheme and scheduling instructions, including: The winning choice set is obtained by performing a conflict graph-based competitive choice set analysis on the driver choice set at the current moment; The winning selection set is used to solidify the matching scheme to obtain the final matching scheme and scheduling instructions.

8. The ride-hailing dispatch management method based on intelligent matching according to claim 6, characterized in that, The candidate set after adjusting the relevance scores is input into the maximum boundary relevance module to obtain the recommendation list set at the current time, including: For each candidate match and its corresponding target driver in the candidate set after adjusting the relevance score, the context pressure is calculated based on the competitiveness of the candidate match and the scarcity of the opportunity set of the target driver. Based on context pressure, context-aware dynamic diversity adjustment parameters are calculated for candidate matching; In the module for maximizing boundary relevance, a dynamic diversity adjustment parameter is applied to adaptively balance relevance and diversity, thereby generating the recommendation list set for the current moment.

9. A ride-hailing dispatch and management system based on intelligent matching, characterized in that, include: The model training module is used to train the driver preference model and the system utility model based on historical log data to obtain the trained driver preference model and the trained system utility model. The candidate matching scoring module is used to generate and score a global candidate matching pool for the real-time driver pool and the real-time order queue based on the trained driver preference model and the trained system utility model, so as to obtain a scored candidate pool. The recommendation allocation module is used to allocate candidate matches from the scored candidate pool to each target driver in the target driver set to be recommended using the maximized boundary correlation module to obtain the recommendation list set at the current time. The push response module is used to push the current recommendation list to the driver's end and receive the current driver selection set from the driver's end; The conflict resolution module is used to resolve conflicts in the driver selection set at the current moment to obtain the final matching scheme and scheduling instructions.

Images