An algorithm result natural language post-processing and versioning checking method and system

Abstract

This invention discloses a method and system for natural language post-processing and version verification of algorithm results, belonging to the field of algorithm result processing technology. The method includes: receiving requests for local adjustments to a completed algorithm task using natural language; reading the task context and summarizing it into an adjustment request summary, generating an adjustment strategy; generating script code in rounds and sequentially executing compilation verification, execution verification, and business constraint verification; after all verifications pass, writing the post-processing result as a post-processing type version into a version list, retaining the original algorithm type version; if verification fails, recording the failure information and proceeding to the next round or terminating. This invention achieves local adjustments without completely rerunning the algorithm, ensures result reliability through three levels of verification, and achieves unified version management of the original result and the post-processing result.

Description

Technical Field

[0001] This invention relates to the field of algorithm result processing technology. Specifically, it relates to a method and system for natural language post-processing and version verification of algorithm results, which is applicable to local result adjustment scenarios after the completion of algorithm tasks such as bin packing algorithm, path planning, production scheduling, and inventory allocation. Background Technology

[0002] In decision-making platform algorithm assistants, after an algorithm task is completed, users may only be dissatisfied with a partial result, such as requesting the removal of goods from a certain pickup point or adjusting part of the loading result. Existing algorithm platforms typically require reconfiguring parameters and rerunning the entire algorithm, which has the following drawbacks: First, adjusting partial results requires rerunning the entire algorithm, resulting in high computational costs and waiting time; second, general code generation lacks binding to algorithm result tables, input tables, and business constraints, which may disrupt the consistency of loading constraints or key performance indicators; third, existing solutions lack a round-based failure retry and verification process display, making it difficult to trace the reasons for adjustment failures; fourth, the original algorithm results and post-processed results lack unified version management, making it difficult for users to compare and roll back. Summary of the Invention

[0003] The present invention aims to solve the above-mentioned technical problems and provide a solution for making local and verifiable adjustments to the results of a completed algorithm without having to completely rerun the algorithm.

[0004] To achieve the above objectives, the present invention provides the following technical solution:

[0005] A method for natural language post-processing and version verification of algorithm results includes:

[0006] Receive requests for local adjustments to natural language for completed algorithmic tasks;

[0007] Read the task context of the algorithm task, which includes at least an input table, an output table, a parameter table, a task identifier, a version list, and constraint verification items;

[0008] The natural language requests are summarized into an adjustment request summary, and an adjustment strategy is generated based on the task context;

[0009] Generate script code to modify the algorithm results for each round, and record the round number, strategy text and code text for each round;

[0010] Perform compilation verification on the generated script code and record the compilation verification results;

[0011] If the compilation verification passes, the script code is executed to generate the post-processing result, and an execution verification is performed after execution is completed, while the execution verification result is recorded.

[0012] If the verification passes, then perform business constraint verification on the generated post-processing result and record the business constraint verification result;

[0013] If the business constraint verification passes, the post-processing result is written into the version list of the same algorithm task, and the request type of the post-processing result is marked as the post-processing type. At the same time, the original algorithm result is retained and marked as the algorithm type.

[0014] If any of the compilation verification, execution verification, or business constraint verification fails, the failure information is recorded, and the process proceeds to the next round or terminates the current process.

[0015] In the above method, entering the next round includes: using the verification result of the current round's failure as supplementary context, regenerating the adjustment strategy and script code, and recording it as a new round. This round retry mechanism can iteratively correct errors or constraint conflicts in the generated code, improving the success rate of post-processing.

[0016] In the above method, the passing criteria for compilation verification include: correct script syntax, existence of the entry function, availability of dependent libraries, referenced table names and field names belonging to the current task context, and no prohibited items that override the original version or involve unauthorized access. The passing criteria for execution verification include: the script terminates normally in the restricted workspace, does not time out, and generates a post-processing result table. The passing criteria for business constraint verification include: all preset strong constraint verification items for the algorithm results are without anomalies. Through the closed-loop design of the three-level verification, the risk of generated code compromising the usability of algorithm results is effectively reduced.

