Method and device for allocating online car-hailing order based on driver preference, and storage medium

Abstract

This application provides a method, apparatus, and storage medium for ride-hailing order allocation based on driver preferences. The method includes: obtaining real-time orders using a ride-hailing platform interface; parsing the real-time orders to obtain the order start coordinates, order destination coordinates, and discount flags; retrieving online drivers within a set radius centered on the order start coordinates using a spatial index to generate a candidate driver set; reading the vehicle type information and order acceptance preferences of each driver in the candidate driver set; filtering the candidate driver set based on the order destination coordinates, discount flags, and order acceptance preferences using multiple conditions to obtain a target driver set that meets the order acceptance criteria; sorting the target driver set according to the real-time distance from the driver to the order start, selecting the driver with the shortest distance, and assigning the current real-time order to the selected driver. This application can improve the probability of drivers accepting orders and improve the accurate matching of discounted orders with driver preferences, thereby achieving real-time and efficient order dispatch.

Description

Technical Field

[0001] This application relates to the field of Internet technology, and in particular to a method, apparatus and storage medium for allocating ride-hailing orders based on driver preferences. Background Technology

[0002] Ride-hailing services rely on mobile internet, GPS, and big data dispatching technology to provide passengers with on-demand travel solutions. To accommodate drivers' independent operation needs, mainstream platforms have configured "route-based mode" and "regional preference" functions on the driver's side: drivers can preset destinations or designate their regular pick-up areas, and the platform will only push orders whose destinations fall within this desired range; at the same time, the platform introduces discount strategies on the order side to stimulate order completion through differentiated pricing.

[0003] Existing dispatch systems typically perform initial matching based on passenger location, vehicle availability, and simple distance weighting, followed by filtering based on driver-defined route or regional preferences. If the number of remaining qualified drivers exceeds a threshold, dispatch is then performed by sorting drivers by distance or response speed. Some platforms allow drivers to set whether or not they accept discounted orders, but there is no linkage mechanism between discounts and preference strength, and spatial indexes often use fixed grids or single-layer search radii, making it difficult to balance real-time performance and accuracy in high-concurrency scenarios.

[0004] However, existing technologies still have the following problems: First, after drivers strictly set their route or region preferences, the number of available candidate orders decreases sharply, the probability of accepting orders drops, empty mileage increases, and operating revenue suffers. Second, the platform's order dispatch logic does not dynamically bind discount levels to the strength of driver preferences, resulting in a lack of targeted allocation of discounted orders. This not only fails to fully utilize the volume of discounted orders but may also affect the income expectations of regular drivers. Third, traditional single-layer spatial retrieval and synchronous query methods easily become performance bottlenecks when large-scale orders flood in frequently, increasing order dispatch delays and affecting passenger experience. Summary of the Invention

[0005] In view of this, embodiments of this application provide a method, apparatus and storage medium for ride-hailing order allocation based on driver preferences, in order to solve the problems of low driver acceptance probability, mismatch between discounted order allocation and driver preferences and poor real-time dispatch in the prior art.

[0006] A first aspect of this application provides a method for allocating ride-hailing orders based on driver preferences, comprising: obtaining real-time orders using a ride-hailing platform interface; parsing the real-time orders to obtain the order start coordinates, order destination coordinates, and discount flags; and unifying the order start coordinates and order destination coordinates into the same geographic coordinate system; retrieving online drivers within a set radius using a spatial index centered on the order start coordinates, and generating a candidate driver set; reading the vehicle type information and order acceptance preferences of each driver in the candidate driver set, the order acceptance preferences including area preferences based on map fences, route preferences based on travel corridors, and a minimum discount threshold; performing multi-condition filtering on the candidate driver set based on the order destination coordinates, discount flags, and order acceptance preferences to obtain a target driver set that meets the order acceptance conditions, wherein a mapping relationship between discount levels and order acceptance preference intensity is established, and the minimum discount threshold is dynamically adjusted according to the mapping relationship during the multi-condition filtering process; sorting the target driver set according to the real-time distance from the driver to the order start, selecting the driver with the shortest distance, and assigning the current real-time order to the selected driver.

[0007] A second aspect of this application provides a ride-hailing order allocation device based on driver preferences, comprising: an acquisition module, configured to acquire real-time orders using a ride-hailing platform interface, parse the real-time orders to obtain the order start coordinates, order destination coordinates, and discount flags, and unify the order start coordinates and order destination coordinates to the same geographic coordinate system; a generation module, configured to retrieve online drivers within a set radius centered on the order start coordinates by calling a spatial index, and generate a candidate driver set; a reading module, configured to read the vehicle type information and order acceptance preferences of each driver in the candidate driver set, the order acceptance preferences including area preferences based on map fences, route preferences based on travel corridors, and a minimum discount threshold; a filtering module, configured to perform multi-condition filtering on the candidate driver set based on the order destination coordinates, discount flags, and order acceptance preferences, to obtain a target driver set that meets the order acceptance conditions, wherein a mapping relationship between discount level and order acceptance preference intensity is established, and the minimum discount threshold is dynamically adjusted according to the mapping relationship during the multi-condition filtering process; and a dispatch module, configured to sort the target driver set according to the real-time distance from the driver to the order start, select the driver with the shortest distance, and dispatch the current real-time order to the selected driver.

[0008] A third aspect of this application provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the above-described method.

[0009] A fourth aspect of this application provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps of the above-described method.

[0010] The above-described technical solutions adopted in the embodiments of this application can achieve the following beneficial effects:

[0011] By utilizing ride-hailing platform interfaces to obtain real-time orders, parsing these orders to obtain the origin coordinates, destination coordinates, and discount flags, and unifying the origin and destination coordinates to the same geographic coordinate system; using the origin coordinates as the center, a spatial index is used to retrieve online drivers within a set radius, generating a candidate driver set; the vehicle type information and order-accepting preferences of each driver in the candidate driver set are read, including region preferences based on map fences, route-corridor preferences, and minimum discount thresholds; based on the destination coordinates, discount flags, and order-accepting preferences, the candidate driver set is filtered under multiple conditions to obtain a target driver set that meets the order-accepting criteria, establishing a mapping relationship between discount levels and order-accepting preference strengths, and dynamically adjusting the minimum discount threshold based on this mapping relationship during the multi-condition filtering process; the target driver set is sorted according to the real-time distance from the driver to the order origin, selecting the driver with the shortest distance, and assigning the current real-time order to the selected driver. This application can improve the driver's order acceptance probability and the accuracy of matching discounted orders with driver preferences, thereby achieving real-time and efficient order dispatch. Attached Figure Description

[0012] To more clearly illustrate the technical solutions in the embodiments of this application, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0013] Figure 1 This is a schematic diagram of a ride-hailing order allocation process based on driver preferences in a real-world scenario provided in the embodiments of this application;

[0014] Figure 2 This is a flowchart illustrating the ride-hailing order allocation method based on driver preferences provided in an embodiment of this application.

[0015] Figure 3 This is a schematic diagram of the structure of the ride-hailing order allocation device based on driver preferences provided in the embodiments of this application;

[0016] Figure 4 This is a schematic diagram of the structure of the electronic device provided in the embodiments of this application. Detailed Implementation

[0017] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application may also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted so as not to obscure the description of this application with unnecessary detail.

