A commodity code classification and rule closed loop optimization method and system

Abstract

The application belongs to the technical field of commodity code classification, and discloses a commodity code classification and rule closed-loop optimization method and system. Through a local student model combined with a hierarchical classification knowledge base, a progressive layer-by-layer reasoning is adopted to replace one-time code generation. First, the commodity information is standardized and processed in the local execution environment to generate a query representation. Then, based on the coding hierarchical relationship and the determined upper path, the current layer rule context is dynamically constructed, so as to guide the model to select nodes layer by layer until the final code is output. The method can significantly improve the classification accuracy and reasoning efficiency, realize traceable iteration and non-interference verification of rules, ensure stable performance in long-tail categories and easily confused scenarios, and form a collaborative closed loop of low-cost local execution and high-performance cloud optimization.

Description

Technical Field

[0001] This invention belongs to the field of commodity coding and classification technology, and in particular relates to a commodity coding and classification and rule closed-loop optimization method and system. Background Technology

[0002] Commodity coding and classification is a core foundational step in import and export declaration, tariff calculation, trade statistics, regulatory condition determination, and trade compliance review. Mainstream coding systems, exemplified by the Harmonized System (HS) commodity name and coding system, possess a strict hierarchical structure. Commodity classification requires a multi-level progressive judgment, proceeding sequentially from class, chapter, heading, subheading to the final tariff code. The classification result depends not only on the commodity name but also on a comprehensive consideration of multi-dimensional technical characteristics such as composition, material properties, main uses, functional principles, processing methods, specifications, packaging status, and attributes of the entire machine or components. Furthermore, there are numerous inclusion rules, exclusion clauses, easily confused judgment conditions, and exceptions between adjacent coding nodes. Therefore, commodity classification is essentially a continuous decision-making process constrained by hierarchical logic and professional rules, demanding extremely high levels of expertise and accuracy.

[0003] Existing commodity coding and classification technologies suffer from several shortcomings: Direct generative classification methods typically input commodity descriptions into a large language model all at once and directly output the final codes, failing to fully utilize the hierarchical structure of the coding system. The model must make a one-time selection from a massive amount of final codes, which can easily lead to invalid codes, codes with invalid hierarchical relationships, or continuous path errors caused by misjudgments of upper-level nodes. While planar classification methods have lower inference costs, they cannot explicitly utilize parent-child node relationships, inclusion rules, exclusion rules, and easily confused candidate differences, resulting in insufficient classification accuracy for long-tail and similar categories. Retrieval enhancement methods can retrieve relevant knowledge from tariff entries and historical cases, but traditional retrieval often relies on text similarity as the core criterion, making it difficult to guarantee that the recalled content matches the current inference level and the determined upper-level path. Loading all category notes, chapter notes, item rules, and historical cases at once can easily cause contextual redundancy and rule conflicts. If only a small amount of text is retrieved, exclusion conditions and easily confused criteria that determine the classification results may be missed. Meanwhile, existing technologies lack a collaborative mechanism between different capability models: online models with large parameters and long contexts have strong error analysis and rule summarization capabilities, but their application in daily high-frequency product classification suffers from high inference costs, long response times, and the risk of business data leakage; local models with small parameters have advantages such as low cost, low latency, and ease of intranet deployment, making them suitable for high-frequency classification tasks, but their ability to independently analyze complex errors and continuously optimize professional rules is limited, and the two cannot form a complementary working loop. In addition, existing rule maintenance mechanisms have significant shortcomings: rule updates are usually manually modified directly based on a small number of errors, lacking version isolation between candidate rule drafts and official rules, and there is no systematic regression testing mechanism for target errors, easily confused samples, and historically correct samples. The repair of a single rule may lead to a decrease in the classification performance of other categories; at the same time, existing systems usually only save the final classification code, without fully recording candidate nodes at each level, called rules, candidate scores, and rule version information, making it difficult to locate and trace classification errors, and the effect of rule modification cannot be quantitatively verified.

[0004] It is evident that existing commodity coding and classification technologies cannot simultaneously achieve high execution efficiency, classification accuracy, rule iterability, and process interpretability. Summary of the Invention

[0005] This invention provides a product coding classification and rule closed-loop optimization method and system. This method can simultaneously take into account execution efficiency, classification accuracy, rule iterability and process interpretability.

[0006] To achieve the above objectives, the present invention adopts the following technical solution: A product coding classification and rule closed-loop optimization method includes: The system receives product information for products to be categorized in the local execution environment, performs preprocessing on the product information, including text cleaning, attribute extraction, and terminology standardization, and generates a product categorization query representation. Based on the hierarchical relationship of product codes in the local hierarchical classification knowledge base, the current reasoning layer and the determined upper-level candidate paths, a set of candidate knowledge nodes for the current layer is generated, and corresponding association rules are scheduled to construct the progressive rule context for the current layer. The product classification query representation and the current layer progressive rule context are input into the local execution student model, the selected node is output, and the candidate search space of the next layer is constrained according to the selected node. The reasoning is carried out layer by layer until the final product code is obtained. Record all nodes, calling rules, scores, and complete paths for this classification to form a classification evidence chain and rule evolution log, and identify misclassified samples based on manual review results or known correct codes; By comparing the predicted classification path of the erroneous sample with the correct classification path, the target error level of the first bifurcation is located, and the corresponding level association information is extracted to generate an error case diagnosis package. Input the error diagnosis package into the upstream strong teacher model, analyze the rule defects of the target error level, and generate candidate rule patch drafts associated with the target knowledge nodes; Perform a format validity check on the candidate rule patch draft, and write it into the draft rule version area, which is isolated from the official rule version, once the check passes. In the local isolated backtesting environment, the official rule version and the draft rule version are loaded respectively, and the local student model is called to perform a comparative backtest to obtain the backtesting performance indicators. If the backtest performance metrics meet the preset conditions, the candidate rule patch will be released as the official rule version and the local hierarchical classification knowledge base will be updated; otherwise, the backtest results will be fed back for further optimization.

[0007] Furthermore, the product classification query representation includes standardized product text and a structured set of product attributes; the structured set of product attributes includes at least one of the following: product type, composition, material, function and purpose, working principle, processing method, specifications and model, packaging status, status of the whole machine or parts, and declaration elements; the progressive rule context is dynamically generated based on the current inference layer, the upper-level candidate path, and the current-level candidate knowledge node.

[0008] Furthermore, the locally executed student model is at least one of the following: a small-parameter language model, a text classification model, a retrieval-enhanced generation model, and a rule-injection-based language model deployed on an enterprise server, edge computing device, enterprise private cloud, or business terminal; the locally executed student model performs product classification according to the official rule version.

[0009] Furthermore, the error diagnosis package includes at least the product attributes that have been structured or desensitized, the predicted classification path, the correct classification path, the first fork level, the correct node and the incorrect node, the corresponding candidate score, the current formal rule summary, and the triggering error identifier; When the upstream strong teacher model is provided by an external online model service, the complete original product profile, full historical dataset, and complete hierarchical classification knowledge base are not sent to the external online model service.

[0010] Furthermore, the upstream strong teacher model is a language model whose parameter size, reasoning ability, or context window length is greater than that of the locally executed student model; The upstream strong teacher model identifies at least one rule defect based on the error diagnosis package and rule knowledge related to the target error level, including: key product attributes not covered by rules, improper attribute judgment priority settings, conflict between inclusion and exclusion rules, insufficient judgment conditions for easily confused nodes, insufficient upper-level routing prompts, or incomplete lower-level candidate guidance. It then outputs the rule defect type, target knowledge node, candidate rule patch content, rule applicable scope, triggering error information, and draft version number.