[0017] In the above method, each version object in the version list includes at least a request identifier, version name, request type, parent request identifier, and creation time; wherein, the request type includes an algorithm type for identifying the original algorithm result and a post-processing type for identifying the post-processing result. Distinguishing between ALGO / POST_PROCESS versions facilitates backtracking, comparison, and auditing.

[0018] In the above method, summarizing the natural language requests into an adjustment request summary includes: determining the set of read tables and the set of write tables required for this post-processing based on the task context.

[0019] The present invention also provides a system for natural language post-processing and version verification of algorithm results for implementing the aforementioned algorithm result natural language post-processing and version verification method, comprising:

[0020] The request receiving module is used to receive requests for local adjustments to the natural language for completed algorithm tasks;

[0021] The context reading module is used to read the task context of the algorithm task. The task context includes at least an input table, an output table, a parameter table, a task identifier, a version list, and constraint verification items.

[0022] The target summarization module is used to summarize the natural language requests into an adjustment request summary and generate adjustment strategies;

[0023] The code generation and round management module is used to generate script code for modifying algorithm results by round, and to record the round number, strategy text and code text for each round;

[0024] The compilation verification module is used to perform compilation verification on the generated script code and record the compilation verification results;

[0025] The execution verification module is used to execute the script code to generate post-processing results after the compilation verification is passed, and to perform execution verification after execution is completed, while recording the execution verification results.

[0026] The business constraint verification module is used to perform business constraint verification on the generated post-processing result after the verification is passed, and to record the business constraint verification result.

[0027] The version management module is used to write the post-processing result as the post-processing type version into the version list when the business constraint verification passes, and to retain the original algorithm type version.

[0028] In the above system, the code generation and round management module is further configured to receive failure information and trigger a new round of strategy and code generation when any of the compilation verification, execution verification or business constraint verification fails.

[0029] In the above system, the version management module is specifically used to: save the original algorithm results in the original output table, save the post-processing results in the post-processing output table, and associate the post-processing results with the post-processing type version under the same algorithm task through the version field.

[0030] In the above system, the business constraint verification includes at least one of the following strong constraints: support anomaly, boundary anomaly, overlap anomaly, heavy weight not pressing on light weight, overweight anomaly, partition anomaly, number of layers anomaly, height anomaly, direction anomaly, and cabinet tail anomaly.

[0031] In summary, compared with the prior art, the beneficial effects of the present invention are reflected in the following aspects:

[0032] Efficiency improvement: Without having to completely rerun the algorithm, the completed algorithm results can be directly post-processed locally, reducing the response time from hours to minutes or even seconds.

[0033] Reliability assurance: Through a three-level closed loop of compilation verification, execution verification, and business constraint verification, we ensure that the post-processing results are syntactically correct, run without exception, and meet all strong business constraints.

[0034] Version traceability: The original result (ALGO) and the post-processed result (POST_PROCESS) coexist as independent versions, supporting arbitrary switching, comparison and rollback, meeting audit requirements.

[0035] Failure transparency: The strategy, code, validation results and logs for each round are recorded, and users can clearly understand the specific reasons for the adjustment failure (whether it is a syntax error, execution timeout or failure of a certain business constraint), which makes it easier to locate the problem.

[0036] Natural language interaction: Users do not need to learn the underlying data structures and script syntax; they can accurately adjust the algorithm results through natural language, thus lowering the barrier to entry. Attached Figure Description

[0037] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort, wherein:

[0038] Figure 1 The structural block diagram of the natural language post-processing and version verification system for the algorithm results provided by this invention. Detailed Implementation

[0039] To make the objectives, technical solutions, and advantages of this invention clearer, the technical solutions of this invention will be described in detail below with reference to preferred embodiments. This preferred embodiment uses natural language post-processing of the results of a bin packing / loading algorithm as a specific application scenario, but this invention is not limited to this and can be extended to algorithmic tasks such as path planning, production scheduling, and inventory allocation.

