Method and system for visualizing and comparing multiple algorithms in logistics scenarios

Abstract

The application relates to the technical field of logistics intelligent scheduling, in particular to a logistics scene multi-algorithm visual demonstration and comparative analysis method and system, which comprises the following steps: S1, standardization of a scene request; S2, strategy registration and automatic routing; S3, unified scheduling execution of multiple engines; S4, multi-target weighted scoring; S5, visual display conversion; and S6, multi-algorithm comparative analysis.The application converts a demonstration request into a standardized algorithm request object through a normalization adapter, selects an optimal algorithm strategy based on a combination key and a three-level routing mechanism from a strategy registration center, then, an executor calls corresponding algorithm engines to complete solving in automatic execution, benchmark comparison or degradation fallback modes, the system carries out multi-dimensional comprehensive evaluation on the output results in combination with scene scoring dimensions and user-defined weights, and generates visual contents such as KPI cards, structured logs and natural language summaries, so that the algorithm reuse capability, the evaluation efficiency and the scene expansion capability are improved.

Description

Technical Field

[0001] This invention relates to the field of intelligent logistics scheduling technology, and in particular to a method and system for visual demonstration and comparative analysis of multiple algorithms in logistics scenarios. Background Technology

[0002] The logistics industry has an increasing demand for intelligent scheduling, route optimization, and resource allocation. Algorithms for route planning, loading optimization, and scheduling have been used in multiple projects. However, these capabilities have long been scattered across various projects, lacking a unified service framework, leading to redundant development and difficulty in reusing experience.

[0003] Meanwhile, traditional algorithm systems rely primarily on data interfaces, making it difficult to intuitively present optimization effects. This restricts the application of algorithm capabilities in pre-sales demonstrations and solution communication. When multiple algorithm strategies are available for the same business scenario, the lack of a unified framework for fair comparison and quantitative analysis of effects under the same data conditions often leads to algorithm selection relying on experience rather than data-driven approaches. Furthermore, adding new business scenarios requires extensive modifications to routing logic and interface code, resulting in high system expansion costs.

[0004] In existing technologies, logistics scheduling and optimization algorithms are usually implemented in a decentralized manner at the project level or interface level, lacking a unified algorithm management and scheduling framework. This makes it difficult for different algorithms to be uniformly accessed and reused in standardized scenarios, resulting in common duplication of development. At the same time, algorithm calls often rely on manual configuration or fixed interface routes, lacking an automated strategy matching mechanism based on scenario and algorithm combination. This means that when adding new scenarios or algorithms, it is often necessary to modify the core routing logic, resulting in poor system scalability. Summary of the Invention

[0005] To address the technical problems existing in the prior art, embodiments of the present invention provide a method and system for multi-algorithm visualization demonstration and comparative analysis in logistics scenarios. The technical solution is as follows:

[0006] A method for visualizing and comparing multiple algorithms in logistics scenarios, including the following steps:

[0007] S1. Contextualized Request Standardization: Receives demonstration requests from logistics scenarios that include scenario identifiers, algorithm identifiers, order data, vehicle data, rule configurations, and optimization target weights. The request normalization adapter converts input data of different formats into a unified strongly typed algorithm request object.

[0008] S2. Strategy Registration and Automatic Routing: Based on a strongly typed algorithm request object, the system reads the scene identifier and multiple algorithm identifiers, and inputs the scene identifier and algorithm identifiers into the strategy registration center. When the system starts, it automatically scans and collects all component instances that implement the algorithm strategy interface, constructs a hash table using the combination of scene identifier and algorithm identifier as the key, and outputs the matched target algorithm strategy as the routing result.

[0009] S3. Unified scheduling and execution of multiple engines: Based on the strategy obtained from the routing, the target algorithm strategy is passed to the engine mode executor. The engine mode executor calls the corresponding algorithm engine to solve the problem and returns the algorithm result in a unified format.

[0010] S4. Multi-objective weighted scoring: Extract the running indicator mapping table from the algorithm results in a unified format, and score the running indicators output by the algorithm in multiple dimensions according to the scoring dimensions defined by the scene scoring plugin and the optimization target weights set by the user. After normalizing the weights of each dimension, calculate the comprehensive score according to the weighted summation formula.

[0011] S5. Visualization and Transformation: The comprehensive score is calculated using formulas and combined with the algorithm results in a unified format. The comprehensive score and algorithm results are then converted into a display layer structure and presented through a front-end visual interface to show the algorithm execution process and optimization results.

[0012] S6. Multi-algorithm comparative analysis: Under the same dataset and constraints, the presentation layer structure executes multiple algorithm engines sequentially or in parallel, comparing the scoring items and comprehensive scores of each solution horizontally. It supports the import of benchmark solutions and relative deviation analysis, and finally generates multi-algorithm comparative analysis results.

[0013] Furthermore, in step S1, the normalization adapter uses an object mapper to map the loose key-value pairs passed from the front end to strongly typed algorithm request objects by field name;

[0014] In step S2, for each algorithm identifier, the combination of the scene identifier and the algorithm identifier is used as the query key to match the corresponding target algorithm strategy in the pre-built strategy registration center to obtain the target algorithm strategy set. After receiving the request, the strategy registration center first matches the scene-specific strategy according to the precise combination key. If no match is found, it searches for the cross-scene general fallback strategy according to the combination of the global identifier and the algorithm identifier. If no match is found, it is downgraded to the general algorithm adapter.

[0015] The registration mechanism of the strategy registration center in step S2 is as follows: Each algorithm strategy implementation class is marked with a declarative annotation. When the system container starts, it automatically scans and collects all marked strategy implementations. Based on the scene identifier and algorithm identifier declared by each strategy implementation, the combination of scene identifier and algorithm identifier is used as the key to store the information in the lookup table.

[0016] In step S3, the algorithm engine includes a greedy engine, a constraint planning engine, and a metaheuristic engine, and returns algorithm results in a unified format, including a vehicle allocation scheme list, a route planning list, an operation index mapping table, and a process log list.

[0017] In step S5, the structure layer is displayed, including key performance indicator cards, structured process logs, and natural language summaries.

[0018] Furthermore, in step S3: the engine mode executor supports three execution modes:

[0019] In automatic mode, the system directly routes to the registration policy execution and returns the main result;

[0020] In the benchmark mode, while executing the main algorithm, the constraint planning engine and constraint satisfaction engine are executed in parallel as reference data.

[0021] In the fallback mode, when the main algorithm returns an empty solution, the constraint planning engine is automatically invoked to solve the problem again. If the fallback result is not empty, it replaces the main result.

[0022] Furthermore, in step S3: the execution chain of the greedy engine is implemented based on the abstract base class of the greedy algorithm, and includes four stages:

[0023] Phase 1: Input standardization. Parse the order list, vehicle list, and rule configuration. Prioritize reading data from strongly typed request objects. If a strongly typed request is empty, fall back to parsing the key-value pairs in the business data mapping table.

[0024] Phase 2: Scenario Priority Sorting. Orders are prioritized according to business requirements using overwriteable scenario sorting hook methods.

[0025] Phase 3, the core of the greedy allocation, iterates through the sorted order list, calls the optimal vehicle selection method for each order to select the best loading vehicle from the available vehicles, and orders without feasible vehicles are put into the unallocated pool. After all orders are allocated, the local repair hook method is called for lightweight optimization.

