Bidding file generation method and device and related equipment

Abstract

The invention provides a bidding file generation method and device and related equipment. The bidding file generation method comprises the following steps: segmenting a bidding file into a plurality of information units with complete semantics; generating a plurality of context embedding vectors in one-to-one correspondence with the plurality of information units, wherein the context embedding vectors comprise specific semantics of the corresponding information units in the context of the bid inviting file; respectively carrying out semantic feature extraction on the plurality of context embedding vectors to obtain a title hierarchical tree of the bid invitation file; performing dependency relationship calculation on the plurality of context embedding vectors to obtain a dependency relationship among the information units, the dependency relationship indicating association types among the information units, and the association types including anaphora association, dependency association and reference association; and generating a bidding file according to the title hierarchy tree and the dependency relationship. In this way, the accuracy of the generated bidding document can be improved.

Description

Technical Field

[0001] This disclosure relates to the field of data processing technology, and in particular to a method, apparatus and related equipment for generating tender documents. Background Technology

[0002] With the continuous development of society, bidding and tendering are becoming increasingly common in social production activities. Currently, in order to improve the accuracy of generated tender documents, bidding documents can be generated based on keyword or rule matching techniques. However, when the content of the tender documents is complex, the accuracy of the tender documents generated by the above-mentioned keyword or rule matching techniques is low. It can be seen that the accuracy of the currently generated tender documents is poor. Summary of the Invention

[0003] This disclosure provides a method, apparatus, and related equipment for generating tender documents to solve the problem of poor accuracy in the generated tender documents.

[0004] To solve the above problems, this disclosure is implemented as follows:

[0005] Firstly, this disclosure provides a method for generating tender documents, including:

[0006] The tender document is divided into multiple semantically complete information units;

[0007] Generate multiple context embedding vectors that correspond one-to-one with multiple information units. The context embedding vectors contain the specific semantics of the corresponding information units in the context of the tender document.

[0008] Semantic features are extracted from multiple context embedding vectors to obtain the title hierarchy tree of the tender document;

[0009] Dependency calculation is performed on multiple context embedding vectors to obtain the dependency relationships between information units. The dependency relationships indicate the association types between information units, including referential association, dependency association, and reference association.

[0010] The tender document is generated based on the title hierarchy tree and dependencies.

[0011] Secondly, this disclosure provides a tender document generation device, including:

[0012] The segmentation module is used to segment the tender document into multiple semantically complete information units;

[0013] The vector generation module is used to generate multiple context embedding vectors that correspond one-to-one with multiple information units. The context embedding vectors contain the specific semantics of the corresponding information unit in the context of the tender document.

[0014] The extraction module is used to extract semantic features from multiple context embedding vectors to obtain the title hierarchy tree of the tender document.

[0015] The computation module is used to perform dependency calculations on multiple context embedding vectors to obtain the dependency relationships between information units. The dependency relationships indicate the association relationships between information units, including referential associations, dependency associations, and reference associations.

[0016] The generation module is used to generate tender documents based on the title hierarchy tree and dependencies.

[0017] Thirdly, this disclosure also provides an electronic device, including: a memory, a processor, and a program stored in the memory and executable on the processor; the processor is configured to read the program in the memory to implement the steps of the method disclosed in the first aspect above.

[0018] Fourthly, this disclosure also provides a readable storage medium for storing a program that, when executed by a processor, implements the steps of the method disclosed in the first aspect above.

[0019] Fifthly, this disclosure also provides a computer program product, including computer instructions that, when executed by a processor, implement the steps of the method disclosed in the first aspect above. Attached Figure Description

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

[0021] Figure 1A This is one of the flowcharts illustrating the tender document generation method provided in this embodiment of the disclosure;

[0022] Figure 1B This is a second schematic flowchart of the tender document generation method provided in this embodiment of the disclosure;

[0023] Figure 1C This is the third flowchart illustrating the tender document generation method provided in this embodiment of the disclosure;

[0024] Figure 1D This is the fourth flowchart illustrating the tender document generation method provided in this embodiment of the disclosure;

[0025] Figure 1E This is the fifth flowchart illustrating the tender document generation method provided in this embodiment of the disclosure;

[0026] Figure 1F This is the sixth flowchart illustrating the tender document generation method provided in this embodiment of the disclosure;

[0027] Figure 1G This is the seventh flowchart illustrating the tender document generation method provided in this embodiment of the disclosure;

[0028] Figure 1H This is the eighth flowchart illustrating the tender document generation method provided in this embodiment of the disclosure;

[0029] Figure 1I This is the ninth flowchart illustrating the tender document generation method provided in this embodiment of the disclosure;

[0030] Figure 2A This is a flowchart illustrating the intelligent parsing and structured modeling process in the tender document generation method provided in this embodiment of the disclosure;

[0031] Figure 2B This is a schematic diagram of the process of binding content generation and traceability in the tender document generation method provided in this embodiment of the disclosure;

[0032] Figure 2C This is a flowchart illustrating the multi-dimensional consistency and risk check process in the tender document generation method provided in this embodiment.

[0033] Figure 2D This is a flowchart illustrating the intelligent recommendation and pre-scoring process in the tender document generation method provided in this embodiment of the disclosure;

[0034] Figure 3 This is a schematic diagram of the structure of the tender document generation device provided in the embodiments of this disclosure;

[0035] Figure 4 This is a schematic diagram of the structure of the electronic device provided in the embodiments of this disclosure. Detailed Implementation

[0036] The technical solutions of the embodiments of this disclosure will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this disclosure. Based on the embodiments of this disclosure, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this disclosure.

[0037] The terms "first," "second," etc., used in the embodiments of this disclosure are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or device that includes a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to these processes, methods, products, or devices. Additionally, the use of "and / or" in this disclosure indicates at least one of the connected objects, such as A and / or B and / or C, representing seven possibilities: including A alone, B alone, C alone, and the presence of both A and B, both B and C, both A and C, and the presence of A, B, and C.

[0038] Please see Figure 1A , Figure 1A This is a flowchart illustrating the tender document generation method provided in this embodiment. Figure 1A The method for generating tender documents shown can be performed by electronic devices.

[0039] like Figure 1A As shown, the method for generating tender documents may include the following steps:

[0040] Step 200: Divide the tender document into multiple semantically complete information units.

[0041] Optionally, a combination of Large Language Model (LLM) and semantic parsing algorithms can be used to divide the tender document into multiple semantically complete information units. This can result in higher integrity of the divided information units and reduce the occurrence of dividing a semantically complete paragraph into multiple information units.

[0042] Alternatively, in scenarios where computing power is limited or offline deployment is required, a lightweight semantic parsing model based on the Transformer architecture can be used to divide the tender document into multiple semantically complete information units. Such lightweight semantic parsing models may include DistilBERT, ERNIE-Tiny, and other models.