[0018] In existing technologies, platforms typically sort passengers by distance from their pick-up point and vehicle availability, then simply overlay driver route patterns or area-based filtering. Because discounted orders lack linkage with driver preferences, and spatial retrieval often uses a single-layer fixed radius, the number of orders drivers can accept decreases drastically when preference constraints are strong, leading to a lower order acceptance probability and a significant increase in empty mileage and dispatch delays.

[0019] To address the aforementioned shortcomings, this application focuses on three major pain points: low driver acceptance probability, mismatched discount order allocation, and poor real-time dispatching. It proposes a ride-hailing order allocation method based on driver preferences. This method first parses real-time orders and standardizes coordinates. Then, it uses a hexagonal hierarchical grid spatial index to quickly select online drivers around the order's origin. Next, it uses a driver profile microservice to read vehicle type and fingerprinted order acceptance preferences, decoding to obtain regional fences, along-route corridors, and a minimum discount threshold. The system establishes a mapping model between discount levels and preference strength, dynamically adjusting the minimum discount threshold during multi-dimensional filtering. It combines vehicle type, region, along-route, and discount constraints to eliminate mismatched drivers. Finally, it uses a dynamic graph neural network path estimation service to calculate real-time travel time, sorts orders by comprehensive priority, and employs a transaction lease mechanism for reliable order dispatching.

[0020] The technical solution proposed in this application can significantly improve the matching accuracy between discounted orders and driver preferences while meeting the personalized trip needs of drivers, increase the probability of drivers accepting orders, reduce the empty mileage rate, and ensure millisecond-level order dispatch response in high-concurrency scenarios, thereby optimizing the overall scheduling efficiency of the platform and the passenger service experience.

[0021] Before providing a detailed explanation of the technical solution of this application, we will first provide a general overview of the overall implementation process of the ride-hailing order allocation method based on driver preferences in a real-world scenario, using specific embodiments as examples. Figure 1 This is a schematic diagram of a ride-hailing order allocation process based on driver preferences in a real-world scenario provided in the embodiments of this application. Figure 1 As shown, the overall implementation process of this ride-hailing order allocation method may include the following:

[0022] In actual order-taking scenarios, when the platform detects a new passenger initiating an order request, the order allocation system first accesses the order through the real-time interface with the ride-hailing platform, parses and obtains the order's origin coordinates, destination coordinates, and discount flag, and immediately maps the origin and destination coordinates to the system's preset geographic coordinate system, laying a consistent data benchmark for subsequent spatial retrieval.

[0023] Subsequently, the system uses the unified order origin coordinates as the center and sets a radius (e.g., 3 kilometers) to call the spatial index service, efficiently retrieves and selects drivers within this range who are online, forming the first batch of candidate drivers.

[0024] For the aforementioned candidate drivers, the system retrieves each driver's vehicle type information and order-accepting preference parameters from the driver profile center. Order-accepting preferences include preset area fences, along-the-route corridors, and minimum discount thresholds. Based on the order destination coordinates, discount markers, and each driver's order-accepting preferences, the system performs multi-dimensional conditional matching, sequentially eliminating drivers who do not meet the conditions, such as mismatched vehicle type, destination not falling within the area fence or along the along-the-route corridor, or order discounts below the minimum discount threshold, thus obtaining a target driver set that meets the order-accepting criteria.

[0025] To shorten passenger waiting times, the system invokes a real-time route estimation service, combining current traffic flow data to calculate the predicted arrival time of each driver in the target driver set to the order's origin, and then sorts the target drivers according to this time from shortest to longest. After sorting, the system sends an order dispatch request to the driver closest to the destination and with the highest overall priority; if the driver does not confirm acceptance within the specified response window, the system automatically pushes the order to the next driver in the sorting order until the order is accepted.

[0026] Through the above steps, the platform ensures that drivers' personalized preferences are fully respected while achieving fast and accurate order allocation.

[0027] The technical solution of this application will now be described in detail with reference to the accompanying drawings and specific embodiments.

[0028] Figure 2 This is a flowchart illustrating the ride-hailing order allocation method based on driver preferences provided in an embodiment of this application. Figure 2 As shown, this ride-hailing order allocation method based on driver preferences may specifically include:

[0029] S201: Use the ride-hailing platform interface to obtain real-time orders, parse the real-time orders to obtain the order start coordinates, order end coordinates and discount markers, and unify the order start coordinates and order end coordinates into the same geographic coordinate system;

[0030] S202: Using the order origin coordinates as the center, retrieve online drivers by calling the spatial index within a set radius and generate a candidate driver set;

[0031] S203, Read the vehicle type information and order-accepting preferences of each driver in the candidate driver set. The order-accepting preferences include regional preferences based on map fences, route preferences based on trip corridors, and minimum discount threshold.

[0032] S204. Based on the order destination coordinates, discount flags and order acceptance preferences, the candidate driver set is filtered by multiple conditions to obtain the target driver set that meets the order acceptance conditions. In this process, a mapping relationship between the discount level and the order acceptance preference intensity is established, and the minimum discount threshold is dynamically adjusted according to the mapping relationship during the multi-condition filtering process.

[0033] S205: Sort the target driver set according to the real-time distance from the driver to the order origin, select the driver with the shortest distance, and dispatch the current real-time order to the selected driver.

[0034] In some embodiments, real-time orders are obtained using a ride-hailing platform interface, and the real-time orders are parsed to obtain the order origin coordinates, order destination coordinates, and discount flags. The order origin coordinates and order destination coordinates are then unified to the same geographic coordinate system, including:

[0035] Real-time order data streams are received via an asynchronous interface based on a message queue, and the field recognition model is called to extract the starting coordinate field, the ending coordinate field, and the discount field.

[0036] The coordinate system to which each coordinate field belongs is determined based on the coordinate system identifier carried by each coordinate field or through a coordinate format recognition algorithm, and the start coordinate field and the end coordinate field are respectively converted to the preset intermediate reference coordinate system;

[0037] The system calls upon multi-source map reference information to convert the starting and ending coordinates in the intermediate reference coordinate system into coordinates in the target unified coordinate system, and records the conversion index for subsequent spatial retrieval.

[0038] Specifically, this embodiment focuses on the "order access and coordinate unification" stage. The system continuously pulls real-time order streams pushed by the ride-hailing platform through an asynchronous message queue interface. First, it calls the field recognition model to quickly parse out the origin coordinate field, destination coordinate field, and discount field. Then, based on the coordinate system identifier or coordinate format recognition result inherent in the coordinate fields, it maps the two sets of coordinates to a preset intermediate reference coordinate system. Finally, it uses multi-source map reference information to complete the conversion to the target unified coordinate system and simultaneously generates a coordinate conversion index for direct reuse in subsequent spatial retrieval. The entire process ensures that coordinate standardization is completed within milliseconds, providing a unified and accurate spatial reference for GEO driver selection.

[0039] First, the concepts of the key technical terms involved in this embodiment will be explained, as follows:

[0040] Asynchronous message queue interface: An event channel based on the publish-subscribe pattern, which can decouple the order generation end and the order dispatch system in high-concurrency scenarios, and achieve non-blocking data access through batch retrieval and client buffering mechanism.