[0026] Phase 4: Result projection, summarizing full load rate, cost, and time efficiency indicators to generate algorithm results in a unified format.

[0027] Furthermore, in step S4: the specific process of multi-objective weighted scoring is as follows:

[0028] The scene scoring plugin retrieves the scoring dimension definitions for the current scene. Each dimension includes a dimension identifier, display label, default weight, optimization direction, and scoring formula.

[0029] Parse the optimization target weight configuration passed in by the user, and use the default weight of the scenario when the user does not specify the weight;

[0030] Filter out valid dimensions with original weights greater than zero;

[0031] The effective weights are normalized so that the sum of the weights of each dimension after normalization is 1;

[0032] The scene scoring plugin calculates the raw scores for each dimension, and then calculates the comprehensive score by weighted summation with the normalized weights using a formula.

[0033] Furthermore, in step S1: a hard constraint verification step is included before receiving the demonstration request.

[0034] Verify the completeness of the scene identifier, algorithm identifier, order list, and vehicle list in the request;

[0035] After the routing results are output in step S2, the scene rule loading step is also included:

[0036] The scene rule engine merges the rule configuration, algorithm parameters, and target weights in the request into the rule template.

[0037] Furthermore, in step S5: the visualization transformation includes:

[0038] Key performance indicator cards are dynamically generated based on the optimized target weight configuration. Each card contains an indicator key, display label, value and unit. The calculation time card is always displayed.

[0039] The algorithm process log is converted into a structured log object. Each log entry contains a timestamp, log level, and text content. The log levels are divided into information level, warning level, and error level.

[0040] Generate a natural language summary of the results, including the number of orders processed, the number of successful assignments, the average load factor of the plan, and the number of vehicles used;

[0041] A multi-algorithm visualization and comparative analysis system for logistics scenarios, comprising:

[0042] Request normalization module: Obtains demonstration requests containing scene identifiers, algorithm identifiers, order data, vehicle data, rule configurations, and optimization target weights, and converts them into unified strongly typed algorithm request objects;

[0043] The strategy registration module obtains strongly typed algorithm request objects, extracts the scene identifier and algorithm identifier corresponding to each strategy instance, establishes a mapping relationship using the combination of scene identifier and algorithm identifier as the key, and generates a strategy mapping lookup table.

[0044] The strategy routing module receives strongly typed algorithm request objects, calls the strategy mapping lookup table, performs exact matching, global fallback matching, and adapter downgrade matching to obtain the target algorithm strategy instance, and combines the strongly typed algorithm request object to generate an algorithm execution context that includes scene identifier, algorithm identifier, order list, vehicle list, rule configuration, and target weight configuration.

[0045] Engine scheduling module: Based on the target algorithm strategy instance in the algorithm execution context, it determines the corresponding algorithm engine, executes the solution in automatic mode, benchmark comparison mode or degraded rollback mode, and generates algorithm results in a unified format;

[0046] Multi-objective scoring module: Collects the running indicator mapping table in the algorithm results and the target weight configuration in the algorithm execution context, calls the scoring dimension definition of the corresponding scenario, performs dimension score calculation, weight normalization processing and weighted summation calculation on the running indicators, and generates dimension score results and comprehensive score results;

[0047] Display Conversion Module: Based on algorithm results, dimensional scoring results, and comprehensive score results, it is used to convert the algorithm kernel output into key performance indicator cards, structured process logs, and natural language summaries to generate front-end display response data;

[0048] Front-end visualization module: Receives front-end display response data, performs interface rendering on key performance indicator cards, structured process logs, natural language summaries and scoring results, and generates algorithm demonstration results, multi-algorithm comparison results and scenario capability mapping results;

[0049] Furthermore, the engine scheduling module and the multi-objective scoring module output algorithm result objects in a unified format, and the display conversion module generates display data based on the algorithm result objects.

[0050] Furthermore, the engine scheduling module and the multi-objective scoring module can operate independently without the display conversion module and the front-end visualization module, and provide algorithm service interfaces to external systems.

[0051] The beneficial effects of the technical solutions provided in the embodiments of the present invention include at least the following:

[0052] 1. This invention converts logistics scenario demonstration requests of different formats into unified strongly typed algorithm request objects through a request normalization adapter, and establishes a policy mapping relationship with scenario identifier and algorithm identifier as the composite key in conjunction with the policy registration center. This enables automatic registration, automatic matching and hierarchical routing of algorithm policies, and can uniformly manage multiple algorithm capabilities under different logistics scenarios. Order data, vehicle data, rule configuration and optimization target weights are all transmitted to the algorithm execution stage in a standardized form, thereby reducing the cost of repeated development, improving the efficiency of algorithm access, system scalability and operational stability.

[0053] 2. This invention achieves unified solution, unified evaluation, and intuitive display of different algorithm solutions under the same dataset and constraints through unified multi-engine scheduling and execution, multi-objective weighted scoring, visual display transformation, and multi-algorithm comparative analysis. It can convert algorithm results into key performance indicator cards, structured process logs, and natural language summaries, and calculate comprehensive scores by combining scenario scoring dimensions and user-defined weights. It further supports horizontal comparison and relative deviation analysis with benchmark solutions, thereby improving the objectivity of algorithm evaluation, the intuitiveness of algorithm demonstration, and the accuracy of business decisions and algorithm selection. Attached Figure Description

[0054] Figure 1 This is a schematic diagram of the overall three-layer architecture of the system of the present invention;

[0055] Figure 2 This is a flowchart of the algorithm strategy registration and routing process of this invention;

[0056] Figure 3 This is a flowchart illustrating the multi-engine unified scheduling and execution process of the present invention.

[0057] Figure 4 This is a flowchart of the four-stage main link of the greedy algorithm of this invention;

[0058] Figure 5 This is a flowchart of the multi-objective weighted scoring process of the present invention;

[0059] Figure 6 This is a schematic diagram of the front-end algorithm demonstration and multi-algorithm comparison visualization interface of the present invention. Detailed Implementation

[0060] The technical solution of the present invention will now be described with reference to the accompanying drawings.

[0061] In embodiments of the present invention, words such as "exemplarily" and "for example" are used to indicate that something is an example, illustration, or description. Any embodiment or design described as "exemplary" in the present invention should not be construed as being more preferred or advantageous than other embodiments or designs. Rather, the use of the word "exemplary" is intended to present the concept in a specific manner. Furthermore, in embodiments of the present invention, the meaning expressed by "and / or" can be both, or either one.

[0062] To make the technical problems, technical solutions and advantages of the present invention clearer, a detailed description will be given below in conjunction with the accompanying drawings and specific embodiments.

[0063] Example 1, as Figure 1-6 As shown, this invention provides a technical solution: a method for visual demonstration and comparative analysis of multiple algorithms in logistics scenarios, comprising the following steps:

[0064] A method for visualizing and comparing multiple algorithms in logistics scenarios, including the following steps:

[0065] S1. Contextualized Request Standardization: Receives demonstration requests from logistics scenarios that include scenario identifiers, algorithm identifiers, order data, vehicle data, rule configurations, and optimization target weights. The request normalization adapter converts input data of different formats into a unified strongly typed algorithm request object.