[0011] Furthermore, the comparative backtesting includes target error test performed on the target error sample that triggers the candidate rule patch, local regression test performed on the target knowledge node and its easily confused knowledge node, and global regression test performed on historical correctly classified samples; the preset conditions include performance improvement conditions and non-degradation conditions. The performance improvement conditions include the target error sample repair rate or the target level accuracy reaching a preset improvement threshold. The non-degradation conditions include overall classification performance not falling below a preset threshold, non-target level performance degradation not exceeding a preset degradation threshold, and no new serious level path errors.

[0012] Furthermore, the classification evidence chain and the rule evolution log are associated with each other through the classification task identifier, knowledge node identifier, and rule version identifier, respectively; The classification evidence chain records at least the product classification query representation, candidate nodes at each level, actual call rules, rule version, candidate score, selected node, classification basis, and complete classification path; the rule evolution log records at least the candidate rule patch, target knowledge node, triggered error, backtest data range, backtest indicators, release conclusion, and release time.

[0013] A commodity coding classification and rule closed-loop optimization system includes: The receiving module is used to receive product information of products to be classified in the local execution environment, preprocess the product information, including text cleaning, attribute extraction and terminology standardization, and generate product classification query representation; The construction module is used to generate a set of candidate knowledge nodes for the current layer based on the hierarchical relationship of product codes in the local hierarchical classification knowledge base, the current inference layer and the determined upper-layer candidate paths, and to schedule the corresponding association rules to construct the progressive rule context for the current layer. The reasoning module is used to input the product classification query representation and the current layer's progressive rule context into the local execution student model, output the selected node, constrain the next layer's candidate search space based on the selected node, and reason layer by layer until the final product code is obtained; The recording module is used to record all nodes, calling rules, scores and complete paths for this classification, forming a classification evidence chain and rule evolution log, and identifying misclassified samples based on manual review results or known correct codes. The comparison module is used to compare the predicted classification path of erroneous samples with the correct classification path, locate the target error level of the first bifurcation, extract the corresponding level association information, and generate an error diagnosis package. The analysis module is used to input the error diagnosis package into the upstream strong teacher model, analyze the rule defects of the target error level, and generate candidate rule patch drafts associated with the target knowledge nodes. The verification module is used to perform format validity checks on the candidate rule patch drafts. Once the checks are passed, the draft rule version is written to the draft rule version area, which is isolated from the official rule version. The backtesting module is used to load the official rule version and the draft rule version in a local isolated backtesting environment, call the local execution student model to perform a comparative backtest, and obtain backtesting performance indicators. The decision module is used to release the candidate rule patch as the official rule version and update the local hierarchical classification knowledge base if the backtest performance indicators meet the preset conditions; otherwise, it will provide feedback on the backtest results for further optimization.

[0014] A commodity coding classification and rule closed-loop optimization device includes: Memory, used to store computer programs; A processor is used to implement the above-mentioned commodity coding classification and rule closed-loop optimization method when executing the computer program.

[0015] A computer-readable storage medium storing a computer program, which, when executed by a processor, is used to implement the above-described commodity code classification and rule closed-loop optimization method.

[0016] Compared with the prior art, the present invention has the following beneficial effects: This invention provides a product coding classification and rule closed-loop optimization method. It utilizes a local student model combined with a hierarchical classification knowledge base, employing progressive, layer-by-layer reasoning instead of one-time coding generation. First, product information is standardized in the local execution environment to generate query representations. Then, based on the coding hierarchy and the determined upper-level paths, the current layer's rule context is dynamically constructed, guiding the model to select nodes layer by layer until the final code is output. This method leverages the tree structure of the coding system to decompose the decision space, avoiding blind selection from a massive amount of final codes. The rule context precisely constrains the candidate range for each layer, effectively eliminating invalid codes and path errors. Simultaneously, a strong teacher model is introduced to perform layered diagnosis of erroneous samples and generate rule patches. After format verification and isolated backtesting, the knowledge base is safely updated. This method significantly improves classification accuracy and reasoning efficiency, enabling traceable iteration and interference-free verification of rules, ensuring stable performance in long-tail categories and easily confused scenarios, and forming a collaborative closed loop of low-cost local execution and high-performance cloud optimization. Attached Figure Description

[0017] Figure 1 A schematic diagram of a rule iteration closed loop based on the collaboration between an upstream strong teacher model and a local execution student model, provided in an embodiment of the present invention; Figure 2 A flowchart illustrating the implementation of the commodity coding classification and rule closed-loop optimization method provided in this embodiment of the invention; Figure 3 A schematic diagram illustrating the progressive rule context disclosure provided in an embodiment of the present invention; Figure 4 This is a schematic diagram of the classification evidence chain structure provided in an embodiment of the present invention; Figure 5 This is a schematic diagram illustrating the upstream strong teacher model error diagnosis and rule patch generation provided in an embodiment of the present invention; Figure 6 This is a schematic diagram illustrating the rule isolation verification and release decision-making process provided in an embodiment of the present invention. Figure 7 This is a main flowchart of a commodity coding classification and rule closed-loop optimization method provided in an embodiment of the present invention; Figure 8 This is a schematic diagram of the structure of a commodity coding classification and rule closed-loop optimization system provided in an embodiment of the present invention. Detailed Implementation

[0018] To further understand the content of this invention, the invention will be described in detail below with reference to the accompanying drawings and specific embodiments. It should be understood that the embodiments are merely illustrative and not limiting of the invention.

[0019] As described in the background section, the shortcomings and deficiencies of the existing technology are as follows: Existing generative classification methods typically input product descriptions into a large language model all at once and directly output the final product code. This method does not fully utilize the hierarchical structure of the product coding system; the model needs to make a one-time selection from a large number of final codes, which easily leads to non-existent codes, codes with invalid hierarchical relationships, or continuous path errors caused by misjudgments from higher layers. While planar classification methods can output codes with lower inference costs, they struggle to explicitly utilize parent-child node relationships, inclusion rules, exclusion rules, and differences between easily confused candidates, making them prone to errors in long-tail categories and similar categories.

[0020] Retrieval enhancement methods can retrieve relevant knowledge from tariff entries and historical cases, but traditional retrieval often relies mainly on text similarity, making it difficult to guarantee that the recalled content matches the current reasoning level and the already determined upper-level path. Loading a large number of class notes, chapter notes, item rules, and historical cases into the model at once can easily lead to contextual redundancy and rule conflicts; if only a small amount of text is retrieved, exclusion conditions that determine the classification results and easily confused discrimination criteria may be missed.

[0021] On the other hand, online models with strong performance and long context windows have better error analysis and rule summarization capabilities, but using them for daily classification of every product leads to high inference costs, long response times, and the risk of business data leakage. Local models with smaller parameter sizes have advantages such as low cost, low latency, and ease of deployment within the intranet, making them suitable for performing high-frequency classification tasks, but their ability to independently analyze complex errors and continuously optimize professional rules is limited. Current technology lacks a collaborative mechanism that allows small local models to stably execute formal rules, allows strong upstream models to centrally analyze errors and generate rule optimization suggestions, and then allows small local models to backtest and verify the suggestions using full data.

