Intelligent document coding system and method based on rule driving

Abstract

The invention discloses an intelligent document coding system and method based on rule driving, and belongs to the technical field of intelligent document processing. According to the system, a three-level DCC coding rule tree (A1 technical field-> A2 main class-> A3 subclass) fusing international standards, national standards and enterprise self-defined requirements is constructed; a two-stage analysis mechanism is adopted, wherein file name information is extracted in a structured mode, and RAG enhanced content analysis is started when the confidence coefficient is lower than 0.8; generating an initial code through the Qwen-72B large model in combination with the structured Prompt, executing format verification, and outputting a compliant code; constructing a hierarchical classification tree based on a coding result and performing multi-dimensional statistics; meanwhile, the matching degree of a file name and a code is calculated, a case lower than 0.6 is marked as a nonstandard case, and a naming template is dynamically generated by utilizing a high-matching case, so that closed-loop iterative optimization of naming specifications is realized. According to the method, coding standardization, automation and traceability are improved.

Description

Technical Field

[0001] This invention belongs to the field of intelligent document encoding, and specifically relates to a rule-driven intelligent document encoding system and method. Background Technology

[0002] Two similar patents were found on the platform using the keywords "document encoding" and "artificial intelligence," with the relevant numbers "CN120067055A Document Retrieval Method and Apparatus, Electronic Device and Storage Medium" and "CN120449823A A General Qualitative Analysis Encoding System Based on LLM." The main technologies of these two patents are as follows: 1. Patent CN120067055A, "Document Retrieval Method, Device, Electronic Equipment, and Storage Medium," focuses on improving the accuracy of financial text retrieval, proposing a document retrieval method and related device that integrates semantic and structural information. Addressing the pain points of long financial documents, complex directory structures, and high semantic similarity, the method extracts key features through multi-dimensional document embedding technology: first, the sample document is segmented into word sequences, paragraphs are divided into paragraph sequences, and the directory structure is extracted; then, word vectors (combining word semantics and positional information), directory tree position vectors (reflecting paragraph hierarchical relationships), and directory index vectors (generated by an encoder) are concatenated to form comprehensive document embedding features. Based on this, a document encoding model is trained using a masked language model (MLM) mechanism. The model parameters are optimized by predicting and restoring the masked features, enabling it to deeply explore the potential correlation between document semantics and structure. In the retrieval stage, the target retrieval expression is transformed into target encoded features through the same embedding and encoding process, and similarity matching is performed with candidate codes in a preset document database to ultimately select accurate target documents. This technology effectively solves the problem of insufficient accuracy of traditional semantic retrieval in complex financial scenarios by integrating text content and structural information.

[0003] The patent "CN120449823A A General Qualitative Analysis Coding System Based on LLM" constructs a general qualitative analysis coding system based on Large Language Model (LLM), aiming to automate, standardize, and improve the coding process in qualitative research. The system's core comprises five modules: an intelligent coding book generation module supports LLM-assisted initial framework construction and flexibly adapts to research needs through human-computer collaborative iterative optimization; a dynamic prompting engineering and preprocessing module optimizes LLM input through character encoding adaptation, intelligent truncation of long texts (preserving key information at the beginning and end), and targeted prompt word construction (clarifying roles, formats, and question batches); a batch document coding module achieves efficient processing of large-scale documents through logical grouping, fault tolerance mechanisms, and main control process coordination; an LLM response parsing and consistency assurance module transforms free text responses into structured data using pattern matching, multiple alternative parsing rules, and standardized output formats, ensuring cross-document consistency through unified instructions, format specifications, and centralized storage; and a structured results module exports Excel / CSV files according to the coding book definition for subsequent analysis. This system solves the problems of low efficiency, strong subjectivity, and difficulty in reusing results in traditional qualitative analysis by using deep semantic understanding and process automation of LLM. It is suitable for text coding scenarios in multiple fields such as academic research and market research.

[0004] A comparison of the above patents reveals the following: The technology described in "CN120067055A Document Retrieval Method, Device, Electronic Equipment and Storage Medium," while improving the accuracy of financial document retrieval by integrating semantic and structural information, has significant limitations: First, its scenario adaptability is limited, as it is designed primarily for financial documents and does not consider the technical classification characteristics of documents in fields such as engineering and manufacturing (e.g., hierarchical associations between technical fields and main document categories), making it difficult to migrate to general document coding scenarios. Second, it lacks standardized coding rule constraints; document embedding features only serve retrieval matching and do not form a reusable coding system, failing to support management needs such as document classification statistics and process optimization. Third, the utilization of structural information is limited to the directory level and does not relate to the business logic of document content (e.g., "technical specifications" corresponding to specific document types), resulting in insufficient deep semantic association mining of documents in professional fields.

[0005] The system described in "CN120449823A A General Qualitative Analysis Coding System Based on LLM" improves the efficiency of qualitative analysis through LLM, but it suffers from several problems, including a lack of rule constraints and insufficient scenario adaptability. Firstly, the coding framework relies on manual iterative optimization and lacks integration with international / national standards (such as IEC61355), making it difficult to meet the standardization requirements of enterprise-level document coding. Secondly, the fixed truncation strategy used for long text processing easily leads to the loss of key hierarchical information in technical documents (such as the association between the A1 technical field and the A2 main category), affecting coding accuracy. Thirdly, it lacks a closed-loop optimization mechanism for coding and document naming, making it unable to improve automated coding efficiency through naming conventions and exhibiting weak adaptability to batch processing of large-scale technical documents.

[0006] In summary, the main technical problem addressed by this invention is that existing intelligent document coding methods lack a structured rule system that integrates with international / national standards, over-reliance on large language models leads to highly subjective coding results, non-compliant formats and logic, and the inability to continuously optimize naming conventions through feedback mechanisms between document naming and coding results makes it difficult to meet enterprises' needs for highly accurate, standardized, and traceable document coding management. Summary of the Invention

[0007] The technical problem to be solved by the present invention is to provide a rule-driven intelligent document coding system and method. Through the whole process design of "rule-driven + intelligent enhancement + closed-loop optimization", it makes up for the shortcomings of the existing technology in terms of standardization, adaptability and efficiency.