[0066] Before receiving a demonstration request, a hard constraint verification step is also included: verifying the completeness of the scene identifier, algorithm identifier, order list, and vehicle list in the request;

[0067] The normalization adapter uses an object mapper to map loose key-value pairs passed from the front end to strongly typed algorithm request objects according to field names. After the mapping is completed, it performs unified validation processing on field types, data integrity and default parameters to generate standardized request data.

[0068] Strongly typed algorithm request objects uniformly encapsulate scenario parameters, business data, and algorithm configuration parameters, eliminating data structure differences between different front-end interfaces and providing a standardized input data foundation for subsequent policy routing, rule loading, and algorithm solving.

[0069] S2. Strategy Registration and Automatic Routing: Based on a strongly typed algorithm request object, the system reads the scene identifier and multiple algorithm identifiers, and inputs the scene identifier and algorithm identifiers into the strategy registration center. When the system starts, it automatically scans and collects all component instances that implement the algorithm strategy interface, constructs a hash table using the combination of scene identifier and algorithm identifier as the key, and outputs the matched target algorithm strategy as the routing result.

[0070] For each algorithm identifier, the combination of the scene identifier and the algorithm identifier is used as the query key to match the corresponding target algorithm strategy in the pre-built strategy registry center to obtain the target algorithm strategy set. After receiving the request, the strategy registry center first matches the scene-specific strategy according to the precise combination key. If no match is found, it searches for the cross-scene general fallback strategy according to the combination of the global identifier and the algorithm identifier. If no match is found, it is downgraded to the general algorithm adapter.

[0071] The registration mechanism of the strategy registry is as follows: Each algorithm strategy implementation class is marked with a declarative annotation. When the system container starts, it automatically scans and collects all marked strategy implementations. Based on the scene identifier and algorithm identifier declared by each strategy implementation, the combination of scene identifier and algorithm identifier is used as the key to store in the lookup table, so as to realize automatic extended registration when adding a new scene or a new algorithm strategy without modifying the core routing logic.

[0072] The routing results simultaneously carry the corresponding algorithm engine type, scenario rule template, and execution mode information, forming an algorithm execution context and providing a strategy basis for subsequent unified scheduling and execution.

[0073] S3. Unified scheduling and execution of multiple engines: Based on the strategy obtained from the routing, the target algorithm strategy is passed to the engine mode executor. The engine mode executor calls the corresponding algorithm engine to solve the problem and returns the algorithm result in a unified format.

[0074] The algorithm engines include: greedy engine, constraint planning engine and metaheuristic engine;

[0075] The algorithm results returned in a uniform format include: a list of vehicle allocation schemes, a list of route plans, a map of operational indicators, and a list of process logs;

[0076] The engine-mode executor supports three execution modes, each corresponding to different algorithm verification requirements:

[0077] (1) In automatic mode, the system directly routes to the registration strategy execution and returns the main result;

[0078] (2) In the benchmark comparison mode, while executing the main algorithm, the constraint planning engine and constraint satisfaction engine are executed in parallel as reference data;

[0079] (3) In the fallback mode, when the main algorithm returns an empty solution, the constraint planning engine is automatically called to solve the problem again. If the fallback result is not empty, the main result is replaced.

[0080] The execution chain of the greedy engine is implemented based on the abstract base class of the greedy algorithm and includes four stages:

[0081] Phase 1: Input standardization. Parse the order list, vehicle list, and rule configuration. Prioritize reading data from strongly typed request objects. If a strongly typed request is empty, fall back to parsing the key-value pairs in the business data mapping table.

[0082] Phase 2: Scenario Priority Sorting. Orders are prioritized according to business requirements using overwriteable scenario sorting hook methods.

[0083] Phase 3, the core of the greedy allocation, iterates through the sorted order list, calls the optimal vehicle selection method for each order to select the best loading vehicle from the available vehicles, and orders without feasible vehicles are put into the unallocated pool. After all orders are allocated, the local repair hook method is called for lightweight optimization.

[0084] Phase 4: Result projection, summarizing indicators such as load factor, cost, and time efficiency to generate algorithm results in a unified format;

[0085] The algorithm results in a unified format include: a list of vehicle allocation schemes, a list of route planning, a map of operational indicators, a list of process logs, and a list of unallocated orders (the output results of each algorithm engine are mapped to a unified data structure to achieve standardized expression of different algorithm results and subsequent comparability processing).

[0086] S4. Multi-objective weighted scoring: Extract the running indicator mapping table from the algorithm results in a unified format, and score the running indicators output by the algorithm in multiple dimensions according to the scoring dimensions defined by the scene scoring plugin and the optimization target weights set by the user. After normalizing the weights of each dimension, calculate the comprehensive score according to the weighted summation formula.

[0087] The overall score is used to quantitatively evaluate the overall performance of the algorithm solution. The scoring results of each dimension are simultaneously generated into detailed scoring data, providing a unified evaluation basis for subsequent visualization and horizontal comparison of multiple algorithms.

[0088] The specific process of multi-objective weighted scoring is as follows:

[0089] (1) Obtain the scoring dimension definition of the current scene through the scene scoring plugin. Each dimension includes dimension identifier, display label, default weight, optimization direction and scoring formula;

[0090] (2) Parse the optimization target weight configuration passed in by the user, and use the default weight of the scenario when the user does not specify the weight;

[0091] (3) Filter out the valid dimensions whose original weights are greater than zero;

[0092] (4) Normalize the effective weights so that the sum of the weights of each dimension after normalization is equal to 1;

[0093] (5) The original scores of each dimension are calculated by the scene scoring plugin, and the comprehensive score is calculated by weighted summation formula with normalized weights;

[0094] S5. Visualization and Transformation: The comprehensive score is calculated using formulas and combined with the algorithm results in a unified format. The comprehensive score and algorithm results are then converted into a display layer structure and presented through a front-end visual interface to show the algorithm execution process and optimization results.

[0095] The presentation layer structure includes: key performance indicator cards, structured process logs, natural language summaries, and algorithm operation statistics, enabling the algorithm execution process, resource utilization, and optimization effects to be presented intuitively in a visual manner;

[0096] The visualization transformation includes:

[0097] (1) Based on the optimization target weight configuration, key performance indicator cards are dynamically generated. Each card contains an indicator key, display label, value and unit. The calculation time card is always displayed.

[0098] (2) Convert the algorithm process log into a structured log object. Each log entry contains a timestamp, log level, and text content. The log levels are divided into information level, warning level, and error level.

[0099] (3) Generate a result summary in natural language format, including the number of orders processed, the number of successful allocations, the average full load rate of the plan, and the number of vehicles used;

[0100] S6. Multi-algorithm comparison analysis: Under the same dataset and constraints, the presentation layer structure executes multiple algorithm engines sequentially or in parallel, compares the scoring items and comprehensive scores of each solution horizontally, supports the import of benchmark solutions and relative deviation analysis, and finally generates multi-algorithm comparison analysis results.

[0101] The results of the multi-algorithm comparison analysis include: algorithm ranking information, dimensional score difference information, comprehensive score difference information, and relative improvement ratio information, which are used to assist users in completing algorithm selection evaluation and scenario adaptation analysis.

