Order ranking method, system, device and storage medium based on hierarchical evaluation

Abstract

This invention provides a hierarchical evaluation-based order ranking method, system, device, and storage medium. The method includes: generating an initial candidate set based on order business sub-scenarios; loading independently configurable constraint check chains for corresponding business sub-scenarios, performing compliance checks and coarse filtering on candidate resource nodes to obtain a compliant candidate set; adopting a hierarchical evaluation architecture of major categories and sub-items, unifying the dimensions of each evaluation sub-item, aggregating them into a major category score, then matching a preset weight configuration group based on order scenario characteristics for major category weighting to obtain a comprehensive score, and further adding adjustment values ​​through configurable post-adjustment rules to obtain the final score; finally, outputting a ranked list according to configurable multi-key ranking rules. This invention achieves hierarchical management of evaluation indicators, decoupling of checking and ranking logic, adaptive ranking strategies for different scenarios, and flexible and configurable post-adjustment, significantly improving the maintainability, flexibility, and configurability of the ranking system.

Description

Technical Field

[0001] This invention relates to the field of resource scheduling, and more specifically, to an order sorting method, system, device, and storage medium based on hierarchical evaluation. Background Technology

[0002] With the rapid development of internet technology, online service platforms (such as ride-hailing, instant delivery, and home services) have become an important part of people's daily lives. One of the core tasks of these platforms is to quickly and accurately match the most suitable resources from a massive pool of candidate resources (e.g., available drivers, delivery personnel, service providers, etc., hereinafter collectively referred to as "resource nodes") for each newly generated user order, and to complete the scheduling decision. This process is usually called order scheduling or resource allocation, and its core element is order ranking, which involves ranking a batch of candidate resource nodes according to their merits to determine which one to assign the order to.

[0003] Currently, mainstream order scheduling and ranking schemes generally adopt a "flat weighted scoring" architecture. The typical implementation of this architecture is as follows: A series of evaluation features related to scheduling decisions are predefined, such as the distance to resource nodes, service rating, order acceptance rate, and working time. Then, a fixed weight coefficient is assigned to each feature. During ranking, for each candidate resource node, the values ​​of all its features are standardized, and then linearly weighted and summed according to the predetermined weight coefficients to obtain a comprehensive score. Finally, all candidate nodes are ranked based on this comprehensive score, and the one with the highest score is the optimal choice.

[0004] Although this flat weighted scoring scheme is relatively simple and straightforward to implement, its inherent technical shortcomings are becoming increasingly apparent as business complexity continues to increase. These shortcomings are mainly manifested in the following aspects: (1) The evaluation indicators lack a hierarchical structure, making it difficult to manage business dimensions in a unified manner. In the existing scheme, all evaluation features are spread out and weighted. When there are many features (dozens), the indicators of different business dimensions (such as efficiency, quality, and matching degree) are mixed at the same level. This not only fails to clearly express the hierarchical relationship of business evaluation, but also makes it necessary to modify the weight of each feature item one by one to adjust the overall weight of a certain business dimension. This results in high maintenance costs and is prone to configuration inconsistencies.

[0005] (2) The coupling of compliance constraint checks and fine-grained scoring results in high rule iteration costs. Existing solutions typically mix "whether it complies with business constraints" (such as hard filtering conditions like the validity of resource node status and capability matching) with "score level" into the same processing logic. The coupling of these two types of logic means that the overall scoring logic needs to be modified when the constraint rules change. Furthermore, if different business sub-scenarios (such as system assignment, active order grabbing, etc.) need to maintain their own independent constraint sets, the implementation cost is high under the existing architecture.

[0006] (3) The ranking strategy is static and fixed, and cannot be differentiated in different business scenarios. The weight coefficients of the existing solutions are usually statically set in the code or configuration and are globally unique. When different scenarios (such as time-sensitive scenarios and quality-priority scenarios) require completely different ranking preferences, they cannot be dynamically switched under the same scoring framework. Multiple independent ranking logics must be maintained.

[0007] (4) Lack of post-adjustment capability, and specific business preferences cannot be decoupled and superimposed with the underlying score. The comprehensive score of the existing solution is the final ranking basis once it is calculated. It does not support the superposition of business-level priority intervention based on the specific attribute combination relationship between the order and the resource node (such as the matching of specific tags of both parties) after the score is completed, which makes it difficult to flexibly introduce dynamic strategies at the operational level.

[0008] Existing order scheduling and sorting schemes have significant shortcomings in handling complex business logic, supporting differentiated strategies for multiple scenarios, and reducing system maintenance costs. There is an urgent need for a more advanced, flexible, and configurable sorting architecture to solve these problems.

[0009] In view of this, the present invention provides an order sorting method, system, device and storage medium based on hierarchical evaluation. Summary of the Invention

[0010] In view of the problems in the prior art, the purpose of this invention is to provide an order sorting method, system, device and storage medium based on hierarchical evaluation, which overcomes the difficulties of the prior art and can overcome the defects of the prior art such as chaotic management of evaluation indicators, coupling of inspection and scoring logic, inability of sorting strategy to adapt to scenarios and lack of flexible post-adjustment capability.

[0011] Embodiments of the present invention provide an order ranking method based on hierarchical evaluation, comprising the following steps: S110. Receive an order request, determine the corresponding business sub-scenario based on its business attributes, and recall one or more resource nodes from the resource pool based on the business sub-scenario to generate an initial candidate set. S120. Load the corresponding constraint check chain according to the business sub-scenario. The constraint check chain contains at least one constraint checker. Use the constraint checker in sequence to perform compliance checks on each resource node in the initial candidate set. Filter and remove resource nodes that fail to pass the check of any constraint checker from the initial candidate set to obtain a compliance candidate set. S130. Perform a hierarchical evaluation on each resource node in the compliance candidate set and calculate the final score; and S140. Based on the configurable multi-key sorting rules, all resource nodes in the compliance candidate set are stably sorted according to their final scores, and the sorted list of resource nodes is output.

[0012] Preferably, in step S120, the constraint check chain includes a pre-filter checker based on a business quantitative indicator threshold, which is used to filter resource nodes that do not meet the conditions according to the preset indicator threshold before entering the sorting layer, so as to compress the size of the candidate set; the composition of the constraint check chain, the execution order of each constraint checker and the activation status are all configured independently by the configuration center according to the business sub-scenario.