[0008] To solve the above-mentioned technical problems, the technical solution adopted by the present invention is as follows: A rule-driven intelligent document coding system and method, comprising a rule construction module for constructing a multi-level DCC coding rule tree that integrates international standards, national standards and enterprise-defined requirements, wherein the rule tree includes A1 nodes, A2 nodes and A3 nodes; The document parsing module is used to receive an input document containing a file name and file content, and extract key encoded information through a two-level parsing mechanism. The two-level parsing mechanism includes: performing structured extraction on the file name to generate a first parsing result; if the confidence of the first parsing result is lower than 0.8, then starting RAG enhanced content parsing, vectorizing the file content, and searching the rule tree keyword library to generate a second parsing result. The intelligent encoding module is used to take the DCC encoding rule tree and the encoding key information as input, generate the initial DCC encoding through the large language model, perform format verification and logical verification, and output the final DCC encoding that passes the verification. The classification and statistics module is used to construct a hierarchical classification tree based on the final DCC code and perform multi-dimensional quantitative statistics. The standardization optimization module is used to calculate the matching degree between the file name and the final DCC code, mark files with a matching degree lower than 0.6 as non-standard naming cases, and generate naming templates containing technical field keywords, main category keywords, subcategory keywords and supplementary information based on high matching degree cases to iteratively optimize the document naming standard.

[0009] Preferably, the A1 node is a technical field node, and its values ​​include technical field codes derived from international standards, technical field extension codes derived from national standards, and enterprise-defined technical field codes; the A2 node is a mandatory set consisting of 12 standard main classes; the A3 node includes standard subclasses associated with the A2 node and enterprise-defined subclasses added under the standard spare range or Z class; all enterprise-defined codes have their change history managed through a version control mechanism.

[0010] Preferably, when performing RAG enhanced content parsing, the document parsing module converts the file content into text, vectorizes it using a pre-trained language model, and performs similarity retrieval in the rule tree keyword vector library to extract core fields.

[0011] Preferably, the intelligent encoding module adopts the Qwen-72B large language model and drives inference through a structured Prompt that includes rule tree hierarchy descriptions, parsing information mapping logic, and output format constraints, generating a formatted output that includes encoding results, inference links, and confidence levels.

[0012] Preferably, the format verification is used to check whether the DCC code consists of 3 uppercase letters and excludes the characters O and I; the logic verification is used to verify whether node A2 belongs to the mandatory set, whether node A3 is associated with node A2, and whether the enterprise custom code complies with version control compliance.

[0013] Preferably, the first-level branches of the hierarchical classification tree are grouped according to A1 nodes, the second-level branches are grouped according to A2 nodes and belong to the corresponding A1 nodes, the third-level branches are grouped according to A3 nodes and belong to the corresponding A2 nodes, and the leaf nodes are the documents belonging to the code; the multi-dimensional quantitative statistics include the number of documents under A1 nodes, the number of documents under the combination of A1 nodes and A2 nodes, and the number of documents under the complete DCC code.

[0014] Preferably, the naming template is dynamically generated by analyzing high-matching cases and is used to guide the iterative optimization of file naming conventions.

[0015] A document intelligent encoding method based on a rule-driven document intelligent encoding system includes the following steps: S1. Construct a multi-level DCC coding rule tree. The rule tree integrates international standards, national standards and enterprise-defined requirements. Its hierarchical structure includes A1 nodes for representing technical fields, A2 nodes for representing the main class of the file and A3 nodes for representing subclasses. The value of A2 node belongs to a preset set of mandatory main classes, and the value of A3 node has a mandatory association relationship with A2 node. S2. Perform two-level parsing on the input document: First, extract the file name in a structured manner to obtain the first parsing result and its confidence level; if the confidence level is lower than 0.8, start RAG enhanced content parsing, vectorize the file content and search the rule tree keyword library to generate the second parsing result; S3. Using the DCC encoding rule tree and the encoding basis set composed of the first parsing result and the second parsing result as input, generate an initial DCC encoding through a large language model, and perform format verification and logical verification, outputting the final DCC encoding that passes the verification; the format verification is used to verify whether the initial DCC encoding consists of three uppercase letters and does not contain the characters O and I, and the logical verification is used to verify whether the value of node A2 belongs to the mandatory main class set and whether the value of node A3 has a legal relationship with the value of node A2; S4. Based on the final DCC code, aggregate documents according to the hierarchical affiliation of A1 node, A2 node and A3 node, construct a hierarchical classification tree, and perform multi-dimensional quantitative statistics. The multi-dimensional quantitative statistics include: counting the number of documents belonging to the same A1 node, the number of documents belonging to the same combination of A1 node and A2 node, and the number of documents with the same complete DCC code. S5. Calculate the matching degree between the file name and the final DCC code. The matching degree is the ratio of the number of identifiable encoded fields in the file name to the total number of valid DCC codes. Files with a matching degree lower than 0.6 are marked as non-standard naming cases. Based on high matching cases with a matching degree of not less than 0.8, generate a naming template containing technical field keywords, main category keywords, subcategory keywords and supplementary information to iteratively optimize the document naming standard.

[0016] Preferably, in step S1, the value of node A1 includes technical field codes derived from international standards, technical field extension codes derived from national standards, and enterprise-defined technical field codes; the value of node A3 includes standard subclass codes corresponding to node A2 and enterprise-defined subclass codes defined in a preset spare range or a subclass range ending with Z; all enterprise-defined codes are associated with attribute information and managed through a version control mechanism.

[0017] Preferably, in step S2, the format of the input document includes Excel, Word, PDF, or TXT; for scanned PDF documents, they are first converted into text by optical character recognition before content parsing.

[0018] Preferably, in step S3, the large language model is Qwen-72B, and its reasoning process is driven by structured prompts. The structured prompts include hierarchical semantic descriptions of the rule tree, mapping logic from parsed information to encoded fields, and output format constraints of three uppercase letters.

[0019] Preferably, in step S3, when the logic verification fails, a correction prompt word is generated based on the verification error information, and secondary reasoning is triggered to regenerate the DCC code until the verification passes or the process is transferred to manual review.

[0020] Preferably, in step S5, the iterative optimization of the naming template includes: analyzing newly added cases of non-standard naming to adjust the composition or order of keywords, and feeding the updated naming template back to the file name parsing stage to improve the confidence of subsequent file name parsing and reduce the dependence on RAG enhanced content parsing.