[0102] Example 2, based on the differentiated implementation of each scenario in Example 1, achieves differentiated logistics optimization solutions by using the unified method flow of steps S1 to S6 and combining the hook extension points of the abstract base class of the greedy algorithm.

[0103] Simple loading scenario: The optimization goal of this scenario is to load all orders with as few vehicles as possible while maximizing the average loading rate, under the premise of satisfying vehicle load and volume constraints. In step S2, the greedy strategy for this scenario is registered through component annotations, using a combination of the simple loading scenario identifier and the greedy algorithm identifier as the registration key;

[0104] In step S3, the order sorting prioritizes large orders; vehicle candidate selection prioritizes large vehicles or capacity matching, ensuring that orders with larger weight and volume are loaded into vehicles with larger capacity; the optimal vehicle selection method in the greedy allocation core selects the vehicle with the highest loading rate after loading orders from available vehicles; hard constraint filtering checks for weight and volume capacity limitations; the local repair hook performs low-load vehicle merging—starting from the vehicle with the lowest loading rate, it attempts to migrate the loaded orders to other vehicles with remaining capacity, as well as backfilling unassigned orders and retrying single-step relocation. In step S4, the scoring dimensions are average load factor (default weight 50%), capacity intensification (default weight 30%), and order fulfillment rate (default weight 20%).

[0105] Complex loading scenario: This scenario adds constraints on the maximum number of customers per vehicle, priority constraints on urgent orders, unloading order constraints on the last-loaded-first-unloaded principle, and vehicle model preference constraints to the simple loading scenario.

[0106] In step S3, the scene sorting hook supports three sorting modes: by density, by weight, and by volume, which are controlled by the greedy sorting mode field in the algorithm parameters. The optimal vehicle selection method in the greedy allocation core adds a check for the maximum number of customers per vehicle during hard constraint filtering, and reverses the unloading order of orders on the same vehicle according to the last-load-first-unload rule during the result projection stage (orders loaded later are unloaded first, and orders loaded earlier are unloaded last). The local repair hook performs low-load vehicle merging and single-step retrying. In addition to the greedy strategy, this scenario also supports a constraint planning engine solution, as well as a hybrid strategy of greedy initial solution superimposed with simulated annealing local search.

[0107] In step S4, the scoring dimensions are average load factor (default weight 35%), order fulfillment rate (default weight 30%), emergency guarantee rate (default weight 20%), capacity utilization (default weight 15%), and business compliance (default weight 0%).

[0108] Urban delivery scenario: This scenario focuses on delivery timeliness and route efficiency, optimizing vehicle loading rate and delivery route in a single delivery task;

[0109] In one implementation, the scenario sorting hook in step S3 sorts according to the same customer aggregation caliber, and centrally allocates orders belonging to the same receiving customer to reduce the number of stops; the optimal vehicle selection method in the greedy allocation core adds time window constraints, maximum number of stops per vehicle constraints, and maximum total mileage limit constraints per vehicle constraints in hard constraint filtering.

[0110] In step S4, the scoring dimensions are timeliness achievement rate (default weight 40%), route efficiency (default weight 30%), and order fulfillment rate (default weight 30%).

[0111] Trunk Line Single Route Scenario: This scenario focuses on the loading rate and capacity utilization efficiency of a single fixed route in trunk transportation.

[0112] In one implementation, the optimal vehicle selection method in the greedy allocation core of step S3 adds a cut-off window constraint and a minimum departure loading rate constraint to the hard constraint filtering. Only vehicles with a loading rate that reaches the minimum departure threshold will be included in the final vehicle allocation scheme list.

[0113] In step S4, the scoring dimensions are vehicle concentration (default weight 35%), route loading rate (default weight 35%), and order fulfillment rate (default weight 30%).

[0114] Multi-line trunk route scenario: This scenario requires a balanced distribution of orders across multiple trunk routes to avoid overload or idle capacity on a single route. In one implementation, the scenario sorting hook in step S3 sorts routes by capacity and service level, ensuring that routes with larger capacity are allocated first; the optimal vehicle selection method in the greedy allocation core adds a balance weight constraint, and additionally considers the balance of order distribution among routes when calculating incremental scores;

[0115] In step S4, the scoring dimensions are overall cost (default weight 35%), multi-line efficiency (default weight 30%), timeliness achievement rate (default weight 20%), and order fulfillment rate (default weight 15%).

[0116] Dynamic order insertion scenario: This scenario handles new orders added in real time during the transportation process, and it is necessary to control the degree of disturbance to the existing schedule while inserting new orders;

[0117] In step S3, the order pre-filter hook excludes locked orders; the vehicle filtering logic excludes locked vehicles; the optimal vehicle selection method in the greedy allocation core adds vehicle and order locking constraints and maximum reordering ratio constraints in the hard constraint filtering to ensure that locked vehicles and orders are not reassigned.

[0118] In addition to the greedy strategy, this scenario also provides multiple solvers such as the genetic algorithm engine, simulated annealing engine, constraint planning engine, and constraint satisfaction engine. Among them, the genetic algorithm engine adopts the chromosome encoding method of "order number to vehicle number" and ensures that hard constraints such as vehicle locking constraints, capacity constraints, and stop point constraints are not violated through repair operators.

[0119] In step S4, the scoring dimensions are order insertion timeliness (default weight 45%), order fulfillment rate (default weight 30%), and disturbance control (default weight 25%).

[0120] Intelligent carpooling scenario: This scenario focuses on route optimization for multiple orders sharing, merging orders from different recipients into the same vehicle to optimize carpooling loading and delivery routes;

[0121] In one implementation, the optimal vehicle selection method in the greedy allocation core of step S3 additionally considers the degree of route compatibility and carpooling efficiency between order delivery locations when calculating incremental scores.

[0122] In step S4, the scoring dimensions are carpooling efficiency (default weight 35%), route efficiency (default weight 35%), and order fulfillment rate (default weight 30%).

[0123] 3D container loading scenario: This scenario focuses on the 3D space utilization of physical goods in a container, with each item carrying independent length, width, and height dimensions;

[0124] In the input standardization stage of step S3, when loading orders, each order is split into piece-level goods according to quantity, and each piece of goods carries independent size data; the scene sorting hook adopts whole vehicle priority sorting, placing orders that can occupy the whole vehicle at the front; the optimal vehicle selection method in the greedy allocation core adds three-dimensional space trial sorting verification in hard constraint filtering - mapping the piece-level goods of the allocated orders and the orders to be allocated together as cubes, performing layered packing judgment, and only allowing allocation when all goods can be put into the container; in the incremental scoring calculation, priority is given to reusing the already loaded vehicles to avoid the goods being scattered in too many containers; the local repair hook performs three operations: same order merging - moving piece-level goods of the same order scattered in different containers to the same container, baffle piece relocation - moving scattered pieces that hinder the main order concentration to other containers, and tail goods migration to small carts - moving large container goods with fewer than the threshold of pieces to smaller containers;

[0125] In step S4, the scoring dimensions are the three-dimensional average load rate (default weight 60%), center of gravity and stability (default weight 30%, deducted based on the number of suspended parts and the number of times overweight stacking), and aggregation degree of similar parts (default weight 10%, deducted based on the number of dispersed groups of goods).