[0022] Current rule maintenance processes typically involve personnel directly modifying rules based on a few errors. This lack of version isolation between candidate rule drafts and final rules, as well as the absence of systematic regression testing between target errors, easily confused samples, and historically correct samples, means that while a rule may fix a few errors, it may degrade performance in other categories. Existing systems usually only save the final code, failing to fully record candidate nodes at each layer, invoked rules, candidate scores, and rule versions. This makes it difficult to locate errors and quantify and verify the effects of rule modifications.

[0023] It is evident that existing product classification methods suffer from several problems, including high execution costs for large-scale models, insufficient ability to analyze complex errors in local small-scale models, redundancy in the context of full-scale rules, difficulty in locating error levels, lack of regression verification for rule updates, and the potential introduction of new errors through rule modifications.

[0024] To address the aforementioned issues, this embodiment provides a product coding classification and rule closed-loop optimization method. This method combines local execution efficiency, upstream strong model reasoning capabilities, progressive rule knowledge scheduling, and local backtesting verification. The local student model performs high-frequency, layer-by-layer classification based on formal rules, while the upstream strong teacher model diagnoses rule defects based on error evidence and generates rule patch drafts. Candidate rules are then released in a controlled manner after being verified through full local backtesting. This achieves continuous iteration of rule knowledge, interpretable reproducibility of the classification process, and reliable control over rule updates. This method separates the responsibilities of product classification execution and rule knowledge optimization: the local execution student model is responsible for understanding product input, invoking formal rules, and completing layer-by-layer classification; the upstream strong teacher model utilizes stronger reasoning capabilities and longer contextual capabilities to centrally analyze error samples, classification evidence chains, and related rules, generating candidate rule patch drafts; the local isolated backtesting module uses local test data and the local student model to verify whether candidate rules can improve the target error correction rate without causing significant performance degradation, and only updates the formal rule base after successful verification.

[0025] The following is a further explanation of the commodity coding classification and rule closed-loop optimization method provided in this embodiment: For example, such as Figure 1 As shown, this embodiment provides a product coding classification and rule closed-loop optimization method. Within a local trusted computing environment, it constructs a rule iteration closed loop consisting of a local execution classification chain, an upstream rule optimization chain, and a local verification and release chain. This enables continuous autonomous optimization of product classification capabilities. The entire closed-loop system can be deployed on an enterprise intranet or private cloud. If the upstream strong teacher model is provided as a controlled online model service, the local system only submits structured, anonymized error diagnosis packages to it through a secure interface. Complete original product data, full test data, and a hierarchical classification knowledge base are all stored locally, ensuring business data security and compliance.

[0026] The entire rule iteration loop is divided into three core stages: evaluation, optimization, and validation. The evaluation stage, serving as the starting point for the loop, aims to complete batch product classification reasoning and filter out erroneous samples for subsequent optimization. First, a pre-set training / test dataset is input into the system. This dataset contains product descriptions, attribute information, and standard classification labels for model inference and performance validation. The data then flows into the local execution environment to run a student model, which is a locally deployed Large Language Model (LLM). The model possesses three core capabilities: understanding the semantics of product input, executing local formal classification rules, and automatically classifying batch product codes. Based on the existing local formal rule base, the model performs reasoning and classification on the entire dataset. After the reasoning is completed, the system verifies and compares the full inference results, compiling a summary of inference results and errors. This includes statistics on the full classification results and precise location of all incorrectly classified samples and their error types. The summary of errors is then submitted to the upstream strong teacher model. This model is a strong model with stronger reasoning capabilities and a longer context window. It can be deployed in a local private cloud or as a controlled online service, undertaking the functions of in-depth error analysis and rule optimization design.

[0027] The optimization phase is the core optimization link in the closed loop. The strong model completes the rule design, and the rules are implemented and pre-validated locally. The upstream strong teacher model performs root cause analysis on the received error cases, locates the coverage blind spots, boundary ambiguities or logical conflicts of the existing classification rules, and outputs targeted rule optimization suggestions / candidate rule patch drafts to complete the initial design of the rules. The candidate rule patch drafts are fed back to the local system to enter the rule base update phase. The system stores the candidate rules in the draft version area of ​​the rule base and records the rule iteration versions, modifications and generation sources through the version management mechanism. It supports historical version backtracking and rollback. After the draft rules are updated, the re-evaluation process is started immediately. The local student model loads the updated draft rule base and re-infers and classifies the full test dataset, i.e., full backtesting. It outputs a new round of quantitative indicators such as classification accuracy and error distribution, providing a basis for judgment in the validation phase.

[0028] The verification phase is a closed-loop quality control stage. Quantitative verification determines whether a new rule should be officially launched. After re-evaluation, the system enters the core judgment node, namely, whether the accuracy has improved without significant degradation. Dual verification is performed from two dimensions: "positive improvement in effect" and "no negative degradation". If the classification accuracy improves under the new rule and there are no significant degradation issues such as scenario-specific accuracy decline or inference performance deterioration, the rule optimization is deemed effective, and the new rule / system upgrade is officially accepted and launched. The draft rule is then incorporated into the local official classification rule library for daily product classification business. If the accuracy does not meet the standard or there is significant business degradation, the optimization is deemed unsuccessful, and the system enters the stage of continuing to modify the rule / iterate optimization. Degraded samples and residual errors found in this round of verification can be fed back to the upstream strong teacher model to start the next round of error analysis and rule revision, forming a continuous iterative optimization closed loop.

[0029] like Figure 2 As shown, Figure 2 As shown, the overall process of the commodity coding classification and rule closed-loop optimization method provided in this embodiment is divided into two parts. The upper part is the online classification main process deployed in a local trusted environment, and the lower part is the offline rule iteration branch that links with the upstream strong teacher model. The two work together to achieve stable execution of high-frequency classification business and continuous iterative optimization of classification rules. The online classification main process takes the local execution student model as the core execution carrier. This model is deployed on enterprise servers, edge computing devices, enterprise private clouds or dedicated business terminals. It can adopt small parameter language models, text classification models, retrieval enhancement generation models or rule injection-based language models. Its main responsibility is to understand the commodity name, specification description and declaration elements, read the current official rule version, select candidate nodes layer by layer according to the hierarchical relationship of the commodity coding system and output structured classification results. The model does not directly generate or modify the official rules, thereby ensuring the stability and controllability of online classification behavior.

[0030] The online classification process begins by receiving product information and sequentially completing text cleaning and attribute extraction, generating a product classification query representation, and then determining the current inference layer. Based on a pre-built hierarchical classification knowledge base, the system generates candidate knowledge nodes for the current layer according to the determined upper-level paths. Each knowledge node in this hierarchical classification knowledge base is associated with at least a node code, node name, parent-child node relationship, classification rules, exclusion rules, easily confused node discrimination conditions, lower-level candidate guidance, and rule version. The system only schedules rule content related to the current layer, the current candidate path, and easily confused candidates, constructing a system that includes the product classification query representation, the current inference layer, the upper-level candidate path, the current candidate node, the classification and exclusion rules for the current candidate node, the discrimination conditions between easily confused candidates, and the lower-level candidate guidance. The system provides a structured output constraint context for the current layer's progressive rules, which is then used by the local student model to perform reasoning and output the current layer's candidate results. After each layer of reasoning is completed, the system redetermines the next layer's candidate knowledge nodes and the rules to be loaded based on the current layer's candidate results, rather than loading all tariff knowledge at once. This reduces the interference of irrelevant rules on the local student model. The system then determines whether the candidate results are credible. If they are not credible, it retains multiple candidate paths or supplements rules and returns to the reasoning stage. If they are credible, it constrains the next layer's candidate search space and determines whether the final encoding level has been reached. If not, it returns to the stage of determining the current reasoning layer and continues the progressive reasoning of the next layer. If the final encoding level has been reached, it records the complete classification evidence chain and outputs the final product code, completing the online classification process.