[0013] Preferably, step S130 includes: S131. Obtain the hierarchical evaluation configuration corresponding to the business sub-scenario. The hierarchical evaluation configuration divides multiple evaluation sub-items into at least one evaluation category. Each evaluation category contains at least one evaluation sub-item. The configuration also configures a weight and dimension unification method for each evaluation sub-item. S132. For each evaluation category, according to the dimension unification method configured for each evaluation sub-item, the original values ​​of resource nodes on each evaluation sub-item are converted into dimension unification scores, and the scores are obtained by weighted summation according to the weight of each evaluation sub-item. S133. Based on the scenario characteristics of the order request, a target weight configuration group is matched from multiple preset weight configuration groups. The target weight configuration group defines the weight of each evaluation category. The scores of each evaluation category are weighted and summed according to the weights in the target weight configuration group to obtain a comprehensive score. S134. Adjust the comprehensive score according to the configurable set of adjustment rules to obtain the final score, wherein each adjustment rule defines a trigger condition and a corresponding numerical adjustment value.

[0014] Preferably, the dimension unification method in step S132 is one of a variety of dimension unification algorithms implemented by the registration-based processor factory. The variety of dimension unification algorithms include linear interval mapping, logarithmic transformation interval mapping, ranking position mapping, and segmented threshold mapping. The dimension unification method and its parameters for each evaluation sub-item are configured independently through the configuration center.

[0015] Preferably, the weight configuration group in step S133 is one of multiple weight configuration groups pre-configured and stored in the configuration center. Each weight configuration group corresponds to a business scenario and defines the weights of each evaluation category under that scenario. The mapping relationship between the scenario characteristics of the order request and the target weight configuration group is configured through the configuration center.

[0016] Preferably, the set of adjustment rules in step S134 includes at least one adjustment rule, and the triggering condition of each adjustment rule is defined based on the combination relationship between order attributes and resource node attributes; the set of adjustment rules is configured through the configuration center, and when multiple rules meet the triggering condition, their corresponding adjustment values ​​are calculated by superposition.

[0017] Preferably, the multi-key sorting rule in step S140 defines a set of ordered sorting keys, each sorting key specifying the source of the value and the sorting direction; when the values ​​of high-priority sorting keys are the same, the sorting keys of the next lower priority are compared in turn to determine the final order; the multi-key sorting rule is configured independently by the configuration center according to the business sub-scenario.

[0018] Embodiments of the present invention also provide an order sorting system based on hierarchical evaluation, used to implement the above-described order sorting method based on hierarchical evaluation, wherein the order sorting system based on hierarchical evaluation includes: The request recall module receives an order request, determines the corresponding business sub-scenario based on its business attributes, and recalls one or more resource nodes from the resource pool based on the business sub-scenario to generate an initial candidate set. The constraint filtering module loads the corresponding constraint check chain according to the business sub-scenario. The constraint check chain contains at least one constraint checker. The constraint checker is used in sequence to perform compliance checks on each resource node in the initial candidate set. Resource nodes that fail to pass the check by any constraint checker are filtered out and removed from the initial candidate set to obtain a compliant candidate set. The tiered evaluation module performs a tiered evaluation on each resource node in the compliance candidate set and calculates the final score; and The sorting output module performs a stable sorting of all resource nodes in the compliant candidate set according to their final scores based on configurable multi-key sorting rules, and outputs a sorted list of resource nodes.

[0019] Embodiments of the present invention also provide an order sorting device based on hierarchical evaluation, comprising: processor; A memory in which executable instructions of the processor are stored; The processor is configured to perform the steps of the hierarchical evaluation-based order sorting method described above by executing the executable instructions.

[0020] Embodiments of the present invention also provide a computer-readable storage medium for storing a program that, when executed, implements the steps of the order sorting method based on hierarchical evaluation described above.

[0021] The purpose of this invention is to provide an order sorting method, system, device, and storage medium based on hierarchical evaluation. It decomposes the order scheduling and sorting process into three decoupled stages: recall, inspection, and sorting. The sorting stage employs a multi-dimensional hierarchical evaluation architecture and supports a configurable sorting method and system with scenario-adaptive weight switching, post-adjustment, and multi-key sorting rules. Compared with existing technologies, the technical solution of this invention enables hierarchical management of evaluation indicators, complete decoupling of inspection and sorting logic, scenario-adaptive switching of sorting strategies, and flexible introduction of operational intervention. Thus, without modifying the code, sorting effects according to any business preference can be achieved through configuration, significantly improving the maintainability, flexibility, and scalability of the sorting system. Attached Figure Description

[0022] Other features, objects, and advantages of the invention will become more apparent from the following detailed description of non-limiting embodiments with reference to the accompanying drawings.

[0023] Figure 1 This is a flowchart of the hierarchical evaluation-based order sorting method of the present invention.

[0024] Figure 2 This is a schematic diagram of the processing flow for implementing the hierarchical evaluation-based order sorting method of the present invention.

[0025] Figure 3 This is a schematic diagram of the recall layer structure according to an embodiment of the present invention.

[0026] Figure 4 This is a schematic diagram of a configurable constraint check chain structure for the check layer according to an embodiment of the present invention.

[0027] Figure 5 This is a schematic diagram of a sorting layer hierarchical scoring calculation structure according to an embodiment of the present invention.

[0028] Figure 6 This is a schematic diagram of the post-adjustment module and multi-key sorting rules according to an embodiment of the present invention.

[0029] Figure 7 This is a system architecture diagram of the order sorting system based on hierarchical evaluation of the present invention.

[0030] Figure 8 This is a schematic diagram of the order sorting device based on hierarchical evaluation according to the present invention.

[0031] Figure 9 This is a schematic diagram of the structure of a computer-readable storage medium according to an embodiment of the present invention. Detailed Implementation

[0032] The following specific examples illustrate the implementation of this application. Those skilled in the art can easily understand the other advantages and effects of this application from the content disclosed herein. This application can also be implemented or applied through other different specific embodiments. Various details in this application can also be modified or changed according to different viewpoints and application systems without departing from the spirit of this application. It should be noted that, in the absence of conflict, the embodiments and features in the embodiments of this application can be combined with each other. The following detailed description of the embodiments of this application is based on the accompanying drawings to enable those skilled in the art to easily implement it. This application can be embodied in many different forms and is not limited to the embodiments described herein.

[0033] Figure 1 This is a flowchart of the hierarchical evaluation-based order sorting method of the present invention. Figure 1 As shown, an embodiment of the present invention provides an order ranking method based on hierarchical evaluation, including the following steps: S110. Receive an order request, determine the corresponding business sub-scenario based on its business attributes, and recall one or more resource nodes from the resource pool based on the business sub-scenario to generate an initial candidate set.

[0034] S120. Load the corresponding constraint check chain according to the business sub-scenario. The constraint check chain contains at least one constraint checker. Use the constraint checker in sequence to perform compliance checks on each resource node in the initial candidate set. Filter and remove resource nodes that fail to pass the check of any constraint checker from the initial candidate set to obtain a compliant candidate set.

[0035] S130. Perform a tiered evaluation on each resource node in the compliance candidate set and calculate the final score.