[0040] This invention provides a method for natural language post-processing and version verification of algorithm results, including:

[0041] Step S1: Receive requests for local adjustments to the natural language for the completed algorithm task;

[0042] Step S2: Read the task context of the algorithm task. The task context includes at least an input table, an output table, a parameter table, a task identifier, a version list, and constraint verification items.

[0043] Step S3: Summarize the natural language requests into an adjustment request summary, and generate an adjustment strategy based on the task context;

[0044] Step S4: Generate script code for modifying the algorithm results according to the round, and record the round number, strategy text and code text for each round;

[0045] Step S5: Perform compilation verification on the generated script code and record the compilation verification results;

[0046] Step S6: If the compilation verification passes, the script code is executed to generate the post-processing result, and the execution verification is performed after the execution is completed, while the execution verification result is recorded.

[0047] Step S7: If the verification passes, perform business constraint verification on the generated post-processing result and record the business constraint verification result;

[0048] Step S8: If the business constraint verification passes, the post-processing result is written into the version list of the same algorithm task, and the request type of the post-processing result is marked as the post-processing type. At the same time, the original algorithm result is retained and marked as the algorithm type.

[0049] Step S9: If any of the verifications—compilation verification, execution verification, or business constraint verification—fail, record the failure information and proceed to the next round or terminate the current processing.

[0050] In step S2, each version object in the version list includes at least a request identifier, version name, request type, parent request identifier, and creation time; wherein, the request type includes an algorithm type for identifying the original algorithm result and a post-processing type for identifying the post-processing result.

[0051] In step S3, summarizing the natural language requests into an adjustment request summary includes: determining the set of read tables and the set of write tables required for this post-processing based on the task context.

[0052] In step S6, the passing criteria for the compilation verification include: correct script syntax, existence of entry function, availability of dependent libraries, referenced table names and field names belonging to the current task context, and no prohibited items such as overwriting the original version or unauthorized access were hit.

[0053] In step S7, the passing criteria for the execution verification include: the script ends normally in the restricted workspace, does not time out, and generates a post-processing result table;

[0054] In step S8, the passing criteria for the business constraint verification include: all preset strong constraint verification items for the algorithm results are without abnormalities.

[0055] In step S9, entering the next round includes: using the verification result of the current round failure as supplementary context, regenerating the adjustment strategy and script code, and recording it as a new round.

[0056] like Figure 1 As shown, the present invention also provides an algorithm result natural language post-processing and version verification system for implementing the aforementioned algorithm result natural language post-processing and version verification method, including a request receiving module 1, a context reading module 2, a target summarization module 3, a code generation and round management module 4, a compilation verification module 5, an execution verification module 6, a business constraint verification module 7, and a version management module 8.

[0057] The request receiving module 1 is used to receive requests for local adjustments to natural language for completed algorithm tasks.

[0058] The context reading module 2 is used to read the task context of the algorithm task. The task context includes at least an input table, an output table, a parameter table, a task identifier, a version list, and constraint verification items.

[0059] The target summarization module 3 is used to summarize the natural language requests into an adjustment request summary and generate adjustment strategies.

[0060] The code generation and round management module 4 is used to generate script code for modifying algorithm results by round, and to record the round number, strategy text and code text for each round.

[0061] The code generation and round management module 4 is further configured to receive failure information and trigger a new round of strategy and code generation when any of the compilation verification, execution verification or business constraint verification fails.

[0062] The compilation verification module 5 is used to perform compilation verification on the generated script code and record the compilation verification results.

[0063] The execution verification module 6 is used to execute the script code to generate post-processing results after the compilation verification is passed, and to perform execution verification after execution is completed, while recording the execution verification results.

[0064] The business constraint verification module 7 is used to perform business constraint verification on the generated post-processing result after the verification is passed, and record the business constraint verification result.

[0065] The business constraint verification includes at least one of the following strong constraints: support anomaly, boundary anomaly, overlap anomaly, heavy weight not pressing on light weight, overweight anomaly, partition anomaly, number of layers anomaly, height anomaly, direction anomaly, and cabinet tail anomaly.