[0031] The offline rule iteration branch focuses on the continuous optimization of classification capabilities. It first collects historical error samples, locates the first error level by comparing the model's predicted path with the standard correct path, and submits the error information to the upstream strong teacher model to analyze the defects of existing rules. The upstream strong teacher model generates candidate rule patch drafts. The drafts first undergo rule format legality verification and are then stored in the draft rule version area of ​​the rule library. Subsequently, local backtesting verification is carried out. The backtesting process simultaneously covers three types of verification scenarios: target error test, easily confused sample test, and historical correct sample regression test. After the test is completed, it is determined whether the new rule simultaneously meets the improvement conditions and non-degenerate conditions. If both are met, the draft rule is published as a formal rule and integrated into the online classification main process. If not, the draft rule is retained and returned to the upstream stage for further optimization, thus forming a complete closed loop of offline rule iteration.

[0032] The specific logic for the formation and generation of progressive rule contexts is as follows: Figure 3As shown, the commodity classification query, serving as the input foundation for the entire classification reasoning, includes three core commodity information categories: commodity name, specification description, and declaration elements. This information, once input into the system, forms the current classification status, specifically encompassing three status information items: the current reasoning level, the upper-level candidate path, and the current-level candidate knowledge nodes. Based on the current classification status, the system connects to a hierarchical classification knowledge base. This knowledge base is divided into categories, chapters, items, sub-items, and final tariff codes according to the hierarchical structure of the commodity coding system. The system only locates the corresponding hierarchical range and candidate node range in the knowledge base based on the current reasoning level and the determined upper-level candidate path, extracting the corresponding rule content to generate the current-level progressive rule context. This context specifically includes five types of rule content: inclusion rules, exclusion rules, easily confused discrimination conditions, lower-level candidate guidance, and structured output constraints. Only the current classification level is disclosed throughout the entire process. The system selects rules for class determination but does not load irrelevant rules from other levels or paths, thereby reducing information redundancy in model reasoning and minimizing interference from irrelevant rules. Under this mechanism, the locally executed student model synchronously records the product classification query representation, candidate nodes at each level, actual called rules, rule versions, candidate scores, selected nodes, classification basis, and complete classification paths during the layer-by-layer classification process, forming a complete classification evidence chain. By associating the manual review results, historical correct codes, or other credible labels with the classification evidence chain, misclassified samples can be identified. The system further compares the predicted path of the misclassified sample with the correct path layer by layer to determine the target error level at which the two paths first diverge, and extracts the corresponding product attributes, correct nodes, error nodes, candidate scores, and rule summaries for that level, providing accurate positioning basis for subsequent rule optimization iterations.

[0033] The overall structure of the chain of evidence is as follows: Figure 4As shown, the entire chain of evidence begins with the classification task record. This record contains basic task information such as task identifier, original product information, product classification query representation, student model version, and classification time. It then sequentially connects to the first-level reasoning record, the second-level reasoning record, the third-level reasoning record, and finally the encoding layer record. Each level of reasoning record fully records the current level, the path to the previous level, candidate nodes, rule version, candidate score, selected node, and classification basis, completely reconstructing the reasoning process and decision-making basis at each level. All levels of reasoning records are ultimately summarized to form the classification result summary, which is then stored. The entire classification path, final product code, and manual review results are linked and mapped at each level of the evidence chain to the task record through task identifiers and rule version identifiers. This supports subsequent error localization, classification result interpretation, and rule version tracing. Based on this structured classification evidence chain, the system can extract corresponding information according to the target error level to form an error diagnosis package. The error diagnosis package includes structured or anonymized product attributes, predicted path, correct path, initial fork level, correct and incorrect nodes, candidate scores, current rule summary, triggering error identifier, and related failure samples. This allows the system to provide... The upstream strong teacher model provides complete evidence needed to complete the diagnosis, while avoiding the need to send complete original product files, all historical samples, and the complete knowledge base to external model services, thus ensuring the security of core business data. The upstream strong teacher model can be deployed on local high-performance servers, enterprise private clouds, or controlled private networks, and can also call online strong model services through securely managed interfaces. Its parameter scale, inference ability, and context window length are all higher than those of the locally executed student model, making it suitable for comprehensive and in-depth analysis of multiple misclassified samples, classification evidence chains, and related rules. This model does not directly handle daily product classification business, nor does it possess... It has the authority to directly modify the official rules, and only outputs candidate rule patch drafts as rule optimization suggestions. The candidate rule patch drafts specifically include rule defect types, target knowledge nodes, inclusion and exclusion conditions that need to be added or modified, product attribute judgment priority, easily confused candidate judgment conditions, rule application scope, trigger error information, and draft version number. The rule drafts output by the teacher model first undergo syntax, field completeness, target node existence, version conflict, and hierarchical relationship legality checks. Only after passing all legality checks can they be written into the draft rule version area and enter the subsequent local backtesting verification stage.

[0034] like Figure 5As shown, this embodiment demonstrates the complete process of comparing predicted and correct paths, locating the first fork level, analyzing differences in product attributes and candidate nodes, checking existing rules, and generating candidate rule patch drafts by the teacher model. First, the predicted classification path output by the local student model is compared layer by layer with the manually confirmed / historically correct classification path. Both paths sequentially cover five levels: category level (L1), chapter level (L2), item level (L3), sub-item level (L4), and final tariff code level (L5). Through layer-by-layer matching, the location where the two paths first fork is located, i.e., the target error level. Then, a process is initiated for this target error level... The diagnostic analysis is conducted from multiple dimensions, specifically including five aspects: comparison of product attributes, comparison of candidate nodes, comparison of candidate scores, actual rule checking, and analysis of differences between correct and incorrect nodes. This comprehensively identifies the causes of errors and deficiencies in existing rules. After completing the diagnostic analysis, the error evidence chain and corresponding rule knowledge are input into an upstream strong teacher model with stronger reasoning and longer contextual capabilities. The upstream strong teacher model then diagnoses rule deficiencies based on the error evidence chain and rule knowledge and generates a rule draft. Finally, the upstream strong teacher model outputs a candidate rule patch draft, which covers the type of rule defect, target knowledge nodes, candidate rule patch content, and the scope of rule application. The system triggers error information and draft version numbers. The entire mechanism follows the principle of separation of responsibilities: the upstream strong teacher model is responsible for diagnosis and rule draft generation, while the local student model only executes the official rules and does not directly modify them. This ensures the stability of online classification operations and the controllability of rule changes. In the implementation phase after rule draft generation, the system employs a mechanism that isolates the draft rule version from the official rule version. Online operations always read the official rule version for daily product classification, while in the local isolated backtesting environment, the same locally executed student model is used, loading both the official and draft rule versions separately to test target error samples and target knowledge. The nodes and their related samples, as well as historically correctly classified samples, are subjected to comparative backtesting. Backtesting metrics may include the target error correction rate, target level accuracy or recall rate, final overall coding accuracy, non-target level performance degradation, and the number of newly added serious errors. Only when the draft rule version meets the target performance improvement conditions and the overall performance and non-target sample performance do not degrade beyond the threshold will the rule publishing module publish the candidate rule patch as the official rule version; otherwise, the draft version and failed samples are retained, and the backtesting results are fed back to the upstream strong teacher model for continued iterative optimization, forming a closed-loop rule optimization chain.