[0021] The present invention can achieve the following beneficial effects: This invention constructs a three-level DCC rule tree (A1 Technical Field → A2 Main Class → A3 Subclass) that integrates international standards, national standards, and enterprise-defined needs in its rule system. Version control enables rule traceability and expansion, addressing the lack of a standardized coding framework in existing technologies. In terms of parsing and reasoning, it innovates a two-level mechanism of "preliminary filename parsing + enhanced RAG content parsing," combining the Qwen-72B model and structured Prompt to achieve integrated reasoning of rules and semantics. Simultaneously, format verification (excluding O / I characters) and logical verification (A2-A3 association matching) ensure coding accuracy, overcoming the subjectivity inherent in pure LLM coding. Regarding the optimization mechanism, it identifies non-standard cases through filename and coding matching analysis, dynamically generating "Technical Field - Main Class - Subclass" naming templates to form a closed loop of "standardization optimization → improved parsing efficiency," reducing RAG dependence and improving automated coding efficiency by 50% compared to existing technologies. In terms of application value, it constructs a hierarchical classification tree and multi-dimensional statistics (A1 field, A1-A2 combination, complete coding) based on the coding results, providing data support for enterprise resource allocation and process optimization.

[0022] The core invention lies in constructing a rule-driven intelligent document coding system and method based on DCC coding rules. By structuring and tree-like DCC coding rules and supporting enterprise-customized extensions, it innovatively designs a two-level information extraction mechanism of "preliminary filename parsing + RAG enhanced content parsing". Combined with LLM inference and rule verification, it achieves automated code generation, simultaneously constructs a classification tree to complete quantitative statistics, and iteratively optimizes naming conventions through filename and code matching degree analysis, forming a closed-loop system of "rule tree construction - content parsing - intelligent coding - statistical analysis - standardization optimization". This effectively improves the standardization, automation efficiency, and enterprise adaptability of document coding, reduces manual intervention, and achieves traceability and optimizability of the entire coding process. Attached Figure Description

[0023] The present invention will be further described below with reference to the accompanying drawings and embodiments: Figure 1 This is a system structure diagram of the present invention; Figure 2 This is a flowchart of the method of the present invention. Detailed Implementation

[0024] Preferred solutions include Figures 1 to 2 As shown, a rule-driven intelligent document coding system includes: The rule building module is used to construct a multi-level DCC coding rule tree that integrates international standards, national standards, and enterprise-defined requirements. The rule tree includes A1 nodes, A2 nodes, and A3 nodes. The A1 node is a technical field node, and its values ​​include technical field codes from international standards, technical field extension codes from national standards, and enterprise-defined technical field codes. The A2 node is a mandatory set consisting of 12 standard main classes. The A3 node includes standard subclasses associated with the A2 node and enterprise-defined subclasses added under the standard spare range or Z class. All enterprise-defined codes have their change history managed through a version control mechanism.

[0025] This module can implement structured storage of rule trees using relational databases (such as MySQL or PostgreSQL), expressing hierarchical relationships A1→A2→A3 using tree data models or parent-child association tables. The application, approval, and release of enterprise-defined codes can be managed through a workflow engine, with version change records tracked via database transaction logs or independent version tables. Since international standards (such as IEC61355) and national standards (such as GB / T26853) have their own clearly defined coding systems, importing them into the system in a structured manner is a routine data modeling operation.

[0026] The document parsing module receives an input document containing a file name and file content, and extracts key encoded information through a two-level parsing mechanism. This two-level parsing mechanism includes: performing structured extraction on the file name to generate a first parsing result; if the confidence level of the first parsing result is lower than 0.8, then initiating RAG-enhanced content parsing, vectorizing the file content, and retrieving a rule-tree keyword library to generate a second parsing result. When performing RAG-enhanced content parsing, the document parsing module converts the file content into text, vectorizes it using a pre-trained language model, and performs similarity retrieval in the rule-tree keyword vector library to extract core fields.

[0027] Filename parsing can be achieved using lightweight large language models or rule template matching. Its confidence assessment is based on semantic similarity calculation between keywords and a pre-defined rule base, representing a mature natural language processing technology. When filename information is insufficient, the system can utilize general OCR tools (for scanned documents) and document parsing libraries (such as Apache Tika) to extract text content. It then uses open-source Chinese embedding models (such as BGE) to generate vectors and retrieves the most relevant rule keywords from vector databases (such as FAISS or Milvus). The entire process is based on current mainstream AI engineering frameworks and has been validated for feasibility in multiple enterprise knowledge management systems.

[0028] The intelligent encoding module is used to generate initial DCC encoding through a large language model, taking the DCC encoding rule tree and the encoding key information as input, and performing format verification and logical verification, and outputting the final DCC encoding that passes the verification; the intelligent encoding module adopts the Qwen-72B large language model, and drives inference through a structured Prompt that includes rule tree hierarchy description, parsing information mapping logic and output format constraints, to generate a formatted output that includes encoding results, inference links and confidence levels.

[0029] Utilizing large language models for structured code generation is a common approach in current AI applications. By designing prompts that include rule constraints and output formatting, the model can be effectively guided to follow preset specifications. Qwen-72B, as an open-source large model, supports private deployment, and its reasoning capabilities are sufficient to understand the semantics of technical documents and map them to encoded fields. Formatting validation (such as character validity) and logical validation (such as the correlation between A2 and A3) of the generated results can be implemented through programmatic rules. If validation fails, it can trigger secondary reasoning with error feedback, forming a reliable closed loop. This method has been implemented in intelligent classification scenarios across multiple industries.

[0030] The classification and statistics module is used to construct a hierarchical classification tree based on the final DCC code and perform multi-dimensional quantitative statistics. This module essentially groups and aggregates coded documents according to the A1, A2, and A3 fields, which is a typical multidimensional data analysis task. It can dynamically construct categorized views based on database GROUP BY operations or in-memory tree structures, and count the number of documents at each level as needed. This type of functionality is widely found in document management systems and archive platforms; the technology is simple and stable to implement, without relying on complex algorithms.

[0031] The standardization optimization module is used to calculate the matching degree between the file name and the final DCC code, mark files with a matching degree lower than 0.6 as non-standard naming cases, and generate naming templates containing technical field keywords, main category keywords, subcategory keywords and supplementary information based on high matching degree cases to iteratively optimize the document naming standard.

[0032] Matching accuracy is calculated by comparing keywords identified in filenames with the set of rule keywords corresponding to the codes; the ratio reflects the degree of naming standardization. The system can periodically summarize commonly used keyword combinations from high-matching cases, automatically generate recommended naming templates (such as "[Technical Field][File Type][Project Abbreviation]"), and guide users to standardize naming through internal notifications or template libraries. This mechanism of "learning standards from data and feeding back into processes" has been validated in enterprise content governance practices and demonstrates good feasibility.

