Engineering cost data evaluation method and device, electronic equipment and storage medium

Abstract

The engineering cost data evaluation method, device, electronic equipment and storage medium provided by the embodiment of the application, the method comprises the following steps: first, obtaining a cost analysis request, determining a structured business parameter and a target cost value based on the cost analysis request; then, performing statistical query in the database based on the structured business parameter, obtaining a judgment enumeration value and an evidence sample set corresponding to the target cost value, and obtaining a data contract based on the judgment enumeration value and the evidence sample set; thereafter, adding the data contract to the system prompt word of the large language model to generate an evaluation result by using the large language model; next, performing consistency test on the evaluation result based on the data contract to obtain a test result; finally, when the test result represents that the consistency test of the evaluation result and the data contract is passed, obtaining a cost data evaluation result based on the test result, thereby effectively improving the credibility and auditability of the conclusion in the professional cost evaluation scene.

Description

Technical Field

[0001] The present application relates to the technical field of artificial intelligence, and in particular to a construction cost data evaluation method, apparatus, electronic device and storage medium. Background Art

[0002] Construction cost analysis is a core business link in the processes of real estate development, infrastructure investment calculation and construction bidding. Business personnel usually need to combine the cost ranges of historical projects of the same type to judge the rationality of the unit cost value of the target project. The common core requirement of the above scenarios is to make objective judgments relying on the enterprise's historical cost database, and provide a readable and traceable analysis report in the form of natural language. Current cost data query tools usually combine the data retrieval capability of a relational database with the text generation capability of a large language model, query the original project data list through the database, and then use the retrieval-augmented generation or tool calling function of the large language model to output cost rationality opinions.

[0003] However, in the prior art, in judgment scenarios where a definite conclusion needs to be given, the judgment of the large language model tends to rely on the experience in the training data. Even if the retrieval results of the database are transmitted as context, since the large language model can still independently decide how to use the retrieval results or tool results, including ignoring, rewriting or re-inferring, the consistency between the conclusion of the key judgment link and the basic data cannot be guaranteed. This situation easily leads to the inconsistency between the judgment conclusion output by the large language model and the actual retrieval results, or the values cited in the generated explanation text do not actually exist in the historical project evidence, which further makes the generated cost evaluation result lack clear data support and cannot be traced, and it is difficult to meet the application requirements for conclusion credibility and auditability in professional evaluation scenarios. Summary of the Invention

[0004] The embodiments of the present application provide a construction cost data evaluation method, apparatus, electronic device and storage medium, which can solve the above technical problems.

[0005] To achieve the above objects, a first aspect of the embodiments of the present application provides a construction cost data evaluation method, the method comprising: acquiring a cost analysis request, and determining structured business parameters and a target cost value based on the cost analysis request; performing a statistical query in a database based on the structured business parameters to obtain a judgment enumeration value and an evidence sample set corresponding to the target cost value, and obtaining a data contract based on the judgment enumeration value and the evidence sample set; adding the data contract to the system prompt of a large language model, so as to generate an evaluation result by using the large language model. Based on the data contract, a consistency check is performed on the evaluation results to obtain the check results. When the test result indicates that the consistency between the evaluation result and the data contract has passed the test, the cost data evaluation result is obtained based on the test result.

[0006] In some embodiments, the step of performing a statistical query in the database based on the structured business parameters to obtain the judgment enumeration value and evidence sample set corresponding to the target cost value includes: Based on the structured business parameters, a quantile pipeline query is performed in the database to obtain the target quantile threshold; The target cost value is compared with the target quantile threshold, and the judgment enumeration value representing the cost evaluation level is generated based on the comparison result. In the database, a nearest neighbor search is performed based on the target cost value to obtain a preset number of historical sample records. Multiple historical sample records are combined to obtain the evidence sample set.

[0007] In some embodiments, the step of performing a quantile pipeline query in the database based on the structured business parameters to obtain the target quantile threshold includes: Based on the structured business parameters, the database is filtered and sorted to obtain an ordered sample set; The target quantile position corresponding to the preset quantile ratio is obtained by multiplying the difference between the total number of samples in the ordered sample set and the first value, and adding the preset offset constant. The two boundary sample values ​​adjacent to the target quantile position in the ordered sample set are determined, and the two boundary sample values ​​are linearly interpolated using the fractional part of the target quantile position to obtain the target quantile threshold.

[0008] In some embodiments, obtaining the data contract based on the judgment enumeration value and the evidence sample set includes: The sample characteristics of the evidence sample set are determined, and the sample characteristics are hashed with the judgment enumeration value to obtain a consistent watermark; The data contract is obtained by structuring and assembling the judgment enumeration value, the evidence sample set, and the consistency watermark.

[0009] In some embodiments, adding the data contract to the system prompts of the large language model to generate evaluation results using the large language model includes: The data contract is added as context to the system prompt word, and the system prompt word is updated based on multi-dimensional constraint instructions, including a conclusion locking instruction for locking the decision enumeration value, an algorithm masking instruction for restricting specific algorithm terms, and a data closure instruction for limiting the data source referenced by the large language model. The evaluation result is generated using the large language model based on a preset structural description pattern. The evaluation result includes a conclusion field corresponding to the decision enumeration value, a watermark write-back field for rewriting the consistency watermark, and an explanatory text containing an evidence pointer index.

[0010] In some embodiments, the consistency check of the evaluation results based on the data contract to obtain the check results includes: The conclusion field and the watermark write-back field are determined based on the evaluation results; The conclusion field is compared with the judgment enumeration value in the data contract to obtain a first comparison result, and the watermark write-back field is compared with the consistency watermark in the data contract to obtain a second comparison result. When both the first and second comparison results indicate that the comparisons are consistent, the test result indicating that the basic test has passed is generated.

[0011] In some embodiments, the step of performing a consistency check on the evaluation results based on the data contract to obtain the check results further includes: Determine the business numerical values ​​contained in the explanatory text, and match the business numerical values ​​with the original numerical values ​​in the evidence sample set or the target cost numerical values ​​within a preset tolerance range to obtain the range tolerance comparison results; Determine the evidence pointer index contained in the explanatory text, and match the evidence pointer index with the legal quantity range of the evidence sample set to obtain the range comparison result; When both the range tolerance comparison result and the interval comparison result indicate that all the business numerical ranges match, the test result indicating that the depth test has passed is generated.

[0012] In some embodiments, the method further includes: When the test result indicates that the consistency test between the evaluation result and the data contract has failed, the reason for the failure is determined and the reason for the failure is added to the system prompt word; The large language model is called a second time based on the low temperature parameter to generate a second evaluation result, and the consistency check is performed again to obtain an updated check result. If the updated test result still indicates that the test is not passed, the natural language generated text of the updated test result is deleted, and the objective data in the data contract is output.

[0013] In some embodiments, the method further includes: When the evidence sample set is not found in the database, obtain the metadata dictionary of the table fields corresponding to the database and the intent description information of the cost analysis request; The table field metadata dictionary and the intent description information are added to the system prompt words, and reference estimation data is generated using the large language model; The reference estimation data is output as a backup evaluation result.

[0014] To achieve the above objectives, a second aspect of this application provides an engineering cost data evaluation apparatus, the apparatus comprising: The acquisition module is used to acquire cost analysis requests and determine structured business parameters and target cost values ​​based on the cost analysis requests; The contract generation module is used to perform statistical queries in the database based on the structured business parameters to obtain the judgment enumeration value and evidence sample set corresponding to the target cost value, and to obtain the data contract based on the judgment enumeration value and the evidence sample set. The model generation module is used to add the data contract to the system prompts of the large language model in order to generate evaluation results using the large language model; The consistency verification module is used to perform consistency verification on the evaluation results based on the data contract, and obtain the verification results. The result output module is used to obtain the cost data evaluation result based on the test result when the test result indicates that the consistency test between the evaluation result and the data contract has passed.

[0015] To achieve the above objectives, a third aspect of this application provides an electronic device, which includes a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the engineering cost data evaluation method as described in the first aspect.

[0016] To achieve the above objectives, a fourth aspect of the present application provides a storage medium, which is a computer-readable storage medium storing a computer program that, when executed by a processor, implements the engineering cost data evaluation method as described in the first aspect.

[0017] The engineering cost data evaluation method, apparatus, electronic device, and storage medium proposed in this application include: First, obtaining a cost analysis request, and determining structured business parameters and target cost values ​​based on the cost analysis request; then, performing a statistical query in the database based on the structured business parameters to obtain the judgment enumeration value and evidence sample set corresponding to the target cost value, and obtaining a data contract based on the judgment enumeration value and evidence sample set; next, adding the data contract to the system prompt words of the large language model to generate evaluation results using the large language model; next, performing a consistency check on the evaluation results based on the data contract to obtain the check result; finally, when the check result indicates that the consistency check between the evaluation result and the data contract passes, obtaining the cost data evaluation result based on the check result. This application embodiment obtains structured business parameters from the cost analysis request and performs statistical queries in the database to obtain judgment enumeration values ​​and evidence sample sets that cannot be modified by the large model. This ensures that the core judgment conclusions are objective and controllable at the architecture level. Furthermore, the data contract containing the judgment enumeration values ​​and evidence sample sets is added as a context constraint to the system prompts of the large language model. After the large language model generates the evaluation results, the data contract is used to perform a retrospective consistency check on the evaluation results. This ensures the consistency between the final cost data evaluation results and objective historical data from both the system architecture and closed-loop verification mechanisms. This makes the output analysis report not only fluent and readable in natural language, but also tamper-proof and traceable in engineering, effectively improving the credibility and auditability of conclusions in professional cost evaluation scenarios.

[0018] Other features and advantages of this application will be set forth in the description which follows, and will be apparent in part from the description, or may be learned by practicing the application. The objectives and other advantages of this application may be realized and obtained by means of the structures particularly pointed out in the description, claims and drawings. Attached Figure Description

[0019] Figure 1 This is a flowchart of an engineering cost data evaluation method provided in an embodiment of this application.

[0020] Figure 2 yes Figure 1 The flowchart for step 102.

[0021] Figure 3 yes Figure 2 The flowchart for step 201.

[0022] Figure 4 yes Figure 1 Another flowchart for step 102.

[0023] Figure 5This is a schematic diagram of the data flow and processing architecture for engineering cost data evaluation, provided in another embodiment of this application.

[0024] Figure 6 yes Figure 1 The flowchart for step 103.

[0025] Figure 7 yes Figure 1 The flowchart for step 104.

[0026] Figure 8 yes Figure 1 Another flowchart for step 104.

[0027] Figure 9 This is a flowchart of an anomaly degradation processing provided in another embodiment of this application.

[0028] Figure 10 This is a schematic diagram of the post-verification and hierarchical processing flow of the large language model output provided in another embodiment of this application.