[0126] Wave picking and delivery collaboration scenario: This scenario groups orders by wave window and coordinates the picking and delivery processes. In one implementation, the optimal vehicle selection method in the greedy allocation core of step S3 adds wave window constraints and platform processing capacity constraints to the hard constraint filtering, ensuring that the total number of orders in each wave does not exceed the upper limit of the platform processing capacity. In step S4, the scoring dimensions are wave on-time rate (default weight 35%), picking and delivery collaboration efficiency (default weight 30%), order fulfillment rate (default weight 20%), and loading utilization rate (default weight 15%).

[0127] Multimodal transport scenario: This scenario involves the combined scheduling of multiple modes of transportation, such as road, rail, and waterway;

[0128] In one implementation, the optimal vehicle selection method in the greedy allocation core of step S3 adds transit penalty constraints, carbon emission weight constraints, and upper limit constraints on the number of transport mode switching times to the hard constraint filtering, thereby optimizing overall transport efficiency while controlling carbon emissions and the number of transits. In step S4, the scoring dimensions are intermodal transport timeliness (default weight 35%), transshipment efficiency (default weight 25%), order fulfillment rate (default weight 20%), and capacity utilization (default weight 20%).

[0129] Example 3: A multi-algorithm visualization demonstration and comparative analysis system for logistics scenarios. The system includes:

[0130] Request normalization module: Obtains demonstration requests containing scene identifiers, algorithm identifiers, order data, vehicle data, rule configurations, and optimization target weights, and converts them into unified strongly typed algorithm request objects;

[0131] The strategy registration module obtains strongly typed algorithm request objects, extracts the scene identifier and algorithm identifier corresponding to each strategy instance, establishes a mapping relationship using the combination of scene identifier and algorithm identifier as the key, and generates a strategy mapping lookup table.

[0132] The strategy routing module receives strongly typed algorithm request objects, calls the strategy mapping lookup table, performs exact matching, global fallback matching, and adapter downgrade matching to obtain the target algorithm strategy instance, and combines the strongly typed algorithm request object to generate an algorithm execution context that includes scene identifier, algorithm identifier, order list, vehicle list, rule configuration, and target weight configuration.

[0133] Engine scheduling module: Based on the target algorithm strategy instance in the algorithm execution context, it determines the corresponding algorithm engine, executes the solution in automatic mode, benchmark comparison mode or degraded rollback mode, and generates algorithm results in a unified format;

[0134] Multi-objective scoring module: Collects the running indicator mapping table in the algorithm results and the target weight configuration in the algorithm execution context, calls the scoring dimension definition of the corresponding scenario, performs dimension score calculation, weight normalization processing and weighted summation calculation on the running indicators, and generates dimension score results and comprehensive score results;

[0135] Display Conversion Module: Based on algorithm results, dimensional scoring results, and comprehensive score results, it is used to convert the algorithm kernel output into key performance indicator cards, structured process logs, and natural language summaries to generate front-end display response data;

[0136] Front-end visualization module: Receives front-end display response data, performs interface rendering on key performance indicator cards, structured process logs, natural language summaries and scoring results, and generates algorithm demonstration results, multi-algorithm comparison results and scenario capability mapping results;

[0137] like Figure 1 As shown, the multi-algorithm visualization demonstration and comparative analysis system for logistics scenarios consists of three layers: the front-end display layer (corresponding to the front-end visualization module), the sandbox display layer (corresponding to the display conversion module, sandbox controller, and demonstration request completion service, etc., which are sandbox-specific components), and the algorithm kernel layer (corresponding to the request normalization module, strategy registration module, strategy routing module, engine scheduling module, and multi-objective scoring module).

[0138] The request normalization module belongs to the algorithm adaptation layer. It can be called in the sandbox display to transform loose front-end data, or it can be used as a standardized entry point for the algorithm kernel when it is not in the sandbox display layer, so that external systems can directly construct strongly typed algorithm request objects and call the algorithm service interface.

[0139] This architecture design ensures the independent deployment capability of the algorithm kernel layer—the engine scheduling module and the multi-objective scoring module can run independently without relying on the display conversion module and front-end visualization module of the sandbox display layer. Its independence is clearly constrained by the design in the system source code: the implementation of the algorithm strategy interface is prohibited from accessing any sandbox display class, the main implementation of the algorithm service does not depend on any component of the sandbox display layer, and the algorithm service facade interface is defined as a unified call entry point for external business systems, enabling the algorithm kernel to be deployed independently in different business systems such as the transportation management system.

[0140] The front-end presentation layer provides four core pages:

[0141] The algorithm demonstration page is used to display the execution process and results of a single algorithm;

[0142] The algorithm comparison page is used for horizontal comparison of multiple algorithms on the same dataset;

[0143] The algorithm matrix page displays a panoramic capability mapping between scenes and algorithms;

[0144] The data management page is used for importing, exporting, and maintaining test datasets;

[0145] The sand table display layer includes the following components:

[0146] The sandbox controller serves as the unified access point for frontend requests, responsible for receiving key-value pair format request data sent by the frontend and orchestrating the entire execution call chain.

[0147] The request normalization adapter (the request normalization module that calls the algorithm kernel layer) is responsible for mapping the loose key-value pair data of the front end to strongly typed algorithm request objects by field name, eliminating the inconsistency between the dynamic data format of the front end and the strongly typed input parameters of the algorithm kernel;

[0148] The demo request completion service is responsible for automatically completing the default order data in demo mode, so that the demo scenario can run without manual data maintenance;

[0149] The sand table display conversion service is responsible for converting the algorithm results output by the algorithm kernel into a renderingable runtime response structure for the front end;

[0150] like Figure 2 As shown, the algorithm kernel layer contains the following key components:

[0151] 1. Policy Registry: After the system service container starts, it automatically scans and injects all component instances that implement the algorithm policy interface;

[0152] In its initialization method, the policy registry iterates through all policy instances, extracts the scenario identifier and algorithm identifier declared for each instance, and uses the combination of the scenario identifier and algorithm identifier as the key. It then stores the key and the corresponding policy instance in a hash lookup table. For example, the greedy policy for a simple loading scenario uses the combination of the simple loading scenario identifier and the greedy algorithm identifier as the registration key, while the genetic algorithm policy for a complex loading scenario uses the combination of the complex loading scenario identifier and the genetic algorithm identifier as the registration key.

[0153] Instances registered later with the same key will overwrite instances registered earlier. When creating a new scene, you only need to create a strategy implementation class and add component annotations for automatic registration, without modifying the registry center code.

[0154] 2. Policy Routing Mechanism: When an algorithm execution request is received, the policy registry first performs an exact match using the combination of scene identifier and algorithm identifier as the key. If a match is found, the corresponding policy is returned. If the exact match fails, a fallback match is performed using the combination of global identifier and algorithm identifier as the key, suitable for algorithm adapters that are universal across scenarios. If the fallback match still fails, the engine-mode executor forwards the request to the general constraint planning adapter or constraint satisfaction adapter based on the algorithm identifier in the request. This three-level routing mechanism ensures the robustness of the system.

[0155] 3. Scene Rule Engine: Before the algorithm strategy is executed, the scene rule engine is responsible for merging the rule configuration, algorithm parameters and target weights in the request into a unified rule mapping table;