[0066] The version management module 8 is used to write the post-processing result as a post-processing type version into the version list when the business constraint verification passes, and to retain the original algorithm type version.

[0067] Furthermore, the version management module 8 is specifically used to: save the original algorithm results in the original output table, save the post-processing results in the post-processing output table, and associate the post-processing results with the post-processing type version under the same algorithm task through the version field.

[0068] The following detailed description of the algorithm result natural language post-processing and version verification method and system provided by the present invention is based on specific embodiments.

[0069] Example 1

[0070] I. System Architecture and Data Structure;

[0071] In this embodiment, the algorithm context is stored in Markdown format with explicit semantic block constraints, including algorithm description (objective, constraints, formula description), parameter description, and input / output table structure field description.

[0072] 1. Algorithm context example;

[0073] The algorithm description section outlines the goal of the bin packing algorithm: to maximize container space utilization and weight load rate while satisfying various constraints. These constraints include: support constraints, boundary constraints, overlap constraints, heavy-weight-to-light constraint, overload constraint, partitioning constraints, layer number constraints, height constraints, orientation constraints, and cabinet rear constraints. The formulas define volume utilization as: load_rate_vol = total_volume / container_volume, and weight utilization as: load_rate_wgt = total_weight / weight_limit.

[0074] 2. Input data structure;

[0075] The cargo information table (cargo_info) contains the following fields:

[0076] sku_id: SKU identifier for goods;

[0077] order_id: Order identifier;

[0078] pickup_loc: pickup point;

[0079] pkg_type: Packaging type;

[0080] length, width, height: length, width and height of the goods (unit: mm);

[0081] weight: Cargo weight (unit: kg);

[0082] volume: cargo volume (unit: mm³);

[0083] num: Quantity of goods;

[0084] container_type: Allowed container types;

[0085] The container information table (container_info) contains the following fields:

[0086] type: Container type;

[0087] inner_length, inner_width, inner_height: The inner length, width, and height of the container (unit: mm);

[0088] weight_limit: Weight limit (unit: kg);

[0089] 3. Output Data Structure

[0090] After the original algorithm executes successfully, the following output table is generated:

[0091] The loading result table (udt_loading_result) contains the following fields:

[0092] seq: Loading sequence number;

[0093] sku_id: SKU identifier for goods;

[0094] pos_x, pos_y, pos_z: Coordinates of the goods within the container (unit: mm);

[0095] x_length, y_length, z_length: The dimensions occupied by the goods after placement;

[0096] container_type: The type of container it contains;

[0097] The Key Performance Indicator (udt_loading_kpi) table contains the following fields:

[0098] load_sku_num: Number of SKUs loaded;

[0099] total_weight: Total loaded weight (kg);

[0100] total_volume: Total loading volume (mm³);

[0101] load_rate_vol: Volume utilization rate (%)

[0102] load_rate_wgt: Weight utilization rate (%);

[0103] left_sku_num: Number of remaining SKUs;

[0104] Inter-table association methods: The cargo table and the loading result table are associated through sku_id; the container table, the loading result table, and the key performance indicator table are associated through container_type; version results are distinguished through request_id.

[0105] 4. Business constraint validation items;

[0106] In this embodiment, the business constraint verification includes 10 strong constraint items, each of which contains the following attributes:

[0107] descriptions: A textual description of the target being verified;

[0108] qlScript: An SQL script used to perform validation;

[0109] hardConstraint: Whether it is a hard constraint (all 10 items in this embodiment are hard constraints);

[0110] It should be noted that the following 10 strong constraints are merely specific examples in the bin packing algorithm implementation of this invention and do not constitute a general limitation on the scope of business constraint verification. In other application scenarios (such as path planning, production scheduling, etc.), the business constraint verification items can be adjusted accordingly based on actual needs.

[0111] The 10 strong constraints and their brief descriptions are as follows:

[0112] Abnormal support: The supporting area under suspended goods must reach the prescribed ratio (e.g., supporting area / bottom area of ​​goods ≥ 70%).

[0113] Boundary anomaly: The coordinates and dimensions of all cargo must be within the container boundary, i.e., pos_x + x_length ≤ container_length, pos_y + y_length ≤ container_width, pos_z + z_length ≤ container_height.

[0114] Overlap Anomaly: Any two loaded goods cannot have overlapping volumes in three-dimensional space. The determination condition is: for goods A and B, the necessary and sufficient condition for non-overlap is that A.pos_x + A.x_length ≤ B.pos_x or B.pos_x + B.x_length ≤ A.pos_x or A.pos_y + A.y_length ≤ B.pos_y or B.pos_y + B.y_length ≤ A.pos_y or A.pos_z + A.z_length ≤ B.pos_z or B.pos_z + B.z_length ≤ A.pos_z.

[0115] The heavier item must not be heavier than the lighter item: the weight of the item above must not exceed the weight of the item below. That is, for item A above item B, the weight_A ≤ weight_B must be satisfied.

[0116] Overweight exception: The total weight loaded inside the container must not exceed the container weight limit, i.e., Σweight ≤ weight_limit.

[0117] Partitioning error: The cargo must be placed in its permitted container partition or type, i.e., cargo.container_type = container.type.

[0118] Layer error: The number of stacked layers must not exceed the preset maximum layer limit.

[0119] Height error: The total stack height must not exceed the container height.

[0120] Orientation error: The orientation of the goods must conform to the permitted rotation direction (e.g., not allowed to stand on their side).

[0121] Container rear abnormality: Goods near the rear of the container must meet special requirements for fixing or leaving empty.

[0122] II. Technical routes for converting natural language into post-processing targets;

[0123] After receiving a user's natural language request, the system first binds the current algorithm task context, including task identifier, task version, algorithm scheme, input table, output table, field structure, sample data, existing execution results, and available constraint validation items.

[0124] The system then summarizes user requests into a "Summary of Adjustment Requests." This summary describes the objects and goals that the user wishes to adjust. In this implementation, the Summary of Adjustment Requests may not necessarily be a complete JSON object, but mainly reflects the context constraints required for subsequent strategies and script generation: which tables need to be read, which tables are allowed to be written to, which task version to use for processing, and the approximate scope of the objects to be processed.

[0125] For example, in a packing scenario, when a user requests to "remove goods with pickup point 22D," the system combines the goods information table, loading result table, and key performance indicator (KPI) table to generate a post-processing strategy: It identifies goods with pickup point 22D from the goods information table, reads the original loading results and KPIs, and generates a post-processing loading result table and a post-processing KPI table. The technical route for converting natural language to the post-processing target can be summarized as follows: Natural language request → Task context binding → Adjustment request summary → Clarifying table reading and writing → Generating the current round's adjustment strategy → Generating the script and entering the third-level validation. If the request cannot be located in a table or field, or if the adjustment target conflicts with business constraints, it enters a failure round and outputs the reason for the failure.

[0126] In this way, by using the above conversion technology, users do not need to understand the underlying data structure and algorithm details. They can simply express their adjustment intentions in natural language, and the system can automatically bind the context and generate an executable post-processing solution, which greatly reduces the threshold for use.

[0127] III. Round-based script generation and retry mechanism;

[0128] In this embodiment, post-processing is performed in rounds, and each round includes the following core components:

[0129] roundNumber: Round number;

[0130] strategy: Strategy description (Markdown format);

[0131] code: The generated script code (Python format);

[0132] codeChecks: Verifies the results of code compilation and execution (returned by the editor);

[0133] validationDetail: Business constraint validation results and details;

[0134] The script is generated by the large model (thinking model) based on the algorithm content and constraints, first generating a post-processing adjustment strategy, and then generating post-processing adjustment code. The server compiles and executes the code in a sandbox environment (i.e., a "restricted workspace"). If editing or execution verification fails, the verification result is added as context, requiring the large model to adjust the strategy and regenerate the code. This process is recorded as a new round.