[0043] These models, through knowledge distillation and task fine-tuning, can significantly reduce inference resource consumption while preserving contextual understanding capabilities.

[0044] Optionally, the large language model can be a pre-trained model used to segment tender documents; alternatively, the large language model can be an acquired general model, that is, the large language model is open source and is used to segment tender documents.

[0045] The specific type of semantic parsing algorithm is not limited here. Optionally, semantic parsing algorithms may include general natural language processing (NLP) algorithms, etc.

[0046] Semantic completeness can be understood as follows: the meaning expressed in an information unit must be complete, accurate, and without omissions. For example, the content in a tender document includes "an object A of XXX and an object B of YYY". If the above content is divided into information unit A, which contains "an object A of XXX", and information unit B, which contains "an object B of YYY", then information unit A and information unit B can be considered semantically complete information units. If the above content is divided into information unit A1, which contains "an object A", information unit A2, which contains "an object B of YYY", then information unit A1 and information unit A2 can be considered semantically incomplete information units, while information unit B is a semantically complete information unit.

[0047] Optionally, when generating multiple information units, a sparse inverted index and a dense vector can be constructed for each information unit for subsequent retrieval and location. For example, the sparse inverted index can be understood as an index constructed based on the BM25 algorithm, while the dense vector can be understood as a domain fine-tuning sentence vector.

[0048] Step 400: Generate multiple context embedding vectors that correspond one-to-one with multiple information units. The context embedding vectors contain the specific semantics of the corresponding information unit in the context of the tender document.

[0049] Optionally, the specific method for generating multiple context embedding vectors is not limited here. Optionally, multiple context embedding vectors can be generated by semantic embedding technology. Alternatively, the above-mentioned multiple context embedding vectors can also be generated by a pre-built embedding vector generation model. The above-mentioned embedding vector generation model can be a model trained using bidding sample files, and the above-mentioned embedding vector generation model is a model used to generate context embedding vectors.

[0050] The context embedding vector contains the specific semantics of the corresponding information unit in the context of the tender document. It can be understood as a more detailed semantic explanation of the corresponding information unit in the context of the tender document, which may include usage scenarios, functions, semantic content, and explanatory information of semantic content.

[0051] Step 600: Extract semantic features from multiple context embedding vectors to obtain the title hierarchy tree of the tender document.

[0052] The heading hierarchy tree can be used to represent the structural relationship between chapter topics, main headings, subheadings, etc. in the entire tender document. For example, the heading hierarchy tree can be understood as a table of contents, and the table of contents can clearly show the structural relationship between chapter topics, main headings, subheadings, etc.

[0053] It should be noted that the title hierarchy tree of the above-mentioned tender documents can be referred to as the heading_tree.

[0054] Step 800: Calculate the dependency relationship between multiple context embedding vectors to obtain the dependency relationship between information units. The dependency relationship indicates the association type between information units. The association type includes referential association, dependency association, and reference association.

[0055] Since the tender document is a single, unified document, the information within it may be interconnected. For example, information unit B1, which states "an A of XXX," and information unit B2, which states "when XXX is xxx, A can perform action c," clearly demonstrate that the content of information unit B2 is a further explanation of the content of information unit B1. In other words, the content of information unit B2 depends on the content of information unit B1, and there is a clear dependency between them. Furthermore, there are various types of dependency relationships, such as referential relationships, dependent relationships, and referential relationships. Therefore, by calculating the dependency relationships between information units, the structural relationships between multiple information units can be more clearly defined.

[0056] In this context, referential association can be understood as the content of one information unit being used to refer to the content of another information unit; dependency association can be understood as the content of one information unit depending on the existence of the content of another information unit; and referential association can be understood as the content of one information unit needing to reference the content of another information unit. For example, referential association can be seen in the following context: "See Article ××, see this article, or see the following situations."

[0057] Optionally, the above-mentioned dependencies can also be represented by a constructed Clause Graph, where nodes in the Clause Graph are clauses or table items, and edges in the Clause Graph are references, conditions, or value dependencies. In this way, the Clause Graph can be used for subsequent consistency checks (i.e., verifying whether key information is consistent with the corresponding information unit) and generating constraints, thereby improving the efficiency of consistency checks and constraint generation.

[0058] Step 1000: Generate the tender document based on the title hierarchy tree and dependencies.

[0059] The specific method for generating the tender document based on the title hierarchy tree and dependencies is not limited here. Optionally, the distribution location of each information unit and the connection relationship between each information unit and other information units can be determined based on the title hierarchy tree and dependencies to generate the tender document.

[0060] In this embodiment, steps 200 to 1000 divide the tender document into multiple semantically complete information units. This strictly adheres to the semantic boundaries of the tender document, effectively avoiding semantic fragmentation or redundant overlap of information units, and ensuring that each extracted information unit possesses independent and complete semantic connotations. Based on this, a context embedding vector corresponding to each information unit is generated. This context embedding vector fully carries the specific semantics of the corresponding information unit within the context of the tender document, and thanks to the semantic accuracy of the slice extraction, the semantic representation of the context embedding vector is more targeted and accurate. Furthermore, semantic features are extracted from multiple context embedding vectors to obtain a title hierarchy tree that clearly represents the themes and hierarchical structure of each chapter in the tender document. Simultaneously, dependency calculations are performed on multiple context embedding vectors to uncover the dependencies between information units. These dependencies clearly indicate the association types between information units. The semantic completeness of the information units brought about by the slice extraction further improves the accuracy of the title hierarchy tree construction and dependency calculation, ensuring that the extracted chapter themes, hierarchical relationships, and association types are highly relevant to the core requirements of the tender document. Then, the tender document is generated based on the title hierarchy tree and dependencies. This not only ensures that the generated tender document fully reproduces the chapter theme structure and title hierarchy logic of the tender document by leveraging the accurate title hierarchy tree, but also fully preserves the core relationships such as reference, dependence, and citation between information units by relying on accurate dependencies. This effectively avoids problems such as semantic misalignment, structural confusion, broken connections, or omission of core requirements in the tender document caused by information extraction deviations. It significantly improves the matching degree between the core requirements of the tender document and the tender document, ensuring that the generated tender document has high accuracy, compliance, and relevance.

[0061] As an optional implementation, see [link to implementation details]. Figure 1B Step 200: Divide the tender document into multiple semantically complete information units, including:

[0062] Step 210: Determine whether the tender documents contain at least one of the tables and diagrams shown in the tender documents;

[0063] Step 220: If so, divide each table or diagram into an information unit;

[0064] Step 230: Determine whether the text content of the tender document has formatted heading levels;

[0065] Step 240: If so, segment the text content based on the format heading level to obtain multiple information units;

[0066] Step 250: If not, segment the text content based on semantic sliding window to obtain multiple information units.

[0067] In this context, "illustration" can be understood as an attached diagram, and "format heading level" can be understood as the format heading level in the table of contents, or a heading level with bold, enlarged font, etc.

