Intelligent evaluation method and device for enterprise bidding

Abstract

The application provides an intelligent evaluation method and device for enterprise bidding, and relates to the technical field of blockchains. The method comprises the following steps: an evaluation rule mapping engine automatically deduces adaptive evaluation clauses, and binds identification information to each evaluation clause; the evaluation clauses are written into an evaluation rule snapshot on a chain generated by a blockchain; irreversible target hash fingerprints are generated for objective data in response data uploaded by a system account and uploaded to the blockchain, and subjective data in the response data is encrypted to generate encrypted data; each target hash fingerprint is judged and processed according to the evaluation rule snapshot to generate a first evaluation result; the encrypted data is decrypted, and expert scoring behavior is bound to the evaluation result and signed to obtain a second evaluation result; the first evaluation result and the second evaluation result are combined to generate an evaluation report, the platform online electronic signature is affixed, and the evaluation report is written into the blockchain. The application can improve the confidence of bidding evaluation results.

Description

Technical Field

[0001] This application relates to the technical field of blockchain, specifically to an intelligent review method and device for enterprise bidding. Background Technology

[0002] The evaluation of enterprise bidding is a systematic and multi-dimensional comprehensive judgment process. Usually, the bidding party will form an evaluation committee with professional background and evaluation qualifications. After the bid deadline, the committee will conduct a formal review, qualification review, technical review and commercial review of all compliant bid documents. The committee will score or rank the bidders based on key factors such as their qualifications, performance capabilities, the advancement and feasibility of their technical solutions, and the reasonableness and competitiveness of their quotations. The comprehensive score will be calculated based on the weighting of the scores to select the best candidates or directly determine the winning bidder. The entire process must ensure openness, transparency, fairness and impartiality, and comply with the evaluation standards and procedures stipulated in the relevant laws and regulations and the bidding documents.

[0003] In the bidding and tendering process, the review data often relies on manual input or localized system storage, and lacks a verifiable full-process recording mechanism, making the review process susceptible to tampering. This includes, but is not limited to, modifying scoring results, replacing review opinions, or artificially adjusting the sorting order, which reduces the confidence of the final review results and makes it difficult to trace the responsible party.

[0004] To address this, existing technologies introduce computers for automated intelligent review, reducing human intervention and thus improving the credibility of the review process. However, the lack of effective information consistency verification and encryption protection between nodes in this process allows internal interference and external attacks to bypass access control or log auditing mechanisms, tampering with review content. This still results in opacity and unfairness in bidding results, seriously affecting the credibility of the review mechanism. Summary of the Invention

[0005] This application provides an intelligent evaluation method and apparatus for enterprise bidding, which can improve the confidence level of bidding evaluation results.

[0006] The first aspect of this application provides an intelligent evaluation method for enterprise bidding, the method comprising:

[0007] During the project release phase, based on the bidding project parameters set in the backend, the review rule mapping engine automatically derives the appropriate review clauses and binds identification information to each of the review clauses.

[0008] Based on the identification information, a hash lock is performed using a smart contract, and the review terms are written into the blockchain to generate a snapshot of the review rules on the chain.

[0009] Content recognition is performed on the response files uploaded by the system account to extract the response data. The system account is an account that the supplier has completed real-name binding with a blockchain identity identifier.

[0010] An irreversible target hash fingerprint is generated for the objective data in the response data and uploaded to the blockchain. At the same time, the subjective data in the response data is encrypted to generate encrypted data.

[0011] During the intelligent review phase, each target hash fingerprint is judged and processed according to the review rule snapshot to generate a first review result;

[0012] The encrypted data is decrypted, and the decrypted data is reviewed according to the subjective scoring criteria of the experts. The experts' scoring behavior is then linked to the review results and signed to obtain the second review result.

[0013] The first review result is combined with the second review result to generate a review report, which is then affixed with an on-chain electronic signature and written into the blockchain.

[0014] Based on the above technical solutions, preferably, the step of generating an irreversible target hash fingerprint from the objective data in the response data and uploading it to the blockchain specifically includes:

[0015] The objective data is processed by field structuring to obtain the first data block;

[0016] A hash digest is calculated on the objective data to obtain a second data block;

[0017] The target data embedding method is generated based on the system account. The target data embedding method is the way in which the second data block is embedded into the first data block. The target data embedding method corresponds to the system account and is different from the historically generated data embedding method.

[0018] The second data block is embedded into the first data block using the target data embedding method to obtain the target hash fingerprint.

[0019] Based on the above technical solutions, preferably, in the intelligent review stage, according to the review rule snapshot, each of the target hash fingerprints is judged and processed to generate a first review result, specifically including:

[0020] During the intelligent review phase, the target data embedding method is invoked based on the system account;

[0021] The corresponding data extraction method is determined by the target data embedding method, and the hash digest is extracted from the target hash fingerprint by the data extraction method to obtain the first data block;

[0022] Determine the field labels corresponding to each field value contained in the first data block;

[0023] By aligning the field labels with the review clauses in the review rule snapshot, a logical mapping relationship between the field values ​​and the review clauses is established to ensure that the field labels correspond one-to-one with the review clauses;

[0024] The decision function is executed by parsing the logic to determine the relationship between the field value and the corresponding review clause's standard value, and the result is output as a Boolean.

[0025] All the aforementioned Boolean results are aggregated and generated into the first review result according to the weights, classifications, and judgment modes set by the review terms.

[0026] Based on the above technical solutions, preferably, after combining the first review result and the second review result to generate a review report, affixing an on-chain electronic signature, and writing it into the blockchain, the method further includes:

[0027] Upon receiving an objection request to the review report, the review report is located from the blockchain based on the electronic signature, and then the corresponding system account is determined based on the review report.

[0028] The system account is used to retrieve the snapshot of the review rules from the blockchain, and the snapshot of the review rules is then verified for version and integrity.

[0029] After the snapshot verification of the review rules is passed, multiple stored hash fingerprints are obtained from the blockchain. Each hash fingerprint is parsed and a hash digest is extracted using the data extraction method corresponding to the system account. The first data block is reconstructed based on the target hash fingerprint among the multiple hash fingerprints.

[0030] Perform field label recognition on the first data block, parse the structural relationship between field labels and field values, and align the field labels with the review clauses in the review rule snapshot;

[0031] Based on the decision function bound to each review clause recorded in the review rule snapshot, re-execute the parsing logic calculation between the field value and the clause standard value, and output each corresponding verification Boolean result;

[0032] Retrieve the first review result from the review report, perform reverse analysis, and extract each of the judgment Boolean results;

[0033] The verification Boolean result is compared with the judgment Boolean result, and an aggregation calculation is performed according to the weights in the original review process to calculate the verification value for the first review result.

[0034] If the verification value is determined to be less than or equal to a preset threshold, then the review report is determined not to have been modified.

[0035] Based on the above technical solutions, preferably, the step of performing content recognition on the response file uploaded by the system account and extracting the response data specifically includes:

[0036] The supplier uses the on-chain address preset during registration as a unique identifier, and registers into the on-chain identity contract by mapping it with real-name authentication information, binding actual identity data and generating a unique system account;

[0037] When the system account uploads the response file, the system automatically identifies the file format of the response file and categorizes the file format by structure.

[0038] Based on the content type classified by the structure, different processing paths are used to extract the content of the response file;

[0039] The response file content is mapped with field tags according to the review clause field specifications and field template library. The field tag mapping performs semantic classification on the unstructured fields in the response file content and maps them uniformly to standard response field tags.

[0040] The standard response field labels are subjected to response field structuring processing, including unifying the response field data format, standardizing the response field units, normalizing the response field time expression method, verifying the legality of the response field value range, and labeling the response field identification confidence level to obtain the response data.

