Order intelligent agent routing and dynamic order distribution method based on large language model

Abstract

This invention relates to the field of e-commerce logistics order fulfillment and intelligent order allocation technology, and particularly to an intelligent proxy routing and dynamic order allocation method based on a large language model. The method includes: receiving structured fields, unstructured remarks text, and historical order behavior summaries of orders to be allocated, generating semantic input data for the orders; calling a large language model to perform fulfillment semantic parsing, generating and validating a structured tag set containing fulfillment constraint tags and tag confidence levels, forming reliable fulfillment constraint tags; combining warehouse inventory snapshots, delivery personnel real-time status snapshots, and business target configuration files, performing hard constraint filtering, soft penalty or weight item mapping, and warehouse-delivery personnel combination scoring, generating a set of candidate allocation schemes; performing feasibility backtracking verification on the candidate allocation schemes, and outputting order allocation decision data. This invention effectively improves the consistency between order semantic constraints and warehouse-distribution order allocation processing.

Description

Technical Field

[0001] This invention relates to the field of e-commerce logistics order fulfillment and intelligent order allocation technology, and in particular to an intelligent proxy routing and dynamic order allocation method based on a large language model. Background Technology

[0002] In the field of e-commerce logistics order fulfillment and intelligent order allocation technology, existing solutions for order allocation typically process orders based on structured order fields, warehouse inventory information, delivery range, promised delivery time, and delivery personnel status. While these solutions can handle basic processing such as warehouse selection, delivery personnel assignment, order splitting, or order merging in typical scenarios, they are prone to limitations when orders simultaneously contain unstructured notes, historical order behavior summaries, multiple warehouse inventory statuses, and real-time delivery personnel status. These limitations include a disconnect between semantic input data and allocation rules, inconsistencies in matching criteria between candidate warehouses and candidate delivery personnel, and a lack of synchronization between allocation decision data and inventory feasibility status.

[0003] Existing solutions often rely on structured fields, fixed rules, keyword recognition, manually set order splitting rules, or fixed-weight scoring functions for processing. When buyer remarks, buyer comments, historical delivery time preferences, historical damage complaint records, or historical designated delivery preferences change, there is a lack of stable connection between unstructured remarks text and subsequent candidate filtering, scoring and sorting, order splitting, or merging processes. This can easily cause fulfillment constraints to fail to enter the processing chain of warehouse and delivery personnel candidates, and can also easily cause data breakpoints between the scoring and sorting results and subsequent inventory verification, delivery personnel capacity verification, and service time window verification.

[0004] Existing technologies for the joint processing of order semantic input data, inventory snapshots, delivery personnel real-time status snapshots, and order allocation decision data still suffer from common shortcomings, including discontinuous connections between label confidence, hard constraint filtering, soft penalty term mapping, candidate allocation scheme sets, and inventory feasibility verification results. Therefore, it is necessary to address the issue of generating order allocation decision data based on order semantic input data, inventory snapshots, and delivery personnel real-time status snapshots, specifically for order fulfillment and order allocation scenarios. Summary of the Invention

[0005] To address the aforementioned technical problems, this invention provides a method for intelligent order proxy routing and dynamic order allocation based on a large language model, comprising:

[0006] S100: Receive the structured fields, unstructured remarks text, and historical order behavior summary of the orders to be split; bind the order identifier and encapsulate the semantic input of the structured fields, unstructured remarks text, and historical order behavior summary to generate order semantic input data;

[0007] S200. Based on the order semantic input data, call the large language model to perform performance semantic parsing, generate a structured tag set containing performance constraint tags and tag confidence, and perform format verification, tag enumeration verification and confidence filtering on the structured tag set to generate reliable performance constraint tags and tag records to be sampled.

[0008] S300: Obtain inventory snapshots of multiple warehouses and real-time status snapshots of multiple delivery personnel; perform hard constraint filtering on warehouse candidate objects and delivery personnel candidate objects based on the trusted fulfillment constraint tags to generate a feasible candidate set.

[0009] S400. Based on the feasible candidate set and business objective configuration file, the reliable performance constraint label is mapped to a soft penalty term or weight term in the multi-objective scoring function, and the warehouse-deliveryman combination is scored and sorted to generate a candidate allocation scheme set.

[0010] S500. Based on the set of candidate allocation schemes, perform a feasibility backtracking verification of product SKU inventory, delivery personnel capacity, and service time window, generate inventory feasibility verification results, and output order splitting decision data based on the inventory feasibility verification results. The order splitting decision data includes target warehouse number, target delivery personnel number, order splitting / merging instructions, and expected fulfillment time window.

[0011] Furthermore, the structured fields of the order include order number, product SKU list, delivery address, promised delivery time, product volume, and product weight; the unstructured remarks text includes buyer remarks, buyer comments, and special instructions; the historical order behavior summary includes historical delivery time preferences, historical damage complaint records, and historical designated delivery preferences; the order identifier binding includes writing the order number into the product SKU list, the delivery address, the promised delivery time, the unstructured remarks text, and the historical order behavior summary, respectively.

[0012] Furthermore, the structured tag set includes tag type, tag confidence level, tag source field, constraint attributes, and tag status; the tag type belongs to a tag dictionary composed of expedited, fragile, secondary packaging, delivery time restriction, and specified delivery preference; the constraint attributes include hard constraint attributes and soft constraint attributes; the tag status includes trusted status, pending inspection status, and conflict status.

[0013] Furthermore, the structured tag set is subjected to format validation, tag enumeration validation, and confidence filtering, including: performing field integrity validation on the structured tag set to generate a format validation result; matching the performance constraint tags with a preset tag dictionary to generate a tag enumeration validation result; comparing the tag confidence with a confidence threshold to generate a confidence filtering result; and generating the trusted performance constraint tags and the tag records to be sampled based on the format validation result, the tag enumeration validation result, and the confidence filtering result.

[0014] Furthermore, the warehouse inventory snapshot includes warehouse number, available inventory of product SKUs, warehouse service area, warehouse packaging capacity, and inventory snapshot timestamp; the delivery person's real-time status snapshot includes delivery person number, current location, service area, number of orders in transit, allocated volumetric load, historical damage rate, and status timestamp; the hard constraint filtering includes removing candidate objects from the candidate objects based on the trusted fulfillment constraint label, where the warehouse service area does not match, the warehouse packaging capacity does not match, the delivery person's service area does not match, or the delivery person's service time window does not match.

[0015] Furthermore, the multi-objective scoring function includes a freight cost item, a delivery distance cost item, a delivery personnel load balancing item, a timeliness urgency weight item, a fragile item damage risk penalty item, and an additional freight cost increment item for split orders; mapping the reliable fulfillment constraint label to soft penalty items or weight items in the multi-objective scoring function includes: mapping the expedited label to a timeliness urgency weight item, mapping the fragile label to a fragile item damage risk penalty item, and mapping the secondary packaging label to a warehouse processing capacity penalty item.

[0016] Furthermore, the business objective configuration file includes freight weight, timeliness weight, load balancing weight, damage risk weight, order splitting freight increment threshold, and configuration version number; S400 includes: reading the currently effective business objective configuration file, generating weight parameters for the multi-objective scoring function based on the freight weight, the timeliness weight, the load balancing weight, and the damage risk weight; and writing the configuration version number into the order splitting audit record.

