Document information entry method, device, and storage medium

Abstract

The application discloses a document information input method and device and a storage medium, and relates to the technical field of electronic digital data processing.The document information input method comprises the following steps: determining a document type according to characters recognized for a to-be-processed document; calling a large language model to extract an entity in the characters, and associating entity relationship, business intention, context context and context relationship corresponding to the entity as reference information of the entity; constructing an extraction question based on a field in a business data structure file corresponding to the document type; and extracting a target field from the entity through the extraction question in combination with the reference information.The application can achieve the technical effect of efficiently and accurately converting fragmented text into structured data available for a business system.

Description

Technical Field

[0001] This application relates to the field of electronic digital data processing technology, and in particular to a document information input method, device and storage medium. Background Technology

[0002] Our business systems contain a large number of unstructured documents such as contracts, invoices, reports, and resumes. Currently, we mainly use optical character recognition (OCR) tools to extract text from these documents, and then manually input the extracted data into the system. However, the text extracted by OCR tools is fragmented and cannot be accurately matched with the specific fields in the business system. Summary of the Invention

[0003] The main purpose of this application is to provide a document information input method, device and storage medium, which aims to solve the technical problem that the text extracted by optical character recognition tools is fragmented and cannot be accurately matched with specific fields of the business system.

[0004] To achieve the above objectives, this application provides a document information entry method, which includes:

[0005] The document type is determined based on the characters identified in the document to be processed;

[0006] The large language model is invoked to extract entities from the characters, and the entity relationships, business intents, contextual contexts, and contextual relationships corresponding to the entities are associated as reference information for the entities.

[0007] The extraction problem is constructed based on the fields in the business data structure file corresponding to the document type.

[0008] Based on the reference information, the target field is extracted from the entity using the extraction question.

[0009] In one embodiment, the step of determining the document type based on characters identified in the document to be processed includes:

[0010] Target characters are filtered from the characters identified in the document to be processed using preset rules;

[0011] Based on the meaning of the target character, the document type is determined, and the document type is at least one of contract, invoice, report, and resume.

[0012] In one embodiment, the step of calling a large language model to extract entities from the characters and associating the entity relationships, business intents, contextual information, and contextual relationships corresponding to the entities as reference information for the entities includes:

[0013] Extract each entity from the characters, and the entity relationships between them;

[0014] Analyze the sentence structure of the sentence containing the entity, the paragraph logic of the paragraph containing the entity, and the overall structure of the document to be processed to construct the context of the entity.

[0015] The historical text corresponding to the document type is invoked to identify the business intent corresponding to the entity.

[0016] The contextual relationship of the entity within the paragraph is determined based on the given context.

[0017] The entity relationship, business intent, context, and contextual relationship corresponding to the entity are associated as reference information for the entity.

[0018] In one embodiment, the step of constructing the extraction problem based on the fields in the business data structure file corresponding to the document type includes:

[0019] Map the business data structure file corresponding to the document type to the knowledge graph, and update the business data structure file according to the mapping information;

[0020] The extraction problem is constructed based on the fields in the updated business data structure file;

[0021] The step of extracting the target field from the entity by combining the reference information and the extraction question includes:

[0022] Using the entity as a corpus, retrieve the answer field corresponding to the extraction question;

[0023] Based on the reference information and the mapping information, the answer fields are filtered to determine the target fields whose similarity to the extraction question is greater than a first threshold.

[0024] In one embodiment, the step of extracting the target field from the entity by combining the reference information and the extraction question includes:

[0025] Using the entity as a corpus, retrieve the answer field corresponding to the extraction question;

[0026] Based on the reference information, the answer fields are filtered to determine the target fields whose similarity to the extraction question is greater than a second threshold.

[0027] In one embodiment, after the step of extracting the target field from the entity by means of the extraction question in conjunction with the reference information, the method includes:

[0028] The target field is validated according to the business data structure specification associated with the business data structure file;

[0029] If the target field fails validation, for the remaining entities, the step of extracting the target field from the entities by combining the reference information and using the extraction question is performed.

[0030] In one embodiment, after the step of extracting the target field from the entity by means of the extraction question in conjunction with the reference information, the method includes:

[0031] Determine the API interface corresponding to the target field;

[0032] Construct a request message based on the target field and the parameter requirements of the API interface;

[0033] Call the API interface to send the request message, and parse the returned result to obtain the supplementary fields;

[0034] Add the supplementary field as the target field.

[0035] In one embodiment, after the step of extracting the target field from the entity by means of the extraction question in conjunction with the reference information, the method includes:

[0036] The target fields are assembled into structured data according to the format specified in the business data structure file;

[0037] The structured form generated from the structured data is displayed on the interface.

[0038] In response to a click operation on a first field in the structured form, a second field corresponding to the first field in the document to be processed is determined;

[0039] Highlight the second field.

[0040] In addition, to achieve the above objectives, this application also provides a document information input device, which includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the computer program is configured to implement the steps of the document information input method described above.

[0041] In addition, to achieve the above objectives, this application also provides a storage medium, which is a computer-readable storage medium, on which a program implementing the document information entry method is stored, and the program implementing the document information entry method is executed by a processor to implement the steps of the document information entry method as described above.

[0042] This application provides a document information input method. First, the document type is determined based on the characters identified in the document to be processed. Then, a large language model is called to extract entities from the characters, and the entity relationships, business intentions, contextual information, and contextual relationships corresponding to the entities are associated as reference information for the entities. An extraction problem is constructed based on the fields in the business data structure file corresponding to the document type. Finally, the target fields are extracted from the entities by combining the reference information with the extraction problem.

[0043] In summary, this application addresses the technical challenge of fragmented text extraction and inability to accurately match it with specific fields in a business system using Optical Character Recognition (OCR) tools. This is achieved through a coherent logic of "precise document type classification - fragmented text semantic integration - targeted association with business fields - precise extraction of target information." First, the document type is determined based on the characters recognized by OCR, laying the foundation for subsequent matching with the corresponding business scenario's field system and avoiding field matching errors caused by document type confusion. Second, a large language model is invoked to perform deep processing on the fragmented OCR characters, not only extracting entities with business significance but also associating these entities with their corresponding... Using entity relationships, business intent, contextual information, and contextual relationships as reference information, isolated fragmented text is transformed into a structured information set with semantic logic and business connections, overcoming the core deficiency of OCR text being "lacking context and logical connections." Then, extraction questions are constructed based on fields in the Business Data Structure (DSL) file corresponding to the document type, directly binding extraction requirements to business fields and clarifying "what to extract" and "extraction criteria." Finally, combining the reference information, the extraction questions are used to accurately locate and extract target fields from entities, ensuring that the extraction results fully match the semantic and format requirements of specific fields in the business system. This achieves efficient and accurate conversion of fragmented text into structured data usable by the business system. Attached Figure Description

[0044] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0045] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0046] Figure 1 This is a flowchart illustrating the document information entry method of this application in Embodiment 1.

[0047] Figure 2This is a flowchart illustrating the second embodiment of the document information entry method for this application.

[0048] Figure 3 This is a flowchart illustrating the fifth embodiment of the document information entry method for this application.

[0049] Figure 4 This is a schematic diagram of the hardware structure involved in the embodiment of the document information input device of this application.

[0050] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0051] It should be understood that the specific embodiments described herein are merely illustrative of the technical solutions of this application and are not intended to limit this application.

[0052] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0053] Currently, our business systems contain a large number of unstructured documents such as contracts, invoices, reports, and resumes. The current approach primarily involves using optical character recognition (OCR) tools to extract text from these documents, followed by manual input based on the extracted fields. However, the text extracted using OCR tools is fragmented and cannot be accurately matched to the specific fields in the business system.

[0054] It should be noted that the executing entity in this embodiment can be a document information entry system, or a computing service device with data processing, network communication, and program execution functions, such as a tablet computer, personal computer, or mobile phone, or a document information entry device capable of performing the above functions. This embodiment does not specifically limit it in this way. The following uses a document information entry system as the executing entity as an example to describe this embodiment and the following embodiments.

[0055] Based on this, Embodiment 1 of this application proposes a document information entry method, please refer to... Figure 1 The document information entry method includes steps S10 to S40:

[0056] Step S10: Determine the document type based on the characters identified in the document to be processed.

[0057] In this embodiment, the document to be processed refers to an unstructured document that requires structured information input, including scanned copies and electronic documents in PDF format, text documents in Word format, spreadsheet documents in Excel format, and document images in JPG, PNG, BMP, etc. The recognized characters refer to the text content that can be directly processed by a machine, obtained by converting image or scanned document formats using Optical Character Recognition (OCR) technology, or by reading electronic documents using document parsing technology. The document type refers to the category categorized according to the business purpose and core content of the document to be processed. Common categories include contract documents, invoice documents, resume documents, and financial report documents. Different document types correspond to different information extraction requirements and data structure specifications.