[0033] Furthermore, the format verification is used to check whether the DCC code consists of 3 uppercase letters and excludes the characters O and I; the logic verification is used to verify whether node A2 belongs to the mandatory set, whether node A3 is associated with node A2, and whether the enterprise custom code complies with version control compliance.

[0034] Furthermore, the first-level branches of the hierarchical classification tree are grouped according to A1 nodes, the second-level branches are grouped according to A2 nodes belonging to the corresponding A1 nodes, the third-level branches are grouped according to A3 nodes belonging to the corresponding A2 nodes, and the leaf nodes are the documents belonging to the encoding; the multi-dimensional quantitative statistics include the number of documents under A1 nodes, the number of documents under the combination of A1 nodes and A2 nodes, and the number of documents under the complete DCC encoding.

[0035] A document intelligent encoding method based on a rule-driven document intelligent encoding system includes the following steps: S1. Construct a multi-level DCC coding rule tree: The rule tree integrates international standards, national standards, and enterprise-defined requirements. Its hierarchical structure includes A1 nodes (technical field nodes), A2 nodes (main category nodes), and A3 nodes (subcategory nodes). Based on the IEC61355-1:2008 international standard and the GB / T26853.1-2011 national standard, and integrating enterprise-defined requirements, a three-level structured rule tree is constructed to realize the visual management and expansion of rules.

[0036] Structured rule tree modeling: The rule tree is represented by the hierarchical function: Tree(DCC)={A1,A2,A3,R}.

[0037] A1 is a node in the technical field (optional), A1∈S_A1∪C_A1.

[0038] Where S_A1={A,B,C,D,E,F} is the set of standard technical field codes defined by IEC61355-1:2008. A1=A indicates "comprehensive management"; A1=B indicates "integrated technology"; A1=C represents "construction engineering"; A1=D represents "Mechanical Engineering"; A1=E represents "Electrical Engineering"; A1=F means "process engineering".

[0039] C_A1 is a custom technical field code for the enterprise (using uppercase letters except O / I), which must be associated with a complete technical field description.

[0040] When A1 is not explicitly specified, the system uses the default value A1=A ("Comprehensive Management") to fill in the blank.

[0041] A2 is the primary class node (mandatory), A2∈S_A2={G,H,I,J,K,L,M,N,O,P,Q,R}.

[0042] This set consists of 12 standard main class codes as specified in GB / T26853.1-2011, and is completely separate from the letter set of node A1.

[0043] A2=G indicates "file description file"; A2=H indicates "Management Files"; A2=I indicates "contract documents"; A2=J indicates "design documents"; A2=K indicates "Technical Requirements and Dimensioning Documents"; A2=L indicates "Function Description File"; A2=M indicates "list file"; A2=N indicates "wiring and cabling documents"; A2=O indicates "procurement documents"; A2=P indicates "Quality Assurance Documents"; A2=Q indicates "Test and Inspection Documents"; A2=R represents "welding file".

[0044] A3 is a subclass node (mandatory), A3∈S_A3(A2)∪C_A3(A2).

[0045] S_A3(A2) is the standard subclass set corresponding to node A2 (e.g., when A2=G, S_A3(A2)={GA,GB,GC,...,GZ}).

[0046] C_A3(A2) is an enterprise-defined subclass that can only be defined in the standard spare range (such as GD-GY when A2=G) or the "Z" class subclass (such as GZ).

[0047] R is a hierarchical association rule set, R={R_(A1→A2),R_(A2→A3)}.

[0048] R_(A1→A2) defines the optional association between A1 and A2, and R_(A2→A3) defines the mandatory association between A2 and A3 (e.g., when A2=G, A3 must belong to the range GA~GZ).

[0049] Custom code management: A1 Technical Field Level: Allows the use of uppercase letters other than S_A1={A,B,C,D,E,F} (excluding O and I) as custom technical field codes, denoted as C_A1.

[0050] For example, a company can define A1=S to represent "new energy technology" and A1=T to represent "environmental protection engineering".

[0051] A3 subclass level: Only allows adding custom subclass code C_A3(A2) within two class ranges: (1) Standard spare code segments (such as GD-GY when A2=G, HJ-HO when A2=H, etc.). (2) "Z" subclasses (all subclass codes of GZ, HZ, IZ, etc. under the A2 main class that end with Z).

[0052] Custom code attribute structure: All custom codes must be associated with a complete set of attributes to ensure their understandability and manageability. The attribute set is defined as follows: Attr(C)={ID,Code,Description,Scope,Version,Creator,CreateTime,UpdateTime,Status} in: ID: Custom code unique identifier (e.g., "CUST-A1-S-001"); Code: Custom code characters (such as "S" at A1 level, "GZ" at A3 level); Description: Detailed information (e.g., "S=New Energy Technologies: Covering documents related to photovoltaic and wind power equipment"). Scope: Scope of application (e.g., "New Energy Business Unit projects only", "Applicable to the entire company"). Version: Version number (in the format "V major version.minor version", such as V1.0); Creator: Creator (Name / Employee ID); CreateTime: Creation time (accurate to the second); UpdateTime: Last update time (same as CreateTime when the application is first created); Status: Status ("In effect", "Revoked", "Pending review").

[0053] Custom code addition process: Enterprise users need to submit custom code applications through the system's dedicated interface. The process is as follows: 1. Submit application: Fill in the Attr(C) attribute set information, specifying the level (A1 / A3), characters, and purpose of the custom code; 2. Rule Validation: The system automatically performs validity checks; 3. Approval workflow: After verification, the application enters the approval process (multi-level approval nodes can be configured). 4. Effective Release: After approval, the custom code is written into the rule tree, and the keyword library K_Tree and vector database DB_Vector are updated synchronously; 5. Push notifications: Push notifications to relevant users to announce the activation of the custom code, including attribute details and usage instructions.

[0054] S2. Perform two-level parsing on the input document: First, extract the file name into a structured form to obtain the first parsing result and its confidence level; if the confidence level is lower than 0.8, start RAG enhanced content parsing, vectorize the file content and search the rule tree keyword library to generate the second parsing result.

[0055] Document content loading and parsing: The system is compatible with common enterprise document formats, covering structured, semi-structured, and unstructured files. The specific format set is defined as: F={Excel,Word,PDF,TXT}.