[0017] Furthermore, the feasibility backtracking verification includes single-warehouse inventory verification and cross-warehouse inventory verification; the single-warehouse inventory verification includes: based on the target warehouse number in the candidate allocation scheme, verifying whether the same warehouse has available inventory of all product SKUs in the order to be split, and generating a single-warehouse shipment splitting result when the same warehouse has available inventory of all product SKUs; the cross-warehouse inventory verification includes: when the same warehouse does not have available inventory of all product SKUs, traversing the product SKU inventory combinations of multiple warehouses to generate cross-warehouse splitting candidate results.

[0018] Furthermore, after generating cross-warehouse order splitting candidate results, the process also includes: verifying the available inventory of the product SKUs in the warehouse corresponding to each sub-waybill, and calculating the order splitting freight increment corresponding to the cross-warehouse order splitting candidate results; when the available inventory of the product SKUs in the warehouse corresponding to each sub-waybill meets the quantity of the product SKUs in the corresponding sub-waybill, and the order splitting freight increment does not exceed the order splitting freight increment threshold, generating a cross-warehouse order splitting instruction and a sub-waybill list; and writing the cross-warehouse order splitting instruction and the sub-waybill list into the order splitting decision data.

[0019] Furthermore, the feasibility backtracking verification also includes a merged delivery verification; the merged delivery verification includes: when there are adjacent pending orders with the same delivery address or the same recipient, verifying whether the adjacent pending orders correspond to the same delivery person, whether they are in the same service time window, whether the total volume and total weight do not exceed the delivery person's carrying capacity limit, and whether there are no merge mutual exclusion tags between the adjacent pending orders; when the adjacent pending orders correspond to the same delivery person, are in the same service time window, the total volume and total weight do not exceed the delivery person's carrying capacity limit, and there are no merge mutual exclusion tags, generating a merge instruction and a merged waybill association; and writing the merge instruction and the merged waybill association into the order splitting decision data.

[0020] The key innovations of this invention include:

[0021] (1) Bind the structured fields, unstructured notes and historical order behavior summaries of the orders to be sorted into order identifiers and encapsulate semantic input. Based on the semantic input data of the orders, call the big language model to generate a set of structured tags containing performance constraint tags and tag confidence. Generate credible performance constraint tags and tag records to be sampled through format validation, tag enumeration validation and confidence filtering.

[0022] (2) Introduce the trustworthy performance constraint label into the candidate filtering and scoring ranking links respectively. Based on the trustworthy performance constraint label, perform hard constraint filtering on warehouse candidate objects and delivery personnel candidate objects to generate feasible candidate sets. Map the trustworthy performance constraint label to soft penalty terms or weight terms in the multi-objective scoring function to generate a set of candidate allocation schemes.

[0023] (3) Perform feasibility backtracking verification on the candidate allocation scheme set with the product SKU inventory, delivery personnel capacity and service time window, generate inventory feasibility verification results, and output order splitting decision data including target warehouse number, target delivery personnel number, order splitting / merging instructions and expected fulfillment time window based on the inventory feasibility verification results.

[0024] The following are its main beneficial effects:

[0025] (1) To address the disconnect between unstructured notes, historical order behavior summaries and order splitting rules, the textual performance constraints in the order are encapsulated through order semantic input, parsing of performance semantics using a large language model, and label verification and filtering. This enables the textual performance constraints in the order to form recordable and verifiable trustworthy performance constraint labels. Labels with low confidence or verification anomalies are entered into the label record to be sampled, thus preventing unverified labels from directly entering the subsequent order splitting process.

[0026] (2) To address the issues of inconsistent matching criteria between candidate warehouses and candidate delivery personnel and the difficulty of fixed-weight scoring in bearing semantic constraints, the same performance constraint label is used to simultaneously participate in the generation of feasible candidate sets and the ranking of warehouse-delivery personnel combination scores, thus forming a continuous data link from semantic constraints to the set of candidate allocation schemes.

[0027] (3) To address the issue of data breakpoints between the scoring and ranking results and inventory verification, delivery personnel capacity verification, and service time window verification, the feasibility backtracking verification of the product SKU inventory, delivery personnel capacity, and service time window is performed on the candidate allocation scheme set. This allows the order splitting decision data to be associated with the inventory feasibility verification results before output, and the order splitting / merging instructions, target warehouse number, target delivery personnel number, and expected fulfillment time window are written into the same order splitting processing result. Attached Figure Description

[0028] Figure 1 A flowchart illustrating an intelligent order proxy routing and dynamic order allocation method based on a large language model, provided for an embodiment of this application;

[0029] Figure 2 This is a structural block diagram of an intelligent order proxy routing and dynamic order allocation method based on a large language model, provided in an embodiment of this application. Detailed Implementation

[0030] Example 1: Refer to Figure 1 This is a flowchart illustrating an intelligent order proxy routing and dynamic order allocation method based on a large language model provided in an embodiment of the present invention. The process may include at least steps S100-S500:

[0031] S100: Receive the structured fields, unstructured remarks text, and historical order behavior summary of the orders to be split; bind the order identifier and encapsulate the semantic input of the structured fields, unstructured remarks text, and historical order behavior summary to generate order semantic input data;

[0032] S200. Based on the order semantic input data, call the large language model to perform performance semantic parsing, generate a structured tag set containing performance constraint tags and tag confidence, and perform format verification, tag enumeration verification and confidence filtering on the structured tag set to generate reliable performance constraint tags and tag records to be sampled.

[0033] S300: Obtain inventory snapshots of multiple warehouses and real-time status snapshots of multiple delivery personnel; perform hard constraint filtering on warehouse candidate objects and delivery personnel candidate objects based on the trusted fulfillment constraint tags to generate a feasible candidate set.

[0034] S400. Based on the feasible candidate set and business objective configuration file, the reliable performance constraint label is mapped to a soft penalty term or weight term in the multi-objective scoring function, and the warehouse-deliveryman combination is scored and sorted to generate a candidate allocation scheme set.

[0035] S500. Based on the set of candidate allocation schemes, perform a feasibility backtracking verification of product SKU inventory, delivery personnel capacity, and service time window, generate inventory feasibility verification results, and output order splitting decision data based on the inventory feasibility verification results. The order splitting decision data includes target warehouse number, target delivery personnel number, order splitting / merging instructions, and expected fulfillment time window.

[0036] S100: Receive the structured fields, unstructured remarks text, and historical order behavior summary of the orders to be split; bind order identifiers and encapsulate semantic input on the structured fields, unstructured remarks text, and historical order behavior summary to generate order semantic input data.

[0037] This step is executed by the order receiving module in the order fulfillment platform. This module is connected to the order management system, the user order submission terminal, the customer's historical order database, and the order allocation task queue. When an order to be allocated enters the order allocation task queue, the order receiving module reads the corresponding structured fields, unstructured remarks text, and historical order behavior summary. Using the order number as the primary index, it writes data from multiple sources into the same order processing record. The structured fields are data already stored in the order management system according to field rules, specifically including the order number, product SKU list, shipping address, promised delivery time, product volume, and product weight. SKU stands for Stock Keeping Unit, used in this embodiment to identify the inventory of each product in the order to be allocated. The unstructured remarks text consists of text content from buyer notes, buyer comments, and special instructions; this text content is not pre-defined as fixed keywords. The historical order behavior summary is data formed by summarizing the customer's historical fulfillment records, specifically including historical delivery time preferences, historical damage complaint records, and historical designated delivery preferences.