[0029] Figure 11 This is a flowchart of an alternative processing procedure for a set of evidence-free samples provided in another embodiment of this application.

[0030] Figure 12 This is a schematic diagram of the overall architecture of an engineering cost rationality assessment system provided in another embodiment of this application.

[0031] Figure 13 This is a core flowchart of a three-layer closed-loop architecture provided in another embodiment of this application.

[0032] Figure 14 This is a schematic diagram of the structure of an engineering cost data evaluation device provided in another embodiment of this application.

[0033] Figure 15 This is a schematic diagram of the hardware structure of an electronic device provided in another embodiment of this application. Detailed Implementation

[0034] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0035] It should be noted that although functional modules are divided in the device schematic diagram and the logical order is shown in the flowchart, in some cases, the steps shown or described may be performed in a different order than the module division in the device or the order in the flowchart.

[0036] Unless otherwise defined, all technical and scientific terms used herein have the same meanings as commonly understood by those skilled in the technical field of the present application. The terms used herein are only for the purpose of describing the embodiments of the present application, and are not intended to limit the present application.

[0037] Construction cost analysis is a core business link in the processes of real estate development, infrastructure investment calculation and construction bidding. Business personnel usually need to combine the cost ranges of historical projects of the same type to judge the rationality of the unit construction cost value of the target project. The common core requirement of the above scenarios is to make objective judgments relying on the enterprise's historical cost database, and output readable and traceable analysis reports in the form of natural language. Current cost data query tools usually combine the data retrieval capability of relational databases with the text generation capability of large language models, query the original project data list through the database, and then use the retrieval-augmented generation or tool calling function of the large language model to output opinions on cost rationality.

[0038] However, in the prior art, in judgment scenarios where definite conclusions need to be given, the judgment of the large language model easily relies on the experience in the training data. Even if the retrieval results of the database are transmitted as context, since the large language model can still independently decide how to use the retrieval results or tool results, including ignoring, rewriting or re-inferring, the consistency between the conclusion of the key judgment link and the basic data cannot be guaranteed. This situation easily leads to the inconsistency between the judgment conclusion output by the large language model and the actual retrieval results, or the values cited in the generated explanatory text do not actually exist in the historical project evidence, which further makes the generated cost evaluation results lack clear data support and cannot be traced, and it is difficult to meet the application requirements for conclusion credibility and auditability in professional evaluation scenarios.

[0039] Based on this, the embodiments of the present application perform statistical query in the database by obtaining the structured business parameters in the cost analysis request, to obtain the judgment enumeration values and evidence sample set that cannot be secondarily modified by the large model, so as to ensure that the core judgment conclusion is objectively controllable at the architecture level. Further, the data contract containing the judgment enumeration values and the evidence sample set is added to the system prompt of the large language model as a context constraint. After the large language model is used to generate the evaluation result, a retrospective consistency check is performed on the evaluation result through the data contract, thereby ensuring the consistency between the final construction cost data evaluation result and the objective historical data through the dual mechanisms of system architecture and closed-loop check, so that the output analysis report not only has the fluent readability of natural language, but also realizes immutability and traceability in engineering, and effectively improves the credibility and auditability of conclusions in professional cost evaluation scenarios.

[0040] The construction cost data evaluation method, apparatus, electronic device and storage medium provided by the embodiments of the present application will be further described below.

[0041] Reference Figure 1 This is an optional flowchart of the engineering cost data evaluation method provided in the embodiments of this application. Figure 1 The method may include, but is not limited to, steps 101 to 105. It is also understood that this embodiment... Figure 1 The order of steps 101 to 105 is not specifically limited; the order of steps can be adjusted or certain steps can be added or removed according to actual needs. The engineering cost data evaluation method provided in this application can be applied to any processing system with computing resources (such as servers, smart terminals, computing processors, etc.).

[0042] Step 101: Obtain the cost analysis request, and determine the structured business parameters and target cost value based on the cost analysis request.

[0043] Step 101 will be described in detail below.

[0044] The system implementing the engineering cost data evaluation method of this application includes a client layer, an orchestration layer, a service layer, and a data layer. The client layer mainly consists of a cross-platform client configured to provide a natural language input interface and is responsible for rendering report cards and displaying the traceability of evidence pointers. The orchestration layer deploys an intelligent agent orchestration platform for performing intent recognition on received user requests, routing tools, and managing the context of multi-turn dialogues. The service layer, as the core backend service of the system, is configured to implement a Model Context Protocol (MCP) server, thereby exposing a cost analysis toolset to the orchestration platform. Internally, this service layer specifically consists of… The system comprises multiple sub-modules, including the main service for cost rationality assessment, database decision service, constrained interpretation generation service, output post-verification service, sampling fallback service, and SQL security verification service, which work together to complete specific business logic processing. The data layer includes a relational database and a key-value database, which are responsible for the persistent storage of historical cost data and the high-frequency caching of decision results. Furthermore, the component price database table built in its relational database contains at least key related fields such as project primary key, project year, engineering type, building area, economic indicators, and professional classification, thereby providing a standardized underlying data foundation for the statistical calculation and cost assessment of the upper-level service modules.

[0045] In step 101 of some embodiments, a cost analysis request submitted by a user in natural language is first received. Based on the cost analysis request, the structured business parameters used for subsequent query calculations and the target cost value as the evaluation object are parsed and determined. Specifically, the structured business parameters may include at least one of the following: region, project category, building type, and area parameters; the target cost value is typically the unit cost value of the target project.

[0046] Examples of structured business parameters are shown in the table below.

[0047]

[0048] Step 102: Perform statistical queries in the database based on structured business parameters to obtain the judgment enumeration value and evidence sample set corresponding to the target cost value, and obtain the data contract based on the judgment enumeration value and evidence sample set.

[0049] Step 102 is described in detail below.

[0050] In step 102 of some embodiments, a defined statistical calculation and retrieval logic is then executed within the relational database to ensure the objectivity of the judgment data. Specifically, firstly, based on the cost assessment scenario to which the structured business parameters corresponding to the cost analysis request belong, an adaptive calculation mode is selected to construct the basic query. The calculation mode may include: a direct unit cost mode (DX_DIRECT mode) for filtering projects of similar scale; a professional summary unit cost mode (ZY1_MERGE_SUM mode) for summing the costs of sub-items of the same profession; and an area-weighted unit cost mode (PROJECT_WEIGHTED mode), calculated using a formula such as weighted unit cost = SUM(unit price × area) / SUM(area). Then, a six-stage common table expression (CTE) pipeline is executed within the database to obtain an evidence sample set. A 256-bit (SHA-256) secure hash algorithm consistency watermark is then generated based on the characteristics of the judgment enumeration value and the evidence sample set to obtain the data contract return. The application layer must not disassemble or recalculate the judgment enumeration value after receiving it. In addition, query conditions can be normalized hashed as cache keys to cache data contracts in a key-value database, ensuring consistent decision results for the same query conditions throughout the cache's validity period.

[0051] The following section will further describe how to obtain the judgment enumeration value and the evidence sample set.

[0052] Reference Figure 2 Based on structured business parameters, statistical queries are performed in the database to obtain the judgment enumeration value and evidence sample set corresponding to the target cost value, including the following steps 201 to 203.

[0053] Step 201: Perform a quantile pipeline query in the database based on structured business parameters to obtain the target quantile threshold.

[0054] Steps 201 to 203 are described in detail below.

[0055] In step 201 of some embodiments, after obtaining the cost analysis request, the structured business parameters (e.g., region, project category, building type, area, etc.) used for query filtering and the target cost value to be evaluated are parsed out. Then, based on the structured business parameters, an adaptive calculation mode is selected to construct the basic query. The calculation mode includes at least the following three: the direct unit cost mode based on project size range (DX_DIRECT mode), used to filter projects of similar size; the professional summary unit cost mode (ZY1_MERGE_SUM mode), used to sum the costs of specific professional sub-items; or the area-weighted unit cost mode (PROJECT_WEIGHTED mode), calculated according to a formula such as weighted unit cost = SUM(unit price × area) / SUM(area), thereby achieving adaptive aggregation of different underlying data dimensions.

[0056] The Direct Single-Unit Cost Mode (DX_DIRECT Mode) uses the user-provided building area as a benchmark and filters similar-sized projects within a fluctuating area range. This range is defined as follows: lower bound = user area × 0.70, upper bound = user area × 1.30. A basic query example is shown below.

[0057] SELECT CAST(c_fid AS CHAR) AS `key`, c_nian AS `year`, CAST(NULLIF(TRIM(c_jjzb1), '') AS DECIMAL(18,4)) AS metric FROM gczj_jgk WHERE c_new_type = 'Project_DX' AND c_jljc1 BETWEEN :area_low AND :area_high AND c_jjzb1 IS NOT NULL AND TRIM(c_jjzb1)<>'' Specialized cost summary mode (ZY1_MERGE_SUM mode). This mode sums the costs of all sub-items within the same specialty under the same project. A basic query example is shown below.

[0058] SELECT CAST(c_fid AS CHAR) AS `key`, MAX(c_nian) AS `year`, SUM(CAST(NULLIF(TRIM(c_jjzb1), '') AS DECIMAL(18,4))) AS metric FROM gczj_jgk WHERE c_zy1 = :zy1 GROUP BY c_fid Area-weighted unit cost model (PROJECT_WEIGHTED model). This model calculates the area-weighted average cost of each sub-item within the same project using the formula: Weighted Unit Cost = SUM(Unit Price × Area) / SUM(Area).

[0059] Based on the selected computation mode, this embodiment executes a six-stage CTE (Common Table Expression) pipeline within the database. The six stages are: base sample screening, ordered arrangement, counting (cnt), quantile position calculation (pos), interpolation boundary picking, and linear interpolation calculation (quant). In the linear interpolation calculation stage, the 25th percentile (P25) and 75th percentile (P75) are calculated using a linear interpolation formula of the form pos = (n-1)×Q+1 as decision thresholds, avoiding the uncertainty caused by directly calculating quantiles through LLM, as described below.

[0060] Reference Figure 3 Based on structured business parameters, a quantile pipeline query is performed in the database to obtain the target quantile threshold, including the following steps 301 to 303.

[0061] Step 301: Based on the structured business parameters, perform filtering and sorting processing in the database to obtain an ordered sample set.

[0062] Step 302: Based on the difference between the total number of samples in the ordered sample set and the first value, multiply it by the preset quantile ratio, and add the preset offset constant to obtain the target quantile position corresponding to the preset quantile ratio.

[0063] Step 303: Determine the two boundary sample values ​​adjacent to the target quantile position in the ordered sample set, and use the decimal part of the target quantile position to perform linear interpolation on the two boundary sample values ​​to obtain the target quantile threshold.

