Intelligent tender document generation system and method based on large model
By constructing an intelligent tender document generation system based on a large model, the problems of low efficiency, unstable quality, and high compliance risks in traditional tender document preparation have been solved. This system enables efficient, professional, and personalized tender document generation and knowledge management, thereby improving the efficiency and competitiveness of enterprises in bidding.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- ANHUI TELECOMM PLANNING & DESIGNING
- Filing Date
- 2026-03-02
- Publication Date
- 2026-06-12
Smart Images

Figure CN122197846A_ABST
Abstract
Description
Technical Field
[0001] This invention belongs to the fields of artificial intelligence, natural language processing, big data and document automation generation technology, and particularly relates to an intelligent tender document generation system and method based on a large model. Background Technology
[0002] In commercial sectors such as engineering construction, product procurement, and technical services, bidding is a crucial step in project contracting. The bid document, as the core document responding to the tender, directly determines the success or failure of the bid. A high-quality bid document requires complete content, standardized format, and precise alignment with the tender requirements in terms of technical solutions and commercial terms, fully demonstrating the bidder's competitiveness. Therefore, the professionalism, efficiency, and compliance of bid document preparation are of paramount importance.
[0003] However, the traditional manual tender document preparation model has several prominent pain points: First, it is inefficient and involves a lot of repetitive work. Tender document preparation requires repeatedly building document structures, reusing qualification documents, and filling in basic information, consuming a lot of manpower and time, and the efficiency bottleneck is particularly significant in intensive bidding scenarios; Second, the quality of content is inconsistent. The quality of tender documents depends on the experience of the preparers. Novices are prone to omitting key clauses and using unprofessional expressions. Tender documents prepared by different personnel have different styles, making it difficult to ensure a consistent external image for the company; Third, information management is fragmented, with core information such as company qualifications, performance, and technical parameters being scattered. The data is stored in a scattered manner, requiring collection from multiple sources during preparation. This can easily lead to the use of outdated or inaccurate information, resulting in bid rejection. Fourth, there are high risks to compliance and matching. The requirements for bidding documents are complex, and manual review can easily lead to errors. The descriptions of technical parameters and service commitments may have compliance flaws. Fifth, collaboration is difficult. Large bids require collaboration among multiple departments, resulting in high communication costs, chaotic version management, and a high risk of content conflicts or omissions. Sixth, the ability to reuse knowledge is weak. The experience and skills of successful bids are accumulated by individuals and have not formed a shared enterprise-level asset. Each bid is almost "starting from scratch".
[0004] While existing tender document preparation software or template tools on the market offer basic format templates and fill-in-the-blank functions, they still have significant limitations: insufficient intelligence, only able to fill in fixed templates and unable to dynamically adjust content according to tender requirements; data silos, with modules such as templates, qualifications, and performance records operating independently, lacking a unified and interconnected knowledge base; lack of contextual understanding capabilities, making it difficult to deeply analyze the core requirements of tender documents, resulting in insufficiently targeted content; and lack of continuous learning capabilities, unable to summarize experience from historical bidding data, making it difficult to adapt to the ever-changing demands of the tendering market.
[0005] In summary, existing technologies cannot fundamentally solve the problems of low efficiency, inconsistent quality, high risk, and difficulty in knowledge reuse in traditional bid preparation. Therefore, there is an urgent need for a system that deeply integrates with enterprise knowledge bases, possesses powerful natural language understanding and generation capabilities, and can achieve intelligent, standardized, and personalized bid generation to improve enterprise bidding efficiency, quality, and core competitiveness, and meet the urgent needs of industry development. Summary of the Invention
[0006] This invention aims to address the problems of low efficiency, unstable quality, chaotic information management, high compliance risks, and insufficient intelligence of existing tools in the manual preparation of tender documents. It provides an intelligent tender document generation system and method based on a large-scale model. Specifically, it aims to: construct a centralized, structured, and dynamically updatable enterprise bidding knowledge base to achieve unified management of core data assets such as templates, qualifications, performance, and technical parameters; leverage the powerful understanding and generation capabilities of a large-scale language model to intelligently analyze bidding documents and automatically generate tender document content, significantly improving preparation efficiency; ensure that the generated content deeply matches the bidding requirements, possessing both professionalism and compliance, and reduce the risk of human error through intelligent review; support flexible personalized customization and multi-person collaborative editing, while ensuring the consistency and professionalism of the company's external output; and establish a closed-loop optimization mechanism based on bidding result feedback to drive the continuous evolution of the knowledge base and generation model, comprehensively enhancing the enterprise's bidding competitiveness.
[0007] To achieve the above objectives, the technical solution adopted by the present invention is as follows:
[0008] A smart tender document generation system based on a large model includes the following modules:
[0009] Unified Knowledge Base Management Module: As the data hub of the system, it is used for structured storage and management of all knowledge assets related to tender document generation, ensuring the uniqueness, accuracy and timeliness of the data; the unified knowledge base management module includes a template library management submodule, a company qualification library management submodule, a historical performance library management submodule and a technical parameter library management submodule;
[0010] Large-scale intelligent processing engine module: As the intelligent core of the system, it calls upon a large-scale language model to achieve deep semantic understanding of bidding documents, intelligent generation and optimization of bidding content, and multi-dimensional review of the initial draft of bidding documents; the large-scale intelligent processing engine module includes a bidding document intelligent parsing submodule, an intelligent content generation and filling submodule, and an intelligent review and optimization submodule;
[0011] Human-computer collaborative editing and process management module: This module provides an interactive interface to support fine-grained editing, enabling multi-person collaboration and process control. The human-computer collaborative editing and process management module includes a visual editing interface unit, a task decomposition and collaboration unit, a version history and difference comparison unit, and an audit process configuration unit.
[0012] The bidding data feedback and model optimization module is used to realize the input of bidding results, data association, and closed-loop evolution of the system. The bidding data feedback and model optimization module includes a bidding result input unit, a data association unit, and a model fine-tuning and knowledge optimization unit.
[0013] A method for generating intelligent tender documents based on a large model includes the following steps:
[0014] S1: Project Creation and Tender Document Parsing: Users create projects and upload tender documents. The system calls the parsing submodule of the large model intelligent processing engine. By improving the named entity recognition algorithm of BERT, the core requirements, scoring rules and compliance clauses of the tender are extracted in a structured manner to complete the parsing of the tender documents.
[0015] S2: Knowledge Base Matching and Data Preparation: Relying on the unified knowledge base management module, based on the parsed project features, the knowledge graph association reasoning algorithm is used to link the qualification database, performance database, and technical parameter database to screen and match valid qualifications, related performance and suitable parameters, and form a structured dataset after standardization.
[0016] S3: Template Matching and Intelligent Generation: The template library submodule of the unified knowledge base recommends a baseline template, which is then filled into the structured data by the generation submodule of the big model intelligent processing engine through the template semantic mapping algorithm. For unstructured content, the big model generates narrative text based on bidding requirements, related performance and technical parameters to form the initial draft of the tender document.
[0017] S4: Human-computer collaborative editing and review: Users review and modify the initial draft of the tender document through the human-computer collaborative editing module; the system synchronously calls the large model intelligent review algorithm to complete the response integrity, compliance and consistency verification and provide optimization suggestions, supporting multi-person collaboration and online review workflow;
[0018] S5: Final Draft Output and Archiving: After the tender document is finalized, it can be exported in a specified format with one click. The unified knowledge base module completes the standardized naming and full-process archiving to ensure data traceability.
[0019] S6: Results Feedback and Model Iteration: Input the bidding results, establish the connection between the results and information such as the bid documents and knowledge base through the bidding data feedback module, and use reinforcement learning algorithms to optimize the template recommendation and large model generation logic, so as to precipitate high-quality content into knowledge assets and realize the closed-loop evolution of the system.
[0020] Furthermore, step S1, leveraging system functionality and an improved BERT named entity recognition algorithm, transforms unstructured / semi-structured bidding documents into a structured core information set, providing accurate input for subsequent bid generation. This step consists of four sub-steps:
[0021] S1.1 Project Creation and File Upload: Users can enter basic metadata such as project name, bidding unit, project manager, and bid deadline through the system's visual interface. The system automatically generates a unique project ID. It supports uploading bidding documents in formats such as PDF, DOCX, and TXT. For scanned PDFs, OCR technology is used to recognize the text, and the file parsing engine completes the format parsing and standardized plain text stream output.
[0022] S1.2 Preprocessing of tender documents: First, the text is cleaned to remove redundant information such as special characters, headers and footers, and page numbers; then, based on the jieba word segmentation tool, the word segmentation effect is optimized by combining a tender field dictionary containing professional terms such as qualification requirements and scoring rules, and at the same time, sentences are segmented according to punctuation marks to generate word segmentation sequences;
[0023] S1.3 Improved BERT Named Entity Recognition Algorithm Core Information Extraction: Addressing the insufficient recognition accuracy of the general BERT in the bidding domain, the model is optimized in three aspects: First, a domain-adaptive embedding layer is added between the original BERT embedding layer and the encoder layer, fusing token word embedding, position embedding, segment embedding, and domain embedding to generate the final embedding vector; second, a domain attention mask matrix is introduced into the encoder layer's self-attention mechanism to force the model to focus on domain entities and optimize attention weight calculation; third, a conditional random field is used as the decoding layer, achieving accurate entity boundary recognition based on the BIOS tag system; model training uses the AdamW optimizer, setting a learning rate of 2e-5, batch size of 16, and training epochs of 10, and employing an early stopping strategy to prevent overfitting;
[0024] S1.4 Structured Parsing Output: Using the improved algorithm described above, key information such as core requirements, scoring details, and compliance clauses in the tender documents are extracted and output in JSON format.
[0025] Furthermore, step S2, based on the structured project features output by S1, relies on the unified knowledge base management module and uses a knowledge graph association reasoning algorithm to accurately match valid data from multiple databases and complete standardization processing, forming a structured dataset that can be directly used for tender document generation. This step consists of four sub-steps:
[0026] S2.1 Unified Knowledge Base Architecture and Initialization: A unified knowledge base is built using a hybrid architecture of structured database and knowledge graph. The structured database is built on MySQL 8.0 and includes three sub-databases: qualification database, performance database, and technical parameter database, with corresponding fields designed for each. The knowledge graph is built on Neo4j and defines four types of entities: project features, qualifications, performance, and technical parameters, as well as three types of relationships: adaptation, association, and inclusion. Initialization is completed by importing historical data through an ETL tool to establish initial relationships between entities.
[0027] S2.2 Project Feature Extraction and Vector Representation: Feature vectors of project type, scale, technical standards, etc. are extracted from the structured analysis results of S1; textual features are encoded into 768-dimensional vectors using an improved BERT model, and numerical features are normalized; the two types of feature vectors are concatenated to generate the final project feature vector, providing a data foundation for subsequent association reasoning;
[0028] S2.3 Knowledge Graph Association Reasoning and Data Matching: An improved TransR algorithm is used to realize knowledge graph association reasoning. By introducing project feature attention weights to optimize the mapping matrix between entities and relationships, the reasoning is enhanced to better fit the current project requirements. Based on the optimization algorithm, the similarity between project features and qualifications / performance / technical parameters is calculated, and a threshold of 0.7 is set to filter entities that meet the requirements. By leveraging the association relationships of the knowledge graph to link the three sub-databases, the required qualifications, similar performance, and suitable technical parameters of the project are accurately matched.
[0029] S2.4 Data Standardization and Structured Dataset Generation: First, the matching data is cleaned to remove duplicates and invalid items; then, the data format is standardized according to the tender document generation specifications; finally, the standardized data is organized according to the hierarchical structure of tender document chapter-data type-data content, and a structured dataset in JSON format is output.
[0030] Furthermore, step S3 recommends the optimal benchmark template based on project features, fills the structured data using a template semantic mapping algorithm, and generates unstructured narrative content using a large model. Finally, these are integrated to form the initial draft of the tender document, which consists of four sub-steps:
[0031] S3.1 Template Library Construction and Feature Representation: The template library sub-module of the unified knowledge base is classified into three levels: industry, project type, and tender document type. It stores DOCX format template files and metadata such as template ID, applicable scenarios, chapter structure, and placeholder list. It adopts the same improved BERT model as the project feature encoding to text-encode the applicable scenario description and chapter structure of the template, generating a template feature vector with a dimension of 768, providing data support for template matching.
[0032] S3.2 Benchmark Template Recommendation Algorithm: A hybrid recommendation algorithm of feature similarity and collaborative filtering is used to select benchmark templates: First, the cosine similarity between the project feature vector and the template feature vector is calculated, and then the collaborative filtering score is calculated based on historical bidding data; the comprehensive score of the template is calculated according to the weight formula, and the top 3 templates are selected for users to choose from, thus determining the final benchmark template;
[0033] S3.3 Template Semantic Mapping and Structured Data Filling: Parse the baseline template to extract placeholders such as qualification names and perform semantic encoding to generate a 768-dimensional placeholder vector; calculate the attention weight between the placeholder vector and the S2 structured data field vector through an attention mechanism, and fill the field data with the highest weight into the corresponding placeholder; at the same time, verify whether the format of the filled data meets the template requirements. If it does not meet the requirements, trigger secondary data standardization processing to ensure that the filled content is compliant.
[0034] S3.4 Unstructured Content Generation and Initial Proposal Construction: For unstructured sections without placeholders, such as the technical solution overview and project implementation plan, construct a structured Prompt containing project requirements, related achievements, technical parameters, and generation requirements; set large model parameters to generate logically rigorous and formally presented narrative text; finally, integrate the structured data filling results with the unstructured generated text, organize the content according to the baseline template chapter structure, generate a DOCX format initial proposal, and save the generation log, including generation time, data used, and large model parameters.
[0035] Furthermore, step S4 optimizes the initial draft of the tender document through a human-machine collaborative mode, comprehensively ensuring the completeness, compliance, and consistency of the tender document's response, supporting multi-person collaborative operation and review workflow, and is divided into 4 sub-steps:
[0036] S4.1 Human-Computer Collaborative Editing Module Deployment: Provides a web-based visual editing interface, supports text modification, format adjustment, and attachment insertion, and adopts an incremental storage strategy to save only the modified content for real-time backup; configures multi-role permissions to distinguish between modification, annotation, and other operation permissions; enables real-time collaborative editing by multiple users through WebSocket technology, adopts a last-editor priority strategy to resolve editing conflicts, and retains historical versions for backtracking;
[0037] S4.2 Large-Scale Intelligent Review Algorithm Design: Constructing a multi-dimensional review system covering three core dimensions: First, response integrity review, which calculates the matching degree by combining keyword matching and semantic similarity verification; if the score is below 0.8, a list of unmatched requirements is output. Second, compliance review, which verifies format requirements by using regular expression matching and checks substantive requirements by using domain-wide large-scale model semantic understanding, generating a compliance score of 0-100; if the score is below 60, an alert is triggered. Third, consistency review, which verifies the consistency of the expression of the same information in different chapters by calculating text similarity; if the score is below 0.9, inconsistent information and its corresponding chapter are marked.
[0038] S4.3 Optimization Suggestion Generation and Review Process: The large model generates targeted optimization suggestions based on the review results, clearly pointing out unresponsive requirements, compliance issues, and inconsistencies in expression, and providing directions for correction; it supports online review process, where users can submit tender documents and review results to designated reviewers, who can approve comments, return for revision, or confirm approval. The entire process records the reviewer, time, and opinions, ensuring traceability.
[0039] S4.4 Editing and Secondary Review: Users modify the tender document based on the review comments and optimization suggestions. After the modification is completed, a secondary review can be initiated. The secondary review only verifies the modified parts to improve efficiency. If the secondary review fails, the modification-review process must be repeated until the tender document is approved.
[0040] Furthermore, step S5 achieves standardized export and full-process archiving of tender documents, ensuring the traceability of project data, and is divided into 3 sub-steps:
[0041] S5.1 Final Confirmation of Tender Documents: After the tender documents are approved, the user confirms the final version. The system then locks the version, generates a unique identifier for the final version, and records the person who confirmed the final version and the confirmation time to ensure the version's authority and traceability.
[0042] S5.2 One-Click Export in Multiple Formats: Utilizes a format conversion engine to export tender documents in multiple formats, supporting DOCX, PDF, PDF / A, etc.; PDF compression level can be set to 60% to balance file size and clarity, ensuring PDF / A format compatibility with the PDF / A-2b standard; Custom watermark functionality is supported, allowing users to set watermark content such as bid-specific watermarks, as well as parameters such as position, transparency, and font; Batch export of multiple format files is supported, and automatic packaging into a ZIP archive for convenient user download.
[0043] S5.3 Standardized Naming and Full-Process Archiving: Exported and archived files adopt a unified naming rule: Bidding Unit - Project Name - Tender Type - Final Draft Time - Format Suffix; The unified knowledge base module completes the full-process archiving. On the one hand, it stores structured data such as project metadata, final draft identifiers, export records, and review records into a MySQL database and establishes a relationship. On the other hand, it stores various format files of the final tender document, qualification scans, and other attachments into a distributed file server, with file paths bound to database metadata; Through the project ID, the entire process of data, including parsing, matching, editing, reviewing, and archiving, can be linked and queried to achieve data traceability.
[0044] Furthermore, step S6 establishes the correlation between bidding results and data throughout the entire process, optimizes the model logic through reinforcement learning algorithms, accumulates high-quality knowledge assets, and achieves closed-loop evolution of the system. This step is specifically divided into four sub-steps:
[0045] S6.1 Bidding Result Input and Data Association: Users input bidding result information, including the winning status, winning bid amount, judges' comments, reasons for not winning / rejecting the bid, etc.; the system establishes association between the results and the entire process information such as bid document content, knowledge base data, generation logs, and review records through the bidding data feedback module, and stores them in a unified data warehouse to provide data support for subsequent model optimization;
[0046] S6.2 Reinforcement Learning Model Construction and Optimization Objectives: Construct a reinforcement learning model with a template recommendation module and a large model generation module as agents. Define project feature vectors and historical bidding data features as states, and template recommendation selection, large model generation parameter adjustment, and text semantic style adjustment as actions. Set a reward function based on bidding results, and introduce bid approval rate and response integrity score as auxiliary rewards. The optimization objective is to maximize the cumulative reward and improve the accuracy of template recommendation and the quality of generated text.
[0047] S6.3 Model Iterative Training and Parameter Update: Extract ≥1000 historical bidding data from the data warehouse and divide the training set and test set in an 8:2 ratio; train the model using the DQN algorithm combined with the experience replay mechanism, and update the model parameters through the loss function; after training, synchronize the optimized parameters to the template recommendation module and the large model generation module, and set the iteration cycle to once a month or once every 200 accumulated bidding projects;
[0048] S6.4 High-Quality Content Accumulation and Knowledge Asset Building: Based on the bidding results and judges' comments, high-quality content in the winning bids is selected and included in the candidate knowledge assets after manual review; the high-quality content is categorized by industry, project type, and chapter, and updated to the template library and technical parameter library of the unified knowledge base, while optimizing the entity relationship of the knowledge graph; the accumulated knowledge assets feed back into the subsequent bid generation process, realizing the closed-loop evolution of the system.
[0049] Furthermore, the specific steps of S2 are as follows:
[0050] S2.1 Unified Knowledge Base Architecture and Initialization
[0051] The unified knowledge base adopts a hybrid architecture of structured database and knowledge graph, specifically including: Structured database: using MySQL 8.0 to store qualification database, performance database, and technical parameter database, with the table structure design as follows:
[0052] Qualification Database: Fields include qualification ID, qualification name, qualification level, issuing authority, validity period, and path to the scanned copy of the qualification; Performance Database: Fields include performance ID, project name, project type, contract amount, completion time, client, and project deliverables description; Technical Parameter Database: Fields include parameter ID, parameter category, parameter name, standard value, applicable scenario, and associated technical solution.
[0053] Knowledge graph: Built using Neo4j, entity types include project characteristics, qualifications, performance, and technical parameters, and relationship types include adaptation, association, and inclusion. During knowledge graph initialization, historical data is imported through an ETL tool to establish initial relationships between entities.
[0054] S2.2 Project Feature Extraction and Vector Representation
[0055] Extract the project feature vector from the structured analysis results output by S1: Where m is the feature dimension, and the features include project type, scale, technical standards, qualification requirements, delivery cycle, etc.; an improved BERT model is used to vectorize textual features, resulting in a feature vector of dimension 768, while numerical features are normalized.
[0056]
[0057] Finally, the project feature vector is obtained through feature concatenation. k is the number of numerical features;
[0058] S2.3 Knowledge Graph Association Reasoning and Data Matching
[0059] An improved TransR algorithm is used to perform associative reasoning on knowledge graphs, accurately matching data that is suitable for project features:
[0060] TransR algorithm optimization: Introduce project feature attention weights and adjust the mapping matrix between entities and relationships to make inference more aligned with the current project requirements. The mapping formula is as follows:
[0061]
[0062] in: The head entity in the knowledge graph is the project feature, and the tail entity is the qualification / performance / technical parameter vector, with 100 dimensions. : The mapping matrix of relation r, with dimensions [100, 100]; : Project feature attention weight matrix, dimension [100, 768+k], learned through project feature vector F, to enhance the association weight of entities related to the current project;
[0063] Similarity calculation: The adaptation similarity between entities is calculated based on the optimized TransR algorithm, using the following formula:
[0064]
[0065] in: Create a relation vector with dimension 100; set a similarity threshold. Entities with a similarity ≥ θ are selected as matching data;
[0066] Multi-database linkage matching: Through the association relationship of knowledge graph, it links qualification database, performance database, and technical parameter database;
[0067] S2.4 Data Standardization and Structured Dataset Generation
[0068] Data cleaning: Removing duplicates and invalid items from the matched data;
[0069] Standardized format: Data format should be standardized according to the tender document generation specifications;
[0070] Structured dataset output: The standardized qualification, performance, and technical parameter data are organized according to the hierarchical structure of tender document chapter-data type-data content to generate a structured dataset in JSON format.
[0071] Furthermore, step S3 is as follows:
[0072] S3.1 Template Library Construction and Feature Representation
[0073] Template Library Classification: The template library sub-module of the unified knowledge base is classified into three levels according to industry, project type, and tender document type, storing template files and template metadata;
[0074] Template feature extraction: The applicable scenario description and chapter structure of each template are text-encoded, and an improved BERT model, identical to that used for project features, is used to generate template feature vectors. ;
[0075] S3.2 Benchmark Template Recommendation Algorithm
[0076] A hybrid recommendation algorithm combining feature similarity and collaborative filtering is used to recommend a baseline template.
[0077] Feature similarity calculation: Calculate the cosine similarity between the project feature vector F and the template feature vector T.
[0078]
[0079] Collaborative filtering score: Based on historical bidding data, calculate the similarity between the current project and historical projects, and assign extra points to high-quality templates used in historical projects.
[0080]
[0081] in: : The feature vector of the i-th historical item; The weight of historical project templates, and the corresponding weight of winning projects. =1.5, unsuccessful bids =0.8; k: number of historical projects, default k=50;
[0082] Overall Score and Template Selection: Overall Score:
[0083]
[0084] The top 3 templates with the highest overall scores are selected for users to choose from. Users can directly select or specify a template as the benchmark template.
[0085] S3.3 Template Semantic Mapping and Structured Data Filling
[0086] An attention-based semantic mapping algorithm is used to achieve accurate matching between structured data and template placeholders.
[0087] Placeholder extraction: The baseline template is parsed to extract placeholders, and each placeholder is semantically encoded to obtain a placeholder vector. ;
[0088] Semantic matching: Calculate the attention weights between the placeholder vector P and the structured data field vector Z extracted from the structured data of S2.
[0089]
[0090] in For vector dimensions; select the field data with the highest attention weight to fill the corresponding placeholders;
[0091] Fill rule validation: Validate whether the format of the filled data conforms to the template requirements. If it does not, trigger secondary data standardization processing.
[0092] S3.4 Unstructured Content Generation and Initial Proposal Construction
[0093] For unstructured chapters without placeholders in the template, a large model generation submodule is used to generate narrative text:
[0094] Prompt Engineering Design: Build a structured Prompt, including project requirements, relevant performance, technical parameters, and generation requirements;
[0095] Large model generation parameters: temperature parameter T=0.7, maximum generation length max length =1024, top p =0.9;
[0096] Initial draft integration: Integrate the results of structured data filling with the results of unstructured text generation, organize the content according to the chapter structure of the benchmark template, generate an initial draft of the tender document in DOCX format, and save the generation log at the same time.
[0097] The present invention has the following beneficial effects:
[0098] Leapfrog efficiency improvement: Automated completion of repetitive tasks such as information collection, data filling, and formatted document generation frees compilers from tedious copy-pasting and basic formatting adjustments, allowing them to focus more on the core ideas and strategy formulation of the proposal. The tender preparation cycle can be shortened by more than 50%.
[0099] Quality Standardization and Professionalism: A unified knowledge base ensures the accuracy and timeliness of all data referenced in tender documents. The content generated by the large model is characterized by standardized language and clear logic. Combined with standard templates, this guarantees the professional level and consistent image of the company's external output documents, greatly reducing basic errors.
[0100] In-depth responsiveness and compliance assurance: The system ensures a comprehensive and accurate understanding of the tender requirements through intelligent analysis, and fills in any gaps through intelligent review, which significantly improves the responsiveness and compliance of the tender documents with the tender documents and reduces the risk of bid rejection due to oversight.
[0101] Knowledge assetization and efficient reuse: Systematically and structurally manage core knowledge such as company qualifications, performance, and technical solutions that are scattered among individuals, forming sustainable and reusable digital assets. New employees can also quickly generate high-quality tender documents that meet company standards.
[0102] Intelligent decision support: The system can not only generate content, but also provide suggestions on content focus and competitiveness analysis based on historical data and bidding requirements, assisting the bidding team in making more scientific strategic decisions.
[0103] Achieving closed-loop learning and continuous evolution: The unique feedback optimization mechanism enables the system to learn from each bidding practice, continuously optimize its generation capabilities and knowledge base quality, making the system "smarter" the more it is used, and continuously consolidating and enhancing the company's bidding competitiveness. Attached Figure Description
[0104] Figure 1 This is a flowchart of an intelligent tender document generation method based on a large model proposed in this invention. Detailed Implementation
[0105] The present invention will be further described in detail below with reference to specific embodiments. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.
[0106] A large-scale intelligent tender document generation system, comprising the following core modules:
[0107] 1. Unified Knowledge Base Management Module
[0108] This module serves as the system's data hub, used for structured storage and management of all knowledge assets related to tender document generation, ensuring the uniqueness, accuracy, and timeliness of the data. Specifically, it includes:
[0109] Template library management submodule:
[0110] Functions: Centrally store and manage various tender document templates, including but not limited to commercial tender document templates, technical tender document templates (such as construction organization designs, technical solutions, implementation plans, etc.), qualification certificate templates, and commitment letter templates. Supports multi-dimensional classification and tagging management by industry, project type, and tenderer category.
[0111] Features: Structured Templates: Templates are not simple Word documents, but are defined using structured formats such as XML or JSON, clearly identifying fixed content, variable fields (placeholders), conditional logic paragraphs, and referenced data sources (such as specific fields linked to qualification or performance databases). Version Control: Strict version management of templates, recording the history of each modification to ensure that the template used is the latest valid version. Access Control: Setting different permissions for different roles to use, create, modify, and approve templates. Customization and Derivation: Users can modify the system's standard templates to create custom templates that meet specific client or project requirements, and can save successful tender documents as new templates.
[0112] Company Qualification Database Management Submodule:
[0113] Function: Establish a company-level digital qualification center to centrally store all business and qualification documents, including business licenses, qualification certificates, safety production licenses, system certification certificates, qualification certificates of key personnel (construction engineers, engineers, etc.), financial statements, audit reports, bank credit certificates, etc.
[0114] Features: Metadata Management: Rich metadata is entered for each qualification document, such as certificate name, issuing authority, number, validity period start / end dates, associated business scope, and applicable project types. Timeliness Monitoring and Early Warning: The system automatically monitors the validity period of all qualifications and sends early warning notifications to administrators when they are close to expiration (e.g., 30 days or 7 days in advance), ensuring that the qualifications referenced in the tender documents are valid. OCR and Intelligent Parsing: Supports uploading scanned documents and automatically extracts key information (such as number and date) through OCR (Optical Character Recognition) technology, storing it in a structured format. Dynamic Reference: When the tender document is generated, a list of compliant and valid qualification documents or key information fragments can be automatically filtered and referenced according to project requirements.
[0115] Historical performance database management submodule:
[0116] Function: Systematically collect the company's past completed project achievements to form a searchable and reusable case knowledge base.
[0117] Features: Structured Information Input: Standardized information fields are defined for each performance project, such as project name, owner, contract amount, start / completion date, project location, project scale / key technical indicators, project characteristics (e.g., awards, technical challenges), project manager, and links to key supporting documents (contract, scanned acceptance report). Multi-dimensional Search: Supports quick retrieval of relevant performance data through multiple dimensions such as keywords, project type, time range, region, contract amount range, and technical keywords. Intelligent Recommendation: When generating technical tender documents, the system can automatically match and recommend the most relevant and persuasive historical cases from the performance database based on the technical characteristics and regional requirements of the current bidding project, and can generate standardized performance description paragraphs with one click.
[0118] Technical parameter library management submodule:
[0119] Function: To establish a standardized and compliant technical parameter database for the products, equipment, materials, or technical services provided by the company.
[0120] Features: Parameter Standardization: Defines a parameter system for products / technology, ensuring the professionalism and consistency of technical descriptions. Compliance Linkage: Links technical parameters with mandatory clauses of national / industry standards and regulations, ensuring that the technical responses in the tender documents fully comply with regulatory requirements. Competitive Analysis Data: Maintains parameters (public information) of similar products from major competitors for use in differentiating advantage analysis when developing technical solutions. Dynamic Generation of Technical Responses: Automatically extracts the corresponding product's technical parameters from the parameter library based on the technical specifications in the tender documents, generating standardized and accurate technical deviation tables or technical response documents.
[0121] 2. Large Model Intelligent Processing Engine Module
[0122] This module is the system's "intelligent brain," integrating or calling large-scale language models (such as GPT, Wenxin Yiyan, Tongyi Qianwen, and other series of models) to perform deep semantic understanding of the bidding documents and drive the intelligent generation and optimization of the bidding content.
[0123] Intelligent parsing submodule for tender documents:
[0124] Function: Upload tender documents (PDF, Word, etc.), and the system will automatically parse them.
[0125] Processing Flow: Document Parsing and OCR: Extracting text content and recognizing document structure (chapter, title, list). Key Information Extraction: Utilizing the large-scale model's NER (Named Entity Recognition) and information extraction capabilities, automatically identifying and structurally extracting information such as the tendering party, project name, project number, bid deadline, bid security requirements, construction / delivery period, quality requirements, scoring methods (especially the weighting and details of technical, commercial, and price aspects), rejection clauses, key technical parameters and requirements, etc. Requirement Semantic Analysis: Deeply analyzing texts such as technical requirements, service scope, and acceptance criteria to understand their core intent, implicit requirements, and key concerns. Compliance Clause Recognition: Automatically identifying mandatory clauses, commitment clauses, and legal and regulatory references in the tender documents.
[0126] Intelligent content generation and filling submodule:
[0127] Function: Based on the parsed bidding requirements and combined with the knowledge base content, automatically generate or populate the initial drafts of each part of the bid document.
[0128] Working Modes: **Template Intelligent Matching and Instantiation:** Based on project type and bidding requirements, the system automatically recommends or allows users to select the most suitable baseline template from the template library. **Data Linkage and Population:** It automatically populates the corresponding positions in the template with valid basic company information and personnel information from the qualification database, as well as project-specific information extracted from the bidding documents (such as project name and number). **Technical Solution Assistance Generation:** Based on the technical requirements of the bidding documents, it retrieves relevant products and parameters from the technical parameter database to form a basic framework for the technical solution. It combines successful experiences from similar projects in the performance database to generate descriptive content such as project implementation methods, process flows, key difficulties analysis, and countermeasures. Utilizing the text generation capabilities of the large model, it automatically expands the framework and key points into fluent, logically rigorous, and highly professional technical solution paragraphs. **Automatic Compilation of Business Sections:** Based on the requirements of the bidding documents, it automatically generates formatted business documents such as the bid letter, legal representative's identity certificate, power of attorney, and bid bond commitment letter. **Personalized Content Optimization:** It intelligently adjusts the content focus based on the scoring details of the bidding documents. For example, if the technical score has a high weighting, the depth and detail of the technical solution will be automatically expanded; if the performance score has specific requirements, the most suitable performance case will be recommended and described in detail.
[0129] Intelligent review and optimization submodule:
[0130] Function: Performs multi-dimensional automated review of the initial draft of the tender document, identifies risks, and provides modification suggestions.
[0131] Audit Dimension: Responsiveness Review: Verify that each item in the tender document fully responds to all requirements of the tender document (especially those marked with ""). Key clauses), identifying areas where responses were not made or were unclear. Compliance review: Checking for potentially ambiguous or compliance-risk statements in the document, verifying the validity of cited standards, and ensuring commitments do not exceed the company's qualifications and capabilities. Consistency review: Ensuring consistency in the description of the same matter throughout the entire tender document (e.g., between the commercial and technical sections) (e.g., project manager's name, project duration). Typography and grammar check: Conducting basic language quality checks. Competitive advantage alerts: Based on historical bidding data (if accumulated), highlighting gaps between the current tender and winning bids in terms of content completeness, the degree of technical highlighting, and common characteristics.
[0132] 3. Human-computer collaborative editing and workflow management module
[0133] This module provides users with a user-friendly interface, supporting fine-grained editing, multi-person collaboration, and process control based on intelligent generation.
[0134] Visual editing interface: Provides a Word-like rich text editing environment, but all referenced content from the knowledge base (such as qualification lists and performance descriptions) exists in the form of "data blocks." The source data cannot be arbitrarily modified during editing, but the presentation format can be adjusted or the data can be hidden. Modifying the source data requires navigating to the knowledge base management module.
[0135] Task breakdown and collaboration: Project managers can break down the tender document preparation task into multiple sub-tasks (such as technical solutions, business documents, and quotation lists) and assign them to different team members. The system supports task assignment, progress tracking, online comments, and annotations.
[0136] Version history and difference comparison: Completely records all versions in the tender document writing process, supports comparison of content differences between any two versions, and facilitates tracing the modification process and final draft.
[0137] Review process configuration: Supports customizable multi-level review processes (such as compiler - department manager - company leader - final submission), and reviewers can annotate, reject or approve online.
[0138] 4. Bidding Data Feedback and Model Optimization Module
[0139] The system forms a closed loop from "learning" to "application" and then to "feedback learning".
[0140] Bidding Result Entry: After each bidding process, regardless of whether the bid is successful or not, key result information (success / failure, score, competitor information, analysis of points lost, etc.) will be entered into the system.
[0141] Data association: Associate the bidding results with the version of the tender document generated this time, the knowledge base content used, and the characteristics of the tender document.
[0142] Model fine-tuning and knowledge optimization: Utilizing accumulated bidding result data, the large model within the system is periodically fine-tuned to make it better at generating bid content that aligns with the preferences of specific industries and bidders. Simultaneously, common characteristics and outstanding segments of winning bids are analyzed and abstracted into new templates or knowledge entries, feeding them back into the knowledge base to achieve system self-evolution.
[0143] A method for generating intelligent tender documents based on a large model includes the following steps:
[0144] S1: Project Creation and Tender Document Parsing: Users create projects and upload tender documents. The system calls the parsing submodule of the large model intelligent processing engine. By improving the named entity recognition algorithm of BERT, the core requirements, scoring rules and compliance clauses of the tender are extracted in a structured manner to complete the parsing of the tender documents.
[0145] This step transforms unstructured / semi-structured tender documents into a structured set of core information, providing accurate input for subsequent tender document generation. It consists of four sub-steps:
[0146] S1.1 Project Creation and File Upload
[0147] Users can complete the entry of basic project information through the system's visual interface, including metadata such as project name, bidding unit, project manager, and bid deadline. The system automatically generates a unique project ID.
[0148] It supports uploading tender documents in formats such as PDF, DOCX, and TXT. The system calls the file parsing engine to complete the format parsing and text extraction. For scanned PDFs, it uses OCR technology to complete text recognition and outputs a standardized plain text stream.
[0149] S1.2 Pre-processing of tender documents
[0150] Text cleaning: Remove special characters, headers, footers, page numbers, and other redundant information.
[0151] Sentence segmentation and word segmentation: The cleaned text was segmented using the jieba word segmentation tool. The word segmentation results were optimized based on a bidding domain dictionary (containing professional terms such as "qualification requirements," "scoring rules," and "delivery cycle"). Sentences were segmented using punctuation marks (.", !;), resulting in a word segmentation sequence. .
[0152] S1.3 Improves BERT's Named Entity Recognition (NER) algorithm to extract core information.
[0153] To address the issue of insufficient entity recognition accuracy in the bidding domain using the general-purpose BERT, a domain-adaptive layer and an attention mechanism are introduced to optimize the model. The specific design is as follows:
[0154] Improved BERT model structure: A domain-adaptive embedding layer is added between the original BERT embedding layer and encoder layer. Word vectors from the bidding domain dictionary (trained via Word2Vec, dimension d=300) are incorporated into the embedding representation. The final embedding vector is calculated as follows:
[0155]
[0156] in: : The original BERT word embedding of the i-th token, with a dimension of 768; Location embedding, dimension 768, represents the location information of the token in the text; Segment embedding, 768 dimensions, distinguishes different text segments; Domain embedding, obtained by attention weighting of domain dictionary word vectors and token embedding, with a dimension of 768.
[0157] Encoder layer optimization: A domain attention mask is introduced into the self-attention mechanism of the BERT encoder to enhance the attention to domain entities. The domain attention weights are calculated as follows:
[0158]
[0159] in: Self-attention query, key-value matrix; Domain attention mask matrix: The mask value for the position corresponding to a domain entity is 0, and the mask value for the position of a non-domain entity is -1e9, which forces the model to focus on domain entities; This represents the column dimensions of the Q and K matrices. =64.
[0160] Decoding layer design: A Conditional Random Field (CRF) is used as the decoding layer to achieve accurate identification of entity boundaries. The state transition score function of the CRF is as follows:
[0161]
[0162] in: : Predicted entity label sequence, with the label system adopting the BIOS format (e.g., B-REQ: core requirement start, I-REQ: core requirement inside, O: non-entity); :Label arrive The transition probabilities are stored in the transition matrix A; Improve the tag corresponding to the i-th token output by the BERT encoder. The probability of emission.
[0163] Model training parameters: The optimizer used is AdamW, the learning rate is lr=2e-5, and the batch size is [missing information]. size =16, training epochs=10, early stopping strategy (patience=3) is used to prevent overfitting.
[0164] S1.4 Structured parsing results output
[0165] By improving the BERT-NER algorithm, the core requirements of the tender (such as project scale, technical standards, and delivery requirements), scoring details (such as the technical part accounting for 40%, the commercial part accounting for 30%, and the price part accounting for 30%), and compliance clauses (such as qualification validity period requirements, bid bond amount and payment time) are extracted and output in a structured JSON format.
[0166] S2: Knowledge Base Matching and Data Preparation: Relying on the unified knowledge base management module, based on the parsed project features, the knowledge graph association reasoning algorithm is used to link the qualification database, performance database, and technical parameter database to screen and match valid qualifications, related performance and suitable parameters, and form a structured dataset after standardization.
[0167] This step involves accurately matching valid data from a unified knowledge base based on the analyzed project features and standardizing the data to create a structured dataset that can be directly used for tender document generation. It consists of four sub-steps:
[0168] S2.1 Unified Knowledge Base Architecture and Initialization
[0169] The unified knowledge base adopts a hybrid architecture of "structured database + knowledge graph", specifically including:
[0170] Structured database: MySQL 8.0 is used to store the qualification database, performance database, and technical parameter database. The table structure is designed as follows:
[0171] Qualification database: Fields include qualification ID, qualification name, qualification level, issuing authority, validity period, and path to the scanned copy of the qualification;
[0172] Performance Database: Fields include performance ID, project name, project type, contract amount, completion time, client, and project deliverables description;
[0173] Technical parameter library: Fields include parameter ID, parameter category, parameter name, standard value, applicable scenario, and associated technical solution.
[0174] Knowledge Graph (KG): Built using Neo4j, entity types include “project characteristics”, “qualifications”, “performance”, and “technical parameters”, and relationship types include “adaptation”, “association”, and “containment”. During the initialization of the knowledge graph, historical data is imported through an ETL tool to establish initial relationships between entities.
[0175] S2.2 Project Feature Extraction and Vector Representation
[0176] Extract project feature vectors from the structured analysis results output by S1.
[0177]
[0178] Where m is the feature dimension (default m=20), and features include project type, scale, technical standards, qualification requirements, delivery cycle, etc.; an improved BERT model is used to vectorize textual features (such as technical standard descriptions) to obtain feature vectors with a dimension of 768, and numerical features (such as project scale) are normalized.
[0179]
[0180] Finally, the project feature vector is obtained through feature concatenation.
[0181]
[0182] k is the number of numerical features.
[0183] S2.3 Knowledge Graph Association Reasoning and Data Matching
[0184] An improved TransR algorithm is used to achieve associative reasoning in the knowledge graph, accurately matching data that is suitable for project features, as detailed below:
[0185] TransR algorithm optimization: Introduce project feature attention weights and adjust the mapping matrix between entities and relationships to make inference more aligned with the current project requirements. The mapping formula is as follows:
[0186]
[0187] in: The knowledge graph contains head entity (project features) and tail entity (qualifications / performance / technical parameters) vectors, each with 100 dimensions. : The mapping matrix of relation r, with dimensions [100, 100]; : Project feature attention weight matrix, dimension [100, 768+k], learned through project feature vector F, to enhance the association weight of entities related to the current project.
[0188] Similarity calculation: The adaptation similarity between entities is calculated based on the optimized TransR algorithm, using the following formula:
[0189]
[0190] in: Create a relation vector with dimension 100; set a similarity threshold. Entities with a similarity of ≥θ are selected as matching data.
[0191] Multi-database linkage matching: Through the association relationship of knowledge graph, the qualification database, performance database, and technical parameter database are linked. For example, if the project feature requires "Grade A qualification for general contracting of building construction", the corresponding qualification will be matched from the qualification database; if the project type is "smart park construction", the performance of similar smart park projects will be matched from the performance database, and the relevant parameters of park intelligence will be matched from the technical parameter database.
[0192] S2.4 Data Standardization and Structured Dataset Generation
[0193] Data cleaning: Remove duplicates and invalid items (such as expired qualifications or unfulfilled performance targets) from the matching data;
[0194] Standardized format: Data format should be standardized according to the tender document generation specifications (e.g., date format should be "YYYY-MM-DD", amount format should be "RMB XX million", qualification level description should be "Level 1 / Level 2 / Level 3").
[0195] Structured dataset output: The standardized qualification, performance, and technical parameter data are organized according to the hierarchical structure of "tender document chapter-data type-data content" to generate a structured dataset in JSON format.
[0196] S3: Template Matching and Intelligent Generation: The template library submodule of the unified knowledge base recommends a baseline template, which is then filled into the structured data by the generation submodule of the big model intelligent processing engine through the template semantic mapping algorithm. For unstructured content, the big model generates narrative text based on bidding requirements, related performance and technical parameters to form the initial draft of the tender document.
[0197] This step recommends the optimal baseline template based on project features, and completes the initial draft of the proposal through template semantic mapping and large model generation technology, as detailed below:
[0198] S3.1 Template Library Construction and Feature Representation
[0199] Template Library Classification: The template library sub-module of the unified knowledge base is classified into three levels according to industry (such as construction, IT, municipal), project type (such as construction, service, procurement), and tender document type (such as technical tender document, commercial tender document, comprehensive tender document). It stores template files (DOCX format) and template metadata (template ID, applicable scenarios, chapter structure, placeholder list).
[0200] Template feature extraction: The applicable scenario description and chapter structure of each template are text-encoded, and an improved BERT model, identical to that used for project features, is used to generate template feature vectors. , dimension 768.
[0201] S3.2 Benchmark Template Recommendation Algorithm
[0202] A hybrid recommendation algorithm combining feature similarity and collaborative filtering is used to recommend a baseline template, as detailed below:
[0203] Feature similarity calculation: Calculate the cosine similarity between the project feature vector F and the template feature vector T.
[0204]
[0205] Collaborative filtering score: Based on historical bidding data, calculate the similarity between the current project and historical projects, and assign additional scores to high-quality templates used in historical projects (templates corresponding to winning projects).
[0206]
[0207] in: : The feature vector of the i-th historical item; The weight of historical project templates, and the corresponding weight of winning projects. =1.5, unsuccessful bids =0.8; k: number of historical projects, default k=50.
[0208] Overall Score and Template Selection: Overall Score:
[0209]
[0210] The top 3 templates with the highest overall scores are selected for users to choose from. Users can directly select or specify a template as the benchmark template.
[0211] S3.3 Template Semantic Mapping and Structured Data Filling
[0212] An attention-based semantic mapping algorithm is used to achieve accurate matching between structured data and template placeholders, as follows:
[0213] Placeholder extraction: The baseline template is parsed to extract placeholders (such as {{qualification name}}, {{similar project performance}}), and each placeholder is semantically encoded to obtain a placeholder vector. ;
[0214] Semantic matching: Calculate the attention weights between the placeholder vector P and the structured data field vector Z extracted from the structured data of S2.
[0215]
[0216] in For vector dimensions;
[0217] Select the field data with the highest attention weight and populate it into the corresponding placeholder;
[0218] Fill rule validation: Validate whether the format of the filled data conforms to the template requirements (e.g., the filled data corresponding to the placeholder {{amount}} must conform to the format "RMB XX million"). If it does not conform, trigger the secondary data standardization processing.
[0219] S3.4 Unstructured Content Generation and Initial Proposal Construction
[0220] For unstructured sections without placeholders in the template (such as technical solution overview, project implementation plan, service commitment, etc.), a large model generation submodule is used to generate narrative text, as follows:
[0221] Prompt Engineering Design: Construct a structured Prompt, including project requirements (S1 parsing results), related achievements (S2 matching achievements), technical parameters (S2 matching parameters), and generation requirements (such as "formal language, clear logic, and highlighting the degree of matching with the bidding requirements").
[0222] Large model generation parameters: Temperature parameter T=0.7 (to balance the diversity and accuracy of generated text), maximum generated length max length =1024, top p =0.9 (kernel sampling strategy, controlling the relevance of generated text);
[0223] Initial draft integration: Integrate the results of structured data filling with the results of unstructured text generation, organize the content according to the chapter structure of the benchmark template, generate an initial draft of the tender document in DOCX format, and save the generation log (including generation time, data used, and large model parameters).
[0224] S4: Human-computer collaborative editing and review: Users review and modify the initial draft of the tender document through the human-computer collaborative editing module; the system synchronously calls the large model intelligent review algorithm to complete the response integrity, compliance and consistency verification and provide optimization suggestions, supporting multi-person collaboration and online review workflow;
[0225] This step optimizes the initial draft of the tender document through a human-machine collaborative model, ensuring the completeness, compliance, and consistency of the tender response. It consists of four sub-steps:
[0226] S4.1 Human-Machine Collaborative Editing Module Deployment
[0227] Editing interface design: A web-based visual editing interface that supports text editing, formatting adjustment, and attachment insertion (such as scanned copies of qualifications and performance contracts), and saves editing records in real time (using an incremental storage strategy, saving only the modified parts).
[0228] Access control: Supports multi-role permission configuration (such as editor, reviewer, administrator), with different roles having different operation permissions (editors can modify content, reviewers can annotate but cannot modify).
[0229] Collaborative editing: WebSocket is used to enable real-time collaborative editing by multiple users and resolve editing conflicts (adopting a "last editor first" strategy while retaining historical edit versions for retrospection).
[0230] S4.2 Large Model Intelligent Review Algorithm Design
[0231] A multi-dimensional audit algorithm has been constructed, covering three core dimensions: response integrity, compliance, and consistency, as detailed below:
[0232] Response integrity audit: A dual verification method using keyword matching and semantic similarity is employed to calculate the degree of match between the tender document content and the core requirements of the tender.
[0233]
[0234] in: The number of core requirements matched in the tender; Total number of core requirements for the tender; Keyword matching weight; : The content vector corresponding to the i-th requirement in the tender document; : The vector of the i-th bidding requirement; n: The number of core bidding requirements.
[0235] When completeness < 0.8, it is judged as incomplete, and the list of unmatched requirements is output.
[0236] Compliance review: Utilizing regular expression matching and domain-specific semantic understanding models, we validate bidding compliance clauses (such as qualification requirements and bid security deposit clauses).
[0237] Regular expression matching: Regular expressions are used to validate format-related compliance requirements (such as date and amount formats).
[0238] Semantic understanding: For substantive compliance requirements (such as qualification level, number of performance records), a large model is used to determine whether the content of the tender document meets the requirements and outputs a compliance score (0-100 points). If the score is lower than 60 points, an alert is triggered.
[0239] Consistency audit: Verify the consistency of the wording of the same information across different chapters of the tender document (such as project name, contract amount, and delivery period), using text similarity calculation.
[0240]
[0241] in This is a text vector containing the same information in different chapters, where k is the number of chapters involving this information; when consistency < 0.9, output the inconsistent information and the chapters in which it occurs.
[0242] S4.3 Optimization Suggestion Generation and Review Process
[0243] Optimization suggestion generation: Based on the intelligent review results, the big model generates targeted optimization suggestions (e.g., "The scoring requirement of 'having more than 3 years of experience in similar projects' was not met, and it is recommended to supplement the performance of smart park construction from 2023 to 2025"); "The delivery cycle descriptions in Chapter 3 and Chapter 5 of the tender document are inconsistent, being 90 days and 120 days respectively, and it is recommended to unify and correct them").
[0244] Review process: Supports online review process. Users can submit the initial draft of the tender document and the review results to the designated reviewer. The reviewer can give comments, return the tender for modification, or approve the tender. The process is recorded in real time (including reviewer, review time, and review comments) and supports process traceability.
[0245] S4.4 Editing and Second Review
[0246] Users can revise the initial draft of the tender document based on the review comments and optimization suggestions. After the revision is completed, a second review can be initiated. The second review only verifies the revised parts, improving the review efficiency. If the second review still fails, the revision-review process must be repeated until the review is passed.
[0247] S5: Final Draft Output and Archiving: After the tender document is finalized, it can be exported in a specified format with one click. The unified knowledge base module completes the standardized naming and full-process archiving to ensure data traceability.
[0248] This step achieves standardized output and full-process archiving of tender documents, ensuring data traceability. It is specifically divided into 3 sub-steps:
[0249] S5.1 Final Draft Confirmation of Tender Documents
[0250] After the review is approved, the user confirms the final draft of the tender document. The system locks the final version (which cannot be modified), generates a unique identifier for the final draft, and records the person who confirmed the final draft and the confirmation time.
[0251] S5.2 One-Click Export to Multiple Formats
[0252] It utilizes a format conversion engine to achieve multi-format export, supporting PDF, DOCX, PDF / A (archive-specific format), etc. Specific functions are as follows:
[0253] Format Conversion: Convert the final DOCX file to the target format. Conversion parameter settings: PDF compression level = 60% (balancing file size and clarity), PDF / A compatibility = PDF / A-2b;
[0254] Watermark addition: Supports custom watermarks (such as "For Bidding Only" or "Confidential Documents"), and allows setting the watermark position (center / corner), transparency (30%), and font size (16pt).
[0255] Batch export: Supports exporting multiple formats simultaneously, and the exported files are automatically packaged into a ZIP archive for easy download by users.
[0256] S5.3 Standardized Naming and Full-Process Archiving
[0257] Standardized naming: Exported files and archived files shall adopt a unified naming rule: "Bidding Unit-Project Name-Tender Type-Final Draft Date-Format Extension";
[0258] Full-process archiving: Archiving is completed by a unified knowledge base module, specifically including: Structured archiving: Project metadata, final tender document identifiers, export records, review records, etc. are stored in a MySQL database, and data associations are established; File archiving: Final tender document files (in various formats) and related attachments (scanned copies of qualifications, performance contracts, etc.) are stored in a distributed file server, and the file paths are associated with database metadata; Traceability assurance: Full-process data (parsing records, matching data, editing records, review records, and archiving records) can be queried by project ID.
[0259] S6: Results Feedback and Model Iteration: Input the bidding results, establish the connection between the results and information such as the bid documents and knowledge base through the bidding data feedback module, and use reinforcement learning algorithms to optimize the template recommendation and large model generation logic, so as to precipitate high-quality content into knowledge assets and realize the closed-loop evolution of the system.
[0260] This step establishes a connection between the bidding results and the entire process of bid document generation. Through reinforcement learning, it optimizes the model and accumulates knowledge, forming a closed-loop system evolution. Specifically, it consists of four sub-steps:
[0261] S6.1 Bidding Result Input and Data Linking
[0262] Results entry: Users enter bidding results, including the bidding status (successful / unsuccessful / rejected), the winning bid amount, the judges' comments, the reasons for not winning the bid (such as insufficient technical solutions or mismatch with past performance), and the reasons for rejecting the bid (such as compliance issues).
[0263] Data association: The bidding data feedback module establishes associations between bidding results and bid document content, knowledge base data, generated logs, and review records, which are then stored in a data warehouse for subsequent analysis.
[0264] S6.2 Reinforcement Learning (RL) Model Construction and Optimization Objectives
[0265] A reinforcement learning model is constructed, with template recommendation accuracy and the quality of text generated by the large model as optimization objectives, as follows:
[0266] RL Model Element Definitions: Agent: Template recommendation module, large model generation module; State s: Project feature vector F, historical bidding data features; Action a: Template recommendation selection, large model generation parameter adjustment (temperature T, top...). p (etc.), semantic style adjustment of generated text; reward r: setting a reward function based on bidding results:
[0267]
[0268] At the same time, auxiliary rewards (such as bid approval rate and response integrity score) are introduced to improve the refinement of model optimization.
[0269] Optimization goal: Maximize cumulative rewards
[0270]
[0271] in This is a discount factor, representing the weight of future rewards.
[0272] S6.3 Model Iterative Training and Parameter Update
[0273] Training data preparation: Extract historical bidding data from the data warehouse (sample size ≥ 1000 records recommended), and divide it into training set and test set in an 8:2 ratio;
[0274] Training process: The reinforcement learning model is trained using the DQN algorithm. An experience replay mechanism is used to store the agent's state-action-reward-next state samples. Random samples are used to update the model parameters. The loss function is as follows:
[0275]
[0276] in: : The action value function of the current Q-network (parameter θ); Target Q-network (parameter θ) - D: Action value function; D: Experience replay buffer, capacity = 10000; Next state;
[0277] Parameter update: After training is completed, the optimized model parameters will be updated to the template recommendation module and the large model generation module. The iteration cycle is set to once a month (or once every 200 bidding projects).
[0278] S6.4 High-quality content accumulation and knowledge asset building
[0279] Selection of high-quality content: Based on the bidding results and the comments of the judges, high-quality content (such as technical solutions, performance descriptions, service commitments, etc.) in the winning bids are selected and included in the candidate knowledge assets after being confirmed by manual review (with a review pass rate of ≥90%).
[0280] Knowledge asset accumulation: High-quality content is categorized by industry, project type, and chapter, and updated to the template library and technical parameter library of the unified knowledge base. At the same time, the entity relationship of the knowledge graph is optimized.
[0281] Closed-loop evolution: The accumulated knowledge assets feed back into the subsequent tender document generation process, improving the accuracy of template recommendation and the quality of text generated by large models.
[0282] Finally, it should be noted that the above are merely preferred embodiments of the present invention and are not intended to limit the present invention. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art can still modify the technical solutions described in the foregoing embodiments or make equivalent substitutions for some of the technical features. 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 smart tender document generation system based on a large model, characterized in that: Includes the following modules: Unified Knowledge Base Management Module: As the data hub of the system, it is used for structured storage and management of all knowledge assets related to tender document generation, ensuring the uniqueness, accuracy and timeliness of the data; the unified knowledge base management module includes a template library management submodule, a company qualification library management submodule, a historical performance library management submodule and a technical parameter library management submodule; Large-scale intelligent processing engine module: As the intelligent core of the system, it calls upon a large-scale language model to achieve deep semantic understanding of bidding documents, intelligent generation and optimization of bidding content, and multi-dimensional review of the initial draft of bidding documents; the large-scale intelligent processing engine module includes a bidding document intelligent parsing submodule, an intelligent content generation and filling submodule, and an intelligent review and optimization submodule; Human-computer collaborative editing and process management module: This module provides an interactive interface to support fine-grained editing, enabling multi-person collaboration and process control. The human-computer collaborative editing and process management module includes a visual editing interface unit, a task decomposition and collaboration unit, a version history and difference comparison unit, and an audit process configuration unit. The bidding data feedback and model optimization module is used to realize the input of bidding results, data association, and closed-loop evolution of the system. The bidding data feedback and model optimization module includes a bidding result input unit, a data association unit, and a model fine-tuning and knowledge optimization unit.
2. A method for generating intelligent tender documents based on a large model, characterized in that: Includes the following steps: S1: Project Creation and Tender Document Parsing: Users create projects and upload tender documents. The system calls the parsing submodule of the large model intelligent processing engine. By improving the named entity recognition algorithm of BERT, the core requirements, scoring rules and compliance clauses of the tender are extracted in a structured manner to complete the parsing of the tender documents. S2: Knowledge Base Matching and Data Preparation: Relying on the unified knowledge base management module, based on the parsed project features, the knowledge graph association reasoning algorithm is used to link the qualification database, performance database, and technical parameter database to screen and match valid qualifications, related performance and suitable parameters, and form a structured dataset after standardization. S3: Template Matching and Intelligent Generation: The template library submodule of the unified knowledge base recommends a baseline template, which is then filled into the structured data by the generation submodule of the large model intelligent processing engine through the template semantic mapping algorithm. For unstructured content, the large model generates narrative text based on bidding requirements, related performance, and technical parameters, forming the initial draft of the tender document; S4: Human-computer collaborative editing and review: Users review and modify the initial draft of the tender document through the human-computer collaborative editing module; the system synchronously calls the large model intelligent review algorithm to complete the response integrity, compliance and consistency verification and provide optimization suggestions, supporting multi-person collaboration and online review workflow; S5: Final Draft Output and Archiving: After the tender document is finalized, it can be exported in a specified format with one click. The unified knowledge base module completes the standardized naming and full-process archiving to ensure data traceability. S6: Results Feedback and Model Iteration: Input the bidding results, establish the connection between the results and information such as the bid documents and knowledge base through the bidding data feedback module, and use reinforcement learning algorithms to optimize the template recommendation and large model generation logic, so as to precipitate high-quality content into knowledge assets and realize the closed-loop evolution of the system.
3. The intelligent tender document generation method based on a large model according to claim 2, characterized in that: Step S1, leveraging system functionality and an improved BERT named entity recognition algorithm, transforms unstructured / semi-structured bidding documents into a structured core information set, providing accurate input for subsequent bid generation. This step consists of four sub-steps: S1.1 Project Creation and File Upload: Users can enter basic metadata such as project name, bidding unit, project manager, and bid deadline through the system's visual interface. The system automatically generates a unique project ID. It supports uploading bidding documents in formats such as PDF, DOCX, and TXT. For scanned PDFs, OCR technology is used to recognize the text, and the file parsing engine completes the format parsing and standardized plain text stream output. S1.2 Preprocessing of tender documents: First, the text is cleaned to remove redundant information such as special characters, headers and footers, and page numbers; then, based on the jieba word segmentation tool, the word segmentation effect is optimized by combining a tender field dictionary containing professional terms such as qualification requirements and scoring rules, and at the same time, sentences are segmented according to punctuation marks to generate word segmentation sequences; S1.3 Improved BERT Named Entity Recognition Algorithm Core Information Extraction: Addressing the insufficient recognition accuracy of the general BERT in the bidding domain, the model is optimized in three aspects: First, a domain-adaptive embedding layer is added between the original BERT embedding layer and the encoder layer, fusing token word embedding, position embedding, segment embedding, and domain embedding to generate the final embedding vector; second, a domain attention mask matrix is introduced into the encoder layer's self-attention mechanism to force the model to focus on domain entities and optimize attention weight calculation; third, a conditional random field is used as the decoding layer, achieving accurate entity boundary recognition based on the BIOS tag system; model training uses the AdamW optimizer, setting a learning rate of 2e-5, batch size of 16, and training epochs of 10, and employing an early stopping strategy to prevent overfitting; S1.4 Structured Parsing Output: Using the improved algorithm described above, key information such as core requirements, scoring details, and compliance clauses in the tender documents are extracted and output in JSON format.
4. The intelligent tender document generation method based on a large model according to claim 2, characterized in that: Step S2, based on the structured project features output from S1, utilizes the unified knowledge base management module and a knowledge graph association reasoning algorithm to accurately match valid data from multiple databases and perform standardization processing, forming a structured dataset that can be directly used for tender document generation. This step consists of four sub-steps: S2.1 Unified Knowledge Base Architecture and Initialization: A unified knowledge base is built using a hybrid architecture of structured database and knowledge graph. The structured database is built on MySQL 8.0 and includes three sub-databases: qualification database, performance database, and technical parameter database, with corresponding fields designed for each. The knowledge graph is built on Neo4j and defines four types of entities: project features, qualifications, performance, and technical parameters, as well as three types of relationships: adaptation, association, and inclusion. Initialization is completed by importing historical data through an ETL tool to establish initial relationships between entities. S2.2 Project Feature Extraction and Vector Representation: Feature vectors of project type, scale, technical standards, etc. are extracted from the structured analysis results of S1; textual features are encoded into 768-dimensional vectors using an improved BERT model, and numerical features are normalized; the two types of feature vectors are concatenated to generate the final project feature vector, providing a data foundation for subsequent association reasoning; S2.3 Knowledge Graph Association Reasoning and Data Matching: An improved TransR algorithm is used to realize knowledge graph association reasoning. By introducing project feature attention weights, the mapping matrix between entities and relationships is optimized to enhance the fit between reasoning and current project requirements. The algorithm calculates the similarity between project features and qualifications / performance / technical parameters, and sets a threshold of 0.7 to filter entities that meet the requirements. By leveraging the relationship between knowledge graphs and three sub-databases, the system accurately matches the qualifications, similar performance, and suitable technical parameters required for the project. S2.4 Data Standardization and Structured Dataset Generation: First, the matching data is cleaned to remove duplicates and invalid items; then, the data format is standardized according to the tender document generation specifications; finally, the standardized data is organized according to the hierarchical structure of tender document chapter-data type-data content, and a structured dataset in JSON format is output.
5. The intelligent tender document generation method based on a large model according to claim 2, characterized in that: Step S3 recommends the optimal baseline template based on project features, fills the structured data using a template semantic mapping algorithm, and generates unstructured narrative content using a large model. Finally, these are integrated to form the initial draft of the tender document, and consist of four sub-steps: S3.1 Template Library Construction and Feature Representation: The template library sub-module of the unified knowledge base is classified into three levels: industry, project type, and tender document type. It stores DOCX format template files and metadata such as template ID, applicable scenarios, chapter structure, and placeholder list. It adopts the same improved BERT model as the project feature encoding to text-encode the applicable scenario description and chapter structure of the template, generating a template feature vector with a dimension of 768, providing data support for template matching. S3.2 Benchmark Template Recommendation Algorithm: A hybrid recommendation algorithm of feature similarity and collaborative filtering is used to select benchmark templates: First, the cosine similarity between the project feature vector and the template feature vector is calculated, and then the collaborative filtering score is calculated based on historical bidding data. The template's overall score is calculated using a weighted formula, and the top 3 templates are selected for users to choose from, thus determining the final benchmark template. S3.3 Template Semantic Mapping and Structured Data Filling: Parse the baseline template to extract placeholders such as qualification names and perform semantic encoding to generate a 768-dimensional placeholder vector; The attention weight between the placeholder vector and the S2 structured data field vector is calculated using an attention mechanism. The field data with the highest weight is then filled into the corresponding placeholder. At the same time, the format of the filled data is checked to ensure that it meets the template requirements. If it does not meet the requirements, a second data standardization process is triggered to ensure that the filled content is compliant. S3.4 Unstructured Content Generation and Initial Proposal Construction: For unstructured sections without placeholders, such as the technical solution overview and project implementation plan, construct a structured Prompt containing project requirements, related achievements, technical parameters, and generation requirements; set large model parameters to generate logically rigorous and formally presented narrative text; finally, integrate the structured data filling results with the unstructured generated text, organize the content according to the baseline template chapter structure, generate a DOCX format initial proposal, and save the generation log, including generation time, data used, and large model parameters.
6. The intelligent tender document generation method based on a large model according to claim 2, characterized in that: Step S4 optimizes the initial draft of the tender document through a human-machine collaborative mode, comprehensively ensuring the completeness, compliance, and consistency of the tender document's response. It supports multi-person collaborative operation and review workflow, and is divided into 4 sub-steps: S4.1 Human-Computer Collaborative Editing Module Deployment: Provides a web-based visual editing interface, supports text modification, format adjustment, and attachment insertion, and adopts an incremental storage strategy to save only the modified content to achieve real-time backup; Configure multi-role permissions to differentiate between modification, annotation, and other operation permissions; enable real-time collaborative editing by multiple users through WebSocket technology, adopt a last-editor priority strategy to resolve editing conflicts, and retain historical versions for backtracking; S4.2 Large Model Intelligent Review Algorithm Design: Construct a multi-dimensional review system covering three core dimensions: First, response integrity review, which calculates the matching degree by combining keyword matching and semantic similarity verification. If the score is lower than 0.8, a list of unmatched requirements is output. Second, compliance review, which verifies format requirements by regular expression matching and checks substantive requirements by semantic understanding of the domain large model, generating a compliance score of 0-100. If the score is lower than 60, an early warning is triggered. Third, consistency review: the consistency of the expression of the same information in different chapters is verified by text similarity calculation. If the similarity is less than 0.9, the inconsistent information and the chapter in which it is located are marked. S4.3 Optimization Suggestion Generation and Review Process: The large model generates targeted optimization suggestions based on the review results, clearly pointing out unresponsive requirements, compliance issues, and inconsistencies in expression, and providing directions for correction; it supports online review process, where users can submit tender documents and review results to designated reviewers, who can approve comments, return for revision, or confirm approval. The entire process records the reviewer, time, and opinions, ensuring traceability. S4.4 Editing and Secondary Review: Users can modify the tender documents based on the review comments and optimization suggestions. After the modification is completed, a secondary review can be initiated. The secondary review only verifies the modified parts to improve efficiency. If the second review fails, the revision and review process must be repeated until the tender document is approved.
7. The intelligent tender document generation method based on a large model according to claim 2, characterized in that: Step S5 achieves standardized export and full-process archiving of tender documents, ensuring the traceability of project data, and consists of 3 sub-steps: S5.1 Final Confirmation of Tender Documents: After the tender documents are approved, the user confirms the final version. The system then locks the version, generates a unique identifier for the final version, and records the person who confirmed the final version and the confirmation time to ensure the version's authority and traceability. S5.2 One-click export in multiple formats: It calls the format conversion engine to export tender documents in multiple formats, supporting DOCX, PDF, PDF / A and other types; The PDF compression level is set to 60% to balance file size and clarity, ensuring compatibility between the PDF / A format and the PDF / A-2b standard; it supports custom watermarking, allowing users to set watermark content such as those for bidding, as well as parameters such as position, transparency, and font; it supports batch export of files in multiple formats and automatically packages them into a ZIP archive for easy download. S5.3 Standardized Naming and Full-Process Archiving: Exported and archived files adopt a unified naming rule: Bidding Unit - Project Name - Tender Type - Final Draft Time - Format Suffix; The unified knowledge base module completes the full-process archiving. On the one hand, it stores structured data such as project metadata, final draft identifiers, export records, and review records into a MySQL database and establishes a relationship. On the other hand, it stores various format files of the final tender document, qualification scans, and other attachments into a distributed file server, with file paths bound to database metadata; Through the project ID, the entire process of data, including parsing, matching, editing, reviewing, and archiving, can be linked and queried to achieve data traceability.
8. The intelligent tender document generation method based on a large model according to claim 2, characterized in that: Step S6 establishes the connection between bidding results and data throughout the entire process, optimizes the model logic through reinforcement learning algorithms, accumulates high-quality knowledge assets, and achieves closed-loop evolution of the system. This step is divided into four sub-steps: S6.1 Bidding Result Input and Data Association: Users input bidding result information, including the winning status, winning bid amount, judges' comments, reasons for not winning the bid / rejection, etc. The system uses a bidding data feedback module to link the results with information from the entire process, including bid document content, knowledge base data, generation logs, and review records, and stores them in a unified data warehouse to provide data support for subsequent model optimization. S6.2 Reinforcement Learning Model Construction and Optimization Objectives: Construct a reinforcement learning model with a template recommendation module and a large model generation module as agents, define project feature vectors and historical bidding data features as states, and template recommendation selection, large model generation parameter adjustment, and text semantic style adjustment as actions; set a reward function based on bidding results, and introduce bid approval rate and response integrity score as auxiliary rewards; The optimization goal is to maximize cumulative rewards and improve template recommendation accuracy and generated text quality. S6.3 Model Iterative Training and Parameter Update: Extract ≥1000 historical bidding data from the data warehouse and divide the training set and test set in an 8:2 ratio; train the model using the DQN algorithm combined with the experience replay mechanism, and update the model parameters through the loss function; after training, synchronize the optimized parameters to the template recommendation module and the large model generation module, and set the iteration cycle to once a month or once every 200 accumulated bidding projects; S6.4 High-Quality Content Accumulation and Knowledge Asset Building: Based on the bidding results and judges' comments, high-quality content in the winning bids is selected and included in the candidate knowledge assets after manual review; the high-quality content is categorized by industry, project type, and chapter, and updated to the template library and technical parameter library of the unified knowledge base, while optimizing the entity relationship of the knowledge graph; the accumulated knowledge assets feed back into the subsequent bid generation process, realizing the closed-loop evolution of the system.
9. The intelligent tender document generation method based on a large model according to claim 4, characterized in that: The specific steps for S2 are as follows: S2.1 Unified Knowledge Base Architecture and Initialization The unified knowledge base adopts a hybrid architecture of structured database and knowledge graph, specifically including: Structured database: using MySQL 8.0 to store qualification database, performance database, and technical parameter database, with the table structure design as follows: Qualification Database: Fields include qualification ID, qualification name, qualification level, issuing authority, validity period, and path to the scanned copy of the qualification; Performance Database: Fields include performance ID, project name, project type, contract amount, completion time, client, and project deliverables description; Technical Parameter Database: Fields include parameter ID, parameter category, parameter name, standard value, applicable scenario, and associated technical solution. Knowledge graph: Built using Neo4j, entity types include project characteristics, qualifications, performance, and technical parameters, and relationship types include adaptation, association, and inclusion. During knowledge graph initialization, historical data is imported through an ETL tool to establish initial relationships between entities. S2.2 Project Feature Extraction and Vector Representation Extract the project feature vector from the structured analysis results output by S1: Where m is the feature dimension, and the features include project type, scale, technical standards, qualification requirements, delivery cycle, etc.; an improved BERT model is used to vectorize textual features, resulting in a feature vector of dimension 768, while numerical features are normalized. Finally, the project feature vector is obtained through feature concatenation. k is the number of numerical features; S2.3 Knowledge Graph Association Reasoning and Data Matching An improved TransR algorithm is used to perform associative reasoning on knowledge graphs, accurately matching data that is suitable for project features: TransR algorithm optimization: Introduce project feature attention weights and adjust the mapping matrix between entities and relationships to make inference more aligned with the current project requirements. The mapping formula is as follows: in: The head entity in the knowledge graph is the project feature, and the tail entity is the qualification / performance / technical parameter vector, with 100 dimensions. : The mapping matrix of relation r, with dimensions [100, 100]; : Project feature attention weight matrix, dimension [100, 768+k], learned through project feature vector F, to enhance the association weight of entities related to the current project; Similarity calculation: The adaptation similarity between entities is calculated based on the optimized TransR algorithm, using the following formula: in: Create a relation vector with dimension 100; set a similarity threshold. Entities with a similarity ≥ θ are selected as matching data; Multi-database linkage matching: Through the association relationship of knowledge graph, it links qualification database, performance database, and technical parameter database; S2.4 Data Standardization and Structured Dataset Generation Data cleaning: Removing duplicates and invalid items from the matched data; Standardized format: Data format should be standardized according to the tender document generation specifications; Structured dataset output: The standardized qualification, performance, and technical parameter data are organized according to the hierarchical structure of tender document chapter-data type-data content to generate a structured dataset in JSON format.
10. The intelligent tender document generation method based on a large model according to claim 5, characterized in that: Step S3 is as follows: S3.1 Template Library Construction and Feature Representation Template Library Classification: The template library sub-module of the unified knowledge base is classified into three levels according to industry, project type, and tender document type, storing template files and template metadata; Template feature extraction: The applicable scenario description and chapter structure of each template are text-encoded, and an improved BERT model, identical to that used for project features, is used to generate template feature vectors. ; S3.2 Benchmark Template Recommendation Algorithm A hybrid recommendation algorithm combining feature similarity and collaborative filtering is used to recommend a baseline template. Feature similarity calculation: Calculate the cosine similarity between the project feature vector F and the template feature vector T. Collaborative filtering score: Based on historical bidding data, calculate the similarity between the current project and historical projects, and assign extra points to high-quality templates used in historical projects. in: : The feature vector of the i-th historical item; The weight of historical project templates, and the corresponding weight of winning projects. =1.5, unsuccessful bids =0.8; k: number of historical projects, default k=50; Overall Score and Template Selection: Overall Score: The top 3 templates with the highest overall scores are selected for users to choose from. Users can directly select or specify a template as the benchmark template. S3.3 Template Semantic Mapping and Structured Data Filling An attention-based semantic mapping algorithm is used to achieve accurate matching between structured data and template placeholders. Placeholder extraction: The baseline template is parsed to extract placeholders, and each placeholder is semantically encoded to obtain a placeholder vector. ; Semantic matching: Calculate the attention weights between the placeholder vector P and the structured data field vector Z extracted from the structured data of S2. in For vector dimensions; select the field data with the highest attention weight to fill the corresponding placeholders; Fill rule validation: Validate whether the format of the filled data conforms to the template requirements. If it does not, trigger secondary data standardization processing. S3.4 Unstructured Content Generation and Initial Proposal Construction For unstructured chapters without placeholders in the template, a large model generation submodule is used to generate narrative text: Prompt Engineering Design: Build a structured Prompt, including project requirements, relevant performance, technical parameters, and generation requirements; Large model generation parameters: temperature parameter T=0.7, maximum generation length max length =1024, top p =0.9; Initial draft integration: Integrate the results of structured data filling with the results of unstructured text generation, organize the content according to the chapter structure of the benchmark template, generate an initial draft of the tender document in DOCX format, and save the generation log at the same time.