[0038] Upon receiving an order to be split, the order receiving module first checks the existence of the structured fields. If the order number, product SKU list, shipping address, or promised delivery time is missing, the order receiving module writes the corresponding order to the abnormal order splitting record and retains the original fields already received. For missing product volume and weight, the order receiving module can retrieve them from the product master data table according to the product SKU. If the corresponding field still does not exist in the product master data table, the order receiving module writes the product SKU to the field to be supplemented record and retains the missing status field in the order semantic input data. For empty unstructured remarks text, the order receiving module writes an empty text identifier to the remarks text field; for cases where the historical order behavior summary does not exist, the order receiving module writes a no-historical-summary identifier. These abnormal identifiers, along with the order number, are written to the order processing record without changing the subsequent processing order of the order.

[0039] During the order identification binding process, the order receiving module writes the order number into the product SKU list, shipping address, promised delivery time, unstructured remarks text, and historical order behavior summary, and writes a field source identifier for each field. The field source identifier is used to distinguish between the order management system, the user order submission end, and the customer's historical order database. The order receiving module also writes a field receiving timestamp, enabling subsequent steps to distinguish field versions of the same order at different points in time when calling order semantic input data. In one implementation, if the buyer modifies the shipping address or remarks text after the order enters the order allocation task queue, the order receiving module generates a new field version number and stores the modified field along with the original field; if the order allocation task has not yet entered S200, the system calls the latest field version to generate order semantic input data; if the order allocation task has entered S200, the order receiving module generates a re-allocation marker and writes the re-allocation marker into the order allocation task queue.

[0040] Semantic input encapsulation refers to the order receiving module organizing the structured fields, unstructured notes, and historical order behavior summaries of the order into a data package that can be used by the subsequent large language model, according to a preset field order. This data package does not change the meaning of the original order fields; it only organizes the fields sequentially, marks their source, and encapsulates their versions. Specifically, the order receiving module first reads the order number, product SKU list, shipping address, and promised delivery time from the structured fields; then it reads the buyer's notes, buyer's comments, and special instructions from the unstructured notes; next, it reads the historical delivery time preference, historical damage complaint records, and historical designated delivery preference from the historical order behavior summary; finally, it merges the above fields according to the order number and generates the order semantic input data. The order semantic input data includes the order number, field version number, structured field area, unstructured text area, historical summary area, field source identifier, and abnormal status field.

[0041] In one implementation, the order fulfillment platform is deployed on the e-commerce platform's order distribution server. A buyer submits an order containing three product SKUs, with the note "Delivery after 6 PM, please handle the glass with care," and the historical order behavior summary records that the buyer previously selected evening delivery. The order receiving module reads the order's product SKU list, shipping address, promised delivery time, product volume, and product weight, and binds the note text and historical order behavior summary according to the order number to generate order semantic input data with a version number field. The unstructured text area of ​​this order semantic input data retains the original note text, the historical summary area retains the evening delivery preference field, and the structured field area retains the product SKU, address, and promised delivery time fields.

[0042] In another implementation, the orders to be processed originate from a third-party e-commerce system. The order receiving module receives structured fields through the order interface and maps the "delivery instructions" field from the third-party e-commerce system to unstructured remarks text using text field mapping rules. If the third-party e-commerce system does not provide a historical order behavior summary, the order receiving module retrieves the corresponding customer's historical fulfillment records from the local customer historical order database using the customer identifier and generates a historical order behavior summary; if the search result is empty, a "no historical summary" flag is written. After this processing is completed, the order receiving module writes the order semantic input data into the semantic parsing task table.

[0043] The order semantic input data generated in this step serves as the input object for S200. The semantic parsing proxy module in S200 reads the unstructured text area and historical summary area from the order semantic input data, and performs fulfillment semantic parsing by combining the product SKU list, shipping address, and promised delivery time from the structured field area. The version number, source identifier, and exception status field from the order semantic input data are simultaneously entered into the parsing record of S200, so that source and version information can be retained when generating the structured tag set later.

[0044] S200. Based on the order semantic input data, a large language model is invoked to perform performance semantic parsing, generating a structured tag set containing performance constraint tags and tag confidence scores. The structured tag set is then subjected to format validation, tag enumeration validation, and confidence score filtering to generate reliable performance constraint tags and tag records to be sampled.

[0045] This step is executed collaboratively by the semantic parsing proxy module and the label verification module. The semantic parsing proxy module receives the order semantic input data generated by S100 and reads the unstructured text area, historical summary area, and structured field area; the label verification module reads the label dictionary, field integrity rules, and confidence threshold configuration. The semantic parsing proxy module calls the large language model to perform performance semantic parsing. The input of the large language model is the encapsulated order semantic input data, and the output is a set of structured labels containing performance constraint labels and label confidence levels.

[0046] The performance constraint tags are structured tags parsed from the semantic input data of the order by the large language model, used to represent the performance requirements of the order. The set of structured tags includes tag type, tag confidence level, tag source field, constraint attributes, and tag status. The tag type belongs to a tag dictionary consisting of expedited, fragile, secondary packaging, delivery time restrictions, and specified delivery preferences; the tag confidence level is the numerical value indicating the credibility of the corresponding tag; the tag source field identifies whether the tag comes from unstructured notes, historical order behavior summaries, or structured fields of the order; constraint attributes include hard constraint attributes and soft constraint attributes; the tag status includes credible status, pending inspection status, and conflict status. All of the above fields are organized by the semantic parsing proxy module according to the structured output template and subsequently verified by the tag verification module.

[0047] In one implementation, the structured output template uses JSON (JavaScript Object Notation) format. The semantic parsing proxy module embeds the unstructured notes and historical order behavior summaries from the order semantic input data into the prompt template, and simultaneously writes the order number, product SKU list, delivery address, and promised delivery time. In the structured tag set returned by the large language model, each tag record contains tag type, tag confidence, tag source field, constraint attribute, and tag status field. If the notes are "Delivered after 6 PM, please handle the glass with care," the large language model can generate a delivery time restriction tag and a fragile tag; the tag source field of the delivery time restriction tag points to the buyer's notes, and the tag source field of the fragile tag points to both the buyer's notes and the product SKU list.

[0048] After the semantic parsing proxy module completes the large language model call, it sends the structured tag set to the tag validation module. The tag validation module first performs field integrity checks, which means verifying whether each tag record contains the tag type, tag confidence score, tag source field, constraint attribute, and tag status field, and generates a format validation result. If a tag record lacks the tag confidence score or tag source field, the tag validation module writes that tag record to the tag record to be sampled, and writes the missing field name to the reason for sampling field. If the overall format of the structured tag set cannot be parsed, the tag validation module writes the entire order to the tag record to be sampled, and retains the original output text of the large language model.

[0049] After the field integrity verification is completed, the label verification module performs label enumeration verification. Label enumeration verification refers to matching the label type of each performance constraint label with a preset label dictionary to generate a label enumeration verification result. If the label type belongs to the label dictionary consisting of expedited, fragile, secondary packaging, delivery time restriction, and specified delivery preference, the label enumeration verification result is recorded as a match; if the label type does not belong to the label dictionary, the label verification module writes the label record to the label record to be inspected and writes the label status to the pending inspection status. In another implementation, the label dictionary can be updated synchronously according to the version of the business target configuration file. The label verification module reads the currently effective label dictionary version and writes the label dictionary version number into the verification record of the structured label set.

[0050] After tag enumeration and validation are completed, the tag validation module performs confidence filtering. Confidence filtering compares the tag confidence level with a confidence threshold to generate a confidence filtering result. For tag records whose confidence level reaches the confidence threshold, pass format validation, and pass tag enumeration validation, the tag validation module writes them into the trusted fulfillment constraint tag and sets the tag status to trusted. For tag records whose confidence level does not reach the confidence threshold, the tag validation module writes them into the tag record to be sampled, retaining the tag type, tag confidence level, tag source field, and the original output fragment of the large language model. For mutually exclusive or conflicting tags appearing simultaneously in the same order, such as the remarks text containing both "deliver as soon as possible" and "delivery only in the evening," the tag validation module sets the corresponding tag status to conflict and generates a conflict identifier.

