Method for generating feasibility study report of highway engineering based on local large model training
By training a large local model to generate highway engineering reports, integrating multi-source data, constructing a knowledge graph and terminology table, optimizing model output, and combining API and RPA technologies, the problems of low efficiency, error-prone verification, and insufficient compliance in traditional report preparation are solved, achieving efficient and accurate report generation and compliance control.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- JIANGXI HIGHWAY RES & DESIGN INST CO LTD
- Filing Date
- 2025-12-24
- Publication Date
- 2026-04-24
AI Technical Summary
Traditional highway engineering feasibility study reports suffer from problems such as low data processing efficiency, error-prone manual verification, delayed updates, and insufficient compliance. Existing AI technologies have failed to effectively address the issues of text generation standardization, compliance, and cross-domain knowledge integration.
The system uses a local large-scale model to train and generate reports, integrates multi-source data and constructs a knowledge graph, extracts standardized fields through regular expressions, injects professional books to build a terminology lookup table, designs a reward function to optimize model output, obtains route parameters through API interfaces, simulates expert perspectives to cross-validate content, uses RPA to crawl and update standards, and verifies compliance through the knowledge graph.
It improves the efficiency and accuracy of report generation, ensures compliance, reduces errors from manual verification, optimizes engineering design, reduces potential disaster remediation costs, and ensures the scientific rigor and reliability of report content.
Smart Images