[0058] As an optional implementation, the identified characters are first preprocessed to remove meaningless spaces, newlines, and special symbols (such as #, *, ¥, and other non-business-related symbols). Then, frequently occurring business feature terms are extracted from the preprocessed characters. Matching is performed based on a preset terminology database, which stores exclusive feature terms corresponding to various document types. For example, contract documents correspond to terms such as "contract name," "signing date," "Party A," and "Party B," while invoice documents correspond to terms such as "invoice number," "invoice date," "tax amount," and "total price including tax." The number of matched feature terms for each document type is counted, and the document type with the most matched terms is selected as the final type of the document to be processed. The database also supports updating the terminology content based on new business scenarios added by the enterprise.

[0059] Step S20: Call the large language model to extract entities from the characters, and associate the entity relationship, business intent, context and context relationship corresponding to the entity as reference information of the entity.

[0060] In this embodiment, a large language model refers to a pre-trained language model with deep semantic understanding and information extraction capabilities, including GPT series models, BERT series models, and customized language models optimized for specific industries (such as finance and law). An entity refers to an information unit with clear business meaning extracted from characters. For example, in contract documents, entities may include the contract name, contract amount, signing date, and the names of the cooperating companies. Entity relationships refer to the logical connections between different entities, such as the "numerical attribution" relationship between "contract amount" and "500,000 yuan," or the "subject correspondence" relationship between "Party A" and "a certain information technology company." Business intent refers to the core business purpose reflected in the document's character content. For example, the business intent of a contract document is "to clarify the rights, obligations, and transaction details of both parties," while the business intent of a bill document is "to record economic transaction amounts and tax information." Contextual context refers to the semantic environment presented by the sentence or paragraph containing the entity. For example, the sentence "This contract was signed on March 15, 2025" is the contextual context of the entity "March 15, 2025." Contextual relationships refer to the logical connections between different sentences and paragraphs in a document. For example, in a contract document, the first paragraph mentions "Party B shall provide technical support services," and the second paragraph mentions "Party B shall submit an acceptance report after the service period expires." The connection between the "service requirements and subsequent processes" in these two paragraphs is a contextual relationship. Reference information refers to a structured set of information formed by integrating entities with their corresponding entity relationships, business intentions, contextual information, and contextual relationships. This information is used to assist in the accurate extraction of target fields.

[0061] As an alternative implementation, a sequence labeling model based on BERT is used as the large language model. First, the identified characters are segmented, and each word is assigned a positional code (identifying the word's position in a sentence) and a type code (identifying the text paragraph to which the word belongs). The processed word sequence is then input into the model, which learns the semantic features of the text through a multi-layer Transformer encoder. Simultaneously, multiple built-in functional modules are activated: the sequence labeling module labels each word with entity categories (e.g., "contract name," "amount value," "date," etc.); the relation extraction module identifies the logical relationships between different entities; the intent recognition module determines the business intent based on the full document's characters; and the context analysis module records the entity context and paragraph relationships. Then, the labeled entities are mapped one-to-one with the association information output by each module to generate a reference information table. Each row in the table corresponds to one entity, and each column corresponds to a type of association information (e.g., entity relationship column, business intent column, etc.). A unique identifier is added to the reference information table, which is then bound and stored with the document to be processed.

[0062] Step S30: Construct an extraction problem based on the fields in the business data structure file corresponding to the document type.

[0063] In this embodiment, the business data structure file, also known as the domain-specific language (DSL) file, is a data structure specification file formulated according to the business requirements of the corresponding document type. It supports formats such as JSON, YAML, and XML. The file contains the field names, field types (e.g., text, numeric, date), field validation rules (e.g., NOT NULL constraints, numeric ranges, date formats), and logical relationships between fields (e.g., calculation relationships, conditional display relationships), required for the document type. A field is a unit defined in the business data structure file used to store specific business information. For example, in the business data structure file corresponding to a contract document, fields may include "Contract Name," "Contract Amount," "Signing Date," and "Party B Company Name." The extraction question refers to a natural language question constructed to obtain the specific information corresponding to each field. The question description must clearly point to the business meaning of the field to ensure accurate matching of the answer from the entity and reference information.

[0064] As an optional implementation, the system first uses its built-in parser to read the business data structure file corresponding to the document type, parsing out the name and semantic description of each field in the file. Then, it constructs an extraction question according to a fixed rule of "interrogative word + field semantic description". For example, if the field name is "contract amount" and the semantic description is "the total transaction amount involved in the contract", then the constructed extraction question is "What is the total transaction amount involved in the contract?". If the field name is "signing date" and the semantic description is "the specific date the contract was officially signed", then the constructed extraction question is "What is the specific date the contract was officially signed?". After construction, a mapping table between extraction questions and corresponding fields is established. The table contains three columns of information: extraction question content, field name, and field type, ensuring that each field has a unique corresponding extraction question, and the mapping table can be updated synchronously with the update of the business data structure file.

[0065] Step S40: Based on the reference information, extract the target field from the entity using the extraction question.

[0066] In this embodiment, reference information refers to the structured information set generated in step S20, which includes entities and their corresponding entity relationships, business intent, context, and contextual relationships. The extraction question refers to the natural language question constructed in step S30, which corresponds one-to-one with the fields of the business data structure file. An entity refers to a business-meaning information unit extracted from the characters of the document to be processed. Target fields refer to structured data that meets the field requirements of the business data structure file and is ultimately to be entered into the business system. Each target field corresponds to a field in the business data structure file, and its value must satisfy the validation rules of that field; it is the core result of document information entry.

[0067] As an optional implementation, the extraction question corresponding to the target field to be extracted is first determined based on the mapping table between the extraction question and the field. Then, entities and related information that are semantically related to the extraction question are filtered from the reference information. For example, for the extraction question "What is the total transaction amount involved in the contract?", entities with the entity category "amount value" (such as "800,000 yuan") and the corresponding contextual context of the entity are filtered from the reference information. After confirming that the contextual context is consistent with the semantics of the extraction question, the entity is initially used as a candidate value for the target field. If multiple candidate entities are filtered (such as "800,000 yuan" and "200,000 yuan" appearing at the same time), the entity relationship in the reference information is further judged. For example, if the entity relationship shows that "800,000 yuan" is associated with "total contract amount" and "200,000 yuan" is associated with "prepayment amount", then "800,000 yuan" is selected as the target field value of the "contract amount" field.

[0068] For example, taking the scenario of a company's finance department processing VAT invoice document information entry as an example, the document to be processed is a scanned copy of a VAT invoice in PDF format. The characters are recognized using OCR technology. The character content includes: "Invoice Name: VAT Special Invoice, Invoice Number: 01234567, Invoice Date: April 20, 2025, Seller Name: [Company Name] Electronic Equipment Co., Ltd., Buyer Name: [Company Name] Technology Development Co., Ltd., Goods Name: Laptop Computers, Quantity: 10 units, Unit Price: 5000 yuan, Amount: 50000 yuan, Tax Rate: 13%, Tax Amount: 6500 yuan, Total Price including Tax: 56500 yuan". The recognized characters... The characters are preprocessed to remove extra spaces, and feature terms such as "invoice name," "invoice number," "invoice date," "tax amount," and "total price including tax" are extracted. After matching with the terminology database, the document type is determined to be a VAT invoice document within the invoice category. The large model is then called to extract entities such as "VAT special invoice," "01234567," "April 20, 2025," "a certain electronic equipment company," "a certain technology development company," "laptop," "10 units," "5000 yuan," "50000 yuan," "13%," "6500 yuan," and "56500 yuan" from the characters, and the reference information of each entity is associated. The entity relationship for "50,000 yuan" is "total amount of corresponding goods," the business intent is "to record the amount and tax information of this electronic device transaction," the context is "amount: 50,000 yuan," and the context relationship is "together with the tax amount of 6,500 yuan, it constitutes a total price including tax of 56,500 yuan." The business data structure file (DSL file) corresponding to the VAT invoice document is read. This file contains fields such as "invoice name," "invoice number," "invoice date," "seller's name," "buyer's name," "goods name," "quantity," "unit price," "amount," "tax rate," "tax amount," and "total price including tax." Based on the semantic description of the "amount" field, "total amount of goods transaction..." The extraction question is constructed using the "Amount Value" and the validation rule "Value greater than 0 and unit is yuan": "What is the total amount of goods transactions with a value greater than 0 and unit is yuan?". The extraction question and reference information are input into the GPT-3.5 model. The model combines the entity relationship of "50,000 yuan" and the context to output "50,000 yuan" as the answer. After verifying that the answer meets the type requirements and validation rules of the "Amount" field, it is determined as the target field value of the "Amount" field. At the same time, the target values ​​of other fields are extracted in the same way, such as "Tax Amount" being extracted to "6,500 yuan" and "Total Price and Tax" being extracted to "56,500 yuan".

[0069] This embodiment accurately determines document types based on a terminology database or text classification model, providing a clear direction for subsequent information extraction and avoiding extraction bias. It leverages a large language model to extract entities and associates them with multi-dimensional reference information, achieving accurate extraction of target fields by addressing the extraction question. This effectively reduces the error rate of manual data entry and improves the accuracy of target field extraction. Furthermore, the entire process eliminates the need for manual word-by-word searching and input, significantly improving input efficiency. It can also adapt to the input needs of different document types by updating the business data structure file, demonstrating strong versatility. This provides timely and accurate structured data support for enterprise business systems, accelerating business process progress.

[0070] Based on any of the above embodiments, in Embodiment 2 of this application, step S10 includes:

[0071] Step S11: Filter the target characters among the characters identified in the document to be processed by using preset rules.

[0072] In this embodiment, the preset rules refer to a set of rules pre-constructed based on the business attributes of multiple document types, used to extract key information from the full set of recognized characters. These rules cover feature term matching rules, stop word filtering rules, synonym normalization rules, and term weight ranking rules. The characters obtained from the recognition of the document to be processed refer to all machine-readable text (including business-related expressions and meaningless expressions) obtained after converting scanned / image documents through optical character recognition (OCR) technology or reading electronic documents through document parsing technology. The target characters refer to text fragments that, after being filtered by the preset rules, can directly reflect the core business attributes of the document and play a decisive role in determining the document type, such as feature terms or specific expressions related to "contract" or "invoice".

[0073] As an alternative implementation, first, construct a feature term library for multiple document types, and label exclusive feature terms for contracts, bills, reports, and resumes respectively (for contracts, label "Party A", "Party B", "Signing Date", "Liability for Breach of Contract", "Contract Amount"; for bills, label "Invoice Number", "Invoice Date", "Tax Amount", "Total Amount of Tax and Price", "Taxpayer Identification Number"; for reports, label "Abstract", "Analysis Conclusion", "Data Source", "Trend Forecast"; for resumes, label "Name", "Work Experience", "Education Background", "Skill Certificates", "Job Hunting Intention"), and configure weights for each feature term (set the weight of core terms such as "Contract Name" and "Invoice Number" to 1.0, and the weight of associated terms such as "Obligation Performance" and "Data Chart" to 0.6); then preprocess the full set of identified characters, and remove meaningless words through stop word filtering rules (such as auxiliary words and prepositions like "of", "in", "for", etc., and non-business-related expressions like "Attachment", "Page Number", "Seal Place"); based on the synonym normalization rule, uniformly convert synonyms, abbreviations, or colloquial expressions in the characters into the standard expressions in the feature term library (such as convert "contract" to "contract", "tax number" to "taxpayer identification number", "work experience" to "work experience", "summary report" to "report"); finally, traverse the preprocessed characters, match the terms in the feature term library and accumulate the weights, and screen out the text segments with the top 20% total weight as the target characters, ensuring that the screening results focus on the core business attributes of the document and exclude interference information.

[0074] Step S12, determine the document type according to the literal meaning of the target character, and the document type is at least one of contract, bill, report, and resume.

[0075] In this embodiment, the literal meaning of the target character refers to the semantic meaning carried by the target character, including the literal本义 and the exclusive meaning in a specific business scenario (such as "Party A" specifically refers to a cooperative party in a contract in a business scenario); the document type refers to the category divided according to the core use of the to-be-processed document, specifically covering contracts, bills, reports, and resumes, and can be extended to other types such as purchase orders and approval forms according to the enterprise's business needs; this step realizes the accurate determination of the type by analyzing the semantic association of the target character and establishing a mapping relationship with the preset document type.

[0076] As an optional implementation, word embedding technology is used to convert the selected target characters into low-dimensional semantic vectors. A pre-trained Word2Vec model is then used to capture the semantic relationships between the target characters (e.g., "Party A," "Party B," and "breach of contract liability" are close in the vector space and highly match the semantics of contract documents; "invoice number," "tax amount," and "total price and tax" tend to be associated with invoice documents). Simultaneously, a document type semantic classification model is constructed. Using standard term vectors for each document type in the feature terminology database as training samples, the model is trained using the Support Vector Machine (SVM) algorithm, enabling the model to compare the target character vectors with the standard document type vectors. The system has the capability to calculate similarity. After inputting the semantic vector of the target character into the classification model, the model outputs the similarity value between the target character and contracts, invoices, reports, and resumes. The document type with the highest similarity and exceeding a preset threshold (e.g., 0.7) is selected as the final result. If the target character matches multiple document types simultaneously (e.g., a document character contains both "report summary" and "contract number"), the system further analyzes the weight distribution of the target character and selects the document type with the highest total weight. If the weight difference is less than 0.1 (e.g., contract type weight 0.65, report type weight 0.60), a manual confirmation process is triggered, where business personnel determine the type based on the overall content of the document, avoiding misjudgments caused by a single feature.

[0077] For example, consider a document with mixed wording processed by a company's administrative department. The document to be processed is a PDF format "2024 Q2 Sales Analysis Report (including contract performance description)". The character content obtained through OCR recognition includes: "Report Summary: This report analyzes product sales trends based on 2024 Q2 sales data; it also includes a performance description of the XX product cooperation contract, with Party A being a retail company and Party B being our company, the signing date being May 10, 2024, the data source being the sales system, and the analysis conclusion being that Q2 sales increased by 15% year-on-year." Preset rules are invoked to first filter out the words "this", "for", and "based on" using stop word filtering. Meaningless words were removed; then, "cooperation contract" was converted to "contract" through synonym normalization; finally, the feature terminology library was matched, and after accumulating weights, target characters such as "report summary", "sales data", "sales trend", "data source", "analysis conclusion", "contract", "Party A", "Party B", and "signing date" were selected; the target characters were converted into semantic vectors and input into the semantic classification model; the model calculated that the similarity between the target characters and "report" was 0.85, the similarity with "contract" was 0.60, and the similarity with "invoice" and "resume" was less than 0.3; since "report" had the highest similarity and exceeded the threshold of 0.7, the document type was finally determined to be "report".

[0078] This embodiment effectively removes meaningless interference information by filtering target characters through preset rules, focusing on the core business attributes of the document, reducing the processing workload of subsequent semantic analysis, and improving the overall efficiency of document type recognition. By combining word embedding technology and semantic classification model to analyze the meaning of target characters, it breaks through the limitations of traditional keyword matching, accurately captures the semantic relationship of characters, and reduces the probability of misjudgment caused by documents containing multiple types of expressions. At the same time, it is suitable for many common document types such as contracts, invoices, reports, and resumes, and can be flexibly extended to other business document types, enhancing the versatility of the solution. By accurately determining the document type, it provides a reliable basis for subsequent matching of the corresponding business data structure file based on the document type and constructing targeted extraction questions, further ensuring the accuracy and smoothness of the entire document information entry process.

[0079] Based on any of the above embodiments, in Embodiment 3 of this application, referring to Figure 2 Step S20 includes:

[0080] Step S21: Extract each entity from the characters and the entity relationships between them.

[0081] In this embodiment, an entity refers to an information unit with a clear business orientation selected from the identified characters of the document to be processed, including but not limited to the name of an organization (such as "a certain construction engineering company"), time (such as "April 20, 2025"), value (such as "800,000 yuan"), project name (such as "XX Park Construction Project"), etc.; entity relationship refers to the correspondence between different entities formed through business logic or semantic association, such as the "subject affiliation" relationship between "Party A" and "a certain construction engineering company", the "value correspondence" relationship between "total contract amount" and "800,000 yuan", the "name matching" relationship between "project name" and "XX Park Construction Project", etc.

[0082] As an optional implementation, a large language model optimized based on the Transformer architecture (such as GPT-4Turbo) is invoked, and the built-in Named Entity Recognition (NER) module and Relation Extraction (RE) module are enabled. First, the characters of the document to be processed are input into the model in segments according to semantic integrity. The NER module annotates each entity and its category (e.g., "ORG" represents an organization, "DATE" represents a date, and "MONEY" represents a sum of money) through semantic analysis of the character sequence. Then, the RE module identifies the relationship type between entity pairs based on the positional association of entities in the characters and semantic logic, and stores the results in the form of a triple of "head entity-relation type-tail entity", such as (Party A, subject ownership, a certain construction engineering company) or (total contract amount, numerical correspondence, 800,000 yuan), ensuring that the entity and relationship extraction results can be directly used for subsequent association operations.

[0083] Step S22: Analyze the sentence structure of the sentence containing the entity, the paragraph logic of the paragraph containing the entity, and the overall structure of the document to be processed to construct the context of the entity.

[0084] In this embodiment, sentence structure refers to the grammatical composition of the statement containing the entity, including the subject-verb-object distribution and the position of modifiers (such as attributives and adverbs); paragraph logic refers to the semantic connection relationship between sentences within the paragraph containing the entity, such as causality, parallelism, and progression; the overall structure of the document to be processed refers to the document's chapter division, heading hierarchy (such as "1. Contract Subject" and "2. Transaction Terms"), and content arrangement order; contextual information refers to the set of information that reflects the semantic background of the entity after integrating the above sentence structure, paragraph logic, and overall document structure, which is used to clarify the specific meaning of the entity in a specific business scenario.

[0085] As an optional implementation, the spaCy syntactic analysis tool is used to parse the dependency tree of the sentence containing the entity, determining the entity's grammatical role in the sentence (e.g., "a certain construction engineering company" is the object in "Party A is a certain construction engineering company"). The subject terms of the paragraph containing the entity are extracted using the LDA (Latent Dirichlet Allocation) topic model (e.g., "contract subject", "rights and obligations", "liability for breach of contract") to determine whether the paragraph logic belongs to "subject definition", "clause explanation", or "dispute resolution". Simultaneously, the entity's position in the entire document is clarified by combining the document's heading level and chapter order (e.g., located under the "contract subject" chapter). Finally, the sentence's grammatical role, paragraph topic, and document location information are integrated to form a contextual description of the entity, for example, "'a certain construction engineering company' is located in the document's 'contract subject' chapter, and is the object in the sentence 'Party A is a certain construction engineering company,' with the paragraph topic 'clarifying the identities of the contracting parties'."

[0086] Step S23: Retrieve the historical text corresponding to the document type to identify the business intent corresponding to the entity.

[0087] In this embodiment, the historical text corresponding to the document type refers to the set of processed documents that are pre-stored by the system and are consistent with the current document type to be processed (such as contracts and invoices). These texts contain common business scenarios, terminology usage habits, and entity function positioning of this type of document. Business intent refers to the core role that an entity plays in the business process of a specific document type. For example, the business intent of "contract amount" in a contract document is to "define the total transaction amount", and the business intent of "tax amount" in an invoice document is to "record the amount of tax payable".

[0088] As an optional implementation, based on the currently determined document type (such as "construction project contract"), historical document fragments with a similarity higher than a preset threshold (such as 0.8) are retrieved from the historical text library. These historical fragments, along with character fragments containing the target entity in the current document to be processed, are input into a large language model. The model summarizes the typical business function of the target entity by comparing and analyzing the usage scenarios and functional descriptions of similar entities in the historical fragments. For example, for the entity "800,000 yuan", combined with the statement in the historical text of the construction project contract that "the contract amount is used to clarify the total cost of the project", its business intent is identified as "defining the total transaction amount of the XX park construction project", and this intent is bound to the entity.

[0089] Step S24: Determine the contextual relationship of the entity within the paragraph based on the contextual information.

[0090] In this embodiment, contextual relationship refers to the semantic association between an entity and other entities, sentences, or paragraph topics within the same paragraph. Common association types include parallel relationships (such as "contract amount" and "payment method"), subordinate relationships (such as "a certain construction engineering company" and "Party A"), and causal relationships (such as "delay in construction period" and "penalty for breach of contract"). This relationship needs to be derived through semantic logic analysis in conjunction with the contextual context constructed in step S22, and is used to further clarify the entity's position and role in the paragraph.

[0091] As an optional implementation, based on the contextual information constructed in step S22, semantic role labeling (SRL) technology is used to identify the semantic roles (such as "agent", "patient", and "instrument") of entities in paragraph sentences. At the same time, discourse analysis tools are used to determine the connection relationship between sentences. For example, in a paragraph containing "Party A is a certain construction engineering company, responsible for the construction of the XX Park project, with a total contract amount of 800,000 yuan", the contextual information shows that "certain construction engineering company" and "Party A" have a subordinate relationship, "800,000 yuan" and "total contract amount" have a subordinate relationship, "certain construction engineering company" and "XX Park project" have a "responsible and being responsible" relationship, and "800,000 yuan" and "XX Park project" have a "amount and project" correspondence. These relationships are classified and recorded to form a list of contextual relationships of entities.

[0092] Step S25: Associate the entity relationship, business intent, context and context relationship corresponding to the entity as reference information for the entity.

[0093] In this embodiment, reference information refers to a structured information set formed by integrating the corresponding entity relationships, business intentions, contextual information, and contextual relationships with the entity as the core. This set needs to have a clear logical hierarchy to facilitate quick invocation and semantic matching in subsequent steps, and to provide comprehensive semantic support for the extraction of target fields.

[0094] This embodiment extracts entities and their relationships in stages, ensuring the accuracy of basic information and avoiding impacts on subsequent processes due to entity omissions or misjudgments of relationships. It constructs contextual information by combining sentence structure, paragraph logic, and the overall document structure, overcoming the limitations of traditional methods that rely solely on keywords to determine entity meaning, and more accurately reflecting the business background of entities. It calls upon historical texts of the same type to identify business intent, making the functional positioning of entities more aligned with actual business scenarios and reducing misjudgments that are detached from business needs. Based on the contextual information, it determines contextual relationships, further clarifying the semantic associations of entities within paragraphs, providing richer logical support for subsequent matching of business fields. Finally, it associates multi-dimensional information as reference information, forming a complete entity semantic archive. This lays a solid foundation for constructing extraction questions based on business data structure files and accurately extracting target fields, comprehensively improving the intelligence and accuracy of document information processing, while making the entire process more aligned with the actual business logic of enterprises and reducing the workload of subsequent manual proofreading.

[0095] Based on any of the above embodiments, the details of steps S30 and S40 in Embodiment 4 of this application are as follows:

[0096] Step S31: Map the business data structure file corresponding to the document type to the knowledge graph, and update the business data structure file according to the mapping information.

[0097] In this embodiment, a knowledge graph refers to a semantic network of a business domain built around the document type, including entities, entity attributes, relationships between entities, and business rules within the domain (e.g., a contract knowledge graph includes entities such as "contract," "Party A," and "amount," and relationships such as "contract-include-amount" and "Party A-sign-contract"). Mapping information refers to the correspondence between fields in the business data structure file and entities / attributes in the knowledge graph. For example, the "contract amount" field in DSL maps to the "transaction amount" attribute of the "contract" entity in the knowledge graph. Updating the business data structure file means supplementing the semantic associations of fields based on the mapping information (e.g., associating entity relationships and business rules in the knowledge graph) and improving the field definitions.

[0098] As an optional implementation, firstly, a domain knowledge graph matching the document type is constructed (e.g., a "knowledge graph of invoices" corresponding to invoice documents, containing entities such as "invoice," "seller," and "tax amount," as well as relationships such as "invoice-related-tax amount" and "seller-issuing-invoice," stored using the Neo4j graph database); then, through a field semantic matching algorithm (e.g., semantic similarity calculation based on Word2Vec), each field in the business data structure file is matched with the entity attributes in the knowledge graph to generate mapping information (e.g., the "seller name" field in the DSL maps to the "seller" attribute of the "invoice" entity, and the "tax amount" field maps to the "tax payable" attribute of the "invoice" entity); then, based on the mapping information, semantic descriptions and association rules for the fields are supplemented, for example, under the "tax amount" field, "the relationship between 'invoice-tax payable' in the association knowledge graph must satisfy the business rule 'tax amount = amount × tax rate'," completing the update of the business data structure file and ensuring that the fields not only contain basic format requirements but also have domain semantic associations.

[0099] Step S32: Construct an extraction problem based on the fields in the updated business data structure file.

[0100] In this embodiment, the updated business data structure file refers to a DSL file that has been supplemented with knowledge graph mapping information (field semantic associations, business rules); the extraction question refers to a natural language question constructed by combining the basic definition and semantic association of the field, which can accurately point to the business meaning of the field and must reflect the semantic background and constraint rules of the field.

[0101] As an optional implementation, the updated business data structure file is parsed to extract the name, semantic description, and knowledge graph mapping information (such as the entity attributes and business rules associated with the field) of each field. Extraction questions are constructed using a rule of "interrogative words + field semantic description + semantic association constraints." For example, for the updated "tax amount" field (semantically described as "the tax payable corresponding to the invoice," and mapping information as "associated with the 'invoice-tax payable' relationship, satisfying 'tax amount = amount × tax rate'"), the extraction question is constructed as "What is the tax payable corresponding to the invoice that satisfies the rule 'tax amount = amount × tax rate'?". For the "seller name" field (semantically described as "the full name of the seller who issued the invoice," and mapping information as "associated with the 'invoice-seller' relationship"), the extraction question is constructed as "What is the full name of the seller who has an issuing relationship with the invoice?". After construction, the semantic fluency of the questions is verified to ensure that the questions both contain the core requirements of the fields and reflect the business logic of the knowledge graph association, avoiding ambiguity.

[0102] Step S40, combining the reference information, extracting target fields from the entity through the extraction question, including: Step S41, using the entity as a corpus, retrieving the answer field corresponding to the extraction question.

[0103] In this embodiment, an entity refers to a business-meaning information unit extracted from the characters of the document to be processed (such as "a certain electronics company" or "6500 yuan"); a corpus refers to a dataset formed by classifying and storing all entities according to semantic categories (such as storing "a certain electronics company" in the "seller" category and "6500 yuan" in the "tax amount" category); and the answer field refers to entities retrieved from the corpus that are semantically related to the extraction question, i.e., candidate entities that may meet the requirements of the extraction question.

[0104] As an optional implementation, all extracted entities are categorized by business type (e.g., "seller," "amount," "tax," "date") to construct a structured corpus, storing the corresponding entity and entity ID under each category. The BM25 retrieval algorithm (a word frequency-based retrieval model) is used to segment the extraction question (e.g., "What is the tax payable corresponding to the invoice that satisfies the rule 'tax amount = amount × tax rate'?" is segmented into "invoice," "tax amount," "amount," "tax rate," and "tax payable"). The segmentation results are used as search keywords to match semantically related entities in the corpus. For example, searching for the keywords "tax amount" and "tax payable" retrieves entities such as "6500 yuan" and "5000 yuan" from the "tax amount" category in the corpus. These entities are used as the answer fields corresponding to the extraction question to initially filter out candidate results.

[0105] Step S42: Based on the reference information and the mapping information, filter the answer fields to determine the target fields whose similarity to the extraction question is greater than a first threshold.

[0106] In this embodiment, the mapping information refers to the correspondence between the fields of the business data structure file and the knowledge graph; the first threshold refers to the preset semantic similarity judgment standard (such as 0.8, based on cosine similarity calculation), which is used to filter out the answer fields with high semantic matching degree with the extraction question; the target field refers to the entity that, after filtering, has a similarity to the extraction question exceeding the first threshold and meets the business requirements.

[0107] As an optional implementation, the following steps are first taken: First, the reference information corresponding to the answer field is obtained (e.g., the reference information for "6500 yuan" includes "business intent: record the tax payable on the invoice" and "contextual context: located under the 'tax amount' column of the invoice, the amount is 50000 yuan, and the tax rate is 13%) and the mapping information from step S31 is obtained (e.g., the "tax amount" field is mapped to the knowledge graph "invoice-tax payable" relationship, satisfying "tax amount = amount × tax rate"). Then, using a semantic similarity calculation model (e.g., a sentence similarity model based on BERT), the reference information and mapping information of each answer field are compared with the extracted question. Semantic matching is performed, for example, calculating the similarity between the reference information of "6500 yuan" ("tax payable", "amount 50000 yuan × tax rate 13% = 6500 yuan") and the extraction question ("tax payable that satisfies 'tax amount = amount × tax rate'"), and obtaining a similarity value of 0.92; finally, the similarity value is compared with the first threshold (0.8). "6500 yuan" has a similarity greater than the threshold and is determined to be the target field corresponding to the "tax amount" field; if the similarity of a certain answer field (such as "5000 yuan") is 0.65, which is lower than the threshold, the candidate is excluded to ensure the accuracy of the target field.

[0108] This embodiment maps and updates business data structure files to a knowledge graph, ensuring that fields not only include basic format requirements but also incorporate domain semantic associations and business rules. This improves the definition dimensions of fields and avoids inaccurate extraction question construction due to limited field information. Extraction questions are constructed based on the updated files, ensuring they address core field requirements and reflect business logic, reducing deviations in extraction direction. Entities are used as a corpus to retrieve answer fields, quickly narrowing the candidate pool and improving extraction efficiency. Answer fields are filtered using reference and mapping information, and similarity thresholds ensure a high degree of match between target fields and extraction questions, reducing misjudgments caused by candidate field interference. The overall process, through semantic association and multi-dimensional information filtering using the knowledge graph, further enhances the accuracy of extraction questions and target fields, making the matching between business data structure files and entity extraction more aligned with domain business logic. This reduces subsequent manual verification costs and improves the reliability and intelligence of document information entry.

[0109] Based on any of the above embodiments, in Embodiment 5 of this application, referring to Figure 3 Step S40 includes:

[0110] Step A41: Using the entity as a corpus, retrieve the answer field corresponding to the extraction question.

[0111] In this embodiment, an entity refers to an information unit with clear business significance extracted from the characters identified in the document to be processed, such as "a certain trading company", "500,000 yuan" and "June 10, 2025" in a contract document, and "invoice number 01234567" and "13% tax rate" in a bill document; the corpus refers to a structured dataset formed by classifying and storing all entities according to business categories (such as "contract subject", "contract amount", "signing date", "invoice number" and "tax rate"). Each category records the specific content of the entity and its corresponding entity identifier; the answer field refers to the entity retrieved from the corpus that is semantically related to the extraction question, that is, the set of candidate entities that initially meet the requirements of the extraction question, which needs to be further filtered to be determined as the target field.

[0112] As an optional implementation method, all extracted entities are first labeled with business categories. The labeling is based on the semantic attributes of the entities and the business requirements corresponding to the document type (e.g., in contract documents, "a certain trading company" is labeled as the "contract subject" category, and "500,000 yuan" is labeled as the "contract amount" category). The labeled entities are then organized by category to construct a structured corpus. Each entry in the corpus contains "entity content - category label - entity identifier". Next, the BM25 retrieval algorithm (a retrieval model based on word frequency statistics and document similarity) is used to perform word segmentation on the extraction question. For example, for the extraction question "What is the total amount involved in the contract?", word segmentation yields keywords such as "contract", "total amount", and "value". Then, using these keywords as search conditions, entities with the same or similar semantics are matched in the corpus. For example, searching for the keywords "total amount" and "value" matches entities such as "500,000 yuan" and "200,000 yuan" from the "contract amount" category. These entities are used as the answer fields corresponding to the extraction question, completing the initial screening of candidate entities and narrowing down the scope of subsequent processing.

[0113] Step A42: Filter the answer fields based on the reference information to determine the target fields whose similarity to the extraction question is greater than a second threshold.

[0114] In this embodiment, the second threshold refers to a preset semantic similarity judgment standard (such as 0.85, calculated based on cosine similarity or BERT sentence similarity model), which is used to distinguish the degree of matching between the answer field and the extraction question; the target field refers to the entity that, after screening, has a semantic similarity to the extraction question that exceeds the second threshold and meets the business requirements, and is the structured data that needs to be entered into the business system in the end.

[0115] As an optional implementation, the reference information corresponding to each answer field is first obtained. For example, the reference information for the answer field "500,000 yuan" includes "Entity relationship: numerical attribution relationship with 'total contract amount'; Business intent: defining the total transaction amount of the contract; Context: located in the 'Transaction Terms' section of the contract, in the sentence 'The total contract amount is 500,000 yuan'". Then, a BERT-based sentence similarity calculation model is called to semantically match the extracted question with the reference information of the answer field—the extracted question "What is the total amount involved in the contract?" is matched with the reference information of "500,000 yuan". The model analyzes the semantic relationship between the two (such as the semantic consistency between "total amount" and "contract total amount", and the attribute matching between "numerical value" and "500,000 yuan") and outputs a similarity value of 0.92. Finally, the similarity value is compared with the second threshold (0.85). "500,000 yuan" has a similarity greater than the threshold and is determined to be the target field corresponding to "contract amount". If the reference information of a certain answer field (such as "200,000 yuan") shows that it is associated with "prepayment amount" and has a similarity of 0.68 with the extraction question, which is lower than the second threshold, the candidate entity is excluded to ensure the accuracy of the target field.

[0116] This embodiment quickly narrows down the range of candidate entities corresponding to the extraction question by constructing entities into a structured corpus and retrieving answer fields, avoiding indiscriminate processing of all entities and improving the initial efficiency of target field extraction. When filtering answer fields in conjunction with reference information, it relies on the semantic background and business relevance of entities for matching, breaking through the limitations of traditional methods that only rely on superficial keyword matching, and can more accurately identify the fit between answer fields and extraction questions. Through similarity judgment based on a second threshold, candidate entities that do not meet the requirements are further filtered, reducing misjudgments caused by candidate interference and ensuring the accuracy of target fields. The overall process simplifies the candidate entity screening process and ensures the reliability of extraction results through multi-dimensional semantic matching, effectively reducing the workload of subsequent manual proofreading and improving the smoothness and intelligence of document information entry processes.

[0117] Based on any of the above embodiments, in Embodiment Six of this application, after step S40, the following is included:

[0118] Step S61: Verify the target field according to the business data structure specification associated with the business data structure file.

[0119] In this embodiment, the business data structure specification refers to a more detailed set of business verification rules associated with the business data structure file, covering requirements such as data format, numerical range, logical correlation, and business legality (e.g., in contract-related specifications, "the signing date must be earlier than the effective date" and "the contract amount must be greater than 0"; in invoice-related specifications, "the invoice date must conform to the YYYY-MM-DD format" and "tax amount = amount × tax rate"). The target field refers to the structured entity extracted in step S40 and intended to be entered into the business system. Verifying the target field means checking whether the target field meets all preset rules according to the business data structure specification and determining whether it conforms to the entry standards of the business system.

[0120] As an optional implementation, the system pre-establishes a "Business Data Structure File-Specification Mapping Table," binding the corresponding business data structure specification to each document type's business data structure file (e.g., contract-type DSLs are bound to "Contract Data Validation Specifications," and invoice-type DSLs are bound to "Invoice Data Validation Specifications"). Once the target field is determined, the system retrieves the corresponding business data structure specification from the mapping table and parses out all the validation rules that the target field must meet (e.g., the "Contract Amount" field must meet three rules: "Data type is numeric," "Number ≥ 0," and "Unit is Yuan"). Then, a rule engine (e.g., Drools) is used. The validation logic compares the actual value of the target field with each rule. For example, if the target field is "Contract Amount = -50000 yuan", the validation first checks if the data type is numeric (which meets the rule), then checks if the numeric value is ≥ 0 (-50000 < 0, which does not meet the rule), and finally determines that the target field fails the validation. If the target field "Contract Amount = 50000 yuan" meets all the rules, the validation is considered successful, and a "Validation Successful" result log is generated. If any rule is not met, the validation is considered unsuccessful, and the specific rule that failed (such as "Number must be ≥ 0") is recorded to provide direction for subsequent re-extraction.

[0121] Step S62: If the target field fails the validation, for the remaining entities, perform the step of combining the reference information and extracting the target field from the entity through the extraction question.

[0122] This embodiment verifies target fields according to business data structure specifications, deeply integrating business rules into the data extraction process. This ensures that target fields not only meet basic format requirements but also align with actual business logic, reducing the amount of data that does not meet business standards from entering the system and mitigating the risk of anomalies in subsequent business processes. If verification fails, the extraction steps are re-executed for the remaining entities, avoiding field omissions or errors due to single extraction deviations. This fully utilizes identified entity resources and improves entity utilization. The overall process forms a closed-loop mechanism of "extraction-verification-re-extraction," eliminating the need for frequent manual intervention to supplement or correct data. This improves the accuracy of target fields, reduces the workload of manual verification, ensures the standardization and reliability of subsequent business system data entry, and makes document information processing more aligned with enterprise business needs.

[0123] Based on any of the above embodiments, in Embodiment Seven of this application, after step S40, the following is included:

[0124] Step S71: Determine the API interface corresponding to the target field.

[0125] In this embodiment, the target field refers to an entity that meets the requirements of the business data structure file after the problem extraction and filtering, such as "contract amount" and "signing date" in contract documents, and "tax amount" and "total price including tax" in invoice documents; the API interface refers to the program interface provided by the business system or third-party service for obtaining or verifying information related to the target field, such as the contract ledger query interface within an enterprise, the invoice verification interface of the tax system, and the employee information query interface of the human resources system; determining the API interface corresponding to the target field means finding the interface address and interface type (such as GET, POST) that can be used to supplement or verify the information of the field based on the business meaning of the field and the interface mapping relationship preset by the system.

[0126] As an optional implementation, the system pre-maintains a "field-API interface mapping table," which records information such as the name of each field, the corresponding interface address, the request method, the list of required parameters, and the returned data structure. For example, the "contract amount" field corresponds to the contract ledger query interface (GET / contract / query), which requires the parameter "contractId" and returns JSON data containing fields such as "amount," "currency," and "taxRate." The "tax amount" field corresponds to the tax invoice verification interface (POST / tax / invoice / verify), which requires the parameters "invoiceCode" and "invoiceNumber" and returns JSON data containing fields such as "taxAmount," "taxRate," and "verifyStatus." Once the target field is determined, the system searches for a matching item in the mapping table based on the field name to determine the corresponding API interface and calling method.

[0127] Step S72: Construct a request message based on the target field and the parameter requirements of the API interface.

[0128] In this embodiment, the target field refers to the extracted entity and its attribute information; the parameter requirements of the API interface refer to the required parameters, optional parameters, data types, format constraints, etc., specified in the interface documentation; the request message refers to structured data that meets the interface requirements and can be directly used to call the API interface, usually in JSON format, containing all the parameters required by the interface.

[0129] As an optional implementation, the system first parses the API interface parameter requirements to determine the required and optional parameters. Then, it extracts the required parameter values ​​from the target fields and their reference information. For example, when calling the contract ledger query interface, it retrieves the "contractId" parameter value from the "contract number" target field and the "signDate" parameter value from the "signing date" target field. If a required parameter is missing from a target field, it infers it based on the reference information or context, or retrieves it from other extracted fields in the document. The parameter names and values ​​are then assembled into a JSON-formatted request message according to the structure required by the interface. Simultaneously, necessary request header information, such as Content-Type and Authorization tokens, is added according to the interface requirements to ensure that the request message conforms to the interface call specifications.

[0130] Step S73: Call the API interface to send the request message and parse the returned result to obtain the supplementary fields.

[0131] In this embodiment, calling the API interface refers to sending a request message to the interface address via HTTP / HTTPS protocol; the returned result refers to the structured data (usually in JSON or XML format) of the interface response, containing supplementary information related to the target field; supplementary fields refer to additional data extracted from the returned result that can be used to complete the target field, such as fields like "currency," "tax rate," and "verifyStatus" returned by the interface. As an optional implementation, the system uses an HTTP client library (such as Python's requests library or Java's OkHttp library) to send a request message to the API interface; if the interface call is successful (HTTP status code 200), the returned JSON data is received and parsed to extract the supplementary information related to the target field. The system extracts "currency," "tax rate," and "status" as supplementary fields; if the interface call fails (e.g., HTTP status code 404 or 500), the system retryes based on the error information or records an exception log to ensure the reliability of the supplementary field acquisition.

[0132] Step S74: Add the supplementary field as the target field.

[0133] In this embodiment, supplementary fields refer to additional information obtained through the API interface to complete the target field. Adding supplementary fields as target fields means associating or merging this additional information with the original target field to form a more complete target field data structure for subsequent use by the business system. As an optional implementation, the system integrates the original target field and supplementary fields into a composite data structure. For example, the original target field "Contract Amount = 500,000 yuan" and the supplementary fields include "currency = CNY", "taxRate = 0.13", and "status = active" are integrated to form: {"fieldName":"Contract Amount","value":500,000,"currency":"CNY","taxRate":0.13,"status":"active"}. Simultaneously, the integrated target field is updated in the system's result set and bound to the unique identifier of the document to be processed, ensuring that the business system can obtain complete field information during subsequent calls. This embodiment establishes a channel for data interaction between document information extraction and business systems by identifying the API interface corresponding to the target field, enabling cross-system data supplementation and verification. Request messages are constructed based on the target field and interface parameter requirements to ensure the accuracy and compliance of API calls. The interface is called, and the returned results are parsed to obtain supplementary fields, expanding the data dimensions of the target field and improving information completeness. These supplementary fields are added to the target field, forming richer structured data that is easily used directly by business systems. The overall process achieves seamless integration between document information and business systems, reducing repetitive manual data entry and querying across multiple systems, improving the automation and accuracy of data processing, and enhancing the credibility and usability of the extraction results.

[0134] Based on any of the above embodiments, in Embodiment 8 of this application, after step S40, the following is included:

[0135] Step S71: Assemble the target field into structured data according to the format specified in the business data structure file.

[0136] In this embodiment, the target field refers to the entity and its supplementary information that have passed the extraction, screening, and verification; the format specified in the business data structure file refers to the definition of the field name, type, arrangement order, nesting relationship, etc. in the file (e.g., JSONSchema or a similar DSL); structured data refers to the standardized data object that can be directly parsed and used by the business system after being assembled according to the format. As an optional implementation, the system parses the business data structure file to determine the name, data type (string, number, date, etc.), required fields, and hierarchical structure of each field; it maps the target fields to the corresponding data nodes according to these definitions, for example, mapping "contract amount" to the "contractAmount" node and "signing date" to the "signDate" node, and ensuring that the data type is consistent with the file requirements; for nested structures, such as "Party A information" containing subfields such as "name" and "unified social credit code", the corresponding target fields are filled into the corresponding subnodes; after assembly, JSON format structured data that meets the requirements of the business data structure file is generated, which is convenient for subsequent rendering as a form on the display interface.

[0137] Step S72: Display the structured form generated from the structured data on the display interface.

[0138] In this embodiment, the display interface refers to the interactive interface through which users process document information, such as a document processing page on a web platform or a client application interface. The structured form refers to a form component dynamically generated based on structured data, used for displaying and editing fields. It includes controls such as input boxes, dropdown lists, and date pickers, with each control corresponding to a field in the structured data. As an optional implementation, the system uses a front-end framework (such as Vue or React) to dynamically render the form based on the field definitions of the structured data. The name of each field is used as a label, and the field value is used as initial content to fill the corresponding control. A date picker is used for date type fields, numeric type fields are restricted to numeric input, and dropdown options are provided for enumeration type fields. Simultaneously, the form provides operation buttons such as edit, delete, and add notes for each field, allowing users to manually proofread or supplement the data. Finally, the structured form is displayed on the display interface in the form of cards or columns for easy viewing and operation by the user.

[0139] Step S73: In response to a click operation on the first field in the structured form, determine the second field corresponding to the first field in the document to be processed.

[0140] In this embodiment, the first field refers to a field clicked by the user in the structured form (e.g., "contract amount"); the second field refers to the entity or text fragment corresponding to this field in the original document to be processed; the click operation refers to the interactive event triggered by the user through a mouse or touch device; determining the correspondence means locating the original source position of the field in the document's recognized characters or layout structure based on the field's reference information (including context, entity relationships, etc.). As an optional implementation, when generating structured data, the system binds the reference information of its source entity to each field, including the entity's position information in the document (page number, coordinate range, line number, etc.) and the context; when the user clicks the first field in the structured form, the front end sends the unique identifier of the field to the back end; the back end searches for the corresponding reference information based on the identifier and extracts the document position information from it; if the document is in PDF or image format, the position information is used to locate the specific area of ​​the entity in the document; if the document is in text format, the corresponding sentence or paragraph is located; finally, the corresponding second field and its position in the document to be processed for the first field are determined.

[0141] Step S74: Highlight the second field.

[0142] In this embodiment, highlighting refers to visually enhancing the document preview interface by prominently displaying the second field, making it clearly distinguishable from other content and facilitating quick user confirmation of the field's accuracy. Common highlighting methods include highlighting the background color, using borders, flashing animations, and zooming in. As an optional implementation, the system draws a semi-transparent yellow highlight layer in the corresponding area of ​​the document preview component based on the location information of the second field, and draws a red border around the highlighted area. Simultaneously, a prompt box containing the field name and value pops up at the top or side of the interface, displaying a summary of the field's context. If the document has multiple pages, it automatically jumps to the page containing the field. For long text paragraphs, the viewport automatically scrolls to the location of the second field and briefly zooms in to ensure clear identification by the user. In addition, functions such as canceling highlighting and viewing multiple fields consecutively are provided to improve the user's proofreading efficiency. Exemplarily, the core idea of ​​this embodiment is: to use an AI model to deeply understand unstructured document content and combine it with the predefined table structure DSL (Domain-Specific Language) of the business system to automatically parse, extract, and structure document information, generating data that precisely matches the fields of the business system. Simultaneously, this method also allows AI to call external APIs as tools during processing for data verification or information supplementation, ultimately achieving one-click, intelligent assisted data entry. Defining the Business Data Structure (DSL): In the business system of the no-code platform, users define the data table structure to be entered through a visual interface, and the system converts it into a DSL. For example, in a contract management system, a form structure containing fields such as "Contract Name" (text), "Contract Amount" (number), "Signing Date" (date), and "Opponent Company" (text) can be defined. The no-code platform provides an intuitive graphical interface, allowing business users to define the data table structure through drag-and-drop, configuration, and other methods. This interface supports various field types (text, number, date, boolean, enumeration, related fields, etc.), field validation rules (such as NOT NULL, uniqueness, format validation, numerical range), and logical relationships between fields (such as conditional display, calculated fields). After the user completes the configuration in the visual interface, the system's built-in DSL generator converts these configurations into structured DSL definition files in real time or in batches. This DSL can use formats such as JSON, YAML, or XML, for example:

[0143] json

[0144] {

[0145] "entityName":"Contract Information",

[0146] "fields":[

[0147] {"name":"Contract Name","type":"text","required":true,"description":"Contract Title or Subject"},

[0148] {"name":"Contract Amount","type":"number","unit":"Yuan","min":0,"validation":"positive","description":"Total Amount Involved in the Contract"},

[0149] {"name":"Date of Signing","type":"date","format":"YYYY-MM-DD","description":"Date of Contract Signing"},

[0150] {"name":"The other party's company","type":"text","lookup_api":"company_info_api","description":"Name of the other party's company in the contract"}

[0151] ],

[0152] "relations":[

[0153] {"from":"Contract Amount","to":"Tax Rate","type":"Calculation","formula":"Contract Amount * Tax Rate"}]}

[0154] The generated DSL file is stored in the metadata management module and parsed by the DSL parser to form a data model that can be called by the AI ​​engine and business systems. This ensures that the AI ​​can accurately understand the structure, type, constraints, and business meaning of the target data when extracting information, providing strict specifications for subsequent accurate matching and structured output. Users upload one or more unstructured documents (such as scanned copies of contracts in PDF, Word, and JPG formats) to the system. The system supports users uploading unstructured documents in various formats, including but not limited to PDF (scanned and electronic versions), Word documents (.doc, .docx), Excel spreadsheets (.xls, .xlsx), and image files (.jpg, .png, .bmp, .tiff). This is achieved by integrating different file parsers and format conversion modules. Uploaded documents are encrypted and stored in a distributed file system (such as HDFS, OSS) or object storage service to ensure data security and high availability. The system generates a unique ID for each document and supports version management, making it convenient for users to trace and manage the document's historical changes. Users can upload documents through the front-end web interface, mobile application, or directly through the API interface. The upload service performs initial file type verification and size limits to prevent malicious file uploads. After receiving the document, the AI ​​engine in the system backend initiates a series of intelligent processing steps, which is one of the core technologies of this invention. Upon receiving the document, the AI ​​engine performs the following operations: image enhancement and orientation correction on the scanned document. For scanned documents or image-formatted documents, the system performs image enhancement processing, including noise reduction, tilt correction, and brightness / contrast adjustment, to improve image quality. Simultaneously, orientation correction is performed to ensure correct text orientation, laying the foundation for subsequent recognition. The OCR service is invoked to convert the document content into editable text. A high-performance OCR service is invoked to convert the image content in the document into editable and searchable text. This step transforms unstructured image information into machine-readable text data. The system can adapt to OCR services from multiple vendors. Advanced large-scale language models (LLMs), such as pre-trained models based on the Transformer architecture (e.g., BERT, GPT series, or their industry-customized versions), are used to perform deep semantic analysis on the text content recognized by OCR. Specifically, LLM, through its multi-layered self-attention mechanism and the knowledge gained from training on massive corpora, can: automatically identify named entities in text (such as names of people, places, organizations, dates, amounts, etc.) and the complex relationships between these entities (such as the "belongs to" relationship between "contract amount" and "500,000 yuan", and the "is" relationship between "Party A" and "a certain company"). It can also understand contextual information: LLM can capture the meaning of words in different contexts, for example, distinguishing between "contract effective date" and "contract signing date," even if they may be similar in the text.It constructs contextual understanding by analyzing sentence structure, paragraph logic, and the overall document structure, forming a semantic representation of the document. Capturing Business Intent: By training on a large number of industry documents, LLM can understand the implicit business intent and logic behind the document, such as identifying whether a clause is about "breach of contract" or "dispute resolution." This deep semantic understanding is the foundation for accurate information extraction. Contextual Relationships: Contextual relationships enable AI to handle the complexity and ambiguity of natural language, avoiding misjudgments caused by simple keyword matching. For example, in a contract, "Party A" may refer to different companies in different paragraphs. Through contextual understanding, LLM can ensure that the extracted "Party A name" always corresponds to the correct entity referred to in the current clause. It ensures the accuracy of AI information extraction and the rigor of business logic. Information Extraction and Matching Based on DSL: The AI ​​model determines the target information to be extracted and its structure based on the DSL (Domain-Specific Language) defined in step one. The DSL not only defines field names and data types but may also include semantic descriptions of fields, data format requirements, and mapping relationships with fields in the business system. Based on deep semantic analysis, AI models utilize the following techniques to achieve accurate matching and extraction of key information: Pattern Matching and Rule Engine: For well-defined fields with fixed patterns in the DSL (such as dates, phone numbers, and amounts), efficient matching can be achieved by combining regular expressions or preset rules. Question-Answering Information Extraction: Each field in the DSL is transformed into a "question" for the document (e.g., "What is the contract amount?", "What is the signing date?"), and then the LLM's question-answering capabilities are used to find the answers to the questions in the document. This approach can flexibly handle the diversity of information expression in documents. Sequence Labeling: The information extraction task is transformed into a sequence labeling problem. The LLM labels each word in the text and determines whether it belongs to the value of a certain target field. For example, labeling "500,000 yuan" as "contract amount". This is usually achieved by adding a classification layer on top of the LLM. Knowledge Graph and Ontology Mapping: For more complex business scenarios, the DSL can be mapped to a knowledge graph or ontology of the business domain. When extracting information, the LLM not only identifies the text but also associates it with concepts in the knowledge graph, ensuring the semantic accuracy and consistency of the extracted information. Dynamic Adjustment and Iteration: During the extraction process, the AI ​​performs preliminary verification of the extraction results based on the DSL definition. If it finds that the results do not conform to the DSL specifications (such as data type mismatch or formatting errors), the AI ​​will attempt to find a more suitable match in the document or mark it as requiring manual review. For example, if the DSL defines "contract amount" as a number, but the AI ​​extracts "not agreed upon," it will mark it as abnormal.

[0155] For example, if the DSL defines a "Contract Amount" field, the AI ​​will search the document and identify expressions such as "Total Contract Amount: ¥500,000.00 yuan," extracting the "500,000.00" and associating it with the "Contract Amount" field. The AI's extraction capabilities are not limited to exact matching; it can also extract necessary information from complex or non-standard expressions through contextual reasoning and pattern recognition. Through the aforementioned detailed semantic analysis and information extraction methods, this invention can achieve efficient, accurate, and intelligent structured transformation of unstructured document data, laying a solid foundation for subsequent assisted data entry.

[0156] Data Processing via API Tools: During information extraction, AI can call external APIs according to preset rules. For example, after extracting the name of the "other company," it automatically calls the enterprise business information query API to obtain the company's unified social credit code and fills it into the corresponding system field, completing data supplementation and verification. API Tool Registration and Management: The platform provides an API tool registration interface, allowing users or developers to register external APIs (such as enterprise business information query, bank card number verification, address resolution, etc.) as tools that AI can call. Registration requires providing API interface specifications (URL, request method, parameters, return format), function description, and calling conditions. AI Tool Call Decision: During information extraction, the AI ​​model (especially LLM) will intelligently determine whether to call external APIs for data supplementation or verification based on the preset DSL definition, the extracted information content, and the function description of the registered API tools. For example, if the DSL defines a "other company" field and this field is configured with `lookup_api:"company_info_api"`, the AI ​​will trigger a call to `company_info_api` after extracting the company name. Parameter Mapping and Request Construction: Based on the API's parameter requirements, the AI ​​maps extracted relevant information (such as company name) to API request parameters and automatically constructs the API request. For example, the extracted "XX Technology Co., Ltd." is used as the `companyName` parameter in `company_info_api`. API Call and Result Processing: The system calls external APIs and obtains the returned results. The AI ​​parses the JSON or XML data returned by the API, extracts the required information (such as unified social credit code, registered address, etc.), and populates it into the corresponding DSL fields. If the API returns an error or information is not found, the AI ​​will handle it according to a preset strategy (such as marking it as an anomaly, trying other APIs, or prompting the user to manually supplement the information). Data Validation and Backfilling: API call results are not only used to supplement information but also for data validation. For example, the validity of a card number can be verified by calling a bank card validation API. Validated data will be backfilled into structured data, improving data accuracy and completeness. The entire process is automated and configurable, greatly enhancing the flexibility and intelligence of data processing. Generating and Previewing Structured Data: The AI ​​generates structured data records according to the DSL format from all extracted and processed information. The system presents this record on the user interface, displaying it side-by-side with the original document for quick preview and proofreading. Data structuring engine: The AI ​​engine takes the information extracted, processed, and verified in step 3 and, according to the DSL pattern defined in step 1, rigorously formats and assembles it through the data structuring engine.This engine is responsible for accurately mapping information from unstructured text to each field defined in the DSL, ensuring compliance with data types, formats, and constraints. For example, it converts the identified "¥500,000.00" into the value "500,000.00" for the "contract amount" field of type "number" defined in the DSL. Front-end data binding and rendering: The system transmits the structured data to the front-end application via API. The front-end uses a responsive framework for data binding and interface rendering. The user interface clearly displays the extracted structured data in the form of forms or tables, with each field corresponding to the DSL definition. Visual proofreading and highlighting: To facilitate quick previewing and proofreading, the system provides the following visualization functions: Side-by-side display of original text and structured data: The original document (PDF, images, etc.) and the extracted structured data form are displayed side-by-side on the same interface for easy comparison. Field-level highlighting and positioning: When a user clicks on a field in the structured data form, the system automatically highlights the corresponding original text location of that field in the original document, achieving bidirectional positioning and greatly improving proofreading efficiency. Confidence Score and Anomaly Marking: The AI ​​outputs a confidence score for each extracted field. For fields with low confidence scores, or those marked as anomalies in steps 3 and 4 (such as format mismatch or API validation failure), the system will provide prominent visual markers (such as red borders or warning icons) to remind users to pay close attention and verify them. Editability: All structured data fields in the preview interface are editable. Users can directly modify inaccurate or missing information to ensure the accuracy of the final data. Confirmation and System Entry: After confirming that the preview data is correct, the user clicks the "Confirm" button. The structured data is then officially written into the business system's database, completing the entire auxiliary data entry process.

[0157] This embodiment assembles target fields into structured data conforming to the business data structure file format, ensuring that the data can be directly used by the business system and improving data integrability. It dynamically generates structured forms on the display interface, providing users with an intuitive and interactive way to display and edit data, facilitating manual proofreading and supplementation. By clicking on form fields, users can quickly locate and highlight their corresponding positions in the original document, achieving a two-way association between form data and document content, significantly improving the efficiency and accuracy of user proofreading. The overall process enhances the system's interactivity and visualization capabilities, reducing the workload of repeatedly switching between forms and documents, making document information processing more intuitive, efficient, and reliable.

[0158] This application provides a document information input device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform the document information input method in the first embodiment described above.

[0159] The following is for reference. Figure 4 The diagram illustrates a structural schematic of a document information input device suitable for implementing embodiments of this application. The document information input device in these embodiments may include, but is not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, personal digital assistants (PDAs), tablets, and in-vehicle terminals, as well as fixed terminals such as digital TVs and desktop computers. Figure 4 The document information entry device shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0160] like Figure 4 As shown, the document information entry device may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 1002 or a program loaded from a storage device 1003 into a random access memory (RAM) 1004. The RAM 1004 also stores various programs and data required for the operation of the document information entry device. The processing unit 1001, the read-only memory 1002, and the RAM 1004 are interconnected via a bus 1005. An input / output (I / O) interface 1006 is also connected to the bus. Typically, the following systems can be connected to I / O interface 1006: input devices 1007 including, for example, touchscreens, touchpads, keyboards, mice, image sensors, microphones, accelerometers, gyroscopes, etc.; output devices 1008 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 1003 including, for example, magnetic tapes, hard disks, etc.; and communication devices 1009. Communication device 1009 allows the document input device to communicate wirelessly or wiredly with other devices to exchange data. Although document input devices with various systems are shown in the figures, it should be understood that it is not required to implement or possess all of the systems shown. More or fewer systems may be implemented alternatively.

[0161] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from ROM 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0162] The document information input device provided in this application, employing the document information input method described in the above embodiments, can solve the technical problem that the text extracted using optical character recognition tools is fragmented and cannot be accurately matched with specific fields of the business system. Compared with the prior art, the beneficial effects of the document information input device provided in this application are the same as those of the document information input device provided in the above embodiments, and other technical features of this document information input device are the same as those disclosed in the method of the previous embodiment, and will not be repeated here.

[0163] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

[0164] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0165] This application provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, which are used to execute the document information entry method in the above embodiments.