[0051] In one implementation, the tag records to be sampled are written to a manual sampling pool. The manual sampling pool stores the order number, field version number, tag type, tag confidence level, tag source field, reason for sampling, and the original output fragment of the large language model. The manual sampling pool does not directly participate in the hard constraint filtering of S300, but its sampling results can be written back to the tag dictionary, confidence threshold configuration, or prompt template version in subsequent rounds. If the order corresponding to the tag record to be sampled still needs to enter the automatic order allocation process, the system only sends the reliable performance constraint tag to S300; the tag record to be sampled is retained in the order allocation audit record.

[0052] During project implementation, after receiving the order semantic input data generated by S100, the semantic parsing proxy module detects that the field version number is V1, the remarks text contains "Please handle the glass with care," and the historical order behavior summary contains "Historical damage complaint records." The large language model returns fragile labels and secondary packaging labels, along with their corresponding label confidence levels. The label verification module performs field integrity verification on the returned results, confirming that the label type, label confidence level, label source field, constraint attribute, and label status fields all exist. Then, it matches the fragile labels and secondary packaging labels with the label dictionary. Finally, it compares the label confidence level with a confidence threshold. Fragile labels with a confidence level reaching the threshold are written into the trusted fulfillment constraint label, while secondary packaging labels with a confidence level below the threshold are written into the pending inspection label record.

[0053] The trusted fulfillment constraint tags generated in this step serve as input for S300's hard constraint filtering and also as input for S400's mapping of soft penalty or weight items. The tag records to be sampled are not used as candidate filtering criteria by S300; they are stored in association with the order number and field version number. S300 reads the tag type, constraint attribute, tag source field, and tag status from the trusted fulfillment constraint tags and filters warehouse and delivery person candidate objects based on these fields.

[0054] S300: Obtain inventory snapshots from multiple warehouses and real-time status snapshots from multiple delivery personnel; perform hard constraint filtering on warehouse candidate objects and delivery personnel candidate objects based on the trusted fulfillment constraint tags to generate a feasible candidate set.

[0055] This step is performed by the status snapshot acquisition module and the candidate filtering module. The status snapshot acquisition module receives the trusted fulfillment constraint tags generated by S200 and reads inventory snapshots from multiple warehouses from the warehouse management system and real-time status snapshots from multiple delivery personnel from the delivery management system. The candidate filtering module reads the tag type, constraint attributes, and tag status from the trusted fulfillment constraint tags and writes the inventory snapshots, real-time status snapshots, and trusted fulfillment constraint tags into the same candidate filtering task, indexed by the order number.

[0056] The warehouse inventory snapshot includes warehouse number, available inventory for each product SKU, warehouse service area, warehouse packaging capacity, and inventory snapshot timestamp. Available inventory for a product SKU is the quantity of inventory available for order splitting at the time corresponding to the snapshot timestamp. The warehouse service area is the delivery address area covered by the warehouse. Warehouse packaging capacity indicates whether the warehouse has the packaging processing capacity corresponding to the secondary packaging labels. The delivery person's real-time status snapshot includes delivery person number, current location, service area, number of orders in transit, allocated volumetric load, historical breakage rate, and status timestamp. The current location can be represented by latitude and longitude or delivery grid number; allocated volumetric load is used for subsequent delivery person capacity verification; historical breakage rate is used for candidate filtering and subsequent scoring of fragile labels.

[0057] When reading inventory snapshots and real-time status snapshots, the status snapshot acquisition module verifies the validity of the snapshot timestamp and status timestamp. If the inventory snapshot timestamp exceeds the valid duration of the inventory snapshot, the status snapshot acquisition module sends a re-read request to the warehouse management system. If the re-read still does not return a response, the status snapshot acquisition module writes the corresponding warehouse into a snapshot exception record and temporarily does not add the warehouse to the warehouse candidate object. If the status timestamp of the delivery person's real-time status snapshot exceeds the valid duration, the status snapshot acquisition module sends a re-read request to the delivery management system. If the delivery person is offline or the status timestamp still does not meet the validity rules, the status snapshot acquisition module temporarily does not add the delivery person to the delivery person candidate object.

[0058] The candidate filtering module first generates initial warehouse candidate objects and initial delivery person candidate objects based on the delivery address and product SKU list in the order's structured fields. For warehouse candidate objects, the module matches the delivery address with the warehouse's service area and performs a preliminary match between the product SKU list and the available inventory of each product SKU. For delivery person candidate objects, the module matches the delivery address with the delivery person's service area and reads the delivery person's current location, the number of orders in transit, and the allocated volume and weight. These preliminary matches form candidate object records, which include the warehouse number, delivery person number, field source, snapshot timestamp, and matching status.

[0059] During the hard constraint filtering process, the candidate filtering module reads the trusted fulfillment constraint label generated by S200. If the trusted fulfillment constraint label contains a delivery time restriction label, the candidate filtering module matches the delivery time restriction label with the delivery person's service time window and deletes delivery person candidates whose service time windows do not match from the candidate list. If the trusted fulfillment constraint label contains a specified delivery preference label, the candidate filtering module matches the specified delivery preference label with the delivery person's service area or delivery resource type and deletes delivery person candidates whose matching fails. If the trusted fulfillment constraint label contains a secondary packaging label, the candidate filtering module matches this label with the warehouse's packaging capacity and deletes warehouse candidate candidates whose packaging capacity does not match. If the trusted fulfillment constraint label contains a fragile label, the candidate filtering module reads the delivery person's historical damage rate and deletes delivery person candidate candidates whose historical damage rate does not match according to the preset damage risk rules.

[0060] In one implementation, hard constraint filtering also includes joint filtering based on inventory and service range. When screening warehouse candidates, the candidate filtering module first checks whether the warehouse's service range covers the delivery address, and then checks whether the warehouse has available inventory of the corresponding product SKU in the pending order. For warehouse candidates with mismatched service ranges, the information is directly written into the filtering record. For warehouse candidates with matched service ranges but insufficient inventory of some product SKUs, they are retained as candidate warehouses for subsequent cross-warehouse inventory verification, and a partial inventory status is written into the candidate record. This partial inventory status does not directly form the order splitting decision, but serves as input for S500 during cross-warehouse inventory verification.

[0061] During project implementation, the S200 outputs reliable fulfillment constraint tags, including delivery time restriction tags, fragile tags, and secondary packaging tags. The status snapshot acquisition module reads inventory snapshots from three warehouses and real-time status snapshots from six delivery personnel. The candidate filtering module first filters out two warehouses whose service area covers the delivery address based on the receiving address, then removes one warehouse lacking packaging capabilities based on the secondary packaging tag. Simultaneously, the candidate filtering module removes two delivery personnel whose service time windows do not match based on the delivery time restriction tag, and reads the historical breakage rate of the remaining delivery personnel based on the fragile tag, removing delivery personnel with mismatched breakage rates. After filtering, the candidate filtering module combines the remaining warehouse and delivery personnel candidates to generate a feasible candidate set.

[0062] The feasible candidate set includes multiple warehouse-deliveryman combinations. Each combination includes a warehouse number, deliveryman number, product SKU inventory status, warehouse packaging capacity matching status, deliveryman service time window matching status, deliveryman capacity status, trusted fulfillment constraint tag reference identifier, inventory snapshot timestamp, and status timestamp. The feasible candidate set serves as the input object for S400. S400 reads the warehouse-deliveryman combinations in the feasible candidate set and performs multi-objective scoring based on the business objective configuration file and trusted fulfillment constraint tags.