[0036] S140. Based on configurable multi-key sorting rules, all resource nodes in the compliance candidate set are stably sorted according to their final scores, and the sorted resource node list is output. This invention enables independent management and overall adjustment of indicators across different business dimensions by organizing evaluation indicators into a configurable hierarchical structure. It decouples compliance constraint checks from the scoring logic and supports independent configuration of constraint rule sets according to business sub-scenarios. By implementing differentiated category weight allocations for different scenarios within the same scoring framework through configuration, multiple sets of sorting logics are eliminated. A configurable post-adjustment mechanism is introduced in addition to the comprehensive scoring to support dynamic priority intervention at the business level. Ultimately, this results in a highly flexible, configurable, and easily iterative order scheduling and sorting scheme.

[0037] In a preferred embodiment, in step S120, the constraint check chain includes a pre-filter checker based on business quantitative indicator thresholds. This pre-filter filters resource nodes that do not meet the conditions according to preset indicator thresholds before entering the ranking layer, thereby compressing the candidate set size. The composition of the constraint check chain, the execution order of each constraint checker, and their activation status are all configured independently by the configuration center according to business sub-scenarios. The constraint check chain not only includes a basic compliance checker but also integrates a pre-filter checker based on business quantitative indicator thresholds. This checker can be configured with multiple indicator thresholds, for example, simultaneously filtering drivers with "service score < 4.5" and "order acceptance rate < 70%" to form a combined filtering condition. Furthermore, to cope with high-concurrency scenarios, the execution logic of this pre-filter checker is designed to be parallelizable. The system will shard the initial candidate set and start multiple worker threads to concurrently execute the pre-filter check. After all shard checks are completed, the results are merged. This parallel design reduces the time spent on multi-threshold coarse-ranking filtering on a million-level candidate set from seconds to milliseconds. Meanwhile, to ensure the robustness of the inspection chain, each inspector incorporates a fault isolation chamber and a timeout circuit breaker mechanism. When an inspector (such as a conflict detector that relies on external services) times out or throws an exception, the system processes it according to a preset degradation strategy (such as "pass," "reject," or "judgment based on cached results"), preventing a single inspector's failure from blocking the entire inspection chain and thus ensuring the system's high availability. By introducing parallel processing and fault isolation mechanisms, this embodiment not only achieves flexible pre-filtering based on multiple indicator combinations but also effectively addresses the challenges of high concurrency and unstable dependent services. Specifically, on the one hand, the parallel design significantly improves the processing efficiency of the inspection layer, enabling rapid screening of large-scale candidate sets. On the other hand, the fault isolation chamber and timeout circuit breaker mechanism ensure that exceptions from a single inspector do not cascade and spread, avoiding blocking the entire scheduling process, thereby significantly improving the overall robustness and availability of the system and ensuring the stable operation of the core scheduling service.

[0038] In a preferred embodiment, step S130 includes: S131. Obtain the hierarchical evaluation configuration corresponding to the business sub-scenario. The hierarchical evaluation configuration divides multiple evaluation sub-items into at least one evaluation category. Each evaluation category contains at least one evaluation sub-item, and configures a weight and dimension unification method for each evaluation sub-item.

[0039] S132. For each evaluation category, according to the dimension unification method configured for each evaluation sub-item, the original values ​​of resource nodes on each evaluation sub-item are converted into dimension unification scores, and the scores are obtained by weighted summation according to the weight of each evaluation sub-item.

[0040] S133. Based on the scenario characteristics of the order request, match the target weight configuration group from multiple preset weight configuration groups. The target weight configuration group defines the weight of each evaluation category. The scores of each evaluation category are weighted and summed according to the weight in the target weight configuration group to obtain the comprehensive score.

[0041] S134. Adjust the overall score according to the set of configurable adjustment rules to obtain the final score, where each adjustment rule defines the triggering condition and the corresponding numerical adjustment value.

[0042] In a preferred embodiment, the dimension unification method in step S132 is one of several dimension unification algorithms implemented through the registration-based processor factory. These algorithms include linear interval mapping, logarithmic transformation interval mapping, ranking position mapping, and segmented threshold mapping. The dimension unification method and its parameters for each evaluation sub-item are configured independently through the configuration center. To address more complex business scenarios, the registration-based processor factory not only supports basic algorithms but also allows developers to register custom complex algorithms. For example, for the "pickup time" indicator, a "step-decay function" can be registered, setting an expected value (e.g., 3 minutes). A perfect score is awarded within 3 minutes, and the score decreases exponentially after 3 minutes, severely penalizing excessively long pick-up times. This custom function more accurately reflects the subtle business psychology of "faster is better, but too slow is completely unacceptable." Furthermore, to ensure the fairness and timeliness of dimension unification, the system introduces an adaptive boundary calculation mechanism. Traditional linear mapping typically uses globally fixed maximum / minimum values, which can lead to distortion of the mapping results when data distribution changes. In this embodiment, the system dynamically calculates the actual maximum and minimum values ​​of each sub-item based on the real-time data distribution of the current candidate set (for example, taking the 95th percentile as the maximum value to eliminate the influence of extreme outliers). For example, for "pickup distance," if drivers in the current candidate set are generally farther away, with a global maximum distance of 10 kilometers, and the dynamically calculated 95th percentile is 8 kilometers, then the score for a driver with a distance of 7 kilometers will no longer be 0.7, but rather (7-0) / (8-0) = 0.875, which better reflects their relative merit in the current candidate set. By supporting custom complex mapping functions and introducing adaptive boundaries, this embodiment greatly improves the accuracy of dimensional unification and scenario adaptability. On the one hand, custom functions allow product managers and operations personnel to directly encode complex, non-linear business intuitions into mathematical rules, enabling sub-item scores to more realistically reflect the business's actual preference for indicators. On the other hand, the adaptive boundary calculation mechanism ensures that the dimensional unification results are always based on the latest and most relevant data distribution, avoiding evaluation distortion caused by global static boundaries. This allows the resource node's score to reflect its relative competitive advantage in a specific context in real time and accurately, laying a solid foundation for subsequent precise ranking. Secondly, weighted aggregation within the category is performed. After obtaining the dimensional unification scores of all sub-items, a weighted sum is calculated based on the weights set for each sub-item within the category in the configuration, yielding the "category score" for the resource node. Category score = Σ(sub-item weight × sub-item dimensional unification score).