[0035] like Figure 6 As shown in the example, this embodiment demonstrates the complete decision-making process for candidate rule patch format validity verification, draft rule version isolated storage, multi-dimensional backtesting verification, quantitative comparison of indicators, and formal rule release or return to the teacher model for further optimization.

[0036] After the candidate rule patch draft is generated, it first enters the rule format legality judgment stage. If it is determined to be invalid, it is directly rejected from being written and returned to the teacher model for modification. If it is determined to be valid, it is written to the draft rule version area for isolated storage, and then enters the local isolated backtesting verification stage. This stage simultaneously carries out three types of verification tests: target error test, local regression test of easily confused samples, and global regression test of historical correct samples. After the three types of tests are completed, a unified index comparison and analysis is carried out, specifically considering five core indicators: target error repair rate, target level accuracy, overall accuracy, non-target level degradation magnitude, and number of newly added serious errors. After the index analysis is completed, the core decision judgment node is entered to determine whether the rule patch simultaneously meets the performance improvement conditions and non-degradation conditions. If the conditions are met, the rule patch is released as the official rule version, the hierarchical classification knowledge base is updated simultaneously for local student model calls, and this rule change is written to the rule evolution log for traceability. If the conditions are not met, the draft version is retained, the failed samples and reasons for failure are recorded, and the system returns to the teacher model to continue optimizing the rule patch. The entire process only involves the official version. The official rule version can be called online by the local student model. Draft rules are always isolated and do not intervene in online business. At the same time, this embodiment ensures the compliance and controllability of the entire system through clear model permission division and data security mechanism. The local execution student model only has the permission to read the official rule, the permission to classify and reason, and the permission to write the evidence chain, but does not have the permission to modify the official rule. The upstream strong teacher model only receives the error diagnosis package required to complete the rule diagnosis and outputs the candidate rule patch draft, and does not directly write it into the official rule version area. The release of the official rule is jointly controlled by the local isolated backtesting module and the rule release module. Through the above permission separation, it can prevent any model from bypassing the verification process and directly modifying the online rule. In the implementation of calling the external online strong model, the system can use field desensitization, product number replacement, original text summarization, knowledge rule fragmentation, transmission encryption, interface authentication and operation auditing to control the data out-of-domain scope. The complete product file, full backtesting data, complete hierarchical knowledge base and official rule version are all kept in the local execution environment. Core business data does not flow out of the local trusted domain at all.

[0037] For example, in order to further verify the effectiveness of the commodity code classification and rule closed-loop optimization method provided in this embodiment, the method was actually implemented, and the specific implementation process is as follows: Step 1: Overall System Deployment and Model Division of Labor In this embodiment, the intelligent commodity coding classification system is deployed on an internal enterprise server and connected to the commodity file system, customs declaration system, and historical classification database. The local server deploys a commodity information processing service, a hierarchical classification knowledge base, a locally executed student model, a classification evidence chain database, a formal rule version area, a draft rule version area, a local backtesting dataset, and a rule publishing module. The upstream strong teacher model can be deployed in the enterprise's private cloud or a controlled online model service, receiving locally generated error diagnosis packages through a secure interface.

[0038] The local student model uses a small-parameter language model to read product names, specifications, and declaration elements, execute formal rules, and complete hierarchical classification. The upstream strong teacher model uses a model with stronger reasoning capabilities and a longer context window to compare incorrect and correct paths, comprehensively analyze multiple error examples, candidate scores, and rule content, and generate draft candidate rule patches. Neither type of model can directly modify formal rules; candidate rules must be verified through local backtesting before being written into the formal rule version area by the rule publishing module.

[0039] Step 2: Hierarchical Knowledge Base Classification and Progressive Rule Scheduling: In this embodiment, the hierarchical classification knowledge base is organized according to categories, chapters, items, sub-items, and final tariff codes. Each knowledge node includes a node code, node name, its level, parent node, set of subordinate nodes, inclusion rules, exclusion rules, easily confused nodes, discrimination conditions, subordinate candidate guidelines, rule application scope, and rule version.

[0040] When the system performs category-level classification, it only loads category-level candidate nodes and category-level judgment rules; after the category-level result is determined, it only loads chapter-level candidate nodes and chapter-level rules under the selected category; subsequent item-level, sub-item-level, and final tariff code-level classifications are scheduled layer by layer in the same way. The system does not load all lower-level tariff code rules during the first-level inference, thereby reducing the context length of the local student model and reducing interference from irrelevant rules.

[0041] Step 3: Product Information Processing and Local Student Model Classification: The product to be categorized is named "Strengthening Shampoo," with a specification description of "80mL, for cleaning hair and scalp, and with hair conditioning function, retail packaging." The system performs text cleaning and attribute extraction on the product information, obtaining the following details: product type: shampoo; main use: human hair and scalp cleaning; additional use: hair conditioning; packaging status: retail packaging; specification: 80mL. The system then uses this information to create a product categorization query representation.

[0042] Step 4: Categorize the chain of evidence and locate the error level: For each classification task, the system generates a unique task identifier and records the candidate nodes, candidate scores, actual called rules, rule versions, selected nodes, and classification basis at each level. When manual review finds that the predicted path for a certain product is "Category 6 → Chapter 34 → 3402 → other lower-level codes", while the correct path is "Category 6 → Chapter 33 → 3305 → 330510 → corresponding final tariff number", the system compares the two paths layer by layer to determine that the two branches for the first time at the chapter level.

[0043] The system extracts the target user, main purpose, predicted node, candidate score for Chapter 34, correct node for Chapter 33, current rule content, and trigger error identifier from the chapter-level evidence chain to form target error level diagnostic information. Multiple error samples of the same type can be aggregated according to the same correct node, error node, or defect pattern, so that the upstream strong teacher model can perform comprehensive analysis in a longer context.

[0044] Step 5: Generation of Error Diagnosis Package and Upstream Strong Teacher Model Rules: The local system aggregates error samples into an error diagnosis package. This package retains structured product attributes, predicted paths, correct paths, initial fork level, candidate scores, rule summaries, and trigger error numbers. For scenarios requiring the invocation of external online strong models, the system replaces the enterprise product number with an internal substitute number and removes supplier names, customer information, and other non-diagnostic fields.

[0045] The upstream strong teacher model analysis revealed that existing rules overemphasize the "cleaning" attribute and fail to clearly define the priority relationship between personal hygiene products and general detergents. Therefore, a draft candidate rule patch was generated: For preparations directly used for cleaning human hair or scalp and possessing conditioning or conditioning properties, Chapter 33 should be prioritized based on the hygiene product attribute; products should not be directly classified into Chapter 34 solely because they have a cleaning effect or contain surfactants; the priority of determining the user and primary purpose is higher than general cleaning function. This rule patch is associated with the knowledge nodes of Chapters 33 and 34 and their corresponding easily confused relationships.

[0046] Step Six: Candidate Rule Patch Format Verification and Version Isolation: Before a candidate rule patch draft is written to the draft rule version area, the system checks whether the target knowledge node exists, whether the rule fields are complete, whether the parent-child hierarchy is valid, whether the rule's scope of application is clear, and whether there are version number conflicts. After passing these checks, the system generates a draft version number and isolates the draft rule from the current official rule. Online classification services continue to read the official rule and are unaffected by the draft rule.