[0063] S400. Based on the feasible candidate set and business objective configuration file, the reliable performance constraint label is mapped to a soft penalty term or weight term in a multi-objective scoring function, and the warehouse-deliveryman combination is scored and ranked to generate a candidate allocation scheme set.

[0064] This step is executed by the multi-objective scoring module. The multi-objective scoring module receives the feasible candidate set generated by S300, and simultaneously reads the trusted fulfillment constraint label generated by S200 and the currently effective business objective configuration file in the configuration center. The business objective configuration file includes freight weight, timeliness weight, load balancing weight, damage risk weight, order splitting freight increment threshold, and configuration version number. The multi-objective scoring module associates the configuration version number, the trusted fulfillment constraint label reference identifier, and the warehouse-delivery person combination in the feasible candidate set to form a scoring task record.

[0065] The multi-objective scoring function includes a freight cost item, a delivery distance cost item, a delivery driver load balancing item, a timeliness urgency weight item, a fragile goods damage risk penalty item, and an additional freight cost increment item for split orders. The freight cost item can be calculated based on the basic delivery cost from the warehouse to the delivery address and potential cross-warehouse costs; the delivery distance cost item can be calculated based on the distance between the warehouse location, the delivery driver's current location, and the delivery address; the delivery driver load balancing item can be calculated based on the number of orders in transit for each delivery driver and the allocated volumetric weight; the timeliness urgency weight item is associated with expedited labels and promised delivery times; the fragile goods damage risk penalty item is associated with fragile labels and the delivery driver's historical damage rate; and the additional freight cost increment item for split orders is associated with the increased freight cost when shipping from multiple warehouses. The weights of the above scoring items are provided by the business objective configuration file.

[0066] When the multi-objective scoring module reads the business objective configuration file, it first verifies whether the configuration version number is the currently effective version. If the configuration version number is inconsistent with the currently effective version recorded in the configuration center, the multi-objective scoring module rereads the business objective configuration file; if the reread fails, the multi-objective scoring module retains the previously effective configuration version number and writes the configuration read exception into the order audit record. After the business objective configuration file is read, the multi-objective scoring module generates weight parameters for the multi-objective scoring function based on freight weight, timeliness weight, load balancing weight, and damage risk weight. These weight parameters are written into the scoring task record along with the configuration version number.

[0067] After the credible fulfillment constraint label enters this step, it is mapped to a soft penalty item or a weight item. Specifically, the multi-objective scoring module maps the expedited label to a time-sensitive weight item, the fragile label to a fragile item damage risk penalty item, and the secondary packaging label to a warehouse processing capacity penalty item. If the expedited label exists in the credible fulfillment constraint label, the multi-objective scoring module increases the weight value of the time-sensitive weight item in the scoring function and reads the matching status between the promised timeliness field and the delivery person's service time window. If the fragile label exists, the multi-objective scoring module reads the delivery person's historical breakage rate and writes it into the fragile item damage risk penalty item. If the secondary packaging label exists, the multi-objective scoring module reads the warehouse packaging capacity matching status and writes warehouse combinations that do not fully match but have not been removed by hard constraints into the warehouse processing capacity penalty item.

[0068] When scoring and ranking warehouse-delivery personnel combinations, the multi-objective scoring module reads the combination records in the feasible candidate set one by one. For each warehouse-delivery personnel combination, the multi-objective scoring module reads the warehouse number, delivery personnel number, inventory status, warehouse packaging capacity matching status, delivery personnel service time window matching status, delivery personnel carrying capacity status, number of orders in transit, and historical damage rate; then, it calculates the combination score according to the multi-objective scoring function and writes the combination score into the candidate allocation scheme record. Multiple candidate allocation schemes are sorted according to the combination score. For multiple candidate allocation schemes with the same combination score, the multi-objective scoring module can sort them according to the newest inventory snapshot timestamp; if the inventory snapshot timestamps are the same, they can be sorted according to the newest delivery personnel status timestamp.

[0069] In one implementation, the orders to be allocated include expedited and fragile labels. The current configuration version number in the business objective configuration file is P1, and the timeliness weight and damage risk weight corresponding to P1 are higher than the previous configuration version. The multi-objective scoring module reads four warehouse-deliveryman combinations from the feasible candidate set and calculates the freight cost item, delivery distance cost item, deliveryman load balancing item, timeliness urgency weight item, and fragile item damage risk penalty item for each combination. Combinations with a large number of orders in transit for deliverymen and mismatched historical damage rates are given higher penalty scores; combinations with closer distances and matching service time windows receive lower overall scores. The multi-objective scoring module sorts the four candidate allocation schemes according to the scoring results and generates a candidate allocation scheme set.

[0070] The candidate allocation scheme set includes candidate scheme number, order number, warehouse number, deliveryman number, combined score, score item details, configuration version number of the business objective configuration file, trusted fulfillment constraint tag reference identifier, inventory snapshot timestamp, and status timestamp. The multi-objective scoring module also writes the configuration version number to the order allocation audit record. This candidate allocation scheme set is not directly used as the final order allocation result, but rather as input for S500 to perform feasibility backtracking verification. S500 reads the candidate allocation scheme set and performs feasibility backtracking verification on the sorted candidate allocation schemes based on product SKU inventory, deliveryman capacity, and service time window.

[0071] S500. Based on the candidate allocation scheme set, perform a feasibility backtracking check on product SKU inventory, delivery personnel capacity, and service time windows, generate inventory feasibility check results, and output order splitting decision data based on the inventory feasibility check results. The order splitting decision data includes target warehouse number, target delivery personnel number, order splitting / merging instructions, and estimated fulfillment time windows.

[0072] This step is executed by the inventory feasibility verification module, the order splitting / merging decision module, and the result writing module. The inventory feasibility verification module receives the candidate allocation scheme set generated by S400 and reads the warehouse number, delivery person number, product SKU inventory status, delivery person capacity status, service time window matching status, and combination score from each candidate allocation scheme according to the candidate scheme sorting. The order splitting / merging decision module reads the inventory feasibility verification results generated by the inventory feasibility verification module and generates order splitting decision data based on the results of single-warehouse inventory verification, cross-warehouse inventory verification, and merged delivery verification. The result writing module writes the order splitting decision data into the order splitting result table and outputs the corresponding fields to the warehouse picking queue and the delivery terminal notification interface.

[0073] The feasibility backtracking verification includes verification of product SKU inventory, delivery personnel capacity, and service time windows. Product SKU inventory verification checks whether the warehouse corresponding to the candidate allocation scheme has available inventory of the product SKUs for the orders to be allocated. Delivery personnel capacity verification checks whether the volume and weight of the products corresponding to the orders to be allocated, after adding the delivery personnel's allocated volume and weight, exceed the delivery personnel's capacity limit. Service time window verification checks whether the service time windows of the candidate delivery personnel cover the promised delivery time or delivery period restriction labels of the orders to be allocated. The feasibility backtracking verification is performed one by one according to the order in the candidate allocation scheme set; when the verification of the current candidate allocation scheme fails, the inventory feasibility verification module retains the failure reason field and rolls back to the next candidate allocation scheme.