[0068] Semantic sliding window can be understood as a semantically based sliding window. It is a sliding window data processing technology that combines semantic integrity constraints. Its core is to use semantic boundaries as the core basis in the process of dividing data in the sliding window, so as to ensure that the data in each window has independent and complete semantic connotations. The length of the sliding window and the sliding length are not specifically limited here.

[0069] Optionally, the title level can refer to H1, H2, or H3 titles, and the resulting multiple information units have a unique identifier slice_id. Each slice_id can include at least one of the following information: {doc_id, page, bbox, heading_path, text, md5, char_offset}, where doc_id is a unique document identifier used to mark the original tender document to which the current information unit belongs; page is the page number used to record the physical page number position of the current information unit in the original tender document; bbox is the bounding box used to locate the geometric position of the current information unit in the original tender document, and is a parameter containing coordinate information; heading_path is the heading path used to record the heading level path to which the current information unit belongs; text is the text content used to indicate the core semantic information carried by the current information unit, that is, the semantically complete text extracted from the original tender document; md5 is the hash value generated by message digest algorithm 5, used to verify the integrity and uniqueness of the text content in the current information unit; char_offset is the character offset used to record the starting and ending character positions of the text content of the current information unit in the full text of the original tender document, which can accurately locate the range of the current information unit in the full text of the tender document and support the backtracking extraction and comparison of the current information unit.

[0070] In this embodiment, the tender document can be segmented according to tables, diagrams, format heading levels, and semantic sliding windows, thereby ensuring the semantic integrity of the segmented information units. At the same time, it can also increase the diversity and flexibility of the tender document segmentation method.

[0071] As an optional implementation, see [link to implementation details]. Figure 1CAfter step 200, which involves dividing the tender document into multiple semantically complete information units, the method disclosed in this disclosure further includes:

[0072] Step 300: Extract key information from multiple information units. Key information includes at least one of the following: text, table, or diagram.

[0073] Then, step 1000, generating the tender document based on the title hierarchy tree and dependencies, includes:

[0074] Step 1010: Generate chapter information based on the title hierarchy tree and the tender template file;

[0075] Step 1020: Generate constraints based on dependencies and key information;

[0076] Step 1030: Obtain the content information corresponding to the chapter information. The content information must meet the constraints.

[0077] Step 1040: Add the content information to the corresponding chapter content location to generate the tender document.

[0078] The specific method for extracting key information is not limited here. Optionally, key information can be extracted based on at least one of several keyword extraction methods, such as context vectors and complete semantics. The extracted keywords can include diverse content such as fields, tables, and diagrams. The aforementioned fields can also be referred to as text. Alternatively, the aforementioned key information can also be extracted using a combination of rule-based template extraction and large-scale model extraction.

[0079] In this context, constraints can be understood as the requirements information in the tender documents. For example, the requirements information may include at least one of the following: certificate type, validity period, region, social security certificate, performance time window, etc. The expressions for constraints may include at least one of the following: ≥, ≤, interval, set, AND, OR, NOT, mutually exclusive, etc.

[0080] For example, constraints may include at least one of the following: a terminology format table (also known as a blacklist or whitelist, used to limit the standard use of terms in the tender document), numbering and heading level constraints, factual consistency constraints (i.e., semantic consistency comparison between the generated tender document and the evidence fragments, rejecting any content in the generated tender document that conflicts with the original tender document); prohibited items (i.e., setting hard prohibitions in the tender document for clauses that "cannot be promised or substituted" as stipulated in the tender document); evidence citation constraints (the tender document must be associated with verifiable evidence fragments to ensure the authenticity and traceability of the content); and threshold constraints (hard requirements for values ​​or ranges specified in the tender document).

[0081] Key information can be understood as the set of elements that can affect the validity of the bid documents and the scoring results. The specific content of the key information is not limited here. Optionally, key information may include basic information (such as the tendering party, agency, project name, project number, bidding time, bid opening time, clarification time, submission medium and location, etc.), qualification requirements (such as qualification category and level, personnel certificates and years of service, performance scale and time window, financial conditions, credit conditions, etc.), evaluation methods (such as score distribution, scoring range, bonus points conditions, deduction points conditions, supporting document requirements, etc.), and rejection clauses (such as missing items, non-compliant format, overdue, abnormal price, etc.).

[0082] The content information can be obtained from multiple databases, which may include at least one of the following: enterprise personnel database, performance database, qualification database, system and solution knowledge base, historical bidding documents, etc.

[0083] Optionally, the content information corresponding to the chapter information can be obtained as described below: The above content information can be obtained based on the search enhancement generation strategy. At the same time, depending on the type of the tender document, different methods can be used to generate the above content information. For example, when the type of the tender document is a commercial tender, the corresponding content information can be saved in the chapter content position by filling in the enterprise factual information; when the type of the tender document is a technical tender, the corresponding content information can be saved in the chapter content position by combining the technical outline and evidence fragments.

[0084] Alternatively, the above-mentioned content information can be obtained from multiple databases through semantic similarity matching models and graph neural network (GNN) graph embedding propagation algorithms.

[0085] In this embodiment, a title hierarchy tree and dependencies can be generated based on the tender documents. Then, chapter information can be generated based on the title hierarchy tree and the bid template file. Furthermore, constraints can be generated based on the dependencies and key information. Content information corresponding to the chapter information is added to the corresponding chapter content location, and this content information must satisfy the constraints. This ensures that the generated bid document's content complies with all constraints of the tender documents, effectively improving the accuracy of the bid document's content. Simultaneously, since the title hierarchy tree and dependencies are directly derived from the analysis results of the tender documents, the bid document generation process relies on these analysis results, further ensuring a high degree of matching between the bid document and the tender documents in terms of structure and content, reducing the risk of structural misalignment or broken connections between the bid document and the tender documents.

[0086] As an optional implementation, see [link to implementation details]. Figure 1DStep 300, the steps for extracting key information from multiple information units, include:

[0087] Step 310: For multiple information units, extract key information with unique identifiers, including the location information of the key information in the bidding documents;

[0088] Step 320: Calculate the information unit corresponding to the key information to obtain the key information verification value;

[0089] Step 330: Based on the unique identifier and key information verification value corresponding to the key information, generate evidence anchor points for the key information. The evidence anchor points can locate the corresponding key information in the bidding documents through the unique identifier, and the evidence anchor points can determine whether the key information is consistent with the corresponding information unit through the key information verification value.

[0090] The calculation of the information unit corresponding to the key information to obtain the key information verification value can be understood as: calculating the original text of the bidding document included in the information unit, and the calculation method can include hash calculation and other known calculation methods.

[0091] The specific type of the unique identifier is not limited here. Optionally, the unique identifier can be an identity identifier, which may include location information, content information, etc.