[0166] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), flash memory, optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, system, or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, radio frequency (RF), or any suitable combination thereof.

[0167] The aforementioned computer-readable storage medium may be included in the document information entry device; or it may exist independently and not be assembled into the document information entry device.

[0168] The aforementioned computer-readable storage medium carries one or more programs. When these programs are executed by the document information input device, the document information input device: determines the document type based on characters identified in the document to be processed; calls a large language model to extract entities from the characters, and associates the entity relationships, business intents, contextual information, and contextual relationships corresponding to the entities as reference information for the entities; constructs an extraction problem based on fields in the business data structure file corresponding to the document type; and extracts target fields from the entities by combining the reference information and the extraction problem.

[0169] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, as well as conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0170] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0171] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0172] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., a computer program) for executing the above-described document information entry method. This solves the technical problem that the text extracted using optical character recognition tools is fragmented and cannot be accurately matched with specific fields of a business system. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as those of the document information entry method provided in the above embodiments, and will not be elaborated upon here.

[0173] This application provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the document information entry method described above.

[0174] The computer program product provided in this application can solve the technical problem that the text extracted using optical character recognition tools is fragmented and cannot be accurately matched with specific fields of a business system. Compared with the prior art, the beneficial effects of the computer program product provided in this application are the same as those of the document information entry method provided in the above embodiments, and will not be repeated here.