[0047] Step 7: Local Backtesting Verification and Official Release The local isolated backtesting dataset includes erroneous shampoo samples that triggered the patch, samples of other shampoos and hair care products, samples of general industrial detergents, samples of surfactant formulations, historical samples that could be correctly classified by the original official rules, and regression samples from other sections. The system uses both the official rule version and the draft rule version to call the same locally executed student model to complete the entire classification process.

[0048] If the draft rules bring the target error correction rate and the accuracy of easily confused samples in Chapters 33 and 34 to the preset improvement threshold, while the overall accuracy does not decrease, the decrease in accuracy of non-target chapters does not exceed the allowed threshold, and no new hierarchical path errors are added, then the system will release the draft rules as the official rule version, update the hierarchical classification knowledge base, and write it to the rule evolution log. Subsequent local execution of the student model will automatically call the updated official rules during classification.

[0049] Step 8: Rules that fail backtesting continue to iterate: When a candidate rule can correct a target error but causes significant degradation in other historically correct samples, the system does not publish the rule, retains the draft version, and records the failed samples, failure level, and performance changes. The backtesting results are used to reconstruct diagnostic information and fed back to the upstream strong teacher model. The teacher model narrows the rule's applicability based on the failed samples, adds exclusion conditions, or adjusts product attributes to determine priority, generates a new draft version, and re-enters the local backtesting process.

[0050] Step 9: Perform data security processing on the controlled online teacher model: When the upstream strong teacher model uses the online strong model service, the local system does not directly upload all the original product data and the complete knowledge base. Instead, it extracts the necessary diagnostic fields based on the initial error level. The transmitted content uses an encrypted channel, and the call time, data fields, model version, and return results are recorded through interface authentication and operation logs. The rule drafts returned by the teacher model do not automatically take effect; format checks, target error testing, local regression testing, and global regression testing must still be performed locally.

[0051] As can be seen, the method provided in this embodiment can be applied to scenarios such as customs commodity classification, import and export declaration assistance, cross-border e-commerce commodity code generation, tariff calculation, trade compliance review, enterprise commodity file management, historical declaration review, and commodity classification rule maintenance. Its local execution student model is suitable for high-frequency processing of commodity data within an enterprise intranet, while the upstream strong teacher model is suitable for comprehensive analysis of multiple error cases and complex rules during the centralized optimization phase. The local isolation backtesting mechanism can verify the optimization effect before rule release. Furthermore, this method can also be transferred to medical diagnostic coding, industrial product classification, financial subject classification, legal provision indexing, standard specification matching, and other classification tasks with hierarchical labels and professional rule constraints.

[0052] For example, such as Figure 7 As shown, this embodiment provides a product coding classification and rule closed-loop optimization method, including: The system receives product information for products to be categorized in the local execution environment, performs preprocessing on the product information, including text cleaning, attribute extraction, and terminology standardization, and generates a product categorization query representation. Based on the hierarchical relationship of product codes in the local hierarchical classification knowledge base, the current reasoning layer and the determined upper-level candidate paths, a set of candidate knowledge nodes for the current layer is generated, and corresponding association rules are scheduled to construct the progressive rule context for the current layer. The product classification query representation and the current layer progressive rule context are input into the local execution student model, the selected node is output, and the candidate search space of the next layer is constrained according to the selected node. The reasoning is carried out layer by layer until the final product code is obtained. Record all nodes, calling rules, scores, and complete paths for this classification to form a classification evidence chain and rule evolution log, and identify misclassified samples based on manual review results or known correct codes; By comparing the predicted classification path of the erroneous sample with the correct classification path, the target error level of the first bifurcation is located, and the corresponding level association information is extracted to generate an error case diagnosis package. Input the error diagnosis package into the upstream strong teacher model, analyze the rule defects of the target error level, and generate candidate rule patch drafts associated with the target knowledge nodes; Perform a format validity check on the candidate rule patch draft, and write it into the draft rule version area, which is isolated from the official rule version, once the check passes. In the local isolated backtesting environment, the official rule version and the draft rule version are loaded respectively, and the local student model is called to perform a comparative backtest to obtain the backtesting performance indicators. If the backtest performance metrics meet the preset conditions, the candidate rule patch will be released as the official rule version and the local hierarchical classification knowledge base will be updated; otherwise, the backtest results will be fed back for further optimization.

[0053] For example, such as Figure 8 As shown, this embodiment also provides a commodity coding classification and rule closed-loop optimization system, including: a receiving module, used to receive commodity information of commodities to be classified in a local execution environment, preprocess the commodity information, and generate a commodity classification query representation; The construction module is used to generate a set of candidate knowledge nodes for the current layer based on the hierarchical relationship of product codes in the local hierarchical classification knowledge base, the current inference layer and the determined upper-layer candidate paths, and to schedule the corresponding association rules to construct the progressive rule context for the current layer. The reasoning module is used to input the product classification query representation and the current layer's progressive rule context into the local execution student model, output the selected node, constrain the next layer's candidate search space based on the selected node, and reason layer by layer until the final product code is obtained; The recording module is used to record all nodes, calling rules, scores and complete paths for this classification, forming a classification evidence chain and rule evolution log, and identifying misclassified samples based on manual review results or known correct codes. The comparison module is used to compare the predicted classification path of erroneous samples with the correct classification path, locate the target error level of the first bifurcation, extract the corresponding level association information, and generate an error diagnosis package. The analysis module is used to input the error diagnosis package into the upstream strong teacher model, analyze the rule defects of the target error level, and generate candidate rule patch drafts associated with the target knowledge nodes. The verification module is used to perform format validity checks on the candidate rule patch drafts. Once the checks are passed, the draft rule version is written to the draft rule version area, which is isolated from the official rule version. The backtesting module is used to load the official rule version and the draft rule version in a local isolated backtesting environment, call the local execution student model to perform a comparative backtest, and obtain backtesting performance indicators. The decision module is used to release the candidate rule patch as the official rule version and update the local hierarchical classification knowledge base if the backtest performance indicators meet the preset conditions; otherwise, it will provide feedback on the backtest results for further optimization.

[0054] The present invention also provides a commodity coding classification and rule closed-loop optimization device, comprising: a memory for storing a computer program; and a processor for executing the computer program to implement the steps of the commodity coding classification and rule closed-loop optimization method.

[0055] The present invention also provides a computer program product, including a computer program / instruction, which, when executed by a processor, implements the steps of the commodity coding classification and rule closed-loop optimization method.