[0092] Evidence anchors can record source evidence for each key piece of information (such as a field or table cell), and can also enable bidirectional navigation between the key information and the original text in the tender document, as well as in-page highlighting. For example, an evidence anchor can include the following information: Evidence Anchor = {slice_id, start_char, end_char, page, ...} The structure is defined as follows: `bbox,md5`, where `slice_id`, as described above, is the unique identifier of the information unit, specifically representing the unique identifier of the information unit to which the key information belongs. Its contents are described above. `start_char` is the starting character offset, indicating the starting character position of the current key information within its information unit, facilitating precise positioning of the starting boundary of the current key information within its information unit. `end_char` is the ending character offset, indicating the ending character position of the current key information within its information unit, facilitating precise positioning of the ending boundary of the current key information within its information unit. `page` refers to the physical page number of the current key information in the tender document. `bbox` is the bounding box, marking the geometric position of the current key information on the corresponding page in the tender document. It contains a set of coordinate information, which allows for precise selection and highlighting of the current key information on the page. `md5` is a hash verification value generated based on the original text of the key information, verifying the integrity and uniqueness of the key information. If the original text of the tender document corresponding to the key information is tampered with, its `md5` value will change. `md5` can be used as a verification value for the key information.

[0093] In this embodiment, evidence anchors for key information can be generated. The evidence anchors can determine whether the key information is consistent with the corresponding information unit through the key information verification value. In this way, the key information can be consistent with the corresponding information unit through the evidence anchors. Only when they are consistent can the tender document be generated based on the key information, thereby further improving the accuracy of the generated tender document.

[0094] As an optional implementation, see [link to implementation details]. Figure 1E Step 1040, adding content information to the chapter content location corresponding to the chapter information to generate the tender document, includes:

[0095] Step 1041: Generate association information. The association information is used to establish a two-way traceability relationship between at least one field of the content information and the corresponding key information. The association information includes the location information of the content information, the evidence anchor point corresponding to each field, and the logical reason for the association between each field and the corresponding key information.

[0096] Step 1042: Add the associated information to the corresponding chapter content location to generate the tender document.

[0097] The specific method for generating the associated information is not limited here. Optionally, the associated information can be generated in at least one of the following ways: based on field anchors, hash indexes, or document annotations.

[0098] The location information of the content information can be understood as: the storage location of the content information, the display location in the entire file, etc.

[0099] The logical reasoning behind the association can be generated based on the factual correspondence between fields in the content information and key information. Alternatively, the logical reasoning can also be obtained based on constraints. Optionally, it can be directly obtained from the constraints; alternatively, it can be generated based on the constraints. Overall, the association between fields in the content information and key information essentially represents the bid document's compliant response to the requirements of the tender document and the factual information.

[0100] In this embodiment of the disclosure, since the aforementioned related information is embedded in the chapter content of the tender document, users can simultaneously obtain the related information while reading the tender document. The related information includes the location information of the content information, the evidence anchor point corresponding to each field, and the logical reason for the association between each field and the corresponding key information. This helps users quickly clarify the compliance basis and evidence source of the tender content, significantly improves the readability and accessibility of the tender document, and optimizes the user's reading experience.

[0101] Furthermore, in this embodiment, the aforementioned related information can be automatically generated and added to the corresponding chapter content location to generate a complete tender document. This ensures that the generated tender document carries a complete original evidence index (i.e., related relationships) from the outset, achieving a closed loop of "content generation—compliance verification—evidence highlighting." This end-to-end evidence binding mechanism differs from post-processing comparison-based highlighting methods in related technologies, guaranteeing content traceability and consistency with evidence during generation, thus ensuring the accuracy of the traceability results.

[0102] It should be noted that the electronic device in this embodiment introduces a structured parsing framework of "file segmentation + dependency calculation + evidence anchor binding," enabling the electronic device in this embodiment to complete accurate field extraction and cross-page positioning by relying on contextual dependency structures even when local semantic understanding is limited. This embodiment differs from traditional text extraction methods that rely on global text traversal in related technologies. It does not require complex semantic analysis of the entire text; global semantic reconstruction can be achieved through local reasoning of a single sentence or paragraph, effectively improving parsing efficiency and the accuracy of field extraction.

[0103] As an optional implementation, see [link to implementation details]. Figure 1FAfter step 1042, which involves adding the associated information to the corresponding chapter content location to generate the tender document, the process also includes:

[0104] Step 1043: When the bidding documents are changed, obtain the updated information unit;

[0105] Step 1044: Determine whether the corresponding key information is consistent with the updated information unit by using the key information verification value in the evidence anchor point;

[0106] Step 1045: In case of inconsistency, correct the corresponding fields and related information in the tender documents based on the updated information units.

[0107] In this context, changes to the bidding documents can be understood as modifications, deletions, or additions. The key information verification values ​​in the evidence anchor points can be used to determine whether the corresponding key information is consistent with the updated information units. If inconsistent, the corresponding fields (i.e., related information) are corrected in the bidding documents based on the updated information units. Conversely, if consistent, the original fields and related information are maintained.

[0108] In this embodiment, when the tender documents are changed, the updated information units can be obtained, and the key information verification value in the evidence anchor point can be used to determine whether the corresponding key information is consistent with the updated information units. If the determination result is inconsistent, the corresponding fields and related information can be corrected in the tender documents according to the updated information units. In this way, the tender documents can be updated in real time according to the updated content of the tender documents, thereby ensuring that the tender documents always meet the requirements of the tender documents, which further improves the accuracy of the tender documents.

[0109] As an optional implementation, see [link to implementation details]. Figure 1G Before step 200, which involves dividing the tender document into multiple semantically complete information units, the following steps are also included:

[0110] Step 100: Perform formatting preprocessing on the tender documents. Formatting preprocessing includes at least one of the following: document format standardization processing, header and footer recognition processing, table of contents recognition processing, optical character recognition processing, noise removal processing, numbering standardization processing, and normalization processing.

[0111] The file format standardization process can be understood as follows: the tender document may be in a non-standard format, but after the file format standardization process, the tender document can be in a standard format, which facilitates subsequent segmentation.

[0112] Among these, header and footer recognition processing can be understood as: recognizing the header and footer information of each page in the tender document; table of contents recognition processing can be understood as: recognizing the table of contents of the tender document; optical character recognition processing can also be called (Optical Character Recognition). Optical character recognition (OCR) processing can be understood as recognizing optical characters or detecting language in tender documents. It can also correct tables and restore rows and columns. Noise removal processing removes noise from the tender document. Noise can refer to information that interferes with subsequent segmentation into multiple information units, or to information that interferes with the generation of the tender document, or even to background textures. Noise standardization processing corrects non-standard numbering in the tender document. Normalization processing normalizes information in the tender document, such as dates, amounts, and units. For example, if some parts of the tender document use year / month / day format for dates, while others use month / day / year format, normalization can unify the date information to the year / month / day format.