[0175] The above are merely preferred embodiments of this application and do not limit the patent scope of this application. Any equivalent structural or procedural transformations made using the content of this application's specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent scope of this application.

Claims

1. A document information entry method, characterized in that, The document information entry method includes: Target characters are filtered from the characters identified in the document to be processed using preset rules. Based on the meaning of the target character, the document type is determined, wherein the document type is at least one of contract, invoice, report, and resume; The large language model is invoked to extract entities from the characters, and the entity relationships, business intents, contextual contexts, and contextual relationships corresponding to the entities are associated as reference information for the entities. The extraction problem is constructed based on the fields in the business data structure file corresponding to the document type. Based on the reference information, the target field is extracted from the entity using the extraction question. The steps for constructing the extraction problem based on the fields in the business data structure file corresponding to the document type include: Construct a knowledge graph that matches the document type; The semantic matching algorithm is used to match each field in the business data structure file with the entity attributes in the knowledge graph to generate mapping information. Based on the mapping information, supplement the semantic descriptions and association rules of the fields to complete the update of the business data structure file; The updated business data structure file is parsed to extract the name, semantic description, and knowledge graph mapping information of each field; extraction questions are constructed using rules of interrogative words + field semantic descriptions + semantic association constraints. The step of extracting the target field from the entity by combining the reference information and the extraction question includes: Using the entity as a corpus, retrieve the answer field corresponding to the extraction question; Based on the reference information and the mapping information, the answer fields are filtered to determine the target fields whose similarity to the extraction question is greater than a first threshold. Determine the API interface corresponding to the target field; Construct a request message based on the target field and the parameter requirements of the API interface; Call the API interface to send the request message, and parse the returned result to obtain the supplementary fields; Add the supplementary field as the target field.