[0043] In a preferred embodiment, the weight configuration group in step S133 is one of multiple pre-configured weight configuration groups stored in the configuration center. Each weight configuration group corresponds to a business scenario and defines the weights of each evaluation category under that scenario. The mapping relationship between the scenario characteristics of order requests and the target weight configuration group is configured through the configuration center. To achieve smooth switching of weight configurations and A / B testing, the system introduces version control and canary release capabilities for weight configuration groups. Each weight configuration group (such as "time-sensitive priority") can have multiple historical versions (v1.0, v1.1, v2.0). When it is necessary to adjust the weight under a certain scenario, a new version can be created in the configuration center and its effective traffic ratio can be set. For example, 10% of "time-sensitive priority" orders can be configured to use the new weight configuration group v2.0, while the remaining 90% can still use v1.0. The system will automatically perform traffic splitting according to this ratio. After observing that the sorting effect and business indicators (such as order acceptance rate and order completion rate) of the new version meet expectations, the traffic will be gradually expanded to 100%. Furthermore, the mapping relationship between weight configuration groups and order scenario features is no longer a simple static one-to-one. This embodiment supports complex dynamic mapping based on a rule engine. The mapping rule can be configured as follows: "IF order.time tag = 'urgent' AND order.city = 'Beijing' AND current time BETWEEN '18:00' AND '20:00' THEN target weight configuration group = 'time-priority type - evening peak version'". By introducing version control, canary release, and rule engine-based dynamic mapping, this embodiment not only achieves static scenario adaptation but also empowers the system to dynamically and controllably adjust strategies based on real-time data and complex business conditions. The version control and canary release mechanisms make any changes to the weight strategy observable and rollbackable, greatly reducing the possibility of introducing online risks through strategy changes and providing security for the rapid iteration of algorithm strategies. Dynamic mapping based on the rule engine breaks the simple binding of scenarios and strategies, enabling the system to accurately match the most suitable sorting strategy for each order based on real-time information from multiple dimensions such as time, location, and user status. This achieves true "personalized ordering" and refined operations, thereby maximizing overall scheduling efficiency and user satisfaction.

[0044] In a preferred embodiment, the adjustment rule set in step S134 includes at least one adjustment rule, and the triggering condition for each adjustment rule is defined based on the combination relationship between order attributes and resource node attributes. The adjustment rule set is configured through a configuration center, and the corresponding adjustment values ​​of multiple rules are calculated cumulatively when the triggering condition is met. The post-adjustment rule set in step S134 is designed as a highly flexible and controllable rule engine. The adjustment value of each rule can be not only a static value but also a dynamic expression that can reference multi-dimensional attributes of orders and resource nodes for calculation. For example, a rule can be configured: "If the driver attribute 'positive review rate' > 0.98, then the adjustment value = overall score". The system uses a 0.1 value to dynamically add points proportionally. To prevent unexpected extreme values ​​from the superposition of multiple rules, a clamping mechanism with upper and lower limits for adjustment values ​​is introduced for the post-adjustment module. For example, the sum of all adjustment values ​​can be configured not to exceed ±20% of the original comprehensive score. Furthermore, for easier troubleshooting and attribution, each adjustment rule, when triggered, records detailed matching information and the contributed adjustment value in the log, forming a traceable "adjustment chain." This embodiment upgrades the post-adjustment module from a simple scorer to a powerful rule engine. (Dynamic table) The support for Dash allows intervention rules to implement more complex and refined business logic, such as proportional adjustment and linkage with multiple attributes, greatly expanding the design space of operational strategies. The introduction of the clamping mechanism provides a safety boundary for the superimposed adjustment values, preventing score control failures caused by improper rule combinations and ensuring the stability and rationality of the ranking results. The "adjustment link" logging function gives the system extremely high observability and interpretability. When abnormal ranking results occur online, technical personnel can quickly trace back which subsequent rules caused the change in the final score, greatly reducing the difficulty of troubleshooting and strategy debugging.

[0045] In a preferred embodiment, the multi-key sorting rule in step S140 defines a set of ordered sorting keys, each specifying the source of the value and the sorting direction. When the values ​​of high-priority sorting keys are the same, the next-priority sorting keys are compared sequentially to determine the final order. The multi-key sorting rule is configured independently by business sub-scenario through the configuration center. The multi-key sorting rule in step S140 is given more powerful expressive capabilities. To cope with complex sorting requirements, the "value source" of the sorting key can not only be a single score or attribute, but also a composite key composed of multiple values. The system will compare these composite keys lexicographically according to the order of their constituent parts. For example, the first sorting key can be defined as a composite key (driver star rating, final score). The system will first compare the driver star ratings, with the higher star rating ranked first. If the star ratings are the same, the final scores will be compared. This makes it possible to integrate different types of data in a single sorting key. In addition, to ensure the consistency of sorting results across different batches and machines, the multi-key sorting rule mandates that the last sorting key must be a globally unique and stable resource node identifier (such as a driver ID). This ensures that when all business-related sorting keys are the same, the final sorting order is absolutely deterministic, satisfying the requirement of stable sorting. This embodiment, by introducing a composite key mechanism, greatly enhances the expressive power of multi-key sorting rules, allowing seamless integration of discrete attributes (such as star ratings and levels) and continuous scores (such as final scores) in a single sort, achieving more refined and flexible sorting control than traditional multi-key sorting. The mandatory requirement to use a unique identifier as the final sorting key fundamentally guarantees the determinism and reproducibility of the sorting results. This is crucial for scenarios requiring paginated display or where multiple query results must remain consistent, avoiding user experience issues and business logic errors caused by sorting jitter, making the behavior of the entire sorting output module highly stable and predictable.

[0046] The following example uses the driver scheduling and ordering of private car orders on online travel platforms (such as ride-hailing services) as a specific illustration. Figures 2 to 6 The technical solution of the present invention will be described in detail below. Those skilled in the art will understand that this is merely an exemplary application scenario, and the technical solution of the present invention is also applicable to any other online service platform that requires order and resource matching and scheduling, such as logistics delivery and home delivery services.

[0047] Figure 2 This is a schematic diagram illustrating the processing flow of the hierarchical evaluation-based order sorting method of the present invention. For example... Figure 2As shown, the order scheduling and sorting method based on multi-stage hierarchical evaluation of this invention clearly decouples the entire sorting process into three independent stages: Recall, Check, and Sort, collectively referred to as the RCS model. Each stage is executed and configured independently, and all strategy parameters are managed uniformly through a configuration center.

[0048] When the platform receives a user's travel order request, the dispatch system first parses the order information, which includes, but is not limited to, the user's location, destination, expected service time, and service type (such as private car, express car, carpooling). Then, the system determines the corresponding business sub-scenario type based on the order's business attributes, such as "real-time order - system assignment," "real-time order - driver bidding," and "reservation order." After determining the business sub-scenario, the order request sequentially enters the recall layer, inspection layer, and sorting layer for processing, ultimately outputting a sorted list of resource nodes (i.e., drivers). The dispatch decision module then uses this list to complete the final order dispatch operation. Throughout the entire process, the configuration center provides the latest policy parameters to all three stages in real time and supports dynamic parameter updates without requiring service redeployment.