[0113] In this embodiment, by preprocessing the tender documents through formatting, problems such as inconsistent formats, content interference, and data heterogeneity in the original tender documents can be effectively eliminated. This results in a standardized text with a regular structure, clear semantics, and unified data format after preprocessing. Standardized text can better adapt to subsequent semantic segmentation, avoiding the fragmentation or redundancy of semantic units caused by format chaos and noise interference. This significantly improves the accuracy and effectiveness of segmenting the tender documents into multiple semantically complete information units, laying a reliable data foundation for subsequent core processes such as header hierarchy tree construction, dependency calculation, and evidence anchor binding.

[0114] As an optional implementation, see [link to implementation details]. Figure 1H After step 1000, generating the tender document based on the title hierarchy tree and dependencies, the process also includes:

[0115] Step 1200: Perform a risk check on the tender documents according to the rule matching method to obtain the first check result; and perform a risk check on the tender documents through the risk detection model to obtain the second check result. The risk detection model is a pre-trained model used to perform risk checks on the tender documents.

[0116] Step 1400: Generate the risk inspection results of the tender documents based on the first inspection results and the second inspection results.

[0117] When conducting risk checks on tender documents, risk checks can be carried out according to target dimensions, which may include at least one of the following:

[0118] Basic information check: Check that the company name, unified social credit code, legal representative, project name, project number, and time nodes are consistent in all places and must be consistent with the bidding documents;

[0119] Business inspection: Qualifications, personnel, performance, credit, etc., must match the terms stipulated in the tender documents; for any discrepancies, the gaps and required supporting documents must be listed.

[0120] Technical inspection: Check each technical parameter one by one, output "satisfied, deviated, or not applicable", and provide the reasons for the deviation and alternative suggestions;

[0121] Quotation checks: consistency of itemization, summary, tax rate, and capitalization; detection of prices exceeding limits and abnormally low prices; recalculation verification of the formulas.

[0122] The process of performing risk checks on the tender documents according to rule matching to obtain the first check result can be understood as: converting the terms of the tender documents into executable constraint expressions and directly judging the deterministic terms of the tender documents, thereby outputting the first check result of pass, fail, or partial pass.

[0123] The process of using a risk detection model to perform a risk check on the bid documents and obtaining a second check result can be understood as follows: the risk detection model checks whether the bid documents implicitly satisfy the classification, whether there are rejection risk sequence markers, and whether there are cross-chapter conflicts, etc., and outputs the second check result based on the above detection results. The aforementioned implicit satisfaction classification can be understood as: whether the completeness of the plan meets the standards, whether the advancement meets the standards, etc. The aforementioned rejection risk sequence markers can be understood as: whether there are missing attachments, whether there are incorrect formats, whether there are contradictory fields, whether there are overdue risks, etc. The aforementioned cross-chapter conflict detection can be understood as: whether there are conflicting pairs after the alignment of entities such as names, amounts, dates, and contact persons (i.e., whether there are inconsistencies in different chapters).

[0124] In this embodiment of the disclosure, the bid documents can be risk-checked according to rule matching to obtain a first check result. In addition, the bid documents can be risk-checked through a risk detection model to obtain a second check result. Then, the risk check result of the bid documents is generated based on the first check result and the second check result. In this way, the risk check result of the bid documents generated by combining the check results of the two detection methods is more accurate. That is, the risk detection of the bid documents can be achieved more accurately through the generated risk check result.

[0125] As an optional implementation, step 1400, generating a risk check result for the tender document based on the first and second check results, includes:

[0126] Based on the results of the first and second inspections, a risk inspection result for the tender documents is generated, along with a prompt message for the tender documents. The prompt message indicates that there is target content in the tender documents, which is content that makes the risk of the tender documents being rejected higher than the preset risk value.

[0127] When there are many target contents, they can be displayed in the form of a list. The list can show the severity of each target content and can also generate links between the target content and the tender documents and bid documents. Through these links, you can locate the relevant part of the tender documents and bid documents with one click.

[0128] It should be noted that the above-mentioned target content can be highlighted, and the specific method of highlighting is not limited here. Optionally, highlighting may include at least one of the following: magnified display, display with a preset color, floating window display, etc.

[0129] In this embodiment of the disclosure, a prompt message can be generated based on the risk check results. The prompt message indicates that there are target contents in the bid documents that increase the risk of bid rejection. This prompts the user to pay close attention to the target contents and modify them to reduce the risk of bid rejection.

[0130] As an optional implementation, see [link to implementation details]. Figure 1I After step 1000, generating the tender document based on the title hierarchy tree and dependencies, the process also includes:

[0131] Step 1600: Generate a predicted score for the bid documents. The predicted score represents the degree of matching between the bid documents and the tender documents.

[0132] Step 1800: Determine the areas for improvement in the tender documents based on the predicted scores, and output optimization suggestions.

[0133] The specific method for generating the predicted score for the tender document is not limited here. Optionally, it may include the following steps: first, score each item of the tender document, and then summarize the scores of each item to obtain the total score. The total score can be the predicted score. For example, the rules such as score distribution, scoring range, bonus conditions, deduction conditions and evidence requirements can be analyzed first, and then each item can be scored according to the above rules. The subjective items in the items can be estimated using classification models or regression models. Then, the scores corresponding to each item are summarized to obtain the predicted score. It should be noted that the above items can include: technical, commercial, and pricing, etc.

[0134] For example, the above scoring can be performed according to the following formula: Score = α·Sim(clause, candidate description) + β·rule satisfaction + γ·historical winning contribution + δ·allocation, where Score represents the score, α, β, γ and δ represent the weight parameters, and Sim(clause, candidate description), rule satisfaction, historical winning contribution and allocation can represent each rule respectively.

[0135] The specific content of the optimization suggestions is not limited here. Optionally, optimization suggestions may include: suggesting adjustments to staffing, supplementing performance cases, supplementing certification materials, etc.

[0136] In this embodiment, a predicted score for the bid document can be generated, and the content to be improved in the bid document can be determined based on the predicted score, as well as optimization suggestions can be output. This can improve the intelligence level of the optimization suggestion generation, and at the same time, guide users to modify the bid document in a targeted manner, effectively improve the matching degree between the bid document and the tender document, and thus help improve the overall quality of the bid document and the probability of winning the bid.

[0137] It should be noted that the above-mentioned predicted score can be understood as an internal evaluation of the bid document after it is generated, and modifications can be made based on the predicted score of the bid document to make the modified bid document more in line with the requirements of the bidding document, thereby increasing the probability of the modified bid document winning the bid.

[0138] Optionally, after generating the tender document, at least one of the following operations can be performed on the tender document, such as: the text, tables, and diagrams of the tender document can be modified in place; evidence bubbles and "replace evidence" operations can be displayed on the side of the tender document; support for "locking paragraphs of the tender document" (which can prevent them from being overwritten by subsequent automatic generation); version tracking (i.e., recording the modifier, time, and type (correction, supplementation, deletion, restatement), supporting version comparison and rollback); feedback learning (i.e., under the local security policy, the confirmed modifications are sampled into weakly supervised data for iterative optimization of parsing and generation effects); and incremental regeneration and re-verification (i.e., when the tender document is updated or paragraphs are edited, only the affected chapters in the tender document are regenerated and local rules and models are re-verified; a full access control check is performed before publication).