[0064] Steps 301 to 303 are described in detail below.

[0065] In this application's scheme, the decision calculation is entirely embedded within a single SQL statement, and the application layer does not participate in the decision logic. The CTE pipeline consists of six subquery stages with strict dependencies, as shown in the table below.

[0066]

[0067] In this six-stage CTE pipeline, linear interpolation is used instead of the nearest-rank method, so that quantile calculation can still provide a continuous and stable decision threshold when the sample size is small; the explicit six-stage construction can run natively on relational databases that do not support the PERCENTILE_CONT function; all decision calculations are completed in a single database round trip.

[0068] Based on this, in step 301 of some embodiments, the target calculation pattern is adaptively matched to construct a basic query based on the obtained structured business parameters. Next, a six-stage CTE (Common Table Expression) pipeline is executed within the relational database. First, the basic sample filtering stage (base) aggregates or filters the underlying historical cost details according to the pattern; then, the ordered arrangement stage (ordered) processes the filtered sample data according to the unit cost value, thereby obtaining the required ordered sample set.

[0069] In step 302 of some embodiments, the total number of ordered samples (n) is obtained based on the counting and statistics stage (cnt) of the ordered sample set. Next, in the quantile position calculation stage (pos), a defined mathematical logic calculation is performed to calculate the difference (n-1) between the total number of ordered samples and a first value (specifically corresponding to a constant 1) as the subtrahend. This difference is then multiplied by a preset quantile ratio (Q, e.g., 0.25 for P25 and 0.75 for P75) (i.e., (n-1)×Q). Finally, a preset offset constant (specifically corresponding to a constant 1) is added to obtain the target quantile position precisely corresponding to the preset quantile ratio (i.e., obtaining the position that satisfies pos = (n-1) / (n-1)). 1) × Q+1 (the position index of the formula).

[0070] In step 303 of some embodiments, based on the calculated target quantile position, two boundary sample values ​​in the ordered sample set that are numerically adjacent to the target quantile position are determined in the interpolation boundary picking stage. Next, the linear interpolation calculation stage (quant) is entered, where a determined linear interpolation calculation principle is applied, and interpolation mathematical calculations are performed on the two boundary sample values ​​using the decimal part of the target quantile position, thereby calculating the final target quantile threshold corresponding to the preset quantile ratio (e.g., calculating the specific unit cost threshold value of P25 or P75).

[0071] Through the above steps 301 to 303, the calculation of the target quantile threshold is completely solidified at the database level. By using the defined multi-stage pipeline as well as the precise linear interpolation calculation steps and formula logic, the exact calculation of the specific percentile cost threshold is completed based on objective historical data, thereby eliminating any possibility of tampering with the core statistical threshold by any application layer or large language model at the architecture level.

[0072] Step 202: Perform numerical comparison between the target cost value and the target quantile threshold, and generate a decision enumeration value representing the cost evaluation level according to the comparison result.

[0073] Step 203: Perform nearest neighbor retrieval in the database based on the target cost value to obtain a preset number of historical sample records, and combine the plurality of historical sample records to obtain an evidence sample set.

[0074] Steps 202 to 203 are described in detail below.

[0075] In step 202 of some embodiments, the target cost value is numerically compared with the calculated target quantile thresholds (P25, P75) to generate a decision enumeration value representing the cost evaluation level. Specifically, if the target cost value is less than P25, the generated decision enumeration value is "low"; if the target cost value is greater than P75, the generated decision enumeration value is "high"; if it is between the two, the generated decision enumeration value is "normal", thereby realizing quantitative decision based on historical objective data.

[0076] In the solution of the present application, the decision logic is executed in the judgement subquery, as shown in the following code example.

[0077] judgement AS ( SELECT CASE WHEN :input_cost<p25 THEN 'low' WHEN :input_cost>p75 THEN 'high' ELSE 'normal' END AS judgement FROM quant ) The decision conclusion is an enumeration-type string constant, which is directly calculated and output by the database, and is used as an untamperable decision certificate.

[0078] In step 203 of some embodiments, while performing CTE pipeline query, the present application scheme performs nearest neighbor evidence retrieval in parallel in the database based on the target cost value, sorts the data in ascending order according to the absolute difference between the target cost value and the sample value, and takes the first K records (K is a preset positive integer, such as 10) as the evidence sample set supporting the judgment conclusion, so as to provide clear data support for the subsequent interpretation of the large model.

[0079] In this application, the nearest neighbor evidence retrieval subquery is executed in parallel within the same SQL statement to filter the K samples with the smallest absolute difference from the user input value from the base set. In this embodiment, K is set to 10, as shown in the code example below.

[0080] evidence AS ( SELECT `key`, `year`, metric FROM base ORDER BY ABS(metric - :input_cost) ASC LIMIT 10 ) After obtaining the judgment enumeration value and the evidence sample set, a SHA-256 consistency watermark is generated based on the features of the judgment enumeration value and the evidence sample set. The judgment enumeration value, the evidence sample set, and the consistency watermark are then encapsulated into a single structured JSON object entity, i.e., a data contract. In subsequent steps, the data contract is injected as an immutable context into the system prompts of the large language model. The system prompts also contain strong constraint instructions such as conclusion locking constraints, algorithm masking constraints, and data closure constraints, leveraging the structured output capabilities of the large language model to drive the generation of an evaluation report.

[0081] Through steps 201 to 203 above, by solidifying the core judgment logic in the cost analysis request at the database level, and through precise quantile CTE pipeline queries and nearest neighbor retrieval, a deterministic judgment and credible evidence chain based on objective historical data are constructed. This deprives the large language model of its autonomy and re-inference rights in key stages at the system architecture level. Furthermore, by adding a data contract containing judgment enumeration values, evidence sample sets, and consistency watermarks as an immutable context to the prompt words, the large model must rewrite the objective judgment conclusion and consistency watermark prefix as is, and the referenced data must be traced back to the evidence sample set. This ensures that the final output evaluation report has both fluent natural language readability and, in engineering terms, immutability and strict auditability.

[0082] The following section will further describe how to obtain the data contract.

[0083] Reference Figure 4The data contract is obtained based on the judgment enumeration value and the evidence sample set, including the following steps 401 to 402.

[0084] Step 401: Determine the sample characteristics of the evidence sample set, and perform hash calculation on the sample characteristics and the judgment enumeration value to obtain the consistency watermark.

[0085] Step 402: The judgment enumeration value, evidence sample set and consistency watermark are structurally assembled to obtain the data contract.

[0086] Steps 401 to 402 are described in detail below.

[0087] In step 401 of some embodiments, sample features of the evidence sample set are extracted using built-in database functions, such as determining the total number of sample records in the array, the minimum value of the cost index, and the maximum value. Further, a hash calculation is performed using a database hash function (such as the SHA-256 algorithm). The input parameters for the calculation include at least the judgment enumeration value text determined in previous steps, and the sample features of the just extracted evidence sample set (such as the total number of records, minimum value, and maximum value). In one possible implementation, the judgment enumeration value and the sample features are concatenated according to a preset rule and used as input to the hash function to calculate a consistent watermark representing the data state.

[0088] In step 402 of some embodiments, a structured assembly operation is performed at the database level using built-in functions provided by the relational database (such as the JSON_OBJECT function). The objectively calculated judgment enumeration value, the queried evidence sample set (in JSON array form), and the consistency watermark are assembled into a single JSON object entity, thus obtaining a data contract containing the objective conclusion, evidence chain, and verification information, which is then returned to the application layer in JSON structure form.

[0089] In this application, the judgment and evidence samples are assembled into a single structured JSON data contract within the database using the JSON_OBJECT function and returned. The binding relationship between the judgment and evidence samples is established at the database layer, and the application layer must not disassemble or recalculate the judgment enumeration value fields after receiving the data, as shown in the code example below.