[0056] Excel: Includes .xlsx and .xls formats, mainly for processing spreadsheet documents (such as bill of materials and parameter lists). Word: Includes .docx and .doc formats, mainly for processing text documents (such as technical specifications and reports); PDF: Includes text-based PDFs and scanned PDFs (which need to be converted to text via OCR), for processing officially published documents; TXT: A plain text format used for simple record or log documents.

[0057] Format adaptation and content extraction: For different file formats, content loading and text extraction are achieved through a unified interface. The core formula is: Text=F_adapt(File,f), f∈F.

[0058] File: The input binary stream of the file (including the filename FileName and the file content FileContent); f: File format (taken from set F); F_adapt(*): Format adaptation function, which calls the corresponding tool to extract content based on the file type. For Word / Excel: Read text / table content directly using the python-docx and openpyxl libraries; For text-based PDFs: Extract text using PyPDF2; For scanned PDFs: Integrate OCR tools to convert them to text; For TXT: Directly read the text content.

[0059] The extracted text needs to be preprocessed (such as removing redundant spaces and standardizing line breaks) to ensure the accuracy of subsequent parsing.

[0060] Two-level intelligent parsing mechanism: To balance parsing efficiency and accuracy, a hierarchical extraction mode of "preliminary filename parsing + RAG enhanced content parsing" is adopted, and the parsing strategy is dynamically switched according to the parsing confidence level.

[0061] Level 1 parsing: Structured extraction of filenames Core objective: To quickly extract key encoded information from filenames, applicable to documents with naming conventions, and reduce reliance on file content.

[0062] Key information extraction: Filenames are parsed using a Large Language Model (LLM) combined with preset prompt words. The formula is: Info_name = LLM(FileName, Prompt_name). FileName: File name string (e.g., "Electrical Engineering Technical Specifications Charging Pile Project.docx"); Prompt_name: Structured prompt word, defining the parsing task: "Extract technical field keywords and file type keywords (such as 'technical specification' 'management plan') from filenames, with the output format being {'technical field': xxx, 'file type': xxx}"; Info_name: Extracted results, including core fields such as technical field and file type (e.g., {'Technical Field': 'Electrical Engineering', 'File Type': 'Technical Specification'}).

[0063] Confidence calculation: To assess the reliability of Info_name, the keyword similarity is matched using a keyword similarity matching rule tree keyword library K_Tree (containing associated keywords with standard and custom codes). The formula is: Confidence_name = Sim(Info_name, K_Tree) Sim: Cosine similarity function, outputs confidence score (range [0,1]); When Confidence_name ≥ 0.8: it is judged as high confidence, and Info_name is directly used as the encoding basis without further parsing of content; When Confidence_name < 0.8: it is determined to be a low confidence level, triggering secondary resolution.

[0064] Second-level analysis: RAG enhanced content analysis When filename parsing is unreliable, key information is extracted through deep analysis of the file content to ensure the integrity of the encoding basis.

[0065] Text vectorization: Convert the preprocessed file content (Text) into a vector. The formula is: V_Text = Embedding(Text). Embedding: Pre-trained language models (such as BERT) transform text into high-dimensional vectors V_Text to capture semantic information.

[0066] Core information retrieval: Retrieve relevant fields from the rule tree vector database DB_Vector based on vector similarity. The formula is: Info_content=Retrieve(V_Text,DB_Vector,Top-K) DB_Vector: A vector library of rule tree keywords and descriptions (e.g., "A2=K: Technical requirements document, including technical specifications, parameter list, etc."). Retrieve(*): A similarity retrieval function that returns the Top-K core fields most relevant to the text semantics (such as "technical requirements", "dimension annotations", "functional description"). Info_content: Key information extracted from the content, supplementing Info_name.

[0067] Content summary generation: To assist in manual review and coding reasoning, a document content summary is generated using LLM. The formula is: Summary = LLM(Text, Prompt_summary). Prompt_summary: Defines the task as: "Summarize the core content of the document, highlighting its purpose, technical topics, and key information types, and outputting a summary of no more than 200 words."

[0068] Fusion of analysis results: Input_encode={Info_name,Info_content,Confidence_name,Summary} Input_encode serves as the input for the subsequent "Intelligent Encoding Reasoning" module; In high-confidence scenarios (Confidence_name ≥ 0.8), Info_content and Summary can be omitted to improve efficiency; In low-confidence scenarios, Info_content and Summary are the core criteria to ensure coding accuracy.

[0069] S3. Using the DCC encoding rule tree and the parsing result as input, generate the initial DCC encoding through the large language model, and perform format verification (check whether the encoding is 3 uppercase letters and exclude O / I) and logic verification (verify whether node A2 belongs to the mandatory set and whether node A3 is associated with node A2), and output the final DCC encoding that passes the verification.

[0070] Intelligent coding reasoning and verification: Based on parsed information and rule trees, compliant DCC codes are generated. Through the mechanism of "Large Language Model (LLM) inference + multi-dimensional verification + secondary correction", the code generation is automated, standardized and accurate.

[0071] LLM and rule-based reasoning: Initial encoding generation: Based on the Qwen-72B large language model, the initial encoding is generated by integrating the rule tree and parsing information. The core formula is: DCC_raw=LLM(Tree(DCC),Input_encode,Prompt_encode) Tree(DCC): A multi-level DCC encoding rule tree (including A1 / A2 / A3 level definitions, association rules, and custom code attributes); Input_encode: The set of encoding criteria for the generated code (including Info_name, Info_content, Confidence_name, and Summary). Prompt_encode: Structured prompts, containing three core parts: Rule tree hierarchy description: Clearly define the meaning of each level's coding and the standard mapping relationship (e.g., "A1=E corresponds to electrical engineering; A2=K corresponds to technical requirements and dimensioning documents"). Parsing information mapping logic: guiding the model to associate parsing keywords and codes (e.g., "if the keyword 'technical specification' is extracted, map A2=K first; if the keyword 'functional description' is extracted, map A2=L first"). Output format constraints: The mandatory encoding format is "3 uppercase letters (A1A2A3, A1 is optional and is padded by default or explicitly identified), such as EKZ, GKL".

[0072] Output: DCC_raw=c1c2c3, where c1 is the A1 technical field code, c2 is the A2 main class code, and c3 is the A3 subclass code (all are single uppercase letters).

[0073] Multi-dimensional verification mechanism: To ensure that DCC_raw conforms to the rule tree logic and format requirements, a dual mechanism of format validation and logical validation is designed, with the formula: Valid(DCC_raw) = Valid_format(DCC_raw) ∧ Valid_logic(DCC_raw). Format validation (Valid_format): Checks the standardization of encoded characters to avoid invalid characters or format errors.