[0056] When the processor executes the computer program, it implements the above-mentioned steps of commodity coding classification and rule closed-loop optimization, for example: receiving commodity information of the commodity to be classified in the local execution environment, preprocessing the commodity information, and generating a commodity classification query representation; Based on the hierarchical relationship of product codes in the local hierarchical classification knowledge base, the current reasoning layer and the determined upper-level candidate paths, a set of candidate knowledge nodes for the current layer is generated, and corresponding association rules are scheduled to construct the progressive rule context for the current layer. The product classification query representation and the current layer progressive rule context are input into the local execution student model, the selected node is output, and the candidate search space of the next layer is constrained according to the selected node. The reasoning is carried out layer by layer until the final product code is obtained. Record all nodes, calling rules, scores, and complete paths for this classification to form a classification evidence chain and rule evolution log, and identify misclassified samples based on manual review results or known correct codes; By comparing the predicted classification path of the erroneous sample with the correct classification path, the target error level of the first bifurcation is located, and the corresponding level association information is extracted to generate an error case diagnosis package. Input the error diagnosis package into the upstream strong teacher model, analyze the rule defects of the target error level, and generate candidate rule patch drafts associated with the target knowledge nodes; Perform a format validity check on the candidate rule patch draft, and write it into the draft rule version area, which is isolated from the official rule version, once the check passes. In the local isolated backtesting environment, the official rule version and the draft rule version are loaded respectively, and the local student model is called to perform a comparative backtest to obtain the backtesting performance indicators. If the backtest performance metrics meet the preset conditions, the candidate rule patch will be released as the official rule version and the local hierarchical classification knowledge base will be updated; otherwise, the backtest results will be fed back for further optimization.

[0057] For example, the computer program can be divided into one or more modules / units, which are stored in the memory and executed by the processor to complete the present invention. The one or more modules / units can be a series of computer program instruction segments capable of performing preset functions, wherein the instruction segments describe the execution process of the computer program in the commodity coding classification and rule closed-loop optimization device. For example, the computer program can be divided into a receiving module, a building module, an inference module, a recording module, a comparison module, an analysis module, a verification module, a backtesting module, and a judgment module; the specific functions are as follows: The receiving module is used to receive the product information of the products to be classified in the local execution environment, preprocess the product information, and generate a product classification query representation; The building module is used to generate a set of candidate knowledge nodes for the current layer based on the hierarchical relationship of product codes in the local hierarchical classification knowledge base, the current inference layer, and the determined upper-layer candidate paths, and to schedule the corresponding association rules to construct the progressive rule context for the current layer; The inference module is used to input the product classification query representation and the progressive rule context for the current layer into the locally executed student model, output the selected node, constrain the next layer candidate search space according to the selected node, and infer layer by layer until the final product code is obtained; The recording module is used to record all nodes, called rules, scores, and complete paths of this classification, forming a classification evidence chain and a rule evolution log. The system is structured as follows: 1) Identify misclassified samples based on manual review results or known correct codes; 2) Compare the predicted and correct classification paths of misclassified samples to pinpoint the target error level of the first bifurcation and extract the corresponding level's association information to generate a misclassification diagnostic package; 3) Input the misclassification diagnostic package into the upstream strong teacher model to analyze rule defects at the target error level and generate candidate rule patch drafts associated with the target knowledge node; 4) Perform format validity checks on the candidate rule patch drafts, and write them to a draft rule version area isolated from the official rule version after passing the check; 5) Load the official rule version and draft rule version in a local isolated backtesting environment, call the local student model to perform a comparative backtest, and obtain backtesting performance indicators; 6) If the backtesting performance indicators meet preset conditions, publish the candidate rule patch as the official rule version and update the local hierarchical classification knowledge base; otherwise, provide feedback on the backtesting results for further optimization.

[0058] The commodity code classification and rule closed-loop optimization device can be a computing device such as a desktop computer, laptop, handheld computer, or cloud server. The commodity code classification and rule closed-loop optimization device may include, but is not limited to, processors and memory. Those skilled in the art will understand that the above are examples of commodity code classification and rule closed-loop optimization devices and do not constitute a limitation on such devices. The device may include more components than described above, or combine certain components, or use different components. For example, the commodity code classification and rule closed-loop optimization device may also include input / output devices, network access devices, buses, etc.

[0059] The processor referred to can be a Central Processing Unit (CPU), or other general-purpose processors, Digital Signal Processors (DSPs), Application Specific Integrated Circuits (ASICs), Field-Programmable Gate Arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor can be a microprocessor, or any conventional processor. The processor is the control center of the commodity coding classification and rule closed-loop optimization system, connecting various parts of the entire commodity coding classification and rule closed-loop optimization equipment through various interfaces and lines.

[0060] The memory can be used to store the computer program and / or modules. The processor implements various functions of the commodity coding classification and rule closed-loop optimization device by running or executing the computer program and / or modules stored in the memory and calling the data stored in the memory.

[0061] The memory may primarily include a program storage area and a data storage area. The program storage area may store the operating system and at least one application program required for a function (such as sound playback, image playback, etc.). The data storage area may store data created based on the use of the mobile phone (such as audio data, phonebook, etc.). Furthermore, the memory may include high-speed random access memory and non-volatile memory, such as hard disks, RAM, plug-in hard disks, smart media cards (SMC), secure digital cards (SD cards), flash cards, at least one disk storage device, flash memory device, or other volatile solid-state storage devices.

[0062] The present invention also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps of the commodity coding classification and rule closed-loop optimization method described above.

[0063] If the modules / units integrated by the commodity coding classification and rule closed-loop optimization system are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium.

[0064] Based on this understanding, the present invention can implement all or part of the processes in the above-mentioned commodity code classification and rule closed-loop optimization method, or it can be accomplished by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium. When executed by a processor, the computer program can implement the steps of the above-mentioned commodity code classification and rule closed-loop optimization method. The computer program includes computer program code, which can be in the form of source code, object code, executable file, or a preset intermediate form, etc.

[0065] The computer-readable storage medium may include: any entity or device capable of carrying the computer program code, recording media, USB flash drive, portable hard drive, magnetic disk, optical disk, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signal, telecommunication signal, and software distribution medium, etc.

[0066] It should be noted that the content contained in the computer-readable storage medium may be appropriately increased or decreased according to the requirements of legislation and patent practice in the jurisdiction. For example, in some jurisdictions, according to legislation and patent practice, the computer-readable storage medium does not include electrical carrier signals and telecommunication signals.

[0067] Compared with existing classification and optimization measures, this invention provides a commodity coding classification and rule closed-loop optimization method and system, which has the following advantages: First, this invention entrusts the daily high-frequency classification to a low-cost, low-latency local execution student model, while entrusting the complex error analysis and rule draft generation to an upstream strong teacher model with stronger reasoning ability and longer contextual ability, thus balancing online execution efficiency and rule optimization quality.

[0068] Secondly, this invention uses progressive rule context scheduling to enable the locally executed student model to receive only the rules required for the current classification judgment at each layer, thereby reducing context redundancy and judgment interference caused by irrelevant hierarchical rules and irrelevant path knowledge.

[0069] Third, by comparing the predicted path with the correct path and locating the first fork level, this invention transforms the final encoding error into a specific level, a specific candidate node, and a specific rule defect, thereby improving the pertinence of rule modification.

[0070] Fourth, in this invention, the upstream strong teacher model only generates candidate rule patch drafts and does not directly participate in the formal rule release; the candidate rules must undergo isolated backtesting with the local student model and local dataset, which can prevent the rules generated by the strong model from directly affecting online business without verification.

[0071] Fifth, this invention simultaneously sets performance improvement conditions and non-degradation conditions, which not only verifies whether the new rule can fix the target error, but also verifies whether it destroys easily confused samples and historically correct samples, thereby reducing the risk of rule updates introducing new errors.

[0072] Sixth, this invention records the evidence chain and rule evolution logs layer by layer, which can explain which rules were called at each layer, why a certain node was selected or excluded, and can reproduce and compare the old and new results after the rule version is updated.

[0073] Seventh, when using an external online strong model, this invention can transmit only the structured or de-identified error diagnosis package, while keeping the complete business data, full test data and complete knowledge base locally, thereby reducing the risk of leakage of highly sensitive trade data and professional knowledge.

