Intelligent bidding document generation method and system based on bidding document topology modeling

Abstract

The invention discloses an intelligent bidding document generation method and system based on bidding document topology modeling, and belongs to the technical field of artificial intelligence. The method comprises the following steps: S1, analyzing a bid invitation file, constructing a scoring criterion topological graph ScoreDAG, and obtaining a semantic anchoring constraint set corresponding to each scoring node in the ScoreDAG; s2, taking the ScoreDAG and the corresponding semantic anchoring constraint set as input to perform knowledge graph retrieval in a knowledge database, and performing high-score path matching on a retrieval result to obtain an evidence packet; s3, the large language model generates a draft according to the bid invitation file and the evidence packet, when the draft is generated, all chapters and sections are constrained through the global constraint variable pool, and meanwhile consistency detection is carried out; s4, performing confrontation closed-loop optimization on the draft according to the responsivity score of the ScoreDAG; and S5, typesetting the manuscript optimized in the step S4 and outputting the manuscript in a deliverable manner to obtain the bidding document.

Description

Technical Field

[0001] This invention belongs to the field of artificial intelligence technology, specifically relating to an intelligent method and system for generating tender documents based on topological modeling of bidding documents. More particularly, it relates to an intelligent method and system for generating tender documents for power system bidding. It involves the integrated application of technologies such as Natural Language Processing (NLP), knowledge graphs, information extraction, constraint reasoning, retrieval-enhanced generation (RAG / GraphRAG), large language model generation, automatic scoring, and adversarial optimization. Specifically, it relates to a complete system and method for achieving structured modeling → constraint generation → automatic scoring → iterative optimization → compliant formatting output in bidding scenarios, centered around the "evaluation method / scoring details," applicable to power industry bidding and possessing cross-industry universality. Background Technology

[0002] Tender documents typically consist of multiple chapters (e.g., technical response, implementation plan, schedule, quality assurance, safety and civility, commercial terms, price / cost explanation, and qualifications and performance records). Evaluation usually involves deducting points or rejecting bids based on the "evaluation methods / scoring rules / rejection clauses" in the tender documents. Traditional manual preparation has the following drawbacks:

[0003] Omissions in response to scoring points: Many scoring clauses are buried in attachments, notes and tables, which are easy to miss manually. Intra-chapter / inter-chapter contradictions: Inconsistencies frequently exist between technical solutions, resource plans, schedules, costs, and business commitments; Risks associated with rejection / no-bid clauses: Requirements for sealed bids, rigid parameter thresholds, qualification certificates, and key equipment models, etc., can lead to immediate rejection if triggered. High typesetting and formatting costs: Power bidding often requires strict requirements for table of contents, page numbers, chapter formats, table styles and response form templates, etc., and manual adjustments are time-consuming.

[0004] Existing technologies can also automatically generate tender documents using large language models. For example, patent application number CN202511321664.2 discloses a document generation method based on a large model and RAG, including: performing deep learning and semantic analysis on the tender document file uploaded by the user using a large model LLM to obtain the core project information in the tender document file; determining the business field and industry category to which the tender document file belongs based on the core project information; and, based on the core project information, the business field, and the industry category of the tender document file, referring to an industry knowledge graph and setting a tender document template database, selecting and obtaining tender documents that match the user's needs. A bid document template is generated; based on the bid document template and the core project information, a bid document outline is generated; based on the bid document outline, the required data is extracted from the set material library using the large model LLM to populate the data and generate a draft bid document; the draft bid document is quality reviewed using NLP technology to check for rejection factors and consistency of key terminology, and to generate problem prompts and correction suggestions; based on the problem prompts and correction suggestions, the draft bid document is revised to generate a revised bid document; the revised bid document is formatted, optimized, and manually reviewed to output the final bid document.

[0005] For example, patent application number CN202311784713.7 discloses a method for generating tender documents based on a large model. The method includes: acquiring historical tender data and decomposing the historical tender data to obtain historical tender format information; acquiring samples of bidding requirements documents and performing structured processing on each sample of bidding requirements documents to obtain structured information of bidding requirements; training a large model based on the structured information of bidding requirements and the historical tender format information, and performing requirements analysis on the tender documents of the target bidding project to obtain bidding requirements; inputting the bidding requirements and enterprise bidding data into the trained large model to generate tender documents to obtain target tender documents, and performing document detection on the target tender documents; revising the target tender documents based on the document detection results, and outputting the revised target tender documents.

[0006] For example, patent application number CN202311484127.0 discloses a method for generating tender documents, including: obtaining tender documents; parsing the tender documents to generate a tender document profile; converting the tender document profile into a first instruction statement, and using the first instruction statement to call a preset large language model to generate a tender document catalog; and generating tender documents based on the tender document catalog using the large language model.

[0007] Existing automated tender document systems (template systems, standard RAG+LLM, case assembly systems) mainly suffer from the following shortcomings (which are also the problems this invention aims to solve): (1) Semantic fragmentation and response distortion General RAGs often use slice-based retrieval, which can easily lose the context of rating clauses, resulting in generated content that "seems relevant but does not hit the rating details one by one," leading to semantic offset.

[0008] (2) Uncontrollable logical contradictions across chapters Existing systems are typically generated independently by chapter, lacking a "global constraint variable pool + propagation mechanism," leading to conflicts such as mismatch between schedule and resources, and mismatch between cost and equipment.