[0041] Field recognition model: Based on a deep sequence labeling network, combined with regular expression templates and platform field dictionaries, it automatically adapts to JSON or ProtoBuf order data submitted by different platforms to ensure accurate extraction of coordinates and discount information.

[0042] Coordinate format recognition algorithm: It uses a combination of numerical range, location information and standard prefix features to determine the coordinate system to which the coordinate belongs, and is compatible with common geographic coordinate systems such as GCJ-02, BD-09 and WGS-84.

[0043] Intermediate reference coordinate system: The system uniformly adopts the ECEF three-dimensional rectangular coordinate system based on the International Earth Reference Ellipsoid as the transition coordinate system to reduce the cumulative error caused by multiple direct transformations.

[0044] Multi-source map reference information: Integrating the coordinate reference frame of the State Bureau of Surveying and Mapping and the publicly available reference parameters of multiple commercial map manufacturers, and using dynamic parameter matching to achieve high-precision conversion.

[0045] Coordinate transformation index: The original order ID, original coordinates, target coordinates and transformation timestamp are hashed and fingerprinted and stored in a distributed key-value database, supporting direct reading of unified coordinates in subsequent retrieval links.

[0046] For example, in a typical scheduling cycle, the platform generates thousands of orders sequentially, all pushed in real time through a Kafka topic named "order-stream". The order dispatch system subscribes to this topic at a high watermark. Upon receiving an order message with the platform identifier "P1", it immediately writes it to the circular buffer and triggers the field recognition model for parsing. The model identifies four fields, "start_lat", "start_lng", "dest_lat", and "dest_lng", and the "discount_code" field from the order body; it determines that the latitude and longitude values ​​are located between 120° and 121° east longitude and 30° and 31° north latitude, and the numerical format retains 6 decimal places. Combined with the P1 platform metadata, it can be known that this batch of coordinates uses the GCJ-02 system.

[0047] The system then calls the "toECEF" method of the coordinate transformation engine to convert the GCJ-02 latitude and longitude into ECEF three-dimensional coordinates (in meters) and records them to the intermediate reference coordinate cache. After the conversion is completed, a second conversion is performed according to the "ECEF→WGS-84" dynamic parameter set maintained by the engine to obtain unified WGS-84 latitude and longitude. Taking the order ID "ORD-20250729-0001" as an example, the starting coordinates were successfully converted from (30.285123, 120.152345) to (30.283901, 120.148987), and the ending coordinates were converted from (30.299876, 120.134210) to (30.298654, 120.130842). The system generates a fingerprint “IDX-015A73…” and writes it together with the order ID, original coordinates, target coordinates and timestamp “20250729T180301Z” into the distributed key-value database “coo rd-kv”.

[0048] At this point, the coordinates for this order have been unified and the converted index has been saved. Subsequently, when the GEO index module searches for drivers within a three-kilometer radius, it can directly read the WGS-84 coordinates from "coord-kv," avoiding redundant calculations and ensuring that the entire dispatch chain maintains sub-second latency even under thousands of concurrent requests.

[0049] In some embodiments, using the order origin coordinates as the center, a spatial index is invoked within a set radius to retrieve online drivers and generate a candidate driver set, including:

[0050] The spatial indexing algorithm is used to map the order's starting coordinates to the first index unit number;

[0051] Within a preset hierarchical range, obtain the set of target index units adjacent to the first index unit number, and traverse them sequentially in order from nearest to farthest.

[0052] Read the driver identifiers in each target index unit whose most recent heartbeat time has not exceeded the threshold and who are online, and accumulate them to form the first driver set;

[0053] When the number of the first driver set is less than the preset candidate threshold, the spatial index level is increased to expand the target index unit set, and the read and accumulation operations are repeated until the second driver set that meets the preset candidate threshold is obtained.

[0054] The second driver set is set as the candidate driver set, and the candidate driver set and its corresponding index unit number are written into distributed memory for subsequent use.

[0055] Specifically, this embodiment focuses on the "spatial indexing for selecting online drivers" step. After receiving the order origin with unified coordinates, the system first maps these coordinates to the first index unit number using a spatial indexing algorithm. Then, it traverses adjacent index units from near to far within a preset hierarchy, reading and accumulating the identifiers of drivers with online heartbeats in real time. If the accumulated result is insufficient to support subsequent preference filtering, the system automatically upgrades the index hierarchy to expand the search radius until a set of drivers meeting the candidate threshold is obtained. Finally, this set and the corresponding index unit number are written into distributed memory, providing an efficient data entry point for subsequent multi-condition filtering.

[0056] Spatial indexing algorithms map the latitude and longitude of the Earth's surface onto a hierarchical hexagonal grid, with each grid cell serving as an index unit. Grids at the same level have the same area and can be uniquely identified by "level + index." The index level indicates the grid's fineness; higher levels have smaller grids. The index unit number is composed of a level code and location information, exhibiting a natural lexicographical order from nearest to farthest. Driver heartbeat refers to the location and status signals periodically reported by the driver. In this embodiment, a heartbeat interval of less than 15 seconds is considered as online. Distributed memory is a high-speed key-value cache deployed across multiple nodes, used to share intermediate results among processing modules.

[0057] The specific implementation process of this embodiment will be described in detail below with reference to examples, and may include the following:

[0058] I. Index Mapping: After receiving the starting coordinates (30.283901, 120.148987), the system calls the spatial indexing algorithm to generate the first index cell number "8-1A7B4C" at level L8. At this time, the algorithm simultaneously returns the cell numbers of the seven adjacent cells at the same level and provides a traversal order from nearest to farthest according to the hexagonal adjacency rule.

[0059] II. Neighbor Unit Traversal and Driver Accumulation: The scheduling engine sequentially queries the online driver list in the driver status index table for "8-1A7B4C" and its neighboring units in traversal order. During the query process, the system only retains the driver identifiers whose most recent heartbeat time is no more than 15 seconds from the current time and writes them to the local set. After completing the query of eight units, the accumulation process terminates if the size of the local set reaches the preset candidate threshold of 50.

[0060] III. Index Level Upgrade: When the local collection is less than 50, the system will upgrade the index level to L9. This upgrade subdivides the original L8 unit into seven sub-units, thereby expanding the search coverage. The engine continues to query the newly added sub-units in a sequence from nearest to furthest and accumulate online drivers until the collection size reaches 50.

[0061] IV. Result Writing and Index Caching: After obtaining a set of 52 online drivers, the system writes the candidate driver set and its corresponding index unit number into the distributed memory "coord-cache" using the order ID as the key, setting an expiration time of 30 seconds. Subsequent multi-condition filtering modules can directly read this key to avoid duplicate space searches.

[0062] For example, if only 42 drivers are obtained at level L8, after the system enters level L9, it first queries the sub-unit "9-1A7B4C-1" corresponding to "8-1A7B4C". In this unit, 8 drivers are added at once, bringing the total number of drivers in the set to 50, which meets the threshold, and no further layer expansion is needed. At this point, the indexing algorithm records "Level promotion count = 1". This indicator can be used for subsequent dynamic parameter tuning to automatically widen the initial radius during peak periods.

[0063] By combining hierarchical hexagonal spatial indexing with online heartbeat verification, this embodiment completes the selection of candidate drivers within a millisecond response time. This ensures both the sufficiency and real-time nature of the candidate set, while effectively controlling the retrieval scope and system load, laying an accurate and efficient data foundation for subsequent preference filtering and dispatch sorting.