[0049] Figure 3 This is a schematic diagram of the recall layer structure according to an embodiment of the present invention. Figure 3 The detailed structure of the recall layer is shown. The goal of the recall layer is to quickly retrieve a small set of candidates related to the current order from a large, full resource pool after receiving an order request, so as to reduce the computational pressure in the subsequent processing stages.

[0050] Specifically, the system first requests the configuration center to load the recall strategy configuration corresponding to the business sub-scenario determined in step S110. Different business sub-scenarios have their own independent recall strategies. For example, the "real-time order - system assignment" scenario may need to recall all online drivers within 5 kilometers of the order's origin; while the "pre-booked order" scenario may need to recall all drivers expected to appear near the origin before the pre-booked time. The recall strategy configuration includes at least: the identifier of the resource candidate set (such as driver pools of different cities and service types), recall conditions (such as geographical range, online status, and service type), and the upper limit of the number of candidate sets.

[0051] Based on the loaded recall strategy, the system performs a retrieval operation from the corresponding resource candidate set to generate an initial candidate set. This stage aims to "cast a wide net," quickly identifying a batch of potential serviceable resources, laying the foundation for subsequent fine-tuning and ranking. All recall strategies are managed through a configuration center, making it very convenient to adjust the recall logic (such as modifying the recall radius) without modifying the code.

[0052] While the initial candidate set generated by the recall layer is of manageable size, not all resource nodes within it may be qualified to accept the order. The purpose of the inspection layer is to conduct a rigorous compliance review of these candidate nodes, filtering out all nodes that do not meet the hard requirements of the business, and generating a fully compliant candidate set for use by the sorting layer. Figure 4 This is a schematic diagram of a configurable constraint check chain structure for the check layer according to an embodiment of the present invention. Figure 4 As shown, the system maintains an independent, configurable "Constraint Check Chain" for each business sub-scenario. This check chain consists of a series of ordered "Constraint Checkers". When processing an order, the system loads the corresponding constraint check chain for the current order's business sub-scenario, and then executes each checker on the check chain sequentially for each resource node in the initial candidate set.

[0053] Each constraint checker is responsible for an independent compliance check. In this embodiment, based on the business characteristics of the online travel platform, the checkers can be divided into the following typical categories: Resource node validity class: Used to verify whether the driver's basic status is available. For example, checking whether the driver is currently in a "driving" state, whether they have completed the necessary identity authentication, and whether they are qualified to serve ride-hailing orders.

[0054] Service Capability Matching Category: This category verifies whether a driver's service capabilities match the specific requirements of the order. For example, if the order requires a "six-seater minivan," it checks whether the driver's vehicle has the required number of seats; if the order has a "pet-friendly" tag, it checks whether the driver has enabled the "pets allowed" option.

[0055] Time-of-day compliance: This category is used to verify whether a driver is eligible to provide service during the current time period. For example, it checks whether the driver is on a rest day or whether their operating permit covers the current time period.

[0056] Conflict and Blocking Category: Used to check whether the driver has any ongoing tasks that conflict with this dispatch (such as unfinished orders), or whether there is a mutual blocking relationship between the driver and the user (such as the user having given the driver a bad review and choosing not to ride with them again).

[0057] Business Quantitative Metric Coarse-Filtration Filtering: This is a special type of checker that doesn't perform hard compliance checks, but rather pre-filters based on a configurable business metric threshold. For example, a "service rating" checker can be configured to directly filter out drivers with a service rating below 4.5. The purpose of this type of checker is to further compress the candidate set size at a very low cost before entering the more computationally intensive fine-tuning and scoring stage, thereby improving overall processing efficiency.

[0058] Any resource node that fails to pass any checker in the check chain will be immediately removed from the candidate set. Only nodes that pass all checkers can enter the final compliance candidate set. Crucially, the composition of each check chain (i.e., which checkers it includes), the execution order of each checker, and its enabled / disabled status can be independently configured by business sub-scenario through the configuration center. For example, the "system assignment" scenario might include all of the above checkers, while the "driver order grabbing" scenario might, to improve order grabbing efficiency, only retain the most critical "validity" and "capability matching" checkers and skip some non-hard threshold filters.

[0059] Through this design, the inspection layer completely decouples the complex and ever-changing compliance judgment logic from the main sorting process, achieving complete decoupling from subsequent fine-tuning and scoring. Any addition, deletion, or modification of constraint rules only requires adjusting the inspection chain configuration for the corresponding business sub-scenario in the configuration center, greatly reducing the cost and risk of rule iteration.

[0060] Figure 5 This is a schematic diagram of a hierarchical scoring calculation structure for a sorting layer according to an embodiment of the present invention. Figure 5 As shown, after passing through the inspection layer, we obtain a fully compliant candidate set. The goal of the ranking layer is to perform a refined evaluation and ranking of all resource nodes in this set. One of the core innovations of this invention lies in the hierarchical evaluation and scenario-adaptive weighting mechanism adopted by the ranking layer.

[0061] Step S131: Obtain the tiered evaluation configuration.

[0062] The system first loads the corresponding hierarchical evaluation configuration for the current business sub-scenario. This configuration organizes all evaluation metrics into a two-level structure: evaluation categories and evaluation sub-items. Each evaluation category represents an independent business dimension, while each evaluation sub-item is a specific metric used to measure that dimension. The number of evaluation categories, the composition of sub-items under each category, and the weight and unification method for each sub-item are all configured through the configuration center.

[0063] In this embodiment, for ease of explanation, we divide the evaluation indicators into the following three categories, but in actual applications, the number and composition of the categories can be flexibly configured.

[0064] Assessment Category 1: Comprehensive Service Capability. This category aims to measure the driver's consistently high service quality over the long term. It may include assessment sub-items such as: historical service ratings (out of 5), cancellation rate after accepting an order (percentage), number of positive user reviews, and complaint rate.

[0065] Evaluation Category Two: Operational Efficiency Achievement. This category aims to assess drivers' current value and contribution to platform goals. Sub-items may include: daily completion rate (completed orders / cumulative daily dispatches), peak-hour online time, etc. For this type of metric, a specific standardized measurement method can be designed. For example, the actual completion rate can be compared to a target baseline (e.g., 60%). Drivers falling below the baseline receive positive incentives (to encourage improvement), while those exceeding the baseline also receive appropriate rewards, but with potentially different weights, ensuring the scoring results align with the platform's operational goals.

[0066] Evaluation Category 3: Spatiotemporal Efficiency. This category aims to evaluate the spatiotemporal costs incurred by the driver in performing this task. Its sub-items typically include: pick-up distance (km), estimated pick-up time (minutes), and the route's proximity to the destination (if the driver has a pre-set destination).

[0067] Step S132: Calculate the scores for each major category.