[0090] SELECT JSON_OBJECT( 'judgement',(SELECT judgment FROM judgment), 'evidence',(SELECT JSON_ARRAYAGG( JSON_OBJECT('key', `key`, 'year', `year`, 'metric', metric) (FROM evidence) 'evidence_n', (SELECT COUNT(*) FROM evidence), 'watermark',SHA2(CONCAT( IFNULL((SELECT judgment FROM judgment), ''), '|', (SELECT COUNT(*) FROM evidence), '|', IFNULL((SELECT MIN(metric) FROM evidence), 0), '|', IFNULL((SELECT MAX(metric) FROM evidence), 0) ), 256) AS result The JSON data contract carries a consistency watermark field. The consistency watermark is generated jointly based on the judgment enumeration value and evidence sample characteristics (quantity, minimum, maximum), calculated using the SHA-256 algorithm, and has an output length of 64 characters. In subsequent steps, the first 16 characters of the consistency watermark are passed as a prompt word context to the large language model, while the full length is used for robust collision-resistant storage of the audit logs. Any tampering with the judgment conclusion or evidence set will compromise the write-back consistency of the watermark.

[0091] Through steps 401 to 402 above, the database-level capabilities are utilized to calculate a consistency watermark based on the statistical characteristics of the objective judgment results and supporting evidence. This watermark is then encapsulated together with the judgment and evidence into a single structured data contract, thereby achieving strong coupling between evidence and conclusion at the data layer. This provides a tamper-proof baseline for subsequent post-conformity verification, effectively enhancing the credibility and auditability of the evaluation results.

[0092] Reference Figure 5 This is a schematic diagram illustrating the data flow and processing architecture logic for engineering cost data evaluation provided in an embodiment of this application. For example... Figure 5 As shown, the processing flow, from left to right, covers the parameter input stage, the database core calculation stage (i.e., the six-stage CTE pipeline), and the output and consistency verification stage, clearly demonstrating the flow mechanism and mapping relationship of various business data at the system's underlying layer.

[0093] During the parameter input phase, the system first acquires the preset instructions and data for cost analysis, specifically including the specified calculation mode (e.g., direct unit cost mode DX, professional summary unit cost mode ZY1, or area-weighted unit cost mode PROJECT), structured business parameters, and user-input cost values. After the input data is imported into the underlying database, it first enters the "base data preparation" module of the pipeline. This module performs targeted filtering and preliminary aggregation of the underlying historical project details based on the selected calculation mode and business parameters, thereby constructing the underlying basic data set for subsequent core calculations.

[0094] Subsequently, the data flow enters the core "six-stage CTE pipeline" from the "base data preparation" module for processing. Specifically, the basic data sequentially passes through the "ordered" stage to achieve ascending order sorting of cost indicators, the "counting and statistics (cnt)" stage to obtain the total sample size, the "quantile position calculation (pos)" stage to determine the theoretical mathematical position of the target quantile, the "position parameter determination (pick)" stage to pick up the boundary values ​​of adjacent samples, and finally, the "linear position value information (quant)" stage uses interpolation logic to calculate the precise target quantile threshold. This pipeline design aims to transform complex statistical calculations into continuous data processing actions that the database can natively execute, avoiding secondary calculations at the application layer.

[0095] During the output and verification phase, the system outputs results in multiple parallel streams based on the aforementioned calculation and preparation stages. On one hand, the threshold output in the "linear warehouse value information (quant)" stage is compared with the user-input cost value and converted into a definite "judgment enumeration value (e.g., too low, normal, or too high)". On the other hand, the system directly extracts and outputs a "set of K evidence samples" supporting the judgment based on the data from the "base data preparation" stage. Finally, the generated judgment enumeration value, the set of K evidence samples, and the corresponding generated consistency verification results are all aggregated into the "consistency verification" stage. Depending on the execution of the verification logic, if data consistency is confirmed, the evaluation result is "output"; if data tampering or verification failure is identified, the relevant execution trajectory and abnormal status are recorded in the "audit log", thereby constructing a complete and highly auditable business closed loop.

[0096] In this application, the system uses the normalized hash of the query conditions as the cache key to cache the complete JSON data contract in a key-value database, with a cache validity period of 20 minutes. The normalized key is constructed as shown in the following code example.

[0097] normalized_key = mode || '|' || sorted_params_kv_pairs || '|' || input_cost_canonical_form cache_key = "cost:judgement:" || SHA-256(normalized_key) Where `sorted_params_kv_pairs` is the concatenation of strings after the business parameters are sorted lexicographically, and `input_cost_canonical_form` is the standardized decimal representation after removing trailing zeros. The caching mechanism ensures that multiple queries under the same query conditions return the same decision result, thus constituting the system's decision idempotency.

[0098] When the number of evidence samples is zero, the system determines that there is insufficient historical data under the current query conditions and jumps to the dual-channel fallback process.

[0099] Step 103: Add the data contract to the system prompts of the large language model to generate evaluation results using the large language model.

[0100] Step 103 will be described in detail below.

[0101] In step 103 of some embodiments, the obtained data contract is injected as an immutable context into the system prompts of the large language model. Utilizing the structured output capabilities of the large language model, the model output is bound to a predefined JSON schema. The system prompts include three types of strong constraint instructions to limit model generation: the first constraint is a conclusion-locking constraint, prohibiting recalculation or modification of the decision enumeration values ​​in the data contract; the second constraint is an algorithm-shielding constraint, prohibiting the introduction of algorithmic terms such as quantiles and interpolation in the explanatory text; and the third constraint is a data closure constraint, prohibiting the introduction of numerical values ​​other than those from the evidence samples. In the generated evaluation results, the conclusion field is limited to an enumeration type, the watermark write-back field requires the original, consistent watermark prefix to be written back, and the model is required to indicate the corresponding evidence sample index in the explanatory text using a preset marking format (e.g., square brackets with a capital letter E followed by an index number).

[0102] The following describes in more detail how the evaluation results are generated.

[0103] Reference Figure 6 Adding data contracts to system prompts in a large language model to generate evaluation results using the large language model includes steps 601 to 602.

[0104] Step 601: Add the data contract as context to the system prompt word, and update the system prompt word based on multi-dimensional constraint instructions. The multi-dimensional constraint instructions include conclusion locking instructions for locking decision enumeration values, algorithm masking instructions for restricting specific algorithm terms, and data closure instructions for limiting the data source referenced by the large language model.

[0105] Step 602: Generate evaluation results using a large language model based on a preset structural description pattern. The evaluation results include a conclusion field corresponding to the decision enumeration value, a watermark write-back field for rewriting the consistency watermark, and an explanatory text containing the evidence pointer index.

[0106] Steps 601 to 602 are described in detail below.

[0107] In step 601 of some embodiments, after obtaining the data contract containing the judgment conclusion and evidence generated by the underlying database, the data contract is injected as immutable contextual information into the system prompt words of the large language model. In this application, in order to eliminate the uncertainty generated by the large language model, multi-dimensional constraint instructions are injected into the system prompt words. In specific implementation, by configuring the conclusion locking instruction, the large model is explicitly restricted from changing the conclusion of the reasonableness of the cost; by configuring the algorithm shielding instruction, the large model is prevented from exposing internal technical implementation details in the text output to business personnel; by configuring the data closure instruction, the possibility of the large model fabricating cost values ​​based on its own corpus is cut off, and its cognitive boundary is strictly confined to the range of real historical data obtained in this query. Among them, the multi-dimensional constraint instruction refers to a set of strong constraint rules explicitly declared in the system prompts, used to limit the free space of the large language model from three dimensions: conclusion, algorithm performance, and data source; the conclusion locking instruction refers to the rule that requires the large language model to strictly output the decision enumeration value calculated by the database, prohibiting it from recalculating, questioning, or using fuzzy expressions to replace the decision based on its own parameter experience; the algorithm shielding instruction refers to the rule that prohibits the large language model from mentioning low-level hardcore algorithm terms such as "quantile" and "interpolation" in the generated explanation text, so as to ensure that the output to end users maintains the readability of business semantics; the data closure instruction refers to the rule that restricts all cost values ​​appearing in the explanation text generated by the large language model to come entirely from evidence samples in the data contract or user input values, prohibiting the introduction of external knowledge, fictitious projects, or industry inferences and estimates.

[0108] In this application, the JSON data contract output by the system serves as the system prompt word for the large language model, with the temperature parameter set to 0.3 and the maximum number of tokens (max tokens) set to 10000 in the calling parameters. The system prompt word explicitly declares three types of strongly constrained instructions, and an example prompt word template is shown below.

[0109] [Objective Results from the Database] - Judgment Conclusion: {judgement} - Consistent watermark: {watermark_short_16} - Number of evidence samples: {evidence_n} - Nearest neighbor evidence sample: {evidence_table} [Strong constraint directive] Constraint 1 (Conclusion Locking Constraint): - The output conclusion field must be exactly equal to "{judgement}", with consistent character levels; - Vague expressions must not be used as substitutes; - The judgment may not be recalculated or challenged.

[0110] Constraint 2 (Algorithm Masking Constraint): - The terms percentile, quartile, quantile, and interpolation must not be mentioned in the explanatory text. Algorithm or implementation terminology; - The output maintains business semantics for end users.

[0111] Constraint 3 (Data Closure Constraint): - All numerical values ​​in the explanatory text must come from the above evidence sample or user input values; - Project numbers, years, and cost figures other than those specified in the evidence sample must not be included; - Industry averages, regional adjustments, future forecasts, and other inferences and estimates are not allowed.

[0112] The three types of constraints respectively restrict the unauthorized space of the large language model in three directions: judgment conclusion, algorithm implementation, and external knowledge.

[0113] In step 602 of some embodiments, after assembling the system prompt words, the large language model is invoked to process the request. To ensure that the output data can be stably parsed by the system program, the output format of the large language model is forcibly bound based on a preset structural description pattern. The large language model generates and returns the evaluation result according to the set pattern specification. The evaluation result includes a conclusion field whose content is limited to a specified enumeration type; a watermark write-back field that is filled in as is according to the rules with a consistency watermark or its prefix string; and a natural language explanatory text. When generating the explanatory text, the model is subject to the dual constraints of the pattern and the prompt words. It must insert an evidence pointer index in a preset format at the reference to specific business data, so that the natural language description and the structured historical objective record can be compared. Among them, the structure description pattern corresponds to the predefined JSON schema, which is used to leverage the structured output capabilities of the large language model software development kit to force its output results to be bound to the specified fields and type specifications; the watermark write-back field refers to a specific field set in the structure description pattern, which requires the large language model to copy the consistency watermark (or its preset length prefix) generated in the previous steps in this field, so that the downstream process can perform anti-tampering verification; the evidence pointer index refers to the preset mark format (such as square brackets with the uppercase letter E and the index number, such as [E1]) that the large language model must use when referencing specific item values ​​in the explanatory text, which is used to establish a corresponding association between the generated text description and the underlying objective evidence sample.

[0114] In this application, this embodiment does not rely on the soft constraints of prompt words to ensure the stability of the output structure. Instead, it uses the structured output capability of the Large Language Model Software Development Kit to bind the output to a predefined JSON pattern, as shown in the following code example.

[0115] { "type": "object", "required": ["conclusion", "explanation", "evidence_table", "watermark_echo"], "properties": { "conclusion":{ "type": "string", "enum": ["lower", "normal", "higher"]}, "explanation":{ "type": "string", "maxLength": 2000}, "evidence_table":{ "type": "array", "minItems": 1, "maxItems": 10, "items": { "type": "object", "required": ["evidence_index", "year", "metric"], "properties": { "evidence_index": { "type": "integer", "minimum": 1, "maximum": 10}, "year":{ "type": "string"}, "metric": { "type": "number"} } } }, "watermark_echo":{ "type": "string", "pattern": "^[a-f0-9]{8,64}$"} } } The conclusion field is limited to an enumeration type, preventing the large language model from generating values ​​outside the enumeration during the toolkit deserialization stage. Each row in the evidence data table must carry an evidence pointer index, serving as a carrier for the strong binding of evidence pointers. The watermark write-back field requires the model to write back the first 16 characters of the consistency watermark exactly as is. Pattern validation triggers rejection at the large language model toolkit layer, preventing the model from freely manipulating the syntactic space.

[0116] Furthermore, all references to specific item values ​​in the explanatory text must be annotated with the corresponding evidence sample index using a preset marking format. This preset marking format consists of square brackets with an uppercase letter E followed by an index number, such as [E1] or [E3]. The front-end can then display the original record details page of the corresponding evidence sample to the user based on this index, enabling end-to-end clickable tracing. An example of explanatory text is as follows: The unit cost of this project, at 8,000 yuan per square meter, is within the historical normal range. The closest reference projects are [E1] (7,950 yuan per square meter) in 2023 and [E2] (8,120 yuan per square meter) in 2022. The highest value in the evidence set appears in [E5] (8,850 yuan per square meter) in 2024.

[0117] Through steps 601 to 602 above, by using objective data contracts as the constraint basis and imposing multi-dimensional strong constraint instructions and structured output restrictions, the large language model is substantially deprived of its autonomous divergence in key business decisions and data references at the architecture system level. This suppresses the data illusion caused by the large language model's reliance on inherent training experience, ensuring that the output evaluation report is not only highly consistent with objective historical details in terms of conclusions, but also achieves reliable transmission of anti-tampering verification features and end-to-end traceability of cost indicators, thereby improving the business credibility and audit security of the intelligent evaluation system in professional fields.

[0118] Step 104: Perform a consistency check on the evaluation results based on the data contract to obtain the check results.

[0119] Step 104 is described in detail below.

[0120] In step 104 of some embodiments, a consistency check is performed independently before the large language model generates the result and returns. The check includes: decision write-back consistency check, which checks whether the conclusion field output by the model is consistent with the decision enumeration value in the data contract at the character level, and whether the watermark write-back field output by the model is consistent with the preset length prefix character level of the consistency watermark; numerical traceability check, which checks whether all cost values ​​in the explanatory text output by the model can be accurately matched in the evidence sample set or the target cost value (the matching adopts a preset relative tolerance, such as 0.5%); and range out-of-bounds check, which checks whether the index value of the preset tag format is within the legal range, as described below.

[0121] Reference Figure 7 The consistency of the evaluation results is checked based on the data contract, and the test results are obtained, including the following steps 701 to 703.

[0122] Step 701: Determine the conclusion field and watermark write-back field based on the evaluation results.

[0123] Step 702: Compare the conclusion field with the decision enumeration value in the data contract to obtain the first comparison result, and compare the watermark write-back field with the consistency watermark in the data contract to obtain the second comparison result.

[0124] Step 703: When both the first and second alignment results indicate that the alignment is consistent, generate an inspection result indicating that the characterization basis test has passed.

[0125] Steps 701 to 703 are described in detail below.

[0126] In step 701 of some embodiments, after the large language model completes the generation of structured content based on the injected data contract context and strong constraint instructions, the independently executed post-verification program first extracts and determines specific key-value data from the structured evaluation results (such as the returned JSON data body) output by the large language model. That is, it extracts the conclusion field representing the final evaluation result of the model and the watermark write-back field representing the model's rewrite verification information, so as to prepare test data for subsequent consistency verification.

[0127] In step 702 of some embodiments, the system performs a decision write-back consistency check between the extracted test data and the underlying objective basis in the data contract. On the one hand, it checks whether the extracted conclusion field and the decision enumeration value, which serves as the objective benchmark, are consistent at the character level, thereby obtaining a first comparison result indicating whether the conclusion has been modified; on the other hand, it checks whether the extracted watermark write-back field is consistent at the character level with a specific part (such as a preset length prefix) of the consistency watermark originally generated in the underlying database and included in the data contract, thereby obtaining a second comparison result indicating whether the verification identifier has been destroyed.

[0128] In step 703 of some embodiments, after obtaining the above two comparison results, a comprehensive judgment is made. Only when the conclusion field does not deviate from the objective judgment enumeration value, and the consistency watermark prefix is ​​accurately copied by the model, that is, when both the first comparison result and the second comparison result represent a complete character-level match, is the judgment write-back consistency verification for the model-generated result confirmed to have passed, and a verification result representing the basic verification to have passed is generated accordingly, so that the system can proceed with the evaluation result to the next stage or use it as compliance data for further in-depth verification such as numerical traceability.

[0129] Through steps 701 to 703 above, by implementing the process from extracting structured results to dual character-level comparison, a machine character-level verification mechanism is established for the core decision conclusions and the consistency watermark prefix. This enables timely and automatic identification of any unauthorized actions by the large language model, such as tampering, recalculation, or obfuscation of the underlying objective decisions, before the evaluation report is returned to the end user. This engineering mechanism ensures that the output analysis conclusions always adhere to rigorous underlying statistical data, enhancing the credibility and tamper-proof capability of the large language model's output in professional cost evaluation scenarios.

[0130] In addition, refer to Figure 8 The evaluation results are tested for consistency based on the data contract to obtain the test results, and the process also includes the following steps 801 to 803.

[0131] Step 801: Determine the business values ​​contained in the explanatory text, and match the business values ​​with the original values ​​or target cost values ​​in the evidence sample set within a preset tolerance range to obtain the range tolerance comparison results.

[0132] Step 802: Determine the evidence pointer index contained in the explanatory text, and match the evidence pointer index with the legal quantity range of the evidence sample set to obtain the range comparison result.

[0133] Step 803: When both the range tolerance comparison result and the interval comparison result indicate that the ranges of all business values ​​are matched, generate a test result indicating that the depth of representation test has passed.

[0134] Steps 801 to 803 are described in detail below.

[0135] In step 801 of some embodiments, the system performs numerical source verification. First, using text parsing techniques such as regular expressions, all business numerical values ​​used as the basis for evaluation are extracted from the explanatory text generated by the large language model. Then, each extracted business numerical value (extracted_number) is compared with the set of legal numerical values ​​in the data contract (legal_number, i.e., the original numerical values ​​in the evidence sample set or the target cost value input by the user) to perform matching using a preset relative tolerance, i.e., verifying whether the mathematical relationship is satisfied: |extracted_number The legal_number| ≤|legal_number| × 0.005 is used to output the range tolerance comparison result, which is used to characterize whether all extracted business values ​​can find the objective data source within the tolerance range.

[0136] In step 802 of some embodiments, the system performs a range out-of-bounds check simultaneously with or after the numerical tracing is performed. Specifically, the system extracts all evidence pointer indices (e.g., [E1]) generated by the large language model from the explanatory text. Simultaneously, it obtains the total number of evidence samples actually recorded in the data contract (evidence_n) to determine the legal quantity range. Then, it checks whether the values ​​of all extracted evidence pointer indices strictly fall within the legal range of [1, evidence_n] to obtain a range comparison result used to characterize whether the citation markers have been fabricated out of bounds.

[0137] In step 803 of some embodiments, the obtained comparison results are comprehensively judged; only when the range tolerance comparison results show that all cost values ​​in the explanation text can be traced back to the underlying objective facts (and meet the preset tolerance), and the interval comparison results show that all cited evidence pointer indices do not exceed the range of the actual number of evidence items provided, is it confirmed that the text generated by the model meets strict logical and factual constraints, and then a test result of passing the characterization depth test is generated. If any condition is not met, the subsequent interception or graded anomaly handling process is triggered.

[0138] Through steps 801 to 803 above, by implementing the in-depth verification steps covering tolerance numerical tracing and index out-of-bounds checks, the large language model is required to ensure that every cost data it cites in the output analysis report has a definite source in the objective historical database, and that the evidence pointers it inserts also point to real and valid historical project entries. This avoids the risk that the large language model may infer or fabricate external values ​​or fictitious project numbers when there is a lack of clear data basis. As a result, the cost assessment report presented to the user is not only highly readable, but also enables end-to-end accurate tracing from text data to original detailed records, fully meeting the stringent business requirements for the credibility and high auditability of conclusions in professional cost assessment scenarios.

[0139] In this application's scheme, before the large language model generation result is returned to the client, a separate output post-validation module performs the following three consistency checks. If any check fails, the output is rejected.

[0140] Verification 1: Decision write-back consistency verification, including two sub-verifications: Sub-verification 1: Check whether the conclusion field output by the model is consistent with the decision enumeration value returned by the database at the character level; Sub-verification 2: Check whether the watermark write-back field output by the model is consistent with the first 16 characters of the consistency watermark returned by the database at the character level.

[0141] Any alteration, recalculation, obfuscation of the judgment conclusion, or tampering with the evidence sample will result in the failure of verification step one.

[0142] Verification 2: Numerical Source Verification. This verifies whether all cost values ​​appearing in the explanation text can be matched against the evidence sample set or the user-input cost values. A 0.5% relative tolerance is used for matching; that is, a match is determined when the following conditions are met, as shown in the formula below.

[0143] |extracted_number legal_number| ≤ |legal_number| × 0.005 Where extracted_number represents the numerical value extracted from the explanatory text using regular expressions, and legal_number represents the element in the set of valid numerical values. To avoid misjudgment of non-cost values ​​such as years and percentages, extraction results with values ​​less than 100 will be skipped in this embodiment.

[0144] Verification 3: Range out-of-bounds verification, including two sub-verifications: Sub-verification 1: Check whether the index values ​​of all preset mark formats (such as [E1]) in the interpretation text are all within the range of [1, evidence_n]; Sub-verification 2: Check whether the evidence pointer index field of each row in the evidence data table is all within the range of [1, evidence_n].

[0145] Step 105: When the test results indicate that the consistency between the evaluation results and the data contract is passed, the cost data evaluation results are obtained based on the test results.

[0146] Step 105 is described in detail below.

[0147] In step 105 of some embodiments, if all consistency checks pass, the evaluation result generated by the model is returned to the client as the final cost data evaluation result for display. If any consistency check fails, a tiered process is triggered: the first level of processing is to call the large language model a second time with lower temperature parameters and inject the reason for the check failure as an additional constraint into the system prompt; the second level of processing is to return a pure data view without model-generated explanation text (only displaying the database decision enumeration values ​​and evidence sample tables); the third level of processing is to record the complete check failure information to the audit log, as described below.

[0148] Reference Figure 9 The engineering cost data evaluation method also includes the following steps 901 to 903.

[0149] Step 901: When the test result characterizes the consistency between the evaluation result and the data contract, the test result characterizes the consistency between the evaluation result and the data contract. The ...

[0150] Step 902: Based on the low temperature parameter, the large language model is called a second time to generate a second evaluation result, and a consistency check is performed again to obtain an updated check result.

[0151] Step 903: If the updated test result still indicates that the test is not passed, delete the natural language generated text of the updated test result and output the objective data in the data contract.

[0152] Steps 901 to 903 are described in detail below.

[0153] In step 901 of some embodiments, when any independent verification performed by the system (such as decision write-back consistency verification, numerical tracing verification, or range out-of-bounds verification) fails, the system intercepts the output and captures the corresponding failure information. Subsequently, the system converts the extracted specific abnormal reasons that caused the verification to fail (e.g., a specific value in the explanatory text cannot be matched in the original evidence sample or user input) into additional constraints in text form, and injects these additional constraints as supplementary error feedback into the system prompts of the large language model. For example, the prompts may include specific instructions such as "The last output failed the numerical tracing verification because a certain value in the explanatory text could not be matched," thereby clearly guiding the model to make targeted corrections.

[0154] In step 902 of some embodiments, after updating the system prompt, the system performs a first-level failure handling operation. The system adjusts the configuration of the model call, using a reduced temperature parameter (e.g., 0.1) to initiate a secondary generation request for the large language model. Under stricter constraints and lower randomness settings, the large language model regenerates a secondary evaluation result containing the conclusion, write-back watermark, and explanatory text. Subsequently, the system performs all predetermined consistency verification procedures again on the secondary evaluation result to obtain an updated verification result used to determine whether the current error correction generation is compliant.

[0155] In step 903 of some embodiments, if the update test result still indicates a consistency conflict or logical deviation in the large model after retrying, the system will trigger a second-level failure handling degradation scheme. At this time, the system determines that there is an uncontrollable risk in the natural language organization process of the large language model under this request, and then directly blocks or strips all natural language interpretation text generated by the model in the secondary evaluation result. Instead, the system returns the basic judgment and evidence records contained in the original data contract directly to the client as a pure data view, and if necessary, transparently marks the user with prompts such as "Natural language interpretation generation is abnormal, only objective data is displayed".

[0156] In addition, complete audit logs will be recorded in the log library. The audit logs will include at least: the user's original problem, the decision enumeration value, the consistency watermark prefix, the verification failure code, the reason for the verification failure, and the complete output of the large language model.

[0157] Through steps 901 to 903 above, by implementing the aforementioned multi-level failure handling and degradation processing, the first level of processing, through error attribution feedback combined with low-temperature parameter invocation, provides the model with a self-correction opportunity under a clear error correction direction, thereby improving the overall service success rate of the system; while the second level of processing decisively discards the large model generation results that produce unreliable explanatory text, retreating to the underlying objective structured data, ensuring that the system can provide users with factual data with a credible baseline under any extreme generation anomaly, preventing false or misaligned cost analysis reports from being leaked, and ensuring the rigor of engineering evaluation business and the continuous availability of system services.

[0158] In one example, a user inputs: "Is it reasonable for a high-rise residential building in region A, with a building area of ​​50,000 square meters and a construction cost of 8,000 yuan per square meter, to be reasonably priced?" First-level output (database JSON data contract): { "judgement": "normal", "evidence": [ {"key": "P2023-001", "year": "2023", "metric": 7950.00}, {"key": "P2022-014", "year": "2022", "metric": 8120.00}, {"key": "P2024-007", "year": "2024", "metric": 7820.00}, {"key": "P2023-022", "year": "2023", "metric": 8285.00}, {"key": "P2024-019", "year": "2024", "metric": 8850.00}, {"key": "P2022-031", "year": "2022", "metric": 7610.00}, {"key": "P2023-045", "year": "2023", "metric": 8475.00}, {"key": "P2021-008", "year": "2021", "metric": 7385.00}, {"key": "P2024-033", "year": "2024", "metric": 8970.00}, {"key": "P2022-050", "year": "2022", "metric": 7245.00} ], "evidence_n": 10, "watermark": "a3f2c891b4d76e02..." } Second layer output (constrained large language model output): { "conclusion": "Normal" "explanation": "The user's inquiry regarding the construction cost of 8,000 yuan per square meter for high-rise residential buildings in Area A is within the normal range for historical projects. The closest comparable projects are 2023 [E1] (7,950 yuan per square meter) and 2022 [E2] (8,120 yuan per square meter). The lowest value in the evidence set occurred in 2022 [E10] (7,245 yuan per square meter), and the highest value occurred in 2024 [E9] (8,970 yuan per square meter). The user's input value falls within the median level of this range. Overall, the construction cost per square meter is reasonable." "evidence_table": [ {"evidence_index": 1, "year": "2023", "metric": 7950.00}, {"evidence_index": 2, "year": "2022", "metric": 8120.00}, {"evidence_index": 9, "year": "2024", "metric": 8970.00}, {"evidence_index": 10, "year": "2022", "metric": 7245.00} ], "watermark_echo": "a3f2c891b4d76e02" } Third-level verification process: Validation C1.1: Conclusion field "Normal" == Decision enumeration value "Normal" passes. Verification C1.2: Watermark writeback "a3f2c891b4d76e02" == Expected prefix pass Verification C2: Values ​​8000, 7950, 8120, 7245, and 8970 all matched successfully. Verification C3: [E1], [E2], [E9], and [E10] all pass within the range [1, 10]. ==> All checks passed, a success response was returned. Example of verification failure: Suppose the large language model fabricated the data "the average price of similar projects in region A in 2020 was 7100 yuan per square meter" in the interpretation text. The numerical source verification will fail because 7100 is not within the valid numerical set {8000, 7950, 8120, 7820, 8285, 8850, 7610, 8475, 7385, 8970, 7245} (no match within a tolerance of 0.5%). The system enters the first-level processing stage, performing a secondary generation with a temperature parameter of 0.1; if this still fails, it enters the second-level processing stage and returns to the pure data view.

[0159] Reference Figure 10 This is a schematic diagram of the post-verification and hierarchical processing flow of the large language model output provided in the embodiments of this application. Figure 10 The diagram illustrates the complete logical path of the system after acquiring the structured output of the large language model, including consistency checks and fallback handling. The input to this process is the structured output generated by the large language model, which specifically includes a conclusion field, explanation text, an evidence table, and a watermark echo field. Before returning the result to the client, the system sequentially or in parallel undergoes three rigorous automated machine verification mechanisms to ensure a strict correspondence between the generated content and the underlying objective data.

[0160] Specifically, the first line of defense is Verification 1, namely "Judgment Write-back Consistency Verification." This verification includes two sub-verification steps: Step C1.1 compares the conclusion field output by the large model with the original judgment enumeration value in the underlying database at the character level; Step C1.2 compares the watermark write-back field with the first 16 characters of the original consistency watermark to identify potential tampering or calculation deviations. Next comes Verification 2, namely "Numerical Source Verification." The system extracts all cost values ​​appearing in the explanatory text and matches them with evidence samples or user input values ​​for verification. This matching process allows for a relative tolerance of 0.5% to accommodate reasonable numerical formatting or minor rounding differences. Finally, there is Verification 3, namely "Range Out-of-Bounds Verification." This verification covers Step C3.1's range verification of the marked indexes (such as [E1], [E3], etc.) in the explanatory text, and Step C3.2's verification of the legal quantity range of the evidence_index field in the evidence data table, ensuring that the evidence pointers referenced by the large model do not exceed the total number of actual evidence samples provided.

[0161] After completing the three checks mentioned above, the system executes a summary judgment logic. When all three checks pass, the system directly returns the evaluation result to the client for display. If any check fails, the system triggers a tiered exception handling mechanism. First, the first level of processing is executed, which involves lowering the temperature parameter of the large language model (e.g., setting the low-temperature parameter to 0.1) for a second generation retry to limit the model's divergence. If the updated check result generated by the retry passes the verification, it is returned to the client; if the retry still fails, the system enters the second level of processing, which involves discarding the natural language generated text with uncontrollable risks and returning a downgraded pure data view containing only objective data. Finally, the relevant exception interception details and the reasons for the verification failure will enter the third level of processing and be recorded in detail in the audit log, thus achieving a complete security closed loop from interception and investigation to downgraded display and data storage in the system engineering.

[0162] In a specific example, the database decision layer is implemented using Java 17 and the Spring Boot 3.4 framework. It employs JdbcTemplate to operate on the relational database and StringRedisTemplate to operate on the key-value database. The core code snippet is shown below.

[0163] @Service public class DatabaseJudgementService { private final JdbcTemplate jdbcTemplate; private final ObjectMapper objectMapper; private final StringRedisTemplate redisTemplate; private final long cacheTtlMinutes = 20L; public JudgmentResult judge(EvaluationMode mode, Map<String, Object> params, BigDecimal inputCost) { / / Step S6, first half: Return if cache is hit (determine idempotency) String cacheKey = buildCacheKey(mode, params, inputCost); String cached = redisTemplate.opsForValue().get(cacheKey); if (cached != null) { return parseJson(cached); } / / Steps S3 to S5: Execute the CTE pipeline; the database directly returns a JSON string. String sql = buildCteSql(mode, params, inputCost); String jsonResult = jdbcTemplate.queryForObject(sql, String.class); JudgmentResult result = parseJson(jsonResult); / / Step S6, second half: Write to cache redisTemplate.opsForValue().set( cacheKey, jsonResult, Duration.ofMinutes(cacheTtlMinutes)); return result; } / ** Normalized cache key: The same parameters will always produce the same key * / private String buildCacheKey(EvaluationMode mode, Map<String, Object> params, BigDecimal inputCost) { Map<String, Object> sorted = new TreeMap<>(params); String normalized = mode.name() + "|" + sorted.entrySet().stream() .map(e ->e.getKey() + "=" + e.getValue()) .collect(Collectors.joining(",")) + "|" + inputCost.stripTrailingZeros().toPlainString(); return "cost:judgment:" + sha256Hex(normalized); } } As shown in the code above, in this specific implementation, the decision service module (e.g., the DatabaseJudgementService class in the code) mainly undertakes the business responsibility of performing cost data statistics and maintaining the idempotency of decisions. Specifically, upon receiving an analysis request containing the evaluation mode, business parameters, and target cost value, the system first constructs a unique cache key using a normalization method. This construction process involves strictly sorting the input business parameters in lexicographical order using an ordered data structure (such as TreeMap), concatenating them with the evaluation mode name and the target cost value after removing trailing zeros, and then using a specific hash algorithm (such as SHA-256) to generate a consistent cache key identifier corresponding to the query condition. The system uses this identifier to perform cache hit checks in a key-value database (such as Redis). If a hit is found, the system directly parses the cached JSON string and returns the corresponding evaluation result, thereby ensuring the idempotency of decisions for multiple requests for the same query condition within a preset effective cache period (such as 20 minutes) from the program architecture level.

[0164] If the cache is not hit, the system drives the underlying relational database to execute the aforementioned multi-stage common table expression (CTE) pipeline query. After completing complex statistical and decision calculations, the underlying database directly returns the assembled data contract as a JSON string. Upon receiving this structured JSON string, the decision service module deserializes it into a specific decision result object for subsequent business layer use, and simultaneously writes the original JSON string and its corresponding normalized cache key into the key-value database for expiration. This code implementation not only rigorously decentralizes the core decision calculation logic to the database for direct execution, preventing unauthorized intervention of core data by the application layer, but also effectively reduces the overhead of repeated queries to the underlying database through a standardized and rigorous cache key construction mechanism, improving system response efficiency and the stability of decision results.

[0165] In addition, refer to Figure 11 The method for evaluating engineering cost data also includes the following steps 1101 to 1103.

[0166] Step 1101: When no evidence sample set is found in the database, obtain the corresponding table field metadata dictionary and the intent description information of the cost analysis request.

[0167] Step 1102: Add the table field metadata dictionary and intent description information to the system prompt words, and use the large language model to generate reference estimation data.

[0168] Step 1103: Output the reference estimation data as a backup evaluation result.

[0169] Steps 1101 to 1103 are described in detail below.

[0170] In step 1101 of some embodiments, when the system executes the underlying quantile pipeline query or nearest neighbor retrieval, if it finds that the number of evidence samples meeting the query conditions is zero (or the general cost query returns an empty result), it determines that there is insufficient historical data under the current query conditions. To avoid directly returning a "no data" system error or blank prompt to the user, the system triggers a fallback service process. At this time, the system no longer relies on specific historical cost details, but extracts the table field metadata dictionary of the corresponding business table in the underlying relational database, and also extracts the description information representing the user's original query intent. In addition, the original SQL statement that did not match the data is also obtained.

[0171] In step 1102 of some embodiments, after obtaining the above-mentioned metadata and intent information, the system jointly constructs them into a system prompt word in a specific format and injects it into the context of the large language model. The prompt word is intended to drive the large language model to switch roles, so that it can make reasonable inferences based on the standardized table field dictionary (such as field type, scope, etc.) in the prompt word and the user's business intent, using its built-in industry experience. According to the above instructions, the large language model generates a set of reference estimation data (e.g., output in JSON array format) that is completely consistent with the real database query results in terms of data structure and field names.

[0172] In step 1103 of some embodiments, after the large language model generates reference estimation data, the system performs robust parsing and normalization on it in multiple formats, converting it into a key-value mapping list format consistent with the normal response. Subsequently, the system encapsulates the reference estimation data as a backup evaluation result and outputs it to the client. It should be noted that, to ensure data compliance and the user's right to know, when outputting this backup evaluation result, the system will clearly indicate in the final response that the data source is artificial intelligence sampling (e.g., marked as "ai_sampling"), and on the client interface, it will visually highlight that the report data is generated by artificial intelligence and is not the result of an actual database query with a prominent warning style (e.g., title-level font size, prominent border, etc.).

[0173] In one example, a backup data service process is provided when a database query returns no results.

[0174] Triggering conditions: The number of evidence samples is zero, or the general cost query returns an empty result.

[0175] Default Status: The dual-channel backup service is disabled by default and must be enabled manually by the system administrator. This default configuration is designed to prevent artificial intelligence-generated, non-realistic data from being misused in professional investment decisions.

[0176] Sampling prompt word construction: When the fallback is enabled, the system will construct the system prompt word by combining the database table field metadata dictionary, the SQL statement that was not matched, the query parameters, and the user intent. The field metadata dictionary includes at least four types of information: field name, field type, field definition description, and field example value: [Data retrieval logic]: {User intent description}, [Data field details]: {Field metadata dictionary (presented in tabular form)}, [SQL that was not matched]: {Original SQL statement}. Please provide reasonable estimated data results based on industry experience and business logic. Output format: JSON array, for example, [{"field1": "value1", ...}].

[0177] The data returned by the large language model is processed by the robust parsing module, which supports automatic recognition and normalization of the following output formats: pure JSON arrays, JSON wrapped in Markdown code blocks, single objects, and mixed outputs with prefixes. All data is uniformly converted to a key-value mapping list format, consistent with the format of real database query results.

[0178] Furthermore, the system annotates the data nature in the final response using the data source field: when the data comes from a real database query, the annotation value is "database", and the bottom of the report indicates "The data in this report comes from the actual database query results"; when the data comes from artificial intelligence sampling, the annotation value is "ai_sampling", and the report header displays a visually prominent warning style stating "The data in this report is generated based on artificial intelligence, not the actual database query results, and is for reference only and should not be used as the basis for investment decisions." A visually prominent warning style must at least meet the following conditions: title-level font size; orange or red border; not hidden; and not scrollable out of the visible area.

[0179] Through steps 1101 to 1103 above, the implementation of fallback data services resolves the issue of existing systems crashing or returning invalid prompts when matching historical projects are lacking. In scenarios with missing data, industry experience from large language models is used to generate standardized reference estimation data, ensuring the continuous availability and business continuity of the evaluation system service. Simultaneously, through transparent data source labeling and visual warning mechanisms, objective historical data and AI estimation data are clearly distinguished, effectively preventing AI-generated reference data from being misused in rigorous professional investment decisions. This enhances system robustness while fully protecting users' right to know and the credibility boundaries of conclusions.

[0180] Through steps 101 to 105 above, by embedding the calculation of the reasonableness judgment of the project cost into the CTE pipeline at the database layer, the large language model is deprived of its autonomous right to amend the judgment in the judgment stage. By using a data contract containing the judgment conclusion, evidence samples, and consistency watermark as a strong constraint context for the large language model, and in conjunction with a consistency post-verification mechanism before output, the risk of inconsistency between the results generated by the large language model and the basic historical data is eliminated from the architectural level. This ensures that the final evaluation report has auditability, with conclusions that cannot be tampered with, interpretations that cannot exceed authority, and cited data that cannot be fabricated.

[0181] In another example, the SQL security control flow for a general cost query scenario is shown below.

[0182] The first layer of control: syntax whitelist verification. The system calls the SQL security verification service and uses an SQL syntax parser (such as JSQLParser) to perform syntax analysis on the SQL statement to be executed, verifying each item: whether the statement type is only a SELECT statement, prohibiting data modification statements such as DROP, DELETE, UPDATE, INSERT, TRUNCATE, ALTER, etc.; whether the statement contains UNION injection characteristics; and whether the table names involved in the statement are within the preset whitelist.

[0183] Second layer of control: Row count limit injection. It checks if the SQL statement contains a LIMIT clause. If not, it automatically appends a "LIMIT 100" clause, limiting the number of records returned in a single query to no more than 100 rows.

[0184] Security anomaly handling: When security controls fail, the system will record the complete attack log (including the original SQL statement and source IP) to a separate security log channel, but will only return a general message to the caller that "the query request was rejected by the security policy" without exposing the internal error details.

[0185] Path isolation principle: When the syntax whitelist verification fails, the SQL statement should not be used as input to the fallback service in Implementation Example 3. This path isolation prevents attackers from indirectly triggering the return of fallback data by constructing abnormal SQL statements. The fallback service path can only be entered when the SQL passes security controls but fails to execute (e.g., query timeout, connection exception).

[0186] In addition, in this application's scheme, before obtaining the cost analysis request, the system checks whether historical analysis report data exists in the request context. If it does, the system proceeds to a follow-up inquiry and detection process.

[0187] Follow-up binary classification: The system calls the large language model with a low temperature parameter (value 0.2), takes the historical report summary and the current user question as input, and asks the model to output a binary classification result. The output format is: { "code": 1, "reason":"The user cited data features from the previous report"}, where a value of 1 in the code field indicates that the current question is a follow-up question, and a value of 0 indicates that the current question is a new query.

[0188] Report reuse and new query routing: When code is 1, the system directly generates a response based on the content of historical reports, and reuses the consistency watermark and evidence pointer anchor of historical reports in the response. When code is 0, the system executes the complete three-layer closed-loop process as described above.

[0189] Reference Figure 12 This is a schematic diagram of the overall architecture of an engineering cost rationality assessment system provided in an embodiment of this application. For example... Figure 12As shown, the system is divided into four main logical layers in its overall architecture, from top to bottom: client layer, orchestration layer, service layer, and data layer.

[0190] Specifically, the client layer at the top of the architecture is configured with a cross-platform client, primarily responsible for receiving user natural language input, rendering report cards after backend processing, and providing users with interactive functionality for tracing evidence pointers. The client layer connects downwards to the orchestration layer, which deploys an intelligent agent orchestration platform configured to recognize the intent of user input requests and perform context management and tool routing operations. This orchestration platform communicates with the lower service layer based on the Model Context Protocol (MCP), accurately routing the parsed user requests to the corresponding backend analysis toolsets.

[0191] The service layer is the core business execution carrier of the system, internally deploying the MCP server and the main service for cost rationality assessment. Around this main service, the system constructs several collaborative microservice modules, specifically including: a database decision service that interfaces with the underlying database; a constrained interpretation generation service that drives the operation of the large model; an output post-verification service that performs consistency checks; a sampling fallback service to handle scenarios without data; and an SQL security verification service that intercepts abnormal queries. As shown in the data flow diagram, after generating the initial interpretation text, the constrained interpretation generation service directly transfers its data to the output post-verification service, forming an internal closed-loop interception mechanism between interpretation generation and machine verification.

[0192] At the bottom of the architecture, the data layer contains relational databases and key-value databases. The database decision service in the service layer interfaces downward with the data layer. On the one hand, it performs pipelined statistical decision calculations using Common Table Expressions (CTEs) based on historical cost data in the relational database. On the other hand, the database decision service maintains cached communication with the key-value database, storing the generated decision results and related data in the key-value database to achieve caching of decision results for the same query conditions, thereby ensuring the idempotency of the system's decisions under given query conditions.

[0193] Reference Figure 13 This is a core flowchart of a three-layer closed-loop architecture provided in an embodiment of this application. Figure 13 As shown, the architecture is divided into three core processing layers from top to bottom: the first layer is the database statistics and decision layer, the second layer is the constrained interpretation and generation layer, and the third layer is the output post-validation layer. First, in the business request phase, the system receives the user request, parses it to extract structured business parameters, and then inputs the parameters into the first layer for underlying hard calculations.

[0194] In the first layer, the database statistical decision layer, the system first automatically selects the appropriate calculation mode based on the parsed structured business parameters. Then, a six-stage CTE pipeline query is executed within the database, and objective decision enumeration values ​​are generated based on the interpolation results. Simultaneously, the system uses the user-input cost as a benchmark and performs nearest-neighbor evidence retrieval in parallel to obtain relevant historical project records as objective evidence. Next, the system merges the generated decision enumeration values ​​with the retrieved evidence samples, assembling them into a structured JSON data contract, and simultaneously generates a SHA-256 watermark to give the contract tamper-proof properties. Finally, the watermarked JSON data contract is cached in a key-value database to ensure the idempotency of decisions under the same conditions.

[0195] The JSON data contract output from the first layer then serves as an immutable context for cross-layer transmission, flowing to the second layer, the constrained interpretation generation layer. In this layer, the system first constructs system prompts and injects the received JSON data contract into them completely. During prompt construction, the system simultaneously issues three types of strong constraint instructions to the large language model, strictly limiting the model's generation permissions from three dimensions: conclusion locking, algorithm shielding, and data encapsulation. Finally, leveraging the structured output capabilities of the large language model, the model-generated explanatory text and write-back data are forcibly bound to a predefined JSON Schema format, thereby generating an LLM (Large Language Model) output containing business analysis content.

[0196] The structured LLM output generated by the second layer is further passed down to the third layer, the output post-validation layer. This layer aims to perform intercept-based review of the generated results of the large language model. At this stage, the system performs three key consistency checks sequentially or in parallel: decision write-back consistency check, numerical source tracing check, and range out-of-bounds check. Based on the comprehensive judgment result of these three checks, the system performs distribution routing: when all checks pass, it indicates that the generated results of the large model are highly consistent with the underlying objective facts, and the system immediately returns the evaluation result to the client normally; when any check fails, the system triggers an exception interception response, entering the red hierarchical processing branch to execute fallback strategies such as lowering the temperature for retrying or downgrading to return to a pure data view, thereby ensuring the accuracy and audit compliance of the final output data.

[0197] This application also provides an engineering cost data evaluation device, which can implement the above-mentioned engineering cost data evaluation method, with reference to... Figure 14 The device 1400 includes: The acquisition module 1410 is used to acquire cost analysis requests and determine structured business parameters and target cost values ​​based on the cost analysis requests; The contract generation module 1420 is used to perform statistical queries in the database based on structured business parameters to obtain the judgment enumeration value and evidence sample set of the corresponding target cost value, and to obtain the data contract based on the judgment enumeration value and evidence sample set. The model generation module 1430 is used to add data contracts to the system prompts of the large language model in order to generate evaluation results using the large language model; The consistency verification module 1440 is used to perform consistency verification on the evaluation results based on the data contract and obtain the verification results. The result output module 1450 is used to obtain the cost data evaluation result based on the test result when the test result characterizes the consistency test between the evaluation result and the data contract.

[0198] In the above embodiments, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, the specific implementation of the engineering cost data evaluation device is basically the same as the specific implementation of the above engineering cost data evaluation method, and will not be repeated here.

[0199] This application also provides an electronic device, including: At least one memory; At least one processor; At least one program; The program is stored in a memory, and the processor executes the at least one program to implement the engineering cost data evaluation method described above. The electronic device can be any smart terminal, including mobile phones, tablets, personal digital assistants (PDAs), and in-vehicle computers.

[0200] Please see Figure 15 , Figure 15 The hardware structure of an electronic device according to another embodiment is illustrated. The electronic device includes: The processor 1501 can be implemented using a general-purpose CPU (Central Processing Unit), microprocessor, application-specific integrated circuit (ASIC), or one or more integrated circuits, and is used to execute relevant programs to implement the technical solutions provided in the embodiments of this application. The memory 1502 can be implemented in the form of ROM (Read Only Memory), static storage device, dynamic storage device, or RAM (Random Access Memory). The memory 1502 can store the operating system and other applications. When the technical solutions provided in the embodiments of this specification are implemented through software or firmware, the relevant program code is stored in the memory 1502 and is called and executed by the processor 1501 using the engineering cost data evaluation method of the embodiments of this application. The input / output interface 1503 is used to implement information input and output; The communication interface 1504 is used to enable communication and interaction between this device and other devices. Communication can be achieved through wired means (such as USB, Ethernet cable, etc.) or wireless means (such as mobile network, WIFI, Bluetooth, etc.). Bus 1505 transmits information between various components of the device (e.g., processor 1501, memory 1502, input / output interface 1503, and communication interface 1504); The processor 1501, memory 1502, input / output interface 1503 and communication interface 1504 are connected to each other within the device via bus 1505.

[0201] This application embodiment also provides a storage medium, which is a computer-readable storage medium, storing a computer program that, when executed by a processor, implements the above-described engineering cost data evaluation method.

[0202] Memory, as a non-transitory computer-readable storage medium, can be used to store non-transitory software programs and non-transitory computer-executable programs. Furthermore, memory may include high-speed random access memory, and may also include non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some embodiments, memory may optionally include memory remotely located relative to the processor, and these remote memories can be connected to the processor via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0203] The embodiments described in this application are for the purpose of more clearly illustrating the technical solutions of the embodiments of this application, and do not constitute a limitation on the technical solutions provided by the embodiments of this application. As those skilled in the art will know, with the evolution of technology and the emergence of new application scenarios, the technical solutions provided by the embodiments of this application are also applicable to similar technical problems.

[0204] Those skilled in the art will understand that the technical solutions shown in the figures do not constitute a limitation on the embodiments of this application, and may include more or fewer steps than shown, or combine certain steps, or different steps.

[0205] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs.

[0206] Those skilled in the art will understand that all or some of the steps in the methods disclosed above, as well as the functional modules / units in the systems and devices, can be implemented as software, firmware, hardware, or suitable combinations thereof.

[0207] The terms “first,” “second,” “third,” “fourth,” etc. (if present) in the specification and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms “comprising” and “having,” and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0208] It should be understood that in this application, "at least one (item)" means one or more, and "more than" means two or more. "And / or" is used to describe the relationship between related objects, indicating that three relationships can exist. For example, "A and / or B" can represent three cases: only A exists, only B exists, and both A and B exist simultaneously, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. "At least one (item) of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one (item) of a, b, or c can represent: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", where a, b, and c can be single or multiple.

[0209] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of the units described above is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. The coupling or direct coupling or communication connection between the shown or discussed units may be through some interfaces, or indirect coupling or communication connection between the apparatus or units, and may be electrical, mechanical, or other forms.

[0210] The units described above as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0211] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0212] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes multiple instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing programs, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0213] The preferred embodiments of the present application have been described above with reference to the accompanying drawings, but this does not limit the scope of the claims of the present application. Any modifications, equivalent substitutions, and improvements made by those skilled in the art without departing from the scope and substance of the embodiments of the present application shall be within the scope of the claims of the present application.