[0064] In some embodiments, reading the vehicle type information and order-accepting preferences of each driver in the candidate driver set includes:

[0065] The driver profiling microservice stores vehicle type information and order acceptance preference fingerprint vectors with driver identifiers as the primary key, and uses an incremental synchronization mechanism to update vehicle type information and order acceptance preference fingerprint vectors in real time.

[0066] Parallel asynchronous queries are initiated in batches for the candidate driver set, and the corresponding vehicle type information and order acceptance preference fingerprint vector are returned from the driver profile microservice.

[0067] The order preference fingerprint vector is input into the hierarchical hash mapping model, and the regional preference fence parameters, the route preference corridor parameters, and the minimum discount threshold are decoded and written into a temporary cache associated with the corresponding driver identifier, along with the vehicle type information.

[0068] Specifically, this embodiment focuses on the "driver profile reading and preference decoding" stage. The system takes a set of candidate drivers as input. First, it uses a driver profile microservice to batch query each driver's vehicle type information and order-acceptance preference fingerprint vector. Then, it uses a hierarchical hash mapping model to quickly decode the fingerprint vector into regional preference fence parameters, route preference corridor parameters, and minimum discount threshold. Finally, the decoding results, along with vehicle type information, are written to a temporary cache, providing directly indexable structured data for subsequent multi-condition filtering. The entire process, coupled with an incremental synchronization mechanism, ensures real-time updates to driver profiles and controllable query latency.

[0069] First, the concepts of the key technical terms involved in this embodiment will be explained, as follows:

[0070] Driver Profile Microservice: An independently deployed microservice that manages vehicle type and preference information using a "driver identifier → profile" key-value structure and supports horizontal scaling.

[0071] Order acceptance preference fingerprint vector: A fixed-length binary or numerical sequence that compresses multi-dimensional preferences such as area fences, along-the-way corridors, and discount thresholds into a single vector through hash mapping, making it easy to retrieve in one search.

[0072] Incremental synchronization mechanism: Based on the subscription mode of event bus, once the driver modifies preferences or vehicle information, a change event is immediately generated and pushed to the profile microservice, achieving sub-second data refresh.

[0073] Layered hash mapping model: The fingerprint vector is hashed and decoded in multiple levels by bit segment. The upper layer locates the preference type, and the lower layer parses the specific parameters. The decoding time complexity is approximately O(1).

[0074] Temporary cache: Deployed in an in-memory database cluster, with a 30-second lifespan, used to reuse profile data within a single dispatch transaction.

[0075] The specific implementation process of this embodiment will be described in detail below with reference to examples, and may include the following:

[0076] I. Data Storage and Incremental Synchronization

[0077] The driver profiling microservice uses a key-value database to store the fields: {vehicle type, fingerprint vector, latest update time}. When a driver adjusts the "permanent fence" or "lowest discount" on the client side, the client generates a change event and writes it to the event bus. After the microservice listens for the event, it only updates the affected fields and refreshes the update time, avoiding a full rewrite.

[0078] II. Batch Parallel Queries

[0079] After receiving the candidate driver set (52 in total), the scheduling engine splits it into 3 batches, with no more than 20 drivers in each batch. For each batch, a parallel asynchronous RPC request is constructed and sent to the driver profile microservice. The microservice returns the batch results by primary key index, with an average batch time of 15ms. After aggregating all responses locally, the engine enters the decoding phase.

[0080] III. Fingerprint Decoding

[0081] Each fingerprint vector is split into three segments: high, medium, and low.

[0082] The high-level segment maps the fence ID of the region, and the model obtains the vertex coordinates of the fence polygon by looking up a table.

[0083] The mid-segment mapping corresponds to the corridor level and corridor width;

[0084] Low-order segment mapping minimum discount threshold percentage.

[0085] The three types of parameters after decoding are combined with the vehicle type information into a structured object.

[0086] IV. Write to temporary cache

[0087] The system writes the key "drv:{driver identifier}:pref" to the decoding object and sets its lifespan to 30 seconds. A dual-write consistency strategy is used at the caching level: if the driver modifies their preferences again within this window, the new profile event will simultaneously refresh both the microservice and the cache, ensuring data consistency.

[0088] For example, taking driver ID "DRV-53701" as an example, its fingerprint vector decoding yields: area fence ID "FEN CE-HZ-07" (corresponding to the polygon of Hangzhou West Lake District), the along-route corridor is "LEVEL-2, width 1.5km", and the minimum discount threshold is "93%". This, along with the vehicle type "pure electric SUV", is written into the cache for direct use by downstream filtering modules.

[0089] Through incremental synchronization and hierarchical hash mapping model of the profile microservice, this embodiment achieves millisecond-level batch parsing of candidate driver vehicle types and refined order-accepting preferences, which not only ensures real-time accuracy of information, but also reduces the query time of the filtering link, providing efficient and reliable data support for subsequent multi-dimensional matching.

[0090] In some embodiments, the candidate driver set is filtered based on order destination coordinates, discount flags, and order acceptance preferences to obtain a target driver set that meets the order acceptance criteria, including:

[0091] Vehicle type information, regional preference compliance, route preference compliance, and dynamically adjusted discount compliance are encoded into a multi-dimensional constraint vector;

[0092] The Boolean rule matching engine is invoked to perform parallel matching on each multidimensional constraint vector, eliminating drivers who do not meet the constraints in any dimension, and obtaining the first target driver subset;

[0093] When the number of the first target driver subset is lower than a preset threshold, the discount compliance constraint is relaxed according to the discount expansion strategy, and the Boolean rule matching is re-executed to generate a second target driver subset;

[0094] Merge the first target driver subset with the second target driver subset to form the target driver set, and write the target driver set into the variable proximity index for subsequent sorting calls.

[0095] Specifically, this embodiment focuses on the step of "generating a target driver set through multi-condition filtering". After obtaining the candidate driver set and corresponding profiles, the system first constructs a multi-dimensional constraint vector for each driver, including vehicle type information, regional preference compliance, route preference compliance, and dynamic discount compliance. Then, it calls the Boolean rule matching engine to detect in parallel whether each dimension meets the constraint conditions, thus obtaining a first target driver subset. If the number of subsets is insufficient to support order dispatch, the system relaxes the discount compliance according to the discount expansion strategy and re-matches to generate a second target driver subset. Finally, the two subsets are merged to form the target driver set, which is written into a variable proximity index for the sorting module to call.

[0096] First, the concepts of the key technical terms involved in this embodiment will be explained, as follows:

[0097] Multidimensional constraint vector: A vector structure composed of multiple screening dimensions in a fixed order, where 1 indicates that the constraint is satisfied and 0 indicates that it is not satisfied; in this embodiment, it is denoted as <V,C,R,D>.

[0098] Boolean rule matching engine: Based on the rule statement "V∧C∧R∧D", it performs bitwise AND operations on vectors in batches to quickly eliminate drivers who do not meet all the conditions.

[0099] Discount compliance: A binary result obtained by comparing the order discount with the driver's minimum discount threshold. 1 means the discount is not lower than the threshold, and 0 means it is lower than the threshold.

[0100] Discount expansion strategy: When there are not enough target drivers, reduce the minimum discount threshold percentage for drivers without changing other dimensional rules to increase the matching success rate.