[0041] Based on the above technical solutions, preferably, during the project release phase, the review rule mapping engine automatically derives suitable review clauses based on the bidding project parameters set in the backend, and binds identification information to each review clause, specifically including:

[0042] Establish parameter fields for the bidding project input by the project initiator to form the basic metadata for rule-based matching;

[0043] Based on the pre-configured clause adaptation mapping table, the basic metadata is matched for conditions, and the set of review clauses to be applied is automatically derived, which includes multiple review clauses.

[0044] For each of the aforementioned review clauses, identification information is automatically bound, which includes one or more of the following: clause category, clause scope of application, clause version number, and clause status.

[0045] Based on the above technical solutions, preferably, the step of performing condition matching on the parameter fields according to a pre-configured clause adaptation mapping table to automatically derive the applicable set of review clauses specifically includes:

[0046] Construct a structured clause adaptation mapping table, which is expressed in the form of a nested rule tree. Each rule unit of the clause adaptation mapping table contains a mapping relationship between a set of bidding project parameters and a set of corresponding review clause numbers.

[0047] The underlying metadata is then transformed into a parameter structure object in a standardized key-value pair format.

[0048] The review clause matching engine performs item-by-item logical judgment operations on the parameter structure object. The review clause matching engine parses the rule conditions one by one from the clause adaptation mapping table according to a preset order, and uses a decision tree path sinking mechanism to complete the rule hit detection operation between the parameter structure object and the rule unit.

[0049] All review clause numbers that are determined to meet the rule conditions are uniformly summarized into a candidate set of clause numbers applicable to the bidding project;

[0050] For each review clause number in the candidate set of clause numbers, perform clause structure loading, look up the review clause metadata table based on the review clause number, obtain complete review clause information, and encapsulate the data corresponding to the review clause information into standardized review clauses to obtain the review clause set.

[0051] A second aspect of this application provides an intelligent evaluation device for enterprise bidding, the device being used to execute an intelligent evaluation method for enterprise bidding as described in any of the preceding claims, the device comprising an acquisition module, a processing module, and an output module, wherein:

[0052] The acquisition module is used to automatically derive suitable review clauses by the review rule mapping engine based on the bidding project parameters set in the background during the project release stage, and bind identification information to each review clause.

[0053] The processing module is used to perform hash locking using a smart contract based on the identification information, and write the review terms into the blockchain to generate a snapshot of the review rules on the chain.

[0054] The processing module is used to perform content recognition on the response file uploaded by the system account and extract the response data, wherein the system account is an account that the supplier has completed real-name binding with blockchain identity identification;

[0055] The processing module is used to generate an irreversible target hash fingerprint for the objective data in the response data and upload it to the blockchain, while encrypting the subjective data in the response data to generate encrypted data.

[0056] The processing module is used to, during the intelligent review stage, perform judgment processing on each of the target hash fingerprints according to the review rule snapshot, and generate a first review result.

[0057] The processing module is used to decrypt the encrypted data, review the decrypted data according to the subjective scoring criteria of the experts, and bind the expert scoring behavior with the review results and sign them to obtain the second review result.

[0058] The output module is used to combine the first review result with the second review result, generate a review report, affix an on-chain electronic signature to the report, and write it into the blockchain.

[0059] A third aspect of this application provides an electronic device including a processor, a memory, a user interface, and a network interface, wherein the memory is used to store instructions, the user interface and the network interface are both used to communicate with other devices, and the processor is used to execute the instructions stored in the memory to cause the electronic device to perform the method as described in any of the foregoing.

[0060] A fourth aspect of this application provides a computer-readable storage medium storing instructions that, when executed, perform the method described in any of the preceding descriptions.

[0061] In summary, one or more technical solutions provided in the embodiments of this application have at least the following technical effects or advantages:

[0062] 1. This application combines a parameter-driven review clause mapping mechanism for bidding projects with on-chain rule snapshot solidification to ensure the uniqueness and immutability of the review basis. Simultaneously, it structures and hierarchically stores response data based on the supplier's blockchain identity. Objective data is stored on-chain using target hash fingerprints, while subjective data is encrypted with expert public keys and decryption permissions are bound, ensuring the authenticity of the data content and the exclusivity of access control. In the intelligent review phase, automated judgment and the generation of the first review result are achieved through precise alignment of on-chain rules and off-chain data. Expert review actions are also confirmed through identity binding and digital signatures. Finally, all review results are uniformly packaged into a review report with the platform's on-chain signature and written to the blockchain. This completes a technical closed loop where rules are verifiable and data is traceable, fundamentally improving the credibility of bidding review results.

[0063] 2. This application constructs a target data embedding method based on system account calls to achieve accurate parsing and field value recovery of the target hash fingerprint in the uploaded response data. Combined with the review clauses in the review rule snapshot, it performs field alignment and logical judgment, automatically outputs the judgment Boolean result, and aggregates the score according to the clause weight and classification, thereby forming a structured, standardized, and traceable first review result. This significantly improves the automation level of the objective review process, the consistency of the judgment logic, and the credibility of the review process, and effectively prevents human intervention and result tampering.

[0064] 3. This application constructs a review report location mechanism based on on-chain electronic signatures, combined with system account-driven rule snapshot verification, hash fingerprint parsing and field-level reconstruction, supplemented by review clause alignment and judgment function recalculation, to form a reversible, verifiable and comparable first review result verification path. This enables full-process consistency verification of review conclusions in terms of structure, content and scoring dimensions, thereby accurately reconstructing the review process and effectively identifying tampering behavior after receiving objection requests, significantly enhancing the verifiability of review results and the fairness of dispute resolution.

[0065] 4. This application introduces a system account mechanism based on blockchain identity contracts, enabling suppliers to use their on-chain address as a unique identifier during the registration phase and bind it to real-name authentication data to generate system accounts, ensuring the authenticity and traceability of the response data source. It automatically identifies the file format of the response file and determines the processing path according to its structure to accurately extract the content. Subsequently, based on the review clause field specifications and field template library, it performs field tag mapping, semantically classifying unstructured fields into unified standard response field tags. Further structured processing is then performed on each field, generating response data that is structurally complete, semantically clear, and formatted correctly, providing a high-quality data input foundation for subsequent intelligent review.

[0066] 5. This application achieves automated logical matching of bidding project parameters by constructing a structured clause adaptation mapping table and adopting a nested rule tree and decision path sinking mechanism. Combined with standardized parameter structure objects and review clause metadata tables, it completes the accurate derivation of review clause numbers and dynamic loading of clause content, ultimately generating a set of review clauses that fully correspond to the project conditions, have a complete structure, and are semantically consistent. This significantly improves the intelligence level and configuration efficiency of review rule adaptation, ensuring the accuracy, uniqueness, and transparency of the review logic. Attached Figure Description

[0067] Figure 1 This is a flowchart illustrating an intelligent review method for enterprise bidding disclosed in an embodiment of this application;

[0068] Figure 2 This is a schematic diagram of a module of an intelligent review device for enterprise bidding disclosed in an embodiment of this application;

[0069] Figure 3 This is a schematic diagram of the structure of an electronic device disclosed in an embodiment of this application.

[0070] Explanation of reference numerals in the attached drawings: 201, acquisition module; 202, processing module; 203, output module; 301, processor; 302, communication bus; 303, user interface; 304, network interface; 305, memory. Detailed Implementation

[0071] To enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments.

[0072] In the description of the embodiments of this application, the words "for example" or "for instance" are used to indicate examples, illustrations, or explanations. Any embodiment or design that is described as "for example" or "for instance" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or design options. Rather, the use of the words "for example" or "for instance" is intended to present the relevant concepts in a specific manner.