Claims

1. A method for evaluating engineering cost data, characterized in that, The method includes: Obtain a cost analysis request, and determine structured business parameters and target cost values ​​based on the cost analysis request; Based on the structured business parameters, a statistical query is performed in the database to obtain the judgment enumeration value and evidence sample set corresponding to the target cost value, and a data contract is obtained based on the judgment enumeration value and the evidence sample set. The data contract is added to the system prompts of the large language model to generate evaluation results using the large language model; Based on the data contract, a consistency check is performed on the evaluation results to obtain the check results. When the test result indicates that the consistency between the evaluation result and the data contract has passed the test, the cost data evaluation result is obtained based on the test result.

2. The method for evaluating engineering cost data according to claim 1, characterized in that, The step of performing statistical queries in the database based on the structured business parameters to obtain the judgment enumeration value and evidence sample set corresponding to the target cost value includes: Based on the structured business parameters, a quantile pipeline query is performed in the database to obtain the target quantile threshold; The target cost value is compared with the target quantile threshold, and the judgment enumeration value representing the cost evaluation level is generated based on the comparison result. In the database, a nearest neighbor search is performed based on the target cost value to obtain a preset number of historical sample records. Multiple historical sample records are combined to obtain the evidence sample set.

3. The method for evaluating engineering cost data according to claim 2, characterized in that, The step of performing a quantile pipeline query in the database based on the structured business parameters to obtain the target quantile threshold includes: Based on the structured business parameters, the database is filtered and sorted to obtain an ordered sample set; The target quantile position corresponding to the preset quantile ratio is obtained by multiplying the difference between the total number of samples in the ordered sample set and the first value, and adding the preset offset constant. The two boundary sample values ​​adjacent to the target quantile position in the ordered sample set are determined, and the two boundary sample values ​​are linearly interpolated using the fractional part of the target quantile position to obtain the target quantile threshold.