[0101] Variable Proximity Index: A dynamically constructed proximity structure for the same order, with the order ID as the key and additional attributes such as the target driver set and real-time distance as the value.

[0102] The specific implementation process of this embodiment will be described in detail below with reference to examples, and may include the following:

[0103] I. Vector Encoding

[0104] The system iterates through the candidate driver set sequentially, generating a vector <V,C,R,D> for each driver:

[0105] V is the vehicle type matching mark. The dispatching rules require passengers to be "Comfort type or above". Pure electric SUVs or gasoline SUVs are marked with 1, and other vehicle types are marked with 0.

[0106] C represents the regional preference conformity. If the order's destination falls within the driver's designated area, it is recorded as 1; otherwise, it is recorded as 0.

[0107] R represents the degree of conformity of the route preference, which is calculated by the distance between the destination and the center line of the driver's route corridor. If it is less than the width of the corridor, it is recorded as 1; otherwise, it is recorded as 0.

[0108] D represents the dynamic discount compliance. The system uses the discount threshold of 93% output by the discount-preference mapping model as the baseline. An order discount of ≥93% is recorded as 1, otherwise it is recorded as 0.

[0109] II. First Rule Matching

[0110] The Boolean rule matching engine performs parallel operations "V∧C∧R∧D" on all vectors to obtain the first target driver subset; in this scenario, there are 17 drivers who satisfy the condition that all four dimensions are 1.

[0111] III. Discount Expansion and Second Matching

[0112] The preset target threshold is 25 drivers, and the current 17 drivers do not meet the threshold. The system activates the discount expansion strategy, lowering the discount threshold to 88%, updates the D position, and re-executes the matching. 11 new drivers meet the requirements, and these are merged with the top 17 drivers to obtain 28 drivers, which meets the threshold.

[0113] IV. Writing to the Variable Proximity Index

[0114] The system uses "ORD-20250729-0001:target" as the key to write the identifiers of 28 target drivers and their real-time distances to the starting point into the Redis cluster. The variable proximity index is set to have a lifespan of 30 seconds, which can be directly read by the subsequent priority sorting module.

[0115] By leveraging the high-concurrency computation of multi-dimensional constraint vectors and Boolean rule matching engines, this embodiment maintains the rigid constraints of vehicle type, region, and route while flexibly adjusting the discount dimension through a discount expansion strategy. This ensures both a sufficient number of target drivers and explicit traceability of all dimensional conditions, achieving a fast, accurate, and scalable multi-condition filtering mechanism.

[0116] In some embodiments, a mapping relationship is established between discount levels and order acceptance preference intensity, and the minimum discount threshold is dynamically adjusted according to the mapping relationship during multi-condition filtering, including:

[0117] Collect drivers' feedback on accepting orders with different discounts in historical orders and the corresponding order acceptance preference strength to construct a discount preference training sample set;

[0118] A discount preference mapping model is obtained by training the discount preference training sample set using a regression algorithm, with the order acceptance preference intensity as input and the discount level as output.

[0119] When performing multi-condition filtering, the order acceptance preference intensity of candidate drivers is obtained, the order acceptance preference intensity is input into the discount preference mapping model to obtain the target discount level, and the target discount level is set as the minimum discount threshold for candidate drivers.

[0120] After the order allocation is completed, the driver's real-time order acceptance feedback is written into the incremental sample queue, and the discount preference mapping model is updated online according to the preset time window.

[0121] Specifically, this embodiment focuses on the "discount level-order acceptance preference intensity mapping and dynamic threshold adjustment" step. The system first constructs a discount preference training sample set based on drivers' historical order acceptance data, and then uses a regression algorithm to train a discount preference mapping model. During real-time order dispatch, the system uses the order acceptance preference intensity of candidate drivers as input to predict their acceptable target discount level, and sets this target discount level as the minimum discount threshold for multi-condition filtering. After an order is completed, the driver's order acceptance feedback is written into an incremental sample queue, and the mapping model is updated online using a sliding window approach.

[0122] First, the concepts of the key technical terms involved in this embodiment will be explained, as follows:

[0123] Order acceptance preference intensity: A normalized parameter calculated by considering factors such as the radius of the area fence, the width of the corridor along the route, and the historical order rejection rate. The range is 0-1, and the larger the value, the stricter the preference.

[0124] Discount Levels: The platform uses discrete labels to segment order discounts by percentage, such as 100% for no discount, 95% for 90% and so on.

[0125] Discount Preference Mapping Model: A regression model based on gradient boosting trees, taking the order acceptance preference strength as input and outputting the lowest acceptable discount level for drivers.

[0126] Incremental Sample Queue: A high-speed message queue used to collect drivers' feedback on accepting or rejecting new orders in real time.

[0127] The specific implementation process of this embodiment will be described in detail below with reference to examples, and may include the following:

[0128] First, the dispatch engine extracts nearly 90 days of historical order logs daily, filters data containing discount fields and driver order acceptance results, and records a quadruple of <driver ID, discount percentage, order acceptance result, order acceptance preference intensity>. The order acceptance preference intensity is calculated by the driver profiling service based on factors such as the area of ​​the fence on that day and the route-following level. A total of 3 million valid samples were obtained during the statistical period.

[0129] Furthermore, in the feature engineering stage, discrete discount levels are mapped according to the discount percentage, and labels are established. The strength of order acceptance preference is used as the main feature, supplemented by secondary features such as the driver's historical order acceptance rate and active time period. A regression framework based on gradient boosting trees is adopted. After 10-fold cross-validation, the mean squared error of the model on the validation set is ≤0.8. The output format is a mapping function of {preference strength → target discount level}. The model is trained offline once a day and persisted to the parameter server.

[0130] Furthermore, in the multi-condition filtering stage, the system queries the order-acceptance preference strength (e.g., 0.78) of each candidate driver in real time and sends it to the mapping model. The model returns the target discount level (e.g., 92%). The system sets 92% as the driver's dynamic minimum discount threshold and participates in the discount compliance calculation.

[0131] Furthermore, after order allocation, the platform generates feedback messages and writes them to the incremental sample queue based on whether the driver actually accepted the order and whether the passenger canceled it. The model service fetches the latest 10,000 incremental samples every 10 minutes for micro-batch training, and uses a learning rate decay and sliding window strategy to update the model weights, ensuring that the mapping relationship adapts to the evolution of driver behavior.

[0132] By introducing a discount preference mapping model, this embodiment realizes the ability to infer the acceptable discount level of drivers in real time based on the strength of their order acceptance preferences. This makes the discount constraint no longer static and fixed, thereby expanding the effective candidate set while ensuring drivers' expected income, and significantly improving the order dispatch success rate and model adaptive performance.

[0133] In some embodiments, the target driver set is sorted according to the real-time distance from the driver to the order origin, the driver with the shortest distance is selected, and the current real-time order is assigned to the selected driver, including:

[0134] Subscribe to real-time traffic flow data through a path estimation service based on a dynamic graph neural network, and obtain the current location of each driver in the target driver set;

[0135] The route estimation service is invoked to generate multiple alternative driving routes between the driver's current location and the order's origin coordinates for each driver. The predicted arrival time of each alternative driving route is calculated by combining real-time traffic flow data, and the shortest predicted arrival time is set as the driver's real-time travel time.