[0074] Valid_format(DCC_raw)=True if and only if c1,c2,c3∈[A–Z] and c1,c2,c3∉{O,I} and length=3.

[0075] Constraints: The code must consist of 3 uppercase letters and exclude easily confused O and I letters to ensure that the code is unambiguous during recording and dissemination.

[0076] Valid_logic: Verifies the compliance of the coding hierarchy association, ensuring that the main class A2 matches the subclass A3 and that the custom code is within the scope of validity.

[0077] Valid_logic(DCC_raw) = True if and only if: c2∈S_A2 (that is, the main class A2 must belong to the standard mandatory set {G,H,I,J,K,L,M,N,O,P,Q,R}, and custom definitions are not allowed); c3∈S_A3(c2)∪C_A3(c2) (that is, the A3 subclass must be the standard subclass or enterprise-defined subclass corresponding to the A2 main class, limited to spare code segments or Z class); c1∈S_A1∪C_A1 (that is, the technical field of A1 must be an IEC standard code or a company-defined code).

[0078] Secondary reasoning correction: When Valid(DCC_raw) = False, a secondary inference correction mechanism is triggered, with the formula: DCC_final = {DCC_raw, if Valid(DCC_raw) = True; Re-LLM(DCC_raw, Error), otherwise} Error: Validation error details (e.g., "c3=GA is not a subclass of c2=G; c1=O is an invalid character"). Re-LLM: A secondary inference function based on error feedback. By supplementing error information in Prompt_encode (such as "Correct error: A3=GA needs to be adjusted to A2=G allowed subclass (GA-GZ)"), it drives the model to regenerate the encoding until Valid(DCC_final)=True.

[0079] Exception handling: If the second reasoning still fails (e.g., due to severe missing parsing information), the case is stored in the optimized dataset Data_opt, and the manual review interface is triggered to ensure a closed loop in the entire coding process.

[0080] Standardized output constraints: Output format must be uniform: all encodings must be output in "3 uppercase letters" format, i.e., DCC_final=c1c2c3.

[0081] When the A1 technical field is optional and not specified, the system uses the default value A1=A ("Comprehensive Management") to pad the code, ensuring that the code length remains 3 bits. The output results must be linked to the reasoning chain (e.g., "EKZ encoding reasoning basis: Info_name extracts 'Electrical Engineering' → A1=E; 'Technical Specifications' → A2=K; 'Requirement Documents' → A3=KZ") to ensure traceability.

[0082] Mapping Relationship Solidification: The mapping relationship between parsed keywords and their encodings is solidified through Prompt_encode, forming a standardized mapping table Map_encode: Map_encode={k→(A1,A2,A3)|k∈Info_name∪Info_content} For example: "Electrical Engineering" → (A1=E,–,–); "Technical Specifications" → (–,A2=K,–); "Functional Description" → (–,A2=L,–); "Wiring Information" → (–,A2=N,A3=A).

[0083] The mapping table dynamically iterates as the rule tree updates (e.g., keyword mapping is updated synchronously when a new custom code is added), ensuring consistent coding logic across different scenarios.

[0084] S4. Based on the final DCC encoding, aggregate documents according to the hierarchical relationship of A1 node, A2 node and A3 node, construct a hierarchical classification tree, and perform multi-dimensional quantitative statistics (including the number of documents under A1 node, the number of documents under the combination of A1 node and A2 node, and the number of documents under complete DCC encoding).

[0085] Encoding classification tree construction and quantitative statistics: The systematization of documents is achieved through a "hierarchical aggregation classification tree," and decision support data is provided through "multi-dimensional quantitative statistics," forming a closed loop from coding generation to management application.

[0086] Hierarchical aggregate classification tree: Construction method: Based on the DCC_final generated by intelligent coding reasoning, a three-level classification tree is constructed according to the coding level (A1→A2→A3).

[0087] Core formula: ClassTree = Aggregate({(DCC_i,Doc_i)}_{i=1}^N) N: Total number of documents in the system; DCC_i=c1_ic2_ic3_i: The final encoding of the i-th document (c1_i is A1 code, c2_i is A2 code, and c3_i is A3 code). Doc_i: Metadata of the i-th document (including filename, storage path, creation time, etc.); Aggregate: A hierarchical aggregation function that groups documents according to their membership relationship A1→A2→A3.

[0088] Hierarchical structure and association rules: The hierarchical structure of the classification tree strictly follows the association logic of the coding rule tree, satisfying: Branch_A1⊇Branch_A2⊇Branch_A3⊇Leaf_Doc.

[0089] Branch A1 (Branch_A1): Identified by the A1 technical field code (such as "E=Electrical Engineering", "S=New Energy Technology"), it contains all documents with that A1 code value; Branch A2 (Branch_A2): Belongs to the corresponding branch A1, identified by "A1-A2" (e.g., "EK=Electrical Engineering Technical Requirements Document"), and contains all documents that match the A1 and A2 codes; Branch A3 (Branch_A3): Belongs to the corresponding branch A2, identified by "A1-A2-A3" (e.g., "EK-KZ=Electrical Engineering Technical Requirements Document Technical Specification"), and contains all documents with completely matching codes; Leaf node (Leaf_Doc): Belongs to the corresponding A3 branch, directly associated with the specific document Doc_i, and records the document's metadata and access entry point.

[0090] Dynamic update mechanism: The classification tree is dynamically adjusted in real time as documents are added, encoding changes, or the rule tree is updated. When a new document is added, it is automatically mounted to the corresponding A3 branch based on its DCC_final value. When the code changes (such as manual corrections or rule optimizations that cause changes to DCC_final), the document is automatically migrated from the original branch to the new branch; When a new custom code is added to the rule tree (such as adding A1=S), the corresponding A1 branch and empty A2 / A3 sub-branches are automatically created to ensure that the new coded document can be mounted normally.

[0091] Multi-dimensional quantitative statistics: Level 1 Statistics (A1 Technical Field Dimension): Counts the total number of documents within each A1 technical field. The formula is: Count(A1=x)=Σ_{i=1}^NI(DCC_i.c1=x) x: A1 code (such as E, S, etc.); I: Indicator function; Example: Count(A1=E)=150 means there are 150 documents in the technical field of "Electrical Engineering".