[0068] For each resource node in the compliance candidate set, the system calculates its score in each evaluation category based on its configuration. The calculation process consists of two steps: First, dimension unification is required. Since the original values ​​of each evaluation sub-item have different dimensions and distributions (e.g., distance is in kilometers, score is in points), they cannot be directly added. Therefore, it is necessary to convert the original values ​​into a dimensionless score within a uniformly comparable range (e.g., 0-1 or 0-100) according to the dimension unification method configured for each sub-item. This invention supports the implementation of various pluggable dimension unification algorithms through a registration-based processor factory, including but not limited to: Linear interval mapping: Suitable for indicators whose values ​​are uniformly distributed within a finite interval, such as service ratings. Score = (Original value - Minimum value) / (Maximum value - Minimum value).

[0069] Logarithmic transformation followed by interval mapping: suitable for indicators with long-tailed distributions, such as pick-up distance. First, take the logarithm to compress the long tail, then perform a linear mapping to better distinguish differences between close-range values. Score = log(original value + 1) / log(maximum value + 1).

[0070] Rank position mapping: Suitable for metrics that only care about relative order. Sort all candidate nodes by metric value, score = 1 - (rank - 1) / (candidate set size - 1).

[0071] Segmented threshold mapping: Applicable to segmented intervals with clear business meaning. For example, segmenting by distance: 0-1km gets 100 points, 1-3km gets 80 points, 3-5km gets 50 points, and >5km gets 0 points.

[0072] The specific dimensional standardization method and related parameters used for each evaluation sub-item can be configured independently through the configuration center, offering extremely high flexibility.

[0073] Secondly, weighted aggregation within the major category. After obtaining the standardized scores of all sub-items, a weighted sum is performed based on the weights set for each sub-item within the major category in the configuration to obtain the "major category score" of the resource node.

[0074] Category score = Σ (sub-item weight × sub-item dimensional unification score)

[0075] Step S133: Adaptive aggregation of category weights and comprehensive scoring of the scene.

[0076] After calculating the scores for all evaluation categories, we need to aggregate these category scores according to the business scenario preferences of the current order to obtain a comprehensive score. This invention introduces the concept of a "weight profile".

[0077] The system pre-maintains multiple weight configuration groups in the configuration center. Each group corresponds to a business scenario and defines the weight coefficients for the aforementioned evaluation categories within that scenario. For example: Weighting Group A (Balanced): Suitable for most common scenarios. The weights of each evaluation category are relatively balanced, for example, spatiotemporal efficiency (0.4), comprehensive service capability (0.3), and operational efficiency achievement (0.3).

[0078] Weighted Configuration Group B (Time-Priority): Suitable for scenarios where users urgently need a vehicle, such as during peak hours or in inclement weather. This configuration group significantly increases the weight of "Time-Spatial Efficiency" categories, for example, Time-Spatial Efficiency (0.7), while the other two categories each account for 0.15.

[0079] Weighted Configuration Group C (Quality Priority): Applicable to high-value order scenarios such as business chauffeured services and pre-booked orders. This configuration group significantly increases the weight of "Comprehensive Service Capability" category, for example, Comprehensive Service Capability category (0.6), while the other two categories each account for 0.2.

[0080] When processing each order, the system matches the corresponding target weight configuration group according to the mapping relationship defined in the configuration center, based on the order's scenario characteristics (e.g., by parsing information such as "user selected immediate departure" or "order remarks include business reception"). Then, the system weights and sums the scores of each major category of the resource node according to the category weights in the target weight configuration group to obtain the node's "comprehensive score".

[0081] Overall score = Σ (Category weight × Category score)

[0082] Through this mechanism, the same evaluation framework and the same resource node can obtain completely different comprehensive scores in different business scenarios, perfectly realizing the scenario adaptation of the ranking strategy. All of this can be accomplished without modifying a single line of code, simply by adjusting the weight configuration group in the configuration center.

[0083] The overall score is already a fairly comprehensive evaluation result, but in some complex business scenarios, we may still need to make a final manual intervention on the score based on specific, combined rules. Figure 6 This is a schematic diagram of a post-adjustment module and multi-key sorting rules according to an embodiment of the present invention. The present invention elegantly achieves this through a post-adjustment module and multi-key sorting rules, such as... Figure 6 As shown.

[0084] Step S134: Post-adjustment and final score.

[0085] The post-adjustment module maintains a configurable "set of adjustment rules". Each rule in the set defines two elements: a trigger condition and a numerical adjustment value. The trigger condition can be defined based on any combination of order attributes and resource node attributes.

[0086] In this embodiment, we can configure the following two rules: Rule 1: If the order attribute "Carrying a child" is True and the driver attribute "Has a child safety seat" is True, then the adjustment value is +10.0.

[0087] Rule 2: If the order attribute "Departure Point" is equal to the airport and the driver attribute "Airport Order Acceptance Qualification" is equal to True, then the adjustment value is +5.0.

[0088] When processing a resource node, the post-adjustment module iterates through the entire set of adjustment rules to determine whether the node meets the triggering conditions of each rule. If it does, the adjustment values ​​(positive or negative) corresponding to the rules are summed up.

[0089] Finally, the "final score" of this resource node is calculated as follows: Final score = Overall score + Σ (Adjustment value corresponding to all adjustment rules that meet the conditions) This post-adjustment module is independent of the core scoring logic, and its rule set is entirely managed by the configuration center. This allows operations personnel to dynamically add, modify, or delete intervention rules at any time according to business needs, without modifying the main sorting process code, thus enabling flexible, rapid, and low-risk implementation of operational strategies.

[0090] Step S140: Multi-key sorting and final output.

[0091] After obtaining the final score for each candidate resource node, the final step is sorting. This invention does not simply sort based on the final score, but introduces a more powerful and flexible configurable "multi-key sorting rule".

[0092] This rule defines a set of ordered sort keys (Key1, Key2, ..., KeyN). Each sort key must specify two attributes: the source of the value and the sorting direction (ascending / descending). The source of the value can be the final score, the score of any evaluation category, or even a preset mapping value of a basic attribute of a resource node.

[0093] In this embodiment, we can configure the following multi-key sorting rules: The first sorting key (Key1) is derived from the "driver ability level" (e.g., an enumeration of values ​​from L1 to L5), and the sorting direction is "descending". This means that the driver with the highest ability level (e.g., L5) will be unconditionally ranked before the driver with the lower ability level (e.g., L1).

[0094] The second sorting key (Key2) is derived from the "final score" and sorted in descending order. This means that within the same ability level, the scores are further sorted according to our carefully calculated final scores.

[0095] The third sort key (Key3): The value is derived from "Driver ID" and the sorting direction is "ascending". This is a backup sort key to ensure that the sorting result is completely deterministic and stable when Key1 and Key2 are the same.