[0139] It should be noted that the application scenarios of the method shown in this embodiment are not specifically limited. Optionally, the application scenarios may include at least one of the following: automatic parsing and generation of procurement documents (i.e., tender documents), clause verification and risk warning of legal contracts, and standardization check and content recommendation of academic papers and patent documents.

[0140] To more fully illustrate the above embodiments, a specific embodiment is given below as an example. See [link to example]. Figures 2A to 2D The entire process can include four parts: intelligent parsing and structured modeling, content generation and source tracing, multi-dimensional consistency and risk checking, and intelligent recommendation and pre-scoring. These four parts can be sequentially divided into the following steps:

[0141] 1. See Figure 2A Intelligent parsing and structured modeling include the following steps:

[0142] Step S1, Tender Document Input and Preprocessing: Receive PDF, DOCX, HTML and their compressed attachments (i.e., tender documents), and perform preprocessing. Preprocessing may include at least one of the following: layout detection, character set and language detection, page number, header and footer recognition, background removal, noise reduction, and skew correction; perform OCR (table correction and row and column restoration) on the scanned documents; and standardize the number, date, amount, and unit.

[0143] Step S2, Tender Document Slicing: Slice the tender document based on the heading level (i.e., the format heading level) (e.g., H1, H2 or H3), tables, diagrams and semantic sliding windows to obtain slice_id level fragments (i.e., multiple information units); each slice_id level fragment records doc_id, page, bbox, heading_path, text, md5, and char_offset.

[0144] Step S3, Topic and Chapter Identification: Construct sparse indexes (BM25) and dense vectors (domain fine-tuning sentence vectors) for information units, and use a few-shot classifier to determine chapter topics such as "business, technology, quotation, general terms, attachments, forms" to form a heading_tree (i.e., a heading hierarchy tree).

[0145] Step S4, Field-level Extraction: A hybrid strategy of "rule template + LLM extractor + table structure restoration" is adopted to extract fields such as project name, purchaser, agency, bid deadline, bid opening time, bid bond, qualification conditions, technical indicators, and review methods (i.e., key information); technical parameters and thresholds are converted into constraint expressions (i.e., constraints), such as a central processing unit (CPU) core count ≥ 8 and memory ≥ 32GB; and the alignment of merged cell headers is restored.

[0146] Step S5: Generate context associations and clause dependencies: Identify references, backreferences, and clause cross-references (such as "see Clause 3.2.1" and "the following situations"), and construct a Clause Dependency Graph (i.e., the clause dependency graph can store dependencies) (nodes = clauses, table items, edges = references, conditions, value dependencies) for subsequent consistency checks and constraint generation.

[0147] Step S6, Establishing Evidence Anchors (i.e., Generating Evidence Anchors): Save an evidence anchor for each extracted field: Evidence={slice_id,start_char,end_char,page,bbox,md5}, and bind it bidirectionally with the field object Field={field_id,name,value,constraints[],evidence_list[],confidence} to achieve mutual jumping and highlighting between "field → original text" and "original text → field".

[0148] Output: A collection of structured information (fields, tables, constraints, dependency graphs) and SliceIndex (inverted index and vector index).

[0149] 2. See Figure 2B Content generation and source tracing are linked, including the following steps:

[0150] Step S7, Outline Synthesis: Based on heading_tree and the general bidding template library, generate OutlineSpec (Chapter → Required Fields, Required Evidence, Forbidden Items).

[0151] Step S8, Search Enhancement: Construct "constraint prompts" (including thresholds, non-committable items, and evidence to be cited) for each chapter, and retrieve candidate content from (a) the bidding evidence slice, (b) the enterprise information database (qualifications, personnel, performance, and systems), and (c) historical excellent bid materials.

[0152] Step S9, Segment Generation: The Retrieval-Augmented Generation (RAG) strategy is used to drive the LLM to generate commercial and technical segments, enabling control decoding (glossary, format, numbering constraints, and prohibited words), and performing factual consistency comparison on the generated content (semantic conflict detection and duplicate pruning with evidence slices).

[0153] Step S10, Layout Composition and Assembly: Map paragraphs to the DOCX template (styles, fields, numbering, figure captions, table of contents), automatically insert fixed components such as cover, table of contents, and commitment letter to obtain a submittable draft (i.e., tender document).

[0154] Step S11, Two-way source binding: Create Binding={section_id,para_id,span,evidence_list[],bind_type,ratione} for each generated paragraph; support one-click jump from the generated text to the original evidence (page number + bbox highlight), and reverse lookup of all referenced paragraphs and fields from the evidence.

[0155] Step S12, Addendum Change Tracking: When the tender addendum text is updated (i.e., the tender document is updated), the evidence is re-aligned by MD5, page, and bbox to determine whether the evidence is invalid; if invalid, a partial regeneration (i.e., updating the fields and related information in the tender document) and re-verification are triggered to ensure consistency with the latest requirements.

[0156] Output: Commercial and technical bid documents (DOCX, PDF) and bindings.json file.

[0157] 3. See Figure 2C Multi-dimensional consistency and risk checks include the following steps:

[0158] Step S13, Rule Engine Verification: Convert the terms such as qualifications, certifications, personnel, technical parameters, and quotations into executable constraint expressions (expression syntax includes ≥, ≤, ∈, AND, OR, NOT, interval, set, and mutual exclusion), evaluate the enterprise information and generated text item by item, and output {pass|fail|partial, gaps[],evidence}.

[0159] Step S14, Model Prediction Judgment: For implicit and ambiguous clauses, three types of model tasks are introduced:

[0160] A. Satisfaction Classification: Input = Clause Slices + Generated Paragraphs + Company Facts; Output = Satisfied, Questionable, Unsatisfied, and Confidence Level;

[0161] B. Risk sequence annotation for rejection: Perform B-begin, I-inside, O-outside (BIO) annotation on the entire text to identify trigger points such as "missing attachments, misformatting, contradictory fields, overdue, etc."

[0162] C. Cross-Chapter Consistency Conflict Detection: Create an alignment table for entities such as "Project Name, Amount, Date, Contact Person", and output conflict pairs and suggested correction values.

[0163] Step S15, Quotation Consistency Verification: Verify the calculation formulas and check the consistency of the amount in words and figures for the pricing description, sub-items, tax rate and total price; output the difference details and positioning anchor points.

[0164] Step S16: Risk Check Report Generation: Summarize the rules and model results to form the risk check result CheckReport={Dimension → Problem List, Severity, Remediation Suggestions, Skip Evidence, Skip Paragraph Links}, and set strong reminders for potential rejection items.