[0135] Specifically, a typical post-processing workflow is as follows:

[0136] Round 1 (Initial Attempt):

[0137] User request: "Remove the goods with pick-up point 22D";

[0138] The system generates an adjustment strategy: Query the SKU list with pickup_loc='22D' in the cargo information table; delete the loading records corresponding to these SKUs from the original loading result table; and recalculate the KPIs.

[0139] The system generates a Python script containing logic for reading the original result table, filtering and deleting target goods, writing to the post-processing result table, and updating KPIs.

[0140] Compilation verification: The script syntax is correct, the dependencies are available, and the compilation is successful.

[0141] Execution verification: The script completed its execution in the sandbox and terminated normally, generating a post-processing result table. The verification was successful.

[0142] Business constraint verification: The loading results showed that after deleting goods, some goods lost their support (there were other goods on top of the originally deleted goods), and the support anomaly verification failed.

[0143] Round 2 (Retry):

[0144] The system uses the verification results supporting the anomaly as supplementary context to regenerate the adjustment strategy: not only should the target goods be deleted, but the affected goods should also be reloaded or repositioned.

[0145] Generate a new Python script that includes the reload algorithm.

[0146] Perform the three-level verification again.

[0147] If successful, the result is written to the post-processing version; if it still fails, the process can proceed to the next round or terminate.

[0148] In this way, by demonstrating the round-based failure retry and verification process, the system can approximate a feasible solution in an iterative manner, while users can clearly trace the reason for each failure, making it easier to locate constraint conflicts.

[0149] IV. Specific judgment criteria for Level 3 verification;

[0150] Level 1: Compilation verification;

[0151] The standards include:

[0152] The script syntax is correct (no Python syntax errors);

[0153] An entry function exists (e.g., def post_process():).

[0154] Dependency libraries are available (the imported libraries are pre-installed in the sandbox environment);

[0155] The referenced table name and field name belong to the current task context (e.g., the table contains a pickup_loc field);

[0156] No violation of the restrictions on overwriting the original version or unauthorized access (e.g., the script must not contain DROP or DELETE operations on the original udt_loading_result table, and only writes to the copy table with the _post_process suffix are allowed).

[0157] If any of the above problems occur, the compilation and verification will fail.

[0158] Level 2: Perform verification;

[0159] The standards include:

[0160] The script terminated normally after execution in the restricted workspace (sandbox) without any uncaught exceptions;

[0161] Execution did not time out (default timeout is 60 seconds, which can be configured according to algorithm complexity);

[0162] After execution, a post-processing result table (e.g., udt_loading_result_post_process) is generated.

[0163] If the script exits abnormally, times out, fails to generate the target table, or the output structure does not meet the requirements, the execution verification is deemed to have failed.

[0164] Level 3: Business constraint verification;

[0165] The passing standard is: all preset strong constraint verification items are normal, and the overall checkSuccess ≡ true. In this embodiment, all 10 strong constraints (support, boundary, overlap, heavy weight not pressing on light weight, overweight, partition, number of layers, height, direction, and cabinet tail) must pass.

[0166] Taking boundary verification as an example, the judgment logic is as follows: For each loaded cargo in the post-processing result table, verify whether its endpoint coordinate (the sum of the starting coordinate and the cargo length) in the x-direction exceeds the internal length of the container, whether its endpoint coordinate in the y-direction exceeds the internal width of the container, and whether its endpoint coordinate in the z-direction exceeds the internal height of the container. If any cargo exceeds the container boundary in any direction, the boundary verification fails.

[0167] Taking overlap verification as an example, the judgment logic is as follows: For any two different goods in the post-processing result table, if their projection intervals in the x-axis direction do not overlap (i.e., the right boundary of goods A ≤ the left boundary of goods B, or the right boundary of goods B ≤ the left boundary of goods A), or their projection intervals in the y-axis direction do not overlap, or their projection intervals in the z-axis direction do not overlap, then the two goods are determined not to overlap; otherwise, if the projection intervals in all three directions overlap, then the two goods are determined to have volume overlap, and the overlap verification fails.