[0073] In the description of the embodiments of this application, the term "multiple" means two or more. For example, multiple systems means two or more systems, and multiple screen terminals means two or more screen terminals. Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the indicated technical features. Thus, a feature defined with "first" or "second" may explicitly or implicitly include one or more of that feature. The terms "comprising," "including," "having," and variations thereof all mean "including but not limited to," unless otherwise specifically emphasized.

[0074] Enterprise bidding review is a complex process that relies on an expert committee to score bid documents from multiple dimensions and determine the winning bidder. However, in the current technology, the review data mainly relies on manual operation and local system management, and lacks a full-process verifiable mechanism. This makes it easy for the scoring results to be tampered with, the review process to be difficult to trace, and the information exchange lacks encryption protection and consistency verification. It is easy for internal interference or external attacks to undermine the fairness of the review, thus seriously weakening the credibility of the review system.

[0075] This embodiment discloses an intelligent review method for enterprise bidding, referring to... Figure 1 This includes the following steps S110-S170:

[0076] S110, during the project release phase, based on the bidding project parameters set in the backend, the review rule mapping engine automatically derives suitable review clauses and binds identification information to each review clause.

[0077] The intelligent evaluation method for enterprise bidding disclosed in this application is applied to a server. The server includes, but is not limited to, electronic devices such as mobile phones, tablets, wearable devices, and PCs (Personal Computers), and can also be a backend server running an intelligent evaluation method for enterprise bidding. The server can be implemented using a standalone server or a server cluster composed of multiple servers.

[0078] In one possible implementation, during the project release phase, based on the bidding project parameters set in the backend, the review rule mapping engine automatically derives suitable review clauses and binds identification information to each review clause. Specifically, this includes: establishing parameter fields for the bidding project input by the project initiator to form basic metadata for rule matching; performing conditional matching on the basic metadata according to the pre-configured clause adaptation mapping table to automatically derive a set of applicable review clauses, which includes multiple review clauses; and automatically binding identification information to each review clause, which includes one or more of the following: clause category, clause scope, clause version number, and clause status.

[0079] Specifically, during the project release phase, the system receives bidding project parameter fields input by the project initiator. These fields include project type, procurement method, budget amount, bidder qualification type, whether joint bidding is allowed, and industry classification. These parameter fields are then structured and parsed, and stored in a standardized key-value pair format to form unique basic metadata corresponding to the current bidding project. This basic metadata serves as the input for subsequent review rule matching, possessing structural consistency, semantic clarity, and field extensibility, and is used to drive the execution of mapping logic.

[0080] The review rule mapping engine is invoked to load the clause adaptation mapping table. This table records the matching rules between different combinations of bidding project parameters and review clauses using preset conditional expressions. Using basic metadata as input, all matching rules in the mapping table are matched, employing methods such as row-by-row traversal, Boolean expression evaluation, or path determination to determine the hit status. The review clause numbers corresponding to all rules that meet the conditions are extracted and aggregated into a review clause set, forming the complete set of review clauses that should be adapted to the current bidding project. This ensures that the matching process is scalable, interpretable, and reproducible.

[0081] For each review clause in the review clause set, an identification information binding operation is performed. The review clause identification information includes attributes such as review clause category, review clause scope, review clause version number, and review clause status. The review clause category indicates the review clause's position in the review process, such as qualification review, responsiveness review, or scoring review; the review clause scope defines the set of project parameter conditions for the review clause to take effect; the review clause version number records the current revision status of the review clause; and the review clause status indicates whether the review clause is enabled. This identification information is written into the review clause structure, forming a complete, clearly defined, and version-controllable review clause object, providing data for subsequent rule snapshot generation and intelligent review execution.

[0082] In one possible implementation, based on a pre-configured clause adaptation mapping table, condition matching is performed on parameter fields to automatically derive the applicable set of review clauses. Specifically, this includes: constructing a structured clause adaptation mapping table, expressed as a nested rule tree, where each rule unit contains a mapping relationship between a set of bidding project parameters and a set of corresponding review clause numbers; converting basic metadata into a standardized key-value pair format parameter structure object; having the review clause matching engine perform item-by-item logical judgment operations on the parameter structure object, parsing rule conditions from the clause adaptation mapping table in a preset order, and using a decision tree path sinking mechanism to complete the rule hit detection operation between the parameter structure object and the rule unit; uniformly summarizing all review clause numbers that are determined to meet the rule conditions into a candidate set of clause numbers applicable to the bidding project; performing clause structure loading on each review clause number in the candidate set, searching the review clause metadata table based on the review clause number to obtain complete review clause information, and encapsulating the data corresponding to the review clause information into standardized review clauses to obtain a set of review clauses.

[0083] Specifically, a structured clause adaptation mapping table is first constructed. The clause adaptation mapping table is expressed in the form of a nested rule tree. Each mapping rule unit is formed by a set of bidding project parameter conditions and a set of review clause numbers. The mapping rules support multi-level condition nesting, logical combination and priority control.

[0084] Let the parameter structure of the bidding project be as follows:

[0085] P = {(k1,v1),(k2,v2),...,(k n ,v n )}

[0086] Where, k i This represents the name of the i-th parameter field, v i This represents the specific value corresponding to the i-th field, and P is a standardized parameter structure object.

[0087] The clause adaptation mapping table is a set of mappings between a set of rule conditions and review clause numbers, represented as follows:

[0088]

[0089] Among them, C j The j-th rule condition is represented by a Boolean logic expression C. j =f j (P)∈{0,1} indicates that f is true when the parameter structure P satisfies this condition. j (P) = 1; This represents the subset of review clause numbers corresponding to this condition, where T is the complete set of review clause numbers.

[0090] When designing the clause adaptation mapping table, a parameter space is constructed based on typical fields such as project type, budget amount, procurement method, bidding organization form, and industry characteristics. Condition judgment logic is set at each branch node to realize an extensible configuration model that drives the precise adaptation of review clauses by parameter changes, ensuring that the rule table has the characteristics of strong expressiveness, high parsing efficiency, and strong configurability.

[0091] After parsing all the bidding project parameter fields entered by the project initiator, the parameters are transformed into a standardized key-value pair format parameter structure object. This parameter structure object is a standard representation of all parameter fields in the current bidding project in terms of structure and semantics, including meta-information such as field name, field value, field type, and value range enumeration, while maintaining logical independence and compatibility between fields. As the input foundation for the review clause matching engine to execute rule matching, the parameter structure object can be dynamically loaded, uniformly transmitted, and structurally traversed, effectively improving the matching engine's processing performance and the accuracy of rule triggering.

[0092] The review clause matching engine is invoked, inputting a parameter structure object and initiating item-by-item logical judgment operations. The engine sequentially reads the rule units in the clause adaptation mapping table according to a preset parsing order and employs a decision tree path-down mechanism to perform conditional judgments on each rule. This mechanism starts from the root node of the rule tree and recursively judges along different logical paths based on the actual field values ​​in the parameter structure object until a match is reached at the rule's terminal leaf node, determining whether a review clause number has been matched. This process offers advantages such as short-circuit acceleration, condition pruning, and path positioning, enabling efficient rule matching decisions in complex condition spaces.

[0093] In the process of matching review clauses based on nested rule trees, the introduction of short-circuit acceleration, condition pruning, and path positioning mechanisms significantly improves the efficiency of rule parsing and the accuracy of matching. The short-circuit acceleration mechanism immediately terminates the evaluation of subsequent conditions on a branch path when a condition at a node is not met, avoiding unnecessary deep calculations. The condition pruning mechanism pre-screens rule branches that are unrelated to or impossible to satisfy the current project parameters during the preprocessing stage, reducing the matching range. The path positioning mechanism directly locates potentially matching path branches using the mapping relationship between parameter fields and rule nodes, thus skipping the full traversal of irrelevant paths. These three mechanisms work together to enable rule matching within a constant-level path depth, even when facing large-scale, high-dimensional, and complex parameter spaces, achieving high-performance, highly controllable, and highly consistent intelligent adaptation of review clauses.