2. The document information entry method as described in claim 1, characterized in that, The step of calling a large language model to extract entities from the characters and associating the entity's corresponding entity relationship, business intent, contextual context, and contextual relationships as reference information for the entity includes: Extract each entity from the characters, and the entity relationships between them; Analyze the sentence structure of the sentence containing the entity, the paragraph logic of the paragraph containing the entity, and the overall structure of the document to be processed to construct the context of the entity. The historical text corresponding to the document type is invoked to identify the business intent corresponding to the entity. The contextual relationship of the entity within the paragraph is determined based on the given context. The entity relationship, business intent, context, and contextual relationship corresponding to the entity are associated as reference information for the entity.

3. The document information entry method as described in claim 1, characterized in that, The step of extracting the target field from the entity by combining the reference information and the extraction question includes: Using the entity as a corpus, retrieve the answer field corresponding to the extraction question; Based on the reference information, the answer fields are filtered to determine the target fields whose similarity to the extraction question is greater than a second threshold.

4. The document information entry method as described in claim 1, characterized in that, Following the step of extracting the target field from the entity by combining the reference information and the extraction question, the following steps are included: The target field is validated according to the business data structure specification associated with the business data structure file; If the target field fails validation, for the remaining entities, the step of extracting the target field from the entities by combining the reference information and using the extraction question is performed.

5. The document information entry method as described in claim 1 or 4, characterized in that, Following the step of extracting the target field from the entity by combining the reference information and the extraction question, the following steps are included: The target fields are assembled into structured data according to the format specified in the business data structure file; The structured form generated from the structured data is displayed on the interface. In response to a click operation on a first field in the structured form, a second field corresponding to the first field in the document to be processed is determined; Highlight the second field.

6. A document information input device, characterized in that, The document information input device includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the document information input method as described in any one of claims 1 to 5.

7. A storage medium, characterized in that, The storage medium is a computer-readable storage medium, and a computer program is stored on the computer-readable storage medium. When the computer program is executed by a processor, it implements the steps of the document information entry method as described in any one of claims 1 to 5.

Images