[0136] Calculate priority scores based on real-time travel time and drivers’ historical order acceptance response probability, sort the target driver set in ascending order of priority scores, and select the first driver.

[0137] The first driver is locked in using a transaction lease and a real-time order is sent. If no order acceptance confirmation is received from the first driver in the preset response window, the transaction lease is automatically released and the real-time order is pushed to the next driver in the sorted order until the real-time order is accepted or the target driver set has been traversed.

[0138] Specifically, this embodiment describes the priority ranking and reliable dispatch mechanism based on the path estimation service of dynamic graph neural network. The system first subscribes to real-time traffic flow data and obtains the current location of each target driver; then, it generates several alternative driving routes for each driver and calculates the corresponding predicted arrival time, taking the shortest predicted arrival time as the real-time travel time; next, it calculates the priority score by combining the driver's historical order acceptance probability, and sorts the target driver set from smallest to largest; finally, it pushes orders sequentially through transaction leases until the order is accepted or the target set has been traversed.

[0139] First, the concepts of the key technical terms involved in this embodiment will be explained, as follows:

[0140] Dynamic Graph Neural Network Path Estimation Service: Based on the traditional road network map, dynamic attributes such as traffic flow, traffic light cycle, and construction closures are introduced, and graph convolution and attention mechanisms are used to update edge weights in real time to output high-precision arrival time predictions.

[0141] Real-time traffic flow data: information such as minute-level congestion index and speed distribution gathered from road sensors, vehicle-to-everything (V2X) terminals, and map open platforms.

[0142] Historical order response probability: The platform statistics show the confirmation rate of drivers after receiving orders in the past 30 days, which is normalized to a response probability between 0 and 1 by an exponentially weighted moving average.

[0143] Transaction lease: The dispatching system and the driver's terminal lock the right to accept orders through lease tokens. The lease is valid until the preset response window (e.g., 8 seconds) expires, avoiding race conditions caused by concurrent order pushes.

[0144] The specific implementation process of this embodiment will be described in detail below with reference to examples, and may include the following:

[0145] First, the system retrieves the current GPS coordinates and speed vectors of 28 drivers from the target driver set via Redis streaming pipeline, and submits them along with the WGS-84 coordinates of the order origin to the route estimation service. The service uses a dynamic graph neural network to retrieve three alternative routes for each driver and calculates the predicted arrival time for each. Taking driver DRV-53701 as an example, the three routes have travel times of 290s, 315s, and 330s respectively. The system takes the shortest value, 290s, as the driver's real-time travel time. This process is completed in parallel within a single batch of requests, with a total time of 220ms.

[0146] Furthermore, the system calculates the priority score according to the formula Priority = α·T + β·(1-P), where T is the normalized real-time travel time, P is the historical order acceptance response probability, and α and β are set to 0.7 and 0.3 respectively through offline parameter tuning. Taking DRV-53701 as an example, T is normalized to 0.38, P is 0.92, and Priority = 0.7 × 0.38 + 0.3 × 0.08 ≈ 0.29. The system performs the same calculation for 28 drivers, forming a set of <driver identifier, Priority> in memory.

[0147] Furthermore, the system sorts the Priority drivers in ascending order, selects the first driver (DRV-53701), generates a lease token (TOKEN-9F2E) and writes it to the lease table, setting an 8-second validity period. Simultaneously, it sends an "Accept Order Now" command to the driver via the gRPC push interface. If the driver returns an ACK within 8 seconds, the lease table marks the token as complete, and the order is successfully dispatched. If no ACK is received within the timeout period, the lease service automatically releases the token, and the scheduling engine selects the next driver according to the sorting order and repeats the lease and push process until the order is accepted or all drivers have tried. If no one accepts the order after iterating through the target set, the system triggers a fallback strategy, re-executes the discount expansion, filters a new target driver set, and dispatches the order again.

[0148] Furthermore, after a successful order acceptance, the system records fields such as <order ID, driver ID, predicted arrival time, and actual arrival time>, and writes the driver's order acceptance result into the incremental sample queue, providing data for the subsequent online updates of the discount preference model and route estimation model.

[0149] By leveraging the high-precision arrival time prediction provided by the dynamic graph neural network path estimation service, the priority ranking combined with historical response probabilities, and the reliable order push with transaction lease guarantees, this embodiment achieves driver sorting and order dispatch within seconds during urban peak hours, significantly reducing passenger waiting time and improving the one-time order dispatch success rate.

[0150] The following are embodiments of the apparatus described in this application, which can be used to execute the embodiments of the method described in this application. For details not disclosed in the apparatus embodiments of this application, please refer to the embodiments of the method described in this application.

[0151] Figure 3 This is a schematic diagram of the structure of the ride-hailing order allocation device based on driver preferences provided in an embodiment of this application. Figure 3 As shown, the ride-hailing order allocation device based on driver preferences includes:

[0152] The acquisition module 301 is used to obtain real-time orders through the ride-hailing platform interface, parse the real-time orders to obtain the order start coordinates, order end coordinates and discount flags, and unify the order start coordinates and order end coordinates into the same geographic coordinate system;

[0153] The generation module 302 is used to retrieve online drivers by calling a spatial index within a set radius, centered on the order's starting point coordinates, and generate a candidate driver set;

[0154] The reading module 303 is used to read the vehicle type information and order acceptance preferences of each driver in the candidate driver set. The order acceptance preferences include regional preferences based on map fences, route preferences based on trip corridors, and minimum discount thresholds.

[0155] The filtering module 304 is used to perform multi-condition filtering on the candidate driver set based on the order destination coordinates, discount flags and order acceptance preferences to obtain the target driver set that meets the order acceptance conditions. In this process, a mapping relationship between the discount level and the order acceptance preference intensity is established, and the minimum discount threshold is dynamically adjusted according to the mapping relationship during the multi-condition filtering process.

[0156] The dispatch module 305 is used to sort the target driver set according to the real-time distance from the driver to the order origin, select the driver with the shortest distance, and dispatch the current real-time order to the selected driver.

[0157] In some embodiments, Figure 3 The acquisition module 301 receives real-time order data streams through an asynchronous interface based on a message queue, and calls the field recognition model to extract the start coordinate field, end coordinate field, and discount field; it determines the coordinate system to which each coordinate field belongs based on the coordinate system identifier carried by each coordinate field or through a coordinate format recognition algorithm, and converts the start coordinate field and end coordinate field to a preset intermediate reference coordinate system respectively; it calls multi-source map reference information to convert the start coordinates and end coordinates under the intermediate reference coordinate system to the target unified coordinate system coordinates, and records the conversion index for subsequent spatial retrieval calls.

[0158] In some embodiments, Figure 3The generation module 302 uses a spatial indexing algorithm to map the order starting coordinates to the first index unit number; it obtains a set of target index units adjacent to the first index unit number within a preset level range, and traverses them sequentially in order from nearest to farthest; it reads the driver identifiers in each target index unit whose most recent heartbeat time has not exceeded the threshold and who are online, and accumulates them to form a first driver set; when the number of the first driver set is less than the preset candidate threshold, it raises the spatial index level to expand the target index unit set, and repeats the reading and accumulation operations until a second driver set that meets the preset candidate threshold is obtained; it sets the second driver set as the candidate driver set, and writes the candidate driver set and the corresponding index unit number into distributed memory for subsequent calls.