[0074] The above embodiments are merely one of the implementation methods for achieving the technical solution of the present invention. The scope of protection claimed by the present invention is not limited to this embodiment, but also includes any variations, substitutions and other implementation methods that can be easily conceived by those skilled in the art within the scope of the technology disclosed in the present invention.

[0075] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and not to limit it. Although the present invention has been described in detail with reference to the above embodiments, those skilled in the art should understand that modifications or equivalent substitutions can still be made to the specific implementation of the present invention. Any modifications or equivalent substitutions that do not depart from the spirit and scope of the present invention should be covered within the protection scope of the present invention.

Claims

1. A commodity coding classification and rule closed-loop optimization method, characterized in that, include: The system receives product information of products to be categorized in the local execution environment, preprocesses the product information, and generates a product categorization query representation. Based on the hierarchical relationship of product codes in the local hierarchical classification knowledge base, the current reasoning layer and the determined upper-level candidate paths, a set of candidate knowledge nodes for the current layer is generated, and corresponding association rules are scheduled to construct the progressive rule context for the current layer. The product classification query representation and the current layer progressive rule context are input into the local execution student model, the selected node is output, and the candidate search space of the next layer is constrained according to the selected node. The reasoning is carried out layer by layer until the final product code is obtained. Record all nodes, calling rules, scores, and complete paths for this classification to form a classification evidence chain and rule evolution log, and identify misclassified samples based on manual review results or known correct codes; By comparing the predicted classification path of the erroneous sample with the correct classification path, the target error level of the first bifurcation is located, and the corresponding level association information is extracted to generate an error case diagnosis package. Input the error diagnosis package into the upstream strong teacher model, analyze the rule defects of the target error level, and generate candidate rule patch drafts associated with the target knowledge nodes; Perform a format validity check on the candidate rule patch draft, and write it into the draft rule version area, which is isolated from the official rule version, once the check passes. In the local isolated backtesting environment, the official rule version and the draft rule version are loaded respectively, and the local student model is called to perform a comparative backtest to obtain the backtesting performance indicators. If the backtest performance metrics meet the preset conditions, the candidate rule patch will be released as the official rule version and the local hierarchical classification knowledge base will be updated; otherwise, the backtest results will be fed back for further optimization.

2. The commodity coding classification and rule closed-loop optimization method according to claim 1, characterized in that, The product classification query representation includes standardized product text and a structured set of product attributes; the structured set of product attributes includes at least one of the following: product type, composition, material, function and purpose, working principle, processing method, specifications and model, packaging status, status of the whole machine or parts, and declaration elements; the progressive rule context is dynamically generated based on the current inference layer, the upper-level candidate path, and the current-level candidate knowledge node.

3. The commodity coding classification and rule closed-loop optimization method according to claim 1, characterized in that, The locally executed student model is at least one of the following: a small-parameter language model, a text classification model, a retrieval-enhanced generation model, and a rule-injection-based language model, deployed on an enterprise server, edge computing device, enterprise private cloud, or business terminal; the locally executed student model performs product classification according to the official rule version.

4. The commodity coding classification and rule closed-loop optimization method according to claim 1, characterized in that, The error diagnosis package includes at least the product attributes that have been structured or de-identified, the predicted classification path, the correct classification path, the first fork level, the correct node and the incorrect node, the corresponding candidate score, the current formal rule summary, and the triggering error identifier; When the upstream strong teacher model is provided by an external online model service, the complete original product profile, full historical dataset, and complete hierarchical classification knowledge base are not sent to the external online model service.

5. The commodity coding classification and rule closed-loop optimization method according to claim 1, characterized in that, The upstream strong teacher model is a language model whose parameter size, reasoning ability, or context window length is greater than that of the locally executed student model. The upstream strong teacher model identifies at least one rule defect based on the error diagnosis package and rule knowledge related to the target error level, including: key product attributes not covered by rules, improper attribute judgment priority settings, conflict between inclusion and exclusion rules, insufficient judgment conditions for easily confused nodes, insufficient upper-level routing prompts, or incomplete lower-level candidate guidance. It then outputs the rule defect type, target knowledge node, candidate rule patch content, rule applicable scope, triggering error information, and draft version number.

6. The commodity coding classification and rule closed-loop optimization method according to claim 1, characterized in that, The comparative backtesting includes target error test performed on the target error sample that triggers the candidate rule patch, local regression test performed on the target knowledge node and its easily confused knowledge node, and global regression test performed on the historical correctly classified sample. The preset conditions include performance improvement conditions and non-degradation conditions; The performance improvement conditions include the target error sample repair rate or the target level accuracy reaching a preset improvement threshold. The non-degradation conditions include overall classification performance not falling below a preset threshold, non-target level performance degradation not exceeding a preset degradation threshold, and no new serious level path errors.

7. The commodity coding classification and rule closed-loop optimization method according to claim 1, characterized in that, The classification evidence chain and the rule evolution log are associated with each other through the classification task identifier, knowledge node identifier, and rule version identifier, respectively. The classification evidence chain records at least the product classification query representation, candidate nodes at each level, actual call rules, rule version, candidate score, selected node, classification basis, and complete classification path; the rule evolution log records at least the candidate rule patch, target knowledge node, triggered error, backtest data range, backtest indicators, release conclusion, and release time.

8. A commodity coding classification and rule closed-loop optimization system, characterized in that, include: The receiving module is used to receive product information of products to be classified in the local execution environment, preprocess the product information, and generate a product classification query representation; The construction module is used to generate a set of candidate knowledge nodes for the current layer based on the hierarchical relationship of product codes in the local hierarchical classification knowledge base, the current inference layer and the determined upper-layer candidate paths, and to schedule the corresponding association rules to construct the progressive rule context for the current layer. The reasoning module is used to input the product classification query representation and the current layer's progressive rule context into the local execution student model, output the selected node, constrain the next layer's candidate search space based on the selected node, and reason layer by layer until the final product code is obtained; The recording module is used to record all nodes, calling rules, scores and complete paths for this classification, forming a classification evidence chain and rule evolution log, and identifying misclassified samples based on manual review results or known correct codes. The comparison module is used to compare the predicted classification path of erroneous samples with the correct classification path, locate the target error level of the first bifurcation, extract the corresponding level association information, and generate an error diagnosis package. The analysis module is used to input the error diagnosis package into the upstream strong teacher model, analyze the rule defects of the target error level, and generate candidate rule patch drafts associated with the target knowledge nodes. The verification module is used to perform format legality checks on the candidate rule patch drafts. Once the checks are passed, the draft rule version is written to the draft rule version area, which is isolated from the official rule version. The backtesting module is used to load the official rule version and the draft rule version in a local isolated backtesting environment, call the local execution student model to perform a comparative backtest, and obtain backtesting performance indicators. The decision module is used to release the candidate rule patch as the official rule version and update the local hierarchical classification knowledge base if the backtest performance indicators meet the preset conditions; otherwise, it will provide feedback on the backtest results for further optimization.

9. A commodity coding classification and rule closed-loop optimization device, characterized in that, include: Memory, used to store computer programs; A processor, configured to implement the commodity coding classification and rule closed-loop optimization method according to any one of claims 1-7 when executing the computer program.

10. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by the processor, it is used to implement the commodity coding classification and rule closed-loop optimization method according to any one of claims 1-7.

Images