[0074] In single-warehouse inventory verification, the inventory feasibility verification module reads the available inventory of product SKUs in the target warehouse based on the target warehouse number in the candidate allocation scheme, and verifies item by item whether the same warehouse has available inventory of all product SKUs in the order to be split. When the same warehouse has available inventory of all product SKUs, and the delivery capacity verification and service time window verification pass, the inventory feasibility verification module generates single-warehouse shipment splitting results. The single-warehouse shipment splitting results include order number, target warehouse number, target delivery person number, product SKU list, estimated fulfillment time window, inventory snapshot timestamp, and delivery person status timestamp. The order splitting / merging decision module writes the single-warehouse shipment splitting results into the splitting decision data and writes the splitting / merging instruction field into the single-warehouse shipment status.

[0075] When a single-warehouse inventory check shows that the same warehouse does not have available inventory for all product SKUs, the inventory feasibility check module performs cross-warehouse inventory check. Cross-warehouse inventory check involves traversing the product SKU inventory combinations across multiple warehouses and generating cross-warehouse splitting candidate results based on the product SKU list in the order to be split. For each cross-warehouse splitting candidate result, the inventory feasibility check module checks the available inventory of product SKUs in the warehouse corresponding to each sub-waybill and calculates the splitting freight increment corresponding to that candidate result. If the available inventory of product SKUs in the warehouse corresponding to each sub-waybill meets the quantity of product SKUs in the corresponding sub-waybill, and the splitting freight increment does not exceed the splitting freight increment threshold in the business target configuration file, the splitting / merging decision module generates a cross-warehouse splitting instruction and a sub-waybill list, and writes these to the order splitting decision data. If the splitting freight increment exceeds the splitting freight increment threshold, the inventory feasibility check module writes the cross-warehouse splitting candidate result to the check failure record and continues to read the next cross-warehouse splitting candidate result.

[0076] Delivery driver capacity verification is invoked in both single-warehouse and cross-warehouse inventory verification. The inventory feasibility verification module reads the volume and weight of goods in the order to be split and the allocated volume and weight in the real-time status snapshot of the candidate delivery driver; then it calculates the total volume and weight after adding the order to be split or the corresponding sub-waybill, and matches it with the delivery driver's capacity limit. If the total volume or total weight exceeds the delivery driver's capacity limit, the inventory feasibility verification module writes the candidate solution into the capacity verification failure record and falls back to the next candidate solution. Service time window verification reads the promised timeliness, delivery time restriction label, and delivery driver service time window; when the delivery driver service time window does not cover the time interval corresponding to the promised timeliness or delivery time restriction label, the inventory feasibility verification module writes the service time window verification failure record and falls back to the next candidate solution.

[0077] This step also includes delivery consolidation verification. Before generating the final order splitting decision data, the order splitting and consolidation decision module queries the order splitting task queue to see if there are adjacent pending orders with the same delivery address or the same recipient. For the adjacent pending orders found, the order splitting and consolidation decision module reads the target delivery person, service time window, product volume, product weight, and reliable fulfillment constraint label for the adjacent pending orders; then it verifies whether the adjacent pending orders correspond to the same delivery person, whether they are in the same service time window, whether the total volume and total weight do not exceed the delivery person's carrying capacity limit, and whether there are no mutual exclusion labels between the adjacent pending orders. The mutual exclusion labels can be formed by a combination of fragile labels and heavy object crush risk labels, or by configuring mutual exclusion relationships in the label dictionary. When adjacent pending orders correspond to the same delivery person, are in the same service time window, the total volume and total weight do not exceed the delivery person's carrying capacity limit, and there are no mutual exclusion labels, the order splitting and consolidation decision module generates a consolidation instruction and a consolidation waybill association, and writes the consolidation instruction and the consolidation waybill association into the order splitting decision data.

[0078] In one engineering implementation, the S400 outputs a set of candidate allocation schemes containing three candidate schemes. The inventory feasibility verification module reads the top-ranked candidate scheme, verifies that the inventory of both SKU-A and SKU-B in the target warehouse meets the order quantity, and reads the allocated volumetric weight of the candidate delivery personnel. After delivery personnel capacity verification and service time window verification, the order splitting / merging decision module generates a single-warehouse shipment splitting result. If the top-ranked candidate scheme has only SKU-A inventory in the target warehouse and no SKU-B inventory, the inventory feasibility verification module reads the second-ranked cross-warehouse candidate scheme, allocates SKU-A to warehouse W1, allocates SKU-B to warehouse W2, and calculates the order splitting freight increase. If the order splitting freight increase does not exceed the order splitting freight increase threshold, the order splitting / merging decision module generates a cross-warehouse order splitting instruction and two sub-waybill records.

[0079] In another implementation, an order to be split shares the same delivery address as another order in the split task queue, and both orders correspond to the same delivery person. The split / merge decision module reads the volume and weight of the goods in both orders, calculates the total volume and weight, and matches it with the delivery person's carrying capacity limit. Simultaneously, it reads the reliable fulfillment constraint tags of both orders, finding no mutually exclusive merge tags. When both orders are within the same service time window, the split / merge decision module generates a merge instruction and a merge waybill association. If one order contains a fragile tag and the other corresponds to a heavy object crush risk tag, the split / merge decision module generates a mutually exclusive merge identifier and retains the original split order path.

[0080] The final output of order splitting decision data includes the order number, target warehouse number, target delivery person number, order splitting / merging instruction, estimated fulfillment time window, sub-waybill list, merged waybill association, inventory feasibility verification result, configuration version number of the business target configuration file, inventory snapshot timestamp, delivery person status timestamp, and order splitting audit record. The result writing module writes the order splitting decision data to the order splitting result table. When the order splitting decision data includes the target warehouse number and product SKU list, the result writing module outputs the warehouse number, product SKU list, and sub-waybill list to the warehouse picking queue. When the order splitting decision data includes the target delivery person number, the result writing module outputs the delivery person number, estimated fulfillment time window, and merged waybill association to the delivery terminal notification interface. Inventory feasibility verification failure records, capacity verification failure records, and service time window verification failure records are written to the order splitting audit record and used as reference records for warehouse availability status, delivery person real-time status, and business target configuration file version when subsequent orders enter S300 and S400.

[0081] Example 2: Figure 2 This diagram illustrates a structural block diagram of an intelligent order proxy routing and dynamic order allocation method based on a large language model according to an embodiment of the present invention. Figure 2 As shown, the structure may include:

[0082] The order semantic input module 01 is used to receive the structured fields, unstructured remarks text, and historical order behavior summaries of orders to be assigned. It performs order identifier binding and semantic input encapsulation on the structured fields, unstructured remarks text, and historical order behavior summaries to generate order semantic input data. Specifically, the order semantic input module receives the structured fields from the order management system, the unstructured remarks text from the order submission end, and reads historical order behavior summaries from the historical order database. The structured fields include order number, product SKU list, delivery address, promised delivery time, product volume, and product weight. The unstructured remarks text includes buyer remarks, buyer comments, and special instructions. The historical order behavior summaries include historical delivery time preferences, historical damage complaint records, and historical designated delivery preferences. The order semantic input module uses the order number as an index to access the product SKU list... The order semantic input module binds the order structured fields, unstructured notes, and historical order behavior summaries, and writes the field source identifier, field version number, and receiving timestamp into the data. When the order number, product SKU list, delivery address, or promised time limit is missing, the order semantic input module generates an abnormal status field and retains the original input content. When the unstructured notes are empty, the order semantic input module writes an empty text identifier. When the historical order behavior summary does not exist, the order semantic input module writes a no-historical-summary identifier. The order semantic input module encapsulates the bound order structured fields, unstructured notes, and historical order behavior summaries according to the semantic input template to form order semantic input data, and passes the order semantic input data to the tag parsing and verification module for the tag parsing and verification module to call the unstructured notes, historical order behavior summary, product SKU list, delivery address, and promised time limit.