[0159] In some embodiments, Figure 3 The reading module 303 stores vehicle type information and order-acceptance preference fingerprint vectors using the driver profile microservice with the driver identifier as the primary key, and updates the vehicle type information and order-acceptance preference fingerprint vectors in real time using an incremental synchronization mechanism; it initiates parallel asynchronous queries on the candidate driver set in batches, and returns the corresponding vehicle type information and order-acceptance preference fingerprint vectors from the driver profile microservice; it inputs the order-acceptance preference fingerprint vectors into a hierarchical hash mapping model, decodes them to obtain the regional preference fence parameters, the route preference corridor parameters, and the minimum discount threshold, and writes them together with the vehicle type information into a temporary cache associated with the corresponding driver identifier.

[0160] In some embodiments, Figure 3 The filtering module 304 encodes vehicle type information, regional preference compliance, route preference compliance, and dynamically adjusted discount compliance into a multi-dimensional constraint vector; it calls the Boolean rule matching engine to perform parallel matching on each multi-dimensional constraint vector, eliminating drivers that do not meet the constraints in any dimension, and obtaining a first target driver subset; when the number of the first target driver subset is lower than a preset threshold, it relaxes the discount compliance constraint according to the discount expansion strategy and re-executes the Boolean rule matching to generate a second target driver subset; it merges the first target driver subset and the second target driver subset to form a target driver set, and writes the target driver set into a variable proximity index for subsequent sorting calls.

[0161] In some embodiments, Figure 3The filtering module 304 collects drivers' order acceptance feedback and corresponding order acceptance preference strength in historical orders for different discount orders, and constructs a discount preference training sample set; it uses a regression algorithm to train the discount preference training sample set to obtain a discount preference mapping model with order acceptance preference strength as input and discount level as output; when performing multi-condition filtering, it obtains the order acceptance preference strength of candidate drivers, inputs the order acceptance preference strength into the discount preference mapping model to obtain the target discount level, and sets the target discount level as the minimum discount threshold for candidate drivers; after the order allocation is completed, it writes the drivers' real-time order acceptance feedback into the incremental sample queue, and updates the discount preference mapping model online according to a preset time window.

[0162] In some embodiments, Figure 3 The dispatch module 305 subscribes to real-time traffic flow data through a path estimation service based on a dynamic graph neural network and obtains the current location of each driver in the target driver set. It calls the path estimation service to generate multiple alternative driving routes between the driver's current location and the order's starting coordinates for each driver. It calculates the predicted arrival time of each alternative driving route based on the real-time traffic flow data and sets the shortest predicted arrival time as the driver's real-time travel time. It calculates a priority score based on the real-time travel time and the driver's historical order acceptance probability, sorts the target driver set according to the priority score from smallest to largest, and selects the first driver. It locks the first driver with a transaction lease and sends a real-time order. If no order acceptance confirmation is received from the first driver within the preset response window, the transaction lease is automatically released, and the real-time order is pushed to the next driver in the sorted order until the real-time order is accepted or the target driver set has been traversed.

[0163] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0164] Figure 4 This is a schematic diagram of the structure of the electronic device 4 provided in an embodiment of this application. Figure 4 As shown, the electronic device 4 of this embodiment includes a processor 401, a memory 402, and a computer program 403 stored in the memory 402 and executable on the processor 401. When the processor 401 executes the computer program 403, it implements the steps in the various method embodiments described above. Alternatively, when the processor 401 executes the computer program 403, it implements the functions of each module / unit in the various device embodiments described above.

[0165] For example, computer program 403 may be divided into one or more modules / units, which are stored in memory 402 and executed by processor 401 to complete this application. The one or more modules / units may be a series of computer program instruction segments capable of performing a specific function, which describe the execution process of computer program 403 in electronic device 4.

[0166] Electronic device 4 can be a desktop computer, laptop, handheld computer, cloud server, or other electronic device. Electronic device 4 may include, but is not limited to, processor 401 and memory 402. Those skilled in the art will understand that... Figure 4 This is merely an example of electronic device 4 and does not constitute a limitation on electronic device 4. It may include more or fewer components than shown, or combine certain components, or different components. For example, electronic device may also include input / output devices, network access devices, buses, etc.

[0167] Processor 401 can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor can be a microprocessor or any conventional processor.

[0168] The memory 402 can be an internal storage unit of the electronic device 4, such as a hard disk or RAM. The memory 402 can also be an external storage device of the electronic device 4, such as a plug-in hard disk, Smart Media Card (SMC), Secure Digital (SD) card, or Flash Card. Furthermore, the memory 402 can include both internal and external storage units of the electronic device 4. The memory 402 is used to store computer programs and other programs and data required by the electronic device. The memory 402 can also be used to temporarily store data that has been output or will be output.

[0169] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is merely an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiments can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit. Furthermore, the specific names of the functional units and modules are only for easy differentiation and are not intended to limit the scope of protection of this application. The specific working process of the units and modules in the above system can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0170] In the above embodiments, the descriptions of each embodiment have different focuses. For parts that are not described in detail or recorded in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0171] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0172] In the embodiments provided in this application, it should be understood that the disclosed apparatus / computer devices and methods can be implemented in other ways. For example, the apparatus / computer device embodiments described above are merely illustrative. For instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. Multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces, and the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0173] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0174] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0175] If integrated modules / units are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, all or part of the processes in the methods of the above embodiments can also be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program may include computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. Computer-readable media may include: any entity or device capable of carrying computer program code, recording media, USB flash drives, portable hard drives, magnetic disks, optical disks, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunication signals, and software distribution media, etc.

[0176] The above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although the technical solutions of this application have been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.

Claims

1. A method for allocating ride-hailing orders based on driver preferences, characterized in that, include: Real-time orders are obtained using the ride-hailing platform interface. The real-time orders are parsed to obtain the order origin coordinates, order destination coordinates, and discount flags. The order origin coordinates and order destination coordinates are then unified into the same geographic coordinate system. Using the order origin coordinates as the center, a spatial index is used to retrieve online drivers within a set radius to generate a candidate driver set; Read the vehicle type information and order-accepting preferences of each driver in the candidate driver set. The order-accepting preferences include region preferences based on map fences, route preferences based on trip corridors, and minimum discount thresholds. Based on the order destination coordinates, discount markers, and order acceptance preferences, the candidate driver set is filtered under multiple conditions to obtain a target driver set that meets the order acceptance conditions. In this process, a mapping relationship between discount level and order acceptance preference intensity is established, and the minimum discount threshold is dynamically adjusted according to the mapping relationship during the multi-condition filtering process. The target driver set is sorted according to the real-time distance from the driver to the order origin, the driver with the shortest distance is selected, and the current real-time order is assigned to the selected driver; The step of reading the vehicle type information and order-accepting preferences of each driver in the candidate driver set includes: The driver profiling microservice stores vehicle type information and order acceptance preference fingerprint vectors with driver identifiers as the primary key, and uses an incremental synchronization mechanism to update the vehicle type information and order acceptance preference fingerprint vectors in real time. Parallel asynchronous queries are initiated in batches for the candidate driver set, and the corresponding vehicle type information and order acceptance preference fingerprint vector are returned from the driver profile microservice. The order acceptance preference fingerprint vector is input into a hierarchical hash mapping model to decode the area preference fence parameters, the route preference corridor parameters, and the minimum discount threshold, and written into a temporary cache associated with the corresponding driver identifier along with the vehicle type information. The process of establishing a mapping relationship between discount levels and order acceptance preference intensity, and dynamically adjusting the minimum discount threshold based on the mapping relationship during multi-condition filtering, includes: Collect drivers' feedback on accepting orders with different discounts in historical orders and the corresponding order acceptance preference strength to construct a discount preference training sample set; The discount preference training sample set is trained using a regression algorithm to obtain a discount preference mapping model with order acceptance preference intensity as input and discount level as output. When performing multi-condition filtering, the order acceptance preference intensity of the candidate driver is obtained, the order acceptance preference intensity is input into the discount preference mapping model to obtain the target discount level, and the target discount level is set as the minimum discount threshold of the candidate driver. After the order allocation is completed, the driver's real-time order acceptance feedback is written into the incremental sample queue, and the discount preference mapping model is updated online according to the preset time window.