[0096] The system will stably sort all resource nodes in the compliance candidate set according to this configured multi-key sorting rule. Only when high-priority sorting keys have the same value will the next higher priority sorting key be compared. Finally, the system outputs a sorted list of resource nodes for the scheduling decision module to use. Different business sub-scenarios can maintain their own independent multi-key sorting rule configurations to achieve differences in the final sorting effect between scenarios. For example, the "system assignment" scenario might be configured as above, while the "driver order grabbing" scenario might directly use "final score" as the sole sorting key to highlight the importance of the score.

[0097] Figure 7 This is a system architecture diagram of the browser connector service in the hierarchical evaluation-based order sorting system of the present invention. Figure 7 As shown, the hierarchical evaluation-based order sorting system 5 of the present invention includes: The request recall module 51 receives the order request, determines the corresponding business sub-scenario based on its business attributes, and recalls one or more resource nodes from the resource pool based on the business sub-scenario to generate an initial candidate set.

[0098] The constraint filtering module 52 loads the corresponding constraint check chain according to the business sub-scenario. The constraint check chain contains at least one constraint checker. The constraint checker is used in turn to perform compliance checks on each resource node in the initial candidate set. Resource nodes that fail to pass the check of any constraint checker are filtered out from the initial candidate set to obtain a compliant candidate set.

[0099] The tiered evaluation module 53 performs a tiered evaluation on each resource node in the compliance candidate set and calculates the final score.

[0100] The sorting output module 54 performs stable sorting of all resource nodes in the compliant candidate set according to their final scores based on configurable multi-key sorting rules, and outputs a sorted list of resource nodes.

[0101] In summary, the hierarchical evaluation-based order sorting system of the present invention can achieve hierarchical management of evaluation indicators, complete decoupling of inspection and sorting logic, adaptive switching of sorting strategies in different scenarios, and flexible introduction of operational intervention. Thus, without modifying the code, sorting effects of any business preference can be achieved through configuration, significantly improving the maintainability, flexibility and scalability of the sorting system.

[0102] This invention also provides an order sorting device based on hierarchical evaluation, including a processor and a memory storing executable instructions for the processor. The processor is configured to execute steps of an order sorting method based on hierarchical evaluation by executing the executable instructions.

[0103] As shown above, the hierarchical evaluation-based order sorting device of this invention can realize hierarchical management of evaluation indicators, complete decoupling of inspection and sorting logic, adaptive switching of sorting strategies in different scenarios, and flexible introduction of operational intervention. Thus, without modifying the code, sorting effects of any business preference can be achieved through configuration, which significantly improves the maintainability, flexibility and scalability of the sorting system.

[0104] Those skilled in the art will understand that various aspects of the present invention can be implemented as systems, methods, or program products. Therefore, various aspects of the present invention can be specifically implemented in the following forms: a completely hardware implementation, a completely software implementation (including firmware, microcode, etc.), or a combination of hardware and software aspects, collectively referred to herein as a "circuit," "module," or "platform."

[0105] Figure 8 This is a schematic diagram of the order sorting device based on hierarchical evaluation according to the present invention. See below for reference. Figure 8 To describe an electronic device 600 according to this embodiment of the present invention. Figure 8The electronic device 600 shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of the present invention.

[0106] like Figure 8 As shown, the electronic device 600 is presented in the form of a general-purpose computing device. The components of the electronic device 600 may include, but are not limited to: at least one processing unit 610, at least one storage unit 620, a bus 630 connecting different platform components (including storage unit 620 and processing unit 610), a display unit 640, etc.

[0107] The storage unit stores program code, which can be executed by the processing unit 610 to perform the steps described in the method section of this specification according to various exemplary embodiments of the present invention. For example, the processing unit 610 can perform actions such as... Figure 1 The steps are shown in the figure.

[0108] Storage unit 620 may include readable media in the form of volatile storage units, such as random access memory (RAM) 6201 and / or cache memory 6202, and may further include read-only memory (ROM) 6203.

[0109] Storage unit 620 may also include a program / utility 6204 having a set (at least one) program module 6205, such program module 6205 including but not limited to: operating system, one or more application programs, other program modules and program data, each or some combination of these examples may include an implementation of a network environment.

[0110] Bus 630 can represent one or more of several types of bus structures, including a memory cell bus or memory cell controller, a peripheral bus, a graphics acceleration port, a processing unit, or a local bus using any of the multiple bus structures.

[0111] Electronic device 600 can also communicate with one or more external devices 700 (e.g., keyboard, pointing device, Bluetooth device, etc.), and with one or more devices that enable a user to interact with electronic device 600, and / or with any device that enables electronic device 600 to communicate with one or more other computing devices (e.g., router, modem, etc.). This communication can be performed via input / output (I / O) interface 650. Furthermore, electronic device 600 can also communicate with one or more networks (e.g., local area network (LAN), wide area network (WAN), and / or public networks, such as the Internet) via network adapter 660. Network adapter 660 can communicate with other modules of electronic device 600 via bus 630. It should be understood that, although not shown in the figures, other hardware and / or software modules can be used in conjunction with electronic device 600, including but not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data backup storage platforms.

[0112] This invention also provides a computer-readable storage medium for storing a program that, when executed, implements the steps of a hierarchical evaluation-based order sorting method. In some possible implementations, various aspects of the invention can also be implemented as a program product comprising program code that, when run on a terminal device, causes the terminal device to perform the steps described in the above-described method section of this specification according to various exemplary embodiments of the invention.

[0113] As shown above, the hierarchical evaluation-based order sorting system of this invention can achieve hierarchical management of evaluation indicators, complete decoupling of inspection and sorting logic, adaptive switching of sorting strategies in different scenarios, and flexible introduction of operational intervention. Thus, without modifying the code, sorting effects of any business preference can be achieved through configuration, significantly improving the maintainability, flexibility, and scalability of the sorting system.

[0114] Figure 9 This is a schematic diagram of the structure of the computer-readable storage medium of the present invention. (Reference) Figure 9 As shown, a program product 800 for implementing the above-described method according to an embodiment of the present invention is described. It may employ a portable compact disc read-only memory (CD-ROM) and include program code, and may run on a terminal device, such as a personal computer. However, the program product of the present invention is not limited thereto. In this document, the readable storage medium may be any tangible medium containing or storing a program that may be used by or in conjunction with an instruction execution system, apparatus, or device.

[0115] The program product may employ any combination of one or more readable media. A readable medium may be a readable signal medium or a readable storage medium. A readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of readable storage media (a non-exhaustive list) include: electrical connections having one or more wires, portable disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0116] Computer-readable storage media may include data signals propagated in baseband or as part of a carrier wave, carrying readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A readable storage medium may also be any readable medium other than a readable storage medium that can transmit, propagate, or transfer a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the readable storage medium may be transmitted using any suitable medium, including but not limited to wireless, wired, optical fiber, RF, etc., or any suitable combination thereof.