[0094] The system aggregates the review clause numbers corresponding to all rule units where the rule determination result is "hit," forming a candidate set of clause numbers applicable to the current bidding project. Based on the parameter structure object P, the system executes the rule matching function f for all rules. j Perform a union operation on all valid subsets of review clause numbers to obtain a candidate set of clause numbers:

[0095]

[0096] Where [f] j [(P) = 1] is an indicator function that takes the value 1 when the condition is true and 0 otherwise. Multiplication is a set-value activation symbol, representing that the subset T of the clause number is only true when the condition is true. j It is included in the final set.

[0097] The candidate set of clause numbers is a collection of clause numbers for review. It is unique, deduplicated, and conditionally sufficient. After compliance verification and logical integrity checks, the set is used to proceed to the next stage for loading and structural reconstruction of subsequent clause content.

[0098] For each review clause number in the candidate set, a clause structure loading process is performed. Based on the review clause number, the review clause metadata table is accessed to retrieve all structural information corresponding to that review clause, including the review clause classification, field requirements, judgment logic, material requirements, applicable conditions, scoring method, version number, and status. Subsequently, the review clause information is encapsulated into a standardized review clause data structure, completing semantic binding, logical encapsulation, and version mapping operations. This ultimately generates a complete set of review clauses applicable to the current bidding project, for subsequent rule on-chaining, intelligent review, and expert review. The complete set of review clauses is then:

[0099]

[0100] Final review clauses The term number set T is generated by matching the project parameter structure P with the condition mapping rule R. * The corresponding set of structured review clause objects constitutes the core execution benchmark for the generation of on-chain rule snapshots and the binding of scoring logic in the intelligent review process.

[0101] S120, based on the identification information, uses a smart contract to perform hash locking, writes the review terms into the blockchain to generate a snapshot of the review rules on the chain.

[0102] First, a structured encapsulation process is performed on each review clause object that has completed the binding of identification information. The review clause object includes elements such as review clause number, review clause category, review clause scope of application, review clause field definition, review clause judgment logic, review clause required materials, review clause scoring method, review clause version number, and review clause status. It is formatted and encoded using JSON or a dedicated rule intermediate representation syntax to ensure that the review clause object has semantic integrity and serializability.

[0103] Then, a hash digest calculation is performed on each of the above structured encoded review clause objects. Standard cryptographic hash functions such as SHA-256 or Keccak256 are used to perform digest operations on the review clause structure data to obtain a one-to-one corresponding review clause target hash fingerprint. The target hash fingerprint uniquely maps the current clause content and structural state, and has irreversibility and content fingerprint properties, ensuring its immutability and traceability after being stored on the chain.

[0104] Next, a dedicated smart contract for review rule snapshots is deployed. This smart contract has functional modules such as rule registration, version binding, hash recording, clause indexing, and API calls, and reserves entry points for state management and access control. The target hash fingerprint of each review clause, along with its review clause number, review clause version number, scope of application, registration timestamp, and API call path, is used as parameters to call the smart contract's registration function. The smart contract then writes this data structure in an immutable form into the blockchain's state storage, forming an on-chain review rule snapshot entry.

[0105] Subsequently, after each review clause is successfully registered, the smart contract generates a rule snapshot index, records it in the on-chain log event, and provides rule snapshot retrieval and verification interfaces to support rule consistency verification and historical state auditing during subsequent review processes. All review clauses written to the blockchain can call the smart contract interface to perform hash verification on the current clause content during smart review, expert review, and dispute resolution, ensuring that the actual executed review logic remains completely consistent with the on-chain snapshot.

[0106] Finally, the hash values ​​of all review clauses in the current project are used to generate an overall snapshot summary, which serves as the root node of the review rule snapshot for the project. The snapshot version number, snapshot generation time, associated project number, and status information are recorded. The snapshot index pointer is written into the blockchain to form a unique identifier. The legality, completeness, and version status of any single review clause can be tracked and verified through this on-chain snapshot identifier.

[0107] Through the above implementation path, the review clauses with structured logic and legal effect are transformed into on-chain data assets with confirmed ownership. With smart contracts as the operating logic, target hash fingerprints as solidified credentials, and blockchain as an immutable carrier, an on-chain governance system for enterprise bidding review rules with auditability, verifiability, and compliance is constructed.

[0108] S130 performs content recognition on the response files uploaded by the system account and extracts the response data.

[0109] The system performs content recognition on response files uploaded by system accounts to extract response data. Specifically, this includes: suppliers registering using a pre-set on-chain address as a unique identifier, mapping it to real-name authentication information to register in an on-chain identity contract, binding actual identity data, and generating a unique system account; automatically identifying the file format of the response file and categorizing it structurally; using different processing paths based on the content type of the structurally categorized response files to extract their content; mapping field tags to the response file content according to the review clause field specifications and field template library; semantically classifying unstructured fields in the response file content and mapping them uniformly to standard response field tags; and performing structuring processing on the standard response field tags, including unifying the response field data format, standardizing response field units, normalizing the response field time expression method, verifying the legality of response field value ranges, and labeling the response field recognition confidence level to obtain the response data.

[0110] Specifically, before the response process is initialized, the identity verification of the system account must be completed. During the platform registration phase, suppliers use a preset on-chain address as their unique identifier. This on-chain address is mapped one-to-one with the real-name registration information, which includes the company name, unified social credit code, legal representative's name, registered mobile phone number, and platform account identifier. This data is encapsulated and registered in the on-chain identity contract, completing the generation of blockchain identity credentials. This system account serves as the sole identity basis for all subsequent response actions, used to associate uploaded data, operation records, and review results, ensuring the uniqueness, verifiability, and traceability of the responding entity.

[0111] When a system account submits a response file, it immediately performs a format recognition operation on the response file. The response file may be in PDF format, image format, or structured electronic document format. The specific type is determined by parsing the file header information, judging the file extension, and recognizing the content signature. Based on the recognition results, the response file is classified into a fixed-format response file or a structured document response file, which serves as the basis for subsequent path routing to ensure that each type of response file enters the corresponding content extraction process.

[0112] Based on the structural classification of the response file, it will proceed to different content processing paths. For fixed-format response files, such as PDF and image format response files, the OCR recognition module will be invoked to extract the text and image content. The recognition module combines text detection, layout analysis, and character recognition models to complete the segmented extraction of text and structural information. For structured document response files, such as Word format response files and online form files, nested fields will be extracted directly through the document object model. The extracted content maintains consistency in hierarchy and attribute mapping, thereby obtaining the complete content of the response file.

[0113] The extracted response file content is mapped with field tags. This mapping process, based on the review clause field specifications and field template library, uses methods such as semantic similarity analysis, keyword tree matching, and named entity recognition to semantically categorize and unify unstructured field information. This maps field content with various expressions to unified standard response field tags; for example, expressions such as "legal representative's name," "company legal person," and "legal person's name" are uniformly mapped to the "legal representative" field tag, ensuring the consistency, structure, and standardization of subsequent field judgment logic.