4. The method for evaluating engineering cost data according to claim 1, characterized in that, The process of obtaining the data contract based on the judgment enumeration value and the evidence sample set includes: The sample characteristics of the evidence sample set are determined, and the sample characteristics are hashed with the judgment enumeration value to obtain a consistent watermark; The data contract is obtained by structuring and assembling the judgment enumeration value, the evidence sample set, and the consistency watermark.

5. The method for evaluating engineering cost data according to claim 1, characterized in that, The step of adding the data contract to the system prompts of the large language model to generate evaluation results using the large language model includes: The data contract is added as context to the system prompt word, and the system prompt word is updated based on multi-dimensional constraint instructions, including a conclusion locking instruction for locking the decision enumeration value, an algorithm masking instruction for restricting specific algorithm terms, and a data closure instruction for limiting the data source referenced by the large language model. The evaluation result is generated using the large language model based on a preset structural description pattern. The evaluation result includes a conclusion field corresponding to the decision enumeration value, a watermark write-back field for rewriting the consistency watermark, and an explanatory text containing an evidence pointer index.

6. The method for evaluating engineering cost data according to claim 1, characterized in that, The consistency check of the evaluation results based on the data contract, to obtain the check results, includes: Based on the evaluation results, determine the conclusion field and the watermark write-back field; The conclusion field is compared with the judgment enumeration value in the data contract to obtain a first comparison result, and the watermark write-back field is compared with the consistency watermark in the data contract to obtain a second comparison result. When both the first and second comparison results indicate that the comparisons are consistent, the test result indicating that the basic test has passed is generated.