[0165] Output: Consistency and risk check report (can be exported independently as PDF or HTML).

[0166] 4. See Figure 2D Intelligent recommendation and pre-scoring includes the following steps:

[0167] Step S17, Candidate Set Construction and Hard Constraint Filtering: Extract personnel (certificates, on-the-job status, social security region), performance (industry, scale, contract amount, role, time), and qualifications (profession, level, validity period) from the enterprise database; filter according to the hard constraints of the terms (certificate type, years, region, validity period).

[0168] Step S18: Calculate the comprehensive score based on semantic matching ranking and interpretability;

[0169] Score = α·Sim(clause text, candidate description) + β·rule satisfaction + γ·historical winning contribution + δ·allocation degree, outputting Top-N with evidence fragments and explanations of non-satisfaction points, facilitating manual replacement.

[0170] Step S19, Analysis of Review Methods and Sub-item Scoring: Extract the score distribution, scoring range, evidence requirements, and conditions for adding or subtracting points from the review method table; perform deterministic scoring on calculable items, and estimate the scores and confidence levels of subjective items (completeness, advancement, and suitability) using regression and classification models.

[0171] Step S20, Total Score Prediction and Output Optimization Suggestions: Summarize the technical, commercial, and pricing sub-items, and provide the predicted range score (i.e., predicted score) and a "Shortcomings List" (corresponding to replaceable personnel, performance that can be strengthened, and supplementary certification materials) (i.e. optimization suggestions) to assist in optimizing the bidding strategy.

[0172] Outputs: Recommendation list (personnel, performance, qualifications) and pre-scoring report.

[0173] See Figure 3 , Figure 3 This is a structural diagram of the tender document generation device provided in this embodiment. The tender document generation device 30 includes:

[0174] Segmentation module 31 is used to segment the tender document into multiple semantically complete information units;

[0175] The vector generation module 32 is used to generate multiple context embedding vectors that correspond one-to-one with multiple information units. The context embedding vectors contain the specific semantics of the corresponding information unit in the context of the tender document.

[0176] Extraction module 33 is used to extract semantic features from multiple context embedding vectors to obtain the title hierarchy tree of the tender document;

[0177] The calculation module 34 is used to calculate the dependency relationship of multiple context embedding vectors to obtain the dependency relationship between information units. The dependency relationship indicates the association relationship between information units, including referential association, dependency association, and reference association.

[0178] Module 35 is used to generate tender documents based on the title hierarchy tree and dependencies.

[0179] The tender document generation apparatus provided in this disclosure divides the tender document into multiple semantically complete information units. This strictly adheres to the semantic boundaries of the tender document, effectively avoiding semantic fragmentation or redundant overlap of information units, and ensuring that each extracted information unit possesses independent and complete semantic connotations. Based on this, a context embedding vector corresponding to each information unit is generated. This context embedding vector fully carries the specific semantics of the corresponding information unit within the context of the tender document, and thanks to the semantic accuracy of the slice extraction, the semantic representation of the context embedding vector is more targeted and accurate. Furthermore, semantic features are extracted from multiple context embedding vectors to obtain a title hierarchy tree that clearly represents the themes and hierarchical structure of each chapter in the tender document. Simultaneously, dependency calculations are performed on multiple context embedding vectors to uncover the dependencies between information units. These dependencies clearly indicate the association types between information units. The semantic completeness of the information units brought about by the slice extraction further improves the accuracy of the title hierarchy tree construction and dependency calculations, ensuring that the extracted chapter themes, hierarchical relationships, and association types are highly relevant to the core requirements of the tender document. Then, the tender document is generated based on the title hierarchy tree and dependencies. This not only ensures that the generated tender document fully reproduces the chapter theme structure and title hierarchy logic of the tender document by leveraging the accurate title hierarchy tree, but also fully preserves the core relationships such as reference, dependence, and citation between information units by relying on accurate dependencies. This effectively avoids problems such as semantic misalignment, structural confusion, broken connections, or omission of core requirements in the tender document caused by information extraction deviations. It significantly improves the matching degree between the core requirements of the tender document and the tender document, ensuring that the generated tender document has high accuracy, compliance, and relevance.

[0180] As an optional implementation, the segmentation module 31 includes:

[0181] The first judgment submodule is used to determine whether there is at least one of the tables and diagrams in the bidding documents; if so, each table or diagram is divided into an information unit.

[0182] The second judgment submodule is used to determine whether the text content of the bidding document has a formatted heading level. If it does, the text content is segmented based on the formatted heading level to obtain multiple information units; otherwise, the text content is segmented based on a semantic sliding window to obtain multiple information units.

[0183] As an optional implementation, the tender document generation device 30 further includes:

[0184] The key information extraction module is used to extract key information from multiple information units. The key information includes at least one of the following: text, table, or diagram.

[0185] Module 35 is generated, including:

[0186] The first generation submodule is used to generate chapter information based on the title hierarchy tree and the tender template file;

[0187] The second generation submodule is used to generate constraints based on dependencies and key information.

[0188] The content information acquisition submodule is used to acquire content information corresponding to the chapter information. The content information must meet the constraints.

[0189] The third generation submodule is used to add content information to the chapter content position corresponding to the chapter information in order to generate the tender document.

[0190] As an optional implementation, the key information extraction module includes:

[0191] The extraction submodule is used to extract key information with unique identifiers from multiple information units. The unique identifiers include the location information of the key information in the bidding documents.

[0192] The calculation submodule is used to calculate the information units corresponding to the key information to obtain the key information verification value;

[0193] The fourth generation submodule is used to generate evidence anchors for key information based on the unique identifier and key information verification value. The evidence anchors can locate the corresponding key information in the bidding documents through the unique identifier, and the evidence anchors can determine whether the key information is consistent with the corresponding information unit through the key information verification value.

[0194] As an optional implementation, the third generation submodule includes:

[0195] The first generation unit is used to generate associated information, which is used to establish a two-way traceability relationship between at least one field of the content information and the corresponding key information. The associated information includes the location information of the content information, the evidence anchor point corresponding to each field, and the logical reason for the association between each field and the corresponding key information.

[0196] The second generation unit is used to add the associated information to the chapter content position corresponding to the chapter information in order to generate the tender document.

[0197] As an optional implementation, the tender document generation device 30 further includes:

[0198] The update information acquisition module is used to acquire updated information units when the bidding documents are changed;

[0199] The verification value judgment module is used to determine whether the corresponding key information is consistent with the updated information unit by using the verification value of key information in the evidence anchor point;

[0200] The information correction module is used to correct the corresponding fields and related information in the tender documents in case of inconsistencies, based on the updated information units.

[0201] As an optional implementation, the tender document generation device 30 further includes:

[0202] The preprocessing module is used to perform formatting preprocessing on the tender documents. The formatting preprocessing includes at least one of the following: document format standardization processing, header and footer recognition processing, table of contents recognition processing, optical character recognition processing, noise removal processing, numbering standardization processing, and normalization processing.