[0168] Changes in key performance indicators (KPIs) can serve as supplementary indicators of result consistency and solution effectiveness. If a threshold is configured in the business (e.g., a failure is determined when volume utilization decreases by more than 10%), the threshold will be used for judgment; if no threshold is configured, changes in KPIs are only used for display and comparison, and will not be used as the basis for pass / fail.

[0169] In this way, the three-level validation filters the code layer by layer from the syntax, execution, and business perspectives, ensuring that the post-processing result is not only executable but also meets the physical and logical constraints of the algorithm itself, thus avoiding the risk of generating code that would compromise the usability of the result.

[0170] V. Version Management and Rollback Mechanism;

[0171] The system uses the same algorithm task as the version management unit. A successful execution of the original algorithm results in an ALGO version, while successful post-processing results in a POST_PROCESS version. A version object must include at least the following fields:

[0172] requestId: A unique identifier for the request;

[0173] versionName: Version name (can be automatically generated by the system or specified by the user);

[0174] requestType: Request type, which can be either ALGO or POST_PROCESS;

[0175] parentRequestId: Parent request identifier (the parent request for the post-processed version is the original algorithm request);

[0176] status: Status (e.g., SUCCESS, FAILED);

[0177] createTime: Creation time;

[0178] Multiple versions are attached to the same taskInfo.id and taskInfo.taskId through taskInfo.versions.

[0179] Result storage:

[0180] The original algorithm results are stored in the original output table, such as udt_loading_result and udt_loading_kpi.

[0181] Post-processing results are stored in post-processing output tables or result copies, such as udt_loading_result_post_process and udt_loading_kpi_post_process.

[0182] Each row of results can be associated with a specific requestId through the request_id, record_version, or equivalent version fields.

[0183] When a user selects the original ALGO version, the system queries the original results table; when a user selects the POST_PROCESS version, it queries the post-processing results table. When comparing results, the initial ALGO version is used as the baseline, and the current POST_PROCESS version is used as the adjustment result; these results are queried separately and displayed side-by-side.

[0184] The rollback operation does not rely on overwritten data, but on version selection: users can return to the original algorithm result by selecting the original ALGO version, or return to the corresponding post-processing result by selecting any historical POST_PROCESS version. If the business system needs to persist the "currently effective version", activeRequestId and activeRequestType can be added as version pointers; during rollback, only the pointers are switched, without modifying the historical result data, thus ensuring that the original result and historical post-processing results are completely traceable.

[0185] In this way, by differentiating versions and storing them in separate tables, the original results and post-processed results are isolated and managed. Users can compare and roll back at any time, and all operations have complete audit logs.

[0186] VI. Other alternative implementation methods;

[0187] Those skilled in the art should understand that the above embodiments are merely illustrative examples and the present invention is not limited thereto.

[0188] Alternative scripting languages: The scripting language can be replaced by a restricted DSL, SQL script, WASM sandbox program, or rule configuration file, as long as it can be executed and the algorithm results modified in a controlled environment.

[0189] Alternative communication methods: Streaming output can be replaced by WebSocket, long polling, or message queue subscription to achieve asynchronous interaction between the front-end and back-end.

[0190] Alternative solutions for business constraint validation: Business constraint validation can be performed by SQL scripts, rule engines, algorithm service interfaces, or dedicated simulators, and is not limited to the SQL method in this embodiment.

[0191] Alternative solutions for application scenarios: This invention is not only applicable to packing / loading algorithms, but can also be extended to algorithmic tasks such as path planning (e.g., users request to "avoid a certain road segment"), production scheduling (e.g., users request to "advance a certain order"), and inventory allocation (e.g., users request to "increase the inventory ratio of a certain warehouse"). Its core inventive concept—binding natural language requests to task context, generating scripts by round, three-level verification, and versioned access—is universally applicable.