[0156] The rule engine maintains a rule template mapping table indexed by scenario identifier. Each scenario has a set of default rule values ​​(such as full load rate threshold, vehicle sorting preference, constraint switch, etc.).

[0157] Upon receiving a request, based on the default rules for the corresponding scenario, the user-defined rule configurations in the request are overwritten key by key on top of the default rules to generate a merged rule mapping table;

[0158] The merged rule mapping table is passed to the four-stage main link of the greedy algorithm abstract base class through the algorithm execution context, so that each stage of hard constraint filtering, priority sorting, incremental scoring and local repair can read it uniformly;

[0159] This merging mechanism allows the front end to only pass in the rule items that need to be customized, while the default values ​​of the scenario are automatically used for the rule items that are not passed in, reducing the complexity of parameter configuration for the caller;

[0160] 4. Unified scheduling across multiple engines: The engine-mode executor receives the algorithm execution context, which includes the scene identifier, algorithm identifier, engine mode, a list of order identifiers participating in the solution, a business data mapping table, and a strongly typed request object, such as... Figure 3 As shown;

[0161] The executor determines the execution method based on the engine mode enumeration value:

[0162] Automatic mode: Directly invokes the strategy matched by the route and returns the solution as the main result;

[0163] Benchmark Comparison Mode: While executing the main algorithm, the constraint planning engine and constraint satisfaction engine are called to solve the problem. The main result and the comparison result are encapsulated in the execution result encapsulation body and returned for comparison and display on the front end.

[0164] Degradation rollback mode: When the vehicle allocation scheme list of the main result is empty (i.e. all orders failed to be allocated successfully), the constraint programming engine is automatically called to solve the problem again. If the vehicle allocation scheme list of the rollback result is not empty, the main result is replaced.

[0165] 5. Greedy algorithm framework: such as Figure 4 As shown, the template method pattern is used to define a general main link, which includes four phases:

[0166] Phase 1, Input Standardization Phase: Read the order list, vehicle list, and rule configuration from the algorithm execution context, prioritizing data from strongly typed request objects; if the request object is empty (to be compatible with historical call methods), parse each key-value pair from the business data mapping table by string key name;

[0167] This stage also includes an order pre-filtering hook, which can be overridden by subclasses to implement scenario-based order filtering logic;

[0168] For example, in a dynamic order insertion scenario, the pre-filter hook can be overridden to exclude locked orders that are already in transit on locked vehicles;

[0169] Phase Two: Scenario Priority Sorting Phase: This phase calls the overridable scenario sorting hook method. Subclasses implement scenario-specific sorting logic to generate a prioritized order list. Subsequent greedy allocation processes orders in this order. The sorting strategies for different scenarios are described below:

[0170] Simple loading scenario: Adopt the strategy of prioritizing large orders and large vehicles, putting orders with larger weight and volume first, so that vehicles with large capacity are filled by large orders first.

[0171] Complex loading scenarios: Supports three sorting modes: by density, by weight, or by volume, with switching controlled by the greedy sorting mode field in the algorithm parameters;

[0172] 3D packing scenario: The whole vehicle is prioritized. The matching degree between the number of pieces in each order and the candidate vehicles is calculated, and orders that can exclusively occupy the whole vehicle are ranked first.

[0173] Phase 3, Greedy Allocation Core Phase: Traverse each order in sorted order, and for each order, call the optimal vehicle selection method to select the best vehicle from the available vehicle list. The specific process of the optimal vehicle selection method is as follows: Traverse all candidate vehicles, first perform hard constraint filtering, and determine whether the vehicle is allowed to load the current order;

[0174] Hard constraints include weight capacity limits, volume capacity limits, and scenario-specific constraints (such as the maximum number of customers per vehicle in complex loading scenarios, vehicle and order locking constraints in dynamic order insertion scenarios, and three-dimensional spatial trial arrangement verification in three-dimensional packing scenarios).

[0175] Vehicles filtered by hard constraints enter the candidate set. An incremental score is calculated for each vehicle in the candidate set. Taking into account factors such as loading utilization, scenario preference and balance, the vehicle with the highest incremental score is selected as the optimal vehicle.

[0176] If all candidate vehicles fail the hard constraint filter (i.e., there are no feasible vehicles), the order is placed in the unassigned pool.

[0177] After all orders have been iterated through, a local repair hook method is called to perform lightweight optimizations on the initial allocation results; different repair operations are implemented for different scenarios:

[0178] Simple loading and complex loading scenarios: Perform low-load vehicle merging - starting with the vehicle with the lowest loading rate, try to migrate the loaded orders of the vehicle to other vehicles with remaining capacity one by one; then directly backfill the orders in the unassigned pool and retry the single-step transfer.

[0179] 3D container loading scenario: Perform same order merging - move piece-level goods of the same order scattered in different containers to the same container; baffle piece relocation - move scattered pieces that are hindering the concentration of the main order to other containers; move leftover goods to carts - move goods in large containers with fewer than the threshold of loaded pieces to smaller containers.

[0180] Phase Four: Calculate the weight utilization rate and volume utilization rate for each vehicle. Determine the final load rate value according to the load rate calculation mode in the rule configuration: in the maximum value mode, take the larger value between weight utilization rate and volume utilization rate; in the average value mode, take the arithmetic mean of the two. Summarize the overall operational indicators such as the average load rate of all used vehicles, total transportation mileage, total number of stops, and number of constraint violations. Generate vehicle allocation plan records and route planning records for each loaded vehicle. The final algorithm output includes five parts: a vehicle allocation plan list, a route planning list, an operational indicator mapping table, a process log list, and an unallocated order list.

[0181] 6. Multi-objective scoring mechanism: such as Figure 5 As shown, the target scoring service receives the scene identifier, target weight configuration, and operational metric data. It obtains a list of scoring dimension definitions for the scene through the scene scoring plugin. Each dimension is described by a scoring dimension record, which contains five attributes: dimension identifier (internal unique number), display label (Chinese name for front-end display), default weight, optimization direction (higher is better or lower is better), and scoring formula.

[0182] The target weight parser parses the weight mapping passed in by the user. Internally, it maintains an alias mapping table to uniformly map the various weight key names (including abbreviations, historical names, etc.) that the user may use to standard internal dimension identifiers.

[0183] This mapping allows the front end to flexibly use different weight parameter names without modifying the algorithm kernel;

[0184] After obtaining the weight mapping, filter out dimensions with original weights equal to zero. If all dimension weights are zero after filtering, revert to using the default weights for the current scenario.

[0185] The original weights of the effective dimensions are normalized by dividing the original weight of each dimension by the sum of the original weights of all effective dimensions, so that the sum of the weights of each dimension after normalization equals 1.

[0186] The scene scoring plugin calculates the raw score (0 to 100 points) for each dimension based on the scoring formula for each dimension, and then calculates the comprehensive score using a weighted summation formula. The weighted summation formula is as follows:

[0187] S = Σ(wi × si).

[0188] Where S represents the overall score (ranging from 0 to 100), Σ represents the summation over all valid scoring dimensions, i is the index of the scoring dimension (ranging from 1 to the total number of valid dimensions n), n is the total number of valid dimensions participating in the scoring, wi is the normalized weight of the i-th scoring dimension, and si is the original score of the i-th scoring dimension (ranging from 0 to 100).