[0083] The tag parsing and verification module 02, connected to the order semantic input module, is used to call a large language model to perform performance semantic parsing based on the order semantic input data, generating a structured tag set containing performance constraint tags and tag confidence levels. It then performs format verification, tag enumeration verification, and confidence level filtering on the structured tag set to generate reliable performance constraint tags and tag records to be sampled. Specifically, the tag parsing and verification module receives order semantic input data from the order semantic input module and reads the unstructured remarks text, historical order behavior summary, product SKU list, delivery address, promised delivery time, and field version number. The tag parsing and verification module calls a large language model according to the tag dictionary and structured output template to perform performance semantic parsing on the order semantic input data, forming a structured tag set. The structured tag set includes tag type, tag confidence level, tag source field, constraint attributes, and tag status. The tag type belongs to a tag dictionary composed of expedited, fragile, secondary packaging, delivery time restrictions, and specified delivery preferences. The constraint attributes include hard constraint attributes. The tag parsing and verification module performs field integrity verification on the structured tag set and generates format verification results. It matches the performance constraint tags with the tag dictionary to generate tag enumeration verification results. It compares the tag confidence level with a confidence threshold to generate confidence filtering results. When the structured tag set lacks tag type, tag confidence level, tag source field, constraint attribute, or tag status, the tag parsing and verification module writes the corresponding tag record into the tag record to be inspected. When a performance constraint tag does not belong to the tag dictionary, the tag parsing and verification module writes the corresponding tag status into the tag record to be inspected. When there are tag conflicts among multiple performance constraint tags, the tag parsing and verification module writes the conflict status. The tag parsing and verification module generates a reliable performance constraint tag based on the format verification results, tag enumeration verification results, and confidence filtering results, and passes the reliable performance constraint tag to the candidate filtering module, which then associates and stores the tag record to be inspected with the order number, field version number, and tag source field.

[0084] Candidate filtering module 03, connected to the tag parsing and verification module, is used to obtain inventory snapshots of multiple warehouses and real-time status snapshots of multiple delivery personnel. Based on the trusted fulfillment constraint tags, it performs hard constraint filtering on warehouse and delivery personnel candidates to generate a feasible candidate set. Specifically, the candidate filtering module receives trusted fulfillment constraint tags from the tag parsing and verification module and reads inventory snapshots of multiple warehouses from the warehouse management system and real-time status snapshots of multiple delivery personnel from the delivery management system. The warehouse inventory snapshots include warehouse number, available inventory of product SKUs, warehouse service area, warehouse packaging capacity, and inventory snapshot timestamp. The delivery personnel real-time status snapshots include delivery personnel number, current location, service area, number of orders in transit, allocated volumetric load, historical damage rate, and status timestamp. The candidate filtering module first matches the delivery address with the warehouse service area to generate warehouse candidates; then it matches the delivery address with the delivery personnel service area to generate delivery personnel candidates. When the inventory snapshot timestamp or status timestamp is inconsistent with the current order assignment task, the candidate filtering... The module rereads the corresponding inventory snapshot or real-time status snapshot and writes the failed warehouse candidate objects or delivery person candidate objects into the snapshot exception record. The candidate filtering module matches the warehouse service range, warehouse packaging capacity, delivery person service area, delivery person service time window, and delivery person historical damage rate based on the delivery time restriction label, specified delivery preference label, secondary packaging label, and fragile label in the trusted fulfillment constraint label. When the warehouse service range, warehouse packaging capacity, delivery person service area, or delivery person service time window do not match, the candidate filtering module deletes the corresponding candidate object from the candidate objects. After hard constraint filtering, the candidate filtering module combines the remaining warehouse candidate objects with the remaining delivery person candidate objects to generate a feasible candidate set. The feasible candidate set includes warehouse number, delivery person number, product SKU inventory status, warehouse packaging capacity matching status, delivery person service time window matching status, delivery person capacity status, trusted fulfillment constraint label reference identifier, inventory snapshot timestamp, and status timestamp, and is passed to the scoring and sorting module by the candidate filtering module.

[0085] The scoring and ranking module 04, connected to the candidate filtering module, is used to map the reliable fulfillment constraint label to a soft penalty term or weight term in a multi-objective scoring function based on the feasible candidate set and the business objective configuration file, and to score and rank the warehouse-delivery personnel combination to generate a set of candidate allocation schemes. Specifically, the scoring and ranking module receives the feasible candidate set from the candidate filtering module and calls the warehouse number, delivery personnel number, product SKU inventory status, warehouse packaging capacity matching status, delivery personnel service time window matching status, delivery personnel capacity status, and reliable fulfillment constraint label reference identifier in the feasible candidate set. The scoring and ranking module reads the currently effective business objective configuration file, which includes freight weight, timeliness weight, load balancing weight, damage risk weight, order splitting freight increment threshold, and configuration version number. When the configuration version number of the business objective configuration file is inconsistent with the configuration version number registered in the current order splitting task, the scoring and ranking module rereads the currently effective business objective configuration file and writes the reading status into the order splitting audit record. The scoring and ranking module maps the reliable fulfillment constraint label to a soft penalty term or weight term in a multi-objective scoring function to generate a set of candidate allocation schemes. The target scoring function includes soft penalty or weight items, where the expedited label is mapped to a time-sensitive weight item, the fragile label is mapped to a fragile item damage risk penalty item, and the secondary packaging label is mapped to a warehouse handling capacity penalty item. The multi-objective scoring function includes freight cost items, delivery distance cost items, delivery personnel load balancing items, time-sensitive weight items, fragile item damage risk penalty items, and additional freight cost increment items for split orders. The scoring and sorting module reads the warehouse-delivery personnel combinations in the feasible candidate set one by one and generates a combination score based on the weight parameters in the business objective configuration file. When multiple warehouse-delivery personnel combinations have the same combination score, the scoring and sorting module sorts them according to the inventory snapshot timestamp and status timestamp. After sorting, the scoring and sorting module generates a candidate allocation scheme set, which includes a candidate scheme number, order number, warehouse number, delivery personnel number, combination score, scoring item details, configuration version number, trusted fulfillment constraint label reference identifier, inventory snapshot timestamp, and status timestamp. The scoring and sorting module passes the candidate allocation scheme set to the backtracking decision module and writes the configuration version number into the order audit record.