[0192] The above description is merely a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. An algorithmic result natural language post-processing and versioning verification method, characterized in that, include: Receive requests for local adjustments to natural language for completed algorithmic tasks; Read the task context of the algorithm task, which includes at least an input table, an output table, a parameter table, a task identifier, a version list, and constraint verification items; The natural language requests are summarized into an adjustment request summary, and an adjustment strategy is generated based on the task context; Generate script code to modify the algorithm results for each round, and record the round number, strategy text and code text for each round; Perform compilation verification on the generated script code and record the compilation verification results; If the compilation verification passes, the script code is executed to generate the post-processing result, and an execution verification is performed after execution is completed, while the execution verification result is recorded. If the verification passes, then perform business constraint verification on the generated post-processing result and record the business constraint verification result; If the business constraint verification passes, the post-processing result is written into the version list of the same algorithm task, and the request type of the post-processing result is marked as the post-processing type. At the same time, the original algorithm result is retained and marked as the algorithm type. If any of the compilation verification, execution verification, or business constraint verification fails, the failure information is recorded, and the process proceeds to the next round or terminates the current processing.

2. The method of claim 1, wherein the method further comprises: Entering the next round includes: using the verification results of the current round as supplementary context, regenerating the adjustment strategy and script code, and recording it as a new round.

3. The method of claim 1, wherein the method further comprises: The compilation verification criteria include: correct script syntax, existence of entry function, availability of dependent libraries, referenced table and field names belonging to the current task context, and no prohibited items such as overwriting the original version or unauthorized access being hit. The pass criteria for the execution verification include: the script terminates normally in the restricted workspace, does not time out, and generates a post-processing result table; The passing criteria for the business constraint verification include: all preset strong constraint verification items for the algorithm results are without anomalies.

4. The method of claim 1, wherein the method further comprises: Each version object in the version list includes at least a request identifier, version name, request type, parent request identifier, and creation time; wherein, the request type includes an algorithm type for identifying the original algorithm result and a post-processing type for identifying the post-processing result.

5. The method of claim 1, wherein the method further comprises: The summary of natural language requests includes: determining the set of read tables and the set of write tables required for this post-processing based on the task context.

6. A system for natural language post-processing and version verification of algorithm results for implementing the algorithm result natural language post-processing and version verification method according to any one of claims 1-5, characterized in that, include: The request receiving module is used to receive requests for local adjustments to the natural language for completed algorithm tasks; The context reading module is used to read the task context of the algorithm task. The task context includes at least an input table, an output table, a parameter table, a task identifier, a version list, and constraint verification items. The target summarization module is used to summarize the natural language requests into an adjustment request summary and generate adjustment strategies; The code generation and round management module is used to generate script code for modifying algorithm results by round, and to record the round number, strategy text and code text for each round; The compilation verification module is used to perform compilation verification on the generated script code and record the compilation verification results; The execution verification module is used to execute the script code to generate post-processing results after the compilation verification is passed, and to perform execution verification after execution is completed, while recording the execution verification results. The business constraint verification module is used to perform business constraint verification on the generated post-processing result after the verification is passed, and to record the business constraint verification result. The version management module is used to write the post-processing result as the post-processing type version into the version list when the business constraint verification passes, and to retain the original algorithm type version.

7. The algorithm result natural language post-processing and version verification system according to claim 6, characterized in that, The code generation and round management module is further configured to receive failure information and trigger a new round of strategy and code generation when any of the compilation verification, execution verification or business constraint verification fails.

8. The algorithmic result natural language post-processing and versioning verification system of claim 6, wherein, The version management module is specifically used to: save the original algorithm results in the original output table, save the post-processing results in the post-processing output table, and associate the post-processing results with the post-processing type version under the same algorithm task through the version field.

9. The algorithmic result natural language post-processing and versioning verification system of claim 6, wherein, The business constraint verification includes at least one of the following strong constraints: support anomaly, boundary anomaly, overlap anomaly, heavy weight not pressing on light weight, overweight anomaly, partition anomaly, number of layers anomaly, height anomaly, direction anomaly, and cabinet tail anomaly.

Images