[0114] The response file content, after completing the field label mapping, undergoes structured processing of the response fields. This process includes standardizing the data format of response fields (e.g., retaining decimal places for numerical values); standardizing units (e.g., converting ten thousand yuan to yuan); normalizing the time representation of response fields (e.g., unifying "January 1, 2023" as "2023-01-01"); validating the legality of response field value ranges (e.g., ensuring the company's establishment date is not later than the bid deadline); and marking the confidence level of response field recognition (e.g., automatically triggering a review flag if the OCR recognition confidence level is below a set threshold). The final generated structured response data consists of field labels, field values, data format, units, time representation, and confidence levels, forming a unified format for providing stable and reliable data input for subsequent intelligent review.

[0115] S140 generates an irreversible target hash fingerprint for the objective data in the response data and uploads it to the blockchain, while encrypting the subjective data in the response data to generate encrypted data.

[0116] First, after the structured response data is generated, the field classification module is invoked to categorize all response fields according to predefined field classification rules. These rules divide the structured response data into objective and subjective data based on the attributes of the review clause fields. Objective data refers to data that can be directly determined according to the rules, such as company name, business license number, qualification level, registered capital, project manager certificate number, and financial statement indicators, without relying on subjective human judgment. Subjective data refers to data that requires comprehensive evaluation by review experts based on experience or judgment, such as technical solutions, performance plans, service commitment statements, and organizational structures; its content is descriptive, structurally open, and involves evaluation differences.

[0117] In one possible implementation, generating an irreversible target hash fingerprint for objective data in the response data and uploading it to the blockchain specifically includes: performing field structuring processing on the objective data to obtain a first data block; performing hash digest calculation on the objective data to obtain a second data block; generating a target data embedding method based on the system account, wherein the target data embedding method is the way the second data block is embedded into the first data block, the target data embedding method corresponds to the system account and is different from the historically generated data embedding method; and embedding the second data block into the first data block through the target data embedding method to obtain the target hash fingerprint.

[0118] Specifically, objective data undergoes field structuring processing. Based on the field definitions and template standards of the review clauses, the objective data in the original response file is parsed and labeled, extracting elements such as field labels, field values, field units, field formats, and field positions. These elements are then encapsulated into a unified data structure, serving as the first data block. This first data block is a field-structured object with stable field boundaries, a standard data expression method, and clear semantic field labels, forming the basic structural unit for subsequent target hash fingerprint construction.

[0119] A hash digest calculation is performed on the objective data. Field labels and values ​​are extracted from the first data block and concatenated in standard serialization order to form a hash input string. The SHA-256 or Keccak256 hash algorithm is then used to perform an irreversible encryption operation on this string, outputting a fixed-length hash value as the second data block. The second data block is the hash digest of the objective fields, uniquely mapping to the original field values. It possesses immutability and deterministic results, and is the core digest unit for achieving on-chain evidence storage.

[0120] Based on the current user's target data embedding method, the data embedding method generation module is invoked. The input parameters are the user's blockchain identity identifier, the relevant field tags, and historical embedding records. Through identity mapping and version control logic, a unique data embedding path rule is assigned to the current user, constructing the target data embedding method. The target data embedding method defines the position, level, tag naming, and structural nesting method of the second data block embedded in the first data block, ensuring that each user's embedding method is unique and different from historical methods, preventing duplicate target hash fingerprints and embedding path conflicts.

[0121] The target hash fingerprint construction operation is performed by invoking the target data embedding method to embed the second data block into the specified position of the first data block, constructing an embedded hash structure as the final target hash fingerprint. This target hash fingerprint structure simultaneously retains the original field structure information and hash digest path information, enabling verification of the integrity of field values ​​and embedding patterns during subsequent verification. The target hash fingerprint, along with field tags, field page number positions, field extraction confidence levels, and the user's blockchain identity credentials, is bound to form a field notarization object. This notarization object is then written to the blockchain via a smart contract interface, forming an on-chain field-level review data notarization record. This ensures the authenticity, structure, and non-repudiation of the response data are guaranteed throughout the entire review process.

[0122] Next, all objective data fields, including target hash fingerprints, field tags, field extraction locations, and the account's blockchain identity credentials, are structurally encapsulated, and the encapsulated data is uploaded to the blockchain via a smart contract interface. This on-chain evidence storage operation is handled by a dedicated response data evidence storage contract, generating an immutable record for each field on the chain, including field identifier, hash value, timestamp, response subject identifier, and project identifier, forming a field-level, non-repudiable blockchain evidence storage track.

[0123] Meanwhile, for subjective data fields, each review expert with scoring authority is assigned a unique encryption key pair, and the public key is registered and bound to the corresponding expert account through an expert identity authentication mechanism. Subsequently, each subjective field content is identified and distributed according to field tags, and the corresponding expert's encryption public key is used to perform asymmetric encryption on the field value, ensuring that the subjective data received by each expert is exclusively encrypted data, which can only be decrypted and accessed by their corresponding private key. The generated encrypted data tags, encrypted expert IDs, encrypted timestamps, and access authorization paths are uniformly sealed in an off-chain database. At the same time, the field encryption digest and public key encryption mapping record are written to the blockchain through a smart contract to ensure that the data transmission process has content confidentiality, reception direction, and decryption controllability, thereby preventing subjective data from being accessed or tampered with by unauthorized entities during transmission, storage, and scoring.

[0124] Finally, the encrypted digests, field tags, and storage paths of all subjective fields are generated into field index records via smart contracts and written to the blockchain. These records are used for subsequent access control verification and consistency checks of encrypted field content, ensuring that expert scoring is based on verifiable and tamper-proof original response content. Through this collaborative mechanism of on-chain storage of objective data and off-chain encryption of subjective data, the response data is made "verifiable," "protectable," "traceable," and "non-repudiable" during the review process, providing structural security and a reliable baseline for intelligent review.

[0125] S150, during the intelligent review phase, performs judgment processing on each target hash fingerprint based on the review rule snapshot, and generates the first review result.

[0126] In one possible implementation, during the intelligent review phase, based on the review rule snapshot, each target hash fingerprint is judged and processed to generate a first review result. Specifically, this includes: during the intelligent review phase, invoking the target data embedding method according to the system account; determining the corresponding data extraction method through the target data embedding method, and extracting a hash digest from the target hash fingerprint using the data extraction method to obtain a first data block; determining the field labels corresponding to each field value contained in the first data block; aligning the field labels with the review clauses of the review rule snapshot to establish a logical mapping relationship between field values ​​and review clauses, ensuring a one-to-one correspondence between field labels and review clauses; performing a judgment function between the field values ​​and the corresponding review clause's standard value through parsing logic calculation, and outputting a judgment Boolean result; and aggregating all judgment Boolean results according to the weights, classifications, and judgment modes set by the review clauses to generate the first review result.

[0127] Specifically, upon entering the intelligent review stage, the system first invokes the target data embedding method corresponding to the account based on the blockchain identity credentials of the account currently participating in the review. The target data embedding method has already been generated for the account and registered on the chain during the response data target hash fingerprint construction stage. By parsing the path rules, field hierarchy mappings, and embedding parameter structures in this embedding method, the system obtains the exclusive data extraction path for the target hash fingerprint under this account, which serves as the unique index method for hash digest extraction.

[0128] The structured parsing operation is performed using the target data embedding method described above. Embedded hash digest data segments are extracted from the target hash fingerprint. The extraction process relies on embedding paths, tag matching, and field indexing mechanisms to ensure that the extracted hash digest data accurately corresponds to the original values ​​of objective fields. This hash digest is then parsed into a first data block, which is a set of structured hash data. Each entry contains a field tag and its corresponding hash value, used for field identification and data content reconstruction before judgment.

[0129] Analyze each data item in the first data block and identify the field label corresponding to the hash digest. The field labels include standard field names such as "Company Name", "Qualification Level", "Registered Capital", and "Project Manager Qualification Certificate Number". Through the field label index structure, semantically confirm each field label with the field dimensions in the review model to ensure that the hash digest can be used for the judgment logic execution of the corresponding review clause.

[0130] The review rule snapshot is invoked, and field alignment is performed on the field labels in the first data block. Based on the field labels bound to each review clause in the review rule snapshot, a logical mapping relationship is established between the field labels and the review clauses. Field alignment requires that the field labels match the field definitions of the review clauses one-to-one, and that the field types, field formats, and field positions are consistent, forming a computable input channel between the field values ​​and the standard values ​​of the clauses, ensuring stable and consistent logical execution input.

[0131] Based on the field alignment results, a decision function is executed to compare the field values ​​with the standard values ​​of the review clauses. The decision function, depending on the logical definition of the review clauses, may include equality determination functions, greater than / less than interval functions, time validity functions, regular expression matching functions, or Boolean logic combination functions, etc. Let the value of the i-th field be v. i Its corresponding field label is l i The review clause number matched in the review rule snapshot is t. i The standard value for this review clause is s. i The corresponding decision function is:

[0132] f i (v i ,s i )

[0133] The logical judgment function between field values ​​and review clause standard values ​​is expressed as follows:

[0134] b i =f i (v i ,s i )∈{0,1}

[0135] Where b i This indicates the Boolean result of the judgment. A value of 1 indicates that the field value meets the requirements of the clause, and a value of 0 indicates that it does not meet the requirements.

[0136] The logical judgment function is set according to the logical type of the review clause, including equal value matching clauses, numerical range clauses, time validity clauses, and regular expression matching clauses, which are represented as follows:

[0137]

[0138] in, and These represent the minimum and maximum values ​​required by the review clause, respectively. All f i The final output is a Boolean value b. i As a result of determining whether this field matches its review terms, the system will subsequently process multiple b... i The merged review and aggregation operations form the complete first review result input. Each function f i In the intelligent review system, it is configured as a rule logic module, which is scalable, verifiable and composable, and supports dynamic loading and binding with on-chain rule snapshots.

[0139] The field value is input into the judgment function, compared with the standard value set in the review clause, and the judgment Boolean result is output. A Boolean result of true indicates pass and false indicates fail. It is the smallest granular unit of judgment.

[0140] All field judgment Boolean results are aggregated and a comprehensive calculation is performed according to the clause weights, clause classifications, and aggregation rules set in the review clause snapshot. Depending on the review model, logical AND / or aggregation, weighted average, or standardized score mapping via a scoring function can be used to ultimately form a structured first review result. The first review result includes detailed field judgments, detailed clause-level scores, aggregated scores, anomaly alerts, and review conclusions, providing an objective basis and tracing evidence for subsequent subjective score merging and expert review.

[0141] S160: Decrypt the encrypted data, review the decrypted data according to the subjective scoring criteria of the experts, and bind the expert scoring behavior with the review results and sign them to obtain the second review result.

[0142] Upon receiving encrypted subjective data, the system first retrieves the private key of the corresponding expert account from the expert key management module based on the expert identity information corresponding to each subjective scoring clause. This private key performs asymmetric decryption on the encrypted data, restoring the original subjective response field content. The decrypted data is then loaded into the expert review interface according to field tags and bound to the current review project number, review clause number, and expert blockchain identity credential. Experts conduct quantitative or qualitative reviews of the content based on the scoring dimensions, standards, and weighting requirements of the subjective scoring clauses. Each scoring action records the corresponding field content, score value, scoring time, scoring device identifier, and expert blockchain address. A non-repudiable digital signature is generated based on this identity information for each scoring action. The score value and signature are encapsulated together into a structured scoring record, forming the second review result. This result is then written to the blockchain using a scoring hash digest, ensuring the integrity of the subjective review results, the authenticity of the identity, traceability, and the immutability of the data.

[0143] S170 combines the results of the first review with those of the second review to generate a review report, affixes an on-chain electronic signature to the platform, and writes it into the blockchain.

[0144] After generating the first and second review results, the two results are first structurally integrated. Based on the review clause numbers, the objective scoring data from the first review result and the subjective scoring data from the second review result are merged and calculated according to clause classification and weighting requirements, generating a review report containing clause-level scores, scoring sources, review paths, and a comprehensive score. This review report is then structurally bound to elements such as the project number, the bidding unit's blockchain identity, the expert's blockchain identity, scoring time, and scoring method, generating a unique review data structure. An on-chain electronic signature is then executed on this review data structure using the platform's private key, forming a signed final review report. Subsequently, the review report smart contract interface is called to write the signed review report summary, signature value, version identifier, and timestamp into the blockchain, achieving full-process ownership verification, immutability, and verifiability of the review results, ensuring the authenticity, legality, and audit traceability of the entire review conclusion.

[0145] In one possible implementation, after combining the first review result with the second review result to generate a review report, affixing an on-chain electronic signature, and writing it into the blockchain, the method further includes: upon receiving an objection request for the review report, locating the review report from the blockchain based on the electronic signature, and then determining the corresponding system account based on the review report; retrieving a snapshot of the review rules from the blockchain through the system account, and performing version and integrity verification on the review rule snapshot; after the review rule snapshot verification is passed, obtaining multiple stored hash fingerprints from the blockchain, parsing each hash fingerprint using the data extraction method corresponding to the system account and extracting the hash digest, and reconstructing the first number based on the target hash fingerprint among the multiple hash fingerprints. According to the data block; perform field label recognition on the first data block, parse the structural relationship between field labels and field values, and align the field labels with the review clauses in the review rule snapshot; according to the decision function bound to each review clause recorded in the review rule snapshot, re-execute the parsing logic calculation between the field value and the clause standard value, and output each corresponding verification Boolean result; retrieve the first review result of the review report, perform reverse parsing, and extract each decision Boolean result; compare the verification Boolean result with the decision Boolean result, perform aggregation calculation according to the weight in the original review process, and calculate the verification value for the first review result; if the verification value is less than or equal to the preset threshold, it is determined that the review report has not been modified.

[0146] Specifically, after the review report is written to the blockchain, if an objection request is received regarding the review report, the review verification mechanism is immediately initiated. The specific implementation process includes eight consecutive steps: review report location, account tracing, rule snapshot verification, hash reconstruction extraction, field alignment verification, Boolean result recalculation, result comparison and aggregation, and verification value determination. This ensures that the objection handling is auditable, verifiable, and non-repudiable.

[0147] Upon receiving an objection request, the platform uses the review report identifier contained in the objection request to perform a unique hash match using the platform's on-chain electronic signature to locate the target review report stored in the blockchain. Based on the identity credential field in the electronic signature structure, the blockchain identity of the account corresponding to the review report is extracted and used as the main index for all subsequent data traceability.

[0148] The system retrieves a snapshot copy of the review rules applicable to the project from the blockchain by accessing the review configuration settings linked to the account. This snapshot, frozen on the blockchain during the project release phase, contains information such as review clause numbers, field definitions, judgment logic, and scoring weights. Version number consistency comparison and hash digest consistency verification are performed on the review rule snapshot to ensure it has not been replaced, tampered with, or redefined.

[0149] Based on the data extraction method bound to the account, all associated hash fingerprint sets are retrieved from the blockchain. For each hash fingerprint, the corresponding target data embedding method is called to perform structural parsing and extract the embedded hash digest content. The first data block is reconstructed according to the embedding path. The first data block is the original structured value set of the objective response fields submitted by the account during the review stage.

[0150] Perform field label recognition and semantic verification operations on the first data block, parse out the correspondence between field labels and field values, and perform field alignment in the review rule snapshot according to the field labels to ensure that each field value corresponds to a unique review clause, thus ensuring that the one-to-one mapping relationship between input data and rule logic is established.

[0151] The decision function is re-executed for each field value and its corresponding standard value in the review clause. The decision function is strictly calculated based on the logical expression recorded in the rule snapshot, including numerical range judgment, string matching, regular expression validation or logical combination function. The execution result is the Boolean result of the verification between each field value and its review standard.

[0152] Retrieve the first review results recorded in the review report and parse the Boolean results at the field levels contained therein. Each Boolean result is stored in a structured manner in the report, including the clause number, field label, judgment conclusion, and scoring weight. Perform reverse parsing on it to extract all the original Boolean judgment outputs, which will serve as the benchmark for subsequent comparisons.

[0153] Each verification Boolean result is compared item by item with its corresponding judgment Boolean result to determine whether they are completely consistent. For consistent items, they are included in the aggregate score according to their original weights; for inconsistent items, the difference fields are marked and recorded, and then all results are aggregated according to the weight function set in the original review process to calculate the verification value of the first review result.

[0154] The verification value is compared with a preset threshold. If the verification value is less than or equal to the threshold, it means that the first review result recorded in the review report has not been modified in terms of fields, logic and scoring, and the review report is deemed credible. If the verification value is higher than the threshold, the audit process is triggered and the on-chain objection mark is recorded, and the review enters the manual review channel. This ensures that every objection has a mathematical basis and on-chain evidence support, thereby improving the review credibility and technical consistency of the review mechanism.

[0155] This embodiment also discloses an intelligent review device for enterprise bidding, which is used to execute an intelligent review method for enterprise bidding as described in any of the above embodiments, referring to... Figure 2 The device includes an acquisition module 201, a processing module 202, and an output module 203, wherein:

[0156] The acquisition module 201 is used to automatically derive suitable review clauses by the review rule mapping engine based on the bidding project parameters set in the background during the project release phase, and bind identification information to each review clause.

[0157] Processing module 202 is used to perform hash locking using a smart contract based on the identification information, and write the review terms into the blockchain to generate a snapshot of the review rules on the chain.

[0158] The processing module 202 is used to perform content recognition on the response files uploaded by the system account and extract the response data. The system account is an account that the supplier has completed real-name binding with blockchain identity identification.

[0159] The processing module 202 is used to generate an irreversible target hash fingerprint for the objective data in the response data and upload it to the blockchain, while encrypting the subjective data in the response data to generate encrypted data.

[0160] The processing module 202 is used to perform judgment processing on each target hash fingerprint according to the review rule snapshot during the intelligent review stage, and generate the first review result.

[0161] The processing module 202 is used to decrypt the encrypted data, review the decrypted data according to the subjective scoring criteria of the experts, bind the expert scoring behavior with the review results and sign them to obtain the second review result.

[0162] Output module 203 is used to combine the first review result with the second review result, generate a review report, affix an on-chain electronic signature to the platform, and write it into the blockchain.

[0163] It should be noted that the above embodiments of the apparatus are only illustrated by the division of the above functional modules. In practical applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. In addition, the apparatus and method embodiments provided in the above embodiments belong to the same concept, and the specific implementation process can be found in the method embodiments, which will not be repeated here.

[0164] This embodiment also discloses an electronic device, as shown in the reference. Figure 3 The electronic device may include: at least one processor 301, at least one communication bus 302, user interface 303, network interface 304, and at least one memory 305.

[0165] The communication bus 302 is used to enable communication between these components.

[0166] The user interface 303 may include a display screen and a camera. Optionally, the user interface 303 may also include a standard wired interface and a wireless interface.

[0167] The network interface 304 may optionally include a standard wired interface or a wireless interface (such as a Wi-Fi interface).

[0168] The processor 301 may include one or more processing cores. The processor 301 connects to various parts of the server using various interfaces and lines, and performs various server functions and processes data by running or executing instructions, programs, code sets, or instruction sets stored in memory 305, and by calling data stored in memory 305. Optionally, the processor 301 may be implemented using at least one hardware form of Digital Signal Processing (DSP), Field-Programmable Gate Array (FPGA), or Programmable Logic Array (PLA). The processor 301 may integrate one or a combination of several of the following: Central Processing Unit (CPU), Graphics Processing Unit (GPU), and modem. The CPU primarily handles the operating system, user interface, and applications; the GPU is responsible for rendering and drawing the content required for display; and the modem handles wireless communication. It is understood that the modem may also be implemented as a separate chip without being integrated into the processor 301.

[0169] The memory 305 may include random access memory (RAM) or read-only memory. Optionally, the memory may include a non-transitory computer-readable storage medium. The memory 305 may be used to store instructions, programs, code, code sets, or instruction sets. The memory 305 may include a program storage area and a data storage area. The program storage area may store instructions for implementing an operating system, instructions for at least one function (such as touch functionality, sound playback functionality, image playback functionality, etc.), instructions for implementing the various method embodiments described above, etc.; the data storage area may store data involved in the various method embodiments described above, etc. Optionally, the memory 305 may also be at least one storage device located remotely from the aforementioned processor 301. As a computer storage medium, the memory 305 may include an operating system, a network communication module, a user interface 303 module, and an application program for an intelligent review method for enterprise bidding.

[0170] exist Figure 3In the electronic device shown, the user interface 303 is mainly used to provide an input interface for the user and to obtain the user input data; while the processor 301 can be used to call the application program stored in the memory 305 for an intelligent review method for enterprise bidding. When executed by one or more processors 301, the electronic device executes one or more methods as described in the above embodiments.

[0171] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions and modules involved are not necessarily essential to this application.

[0172] In the above embodiments, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions in other embodiments.

[0173] In the several embodiments provided in this application, it should be understood that the disclosed apparatus can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units 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. Furthermore, the shown or discussed mutual couplings or direct couplings or communication connections may be through some service interfaces; indirect couplings or communication connections between apparatuses or units may be electrical or other forms.

[0174] The units described 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.

[0175] 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.

[0176] 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 device (CMD). 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 memory 305 and includes several 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 memory 305 includes various media capable of storing program code, such as a USB flash drive, external hard drive, magnetic disk, or optical disk.

[0177] This application also discloses a computer-readable storage medium storing instructions. When executed by one or more processors 301, these instructions cause an electronic device to perform one or more of the methods described in the above embodiments.

[0178] The foregoing description is merely an exemplary embodiment of this disclosure and should not be construed as limiting the scope of this disclosure. Any equivalent changes and modifications made in accordance with the teachings of this disclosure shall still fall within the scope of this disclosure. Those skilled in the art will readily conceive of other embodiments of this disclosure upon considering the specification and the disclosure of practical truth. This application is intended to cover any variations, uses, or adaptations of this disclosure that follow the general principles of this disclosure and include common knowledge or customary techniques in the art not described in this disclosure. The specification and embodiments are considered exemplary only, and the scope and spirit of this disclosure are defined by the claims.

Claims

1. An intelligent review method for enterprise bidding, characterized in that, The method comprises: In the project release stage, based on the background setting of the bidding project parameters, the adaptive evaluation clauses are automatically derived by the evaluation rule mapping engine, and the identification information of each evaluation clause is bound; According to the identification information, the evaluation clauses are written into the evaluation rule snapshot on the block chain generation chain by using the smart contract for hash locking; The content of the response file uploaded by the system account is identified, and the response data is extracted, wherein the system account is an account of a supplier that has completed real-name binding with a blockchain identity; Objective data in the response data is generated into an irreversible target hash fingerprint and uploaded to the blockchain, while subjective data in the response data is encrypted to generate encrypted data; In the intelligent evaluation stage, according to the evaluation rule snapshot, each target hash fingerprint is judged and processed to generate a first evaluation result; The encrypted data is decrypted, the decrypted data is evaluated according to the subjective scoring clause of the expert, and the expert scoring behavior and the evaluation result are bound and signed to obtain a second evaluation result; The first evaluation result and the second evaluation result are combined to generate an evaluation report and affix a platform on-chain electronic signature, and are written into the blockchain; After the first evaluation result and the second evaluation result are combined to generate an evaluation report and affix a platform on-chain electronic signature, and are written into the blockchain, the method further comprises: After receiving the objection request for the evaluation report, the evaluation report is located from the blockchain according to the electronic signature, and the corresponding system account is determined according to the evaluation report; Through the system account, the evaluation rule snapshot is called from the blockchain, and version checking and integrity checking are performed on the evaluation rule snapshot; After the evaluation rule snapshot passes the checking, a plurality of hash fingerprints stored in the blockchain are obtained, each hash fingerprint is parsed and hash digest is extracted through the data extraction method corresponding to the system account, and a first data block is reconstructed according to the target hash fingerprint in the plurality of hash fingerprints; The field label identification is performed on the first data block, the structural relationship between the field label and the field value is parsed, and the field label is aligned with the evaluation clause in the evaluation rule snapshot; According to the judgment function bound to each evaluation clause recorded in the evaluation rule snapshot, the parsing logic calculation between the field value and the clause standard value is re-executed, and each corresponding verification Boolean result is outputted; The first evaluation result of the evaluation report is called and reverse parsed to extract each judgment Boolean result; The verification Boolean result and the judgment Boolean result are compared, and the verification value for the first evaluation result is calculated by performing aggregation calculation according to the weight in the original evaluation process. If it is judged that the verification value is less than or equal to a preset threshold, it is determined that the evaluation report has not been modified.

2. The intelligent review method for enterprise bidding according to claim 1, characterized in that, The objective data in the response data is generated into an irreversible target hash fingerprint and uploaded to the blockchain, specifically comprising: The objective data is subjected to field structural processing to obtain a first data block; Hashing digest calculation is performed on the objective data to obtain a second data block; A target data embedding mode is generated based on the system account, the target data embedding mode being a mode in which the second data block is embedded in the first data block, and the target data embedding mode corresponding to the system account; The second data block is embedded in the first data block through the target data embedding mode to obtain the target hash fingerprint.

3. The intelligent review method for enterprise bidding according to claim 2, characterized in that, In the intelligent review stage, each target hash fingerprint is determined and processed according to the review rule snapshot to generate a first review result, specifically including: In the intelligent review stage, the target data embedding mode is called according to the system account; A corresponding data extraction mode is determined through the target data embedding mode, and a hash digest is extracted from the target hash fingerprint through the data extraction mode to obtain the first data block; The field labels corresponding to the field values contained in the first data block are determined; The field labels are aligned with the review clauses of the review rule snapshot through the field labels to establish a logical mapping relationship between the field values and the review clauses, ensuring that the field labels and the review clauses correspond one by one; A determination function is executed between the field values and the clause standard values of the corresponding review clauses through analysis logic calculation to output a determination Boolean result; All determination Boolean results are collected and aggregated to generate the first review result according to the weight, classification and determination mode set by the review clause.

4. The intelligent review method for enterprise bidding according to claim 1, characterized in that, The content of the response file uploaded by the system account is identified, and the response data is extracted, specifically including: The supplier uses the preset on-chain address as the unique identity when registering, and registers in the on-chain identity contract through the mapping with the real-name authentication information, binds the actual identity data, and generates a unique system account; When the response file is uploaded by the system account, the file format of the response file is automatically identified, and the file format is classified by structure; According to the content type of the structure classification, different processing paths are used for the response file to extract the response file content; The response file content is mapped to the field label according to the field specification and field template library of the review clause, and the unstructured field in the response file content is semantically classified and uniformly mapped to a standard response field label; The standard response field label is subjected to response field structuring processing, including uniform response field data format, standardized response field unit, normalized response field time expression method, verification of response field value domain legality, and labeling of response field recognition confidence, to obtain the response data.

5. The intelligent review method for enterprise bidding according to claim 1, characterized in that, In the project release stage, the bidding project parameters set by the background are used to automatically derive the adapted review clauses by the review rule mapping engine, and identification information is bound to each review clause, specifically including: A parameter field for the bidding project input by the project initiator is established to form basic metadata for rule matching; According to a pre-configured clause adaptation mapping table, the base metadata is conditionally matched to automatically derive a set of applicable review clauses, the set of review clauses including a plurality of review clauses; For each of the review clauses, identification information is automatically bound, the identification information including one or more of clause classification, clause scope of application, clause version number, and clause status.

6. The intelligent review method for enterprise bidding according to claim 5, characterized in that, The parameter fields are conditionally matched according to the pre-configured clause adaptation mapping table to automatically derive a set of applicable review clauses, specifically including: A structured clause adaptation mapping table is constructed, the clause adaptation mapping table being expressed in the form of a nested rule tree, each rule unit of the clause adaptation mapping table containing a mapping relationship between a group of bidding project parameters and a group of corresponding review clause numbers; The base metadata is converted into a parameter structure object in the form of a standardized key-value pair; A review clause matching engine performs item-by-item logical judgment operations on the parameter structure object, the review clause matching engine parsing rule conditions from the clause adaptation mapping table in a preset order and using a decision tree path sinking mechanism to complete rule hit detection operations between the parameter structure object and the rule unit; All review clause numbers determined to satisfy rule conditions are uniformly summarized into a candidate set of clause numbers applicable to the bidding project; For each review clause number in the candidate set of clause numbers, clause structure loading is performed, complete review clause information is obtained by searching a review clause metadata table according to the review clause number, and data corresponding to the review clause information is encapsulated into a standardized review clause to obtain the set of review clauses.

7. An intelligent review device for enterprise bidding, characterized by, The device is used to perform an intelligent review method for enterprise bidding as claimed in any one of claims 1-6, and the device includes an acquisition module (201), a processing module (202), and an output module (203), wherein: The acquisition module (201) is configured to, in a project publishing stage, automatically derive adapted review clauses by an evaluation rule mapping engine based on bidding project parameters set in the background, and bind identification information to each of the review clauses; The processing module (202) is configured to use a smart contract to perform hash locking according to the identification information, and write the review clauses into an evaluation rule snapshot on a blockchain generation chain; The processing module (202) is configured to perform content recognition on a response file uploaded by a system account, and extract response data, wherein the system account is an account of a supplier that has completed real-name binding with a blockchain identity; The processing module (202) is configured to generate an irreversible target hash fingerprint for objective data in the response data and upload the target hash fingerprint to the blockchain, and encrypt subjective data in the response data to generate encrypted data; The processing module (202) is configured to, in an intelligent review stage, perform judgment processing on each of the target hash fingerprints according to the evaluation rule snapshot to generate a first evaluation result; The processing module (202) is used for decrypting the encrypted data, reviewing the decrypted data according to the subjective scoring clause of the expert, and binding and signing the expert scoring behavior and the review result to obtain a second review result; The output module (203) is used for combining the first review result and the second review result, generating a review report, and stamping a platform on-chain electronic signature, and writing into a block chain.

8. An electronic device, comprising: The electronic device comprises a processor (301), a communication bus (302), a user interface (303), a network interface (304) and a memory (305), the memory (305) is used for storing instructions, the user interface (303) and the network interface (304) are both used for communicating with other devices, the communication bus (302) is used for realizing the connection communication between components in the electronic device, and the processor (301) is used for executing the instructions stored in the memory (305) to enable the electronic device to execute the method in any one of claims 1-6.

9. A computer-readable storage medium, characterized in that, The computer readable storage medium stores instructions, when the instructions are executed, the method in any one of claims 1-6 is executed.

Images