[0009] (3) Compliance verification is delayed and it is impossible to avoid rejection points during the generation process. Many systems perform keyword filtering or simple rule checks after generation, but cannot avoid hidden invalidation clauses (such as blind bidding, hard threshold parameters, or lack of qualifications) in real time during the generation process.

[0010] (4) Lack of score-driven closed-loop optimization Most systems "generate once and then stop," lacking an automatic feedback mechanism such as "analysis of expert deduction logic," let alone a "reverse optimization" closed loop based on scoring topology. Summary of the Invention

[0011] To address the aforementioned issues, this invention provides an intelligent method and system for generating tender documents based on topological modeling of tender documents. The method parses the evaluation methods / scoring details in the tender documents into a computable scoring criterion topology graph (DAG) and forms an executable "response task list." A semantic anchoring constraint set is constructed for each scoring node to ensure that the generated content responds "point-by-point," avoiding semantic deviation. A cross-chapter constraint propagation engine is established to continuously maintain global consistency during the generation process. Through an adversarial closed loop between the generation engine and the evaluation engine, the method simulates expert deduction logic for reverse optimization, automatically iterating until the scoring converges. The technical solution is as follows: On one hand, embodiments of the present invention provide an intelligent method for generating tender documents based on topology modeling of tender documents, the method comprising: S1: Parse the tender documents and construct the scoring criteria topology graph ScoreDAG, and obtain the semantic anchoring constraint set AnchorConstraintSet corresponding to each scoring node ScoreNode in ScoreDAG; S2: Using ScoreDAG and the corresponding AnchorConstraintSet as input, perform knowledge graph retrieval in the knowledge database, and obtain the evidence package by high-scoring path matching of the retrieval results; S3: The large language model generates a draft based on the tender documents and evidence package. When generating the draft, all chapters are constrained through the global constraint variable pool GlobalConstraintPool, and consistency checks are performed at the same time. S4: Perform adversarial closed-loop optimization on the draft based on the response score of ScoreDAG; The responsiveness score is derived from the coverage score, precision score, evidence score, consistency score, and risk penalty score. The coverage_score is used to determine whether the content fully covers all the requirements of the ScoreNode. The precision_score is used to evaluate the degree of matching between the content and the hard_constraints[] in AnchorConstraintSet. The evidence_score is used to evaluate whether a verifiable evidence package has been provided. The consistency_score is used to evaluate the consistency of content with the GlobalConstraintPool. The risk_penalty is used to evaluate whether to trigger the risk_flags[] in AnchorConstraintSet; S5: Format and deliver the manuscript obtained from step S4 to produce the tender document.

[0012] ScoreNode includes a unique identifier node_id, type node_type, scoring item name title, corresponding original text segment in the tender document raw_text_span, score / weight weight, response requirement list requirements[], evidence types[], semantic anchor constraints anchor_constraints[], potential rejection / blind bid risk flags risk_flags[], and dependent upstream nodes dependencies[]; The knowledge database includes historical tender documents, company personnel information, company qualification information, and industry standards. AnchorConstraintSet is obtained by classifying anchor_constraints[]. AnchorConstraintSet includes hard_constraints[], soft_constraints[], forbidden_patterns[], and / or coverage_targets[], which must appear and cannot be changed. The GlobalConstraintPool is derived from the key variables extracted in step S3, including entity_constraints, numeric_constraints, commitment_constraints, trace_links, and conflict_rules.

[0013] Specifically, parsing the tender documents and constructing the ScoreDAG scoring criterion topology graph includes: S101: Obtain the tender documents; S102: Perform structured parsing of the tender documents; S103: Obtain scoring information; S104: Obtain the corresponding "Bidding Requirements - Scoring Details - Score Weight" triplet based on the scoring information; S105: ScoreNode is constructed from triples; S106: Identify dependencies between ScoreNodes; identify dependencies according to the following rules: (1) If the clause contains "must / otherwise veto / if not met, the bid will be cancelled", it shall be used as a prerequisite for qualification / veto point; (2) If the scoring item references the qualifications / certificates mentioned above, then establish a dependency edge; (3) If the technical solution evaluation depends on the equipment parameter response, then the equipment parameter node is a prerequisite qualification node; S107: ScoreDAG is constructed from ScoreNode and its dependencies; S108: Determine if the ScoreDAG is cyclic. If not, output the result; otherwise, break the cycle according to the following rules: If a circular dependency is detected, the loop will be broken according to the order of "veto > qualification > technology > business > bonus".

[0014] Specifically, obtaining the semantic anchoring constraint set AnchorConstraintSet corresponding to each score node ScoreNode in ScoreDAG includes: S111: Select ScoreNode; S112: Identify anchor_constraints[], which includes numerical values / ranges, standards / specifications, certificates / certifications, and project duration / milestones; S113: Classify anchor_constraints[] to obtain AnchorConstraintSet.

[0015] Specifically, step S2 includes: S201: Structure the files in the knowledge database into a graph entity relationship of "project type - scoring node type - technical parameters - expert evaluation"; S202: Using ScoreDAG and the corresponding AnchorConstraintSet as input, perform knowledge graph retrieval in the knowledge database to obtain several evidence chains that best match the scoring node; the evidence chains include case paragraphs, parameter tables, and certificate citation templates; S203: Obtain a package of evidence for chapter arrangement from several chains of evidence based on the manuscript acquisition strategy, the rules of which are as follows: (1) For high-weight nodes, retrieve stronger evidence and longer chains of argumentation; (2) For veto nodes, generate a hard response table and an evidence catalog.