7. The method for evaluating engineering cost data according to claim 6, characterized in that, The step of performing a consistency check on the evaluation results based on the data contract to obtain the check results further includes: Determine the business numerical values ​​contained in the explanatory text, and match the business numerical values ​​with the original numerical values ​​in the evidence sample set or the target cost numerical values ​​within a preset tolerance range to obtain the range tolerance comparison results; Determine the evidence pointer index contained in the explanatory text, and match the evidence pointer index with the legal quantity range of the evidence sample set to obtain the range comparison result; When both the range tolerance comparison result and the interval comparison result indicate that all the business numerical ranges match, the test result indicating that the depth test has passed is generated.

8. The method for evaluating engineering cost data according to claim 1, characterized in that, The method further includes: When the test result indicates that the consistency test between the evaluation result and the data contract has failed, the reason for the failure is determined and the reason for the failure is added to the system prompt word; The large language model is called a second time based on the low temperature parameter to generate a second evaluation result, and the consistency check is performed again to obtain an updated check result. If the updated test result still indicates that the test is not passed, the natural language generated text of the updated test result is deleted, and the objective data in the data contract is output.

9. The method for evaluating engineering cost data according to claim 1, characterized in that, The method further includes: When the evidence sample set is not found in the database, obtain the metadata dictionary of the table fields corresponding to the database and the intent description information of the cost analysis request; The table field metadata dictionary and the intent description information are added to the system prompt words, and reference estimation data is generated using the large language model; The reference estimation data is output as a backup evaluation result.

10. A device for evaluating engineering cost data, characterized in that, The device includes: The acquisition module is used to acquire cost analysis requests and determine structured business parameters and target cost values ​​based on the cost analysis requests; The contract generation module is used to perform statistical queries in the database based on the structured business parameters to obtain the judgment enumeration value and evidence sample set corresponding to the target cost value, and to obtain the data contract based on the judgment enumeration value and the evidence sample set. The model generation module is used to add the data contract to the system prompts of the large language model in order to generate evaluation results using the large language model; The consistency verification module is used to perform consistency verification on the evaluation results based on the data contract, and obtain the verification results. The result output module is used to obtain the cost data evaluation result based on the test result when the test result indicates that the consistency test between the evaluation result and the data contract has passed.

11. An electronic device, characterized in that, The system includes a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the engineering cost data evaluation method according to any one of claims 1 to 9.

12. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the engineering cost data evaluation method according to any one of claims 1 to 9.

Images