[0117] Program code for performing the operations of this invention can be written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Java and C++, and conventional procedural programming languages ​​such as C or similar languages. The program code can execute entirely on the user's computing device, partially on the user's device, as a standalone software package, partially on the user's computing device and partially on a remote computing device, or entirely on a remote computing device or server. In cases involving remote computing devices, the remote computing device can be connected to the user's computing device via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computing device (e.g., via the Internet using an Internet service provider).

[0118] In summary, the purpose of this invention is to provide an order sorting method, system, device, and storage medium based on hierarchical evaluation, which can realize hierarchical management of evaluation indicators, complete decoupling of inspection and sorting logic, adaptive switching of sorting strategies in different scenarios, and flexible introduction of operational intervention. Thus, without modifying the code, sorting effects of any business preference can be achieved through configuration, significantly improving the maintainability, flexibility, and scalability of the sorting system.

[0119] The above description, in conjunction with specific preferred embodiments, provides a further detailed explanation of the present invention. It should not be construed that the specific implementation of the present invention is limited to these descriptions. For those skilled in the art, various simple deductions or substitutions can be made without departing from the concept of the present invention, and all such modifications and substitutions should be considered within the scope of protection of the present invention.

Claims

1. A method for order ranking based on hierarchical evaluation, the method comprising: receiving a plurality of orders; and ranking the plurality of orders based on a hierarchical evaluation of the plurality of orders. Includes the following steps: S110. Receive an order request, determine the corresponding business sub-scenario based on its business attributes, and recall one or more resource nodes from the resource pool based on the business sub-scenario to generate an initial candidate set. S120. Load the corresponding constraint check chain according to the business sub-scenario. The constraint check chain contains at least one constraint checker. Use the constraint checker in sequence to perform compliance checks on each resource node in the initial candidate set. Filter and remove resource nodes that fail to pass the check of any constraint checker from the initial candidate set to obtain a compliance candidate set. S130. Perform a hierarchical evaluation on each resource node in the compliance candidate set and calculate the final score; as well as S140. Based on the configurable multi-key sorting rules, all resource nodes in the compliance candidate set are stably sorted according to their final scores, and the sorted list of resource nodes is output.

2. The layered assessment based order sequencing method as claimed in claim 1, wherein, In step S120, the constraint check chain includes a pre-filter checker based on a business quantitative indicator threshold, which is used to filter resource nodes that do not meet the conditions according to the preset indicator threshold before entering the sorting layer, so as to compress the size of the candidate set. The composition of the constraint check chain, the execution order of each constraint checker and the activation status are all configured independently by the configuration center according to the business sub-scenario.

3. The layered assessment based order sequencing method as claimed in claim 1 wherein, Step S130 includes: S131. Obtain the hierarchical evaluation configuration corresponding to the business sub-scenario. The hierarchical evaluation configuration divides multiple evaluation sub-items into at least one evaluation category. Each evaluation category contains at least one evaluation sub-item. The configuration also configures a weight and dimension unification method for each evaluation sub-item. S132. For each evaluation category, according to the dimension unification method configured for each evaluation sub-item, the original values ​​of resource nodes on each evaluation sub-item are converted into dimension unification scores, and the scores are obtained by weighted summation according to the weight of each evaluation sub-item. S133. Based on the scenario characteristics of the order request, a target weight configuration group is matched from multiple preset weight configuration groups. The target weight configuration group defines the weight of each evaluation category. The scores of each evaluation category are weighted and summed according to the weights in the target weight configuration group to obtain a comprehensive score. S134. Adjust the comprehensive score according to the configurable set of adjustment rules to obtain the final score, wherein each adjustment rule defines a trigger condition and a corresponding numerical adjustment value.

4. The layered assessment based order sequencing method of claim 3, wherein, The dimension unification method in step S132 is one of a variety of dimension unification algorithms implemented through the registration-based processor factory. The variety of dimension unification algorithms include linear interval mapping, logarithmic transformation interval mapping, ranking position mapping, and segmented threshold mapping. The dimension unification method and its parameters for each evaluation sub-item are configured independently through the configuration center.

5. The layered evaluation based order sequencing method as claimed in claim 3, wherein, The weight configuration group in step S133 is one of multiple weight configuration groups that are pre-configured and stored in the configuration center. Each weight configuration group corresponds to a business scenario and defines the weights of each evaluation category under that scenario. The mapping relationship between the scenario characteristics of the order request and the target weight configuration group is configured through the configuration center.

6. The layered evaluation based order sequencing method as claimed in claim 3, wherein, The set of adjustment rules in step S134 includes at least one adjustment rule. The triggering condition of each adjustment rule is defined based on the combination relationship between order attributes and resource node attributes. The set of adjustment rules is configured through the configuration center, and when multiple rules meet the triggering condition, their corresponding adjustment values ​​are calculated by superposition.

7. The layered assessment based order sequencing method as claimed in claim 1 wherein, The multi-key sorting rule in step S140 defines a set of ordered sorting keys, each sorting key specifying the source of the value and the sorting direction; when the values ​​of high-priority sorting keys are the same, the sorting keys of the next lower priority are compared in turn to determine the final order; the multi-key sorting rule is configured independently by the configuration center according to the business sub-scenario.

8. A layered evaluation based order ranking system for implementing the method of any one of claims 1 to 7, characterized in that, include: The request recall module receives an order request, determines the corresponding business sub-scenario based on its business attributes, and recalls one or more resource nodes from the resource pool based on the business sub-scenario to generate an initial candidate set. The constraint filtering module loads the corresponding constraint check chain according to the business sub-scenario. The constraint check chain contains at least one constraint checker. The constraint checker is used in sequence to perform compliance checks on each resource node in the initial candidate set. Resource nodes that fail to pass the check by any constraint checker are filtered out and removed from the initial candidate set to obtain a compliant candidate set. The tiered evaluation module performs a tiered evaluation on each resource node in the compliance candidate set and calculates the final score. as well as The sorting output module performs a stable sorting of all resource nodes in the compliant candidate set according to their final scores based on configurable multi-key sorting rules, and outputs a sorted list of resource nodes.

9. A layered evaluation based order sequencing device, characterized by, include: processor; A memory in which executable instructions of the processor are stored; The processor is configured to perform the steps of the hierarchical evaluation-based order sorting method according to any one of claims 1 to 7 by executing the executable instructions.

10. A computer readable storage medium for storing a program, characterized in that, When the program is executed by the processor, it implements the steps of the hierarchical evaluation-based order sorting method according to any one of claims 1 to 7.

Images