[0189] The default weights and scoring formulas for the core scoring dimensions of each scenario are defined as follows: Simple loading scenario: Average load factor (weight 50%), scoring formula:

[0190] S1 = Ravg × 100.

[0191] Where S1 represents the comprehensive score of the average load factor dimension, and Ravg is the arithmetic mean of the load factor of all used vehicles.

[0192] The scoring formula for the capacity utilization dimension (weight 30%) is as follows:

[0193] S2 = (Vmin / Vused) × 100.

[0194] Among them, S2 is the comprehensive score of the capacity intensification dimension, Vmin is the theoretical minimum number of vehicles calculated based on the maximum load capacity of the vehicles, and Vused is the actual number of vehicles in use;

[0195] Order fulfillment rate (weight 20%), scoring formula:

[0196] S3 = (Nassigned / Ntotal) × 100.

[0197] Where S3 is the comprehensive score of the order fulfillment rate dimension, Nassigned is the number of successfully assigned orders, and Ntotal is the total number of orders participating in the solution;

[0198] Complex loading scenarios: Average load factor (weight 35%), order fulfillment rate (weight 30%), emergency response rate (weight 20%), scoring formula:

[0199] Sp=(Np1assigned / Np1total)×100.

[0200] Among them, Sp is the comprehensive score of the emergency guarantee rate dimension, Np1assigned is the number of emergency orders assigned, and Np1total is the total number of emergency orders. When the total number of emergency orders is zero, 100 points are awarded directly.

[0201] The dimensions of capacity utilization (weight 15%) and business compliance (weight zero, not included in the overall score) are deducted based on the number of times constraints are violated.

[0202] Urban delivery scenario: Timeliness achievement rate (weight 40%), scoring formula:

[0203] St = Ton × 100.

[0204] Among them, St is the comprehensive score of the timeliness achievement rate dimension, and Ton is the on-time delivery rate;

[0205] Line efficiency dimension (weight 30%), scoring formula:

[0206] Sr=1000 / (1000+Dtotal)×100.

[0207] Among them, Sr is the comprehensive score of the route efficiency dimension, Dtotal is the total transportation mileage in kilometers; and the order fulfillment rate dimension (weight 30%).

[0208] Trunk line single route scenario: vehicle utilization rate (weight 35%), route loading rate (weight 35%), order fulfillment rate (weight 30%).

[0209] Multi-line trunk route scenario: Overall cost dimension (weight 35%), scoring formula:

[0210] Sc=Cref / (Cref+Cactual)×100.

[0211] Where Sc is the comprehensive score of the comprehensive cost dimension, Cref is the reference cost base (Cref can be an empirical value, such as 10000), and Cactual is the actual total cost of the algorithm solution;

[0212] Multi-line efficiency (weight 30%), timeliness achievement rate (weight 20%), and order fulfillment rate (weight 15%).

[0213] Dynamic order insertion scenario: order insertion timeliness (weight 45%), order fulfillment rate (weight 30%), disturbance control (weight 25%).

[0214] Intelligent carpooling scenario: carpooling efficiency (weight 35%), route efficiency (weight 35%), and order fulfillment rate (weight 30%).

[0215] 3D Packing Scenario: 3D Average Load Rate Dimension (Weight 60%), Scoring Formula:

[0216] Sv = Vutil × 100.

[0217] Among them, Sv is the comprehensive score of the three-dimensional average full load rate dimension, Vutil is the three-dimensional volume utilization rate, the center of gravity and stability dimension (weight 30%) is calculated by deducting points based on the number of suspended parts and the number of times of overweight stacking, and the aggregation degree dimension of similar parts (weight 10%) is calculated by deducting points based on the number of dispersed groups of goods.

[0218] Wave picking and packing collaboration scenario: Wave on-time rate (weight 35%), picking and packing collaboration efficiency (weight 30%), order fulfillment rate (weight 20%), loading utilization rate (weight 15%).

[0219] Multimodal transport scenarios: intermodal transport timeliness (weight 35%), transshipment efficiency (weight 25%), order fulfillment rate (weight 20%), and capacity utilization (weight 20%).

[0220] 7. Visualization and Conversion: The sandbox display and conversion service converts the algorithm results output by the algorithm kernel into a front-end renderable runtime response structure: It dynamically generates key performance indicator cards based on the optimization target weight configuration, generating corresponding indicator cards only for dimensions with weights greater than zero. Each card contains four fields: indicator key, display label, value, and unit. The calculation time card is always displayed. The algorithm process log is converted into a structured log object, with each log entry containing a timestamp, log level, and text content. Log levels are divided into information level, warning level, and error level. It generates a natural language format result summary, including fixed template text such as "A total of N orders were processed, with M orders successfully allocated" and "The average load factor of the solution is X%, with a total of Y vehicles used."

[0221] 8. Comparative analysis of multiple algorithms: such as Figure 6 As shown, the front-end algorithm comparison page allows users to add multiple algorithm scheme entries in the same scenario, and each entry can independently select the algorithm engine and parameter configuration;

[0222] During execution, the system sequentially calls each algorithm engine to solve the problem under the same order dataset and constraints, and calls the comparison scoring and filling method to fill the scoring items and comprehensive score for each solution result;

[0223] The front end uses a table to horizontally compare the scores of each solution across different dimensions and the overall score. It supports importing manual scheduling solutions as a benchmark solution and displays the degree of improvement of the algorithm solution relative to the benchmark solution by calculating the relative deviation.

[0224] The above are merely specific embodiments of the present invention, but the scope of protection of the present invention is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in the present invention should be included within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A method for visual demonstration and comparative analysis of multiple algorithms in logistics scenarios, characterized in that, Includes the following steps: S1. Contextual Request Standardization: Receives demonstration requests from logistics scenarios containing scenario identifiers, algorithm identifiers, order data, vehicle data, rule configurations, and optimization target weights. A request normalization adapter converts input data of different formats into a unified strongly typed algorithm request object. S2. Policy Registration and Automatic Routing: Reads scenario identifiers and multiple algorithm identifiers based on the strongly typed algorithm request object. Inputs these identifiers into the policy registration center. Upon system startup, it automatically scans and collects all component instances that implement the algorithm policy interface. A hash table is constructed using the combination of scenario identifiers and algorithm identifiers as the query key. The system matches the corresponding target algorithm policy in the policy registration center, prioritizing scenario-specific policies. If no match is found, a general policy is searched based on the combination of global identifiers and algorithm identifiers. If still no match is found, the system degrades to the general algorithm adapter, ultimately outputting a set of target algorithm policies. S3, Unified scheduling and execution of multiple engines: The target algorithm strategy is passed to the engine mode executor, which calls the corresponding algorithm engine to solve the problem and returns the algorithm results in a unified format. The algorithm engines include greedy engine, constraint planning engine, constraint satisfaction engine and metaheuristic engine. The returned algorithm results include a list of vehicle allocation schemes, a list of route planning, a map of operation indicators and a list of process logs. The engine-mode executor supports three execution modes: in automatic mode, it directly routes to the registered strategy for execution and returns the main result; In benchmark mode, the constraint planning engine and constraint satisfaction engine are executed in parallel as reference data while the main algorithm is being executed; in degraded rollback mode, when the main algorithm returns an empty solution, the constraint planning engine is automatically called to solve the problem again, and if the rollback result is not empty, it replaces the main result; S4, multi-objective weighted scoring; S5, Visualization and Transformation; S6. Comparative analysis of multiple algorithms.