[0016] Specifically, constraining all chapters through the global constraint variable pool GlobalConstraintPool includes: when each chapter is generated, existing constraints are read from GlobalConstraintPool and applied to the generation of that chapter; after the chapter is generated, key variables are obtained as constraints and written into GlobalConstraintPool to constrain subsequent chapters; the key variables include equipment model, quantity, construction period, and / or standard number; the consistency check includes: after each chapter is generated, a consistency check is performed; the rules for consistency check are: different values ​​for the same variable, inconsistent unit conversions, or contradictory versions of the same commitment constitute a conflict; once a conflict occurs, modification suggestions are generated and the chapter is regenerated; if there is no conflict, the next chapter is generated; after all chapters are generated, a draft is obtained and a conflict list is output.

[0017] Specifically, step S4 includes: S401: The generation engine modifies the draft to obtain a manuscript that meets the requirements of writing style and structure and can be recognized by the evaluation engine. S402: The evaluation engine simulates the scoring logic of bidding experts, compares the ScoreDAG to score the responsiveness of the manuscript and obtains an evaluation report; the responsiveness score = coverage_score + precision_score + evidence_score + consistency_score - risk_penalty; the evaluation report includes: node-by-node score node_scores{node_id:score}, deduction_reasons[], fatal_flags[], cross-chapter contradiction location contradictions[], and executable revision actions revise_actions[]; S403: Compare the response score with a preset threshold; if it is lower than the preset threshold or fatal_flags[] is found, proceed to step S404; otherwise, proceed to step S405. S404: Obtain revise_actions[] as revision constraints and feed them back to the generation engine. The generation engine performs local or global rewriting of the document and then executes step S402. S405: Output the optimized document.

[0018] On the other hand, embodiments of the present invention also provide an intelligent tender document generation system based on tender document topology modeling, comprising: The tender document parsing module is used to parse tender documents. The scoring criterion topology graph construction module is used to construct the scoring criterion topology graph ScoreDAG; The semantic anchoring module for scoring nodes is used to obtain the semantic anchoring constraint set AnchorConstraintSet corresponding to each scoring node ScoreNode in ScoreDAG; The knowledge graph construction and retrieval module is used to structure historical tender documents, and to perform knowledge graph retrieval in the knowledge database using ScoreDAG and its corresponding AnchorConstraintSet as input. The retrieval results are then matched with high-scoring paths to obtain evidence packages. The chapter generation and arrangement module is used to generate chapters based on the tender documents and evidence packages and perform consistency checks, from which drafts are obtained; The cross-chapter constraint propagation module is used to constrain chapters through the global constraint variable pool GlobalConstraintPool when generating chapters; The adversarial loop optimization module is used to perform adversarial loop optimization on the draft based on the response score of ScoreDAG. The semantic tag layout and rendering module is used to layout and deliver tender documents from the text optimized by the adversarial closed-loop optimization module.

[0019] Specifically, the anti-loop optimization module includes: The generation engine is used to modify drafts to obtain manuscripts that meet the requirements of writing style and structure and can be recognized by the evaluation engine. The evaluation engine simulates the scoring logic of bidding experts, scores the responsiveness of the document against the ScoreDAG, and generates an evaluation report. The adversarial iteration control unit is used to compare the responsiveness score with a preset threshold. If it is lower than the preset threshold or if fatal_flags[] is found in the evaluation report, the revise_actions[] in the evaluation report is obtained as a revision constraint and fed back to the generation engine, so that the generation engine can rewrite the document locally or globally. Otherwise, the optimized document is output.

[0020] In another aspect, embodiments of the present invention also provide a computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps of the aforementioned method.

[0021] The beneficial effects of the technical solution provided by the embodiments of the present invention are as follows: 1. Improved response accuracy: By using scoring DAG + semantic anchoring, we ensure that every item is addressed, reducing off-topic and omissions; 2. Significantly improved logical consistency: The cross-chapter constraint propagation engine eliminates parameter conflicts and inconsistencies in terminology; 3. Significantly reduced risk of rejection: Adversarial verification can identify and avoid rejection points / blind bidding risks during the generation process; 4. Convergent generation quality: The score-driven closed-loop iteration makes the output continuously approach the optimal score, rather than generating it all at once. Attached Figure Description

[0022] Figure 1 This is a flowchart of the intelligent generation method for tender documents based on topology modeling of tender documents provided in an embodiment of the present invention; Figure 2 This is a flowchart of the ScoreDAG topology graph construction process; Figure 3 This is a flowchart for obtaining the semantic anchoring constraint set; Figure 4 This is a flowchart of step S2; Figure 5 This is a flowchart of step S3; Figure 6 This is a flowchart of step S4; Figure 7This is the flowchart for step S5. Detailed Implementation

[0023] To make the objectives, technical solutions, and advantages of the present invention clearer, the present invention will be further described in detail below with reference to the accompanying drawings.