[0092] Secondary statistics (A1-A2 combination dimension): Counts the number of documents under a specific combination of A1 technical field and A2 main category. The formula is: Count(A1=x,A2=y)=Σ_{i=1}^NI(DCC_i.c1=x∧DCC_i.c2=y) y: A2 code (such as K, L, etc.); Example: Count(A1=E,A2=K)=50 means there are 50 documents under the "Electrical Engineering Technical Requirements Documents" group.

[0093] Level 3 Statistics (Complete Encoding Dimension): Counts the number of documents corresponding to each complete DCC encoding, using the formula: Count(DCC=xyz)=Σ_{i=1}^NI(DCC_i=xyz) xyz: Complete encoding (such as EKZ, GKL, etc.); Example: Count(DCC=EKZ)=20 means there are 20 documents with the encoding "EKZ".

[0094] Statistical results output: All statistical results are summarized into a structured dataset Stats={Count(A1),Count(A1,A2),Count(DCC)}, with output formats including numerical tables, bar charts (showing the proportion of documents in each A1 domain), and heatmaps (showing the document distribution density of the A1-A2 combination); it supports filtering by time range (such as "statistics of new documents in the last 3 months") and by department (such as "statistics of production department documents"), improving statistical flexibility.

[0095] S5. Calculate the matching degree between the file name and the final DCC code (the ratio of the number of effective encoded fields to the total number of fields). Mark files with a matching degree lower than 0.6 as non-standard naming cases, and generate naming templates containing technical field keywords, main category keywords, subcategory keywords and supplementary information based on high matching degree cases to iteratively optimize the document naming standard.

[0096] Matching degree analysis mechanism: Match score calculation logic: Based on the key information of the filename extracted during the document parsing stage and the final encoding result, the match score between the two is calculated using the formula: MatchScore=Num(K_name∩(K_A1∪K_A2∪K_A3)) / Len(ValidFields(DCC_final)) K_name: A set of keywords extracted from the filename (i.e., valid fields in Info_name, such as {"Electrical Engineering", "Technical Specifications"}); K_A1: The set of standard keywords corresponding to the technical field of A1 in the encoding (e.g., when A1=E, {"Electrical Engineering", "Power System"}). K_A2: The set of standard keywords corresponding to the main class A2 in the encoding (e.g., when A2=K, {"technical specifications", "parameter requirements"}). K_A3: The set of standard keywords corresponding to the A3 subclass in the encoding (e.g., when A3=KZ, {"specification document", "technical details"}). ValidFields(DCC_final): The number of valid fields in DCC_final (2 if A1 is optional, 3 if required, i.e., Len can be 2 or 3). Num(): The number of elements in the intersection of the sets, i.e. the number of keywords that were successfully matched.

[0097] Irregular case identification and high-match case mining: Cases with non-standard naming: When MatchScore < 0.6, these cases are marked as non-standard cases and added to the Case_invalid set. These cases usually have missing, misplaced, or ambiguous keywords in the filename (e.g., "Project Documentation V2.docx" does not reflect the technical field and file type), and should be used as optimization target samples.

[0098] High-match cases: When the MatchScore is ≥ 0.8, they are marked as high-quality cases and stored in the Case_valid set. The file names of these cases clearly reflect the core coding information (e.g., "XXX Electrical Engineering Technical Specification Charging Pile KZ.docx"), which is the core basis for extracting naming rules.

[0099] Keyword mapping table generation: Based on the Case_valid set, the mapping relationship between keywords and encoded fields is extracted to form a standardized mapping table: Map_keyword={(k,(A1,A2,A3))|k∈K_name,(A1,A2,A3)=DCC_final field} Example: "Electrical Engineering" → (A1=E,–,–); "Technical Specifications" → (–,A2=K,–); "Specification Documents" → (–,–,A3=KZ).

[0100] The mapping table is dynamically updated with each new Case_valid, ensuring that the correspondence between keywords and codes always aligns with the company's actual naming habits.

[0101] Naming template iteration: Basic naming template construction: Based on Map_keyword and encoding hierarchy, standardized naming templates are generated. The core formula is: Template=[k_A1][k_A2][k_A3][Supplementary Information] [k_A1]: Placeholder for technical field keywords (taken from the keyword corresponding to A1 in Map_keyword, such as "electrical engineering"); [k_A2]: Placeholder for the main class keyword (taken from the keyword corresponding to A2 in Map_keyword, such as "technical specifications"); [k_A3]: Subclass keyword placeholder (taken from the keyword corresponding to A3 in Map_keyword, such as "system design"); [Supplementary Information]: Reserved field for adding personalized information such as the original file name and project name.

[0102] Template iteration optimization mechanism: Named templates need to be updated periodically (e.g., weekly) based on newly added coded data. The formula is: Template_{n+1}=Update(Template_n,Data_new,Case_invalid) Data_new: Newly added encoded data and corresponding filename information; Update(): An optimization function that adjusts the template in the following ways: If a high-frequency new keyword (such as "energy storage system") appears in Data_new, add it to Map_keyword and update the corresponding placeholder; Analyze the reasons for non-standard statements in Case_invalid (such as missing [k_A2]), and strengthen the prompts for corresponding keywords in the template (such as "It is recommended to include main category keywords such as 'technical specifications' and 'management plan'"). Adjust the order or format of keywords (e.g., move "[Supplementary Information]" to the front to fit the naming convention of prioritizing projects).

[0103] The optimized template feeds back into the coding process through the following paths: Improve parsing confidence: Embed Template_{n+1} into the Prompt_name of filename parsing to guide users to name files according to the specifications; Reduce RAG dependency: In high-confidence parsing scenarios, there is no need to start secondary RAG content parsing, thus reducing the time spent in the encoding process; Reduced human intervention: Improved naming standardization further reduces the error rate of coding reasoning, thus reducing the amount of manual review.

[0104] The above embodiments are merely preferred technical solutions of the present invention and should not be considered as limitations on the present invention. The scope of protection of the present invention should be limited to the technical solutions described in the claims, including equivalent substitutions of the technical features described in the claims. That is, equivalent substitutions and improvements within this scope are also within the scope of protection of the present invention.

Claims