[0203] As an optional implementation, the tender document generation device 30 further includes:

[0204] The risk check module is used to perform risk checks on the bid documents according to rule matching to obtain the first check result, and to perform risk checks on the bid documents through the risk detection model to obtain the second check result. The risk detection model is a pre-trained model for performing risk checks on bid documents.

[0205] The risk inspection result generation module is used to generate risk inspection results for the tender documents based on the first inspection result and the second inspection result.

[0206] As an optional implementation, the risk inspection result generation module is also used for:

[0207] Based on the results of the first and second inspections, a risk inspection result for the tender documents is generated, along with a prompt message for the tender documents. The prompt message indicates that there is target content in the tender documents, which is content that makes the risk of the tender documents being rejected higher than the preset risk value.

[0208] As an optional implementation, the tender document generation device 30 further includes:

[0209] The predictive score generation module is used to generate a predictive score for the bid documents, which represents the degree of matching between the bid documents and the tender documents.

[0210] The optimization suggestion output module is used to determine the aspects of the bid document that need improvement based on the predicted score, and output optimization suggestions.

[0211] This disclosure also provides an electronic device. See also... Figure 4 The electronic device may include a processor 401, a memory 402, and a program 4021 stored in the memory 402 and executable on the processor 401. When the program 4021 is executed by the processor 401, it can achieve... Figure 1AAny steps in the corresponding method embodiments and the achievement of the same beneficial effects will not be repeated here.

[0212] Those skilled in the art will understand that all or part of the steps of the methods described in the above embodiments can be implemented by hardware related to program instructions, and the program can be stored in a readable medium. This disclosure also provides a readable storage medium storing a computer program, which, when executed by a processor, can implement the above... Figure 1A Any step in the corresponding method embodiment can achieve the same technical effect, and will not be repeated here to avoid repetition.

[0213] The aforementioned storage media include read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0214] This disclosure also provides a computer program product, including computer instructions, which, when executed by a processor, can perform the above-described functions. Figure 1A Any step in the corresponding method embodiment can achieve the same technical effect, and will not be repeated here to avoid repetition.

[0215] The above-disclosed content is a preferred embodiment of the present disclosure. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principles disclosed in this disclosure, and these improvements and modifications should also be considered within the scope of protection of this disclosure.

Claims

1. A method of generating a bid document, characterized by, include: The tender document is divided into multiple semantically complete information units; Generate multiple context embedding vectors that correspond one-to-one with the multiple information units, wherein the context embedding vectors contain the specific semantics of the corresponding information unit in the context of the tender document; Semantic features are extracted from the multiple context embedding vectors to obtain the title hierarchy tree of the tender document; Dependency calculation is performed on multiple context embedding vectors to obtain the dependency relationship between the information units. The dependency relationship indicates the association type between the information units, and the association type includes referential association, dependency association, and reference association. The tender document is generated based on the title hierarchy tree and the dependencies.

2. The method of claim 1, wherein, The process of dividing the tender document into multiple semantically complete information units includes: Determine whether the tender document contains at least one of the tables and illustrations; if so, divide each table or illustration into one information unit. Determine whether the text content of the tender document has a formatted heading level. If it does, segment the text content based on the formatted heading level to obtain multiple information units. If not, segment the text content based on a semantic sliding window to obtain multiple information units.

3. The method of claim 1, wherein, After the step of segmenting the tender document into multiple semantically complete information units, the method further includes: extracting key information from the multiple information units, the key information including at least one of the following: text, tables, and diagrams; generating the tender document based on the title hierarchy tree and the dependency relationship includes: Generate chapter information based on the title hierarchy tree and the tender template file; Constraints are generated based on the dependencies and the key information; Obtain content information corresponding to the chapter information, wherein the content information must satisfy the constraints. The content information is added to the corresponding chapter content location to generate the tender document.

4. The method of claim 3, wherein, The step of extracting key information from multiple information units includes: For multiple information units, extract key information with unique identifiers, the unique identifiers including the location information of the key information in the tender document; The key information verification value is obtained by calculating the information unit corresponding to the key information. Based on the unique identifier corresponding to the key information and the key information verification value, an evidence anchor point for the key information is generated. The evidence anchor point can locate the corresponding key information in the tender document through the unique identifier. The evidence anchor point can determine whether the key information is consistent with the corresponding information unit through the key information verification value.

5. The method of claim 4, wherein, The step of adding the content information to the chapter content position corresponding to the chapter information to generate the tender document includes: Generate association information, which is used to establish a bidirectional tracing relationship between at least one field of the content information and the corresponding key information; the association information includes the location information of the content information, the evidence anchor point corresponding to each of the included fields, and the association logic reason between each field and the corresponding key information; The associated information is added to the chapter content location corresponding to the chapter information to generate the tender document.

6. The method of claim 5, wherein, After adding the associated information to the chapter content location corresponding to the chapter information to generate the tender document, the method further includes: When the tender documents are changed, obtain the updated information unit; By using the key information verification value in the evidence anchor, it is determined whether the corresponding key information is consistent with the updated information unit; In the event of inconsistency, the corresponding fields and associated information in the tender document shall be corrected according to the updated information unit.

7. The method of claim 1, wherein, Before the step of dividing the tender document into multiple semantically complete information units, the method further includes: The tender documents are formatted and preprocessed, including at least one of the following: file format standardization, header and footer recognition, directory recognition, optical character recognition, noise removal, numbering standardization, and normalization.

8. The method according to any one of claims 1 to 7, characterized in that, After generating the tender document based on the title hierarchy tree and the dependencies, the method further includes: The bid documents are subjected to risk checks according to rule matching to obtain a first check result. The bid documents are then subjected to risk checks using a risk detection model to obtain a second check result. The risk detection model is a pre-trained model used to perform risk checks on bid documents. The risk check results of the tender documents are generated based on the first check results and the second check results.

9. A bid document generating apparatus characterized by comprising: include: The segmentation module is used to segment the tender document into multiple semantically complete information units; A vector generation module is used to generate multiple context embedding vectors that correspond one-to-one with the multiple information units, wherein the context embedding vectors contain the specific semantics of the corresponding information unit in the context of the tender document; The extraction module is used to extract semantic features from the multiple context embedding vectors respectively to obtain the title hierarchy tree of the tender document; The calculation module is used to perform dependency calculation on multiple context embedding vectors to obtain the dependency relationship between the information units. The dependency relationship indicates the association relationship between the information units, and the association relationship includes referential association, dependency association, and reference association. A generation module is used to generate the tender document based on the title hierarchy tree and the dependencies.

10. An electronic device, comprising: A memory, a processor, and a program stored in the memory and executable on the processor; characterized in that the processor is configured to read the program from the memory to implement the steps in the tender document generation method as described in any one of claims 1 to 8.

Images