2. The method according to claim 1, characterized in that, The process of obtaining real-time orders using the ride-hailing platform interface, parsing the real-time orders to obtain the order origin coordinates, order destination coordinates, and discount flags, and unifying the order origin coordinates and order destination coordinates to the same geographic coordinate system includes: Real-time order data streams are received via an asynchronous interface based on a message queue, and the field recognition model is called to extract the starting coordinate field, the ending coordinate field, and the discount field. The coordinate system to which each coordinate field belongs is determined based on the coordinate system identifier carried by each coordinate field or through a coordinate format recognition algorithm, and the starting point coordinate field and the ending point coordinate field are respectively converted to a preset intermediate reference coordinate system; The multi-source map reference information is invoked to convert the starting point coordinates and ending point coordinates under the intermediate reference coordinate system into the target unified coordinate system coordinates, and the conversion index is recorded for subsequent spatial retrieval.

3. The method according to claim 1, characterized in that, The step of retrieving online drivers by calling a spatial index within a set radius, centered on the order's origin coordinates, and generating a candidate driver set includes: The spatial indexing algorithm is used to map the order's starting coordinates to the first index unit number; Within a preset hierarchical range, obtain a set of target index units adjacent to the first index unit number, and traverse them sequentially in order from nearest to farthest. Read the driver identifiers in each target index unit whose most recent heartbeat time has not exceeded the threshold and who are online, and accumulate them to form a first driver set; When the number of the first driver set is less than the preset candidate threshold, the spatial index level is increased to expand the target index unit set, and the read and accumulation operations are repeated until a second driver set that meets the preset candidate threshold is obtained. The second driver set is set as the candidate driver set, and the candidate driver set and its corresponding index unit number are written into distributed memory for subsequent use.

4. The method according to claim 1, characterized in that, The process of filtering the candidate driver set based on the order destination coordinates, discount markers, and order acceptance preferences to obtain a target driver set that meets the order acceptance criteria includes: The vehicle type information, regional preference compliance, route preference compliance, and dynamically adjusted discount compliance are encoded into a multi-dimensional constraint vector; The Boolean rule matching engine is invoked to perform parallel matching on each multidimensional constraint vector, eliminating drivers who do not meet the constraints in any dimension, and obtaining the first target driver subset; When the number of the first target driver subset is less than a preset threshold, the discount compliance constraint is relaxed according to the discount expansion strategy, and the Boolean rule matching is re-executed to generate a second target driver subset; The first target driver subset and the second target driver subset are merged to form the target driver set, and the target driver set is written into the variable proximity index for subsequent sorting calls.

5. The method according to claim 1, characterized in that, The step of sorting the target driver set according to the real-time distance from the driver to the order origin, selecting the driver with the shortest distance, and assigning the current real-time order to the selected driver includes: The path estimation service based on dynamic graph neural network subscribes to real-time traffic flow data and obtains the current location of each driver in the target driver set. The route estimation service is invoked to generate multiple alternative driving routes between the driver's current location and the coordinates of the order's origin for each driver. The predicted arrival time of each alternative driving route is calculated in conjunction with the real-time traffic flow data, and the shortest predicted arrival time is set as the driver's real-time travel time. Calculate a priority score based on the real-time travel time and the driver's historical order acceptance probability, sort the target driver set in ascending order of priority score, and select the first driver. The first driver is locked in a transaction lease and the real-time order is sent. If the first driver does not accept the order within the preset response window, the transaction lease is automatically released and the real-time order is pushed to the next driver in sorting order until the real-time order is accepted or the target driver set is traversed.

6. A ride-hailing order allocation device based on driver preferences, characterized in that, include: The acquisition module is used to obtain real-time orders using the ride-hailing platform interface, parse the real-time orders to obtain the order start coordinates, order end coordinates and discount flags, and unify the order start coordinates and order end coordinates to the same geographic coordinate system; The generation module is used to retrieve online drivers by calling a spatial index within a set radius, centered on the coordinates of the order's starting point, and generate a set of candidate drivers; The reading module is used to read the vehicle type information and order-accepting preferences of each driver in the candidate driver set. The order-accepting preferences include regional preferences based on map fences, route preferences based on trip corridors, and minimum discount thresholds. The filtering module is used to perform multi-condition filtering on the candidate driver set based on the order destination coordinates, discount flags and order acceptance preferences to obtain a target driver set that meets the order acceptance conditions. The module establishes a mapping relationship between discount level and order acceptance preference intensity and dynamically adjusts the minimum discount threshold according to the mapping relationship during the multi-condition filtering process. The dispatch module is used to sort the target driver set according to the real-time distance from the driver to the order origin, select the driver with the shortest distance, and dispatch the current real-time order to the selected driver; The reading module is used to store vehicle type information and order-acceptance preference fingerprint vectors using the driver profile microservice with the driver identifier as the primary key, and to update the vehicle type information and order-acceptance preference fingerprint vectors in real time using an incremental synchronization mechanism; it initiates parallel asynchronous queries on the candidate driver set in batches, and returns the corresponding vehicle type information and order-acceptance preference fingerprint vectors from the driver profile microservice; it inputs the order-acceptance preference fingerprint vectors into a hierarchical hash mapping model, decodes them to obtain the regional preference fence parameters, the route preference corridor parameters, and the minimum discount threshold, and writes them together with the vehicle type information into a temporary cache associated with the corresponding driver identifier; The filtering module is used to collect drivers' order acceptance feedback for different discount orders in historical orders and the corresponding order acceptance preference intensity to construct a discount preference training sample set; the discount preference training sample set is trained using a regression algorithm to obtain a discount preference mapping model with order acceptance preference intensity as input and discount level as output; when performing multi-condition filtering, the order acceptance preference intensity of candidate drivers is obtained, the order acceptance preference intensity is input into the discount preference mapping model to obtain the target discount level, and the target discount level is set as the minimum discount threshold for the candidate drivers; after the order allocation is completed, the real-time order acceptance feedback of drivers is written into the incremental sample queue, and the discount preference mapping model is updated online according to a preset time window.

7. An electronic device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the method as described in any one of claims 1 to 5.

8. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method as described in any one of claims 1 to 5.

Images