[0024] Example 1 See Figure 1 Example 1 provides an intelligent method for generating tender documents based on topology modeling of tender documents. The method includes: S1: Parse the tender documents and construct the scoring criteria topology graph ScoreDAG, and obtain the semantic anchoring constraint set AnchorConstraintSet corresponding to each scoring node ScoreNode in ScoreDAG.

[0025] ScoreNode includes a unique identifier node_id, a type node_type (eligibility, rejection, technical, business, bonus points, etc.), a scoring item name title, a corresponding original text segment raw_text_span in the tender document (position, page number, paragraph, etc.), a score / weight weight, a list of response requirements requirements[] (parameters, certificates, processes, description depth, etc.), evidence types required evidence_types[] (qualification certificates, test reports, performance proofs, solution diagrams, etc.), semantic anchor constraints anchor_constraints[], potential rejection / blind bid risk flags risk_flags[], and dependent upstream nodes dependencies[] (to obtain the edges of ScoreDAG), etc.

[0026] AnchorConstraintSet is obtained by classifying anchor_constraints[]. AnchorConstraintSet includes hard_constraints[] which must appear and cannot be changed (such as frequency range, standard number, key equipment model, certificate number type, etc.), soft_constraints[] which are suggested to appear to improve the score (such as advantages and highlights, comparative demonstration, risk control, etc.), forbidden_patterns[] which are prohibited from appearing (such as blind bidding information, sensitive brands, prohibited disclosure items in bidding, etc.) and / or coverage target constraints coverage_targets[].

[0027] S2: Using ScoreDAG and the corresponding AnchorConstraintSet as input, perform knowledge graph retrieval in the knowledge database, and obtain evidence packages by high-scoring path matching of the retrieval results to ensure the reliability of the evidence.

[0028] The knowledge database includes a wide variety of bidding materials, such as historical tender documents, company personnel information, company qualification information, and industry standards (and other materials as needed, which will not be listed in this patent). This patent does not limit the types of materials.

[0029] S3: The large language model generates a draft based on the tender documents and evidence package. When generating the draft, all chapters are constrained through the global constraint variable pool GlobalConstraintPool, and consistency checks are performed to ensure consistency.

[0030] The GlobalConstraintPool consists of key variables extracted from the chapters generated in step S3. These variables include entity_constraints (equipment, systems, personnel, project duration, milestones, etc.), numeric_constraints (capacity, indicators, quantities, unit prices, total price ranges, etc.), commitment_constraints (response format, original text citations, clause consistency, etc.), trace_links (which chapter or node was first determined), and conflict_rules (inconsistent values, inconsistent units, different values ​​with the same name, etc.).

[0031] S4: The generation engine and the evaluation engine compete against each other, and the draft is optimized in a closed loop by comparing the response score of ScoreDAG.

[0032] The responsiveness score is derived from the coverage score, precision score, evidence score, consistency score, and risk penalty score. The responsiveness score is obtained according to preset rules and can be obtained by direct addition or subtraction, or by weighted summation (with different weights set, and risk penalty being negative).

[0033] Among them, coverage_score is used to determine whether the content fully covers all the requirements of ScoreNode, precision_score is used to evaluate the matching degree between the content and hard_constraints[] in AnchorConstraintSet, evidence_score is used to evaluate whether verifiable evidence is provided, consistency_score is used to evaluate the consistency between the content and GlobalConstraintPool, and risk_penalty is used to evaluate whether risk_flags[] in AnchorConstraintSet is triggered; S5: Format and deliver the manuscript obtained from step S4 to produce the tender document.

[0034] Example 2 See Figure 1-7 Example 2 provides an intelligent method for generating tender documents based on topology modeling of tender documents, including the following steps: S1: Parse the tender documents and construct the scoring criterion topology graph ScoreDAG, obtaining the semantic anchoring constraint set AnchorConstraintSet corresponding to each scoring node ScoreNode in ScoreDAG. See also Figure 2 The construction process of the ScoreDAG topology graph for the scoring criteria is as follows: S101: Obtain the tender documents (in PDF / Word / image format, and also include optional attachments (including scoring sheets, response form templates, etc.)).

[0035] S102: Perform structured parsing of the tender documents; including the following processes: (1) Document layering: chapters, clauses, tables, attachments, headers and footers, and numbering systems, etc.; (2) Table analysis: The scoring sheet is often in a table, and the "scoring items, scores and requirements" must be accurately extracted.

[0036] S103: Obtain rating information.

[0037] S104: Obtain the corresponding "Bidding Requirements - Scoring Details - Score Weights" triplet based on the scoring information.

[0038] S105: ScoreNode is constructed from triples, as described in Example 1.

[0039] S106: Identify dependencies between ScoreNodes; identify dependencies according to the following rules: (1) If a clause contains "must / otherwise rejected / not meeting the requirements will result in rejection", it will be used as a prerequisite / rejection point. Specifically, if it contains "must", it will be used as a prerequisite; if it contains "otherwise rejected / not meeting the requirements will result in rejection", it will be used as a rejection point.

[0040] (2) If the scoring item references the qualifications / certificates mentioned above, then establish a dependency edge; (3) If the technical solution evaluation depends on the equipment parameter response, then the equipment parameter node is a prerequisite qualification node.