1. A rule-driven intelligent document coding system, characterized in that, include: The rule building module is used to build a multi-level DCC coding rule tree that integrates international standards, national standards and enterprise-defined requirements. The rule tree includes A1 nodes, A2 nodes and A3 nodes. The document parsing module is used to receive input documents containing file names and file contents, and extract key encoded information through a two-level parsing mechanism; The two-level parsing mechanism includes: performing structured extraction on the file name to generate a first parsing result; if the confidence of the first parsing result is lower than 0.8, then starting RAG enhanced content parsing, vectorizing the file content, and searching the rule tree keyword library to generate a second parsing result. The intelligent encoding module is used to take the DCC encoding rule tree and the encoding key information as input, generate the initial DCC encoding through the large language model, perform format verification and logical verification, and output the final DCC encoding that passes the verification. The classification and statistics module is used to construct a hierarchical classification tree based on the final DCC code and perform multi-dimensional quantitative statistics. The standardization optimization module is used to calculate the matching degree between the file name and the final DCC code, mark files with a matching degree lower than 0.6 as non-standard naming cases, and generate naming templates containing technical field keywords, main category keywords, subcategory keywords and supplementary information based on high matching degree cases to iteratively optimize the document naming standard.

2. The rule-driven intelligent document encoding system according to claim 1, characterized in that, The A1 node is a technical field node, and its values ​​include technical field codes derived from international standards, technical field extension codes derived from national standards, and enterprise-defined technical field codes; the A2 node is a mandatory set consisting of 12 standard main classes; the A3 node includes standard subclasses associated with the A2 node and enterprise-defined subclasses added under the standard spare range or Z class; all enterprise-defined codes have their change history managed through a version control mechanism.

3. The rule-driven intelligent document coding system according to claim 1, characterized in that, When performing RAG enhanced content parsing, the document parsing module converts the file content into text, then vectorizes it using a pre-trained language model, and performs similarity retrieval in the rule tree keyword vector library to extract core fields.

4. The rule-driven intelligent document coding system according to claim 1, characterized in that, The intelligent encoding module adopts the Qwen-72B large language model and drives inference through a structured Prompt that includes rule tree hierarchy descriptions, parsing information mapping logic, and output format constraints, generating a formatted output that includes encoding results, inference links, and confidence levels.

5. The rule-driven intelligent document coding system according to claim 1, characterized in that, The format verification is used to check whether the DCC code consists of 3 uppercase letters and excludes the characters O and I; the logic verification is used to verify whether node A2 belongs to the mandatory set, whether node A3 is associated with node A2, and whether the enterprise custom code complies with version control compliance.

6. The rule-driven intelligent document encoding system according to claim 1, characterized in that, The hierarchical classification tree has first-level branches grouped by A1 nodes, second-level branches grouped by A2 nodes belonging to the corresponding A1 nodes, third-level branches grouped by A3 nodes belonging to the corresponding A2 nodes, and leaf nodes representing documents belonging to that encoding. The multi-dimensional quantitative statistics include the number of documents under A1 nodes, the number of documents under the combination of A1 and A2 nodes, and the number of documents under complete DCC encoding.

7. The rule-driven intelligent document coding system according to claim 1, characterized in that, The naming template is dynamically generated by analyzing highly matching cases and is used to guide the iterative optimization of file naming conventions.

8. The document intelligent encoding method of the rule-driven document intelligent encoding system according to claim 1, characterized in that, Includes the following steps: S1. Construct a multi-level DCC coding rule tree. The rule tree integrates international standards, national standards and enterprise-defined requirements. Its hierarchical structure includes A1 nodes for representing technical fields, A2 nodes for representing the main class of the file and A3 nodes for representing subclasses. The value of A2 node belongs to a preset set of mandatory main classes, and the value of A3 node has a mandatory association relationship with A2 node. S2. Perform two-level parsing on the input document: First, extract the file name in a structured manner to obtain the first parsing result and its confidence level; if the confidence level is lower than 0.8, start RAG enhanced content parsing, vectorize the file content and search the rule tree keyword library to generate the second parsing result; S3. Using the DCC encoding rule tree and the encoding basis set composed of the first parsing result and the second parsing result as input, generate an initial DCC encoding through a large language model, and perform format verification and logical verification, outputting the final DCC encoding that passes the verification; the format verification is used to verify whether the initial DCC encoding consists of three uppercase letters and does not contain the characters O and I, and the logical verification is used to verify whether the value of node A2 belongs to the mandatory main class set and whether the value of node A3 has a legal relationship with the value of node A2; S4. Based on the final DCC code, aggregate documents according to the hierarchical affiliation of A1 node, A2 node and A3 node, construct a hierarchical classification tree, and perform multi-dimensional quantitative statistics. The multi-dimensional quantitative statistics include: counting the number of documents belonging to the same A1 node, the number of documents belonging to the same combination of A1 node and A2 node, and the number of documents with the same complete DCC code. S5. Calculate the matching degree between the file name and the final DCC code, wherein the matching degree is the ratio of the number of identifiable encoded fields in the file name to the total number of valid fields in the DCC code; Files with a matching score below 0.6 are marked as non-standard naming cases. Based on high-matching cases with a matching score of not less than 0.8, naming templates containing technical field keywords, main category keywords, subcategory keywords, and supplementary information are generated to iteratively optimize document naming conventions.

9. The rule-driven intelligent document encoding method according to claim 8, characterized in that, In step S1, the value of node A1 includes technical field codes from international standards, technical field extension codes from national standards, and enterprise-defined technical field codes; the value of node A3 includes standard subclass codes corresponding to node A2 and enterprise-defined subclass codes defined in a preset spare range or a subclass range ending with Z; all enterprise-defined codes are associated with attribute information and managed through a version control mechanism.

10. The rule-driven intelligent document encoding method according to claim 8, characterized in that, In step S2, the input document format includes Excel, Word, PDF, or TXT; for scanned PDF documents, they are first converted into text through optical character recognition before content parsing.

11. The rule-driven intelligent document encoding method according to claim 8, characterized in that, In step S3, the large language model is Qwen-72B, and its reasoning process is driven by structured prompt words. The structured prompt words include rule tree hierarchical semantic descriptions, mapping logic from parsed information to encoded fields, and output format constraints of three uppercase letters.

12. The rule-driven intelligent document encoding method according to claim 8, characterized in that, In step S3, when the logic verification fails, a correction prompt is generated based on the verification error information, and secondary reasoning is triggered to regenerate the DCC code until the verification passes or the process is transferred to manual review.

13. The rule-driven intelligent document encoding method according to claim 8, characterized in that, In step S5, the iterative optimization of the naming template includes: analyzing newly added cases of non-standard naming to adjust the composition or order of keywords, and feeding the updated naming template back to the file name parsing stage to improve the confidence of subsequent file name parsing and reduce the dependence on RAG enhanced content parsing.

Images