[0086] The backtracking decision module 05 is connected to the scoring and sorting module. It is used to perform feasibility backtracking verification of product SKU inventory, delivery personnel capacity and service time window based on the candidate allocation scheme set, generate inventory feasibility verification results, and output order splitting decision data based on the inventory feasibility verification results. The order splitting decision data includes target warehouse number, target delivery personnel number, order splitting / merging instructions and expected fulfillment time window. Specifically, the backtracking decision module receives a set of candidate allocation schemes from the scoring and sorting module, and reads the warehouse number, delivery person number, product SKU inventory status, delivery person capacity status, service time window matching status, combined score, and configuration version number according to the sorting corresponding to the candidate scheme number. Based on the target warehouse number in the candidate allocation scheme, the backtracking decision module verifies whether the same warehouse has available inventory for all product SKUs in the order to be split. When the same warehouse has available inventory for all product SKUs, the backtracking decision module continues to verify the delivery person capacity and service time window, and generates a single-warehouse shipment splitting result. When the same warehouse does not have available inventory for all product SKUs, the backtracking decision module traverses the product SKU inventory combinations of multiple warehouses, generates cross-warehouse splitting candidate results, and verifies the available inventory of product SKUs in the warehouse corresponding to each sub-shipment. The backtracking decision module calculates the splitting freight increment corresponding to the cross-warehouse splitting candidate results and compares the splitting freight increment with the data in the business target configuration file. The backtracking decision module matches the order splitting freight increment threshold; when the available inventory of the SKUs in the warehouse corresponding to each sub-waybill meets the quantity of the corresponding sub-waybill's SKUs, and the order splitting freight increment does not exceed the order splitting freight increment threshold, the backtracking decision module generates a cross-warehouse order splitting instruction and a sub-waybill list; when there are adjacent pending orders with the same delivery address or the same recipient, the backtracking decision module verifies whether the adjacent pending orders correspond to the same delivery person, whether they are in the same service time window, whether the total volume and total weight do not exceed the delivery person's carrying capacity limit, and whether there are no merge mutually exclusive tags between adjacent pending orders; when the verification passes, the backtracking decision module generates a merge instruction and a merged waybill association; the backtracking decision module writes the target warehouse number, target delivery person number, order splitting / merging instruction, expected fulfillment time window, sub-waybill list, merged waybill association, inventory feasibility verification result, inventory snapshot timestamp, status timestamp, and configuration version number into the order splitting decision data, and outputs the order splitting decision data to the order splitting result table.

Claims

1. A method for intelligent order proxy routing and dynamic order allocation based on a large language model, characterized in that, include: S100: Receive the structured fields, unstructured remarks text, and historical order behavior summary of the orders to be split; bind the order identifier and encapsulate the semantic input of the structured fields, unstructured remarks text, and historical order behavior summary to generate order semantic input data; S200. Based on the order semantic input data, call the large language model to perform performance semantic parsing, generate a structured tag set containing performance constraint tags and tag confidence, and perform format verification, tag enumeration verification and confidence filtering on the structured tag set to generate reliable performance constraint tags and tag records to be sampled. S300: Obtain inventory snapshots of multiple warehouses and real-time status snapshots of multiple delivery personnel; perform hard constraint filtering on warehouse candidate objects and delivery personnel candidate objects based on the trusted fulfillment constraint tags to generate a feasible candidate set. S400. Based on the feasible candidate set and business objective configuration file, the reliable performance constraint label is mapped to a soft penalty term or weight term in the multi-objective scoring function, and the warehouse-deliveryman combination is scored and sorted to generate a candidate allocation scheme set. S500. Based on the set of candidate allocation schemes, perform a feasibility backtracking verification of product SKU inventory, delivery personnel capacity, and service time window, generate inventory feasibility verification results, and output order splitting decision data based on the inventory feasibility verification results. The order splitting decision data includes target warehouse number, target delivery personnel number, order splitting / merging instructions, and expected fulfillment time window.

2. The method according to claim 1, characterized in that, The structured fields of the order include order number, product SKU list, shipping address, promised delivery time, product volume, and product weight; the unstructured remarks text includes buyer remarks, buyer comments, and special instructions; the historical order behavior summary includes historical delivery time preferences, historical damage complaint records, and historical designated delivery preferences; the order identifier binding includes writing the order number into the product SKU list, the shipping address, the promised delivery time, the unstructured remarks text, and the historical order behavior summary.

3. The method according to claim 1, characterized in that, The structured tag set includes tag type, tag confidence level, tag source field, constraint attributes, and tag status; the tag type belongs to a tag dictionary consisting of expedited, fragile, secondary packaging, delivery time restriction, and specified delivery preference; the constraint attributes include hard constraint attributes and soft constraint attributes; the tag status includes trusted status, pending inspection status, and conflict status.

4. The method according to claim 1, characterized in that, The structured tag set is subjected to format validation, tag enumeration validation, and confidence filtering, including: performing field integrity validation on the structured tag set and generating a format validation result; matching the performance constraint tags with a preset tag dictionary and generating a tag enumeration validation result; comparing the tag confidence with a confidence threshold and generating a confidence filtering result; and generating the trusted performance constraint tags and the tag records to be sampled based on the format validation result, the tag enumeration validation result, and the confidence filtering result.

5. The method according to claim 1, characterized in that, The warehouse inventory snapshot includes warehouse number, available inventory of product SKUs, warehouse service area, warehouse packaging capacity, and inventory snapshot timestamp; the delivery person's real-time status snapshot includes delivery person number, current location, service area, number of orders in transit, allocated volumetric load, historical damage rate, and status timestamp; the hard constraint filtering includes removing candidate objects from the candidate objects based on the trusted fulfillment constraint label, where the warehouse service area, warehouse packaging capacity, delivery person service area, or delivery person service time window do not match.

6. The method according to claim 1, characterized in that, The multi-objective scoring function includes a freight cost item, a delivery distance cost item, a delivery person load balancing item, a time urgency weight item, a fragile item damage risk penalty item, and an additional freight cost increment item for split orders. Mapping the credible performance constraint labels to soft penalty terms or weight terms in a multi-objective scoring function includes: mapping expedited labels to time-sensitive weight terms, fragile labels to fragile item breakage risk penalty terms, and secondary packaging labels to warehouse processing capacity penalty terms.

7. The method according to claim 1, characterized in that, The business objective configuration file includes freight weight, timeliness weight, load balancing weight, damage risk weight, order splitting freight increment threshold, and configuration version number; S400 includes: reading the currently effective business objective configuration file, generating weight parameters for the multi-objective scoring function based on the freight weight, the timeliness weight, the load balancing weight, and the damage risk weight; and writing the configuration version number into the order splitting audit record.

8. The method according to claim 1, characterized in that, The feasibility backtracking verification includes single-warehouse inventory verification and cross-warehouse inventory verification. The single-warehouse inventory verification includes: based on the target warehouse number in the candidate allocation scheme, verifying whether the same warehouse has available inventory of all product SKUs in the order to be split, and generating a single-warehouse shipment splitting result when the same warehouse has available inventory of all product SKUs. The cross-warehouse inventory verification includes: when the same warehouse does not have available inventory of all product SKUs, traversing the product SKU inventory combinations of multiple warehouses to generate cross-warehouse splitting candidate results.

9. The method according to claim 8, characterized in that, After generating cross-warehouse order splitting candidate results, the process further includes: verifying the available inventory of product SKUs in the warehouse corresponding to each sub-waybill, and calculating the order splitting freight increment corresponding to the cross-warehouse order splitting candidate results; when the available inventory of product SKUs in the warehouse corresponding to each sub-waybill meets the quantity of product SKUs in the corresponding sub-waybill, and the order splitting freight increment does not exceed the order splitting freight increment threshold, generating a cross-warehouse order splitting instruction and a sub-waybill list; and writing the cross-warehouse order splitting instruction and the sub-waybill list into the order splitting decision data.

10. The method according to claim 1, characterized in that, The feasibility backtracking verification also includes a merged delivery verification; the merged delivery verification includes: when there are adjacent pending orders with the same delivery address or the same recipient, verifying whether the adjacent pending orders correspond to the same delivery person, whether they are in the same service time window, whether the total volume and total weight do not exceed the delivery person's carrying capacity limit, and whether there are no merge mutual exclusion tags between the adjacent pending orders; when the adjacent pending orders correspond to the same delivery person, are in the same service time window, the total volume and total weight do not exceed the delivery person's carrying capacity limit, and there are no merge mutual exclusion tags, generating a merge instruction and a merged waybill association; and writing the merge instruction and the merged waybill association into the order splitting decision data.

Images