[0041] S107: The ScoreDAG is constructed from ScoreNodes and their dependencies. The structure of the ScoreDAG is as follows: (1) nodes{}: ScoreNode collection; (2) edges[]: directed edges (A→B means that B's response depends on the prerequisite of A, which is a dependency edge); (3) root: the target node for the overall score; (4) Subgraphs: Subgraphs divided by chapter / topic (for parallel generation).

[0042] S108: Determine if the ScoreDAG is cyclic. If not, output the result; otherwise, break the cycle according to the following rules: If a circular dependency is detected, the loop will be broken according to the order of "veto > qualification > technology > business > bonus".

[0043] Specifically, for the power sector, input: power engineering bidding documents (including: evaluation methods, technical specifications, bid document format and response form template, etc.).

[0044] System analysis: Identify hard thresholds (voltage level, capacity, standards and safety regulations, etc.) in the "Technical Specifications"; identify chapter requirements and response tables in the "Tender Document Format"; extract the scoring details table as ScoreNodes.

[0045] ScoreDAG construction example: Node A: Qualification requirements (safety production license, installation / repair / testing qualifications, etc.) → Pre-qualification node; Node B: Rejection Clause (Deviation of Key Parameters / Failure to Provide Test Report) → Rejection Node; Node C: The technical solutions (system architecture, secondary protection, communication protocols, etc.) depend on Node B; Node D: The project schedule depends on Node C (because resource allocation depends on the complexity of the solution); Node E: The pricing details depend on Node C / D (equipment list and timeline affect costs).

[0046] The ScoreDAG dependent edge identification algorithm is as follows: Rule layer: Rejection trigger words ("otherwise the bid will be rejected / must not / strictly prohibited / invalid") → Rejection node; Reference relationship ("See Article X / According to Standard X / Meets Certificate X") → Establish dependency edges; The scoring sheet's "Prerequisites" column → edge.

[0047] Learning layer (optional): Train a "dependency classifier" that takes two node text fragments as input and outputs whether a dependency edge exists.

[0048] Among them, see Figure 3 The classification process of the semantic anchoring constraint set AnchorConstraintSet specifically includes: S111: Select ScoreNode.

[0049] S112: Identify anchor_constraints[]; anchor_constraints[] includes numerical values / ranges, standards / specifications, certificates / certifications, project duration / milestones, etc. Specifically, numerical values / ranges include power equipment capacity, efficiency, or frequency range, etc.; standards / specifications include national / industry standard numbers, etc.; and certificates / certifications include ISO, safety regulations, or licenses, etc.

[0050] S113: Classify anchor_constraints[] to obtain AnchorConstraintSet. See the description of Example 1 for classification.

[0051] The specific process is as follows: Numerical extraction: range, unit (kV, MW, Hz), precision; Standard number extraction: GB / T, DL / T, etc.; Certificate Extraction: Certificate Name + Issuing Authority + Validity Period Slot (Even if the certificate number is not filled in, "Evidence Placeholder + Directory Reference" is required).

[0052] Normalization: Unit conversion and synonym mapping (e.g., "construction period = total construction period = planned period" unified key).

[0053] S2: Using ScoreDAG and its corresponding AnchorConstraintSet as input, perform knowledge graph retrieval in the knowledge database, and obtain the evidence package by performing high-scoring path matching on the retrieval results. See also Figure 4 Specifically, it includes the following process: S201: Structure the files in the knowledge database into a graph entity relationship of "project type - scoring node type - technical parameters - expert evaluation".

[0054] The project types include power transmission and transformation, distribution automation, secondary systems, communication, and dispatching. The scoring node types include reliability, economy, schedule, safety regulations, and performance. The technical parameter entities include capacity, voltage level, redundancy, and protocols. The expert evaluation entities include deduction points, bonus points, and common questions.

[0055] S202: Using the ScoreDAG and its corresponding AnchorConstraintSet as input, perform a knowledge graph retrieval in the knowledge database to obtain several evidence chains that best match the scoring node. These evidence chains include case paragraphs, parameter tables, and certificate citation templates, etc.

[0056] S203: Obtain a package of evidence for chapter arrangement from several chains of evidence based on the manuscript acquisition strategy, the rules of which are as follows: (1) For high-weight nodes (which can be identified from the score / weight), retrieve stronger evidence and longer chains of argumentation; (2) For veto nodes (which can be identified from risk_flags[]), generate a "hard response table + evidence directory" (which will be used when generating chapters).

[0057] S3: The large language model generates a draft based on the tender documents and evidence package (other documents or parameters, such as templates, may also be included as needed; this is a conventional technique in the field, and detailed description is omitted in this embodiment). During draft generation, all sections are constrained through the global constraint variable pool (GlobalConstraintPool), and consistency checks are performed simultaneously. This process ensures consistency throughout. See also... Figure 5 The specific process is as follows: When each chapter is generated, existing constraints are read from the GlobalConstraintPool and applied to the generation of that chapter. After the chapter is generated, key variables are obtained as constraints and written to the GlobalConstraintPool to constrain subsequent chapters (forced writing to prompts / plans). Key variables include equipment model, quantity, construction period, and / or standard number, etc., for specific definitions as described in Example 1.

[0058] After each chapter is generated, a consistency check is performed. The rules for consistency check are: different values ​​for the same variable, inconsistent unit conversions, or contradictory versions of the same commitment constitute a conflict. Once a conflict occurs, modification suggestions are generated and the chapter is regenerated (locating the conflicting paragraphs and providing a "unified standard" suggestion). If there is no conflict, proceed to the next chapter. Once all chapters are generated, a draft is obtained and a conflict list (if any) is output.

[0059] The specific process of setting constraints is as follows: Once the technical section determines the "main equipment model / quantity / redundancy scheme / protocol standard", it will automatically propagate to: construction organization design (resources, personnel, schedule), quality and safety (corresponding safety regulations and standard numbers) and commercial quotation (equipment list and cost caliber); if a conflict occurs (e.g., the quantity of equipment in the quotation is inconsistent with the technical section), it will trigger an automatic rewrite and revision.

[0060] The propagation strategy of GlobalConstraintPool is as follows: Forced injection: For hard_constraints[], directly write to generate hints and validators; if inconsistencies are found, it must be rewritten. Flexible guidance: If soft_constraints[] is not satisfied, points will be deducted during evaluation and a prompt for supplementation will be given, without necessarily rewriting it.

[0061] Propagation granularity: Variable level (numerical value / model); specifically, constraints on specific numerical values ​​or models (such as equipment capacity, quantity, construction period, etc.) to ensure data consistency across chapters.

[0062] Statement level (commitment definition); specifically, constraints on the commitment definition (such as the requirement that the description in the technical solution must be consistent with the commitment in the business terms) to avoid semantic contradictions.

[0063] At the structural level (consistent chapter outlines); constraints on chapter outlines and logical structures (such as directory hierarchy and corresponding table formats) are used to ensure a unified overall document framework.

[0064] S4: Perform adversarial loop optimization on the draft based on the response score of ScoreDAG; see [link / reference] Figure 6 The specific process is as follows: S401: The generation engine (which can use the electric vertical reinforcement model) modifies the draft to obtain a manuscript that meets the requirements of writing style and structure and can be recognized by the evaluation engine.

[0065] S402: The evaluation engine simulates the scoring logic of bidding experts, compares the ScoreDAG to score the responsiveness of the document and obtains an evaluation report; responsiveness score = coverage_score + precision_score + evidence_score + consistency_score - risk_penalty. Specifically, the responsiveness score is assessed by the coverage score, which evaluates whether the content fully covers all requirements of the scoring points (ScoreNode). For example, if the scoring details require 5 technical points, but the content only mentions 3, the score will be low. The precision score evaluates the accuracy of the content in matching hard constraint parameters (such as equipment model, standard number). For example, if the tender requires "voltage level of 10KV", but the generated content is "12KV", the precision score will be deducted. The evidence score evaluates whether verifiable evidence (such as certificate number, qualifications, case data, etc.) is cited; a lack of specific evidence or only vague descriptions will lower the score. The consistency score evaluates the consistency of the content with the global constraint variable pool (GlobalConstraintPool) to avoid cross-chapter contradictions, such as inconsistencies between the number of devices in the technical solution and the quotation section. The compliance score, risk_penalty, is a deduction item that addresses risks that may directly lead to the rejection of the bid (such as adding blind bidding information, lack of qualifications, deviation from hard threshold parameters, etc.). The penalty value is usually high to prioritize avoiding the risk of rejection.

[0066] The evaluation report includes: node_scores{node_id:score}, deduction_reasons[] (missing, off-topic, contradictory, lack of evidence, format mismatch, etc.), fatal_flags[] (risk warning for rejection / cancellation), cross-chapter contradiction location contradictions[] (location, variables, suggested changes, etc.), and executable revision actions[] (rewriting paragraphs, adding evidence, replacing parameters, etc.).

[0067] S403: Compare the response score with a preset threshold (which can be obtained based on experience, set manually, or obtained by scoring excellent tenders, etc.); if it is lower than the preset threshold or fatal_flags[] is found, then proceed to step S404; otherwise, proceed to step S405. S404: Obtain revise_actions[] as revision constraints and feed them back to the generation engine. The generation engine performs a partial rewrite of the manuscript (only rewrites the relevant paragraphs of a certain node) or a global rewrite (refreshes the whole book after adjusting key parameters), and then executes step S402. S405: Output the optimized document.

[0068] The specific process is as follows: The evaluation engine indicated: "Insufficient technical solution node coverage: Failed to meet the test method requirements of the DL / T xxxx standard"; "Rejection risk: No 'test report' evidence catalog item provided."

[0069] Generate revise_actions: supplement the standard response paragraph (cite the standard number, test method overview), automatically generate an "evidence catalog" and place it in the attachment.

[0070] The generation engine partially rewrites the relevant paragraphs based on revise_actions and re-scores them until the threshold is reached.

[0071] S5: Format and deliver the optimized document from step S4 to obtain the tender document, as follows: Figure 7 The diagram shows a relatively conventional process; detailed descriptions are omitted in this embodiment. The requirements are as follows: (1) Use enhanced Markdown (including semantic tags) uniformly: for example: [SCORE_NODE:xxx], [EVIDENCE:cert], [RISK:anonymity]; (2) Markdown-to-Office dynamic rendering; (3) Parse semantic tags → Map Word styles (Heading level, table style, numbering, table of contents); (4) Automatically generate standard tables from "Response Table", "Deviation Table" and "Evidence Catalog"; (5) Output: Word (.docx) / PDF / response form attachment package, which can be submitted directly.

[0072] The style mapping table for semantic tag layout is shown below: [SCORE_NODE: Qualification] → Heading 2 + "Qualification Response" fixed paragraph header template; [EVIDENCE: Certificate] → Form: Certificate Name / Number / Validity Period / Attachment Page Number; [PARAM_TABLE] → Device parameter lookup table style (row shading, column width); [RISK:Blind Mark] → Red annotation (internal version only) or automatic removal of sensitive fields (external version).

[0073] Example 3 Example 3 provides an intelligent tender document generation system based on tender document topology modeling, including: The tender document parsing module is used to parse tender documents.

[0074] The scoring criterion topology graph construction module (DAG Builder) is used to construct the scoring criterion topology graph ScoreDAG.

[0075] The Semantic Anchor module is used to obtain the AnchorConstraintSet, which is the semantic anchoring constraint set corresponding to each ScoreNode in the ScoreDAG.

[0076] The Knowledge Graph Construction and Retrieval Module (KG / GraphRAG) is used to structure historical tender documents. It uses ScoreDAG and its corresponding AnchorConstraintSet as input to perform knowledge graph retrieval in the knowledge database and performs high-scoring path matching on the retrieval results to obtain evidence packages.

[0077] The chapter generation and arrangement module (Composer / Orchestrator) is used to generate chapters based on the tender documents and evidence packages and perform consistency checks, from which drafts are obtained.

[0078] The Constraint Propagation Engine is used to constrain chapters through the GlobalConstraintPool when generating chapters.

[0079] The adversarial loop optimization module is used to perform adversarial loop optimization on the draft based on the response score of ScoreDAG.

[0080] The Semantic Tag Layout and Rendering Module (Markdown-to-Office Renderer) is used to layout and deliver tender documents from the documents optimized by the adversarial closed-loop optimization module.

[0081] Specifically, the anti-loop optimization module includes: The Generato engine is used to modify drafts to produce manuscripts that meet the requirements of writing style and structure and can be recognized by the evaluation engine.

[0082] The evaluation engine (Discriminator) is used to simulate the scoring logic of bidding experts, and to score the responsiveness of the manuscript according to the ScoreDAG and generate an evaluation report.

[0083] The Adversarial Loop Controller compares the responsiveness score with a preset threshold. If the score is lower than the preset threshold or if fatal_flags[] is found in the evaluation report, the revise_actions[] in the evaluation report is retrieved as a revision constraint and fed back to the generation engine, allowing the generation engine to perform a partial or global rewrite of the document. Otherwise, the optimized document is output.

[0084] The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A method for intelligently generating tender documents based on topology modeling of tender documents, characterized in that, The method includes: S1: Parse the tender documents and construct the scoring criteria topology graph ScoreDAG, and obtain the semantic anchoring constraint set AnchorConstraintSet corresponding to each scoring node ScoreNode in ScoreDAG; S2: Using ScoreDAG and the corresponding AnchorConstraintSet as input, perform knowledge graph retrieval in the knowledge database, and obtain the evidence package by high-scoring path matching of the retrieval results; S3: The large language model generates a draft based on the tender documents and evidence package. When generating the draft, all chapters are constrained through the global constraint variable pool GlobalConstraintPool, and consistency checks are performed at the same time. S4: Perform adversarial closed-loop optimization on the draft based on the response score of ScoreDAG; The responsiveness score is derived from the coverage score, precision score, evidence score, consistency score, and risk penalty score. The coverage_score is used to determine whether the content fully covers all the requirements of the ScoreNode. The precision_score is used to evaluate the degree of matching between the content and the hard_constraints[] in AnchorConstraintSet. The evidence_score is used to evaluate whether a verifiable evidence package has been provided. The consistency_score is used to evaluate the consistency of content with the GlobalConstraintPool. The risk_penalty is used to evaluate whether to trigger the risk_flags[] in AnchorConstraintSet; S5: Format and deliver the manuscript obtained from step S4 to produce the tender document.

2. The method according to claim 1, characterized in that, The ScoreNode includes a unique identifier node_id, a type node_type, a scoring item name title, a corresponding original text segment in the tender document raw_text_span, a score / weight weight, a list of response requirements[], evidence types[], semantic anchoring constraints anchor_constraints[], potential rejection / blind bid risk flags risk_flags[], and the upstream nodes dependencies[] that it depends on. The knowledge database includes historical tender documents, company personnel information, company qualification information, and industry standards; AnchorConstraintSet is obtained by classifying anchor_constraints[]. AnchorConstraintSet includes hard_constraints[], soft_constraints[], forbidden_patterns[], and / or coverage_targets[], which must appear and cannot be changed. The GlobalConstraintPool is derived from the key variables extracted after generating each chapter in step S3. These variables include entity statements (entity_constraints), numeric statements (numeric_constraints), commitment statements (commitment_constraints), variable source traces (trace_links), and conflict rules (conflict_rules).

3. The method according to claim 2, characterized in that, The process of parsing the tender documents and constructing the ScoreDAG scoring criterion topology graph specifically includes: S101: Obtain the tender documents; S102: Perform structured parsing of the tender documents; S103: Obtain scoring information; S104: Obtain the corresponding "Bidding Requirements - Scoring Details - Score Weights" triplet based on the scoring information; S105: ScoreNode is constructed from triples; S106: Identify dependencies between ScoreNodes; identify dependencies according to the following rules: (1) If the clause contains "must / otherwise veto / if not met, the bid will be rejected", it shall be used as a prerequisite for qualification / veto point; (2) If the scoring item references the qualifications / certificates mentioned above, then establish a dependency edge; (3) If the technical solution evaluation depends on the equipment parameter response, then the equipment parameter node is a prerequisite qualification node; S107: ScoreDAG is constructed from ScoreNode and its dependencies; S108: Determine if the ScoreDAG is cyclic. If not, output the result; otherwise, break the cycle according to the following rules: If a circular dependency is detected, the loop will be broken according to the order of "veto > qualification > technology > business > bonus".

4. The method according to claim 3, characterized in that, The specific steps of obtaining the semantic anchoring constraint set AnchorConstraintSet corresponding to each score node ScoreNode in ScoreDAG include: S111: Select ScoreNode; S112: Identify anchor_constraints[], which includes numerical values / ranges, standards / specifications, certificates / certifications, and project duration / milestones; S113: Classify anchor_constraints[] to obtain AnchorConstraintSet.

5. The method according to claim 4, characterized in that, Step S2 specifically includes: S201: Structure the files in the knowledge database into a graph entity relationship of "project type - scoring node type - technical parameters - expert evaluation"; S202: Using ScoreDAG and the corresponding AnchorConstraintSet as input, perform knowledge graph retrieval in the knowledge database to obtain several evidence chains that best match the scoring node; the evidence chains include case paragraphs, parameter tables, and certificate citation templates; S203: Obtain a package of evidence for chapter arrangement from several chains of evidence based on the manuscript acquisition strategy, the rules of which are as follows: (1) For high-weight nodes, retrieve stronger evidence and longer chains of argumentation; (2) For veto nodes, generate a hard response table and an evidence catalog.

6. The method according to claim 5, characterized in that, The specific steps of constraining all chapters through the global constraint variable pool GlobalConstraintPool include: when each chapter is generated, existing constraints are read from GlobalConstraintPool and constrained for the generation of the chapter; after the chapter is generated, key variables are obtained as constraints and written into GlobalConstraintPool to constrain subsequent chapters; the key variables include equipment model, quantity, construction period and / or standard number; The consistency check specifically includes: after each chapter is generated, a consistency check is performed; the rules for consistency check are: different values ​​for the same variable, inconsistent unit conversions, or contradictory versions of the same commitment constitute a conflict; once a conflict occurs, modification suggestions are generated and the chapter is regenerated; if there is no conflict, the next chapter is proceeded. Once all chapters are generated, a draft will be obtained and a conflict list will be output.

7. The method according to claim 4, characterized in that, Step S4 specifically includes: S401: The generation engine modifies the draft to obtain a manuscript that meets the requirements of writing style and structure and can be recognized by the evaluation engine. S402: The evaluation engine simulates the scoring logic of bidding experts, compares the ScoreDAG to score the responsiveness of the manuscript and obtains an evaluation report; the responsiveness score = coverage_score + precision_score + evidence_score + consistency_score - risk_penalty; the evaluation report includes: node-by-node score node_scores{node_id:score}, deduction_reasons[], fatal_flags[], cross-chapter contradiction location contradictions[], and executable revision actions revise_actions[]; S403: Compare the response score with a preset threshold; if it is lower than the preset threshold or fatal_flags[] is found, proceed to step S404; otherwise, proceed to step S405. S404: Obtain revise_actions[] as revision constraints and feed them back to the generation engine. The generation engine performs local or global rewriting of the document and then executes step S402. S405: Output the optimized document.

8. An intelligent tender document generation system based on topology modeling of tender documents, characterized in that, include: The tender document parsing module is used to parse tender documents. The scoring criterion topology graph construction module is used to construct the scoring criterion topology graph ScoreDAG; The semantic anchoring module for scoring nodes is used to obtain the semantic anchoring constraint set AnchorConstraintSet corresponding to each scoring node ScoreNode in ScoreDAG; The knowledge graph construction and retrieval module is used to structure historical tender documents, and to perform knowledge graph retrieval in the knowledge database using ScoreDAG and its corresponding AnchorConstraintSet as input. The retrieval results are then matched with high-scoring paths to obtain evidence packages. The chapter generation and arrangement module is used to generate chapters based on the tender documents and evidence packages and perform consistency checks, from which drafts are obtained; The cross-chapter constraint propagation module is used to constrain chapters through the global constraint variable pool GlobalConstraintPool when generating chapters; The adversarial loop optimization module is used to perform adversarial loop optimization on the draft based on the response score of ScoreDAG. The semantic tag layout and rendering module is used to layout and deliver tender documents from the text optimized by the adversarial closed-loop optimization module.

9. The system according to claim 8, characterized in that, The adversarial closed-loop optimization module includes: The generation engine is used to modify drafts to obtain manuscripts that meet the requirements of writing style and structure and can be recognized by the evaluation engine. The evaluation engine simulates the scoring logic of bidding experts, scores the responsiveness of the document against the ScoreDAG, and generates an evaluation report. The adversarial iteration control unit is used to compare the responsiveness score with a preset threshold. If it is lower than the preset threshold or if fatal_flags[] is found in the evaluation report, the revise_actions[] in the evaluation report is obtained as a revision constraint and fed back to the generation engine, so that the generation engine can rewrite the document locally or globally. Otherwise, the optimized document is output.

10. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method as described in any one of claims 1-7.

Images