Figure CN121413576B_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of artificial intelligence technology, and in particular to a method for generating feasibility study reports for highway engineering based on local large-scale model training. Background Technology
[0002] Currently, the preparation of feasibility study reports for highway engineering relies on manual processing of multi-source heterogeneous data, including GIS topographic maps, design drawings, and policy provisions. This results in problems such as low data cleaning efficiency and difficulty in extracting structured fields. Traditional methods require manual verification of the consistency between design parameters and specifications, which can easily lead to design deviations due to ambiguous policy interpretations or confusing terminology. Furthermore, it is difficult to respond to local policy updates. Existing systems lack automated identification of high-risk areas and recommendations for bypass schemes, and the generation of chapter content relies on template libraries, resulting in poor flexibility.
[0003] Although some AI technologies are applied to highway engineering, they mainly focus on image recognition and efficiency improvement, failing to address the issues of standardization, compliance, and cross-domain knowledge integration in text generation. Large models are prone to generating illusions during the generation process and lack knowledge graph verification mechanisms, leading to conflicts between report content and the latest policies. Therefore, there is an urgent need for a technical solution that combines local large models, knowledge graphs, and compliance verification, especially by introducing domain-enhanced reward functions to achieve intelligent generation and precise compliance control of highway engineering reports. Summary of the Invention
[0004] The purpose of this invention is to provide a method for generating feasibility study reports for highway engineering based on local large model training.
[0005] The problem this invention aims to solve is to address the issues of low efficiency in manually processing multi-source heterogeneous data, insufficient standardization due to terminology confusion, lack of risk assessment, and lagging compliance in the preparation of feasibility study reports for traditional highway engineering projects.
[0006] The method for generating feasibility study reports for highway engineering based on local large-scale model training employs the following technical solution:
[0007] S1: Select Qwen3 as the base model, deploy it on a local GPU and use INT8 quantization to compress the model volume, integrate multi-source data, including historical project data, GIS topographic maps, design drawings and local policy provisions, and extract standard fields, including route length, design speed, gradient and curve radius, through regular expressions;
[0008] A knowledge graph of highway engineering terminology is constructed, which maps fuzzy policy descriptions to standardized fields. Implicit conditions, including environmental impact assessment requirements, are parsed based on the semantic understanding of a large model. After generating structured fields, their legality is verified through a pre-set highway engineering technical standard field mapping table, including curve radius ≥150m. Abnormal fields trigger correction suggestions.
[0009] S2: Accelerate model inference based on TensorRT, incorporate highway engineering textbooks, construct a terminology comparison table, design a comparative learning task for easily confused terms, and optimize the consistency between model output and standard terminology through the cosine similarity loss function.
[0010] A LoRA fine-tuning model is adopted, and the model is trained on the SFT dataset to generate standard text, including input parameters and output chapter pairing. A reward function is designed to reward +1 when the generated content conforms to the standard text, otherwise deduct 1 and trigger regeneration. The LoRA weights are integrated into the original model and deployed to the production environment.
[0011] S3: Connect to the route selection system via API interface, input the starting and ending coordinates of the selected route, GIS topographic map and design drawing parameters into the model, including horizontal and vertical curves, number of bridges and tunnels, directly extract the geometric features of the route, including length, earthwork volume and longitudinal slope, obtain map data along the selected route based on map API, including landslide risk level and ecological protection area boundary, and analyze the distance between the selected route and high-risk areas through coordinate system alignment and buffer analysis;
[0012] The outline of chapters is generated based on the route selection parameters and is divided into four major modules: technical solutions, economic analysis, environmental impact, and conclusions and recommendations. Each module is further subdivided into sub-chaps, including route design, engineering quantity summary, IRR and NPV calculation, and geological risk assessment. The route selection parameters are mapped to the fields of the corresponding chapters, and the chapter content is adjusted according to the route selection results.
[0013] S4: Based on the model output, standard and specification texts that conform to the compilation method of feasibility study reports for highway engineering are output, avoiding colloquial expressions, using professional terms including this project and recommendations, and simulating the expert perspective to cross-validate the chapter content to ensure consistency between technical details and conclusions.
[0014] S5: RPA is used to crawl specification update announcements. The model identifies the updated content, triggers the Kafka message queue, and the model reconstructs entity relationships based on the knowledge graph. It calls the external knowledge base to verify the compliance of the generated content. The retrieval module uses the Faiss vector library to store local policy provisions. The generation module calls Faiss to retrieve relevant provisions, verifies the consistency of the content with the latest specifications, and provides correction suggestions when there are conflicts.
[0015] Furthermore, in S1, multi-source data is integrated, and standardized fields are extracted using regular expressions, including:
[0016] The database extracts past highway engineering design parameter fields, including route length and design speed, and stores them in CSV format. Data cleaning is performed using Pandas, including missing value filling and unit standardization. Topographic map data is obtained by calling ArcGIS API, and spatial features, including slope and elevation, are extracted and converted to GeoJSON format. Geometric parameters, including curve radius and longitudinal slope, are extracted. Text fields are extracted based on the base model. Policy documents from the official website of the local transportation department are crawled. The requests library of Python is used to download PDF files and extract text content based on the base model.
[0017] To address the vague descriptions in local policy provisions, including the prohibition of crossing ecological red lines, regular expression rules were designed to match and extract fields. By combining regular expressions with contextual semantic analysis, unstructured text was mapped into standardized fields, and the extracted fields were then standardized.
[0018] Furthermore, in step S1, a knowledge graph of highway engineering terminology is constructed, and its validity is verified through a preset mapping table of highway engineering technical standard fields, including:
[0019] Based on the entity recognition capability of the base model, entities including ecological red lines and landslide-prone areas are extracted from local policy provisions, and relationships including prohibited crossing and required environmental impact assessment reports are constructed. Knowledge graph triples are constructed, including ecological red line → prohibited crossing → route and landslide-prone area → required environmental impact assessment report → route.
[0020] The vague descriptions in the policy, including the prohibition of crossing the ecological red line, are mapped into normative fields, and the implicit conditions are analyzed through the semantic understanding capabilities of the base model.
[0021] The structured fields are compared one by one with the field mapping table of highway engineering technical standards. The verification rules include numerical verification and Boolean verification. If the verification fails, the abnormal field is recorded.
[0022] If the field value does not meet the specifications, an exception is triggered and a correction suggestion is generated to notify the designer.
[0023] Furthermore, S2 incorporates highway engineering textbooks and constructs a terminology comparison table. A comparative learning task is designed for easily confused terms to optimize the consistency between the model output and the standard terminology, including:
[0024] The text of professional books, including highway engineering technical standards, is converted into structured data JSON format through a base model. Terminology, including design speed, curve radius and their definitions, is extracted, a terminology lookup table is constructed, and easily confused terms, including roadbed width and pavement width, are mapped to unique identifiers.
[0025] A contrastive learning task is designed to solve the terminology confusion problem. A contrastive learning framework is adopted, and the consistency between the model output and the standard term is optimized by using the cosine similarity loss function. Positive and negative sample pairs are constructed: positive samples: standard term and corresponding definition; negative samples: confused term and incorrect definition.
[0026] A pedestal model is used to encode sample pairs and calculate cosine similarity. Positive sample similarity is close to 1, and negative sample similarity is close to 0. The model parameters are updated through backpropagation to maximize positive sample similarity and minimize negative sample similarity.
[0027] Furthermore, in S2, a LoRA fine-tuning model is used, the model is trained using the SFT dataset to generate canonical text, a reward function is designed, LoRA weights are fused into the original model, and the model is deployed to the production environment, including:
[0028] The SFT dataset is constructed, with the data source being historical highway engineering feasibility study reports. It includes a route design section with paired input parameters and output text. The data format is a CSV file, containing fields such as: input parameters, including route length and design speed, and expected output. The text is converted into a vector form that the model can process based on tokenization.
[0029] Initialize LoRA parameters, matrix A is a random Gaussian distribution, matrix B is initialized to zero, and the reward function is defined. R represents the overall reward value, ranging from [0,1], and is used to evaluate the quality of the generated text. The weight coefficients for the four evaluation dimensions are determined as follows: A panel of 10 senior engineers with over 10 years of experience in highway engineering design used the analytic hierarchy process (AHP) to score the importance of each dimension. After a consistency test (CR < 0.1), the weight values were calculated, specifically representing the standard compliance weight. =0.4, Terminology Consistency Weight =0.3, Space Security Weight =0.2, Economic rationality weight =0.1, which satisfies =1;
[0030] The formula for calculating the degree of compliance with the standard is as follows: Where n is the number of technical parameters that need to be verified; This is the actual value of the i-th technical parameter in the generated content; The standard value is the one required by the corresponding specification; when When it meets the requirements of the specifications, =0; When the parameter is of Boolean type, it takes the value 1 if the requirement is met and 0 if the requirement is not met;
[0031] To indicate terminological consistency, the calculation formula is as follows: Where cos_sim represents the cosine similarity function; E() represents the text embedding vector obtained through the last hidden state of the Qwen3 model; output is the terminology text generated by the model; standard_term is the standard term in the highway engineering terminology standard; by calculating the similarity distribution of 200 positive and negative sample pairs, a threshold of 0.85 is set. When the similarity is <0.85, it is judged as terminology inconsistency.
[0032] The formula for representing spatial security is as follows: Where e is the natural constant; λ is the risk decay coefficient. By analyzing geological disaster cases in national highway engineering from 2018 to 2023, the maximum likelihood estimation method was used to fit λ=0.005. The minimum distance between the selected route and the nearest high-risk area is calculated using GIS spatial analysis.
[0033] To indicate economic rationality, the calculation formula is as follows: ,in, The net present value calculated for the generated scheme; The industry benchmark net present value is determined according to the economic evaluation method for highway construction projects; the max(0,min(1, )) function ensures Within the range [0,1];
[0034] When R < 0.75, the generated content is deemed substandard, a penalty of -1 is applied, and a regeneration mechanism is triggered. The threshold of 0.75 was determined through comparative experiments: 50 historical feasibility study reports were manually scored from 1 to 5 points. The R values corresponding to reports with scores ≥ 4 points (i.e., good) were statistically analyzed, and the 25th percentile was taken as the threshold to ensure that the generated quality is not lower than the excellent level of manual compilation.
[0035] The LoRA parameters are updated by the Adam optimizer and finally merged into the original model weights. The fine-tuned model is then exported and deployed to a cloud server for use.
[0036] Furthermore, in S3, the system connects to the route selection system via an API interface, inputting the start and end coordinates of the selected route, GIS topographic map, and design drawing parameters into the model. It directly extracts the route's geometric features and analyzes the distance between the selected route and high-risk areas through coordinate system alignment and buffer analysis, including:
[0037] Define an API interface. After the route planning is completed in the route selection system, call the API to receive the final route selection data in the route selection system, store the starting and ending coordinates, GIS topographic map and design drawing parameters in JSON format, and send the parameters to the large model server in JSON format.
[0038] Based on the coordinates of the starting and ending points and the horizontal and vertical curves in the GIS topographic map, the distance of the broken line is extracted. Combined with the GIS elevation data and the cut and fill areas in the design drawings, the volume is extracted. The maximum longitudinal slope is extracted through the elevation profile.
[0039] By integrating the map API with the selected route coordinates, the returned JSON data includes landslide risk level and ecological protection area boundaries. The API response data is parsed, fields are extracted and converted into GeoDataFrame format, the minimum distance between the route and the ecological protection area is calculated, and whether the route crosses a high-risk area is marked. Through buffer analysis, the spatial relationship between the route and the high-risk area is evaluated, providing a basis for subsequent risk avoidance.
[0040] Furthermore, in step S3, a chapter outline is generated based on the line selection parameters, the line selection parameters are mapped to the fields of the corresponding chapters, and the chapter content is adjusted according to the line selection results, including:
[0041] The chapter outline is divided into four modules: technical solution, economic analysis, environmental impact, and conclusions and recommendations. The technical solution includes sub-chapter on route design, bridge and tunnel design, and construction organization. The economic analysis includes sub-chapter on quantity summary, IRR and NPV calculation, and cost-benefit analysis. The environmental impact includes sub-chapter on ecological protection, landslide risk, and soil and water conservation. The conclusions and recommendations include sub-chapter on risk mitigation measures and future research directions. A template engine is used to achieve modular management of chapter templates.
[0042] Design the mapping table rules: route length corresponds to the technical solution - route design section field, data type is numeric; earthwork volume corresponds to the economic analysis - engineering quantity summary section field, data type is numeric; landslide risk level corresponds to the environmental impact - geological risk assessment section field, data type is text; parameters are extracted based on regular expressions and filled into the corresponding sections.
[0043] The system sets rules for adjusting the content of the selected route, including adjusting the environmental impact section and the technical solution section. It reads the selected route parameters, determines whether the conditions are met, and loads the corresponding environmental impact sub-section template. When the route crosses a nature reserve, an ecological red line analysis sub-section is added to the environmental impact section. When there is a landslide-prone area, a landslide risk assessment sub-section is added. Based on the parameter values, the system calls the preset sub-section template and inserts it into the technical solution module. When there is an extra-long tunnel, a ventilation and lighting design sub-section is added to the technical solution section. When the route needs to cross a large river, a bridge seismic design sub-section is added.
[0044] Furthermore, in S4, the model outputs standard and specification texts that conform to the compilation methods for feasibility study reports of highway engineering, and simulates expert perspectives to cross-validate the chapter content, including:
[0045] Based on the chapter structure of the feasibility study report preparation method for highway engineering, a standardized Markdown template was designed, including field placeholders. Highway engineering standard text was injected to generate text that conforms to the standard specifications. A table of colloquial vocabulary and standard terminology was established, including "approximately" → "expected" and "somewhat" → "requires further demonstration". Non-standard expressions were matched and replaced. High-frequency terms in the field of highway engineering were compiled, including "this project", "recommendation", and "design speed". Usage scenarios were defined, including "recommendation" for the conclusion chapter. The most appropriate terms were selected based on the context identified by the model.
[0046] Technical clauses are extracted from highway engineering specifications, including highway engineering technical standards, such as curve radius ≥150m. A structured knowledge base is constructed, and verification rules are defined, including triggering a warning if curve radius <150m. The generated technical solution fields are compared with the descriptions in the conclusion section to ensure that the values are consistent. If inconsistencies are found, a regeneration mechanism is triggered to re-call the large model to revise the conclusion section.
[0047] Furthermore, S5 employs RPA to retrieve specification update announcements, the model identifies the update content, and triggers the Kafka message queue, including:
[0048] Deploy scheduled tasks to monitor the official website of the Ministry of Transport, local transportation department websites, and the highway engineering standards database platform. Use selectors to locate the specification update section, extract the title, publication date, and file type, download attachments and store them in the local directory, classify them by year and month, convert the stored text to Markdown text, and retain the table and formula structure.
[0049] Based on the entity recognition capabilities of the large model, the feature fields related to highways in the updated content are extracted, including the minimum radius of curves and the maximum value of longitudinal slope. The change type is classified into adding clauses, modifying clauses, and abolishing clauses. The recognition results are encapsulated in JSON format, including clause number, change type, and effective date, and pushed to a Kafka topic.
[0050] Furthermore, in S5, the model reconstructs entity relationships based on a knowledge graph, calls an external knowledge base, verifies the compliance of the generated content, and retrieves the consistency of the content verified by the module library with the latest specifications, including:
[0051] The entities stored in the highway engineering specifications include curve radius, longitudinal slope and their relationships, including curve radius → impact → horizontal and vertical curve coordination. Based on the semantic understanding capability of the large model, the relationships between entities are extracted from the updated content. When a Kafka message is received, the incremental update of the graph database is triggered, including deleting old nodes and adding relationships.
[0052] The system accesses national standards databases, including highway engineering technical standards, and local policy documents, including provincial mountainous highway design guidelines. It performs highway feature word retrieval and full-text retrieval. The Faiss vector library is used to store the embedding vectors of policy documents generated by the large model. When the generated content contains feature words, similar documents in the Faiss library are retrieved. When there is a conflict between the generated content and the search results, a correction process is triggered. When the conflict type is that the numerical value does not meet the requirements, a correction value is suggested. When the conflict type is that the document reference is incorrect, the latest document number is recommended.
[0053] The beneficial effects of this invention are: it solves the problems of cumbersome data processing, error-prone manual verification, and delayed updates in the preparation of traditional highway engineering reports, and also improves the efficiency, accuracy, and compliance of report generation.
[0054] Traditional highway engineering feasibility study report preparation requires a lot of manual time, including data collection, chapter writing, and compliance verification. This solution shortens the cycle by automating the process, including data cleaning, chapter generation, and compliance verification.
[0055] To reduce manual verification errors and rework costs, while optimizing engineering design through bypass solution recommendations to lower potential disaster repair costs, and to ensure that the report content meets high industry standards in terms of technical details, language style and policy compliance through a multi-verification mechanism of knowledge graph, terminology consistency and compliance verification.
[0056] In particular, the professional domain-enhanced reward function introduced in this invention enables quantitative evaluation of report quality, organically integrating four key dimensions: compliance with standards, consistency of terminology, spatial safety, and economic rationality. Through scientific weighting and threshold setting, this function improves the first-pass yield of reports, shortens risk identification and response time, avoids design rework due to terminological confusion and non-compliance with standards, and makes the report preparation process more scientific, reliable, and of more stable quality. Attached Figure Description
[0057] Figure 1 A flowchart illustrating the method for generating feasibility study reports for highway engineering based on local large-scale model training. Detailed Implementation
[0058] The present invention will be further described clearly and completely below, but the scope of protection of the present invention is not limited thereto.
[0059] Furthermore, the term "and / or" in this article is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone. Additionally, the character " / " in this article, unless otherwise specified, generally indicates that the preceding and following related objects have an "or" relationship.
[0060] Example 1
[0061] The method for generating feasibility study reports for highway engineering based on local large-scale model training employs the following technical solution:
[0062] S1: Select Qwen3 as the base model, deploy it on a local GPU and use INT8 quantization to compress the model volume, integrate multi-source data, including historical project data, GIS topographic maps, design drawings and local policy provisions, and extract standard fields, including route length, design speed, gradient and curve radius, through regular expressions;
[0063] A knowledge graph of highway engineering terminology is constructed, mapping fuzzy policy descriptions to standardized fields, including mapping the prohibition of crossing ecological red lines to protected_area_crossing: false. Implicit conditions, including environmental impact assessment requirements, are parsed based on the semantic understanding of the large model. After generating structured fields, their legality is verified through a pre-set highway engineering technical standard field mapping table, including curve radius ≥150m. Abnormal fields trigger correction suggestions.
[0064] S2: Accelerate model inference based on TensorRT, incorporate highway engineering textbooks, and construct a terminology comparison table. Design comparative learning tasks for easily confused terms, such as roadbed width and pavement width. Optimize the consistency between model output and standard terminology through the cosine similarity loss function.
[0065] A LoRA fine-tuning model is adopted, and the model is trained on the SFT dataset to generate standard text, including input parameters and output chapter pairing. A reward function is designed to reward +1 when the generated content conforms to the standard text, otherwise deduct 1 and trigger regeneration. The LoRA weights are integrated into the original model and deployed to the production environment.
[0066] S3: Connect to the route selection system via API interface, input the starting and ending coordinates of the selected route, GIS topographic map and design drawing parameters into the model, including horizontal and vertical curves, number of bridges and tunnels, directly extract the geometric features of the route, including length, earthwork volume and longitudinal slope, obtain map data along the selected route based on map API, including landslide risk level and ecological protection area boundary, and analyze the distance between the marked route and high-risk area through coordinate system alignment and buffer analysis;
[0067] The outline of chapters is generated based on the route selection parameters and is divided into four major modules: technical solutions, economic analysis, environmental impact, and conclusions and recommendations. Each module is further subdivided into sub-chaps, including route design, engineering quantity summary, IRR and NPV calculation, and geological risk assessment. The route selection parameters are mapped to the fields of the corresponding chapters, such as route length → technical solutions - route design and earthwork volume → engineering quantity summary. The content of the chapters is adjusted according to the route selection results. When the route crosses a nature reserve, the environmental impact chapter adds ecological red line analysis. When there are extra-long tunnels, the technical solutions chapter adds ventilation and lighting design.
[0068] S4: Based on the model output, standard and specification texts that conform to the compilation method of feasibility study reports for highway engineering are output, avoiding colloquial expressions, using professional terms including this project and recommendations, and simulating the expert perspective to cross-validate the chapter content to ensure consistency between technical details and conclusions.
[0069] S5: RPA is used to crawl specification update announcements. The model identifies the updated content, triggers the Kafka message queue, and the model reconstructs entity relationships based on the knowledge graph. It calls the external knowledge base to verify the compliance of the generated content. The retrieval module uses the Faiss vector library to store local policy provisions. The generation module calls Faiss to retrieve relevant provisions, verifies the consistency of the content with the latest specifications, and provides correction suggestions when there are conflicts.
[0070] refer to Figure 1 The diagram shows a flowchart of a method for generating a feasibility study report for a highway project based on training a large local model.
[0071] Furthermore, in S1, multi-source data is integrated, and standardized fields are extracted using regular expressions, including:
[0072] The database extracts past highway engineering design parameter fields, including route length and design speed, and stores them in CSV format. Data cleaning is performed using Pandas, including missing value filling and unit standardization. Topographic map data is obtained by calling ArcGIS API, and spatial features, including slope and elevation, are extracted and converted to GeoJSON format. Geometric parameters, including curve radius and longitudinal slope, are extracted. Text fields are extracted based on the base model. Policy documents from the official website of the local transportation department are crawled. The requests library of Python is used to download PDF files and extract text content based on the base model.
[0073] To address the vague descriptions in local policy provisions, including the prohibition of crossing ecological red lines, regular expression rules such as r"prohibit.*ecological red line" are designed to match and extract fields. By combining regular expressions with contextual semantic analysis, unstructured text is mapped to standardized fields. The extracted fields are then standardized, such as unifying slope >30° as slope: "30+", and a structured data table design_parameters.csv is generated.
[0074] Furthermore, in step S1, a knowledge graph of highway engineering terminology is constructed, and its validity is verified through a preset mapping table of highway engineering technical standard fields, including:
[0075] Based on the entity recognition capabilities of the base model, key entities are extracted from preprocessed policy texts. Specifically, the model is fine-tuned to recognize 12 types of entities specific to the highway engineering field, including sensitive areas such as ecological red lines, landslide-prone areas, and water source protection areas, as well as constraints such as prohibitions on crossing, the requirement to submit environmental impact assessment reports, and height restrictions. The fine-tuning process uses 500 annotated policy documents as a training set, enabling the model to achieve an F1 score of 91.3% for entity recognition in this field.
[0076] Based on the identified entities and relationships, a knowledge graph triple in the form of (subject, predicate, object) is constructed. For example, when a route is identified as prohibiting crossing an ecological protection red line area, the system automatically constructs a triple (ecological red line, prohibition, route); when a landslide-prone area is identified as requiring an environmental impact assessment report, a triple (landslide-prone area, environmental impact assessment report required, route) is generated, and each triple is assigned a confidence score.
[0077] Establish a rule base for mapping policy texts to structured parameters: unify the mapping of statements such as prohibiting crossing ecological red lines to the `protected_area_crossing: false` field; and map the requirement to avoid basic farmland to `basic_farmland_avoidance: true`. The mapping rules are stored in key-value pair format, covering common policy constraints.
[0078] By leveraging the contextual semantic understanding capabilities of the base model, implicit conditions in policies can be analyzed: when the text includes the requirement that if ecological red lines cannot be avoided, sufficient justification and an environmental impact assessment report must be provided, it not only maps protected_area_crossing: true (allowing crossing), but also automatically derives the implicit condition environmental_assessment_required: true.
[0079] The structured fields are compared one by one with the field mapping table of highway engineering technical standards. The verification rules include numerical verification: min_curve_radius 150m and Boolean verification: protected_area_crossing: false. If the verification fails, the abnormal field is recorded.
[0080] If the field value does not meet the specification, such as min_curve_radius: 120m < 150m, an exception is triggered and a correction suggestion is generated, such as suggesting increasing the curve radius to 150m, and the designer is notified via email or API.
[0081] Furthermore, S2 incorporates highway engineering textbooks and constructs a terminology comparison table. A comparative learning task is designed for easily confused terms to optimize the consistency between the model output and the standard terminology, including:
[0082] The text of professional books, including highway engineering technical standards, is converted into structured data JSON format through a base model. Terminology, including design speed, curve radius and their definitions, is extracted. A terminology comparison table is built based on the extraction results. Easily confused terms, such as roadway width and pavement width, are mapped to unique identifiers, such as roadway_width vs. pavement_width.
[0083] A contrastive learning task is designed to address the terminology confusion problem. A contrastive learning framework is adopted, and the consistency between the model output and the standard terminology is optimized through the cosine similarity loss function. Positive and negative sample pairs are constructed. Positive samples are standard terms such as roadway_width and their corresponding definitions, such as the earthwork excavation width within the road design range. Negative samples are confused terms such as pavement_width and their incorrect definitions, such as the asphalt paving width of the road surface. Positive sample pairs are highly consistent in semantics, while negative sample pairs are superficially similar but conceptually different. The difficulty coefficient is controlled between 0.3 and 0.7 (1 indicates that they are very easy to distinguish, and 0 indicates that they are completely indistinguishable).
[0084] A pedestal model is used to encode sample pairs. The input text is encoded into a 128-dimensional vector representation by the encoder. Cosine similarity is calculated, with positive sample similarity close to 1 (e.g., 0.95) and negative sample similarity close to 0 (e.g., 0.1). Model parameters are updated through backpropagation, with a learning rate of 2e-5, weight decay of 0.01, and batch size of 16. An early stopping strategy is adopted during training, terminating training when the validation set loss does not decrease for three consecutive rounds to prevent overfitting. The training data is divided into a training set (70%), a validation set (15%), and a test set (15%) to maximize positive sample similarity and minimize negative sample similarity.
[0085] Furthermore, in S2, a LoRA fine-tuning model is used, the model is trained using the SFT dataset to generate canonical text, a reward function is designed, LoRA weights are fused into the original model, and the model is deployed to the production environment, including:
[0086] The SFT dataset is constructed, with the data source being historical highway engineering feasibility study reports. It includes a route design section with paired input parameters and output text. The data format is a CSV file, containing the following fields: input parameters (including route length and design speed) and expected output (e.g., the total route length of this project is 12.5km and the design speed is 60km / h). The text is converted into a vector form that the model can process based on tokenization.
[0087] Initialize LoRA parameters, matrix A is a random Gaussian distribution, matrix B is initialized to zero, and the reward function is defined. R represents the overall reward value, ranging from [0,1], and is used to evaluate the quality of the generated text. The weight coefficients for the four evaluation dimensions are determined as follows: A panel of 10 senior engineers with over 10 years of experience in highway engineering design used the analytic hierarchy process (AHP) to score the importance of each dimension. After a consistency test (CR < 0.1), the weight values were calculated, specifically representing the standard compliance weight. =0.4, Terminology Consistency Weight =0.3, Space Security Weight =0.2, Economic rationality weight =0.1, which satisfies =1;
[0088] The formula for calculating the degree of compliance with the standard is as follows: Where n is the number of technical parameters that need to be verified; This is the actual value of the i-th technical parameter in the generated content; The standard value is the one required by the corresponding specification; when When it meets the requirements of the specifications, =0; When the parameter is a boolean type such as protected_area_crossing, the value is 1 if the requirement is met, and 0 if the requirement is not met;
[0089] To indicate terminological consistency, the calculation formula is as follows: Where cos_sim represents the cosine similarity function; E() represents the text embedding vector obtained through the last hidden state of the Qwen3 model; output is the terminology text generated by the model; standard_term is the standard term in the highway engineering terminology standard; by calculating the similarity distribution of 200 positive and negative sample pairs, a threshold of 0.85 is set. When the similarity is <0.85, it is judged as terminology inconsistency.
[0090] The formula for representing spatial security is as follows: Where e is the natural constant; λ is the risk decay coefficient. By analyzing 500 cases of geological disasters in highway engineering across the country from 2018 to 2023, the maximum likelihood estimation method was used to fit λ=0.005. The minimum distance between the selected route and the nearest high-risk area, such as a landslide area or an ecological protection zone, is expressed in meters and is calculated through GIS spatial analysis.
[0091] To indicate economic rationality, the calculation formula is as follows: ,in, The net present value calculated for the generated scheme; The industry benchmark net present value is determined according to the economic evaluation method for highway construction projects; the max(0,min(1, )) function ensures Within the range [0,1];
[0092] When R < 0.75, the generated content is deemed substandard, a penalty of -1 is applied, and a regeneration mechanism is triggered. The threshold of 0.75 was determined through comparative experiments: 50 historical feasibility study reports were manually scored from 1 to 5 points. The R values corresponding to reports with scores ≥ 4 points (i.e., good) were statistically analyzed, and the 25th percentile was taken as the threshold to ensure that the generated quality is not lower than the excellent level of manual compilation.
[0093] The LoRA parameters are updated by the Adam optimizer and finally merged into the original model weights. The fine-tuned model is then exported and deployed to a cloud server for use.
[0094] Furthermore, in S3, the system connects to the route selection system via an API interface, inputting the start and end coordinates of the selected route, GIS topographic map, and design drawing parameters into the model. It directly extracts the route's geometric features and analyzes the distance between the selected route and high-risk areas through coordinate system alignment and buffer analysis, including:
[0095] Define an API interface that conforms to the OpenAPI 3.0 specification, including detailed request body and response format descriptions. After the route selection system completes route planning, the API is called to receive the final route selection data from the system. The origin and destination coordinates, GIS topographic map, and design drawing parameters are stored uniformly in JSON format. These parameters are then sent to the large model server in JSON format, such as:
[0096] {
[0097] "start_point": {"latitude": 22.5432, "longitude": 113.9876},
[0098] "end_point": {"latitude": 22.5500, "longitude": 113.9900},
[0099] "gis_data": {"elevation": [100, 150, 200], "slope": [3, 5, 7]},
[0100] "design_parameters": {"horizontal_curve_radius": 150, "bridge_count": 2, "tunnel_count": 1}
[0101] };
[0102] Based on the coordinates of the starting and ending points and the horizontal and vertical curves in the GIS topographic map, the broken line distance is extracted, such as the total length = 12.5km. Combining the GIS elevation data and the cut and fill areas in the design drawings, the total earthwork volume is calculated using the average section method, such as the total earthwork volume = 300,000m³. The maximum longitudinal slope is extracted from the elevation profile, such as the maximum longitudinal slope = 6%.
[0103] By integrating the map API with the selected route's coordinates, the returned JSON data includes the landslide risk level "slope_risk":"level_2" and the ecological protection area boundary "protected_area_name":"XX Nature Reserve". The API response data is parsed, fields are extracted and converted to GeoDataFrame format, and the minimum distance between the route and the ecological protection area is calculated: min_distance=geopandas.overlay(gis_data, api_data, how="nearest"). Whether the route crosses a high-risk area is marked. Buffer analysis, such as setting a buffer radius of 500 meters, is used to assess the spatial relationship between the route and the high-risk area, providing a basis for subsequent risk avoidance.
[0104] Furthermore, in step S3, a chapter outline is generated based on the line selection parameters, the line selection parameters are mapped to the fields of the corresponding chapters, and the chapter content is adjusted according to the line selection results, including:
[0105] The chapter outline is divided into four modules: technical solution, economic analysis, environmental impact, and conclusions and recommendations. The technical solution includes sub-chapter on route design, bridge and tunnel design, and construction organization. The economic analysis includes sub-chapter on quantity summary, IRR and NPV calculation, and cost-benefit analysis. The environmental impact includes sub-chapter on ecological protection, landslide risk, and soil and water conservation. The conclusions and recommendations include sub-chapter on risk avoidance measures and future research directions. A template engine such as Jinja2 is used to realize the modular management of chapter templates.
[0106] Design the mapping table rules. The route length corresponds to the technical solution - route design section field, and the data type is numeric. The mapping logic example is route_length: 12.5km. The earthwork volume corresponds to the economic analysis - engineering quantity summary section field, and the data type is numeric. The mapping logic example is earthwork_volume: 300,000m³. The landslide risk level corresponds to the environmental impact - geological risk assessment section field, and the data type is text. The mapping logic example is landslide_risk: high risk. Based on the regular expression r"route length:\s*(\d+\.?\d*)km" extract the parameter "route length:12.5km" and fill it into the corresponding section. r is the Python raw string prefix. ( ) defines the boundary of the capture group. \s* matches whether there is a space. \d+ matches 12. \.? matches ".". \d* matches 5. Finally, it matches the km unit.
[0107] The system sets rules for adjusting the content of the selected route, including adjusting the environmental impact section and the technical solution section. It reads the selected route parameters, determines whether the conditions are met, and loads the corresponding environmental impact sub-section template. When the route crosses a nature reserve (e.g., protected_area_crossing: true), an ecological red line analysis sub-section is added to the environmental impact section. When there is a landslide-prone area (e.g., landslide_risk: high risk), a landslide risk assessment sub-section is added. Based on parameter values such as tunnel length, a preset sub-section template is called and inserted into the technical solution module. When there is an extra-long tunnel (e.g., length > 3km), a ventilation and lighting design sub-section is added to the technical solution section. When the route needs to cross a large river, a bridge seismic design sub-section is added.
[0108] Furthermore, in S4, the model outputs standard and specification texts that conform to the compilation methods for feasibility study reports of highway engineering, and simulates expert perspectives to cross-validate the chapter content, including:
[0109] Based on the chapter structure of the feasibility study report preparation method for highway engineering, a standardized Markdown template such as the Jinja2 template is designed, containing field placeholders such as {{ route_length}}. Highway engineering standard text is injected to generate text that conforms to the standard specifications, such as "the route length of this project is 12.5km". A table of colloquial vocabulary and standard terminology is established, including "approximately" → "estimated", "somewhat" → "requires further demonstration". Non-standard expressions are matched and replaced, such as "approximately (\d+\.?\d*)km" → "estimated\1km", where \1 indicates a reference to the content of the first capture group. When matching "approximately 12.5km", \1 will be replaced with "12.5". High-frequency terms in the field of highway engineering are compiled, including "this project", "recommendation", and "design speed", and usage scenarios are defined, including "recommendation" for the conclusion chapter. Based on the model, the most appropriate term is selected based on the context, such as "route design" in the technical solution chapter and "route mileage" in the economic analysis chapter.
[0110] Technical clauses are extracted from highway engineering specifications, including highway engineering technical standards, such as curve radius ≥150m. A structured knowledge base is constructed, and verification rules are defined, including triggering a warning if curve radius <150m. The generated technical solution fields, including route length and earthwork volume, are compared with the statement in the conclusion chapter, which includes a total route length of 12.5km, to ensure that the values are consistent. If inconsistencies are found, a regeneration mechanism is triggered to re-call the large model to revise the conclusion chapter.
[0111] Furthermore, S5 employs RPA to retrieve specification update announcements, the model identifies the update content, and triggers the Kafka message queue, including:
[0112] Deploy scheduled tasks to monitor the official website of the Ministry of Transport, local transportation department websites, and the highway engineering standards database platform. Use selectors to locate the specification update section, extract the title, publication date, and file type, download attachments and store them in the local directory, classify them by year and month, convert the stored text to Markdown text, and retain the table and formula structure.
[0113] Based on the entity recognition capabilities of the large model, highway-related feature fields are extracted from the updated content, including minimum curve radius and maximum longitudinal slope. Change type classification includes adding clauses, modifying clauses (e.g., revising to longitudinal slope ≤3%), and abolishing clauses. The recognition results are encapsulated in JSON format, including clause number, change type, and effective date, and pushed to a Kafka topic: "article_id":, "change_type": "Added", "content": "Added content: Subgrade compaction degree ≥95%", "effective_date".
[0114] Furthermore, in S5, the model reconstructs entity relationships based on a knowledge graph, calls an external knowledge base, verifies the compliance of the generated content, and retrieves the consistency of the content verified by the module library with the latest specifications, including:
[0115] The entities stored in the highway engineering specifications include curve radius, longitudinal slope and their relationships, including curve radius → impact → horizontal and vertical curve coordination. Based on the semantic understanding capability of the large model, the relationships between entities are extracted from the updated content. Curve radius ≥150m → allowed → maximum longitudinal slope 3%. When a Kafka message is received, the incremental update of the graph database is triggered, including deleting old nodes and adding relationships.
[0116] The system accesses national standards databases, including highway engineering technical standards, and local policy documents, including provincial mountainous highway design guidelines. It performs highway keyword searches, including curve radius, and full-text searches, including longitudinal slope ≤3%. The Faiss vector library stores the embedding vectors of policy documents generated from the large model. When the generated content includes a curve radius of 120m, it searches the Faiss library for similar documents with curve radii ≥150m. If the generated content conflicts with the search results (e.g., a curve radius of 120m violating ≥150m), a correction process is triggered. If the conflict type is a numerical mismatch, it suggests adjusting the curve radius to 150m. If the conflict type is an incorrect document citation, it recommends referencing the latest document number.
[0117] Example 2
[0118] A feasibility study report for the reconstruction and expansion project of a certain section of provincial highway has been generated. The design standard is a Class II highway with a design speed of 60 km / h. The traffic volume is projected to be 8,000 vehicles per day in 2025, with an annual growth rate of 5%. The design institute has completed the highway route selection, numbered XW-AY01.
[0119] The personnel writing the feasibility study report for highway engineering call the API to receive the final alignment data from the alignment system, including the following structured parameter groups:
[0120] {
[0121] "coordinate": {
[0122] "start": {"lat": 25.1265, "lon": 115.6421} / / Starting coordinates
[0123] "end": {"lat": 25.0987, "lon": 115.3028} / / End point coordinates
[0124] }
[0125] "design_params": {
[0126] "design_speed": 60, / / Design speed 60km / h
[0127] "max_slope": 5.2, / / Maximum longitudinal slope 5.2%
[0128] "min_curve_radius": 120, / / Minimum curve radius 120m
[0129] "bridge_count": 3, / / 3 bridges
[0130] "tunnel": {
[0131] "exist": true, / / Tunnel exists
[0132] "length": 2.5 / / Tunnel length 2.5km
[0133] }
[0134] },
[0135] "gis_data": "DEM.tif of a section of provincial highway", / / GIS topographic map (including elevation / slope raster)
[0136] "policy_ref": "Ecological Protection Zone Planning" / / Local policy basis
[0137] }
[0138] Perform GIS spatial processing, calling the map API based on the input coordinates coordinate.start and coordinate.end, outputting: "Crossing the buffer zone of a national ecological protection area, with the boundary distance from the route buffer_distance=320m"; parse the elevation data in the input file gis_data, extracting: total route length = distance_calculation(gis_data, start,end)=34.8km, input parameter max_slope=5.2% → validation standard, longitudinal slope of mountain roads ≤6% → pass.
[0139] To generate the report content, input → chapter mapping closed loop, as shown in the table below;
[0140] Input parameters Technical Solution Chapter Generate content design_speed:60 3.1 Route Design This project adopts a design speed of 60km / h, which meets the requirements for Class I highways in mountainous areas. min_curve_radius:120 3.1 Route Design The minimum horizontal curve radius is 120m (see K22+700), which is lower than the standard value of 150m. It is recommended to optimize it to 160m. tunnel.length: 2.5 3.3 Tunnel Design The tunnel is 2.5km long and uses a two-lane, two-way design. bridge_count:3 3.2 Bridge Engineering The entire line includes three bridges (see Appendix 1), among which the Xunshui River Bridge is 580m long.
[0141] The parameter-driven section adds new content based on input parameters. For example, because the input parameter `buffer_distance=320m<500m`, section 5.3, "Ecological Protection Zone Avoidance Measures," is added: The route is 320m from the nearest boundary of the protection zone. Based on the input coordinate verification results, four sound barriers and animal passages need to be installed. Because the input parameter `max_slope=5.2%>5%`, section 6.2, "Longitudinal Slope Economic Efficacy Demonstration," is added: The maximum longitudinal slope of 5.2% increases truck operating costs by 12%, and it is recommended to add a gentle slope section at K18+200.
[0142] Terminology consistency check, input parameter design_speed:60 → Conclusion section terminology matching: It is recommended to adopt a design speed of 60km / h, which is consistent with section 3.1 of the technical solution; Numerical logic verification, input parameter tunnel.length=2.5km → Summary table of engineering quantities: Tunnel excavation volume 250000m³, calculated based on GIS elevation data and tunnel parameters. If the deviation of the tunnel cost field in the economic analysis is >10%, → trigger regeneration.
[0143] When the input parameter min_curve_radius:120 triggers an alarm, the system detects that a new national regulation has been issued:
[0144] / / Kafka push update (source: RPA crawl)
[0145] {
[0146] "article",
[0147] "change": "The minimum curve radius of secondary roads in mountainous areas has been reduced from 150m".
[0148] "effective_date",
[0149] }
[0150] The original warning has been marked as an outdated historical warning. A note has been added to the technical solution section: Note: The radius of the K22+700 curve is 120m, which meets the requirements of the new regulations.
[0151] The final feasibility study report for the highway project is generated, and excerpts of some key chapters include: Chapter 3 Technical Scheme: 3.1 Route Design, 3.2 Bridge Engineering, 3.3 Tunnel Design; Chapter 5 Environmental Impact: 5.3 Ecological Protection Zone Avoidance Measures, 5.4 Geological Risk Assessment; Chapter 6 Economic Analysis: 6.1 Summary of Engineering Quantities, 6.2 Economic Demonstration of Longitudinal Slope; Chapter 8 Conclusions and Recommendations.
[0152] 3.1 Route Design: This project starts at coordinates: E115.6421°, N25.1265° and ends at coordinates: E115.3028°, N25.0987°, with a total length of 34.8km. The design speed is 60km / h. There are 32 horizontal curves along the entire route, with the smallest horizontal curve radius being 120m (at K22+700). This value is lower than the standard lower limit of 150m, and it is recommended to optimize it to 160m, which requires an additional excavation volume of 18,000 m³. Longitudinal slope design: The maximum longitudinal slope is 5.2%, and an uphill lane needs to be added at K18+200.
[0153] 3.2 Bridge Engineering: A total of 3 bridges are constructed along the entire line: Bridge 1 is 580m long with a span combination of 6×30m precast T-beams; Bridge 2 is 420m long with a main span of 80m continuous rigid frame; Bridge 3 is 320m long with cast-in-place box girder.
[0154] 3.3 Tunnel Design: The tunnel is 2.5km long, with two tunnels and four lanes in both directions. The ventilation and lighting system is designed according to standards and requires 8 sets of axial flow fans with a power of 2×110kW.
[0155] 5.3 Ecological Protection Zone Avoidance Measures: The route is 320m from the nearest boundary of the national nature reserve. In accordance with the ecological protection zone plan, the following measures will be taken: 4 sound barriers will be set up, with a total length of 2.1km; 3 wildlife crossings will be constructed, with culverts under the bridges; 38.5 hectares of vegetation will be restored outside the red line.
[0156] 5.4 Geological Risk Assessment: Through comparison with the landslide disaster database, it was found that K7+200 is a high landslide risk area with 4 landslides in the past 10 years. The treatment plan adopts anti-slide piles + prestressed anchor cables, with a pile length of 15m and a spacing of 2m, and an additional 1200m³ of concrete is required.
[0157] 6.1 Summary of project quantities: 1.68 million m³ of earthwork for roadbed, 12,000 m³ of concrete for bridges, and 250,000 m³ of tunnel excavation;
[0158] 6.2 Economic justification for longitudinal slope: Due to the maximum longitudinal slope of 5.2%, the fuel cost of trucks increases by 12% → NPV decreases from 180 million to 150 million. It is recommended to add a gentle slope section at K18+200 with a length of 800m, which can increase NPV to 165 million.
[0159] Curve radius optimization: The curve radius of 120m at K22+700 has passed the new regulations and does not need to be adjusted; Ecological avoidance measures: The 320m distance from the boundary of the protected area meets the minimum buffer requirement, and the plan is feasible; Investment recommendation: The total cost is 2.43 billion yuan, and the IRR is 7.2%. It is recommended to proceed with the preliminary design according to the current parameters.
[0160] Traditional manual parameter verification takes 3 days, with engineers checking 100+ specification clauses. This solution completes verification within 30 minutes. Traditional manual report writing takes 3 weeks and requires multi-disciplinary collaboration. This solution generates a complete report with charts in 4 hours. Traditional manual specification update response is delayed by 1-2 weeks. This solution uses Kafka+RPA to correct within 30 seconds.
[0161] Zero-deviation parameter transfer: input parameter tunnel length 2.5km → engineering quantity calculation 250,000 m³ → cost analysis full-link closed loop, eliminating manual transcription errors; landslide database linked to GIS coordinates, generating protection plan at K7+200, avoiding the problem of traditional design ignoring local geological risks;
[0162] The system boasts a comprehensive database of national and local regulations, with an update cycle of less than one hour. For example, due to the release of new regulations, the minimum curve radius alarm can be triggered and deactivated without any manual intervention. Policy terminology is 100% matched, mapping the 320m ecological protection zone to ecological regulations clauses to avoid colloquial descriptions that could lead to approval disputes.
[0163] The above formulas are all dimensionless calculations. Dimensionless calculations can be performed using various methods such as standardization, which will not be elaborated here. The formulas are derived from software simulations based on a large amount of collected data, and the preset parameters in the formulas can be set by those skilled in the art according to the actual situation.
[0164] In conclusion, the above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.
[0165] This invention provides a method for generating feasibility study reports for highway engineering based on a locally deployed large model. It integrates multi-source data using a locally deployed large model, extracts standard fields through regular expressions, and constructs a highway engineering knowledge graph to achieve mapping and verification from fuzzy policies to structured fields. TensorRT is used to accelerate inference, a standard terminology list is injected, and contrastive learning is combined to optimize terminology consistency. LoRA fine-tuning and a reward function are used to generate standard text. After inputting route parameters, geometric features are calculated, and bypass schemes are recommended based on a disaster database to generate chapter content. A formal report is output based on a template, and cross-validation ensures data consistency. RPA is used to capture standard updates, and Kafka and Faiss vector libraries are used for compliance verification, triggering incremental updates and conflict corrections to the knowledge graph, forming a fully automated and intelligent feasibility study report generation system.
Claims
1. A method for generating feasibility study reports for highway engineering based on local large-scale model training, characterized in that, include: S1: Select a large language model as the base model, deploy it locally, compress the model using quantization technology, and integrate multi-source heterogeneous data. The multi-source heterogeneous data includes at least historical project data, geographic information system topographic maps, engineering design drawings, and local policy provisions. Extract standard fields using pattern recognition technology; construct a highway engineering terminology knowledge graph, map unstructured policy descriptions into structured standard fields, and parse the implicit conditions of policies based on the semantic understanding capabilities of the large model. After generating structured fields, perform legality verification through a preset highway engineering technical standard mapping table, and generate correction suggestions for fields that do not meet the standards. S2: An inference acceleration framework is adopted to optimize the model's inference efficiency, professional knowledge in the field of highway engineering is injected, a terminology mapping table is constructed, a comparative learning task is designed for easily confused professional terms, and the consistency between the model output and the standard terminology is optimized through a similarity loss function. Based on parameter fine-tuning, the training model generates standardized text, establishes a reward mechanism, provides positive feedback for content with a reward value greater than a preset threshold, provides negative feedback for content with a reward value less than a preset threshold and triggers regeneration, integrates the optimized parameters into the original model, and completes model deployment; S3: Connect to the highway alignment system via the application programming interface (API), input the spatial coordinates, geographic information data, and engineering design parameters of the selected route, extract the geometric feature parameters of the route, obtain the geographic environment data along the route, and calculate the spatial relationship between the route and environmentally sensitive areas through spatial analysis; generate a hierarchical chapter structure based on the alignment feature parameters. The hierarchical chapter structure includes four major modules: technical solution, economic analysis, environmental impact, and conclusions and recommendations. Each module has corresponding sub-chaps, and the chapter content is adjusted according to the alignment features. S4: The control model outputs standard text that conforms to the specifications for compiling feasibility study reports for highway engineering, unifies the expression of professional terminology, and performs cross-chapter content consistency verification. S5: Employs automated technology to monitor specification updates, triggers knowledge graph reconstruction through message passing mechanisms, calls external knowledge bases to verify content compliance, builds a vector retrieval system to store and match local policy provisions, verifies the consistency of generated content with the latest specifications, and provides correction suggestions for conflicting content; The S2 process of generating standardized text based on parameter fine-tuning training model includes: constructing a supervised fine-tuning dataset, the data of which comes from historical highway engineering feasibility study reports, containing the mapping relationship between route design parameters and corresponding standard text, and converting the text data into a vector representation that the model can process; The reward mechanism established in S2 includes: initializing a low-rank adaptive parameter matrix and defining a multi-dimensional reward function. The reward function comprehensively evaluates four dimensions: compliance with standards, consistency of terminology, spatial safety, and economic rationality. The weight of each dimension is determined through expert evaluation. The compliance with standards is calculated based on the deviation between the generated content and the technical standard requirements. The consistency of terminology is measured by vector similarity to determine the degree of matching between the generated terminology and the standard terminology. The spatial safety is calculated based on the spatial relationship between the route and the risk area. The economic rationality is determined based on the ratio of economic indicators to industry benchmarks. In step S2, the optimized parameters are fused into the original model to complete the model deployment. This includes updating the low-rank adaptation parameters through a machine learning optimizer, fusion of the optimized parameters into the weights of the original model, and completing the model export and deployment.
2. The method for generating highway engineering feasibility study reports based on local large model training as described in claim 1, characterized in that, The S1 integrates multi-source heterogeneous data and extracts standardized fields using pattern recognition technology, including: Highway engineering design parameters are extracted from historical project databases, stored in a structured data format, and preprocessed using a data cleaning framework, including missing data completion and unit of measurement standardization. Call the geographic information system interface to obtain terrain spatial data, extract terrain feature parameters, convert the spatial data into standard geographic information format, and extract road geometric feature parameters; Text features are extracted based on a pre-trained language model. Policy documents issued by local transportation authorities are obtained through web scraping tools, electronic documents are downloaded, and text content is extracted based on the pre-trained language model. To address imprecise expressions in policy texts, a set of pattern recognition rules is designed. Key constraints are extracted through text matching. By combining pattern recognition and contextual semantic analysis techniques, unstructured policy texts are mapped into standardized fields, and the extracted fields are subjected to standardized transformation processing.
3. The method for generating highway engineering feasibility study reports based on local large model training as described in claim 1, characterized in that, The S1 section constructs a knowledge graph of highway engineering terminology, and performs legality verification through a pre-set highway engineering technical standard mapping table, including: Based on the information extraction capabilities of the adopted base model, professional entities and the constraints between entities are identified from local policy texts, and the entity-relationship-entity structure of the knowledge graph is constructed. Unstructured constraints in policies are mapped to standardized data fields, and implicit constraints in text are parsed through the contextual understanding capabilities of pre-trained language models. The generated structured data fields are compared item by item with the preset mapping table of highway engineering technical standard fields. Verification rules, including numerical range verification and logical condition verification, are applied to mark fields that fail the verification as abnormal. When a field value is detected as not conforming to technical standards and specifications, an exception handling mechanism is triggered to generate standardized correction suggestions and send exception notifications to relevant personnel through preset communication channels.
4. The method for generating highway engineering feasibility study reports based on local large model training as described in claim 1, characterized in that, S2 incorporates professional knowledge from the highway engineering field, constructs a terminology mapping table, and designs comparative learning tasks for easily confused professional terms, including: Highway engineering technical standards and related professional literature are converted into structured data using the adopted base model. Professional terms and their definitions are extracted, a terminology comparison table is constructed, and unique identifiers are assigned to easily confused terms. Design a contrastive learning training mechanism to construct positive and negative sample pairs of terms, where positive samples contain standardized terms and their corresponding accurate definitions, and negative samples contain confusing terms and incorrect definitions; The consistency between the model output and the standard terminology is evaluated using a vector similarity metric function. The similarity of positive sample pairs is maximized and the similarity of negative sample pairs is minimized through neural network parameter optimization, and the internal parameters of the model are updated.
5. The method for generating highway engineering feasibility study reports based on local large model training as described in claim 1, characterized in that, In S3, the system connects to the highway alignment system via an application programming interface (API). It inputs the spatial coordinates, geographic information data, and engineering design parameters of the selected route, extracts the route's geometric feature parameters, and calculates the spatial relationship between the route and environmentally sensitive areas through spatial analysis. This includes: Define a standardized interface protocol. After the route planning is completed by the route selection system, the final route selection data is obtained through the interface. Spatial coordinates, geographic information data and design parameters are converted into structured data format and transmitted to the model server. Based on the coordinates of the starting and ending points and the route curve characteristics in the geographic information data, the route length is calculated. Combined with the elevation data and the design cut and fill area, the earthwork volume is calculated. The longitudinal slope characteristics of the route are extracted from the topographic profile data. The system calls the geographic information service interface to obtain environmental risk data within the selected route area, including geological disaster risk level and ecological protection zone boundary information. The returned risk data is converted into a geospatial data structure, the spatial distance between the route and the ecological protection area is calculated, the spatial relationship between the route and high-risk areas is identified, and the spatial location relationship between the route and various risk areas is evaluated through spatial buffer analysis technology.
6. The method for generating highway engineering feasibility study reports based on local large model training as described in claim 1, characterized in that, The S3 step involves generating a hierarchical chapter structure based on line selection feature parameters and adjusting the chapter content according to the line selection features, including: The design incorporates a hierarchical chapter structure, including four core modules: technical solutions, economic analysis, environmental impact, and conclusions and recommendations. Each core module is further divided into specialized sub-chaps, and a template engine is used to enable modular configuration and management of chapter templates. Establish a parameter-chapter mapping rule table to define the correspondence between line selection parameters and report chapter fields, including numerical parameter mapping rules and text parameter mapping rules. Extract parameter values from the line selection data and fill them into the corresponding chapter fields using pattern matching technology. Configure a condition-triggered mechanism to adjust the chapter content structure based on the route selection feature parameters, thereby achieving a match between the report content and the route selection features.
7. The method for generating highway engineering feasibility study reports based on local large model training as described in claim 1, characterized in that, The control model output in S4 conforms to the standard text of the highway engineering feasibility study report preparation specifications, and performs cross-chapter content consistency verification, including: Based on the chapter structure of the highway engineering feasibility study report preparation specifications, a standardized document template is designed, parameterized placeholders are set, standardized text content is injected, and a report text that conforms to industry standards is generated. A mapping table between non-standard expressions and professional terms is established. Non-standard expressions are identified and replaced through text pattern matching. A highway engineering professional terminology library is constructed, applicable context scenarios are defined for key terms, and professional terms that conform to the scenarios are selected based on semantic context analysis. Technical constraints are extracted from highway engineering technical specifications, a structured technical rule knowledge base is constructed, parameter verification rules are set, an alarm mechanism is triggered for parameter values that violate technical specifications, the consistency of key parameters in the technical solution chapter with the corresponding statements in the conclusion chapter is verified, and when parameter values are found to be inconsistent, the content regeneration process is activated, and the base model is called to correct and update the relevant chapter content.
8. The method for generating highway engineering feasibility study reports based on local large model training as described in claim 1, characterized in that, The S5 uses automated technology to monitor specification update information, including: Configure scheduled monitoring tasks to track the official websites of transportation authorities, local traffic management platforms, and industry standard databases, locate the areas of updated information, extract information summaries, release time and document type, obtain updated documents and classify and store them according to time dimension, convert the document content into a structured format, and retain the original document's table and formula structure; By utilizing the entity recognition function of the base model, the relevant change features and change types of highway engineering technology are extracted from the updated content. The recognition results are encapsulated into a structured data format, including specification identifiers, change categories and effective time information, and pushed to a distributed message queue system.
9. The method for generating a highway engineering feasibility study report based on local large model training as described in claim 1, characterized in that, In S5, knowledge graph reconstruction is triggered through a message passing mechanism, and an external knowledge base is called to verify content compliance and check the consistency of the generated content with the latest specifications, including: A knowledge graph of highway engineering specifications is constructed to store technical specification entities and their relationships. Based on the base model, constraint rules between entities are extracted from the updated specification content. When a specification update message is received, the incremental update mechanism of the knowledge graph is triggered to maintain nodes and relationships. Access to national and local highway engineering standard databases is provided to establish a multi-dimensional search mechanism, including keyword search and full-text semantic search. A vector search system is used to store the semantic embedding vectors of standard provisions. When the generated content contains specific technical features, similar standard provisions are searched. When a conflict is detected between the content and the standard provisions, a correction process is initiated, and corresponding correction suggestions are provided according to the conflict type, including suggestions for adjusting parameter values and updating standard references.
Citation Information
Patent Citations
Database data processing method and device based on distributed file storage
CN118626464A
Large model-based road detection report generation method, apparatus and device, and medium
CN120278162A