2. The method for multi-algorithm visualization demonstration and comparative analysis of logistics scenarios according to claim 1, characterized in that, In step S3: the execution chain of the greedy engine is implemented based on the abstract base class of the greedy algorithm, and includes four stages: Stage 1, Input standardization, parsing the order list, vehicle list and rule configuration, prioritizing reading data from strongly typed request objects, and if the strongly typed request is empty, falling back to parsing the key-value pairs in the business data mapping table; Stage 2, Scene priority sorting, using an overwriteable scene sorting hook method to prioritize orders according to business needs; Stage 3, Greedy allocation core, traversing the sorted order list, calling the optimal vehicle selection method for each order to select the best loading vehicle from available vehicles, orders without feasible vehicles enter the unallocated pool, and calling the local repair hook method for lightweight optimization after all orders are allocated; Stage 4, Result projection, summarizing the load factor, cost, and time efficiency indicators to generate algorithm results in a unified format.

3. The method for multi-algorithm visualization demonstration and comparative analysis of logistics scenarios according to claim 1, characterized in that, In step S4, the specific process of multi-objective weighted scoring is as follows: obtain the scoring dimension definition of the current scene through the scene scoring plugin. Each dimension includes dimension identifier, display label, default weight, optimization direction and scoring formula; parse the optimization target weight configuration passed by the user, and use the scene default weight when the user does not specify the weight; Filter out the valid dimensions whose original weights are greater than zero; normalize the valid weights so that the sum of the weights of each dimension after normalization equals 1; The scene scoring plugin calculates the raw scores for each dimension, and then calculates the comprehensive score by weighted summation with the normalized weights using a formula.

4. The method for multi-algorithm visualization demonstration and comparative analysis of logistics scenarios according to claim 1, characterized in that, In step S1: after receiving the demonstration request and before executing the algorithm solution, a request integrity verification step is also included: verifying the integrity of the scene identifier, algorithm identifier, order list and vehicle list in the request; after the routing result is output in step S2, a scene rule loading step is also included: merging the rule configuration, algorithm parameters and target weight in the request into the rule template through the scene rule engine.

5. The method for multi-algorithm visualization demonstration and comparative analysis of logistics scenarios according to claim 1, characterized in that, In step S5, the visualization transformation includes: dynamically generating key performance indicator cards based on the optimization target weight configuration, each card containing an indicator key, display label, value, and unit; the calculation time card is always displayed; converting the algorithm process log into a structured log object, each log containing a timestamp, log level, and text content, with log levels divided into information level, warning level, and error level; and generating a result summary in natural language format, including the number of orders processed, the number of successful allocations, the average full load rate of the plan, and the number of vehicles used.

6. The method for multi-algorithm visualization demonstration and comparative analysis of logistics scenarios according to claim 1, characterized in that, In step S1, the normalization adapter uses an object mapper to map the loose key-value pairs passed from the front end to strongly typed algorithm request objects according to the field names; in step S2, the registration mechanism of the policy registry is as follows: each algorithm policy implementation class is marked with a declarative annotation. When the system container starts, it automatically scans and collects all marked policy implementations. Based on the scene identifier and algorithm identifier declared by each policy implementation, the combination of scene identifier and algorithm identifier is used as the key to store the information in the lookup table.

7. The method for multi-algorithm visualization demonstration and comparative analysis of logistics scenarios according to claim 1, characterized in that, Step S4 specifically involves: extracting the running indicator mapping table from the algorithm results in a unified format; performing multi-dimensional scoring on the running indicators output by the algorithm based on the scoring dimensions defined by the scene scoring plugin and the optimization target weights set by the user; normalizing the weights of each dimension and calculating the comprehensive score using a weighted summation formula; Step S5 specifically involves: calculating the comprehensive score and combining it with the unified format algorithm results; converting the comprehensive score and algorithm results into a presentation layer structure; and presenting the algorithm execution process and optimization results through a front-end visual interface; Step S6 specifically involves: based on the presentation layer request, under the same dataset and constraints, the system executes multiple algorithm engines sequentially or in parallel through the engine scheduling module; comparing the scoring items and comprehensive scores of each solution horizontally; supporting the import of benchmark solutions and relative deviation analysis; and finally generating multi-algorithm comparison analysis results.

8. A multi-algorithm visualization demonstration and comparative analysis system for logistics scenarios, characterized in that: The system is used for the multi-algorithm visualization demonstration and comparative analysis method for logistics scenarios as described in any one of claims 1-7. The system comprises: a request normalization module: acquiring a demonstration request containing scenario identifiers, algorithm identifiers, order data, vehicle data, rule configurations, and optimization target weights, and converting it into a unified strongly typed algorithm request object; a strategy registration module: acquiring the strongly typed algorithm request object, extracting the scenario identifier and algorithm identifier corresponding to each strategy instance, establishing a mapping relationship using the combination of scenario identifiers and algorithm identifiers as keys, and generating a strategy mapping lookup table; a strategy routing module: receiving the strongly typed algorithm request object, calling the strategy mapping lookup table, performing exact matching, global fallback matching, and adapter downgrade matching to obtain the target algorithm strategy instance, and combining the strongly typed algorithm request object to generate an algorithm execution context containing scenario identifiers, algorithm identifiers, order lists, vehicle lists, rule configurations, and target weight configurations; and an engine scheduling module: based on algorithm execution... The target algorithm strategy examples below identify the corresponding algorithm engine, execute the solution according to automatic mode, benchmark comparison mode, or fallback mode, and generate algorithm results in a unified format; Multi-objective scoring module: collects the running indicator mapping table in the algorithm results and the target weight configuration in the algorithm execution context, calls the scoring dimension definition of the corresponding scenario, performs dimension score calculation, weight normalization processing, and weighted summation calculation on the running indicators, and generates dimension score results and comprehensive score results; Display conversion module: based on the algorithm results, dimension score results, and comprehensive score results, it is used to convert the algorithm kernel output into key performance indicator cards, structured process logs, and natural language summaries, and generate front-end display response data; Front-end visualization module: receives the front-end display response data, performs interface rendering on key performance indicator cards, structured process logs, natural language summaries, and scoring results, and generates algorithm demonstration results, multi-algorithm comparison results, and scenario capability mapping results.

9. The logistics scenario multi-algorithm visualization demonstration and comparative analysis system according to claim 8, characterized in that: The engine scheduling module outputs algorithm result objects in a unified format. The multi-objective scoring module outputs dimensional scoring results and comprehensive scoring results based on the algorithm result objects. The display and conversion module generates display data based on the algorithm result objects.

10. The logistics scenario multi-algorithm visualization demonstration and comparative analysis system according to claim 9, characterized in that: The engine scheduling module and the multi-objective scoring module can operate independently without the display conversion module and the front-end visualization module, and provide algorithm service interfaces to external systems.

Images