A method and device for detecting bidding contradictions based on multi-modal evidence and contradiction propagation graph

Abstract

The application relates to a bidding contradiction detection method and device based on multi-modal evidence and contradiction propagation graph. The method comprises the following steps: acquiring technical requirements in a bidding document, and extracting response evidence for the technical requirements from multiple positions, multiple modes and multiple granularities of the same bidding document. According to the technical requirements and the response evidence, contradiction detection is performed from three dimensions of cross-position, cross-mode and cross-granularity, and a contradiction list is generated. A contradiction propagation graph is constructed according to the cause-effect relationship between contradictions in the contradiction list. According to the graph, the cumulative influence coefficient of each contradiction is calculated, and a contradiction density index is calculated based on the cumulative influence coefficient. According to the response evidence, an evidence chain integrity score reflecting the integrity of multi-modal technical evidence is calculated. The contradiction density index and the evidence chain integrity score are fused to calculate a comprehensive contradiction risk value. By using the method, quantitative evaluation of internal contradiction chain risk of a bidding scheme and intelligent detection of a comprehensive risk value can be realized.

Description

Technical Field

[0001] This application relates to the field of intelligent bidding and tendering review technology, and in particular to a bidding conflict detection method and device based on multimodal evidence and conflict propagation graph. Background Technology

[0002] In software development project bidding, the technical solution review is the core step in determining the winning bid. Review experts need to compare the technical solution in the bid documents with the technical requirements in the tender documents item by item to determine whether the bid solution meets the requirements. This process has the following characteristics: there are many technical requirements, with a single tender document potentially containing dozens or even hundreds of technical requirements; the technical requirements are scattered across multiple chapters of the tender document; and the bidders' responses are also scattered across multiple chapters, modalities, and granularities in the bid documents.

[0003] In current review practices, experts need to search, correlate, and compare across chapters, modalities, and granularities, manually completing the matching and compliance judgment of technical requirements and responses. This approach suffers from low efficiency, easy omissions, and strong subjectivity. More importantly, most existing intelligent review methods stop at "detecting problems" and lack the ability to "quantify risks" and "make corrective suggestions," requiring reviewers to still manually write review comments and corrective suggestions.

[0004] In recent years, multimodal information parsing and consistency verification technologies have emerged. For example, Huahui Tomorrow (CN121579422A) has achieved automatic parsing, association, and consistency verification of multimodal information, but its processing object is tender documents, and the output is a consistency verification result, without involving response method classification, evidence chain scoring, contradiction classification, and automatic correction. Fazheng Intelligent (CN120470333A) has implemented multimodal parsing and dynamic weight models, but it is used for tender document deduplication and does not involve compliance assessment and correction suggestions. Jiangsu Equipment Complete Set (CN121504484A) uses multimodal knowledge graphs for tender document compliance review and outputs binary compliance assessment results, without involving contradiction propagation analysis and generative correction. There are also error checking methods for tender documents based on large language models (such as CN120874825A), which construct a knowledge graph of tender requirements, use a large language model for two-round analysis, and output a list of non-compliant items, but do not involve contradiction propagation graphs, cumulative impact coefficients, and risk quantification based on propagation effects. For example, CN121543581B proposes a cross-document semantic consistency verification system, but its processing object is the consistency between different bidding documents, and it does not involve the detection of contradictions and the quantification of propagation risks in multi-source responses within the same bidding document. In addition, although the PageRank algorithm is applied in the fields of fault propagation analysis (such as CN120763534A) and network security assessment (such as CN104348652A), its processing object is physical fault or attack graph, which is fundamentally different from the semantic contradiction detection of bidding responses in this application in terms of technical issues and causal relationship construction methods.

[0005] In the bidding and evaluation of software development projects, the following four types of deep semantic inconsistencies exist in the bid responses.

[0006] (a) Declaration-level contradiction (inconsistency across positions).

[0007] The same technical requirement is contradictory in different sections of the tender document (such as "Technical Solution" and "Performance Design"). For example, Chapter 3 states "Supports MySQL, Oracle, and API interfaces," while the interface list table in Chapter 6 only lists MySQL and Oracle, omitting the API interface. Existing keyword-matching methods can only detect literal differences, failing to understand semantic conflicts or determine the true intent.

[0008] (ii) Cross-modal contradictions (inconsistency between text / image code) There are conflicts in the descriptions of the same technical requirements in text descriptions, architecture diagrams, configuration files, and code snippets. For example, the text states that "the system adopts a microservice architecture," but the architecture diagram shows a monolithic architecture (fewer than 5 components and no API gateway). D3 (Image Multi-Dimensional Consistency Detection System, related application submitted on the same day) has specifically handled image-related conflicts. This application can accept D3's image-text / image-code conflict output as optional input features, while also covering cross-modal conflicts of other modalities such as tables and text.

[0009] (iii) Commitment-fulfillment fracture (across granularity inconsistency) There is a granularity gap between chapter-level strong declarations (such as "fully meets high concurrency requirements") and component-level implementations (no caching, no message queues, no load balancers). This issue overlaps with, but is not entirely the same as, D2's "overcommitment" (triple asymmetric cross-validation system, a related application submitted on the same day) detection. This application focuses on "logical breaks between multi-source responses" (e.g., a declaration being negated by another declaration, or a conflict between conditional and absolute responses). The two can complement each other, and this application can also independently implement granular mapping detection.

[0010] (iv) The chain of contradiction propagation (root contradictions and cascading effects) When a lower-level response is missing, multiple higher-level responses may simultaneously contradict each other, forming a chain of contradictions. For example, the lack of database connection pool configuration (lower level) may cause performance claims to fail to meet standards (higher level), leading to contradictions in multiple performance metrics. This application identifies root cause contradictions by constructing a contradiction propagation graph, calculates the cumulative impact coefficient, and quantifies the cascading risks. Summary of the Invention

[0011] Therefore, it is necessary to provide a bidding conflict detection method and device based on multimodal evidence and conflict propagation graph, which can achieve quantitative assessment of the chain risk of internal conflicts in bidding proposals and intelligent detection of comprehensive risk values, in order to address the above-mentioned technical problems.

[0012] A bid conflict detection method based on multimodal evidence and conflict propagation graph, the method comprising: Obtain the technical requirements from the tender documents and extract evidence of response to the technical requirements from multiple locations, modalities, and granularities of the same tender document.

[0013] Based on technical requirements and response evidence, conflict detection is performed across three dimensions: cross-location, cross-modality, and cross-granularity. This identifies deep semantic conflicts between multiple sources within the same tender document and generates a conflict list.

[0014] Construct a contradiction propagation graph based on the causal relationships between contradictions in the contradiction list. The contradiction propagation graph uses contradictions as nodes and causal relationships as directed edges.

[0015] Based on the contradiction propagation diagram, the cumulative impact coefficient of each contradiction is calculated, and the contradiction density index, which reflects the intensity of contradictions within the bidding proposal, is calculated based on the cumulative impact coefficient.

[0016] Based on the response evidence, calculate the evidence chain integrity score, which reflects the integrity of multimodal technical evidence.

[0017] By integrating the contradiction density index with the evidence chain integrity score, a comprehensive contradiction risk value is calculated, and the comprehensive contradiction risk value and contradiction classification list are output.

[0018] A bid conflict detection device based on multimodal evidence and conflict propagation graph, the device comprising: The response evidence extraction module is used to obtain the technical requirements in the tender documents and extract response evidence to the technical requirements from multiple locations, modalities, and granularities in the same tender documents.

[0019] The contradiction list module is used to perform contradiction detection from three dimensions: cross-location, cross-modality, and cross-granularity, based on technical requirements and response evidence, to identify deep semantic contradictions between multiple source responses within the same tender document and generate a contradiction list.

[0020] The graph construction module is used to construct a conflict propagation graph based on the causal relationships between conflicts in the conflict list. The conflict propagation graph uses conflicts as nodes and causal relationships as directed edges.

[0021] The Conflict Density Index Calculation Module is used to calculate the cumulative impact coefficient of each conflict based on the conflict propagation diagram, and to calculate the conflict density index, which reflects the intensity of internal conflicts in the bidding proposal, based on the cumulative impact coefficient.

[0022] The integrity scoring module is used to calculate an evidence chain integrity score that reflects the integrity of multimodal technical evidence based on the response evidence.

[0023] The detection and evaluation module is used to integrate the contradiction density index with the evidence chain integrity score, calculate the comprehensive contradiction risk value, and output the comprehensive contradiction risk value and contradiction classification list.

[0024] The aforementioned bid conflict detection method and apparatus based on multimodal evidence and conflict propagation graphs extracts response evidence from multiple locations, modalities, and granularities within the same bid document and performs three-dimensional conflict detection across locations, modalities, and granularities. This automatically identifies deep semantic conflicts that are difficult to detect using traditional methods, such as declaration-level conflicts, inconsistencies between text and graphics, and promise-fulfillment breaks. Building upon this, a conflict propagation graph is constructed with conflicts as nodes and causal relationships as edges. The cumulative impact coefficient and conflict density index (CDI) of each conflict are calculated, achieving for the first time a quantitative assessment of the risk of chain propagation of internal conflicts within a bid proposal. This overcomes the limitation of existing technologies, which can only perform binary or classification judgments and cannot quantify cascading risks. Simultaneously, by calculating the evidence chain integrity score, which reflects the integrity of multimodal technical evidence, and weighting and fusing it with the CDI, a comprehensive conflict risk value is obtained. This ensures that the review results are sensitive to both conflict density and evidence integrity, providing experts with a more comprehensive and objective quantitative decision-making basis. This method not only significantly improves the automation and accuracy of bidding and tendering review, reduces omissions and subjective biases caused by manual comparison, but also effectively warns of potential performance risks, achieving a technological leap from "qualitative detection" to "quantitative risk assessment". Attached Figure Description

[0025] Figure 1 This is a flowchart illustrating a bidding conflict detection method based on multimodal evidence and conflict propagation graphs in one embodiment. Figure 2 This is a structural block diagram of a bid contradiction detection device based on multimodal evidence and contradiction propagation graph in one embodiment. Detailed Implementation

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

[0027] In one embodiment, such as Figure 1 As shown, a bid conflict detection method based on multimodal evidence and conflict propagation graph is provided, including the following steps: Step 102: Obtain the technical requirements in the tender documents and extract evidence of response to the technical requirements from multiple locations, modalities, and granularities in the same tender documents.

[0028] Specifically, all technical requirements in the tender documents are obtained to provide a benchmark for subsequent response comparison. Acquisition methods include, but are not limited to: automatic extraction from the tender documents, receipt from a structured data interface, manual input, or import from a historical database. Natural language processing technology, combined with dependency parsing, is used for sub-requirement segmentation.

[0029] Furthermore, the BERT-based sequence labeling model was used to identify paragraphs containing technical requirements from the sections of the tender documents, including "Technical Requirements," "Technical Specifications," "Functional Requirements," "Performance Requirements," and "Safety Requirements." The extraction accuracy rate on 50 tender documents was 86.5%.

[0030] Furthermore, the identified chapters are segmented at the item level. Each technical requirement item is recorded as follows: Requirement ID, Requirement Type (Functionality / Performance / Security / Availability / Scalability), Requirement Description, and Enforceability Level (identified from modal verbs such as "must," "should," and "may," with mapping values ​​of 1.0, 0.66, and 0.33 respectively (example mapping: must / must → 1.0, should → 0.66, may → 0.33; this mapping is only an example and can be adjusted according to business scenarios). For technical requirements containing parallel structures, dependency parsing is used to identify conjunctions such as "," "," "and," "as well as," "and," "or," and "and," to segment out a list of sub-requirements.

[0031] Furthermore, it extracts response evidence for each technical requirement from multiple locations, modalities, and granularities within the tender documents. It integrates multimodal parsing technology to branch text, architecture diagrams, tables, configuration files, and code snippets, and can selectively accept outputs from external systems (such as overcommitment detection results from longitudinal verification systems and image-text inconsistency lists from image consistency detection systems) as prior information.

[0032] Furthermore, the tender documents were identified to include sections potentially containing technical responses: technical solutions, overall architecture, functional implementation, performance design, security design, interface design, deployment plan, and testing plan. Named entity recognition and information extraction techniques based on BERT+CRF were used to extract sentences and paragraphs related to the technical requirements from these sections. The F1 score was 0.84. YOLOv8 was used to detect component types (module boxes, database icons, interface icons, API gateways, etc.) in the architecture diagram, OCR was used to recognize component annotation text, and Hough transform was used to detect the direction of connections and arrows to determine call / dependency relationships. The training was performed on a dataset of 6000 annotated architecture diagrams, achieving an mAP of 0.91. Table structure parsing tools (such as Camelot) were used to extract structured data from the tables, including indicator names, values, and units.

[0033] Furthermore, the configuration files are parsed: application.yml, pom.xml, Dockerfile, etc., to extract service ports, data source configurations, cache configurations, message queue configurations, dependency library versions, etc. Code blocks are identified, and the programming language is determined based on file extensions or code characteristics. An AST parser for the corresponding language is used to extract interface definitions, class names, method signatures, annotations, and configuration parameters.

[0034] Furthermore, the system can receive detection results from external systems (such as longitudinal overcommitment detection systems and image consistency detection systems) as additional evidence input for this step, enriching the feature space for contradiction detection. Even without such information, this step can still independently complete multimodal response extraction. The response information extracted from the different modalities is uniformly stored in a structured format (JSON). When the same information contradicts itself in different modalities (e.g., the text says "microservices" while the architecture diagram shows a monolith), it can optionally be pre-marked as "cross-modal inconsistency" and recorded as a reference feature for contradiction detection, but not as the final judgment criterion.

[0035] Step 104: Based on the technical requirements and response evidence, perform contradiction detection from three dimensions: cross-location, cross-modality, and cross-granularity, identify deep semantic contradictions between multiple source responses within the same tender document, and generate a contradiction list.

[0036] Specifically, it detects response contradictions across locations, modes, and granularities, and can integrate the output of external systems as prior features. The technical approach involves designing detection rules for each of the three types of contradictions, and it can also accept external contradiction inputs.

[0037] Furthermore, cross-location contradiction detection is implemented. Declaration contradictions occur when the same requirement is stated contradictorily in different sections (one section says "supported," while another says "not supported"). Through semantic similarity and negative word detection, a contradiction is identified when the similarity exceeds a preset threshold (0.7 in the example) and one side contains a negative word.

[0038] Functional contradiction: The sets of functions mentioned in different responses are inconsistent. A contradiction is determined when the Jaccard similarity is less than or equal to a preset threshold (0.5 in the example). This threshold is determined based on the analysis of the statistical distribution of the function sets and can clearly distinguish between functional contradiction and functional consistency.

[0039] Indicator contradiction: When the quantitative indicators in different responses are inconsistent and the relative difference exceeds a preset threshold (20% in the example, determined based on the industry's engineering error range), it is judged as a contradiction.

[0040] Furthermore, cross-modal contradiction detection: text-image contradiction: the architectural style described in the text (e.g., "microservices") does not match the architectural style inferred from the architecture diagram. Architectural style inference rules: if the number of independent service modules in the architecture diagram is ≥3 and there is an API gateway or service registry, it is determined to be a microservice architecture; otherwise, it is determined to be a monolithic or SOA architecture.

[0041] Text-table discrepancy: The performance metrics declared in the text do not match the quantitative metrics filled in the table.

[0042] Text-code contradiction: The technology stack or configuration requirements declared in the text do not match the implementation in the configuration file / code snippet.

[0043] Image-table discrepancy: The number of components in the architecture diagram does not match the number of modules listed in the table.

[0044] Image-code discrepancy: The components in the architecture diagram do not match the service definitions in the configuration file.

[0045] In addition, the image-text contradiction list and image-code contradiction list output by the external image consistency detection system can be directly received as optional input features for this step.

[0046] Furthermore, cross-granularity conflict detection: Granularity mapping rules: Pre-constructing the mapping relationship from declarative-level concepts to component-level implementation elements. Granularity mapping rules can be implemented based on one or more of the following methods: knowledge base, rule base, case matching, or machine learning model. A preferred implementation uses a granularity mapping knowledge base, for example, "high concurrency" is mapped to {caching components, message queues, load balancers, connection pools}; "high availability" is mapped to {cluster deployment, session replication, failover, health checks}.

[0047] The construction method of the granular mapping knowledge base is as follows: (1) manual rule entry based on software architecture design patterns; (2) automatic learning from historical review cases through association rule mining: using Apriori or FP-Growth algorithms, the minimum support is preset to 0.05 and the minimum confidence is 0.7. The rules mined are entered into the database after being reviewed by experts; (3) reasoning expansion combined with domain knowledge graph. The knowledge base supports incremental updates. When an undefined mapping appears in a new project, the system records the manual confirmation result and adds it to the database.

[0048] Granularity consistency check: If a chapter-level declaration exists but the corresponding implementation element is missing at the component level (based on granularity mapping rules), it is determined to be a granularity contradiction; if there is no declaration at the chapter level but there is an implementation at the component level, it is marked as an implicit capability (refer to the output of the external system).

[0049] Furthermore, the system integrates conflict aggregation with external information: overcommitment detection results (strong claims but weak architecture) from external systems are used as supplementary evidence for "commitment-fulfillment disconnect" type conflicts. Each conflict record includes: conflict ID, conflict type, involved requirements, involved response locations (multimodal, multi-location), and a preliminary label of conflict severity (high / medium / low, for subsequent model refinement).

[0050] Specifically, each response is classified based on detected technical evidence (rather than pure text rules), and the raw quality score is quantified. The technical approach is to determine the quality based on a combination of textual claim strength and the presence of multimodal evidence. For each technical requirement, the evidence extracted from each modality is summarized: (1) Textual evidence: Does the declaration statement exist? (2) Code evidence: Does the corresponding implementation code annotation and configuration parameters exist? (3) Architecture diagram evidence: Does the corresponding component or relationship exist? (4) Tabular evidence: whether there are corresponding indicators or list items.

[0051] Furthermore, the five-level classification rules are formulated as shown in Table 1: Response type Judgment conditions Raw quality score (default cold start value) Direct and explicit response Text declaration + detection of specific implementations in configuration files or code 0.9 Indirect proof response The textual declaration and architecture diagram show the corresponding component (or the table shows the corresponding item), but there is no code / configuration evidence. 0.8 Implicit Response Only keywords appeared, but no specific implementation was detected in any technical modality. 0.5 Partial Response The number of covered sub-requirements is less than the total number of sub-requirements, and there is no corresponding evidence for the missing sub-requirements in the technical modality. 0.4 × Coverage Ratio (Coverage Ratio = Number of Matched Sub-requirements / Total Number of Sub-requirements) Deviation response If the semantic similarity is less than a preset threshold (0.5 in the example), or if the detected technical evidence is significantly inconsistent with the requirements. 0.2 The thresholds mentioned above (0.5, 0.4, 0.2, etc.) are example values ​​and can be dynamically adjusted based on the actual data distribution after system deployment. For partial responses, based on the sub-requirement segmentation results, each sub-requirement is verified one by one to see if there is technical evidence to support it in any modality. The output includes the coverage ratio and a list of missing sub-requirements.

[0052] Step 106: Construct a contradiction propagation graph based on the causal relationships between contradictions in the contradiction list. The contradiction propagation graph uses contradictions as nodes and causal relationships as directed edges.

[0053] Specifically, a causal propagation graph of contradictions is constructed, the cumulative influence coefficient α is calculated, and then the contradiction density index (CDI) is calculated. The technical approach is to construct a directed graph based on the dependencies between contradictions and use the weighted PageRank algorithm to calculate the cumulative influence coefficient.

[0054] Further, contradiction feature extraction and normalization are performed. For each detected contradiction, the following feature vector is extracted and processed using Min-Max normalization: (1) Contradictory type (converted to one-hot encoding); (2) The number of modes involved (normalized to [0,1]); (3) Number of missing architectural elements (with the total number of expected architectural elements as the denominator); (4) Declare strength difference (difference, if available from an external system); (5) Cross-granularity depth (max(|original requirement granularity layer - implementation granularity layer|) / maximum number of granularity layers, in the example, the maximum number of granularity layers is 4). (6) The degree of mandatory nature of the bidding requirements (using the mandatory nature mapping value).

[0055] Furthermore, the contradiction propagation graph is constructed and causal relationships are identified. Using contradictions as nodes V and causal relationships as directed edges E, a contradiction propagation graph G=(V,E) is constructed. The causal relationship identification method is as follows: (1) Based on a predefined technology dependency knowledge base: This knowledge base stores the dependency relationships between common technical elements in software engineering. For example: missing cache → high concurrency cannot be supported → response latency exceeds the standard; missing message queue → insufficient asynchronous processing capability → peak shaving and valley filling failure; missing configuration center → service configuration cannot be uniformly managed → runtime configuration conflict. Each dependency rule includes the premise contradiction type, the result contradiction type, and the causal strength weight (value range 0.8-1.0).

[0056] (2) Automatic extraction based on dependency parsing (optional enhancement): From the technical requirements description in the tender document, dependency parsing is used to identify relational words such as "dependence", "requirement" and "based on", and the dependency relationships between technical elements are automatically extracted and added to the knowledge base.

[0057] (3) Causal relationship determination rule: If the missing technical element reflected by contradiction A (i.e., the technical component or configuration that is not satisfied in contradiction A) is a prerequisite for the realization of a certain function in contradiction B (i.e., there is a dependency rule in the knowledge base from the missing element to the related function of contradiction B), then a directed edge A→B is established. The edge weight is the causal strength predefined in the knowledge base.

[0058] (4) Special cases of propagation graph: When there is an isolated node (without any incoming or outgoing edges), its cumulative influence coefficient α is equal to its initial contradiction level weight. When there is a circular dependency, the minimum fixed point solution method is adopted, and the maximum number of iterations is set in the iterative calculation (100 times in the example) to ensure convergence.

[0059] Furthermore, the cumulative influence coefficient α is calculated (weighted PageRank). To address potential circular dependencies and sparse graph structures in the conflict propagation graph of bidding responses, this application employs a weighted PageRank algorithm with adaptive adjustment of the damping coefficient (see formula below), enabling the algorithm to effectively handle conflict propagation graphs of varying densities. This adaptation scheme differs from the conventional applications of PageRank in fault propagation or network security.

[0060] The cumulative impact coefficient of each conflict is calculated iteratively using the weighted PageRank algorithm. The damping coefficient takes values ​​within a preset range or is adaptively adjusted based on the density of the contradiction propagation diagram. One selectable preset range is 0.7 to 0.95. One possible adaptive adjustment algorithm is as follows: ,in , . The number of conflicting nodes. Let be the number of directed edges. The density of the contradiction propagation graph is defined as follows: (when (time), if (If there is only one contradictory node), then define . This is the adjustment factor (2.0 in the example). When When the size is small (the graph is sparse). Values ​​close to the lower limit To reduce the impact of the initial weights; when When the size is large (the graph is dense). The value is close to the upper limit. To strengthen the weight of the propagation effect. An optional default value is... =0.85 (without adaptive mode), this value is determined based on experimental optimization.

[0061] The above , , The values ​​provided are for illustrative purposes and were determined based on experimental optimization. Those skilled in the art can adjust this range of values ​​according to the density distribution of actual contradiction propagation diagrams, which does not constitute a limitation of the present invention.

[0062] node The initial weights are the conflict level weights. The conflict level weights are determined from at least three independent sources: (1) rule-based cold start level classification (see cold start rules); (2) dispute prediction model output (optional enhancement); and (3) expert-preset rules. When the dispute prediction model is unavailable (e.g., during the cold start phase), rule-based conflict level classification is used. Iteration formula:

[0063] Iterate until convergence (the change is less than a preset threshold, for example, take...). (or reaches the maximum number of iterations (100 in this example).) This represents the process from node [node name] in the contradiction propagation graph. To the node A directed edge; For the edge The causal strength weight (the value is usually between 0.8 and 1.0). For nodes The cumulative impact coefficient (calculated by weighted PageRank iteration); For nodes The outgoing degree, that is, from The total number of directed edges from which a starting point is reached.

[0064] Handling nodes with an out-degree of zero: If the node out of degree Then its weight Distribute evenly to all nodes in the graph (including itself), that is, for each node... Contribution item is This processing is equivalent to processing the node. Add virtual edges pointing to all nodes (each virtual edge has a weight of 1). This ensures that the iteration converges and that all nodes receive propagation weights fairly.

[0065] Furthermore, the contradiction density index (CDI) is calculated as follows:

[0066] in The total number of responses is represented by the number of response evidence items corresponding to all technical requirements (independent response items after cross-modal deduplication). For the first The CDI (Consumption-Induced Dispute) is the cumulative impact coefficient of each conflict. It is calculated by summing the cumulative impact coefficients of each conflict and then dividing by the total number of responses, reflecting the overall conflict density and propagation risk of the project. Empirical studies on the CDI value range and project failure rate show that the higher the CDI value, the denser the internal conflicts of the project, and the significantly increased the performance risk. The typical CDI value range is [0, 0.5], and an additional risk deduction is triggered when it exceeds a preset threshold (0.2 in the example).

[0067] Furthermore, the dispute prediction model incorporates a cold-start rule for conflict grading (optional enhancement). Optionally, a dispute prediction model (logistic regression or random forest) can be constructed, inputting a conflict feature vector (including conflict type, number of involved modalities, number of missing structural elements, difference in claim strength, degree of mandatory bidding requirements, conflict propagation graph depth, etc.), and outputting a dispute risk probability p∈[0,1]. Grading rules: p≥0.7 indicates a fatal conflict, 0.4≤p<0.7 indicates a serious conflict, and p<0.4 indicates a general conflict. Five-fold cross-validation is employed. All 200 samples (80 dispute cases + 120 non-dispute cases) are randomly divided into 5 equal parts, with 4 parts used as the training set and 1 part as the validation set each time, repeated 5 times. The AUC is the average and standard deviation of the 5 results, which is 0.87±0.03. During model training, all parameter selections are based on the cross-validation results; no separate test set is created to prevent data leakage.

[0068] When the dispute prediction model is unavailable (e.g., during the cold start phase or without labeled historical data), a rule-based conflict level classification is used: Fatal contradiction: The number of missing architectural elements is ≥2 and the bidding requirements are "mandatory" (mandatory mapping value ≥0.8). Serious contradiction: The number of missing architectural elements is 1 and the mandatory level is "should" (mapping value 0.66~0.8), or the number of missing elements is ≥2 but the mandatory level is "allowable" (mapping value ≤0.5); General contradictions: other situations.

[0069] This rule and the dispute prediction model form a two-stage switching process of "rule → model". After accumulating enough training data (for example, after accumulating 50 dispute cases), it automatically switches to model prediction mode.

[0070] Furthermore, based on the detected contradictions and their classification results, natural language correction suggestions are dynamically generated to replace the predefined template library. The technical approach involves using Retrieval-Enhanced Generation (RAG) technology, combined with a historical case library, inputting contradictory context, and outputting natural language correction suggestions.

[0071] Furthermore, a historical amendment case library is constructed. Pairs of "conflict description + amendment suggestion" are collected from historical review reports. Each data entry includes: conflict type, original tender requirements, original bid response, a list of missing elements, expert-written amendment suggestions, and the acceptance results after the suggestions were adopted. The case library sources include: amendment suggestions from real tender documents, simulated conflict generation examples, and content extracted from historical dispute arbitration case handling opinions. The total case library is recommended to be no less than 800 entries, covering more than 25 conflict types.

[0072] Furthermore, the base model and fine-tuning strategy are discussed. This application does not limit the specific model type. One optional implementation uses a Transformer-based pre-trained large language model (such as ChatGLM, LLaMA, etc.) for fine-tuning via LoRA low-rank adaptation (example parameters: rank=8, alpha=16, learning_rate=2e-5). Alternatively, the base model can be used directly for RAG inference without fine-tuning to reduce implementation costs.

[0073] Furthermore, the construction and retrieval of prompt terms are enhanced. For each conflict to be processed, prompt terms containing the following information are constructed: conflict type and level, original text of the tender requirements, relevant fragments of the bid response (marked location), missing elements or conflict details, and summary of the chain of evidence (which modalities are consistent and which are inconsistent).

[0074] The system retrieves Top-K similar cases (Top-3 in this example) from the historical case database using BERT similarity. The similarity threshold is set to a configurable value (0.65 in this example; cases below this threshold are not used for retrieval and are generated directly). The retrieved similar cases are then embedded as examples into the prompt words (few-shot learning). The similarity threshold can be dynamically adjusted based on subsequent feedback data.

[0075] Further, the process involves de-illusioning. Location validity verification: A regular expression-based page number and figure number extraction method is used to extract all mentioned page number and figure number strings (such as matching patterns like "Page X", "Figure Y", "Figure Z") from the generated natural language text. These are then compared one-to-one with the recorded evidence location index. If any extracted location does not match any record in the index, the location validity verification fails.

[0076] Element rationality verification: A technical component extraction method based on Named Entity Recognition (NER) is adopted to extract all technical component names (such as "Redis cluster", "Nginx", etc.) from the generated suggestions and match them with the standard component names in the granular mapping knowledge graph. If any extracted component does not exist in the knowledge graph (or does not match the requirement type), it is determined that the element rationality verification fails.

[0077] Confidence Threshold: Sets the output probability threshold for the generative model (0.7 in the example). The generation confidence is the output probability of the generative model, and this threshold is determined based on ROC analysis of the output probability distribution of expert-adopted and non-adopted samples in historical revision suggestions (AUC≈0.92). When the value falls below the threshold, secondary generation is triggered (generation parameters can be adjusted, such as reducing the temperature parameter to 0.6, increasing the generation length, etc.). If the secondary generation is still below the threshold, it falls back to the backup template library. The backup template library retrieves high-quality revision suggestions with similarity higher than the preset threshold (0.8 in the example) from the historical case library. If none are found, a predefined general template is used (containing standard suggestions such as "Please supplement the missing technical elements" and "Please check the consistency between the statement and the implementation"). The above thresholds are all exemplary values ​​and can be dynamically learned and optimized based on actual data after system deployment.

[0078] Furthermore, priority ranking and output are implemented. Critical contradictions are marked as "must be corrected," serious contradictions as "suggested correction," and minor contradictions as "optional optimization." Each suggestion is accompanied by a confidence score (based on the output probability of the generative model and the adoption rate of historical similar cases).

[0079] Step 108: Calculate the cumulative impact coefficient of each contradiction based on the contradiction propagation diagram, and calculate the contradiction density index, which reflects the intensity of contradictions within the bidding proposal, based on the cumulative impact coefficient.

[0080] Step 110: Calculate the evidence chain integrity score, which reflects the integrity of multimodal technical evidence, based on the response evidence.

[0081] Specifically, the calculation of the evidence chain integrity score employs a two-stage weight determination strategy: the initial stage uses preset default weights based on expert surveys, and after accumulating sufficient data, it switches to a weight learning mechanism based on information entropy (periodically calculating fixed weights based on historical consistency probability). The technical approach is as follows: the initial default weights are determined by domain experts using the Analytic Hierarchy Process (AHP); once the number of historical items reaches a preset threshold (N≥100 in this example), the weights for each modality are automatically learned based on the information entropy method.

[0082] Furthermore, a default weight is preset (cold start phase): the default weight is determined based on an AHP questionnaire survey of experts with bidding review experience, with a consistency ratio (CR) < 0.1, to determine the initial weight of each modality. An optional weight configuration is: configuration file 0.40, code snippet 0.30, table 0.15, architecture diagram 0.10, and text 0.05. These values ​​are merely examples and do not constitute a limitation on the scope of protection. The preset default weight in claim 3 is determined by the AHP method and is not limited to the values ​​in this example; it can be re-determined using the AHP method according to the business scenario.

[0083] Historical Data Collection and Consistency Labeling: Collect tender documents and corresponding final acceptance results from N historical projects (N reaches a preset threshold; in this example, N≥100 is used to obtain stable weights). For each project, label whether the modal evidence is consistent with the final implementation. The judgment criteria are as follows: (1) Configuration file: Configuration parameters that completely match the final deployment configuration are considered to be consistent; (2) Code snippets: Key interfaces that are consistent with the final implemented functions are considered consistent; (3) Architecture diagram: Key components that exist and have correct relationships are considered consistent; (4) Table: If the deviation between the index value and the measured value is within the predetermined range (for example, within 20%), it is considered consistent; (5) Text: If the semantic similarity between the technical statement and the final implementation is greater than the preset threshold (0.8 in the example) and does not contain contradictory or negative statements, they are considered to be consistent.

[0084] Modal consistency probability calculation: For each mode Calculate its consistency probability:

[0085] Information entropy and weight calculation (dynamic update stage): modality The amount of information is Weights are inversely proportional to the amount of information; normalization:

[0086] in, This is a collection of all modalities (text, architecture diagrams, tables, configuration files, code snippets). Traversing a collection Each mode in it.

[0087] Furthermore, the calculation of the chain of evidence integrity score and the handling of missing modalities: For the current bidding proposal, the original value of the chain of evidence integrity score is:

[0088] in, For modality Fixed weights (sum of all modal weights) (This is a constant; in the example, configuration file 0.40 + code 0.30 + table 0.15 + architecture diagram 0.10 + text 0.05 = 1.0). ; For modality The completeness of evidence (1 for evidence that exists and is consistent, 0 for evidence that exists but is inconsistent, and a percentage value for evidence that exists partially). This represents the confidence score for modality detection (accuracy based on the analytical model). When a modality is completely missing, its... This mode does not contribute to the score. The weights of the remaining modes... Remain unchanged and do not renormalize.

[0089] The final score for the completeness of the chain of evidence is:

[0090] If all modes exist and are completely consistent, then , If a certain mode is completely missing, even if all other modes are complete and identical, , This should reasonably reflect the punishment for lack of evidence.

[0091] Specific implementation: If the configuration file (weight 0.40) is completely missing, but all other modalities are complete and identical, then , , Compared to the perfect score of 1.0 when no evidence was missing, the score decreased by 0.40, which correctly reflects the risk of missing key evidence.

[0092] It is worth noting that in this step, the weights of each mode... Within the current scoring period, all projects and all technical requirements remain fixed and are not dynamically adjusted based on the specific technical characteristics of the current project. This is because the design goal of the information entropy weights is to statistically summarize the average credibility of each modality in historical projects, rather than capturing the modal credibility differences between different technical requirements within the same project—the latter has been compensated for by the propagation analysis in steps 104 (contradiction detection) and 106 (contradiction propagation graph). Experiments show that this fixed weight scheme has better consistency with human scoring (Kappa=0.81) than the simulated "project-level dynamic weight" scheme (Kappa=0.73), which introduces unnecessary noise due to data sparsity.

[0093] Furthermore, the weights are updated periodically, and a cold start contingency plan is implemented: After processing a preset number of new projects (100 in the example) or after each preset time period (quarter in the example), whichever comes first, the iteration step is re-executed to update the weights. This enables cross-cycle weight optimization.

[0094] Step 112: Integrate the contradiction density index with the evidence chain integrity score to calculate the comprehensive contradiction risk value, and output the comprehensive contradiction risk value and contradiction classification list.

[0095] Specifically, all test results are integrated to output a visualized report. The comprehensive risk value is used to assess the overall degree of contradiction risk in the bidding proposal, and is obtained by fusing the Contradiction Density Index (CDI) and the Evidence Chain Integrity S_evidence_norm.

[0096] CDI stands for Contradiction Density Index. The normalized chain of evidence integrity score is given (values ​​[0,1]). The fusion weight ranges from 0.5 to 0.7 and can be configured according to the business scenario. The default recommended value is... =0.6 (determined based on correlation analysis of CDI and chain of evidence scores in historical samples).

[0097] The higher the overall risk value, the greater the risk of internal contradictions in the bidding proposal, and the corresponding increase in performance risk. When generating the review report, the overall risk value can serve as an important basis for the overall risk rating.

[0098] Furthermore, the report content is organized as follows: The report content includes: a list of technical requirements and a summary of responses (including five-level classification results), the compliance level and overall score for each technical requirement, the chain of evidence integrity score, a list of contradiction levels and CDI, a list of corrective suggestions compiled from the outputs (including priority and related evidence), and key areas of concern (non-compliance items, deviations, and contradictions).

[0099] Furthermore, the presentation is visualized: the response summary is displayed in tabular form, and the conflict level is indicated by color (red for fatal, yellow for severe, and blue for moderate), with the location of missing elements highlighted.

[0100] Furthermore, the adoption status of the review experts' suggestions and the final project acceptance results are fed back to each model to achieve continuous learning. The technical approach involves recording feedback signals, periodically retraining or fine-tuning the weight model, dispute prediction model, and generative suggestion model, and updating the knowledge graph. The closed-loop feedback cycle can use an example value (e.g., 90 days or every 300 new projects processed, whichever comes first). This value is an example configuration parameter and can be dynamically adjusted according to actual deployment conditions.

[0101] Feedback signal acquisition The reviewers marked each suggested revision as: adopted / not adopted / partially adopted; If the suggestion is not adopted, record the reason (e.g., "the suggestion is impractical", "the location is wrong", "there are other solutions already available"). Final project acceptance results (success / failure) and any disputes that occurred.

[0102] Furthermore, the evidence chain weight model is updated (in two stages): Cold start phase (the number of historical projects has not reached the preset threshold, for example, N<100): Maintain the fixed default weights and do not update.

[0103] Dynamic Phase (Number of historical projects reaches a preset threshold, example N≥100): Whenever a preset number of new projects are processed (example 100) or a preset time period (example quarter), whichever comes first, steps 104-106 are re-executed based on the latest feedback data to calculate the consistency probability of each modality. and amount of information Update weights .

[0104] Furthermore, the feedback signal classification and weight fine-tuning mechanism: During daily operation, the weights are fine-tuned in real time based on the feedback signals from review experts. The accumulated fine-tuning results will be incorporated into the next periodic recalculation. Feedback is divided into two categories: (1) Hard feedback: Acceptance failure cases or weight deviation corrections confirmed by experts. This type of feedback is forcibly included in the training set, triggering a significant weight adjustment. Specifically, when hard feedback occurs, the weights of the relevant modes are adjusted in fixed steps. Make corrections (example taken) The sample is then added to the historical dataset for recalculation of the periodic weights in the next cycle.

[0105] (2) Soft Feedback: Records of expert adoption of corrective suggestions (adopted / partially adopted / not adopted). This type of feedback is only used for fine-tuning the current weights and is not mandatory for inclusion in the training set. For each piece of soft feedback, if the expert adopts a suggestion related to the modality... If the suggested correction is made, the weights of the mode will be fine-tuned according to the following formula: .in, Fine-tune the step size based on the baseline (0.01 in the example). For modality Historical adoption rate bias is defined as:

[0106] when When the historical adoption rate of this modality is higher than average, its weight is increased (to improve credibility); when If necessary, reduce the weight of each modality. The fine-tuned weights must ensure that the sum of all modal weights remains 1 (through renormalization).

[0107] Cumulative feedback triggers a forced update: When the same modality experiences 10 consecutive soft feedbacks, and each time... If the signs are the same (both positive or both negative), a hard feedback-level forced update (i.e., updating in fixed steps) is triggered. Adjust the weights), and clear the soft feedback counter for that mode.

[0108] Weight range constraint: The weight of any modality after adjustment shall not be lower than the preset lower limit (0.01 in the example) or higher than the preset upper limit (0.60 in the example) to ensure the rationality of the weight.

[0109] The above parameters ( , (Lower limit 0.01, upper limit 0.60, consecutive count 10) are all example values. In actual deployment, they can be dynamically adjusted according to the statistical distribution of feedback data.

[0110] Furthermore, the dispute prediction model is updated. Newly occurring dispute cases and their conflict characteristics are added to the training set, and the dispute prediction model is retrained to optimize the grading threshold and feature weights. An incremental learning strategy is adopted to retain the core distribution of old samples and avoid catastrophic forgetting.

[0111] Furthermore, the generative suggestion model is fine-tuned. High-quality revised suggestions adopted by review experts are used as positive samples, and suggestions not adopted are used as negative samples to incrementally fine-tune the base large language model (LoRA). At the same time, the adoption rate is fed back to adjust the similarity threshold of RAG retrieval.

[0112] Furthermore, the knowledge graph is updated. For conflicts caused by missing implicit requirements, the confirmed "requirement type → implicit constraint" pair is added to the knowledge graph with an initial confidence level of 0.7. The confidence decay coefficient is then adjusted based on project feedback. The granular mapping knowledge base also supports incremental updates: when there are uncovered granular mappings in a new project, the manually confirmed mapping relationships are recorded, and after a preset number of confirmations (3 in this example), they are automatically added to the database.

[0113] The aforementioned bid conflict detection method based on multimodal evidence and conflict propagation graphs extracts response evidence from multiple locations, modalities, and granularities within the same bid document and performs three-dimensional conflict detection across locations, modalities, and granularities. This automatically identifies deep semantic conflicts that are difficult to detect using traditional methods, such as declaration-level conflicts, inconsistencies between text and graphics, and promise-fulfillment breaks. Building upon this, a conflict propagation graph is constructed with conflicts as nodes and causal relationships as edges. The cumulative impact coefficient and conflict density index (CDI) of each conflict are calculated, achieving for the first time a quantitative assessment of the risk of chain propagation of internal conflicts within the bid proposal. This overcomes the limitation of existing technologies, which can only perform binary or classification judgments and cannot quantify cascading risks. Simultaneously, by calculating the evidence chain integrity score, which reflects the integrity of multimodal technical evidence, and weighting and fusing it with the CDI, a comprehensive conflict risk value is obtained. This ensures that the review results are sensitive to both conflict density and evidence integrity, providing experts with a more comprehensive and objective quantitative decision-making basis. This method not only significantly improves the automation and accuracy of bidding and tendering review, reduces omissions and subjective biases caused by manual comparison, but also effectively warns of potential performance risks, achieving a technological leap from "qualitative detection" to "quantitative risk assessment".

[0114] In one embodiment, a predefined technology dependency knowledge base is obtained, which stores the dependency relationships and causal strength weights between technical elements in software engineering. If a dependency rule exists in the technology dependency knowledge base from the missing technical element reflected in the first contradiction to the functional implementation of the second contradiction, then a directed edge is established from the first contradiction to the second contradiction, and the causal strength weight is assigned to each directed edge. Using all detected contradictions as nodes and the directed edges as edges, the contradiction propagation graph is constructed according to the causal strength weights.

[0115] In one embodiment, a feature vector is extracted for each conflict. This feature vector includes the conflict type, the number of modalities involved, the number of missing architectural elements, the difference in assertion strength, the depth across granularities, and the degree of mandatory nature of the bidding requirements. The feature vector is then input into a weighted PageRank algorithm to iteratively calculate the cumulative impact coefficient for each conflict.

[0116] in, Let be the cumulative impact coefficient of the j-th contradiction. To control the propagation ratio of each node's weight in the contradiction propagation graph during the iteration process, For the edge Causal strength weight, Let be the cumulative impact coefficient of the i-th contradiction. From The total number of directed edges originating from the node. The initial weights of the nodes are determined based on the conflict hierarchy, and the damping coefficients are adaptively adjusted according to the conflict propagation graph density.

[0117] In one embodiment, during the cold start phase, preset default weights determined based on the analytic hierarchy process (AHP) are used as the initial fixed weights for each modality. Once the accumulated number of historical projects reaches a preset threshold, the system switches to dynamic learning weights based on information entropy, calculating the information content of each modality based on the consistency probability between the evidence from each modality and the final acceptance result.

[0118]

[0119] in, For modality The amount of information, For modality The consistency probability. The weights are updated to normalized values ​​inversely proportional to the amount of information:

[0120] in, These are the normalized weight values. For the set of all modalities, For traversing the set For each modality in the dataset, calculate the chain of evidence integrity score based on the normalized value:

[0121]

[0122]

[0123] in, This is the original value for the chain of evidence integrity score. For the completeness of valid evidence for modality m, For modality The completeness of evidence is determined by a value of 1 if the completeness of evidence exists and is consistent, and 0 if the completeness of evidence exists but is inconsistent. Scoring for the completeness of the chain of evidence. The sum of the normalized weights for all modes. This represents the confidence level for modal detection.

[0124] In one embodiment, the contradiction density index is fused with the evidence chain integrity score to calculate a comprehensive contradiction risk value:

[0125]

[0126] in, To comprehensively assess the risk of contradictions, To integrate weights, Scoring for the completeness of the chain of evidence. The contradiction density index, This represents the total number of responses. For the first The cumulative impact coefficient of each contradiction is calculated. The overall contradiction risk value and contradiction classification list are output.

[0127] In one embodiment, based on retrieval-enhanced generation technology, similar contradictions are retrieved from a historical case database. Hint words containing the contradiction type, the original text of the tender requirements, fragments of the bid response, and missing elements are constructed and input into a pre-trained large language model to dynamically generate natural language correction suggestions. The generated correction suggestions undergo de-illusion verification, including verifying that the cited locations are consistent with the evidence chain and that the mentioned technical components exist in the knowledge graph. The adoption status of the correction suggestions by review experts and the final project acceptance results are used as feedback signals, updated at different intensities to the evidence chain weight model and the knowledge graph, achieving continuous optimization of model parameters.

[0128] In one embodiment, a task for cross-modal semantic inconsistency detection and correction is provided, and the detection content of the task is as follows: Project Background: A cloud platform project's tender requirement is that "the system must support access to multiple data sources (MySQL, Oracle, and API interfaces)."

[0129] The tender proposal states in Chapter 3, the technical solution, that it "fully meets the requirements for accessing multiple data sources"; in Chapter 6, the function implementation table lists "MySQL and Oracle" but does not include API interfaces; the configuration file does not contain any API interface-related configurations.

[0130] Processing procedure: Step 1: Extract text declarations and tables; configuration files are missing.

[0131] Step 2 determined it to be a partial response (coverage ratio 0.67), with an original quality score of 0.268.

[0132] Step 3: Evidence chain scoring: Text 0.05 + Table 0.15 = 0.20, configuration file missing. (The weight of missing configuration file is 0.40 out of a possible 1.0).

[0133] Step 4 detected a text-table contradiction (the declaration is fully satisfied vs. the table lacks an API interface) and marked it as a cross-modal contradiction.

[0134] Step 5: Conflict Feature Extraction (Conflict Type Encoding, Number of Modalities Involved = 2, Number of Missing Elements = 1). The dispute prediction model p = 0.45, classifying it as a serious conflict. The initial depth of the propagation graph is 0, and α = initial conflict level weight (severe conflict corresponds to an example value of 0.5). The total number of responses for this project is 5 (i.e., there are 5 technical requirements, this conflict corresponds to one of them, and the other 4 are not contradictory), CDI = 0.5 / 5 = 0.1.

[0135] Step 6 generates correction suggestions: "The declaration in Chapter 3 is fully satisfied, but the table in Chapter 6 only lists MySQL and Oracle, and does not include the API interface. Suggestion: Option 1, if the API interface is actually supported, please add the table and update the configuration file; Option 2, if it is not actually supported, please modify the declaration." Step 7: Experts adopted Solution 1, and the project was successfully accepted. Feedback signals updated the weight model, and this case was added to the fine-tuning dataset.

[0136] In one embodiment, a task for detecting and correcting cross-granularity logical inconsistencies is provided, and the detection content of the task is as follows: Project Background: The tender requirement is that "the system must support high concurrency access (QPS≥5000)".

[0137] The bidding proposal states in Chapter 3 that it "fully meets the high concurrency requirements and can reach 8000 QPS after stress testing"; the architecture diagram in Chapter 4 shows only one application server and one database server, without caching, message queues, or load balancers.

[0138] Processing procedure: Step 1: Extract the text declaration (strength 0.95) and architecture diagram components.

[0139] Step 2 is determined to be a direct and explicit response (with a textual statement but no code / configuration evidence, original quality score 0.8).

[0140] Step 3 Evidence Chain Score: Text 0.05 + Architecture Diagram 0.10 × 0 = 0.05, extremely low score.

[0141] Step 4 detected inconsistencies in cross-granularity logic. In the granularity mapping rules, "high concurrency" is mapped to {caching components, message queues, load balancers, connection pools}, all of which are missing from the architecture diagram.

[0142] Step 5: Contradictory characteristics: 3 missing architectural elements, with a mandatory level of "must". Based on the rule-based cold start level classification, this is determined to be a fatal contradiction (2 or more missing elements and a mandatory level of "must"), α=1.0, CDI=1.0 / 5=0.2 (assuming the total number of responses for this project is 5).

[0143] Step 6 generates correction suggestions: "The statement claims support for 8000 QPS, but the architecture diagram lacks caching, message queues, and load balancing. It is recommended to add Redis cluster, RocketMQ, and Nginx, or reduce the statement strength." Step 7: The experts adopted Option 1 and requested the bidder to clarify. The bidder was unable to provide any clarification and ultimately did not win the bid.

[0144] In one embodiment, a task involving a contradiction propagation graph and the cumulative effect of CDI is provided. The detection content of the task is as follows: Project Background: A microservice architecture project, the bidding requirements include "support for automatic service registration and discovery", "support for configuration center" and "support for API gateway".

[0145] The bidding proposal states "using Spring Cloud microservice architecture" in the text; however, the architecture diagram only shows three directly connected service modules, with no API gateway and no registry center. Contradictions include: Contradiction A (textual microservices vs. directly connected architecture diagrams), Contradiction B (no API gateway), and Contradiction C (no registry center). The contradiction propagation relationship is: A→B, A→C (the lack of a microservice architecture leads to the absence of an API gateway and registry center).

[0146] Processing procedure: (Steps 1-3 are the same as in the two embodiments above) Step 4 detected contradictions A, B, and C. The causal relationship knowledge base contains the rules: "Missing microservice architecture → Missing API gateway" and "Missing microservice architecture → Missing service registry."

[0147] Step 5: Construct the propagation graph: Nodes A, B, and C, with directed edges A→B and A→C. Perform a weighted PageRank iteration (d is adaptively adjusted; calculated based on ρ=2 / 9≈0.22, d≈0.78). Initially, A has a fatal weight of 1.0, and B and C have severe weights of 0.5. After iteration, α_A=1.0, α_B=0.78, and α_C=0.78. Assuming the project has 10 technical requirements (response items), then CDI=(1.0+0.78+0.78) / 10=2.56 / 10=0.256. This value exceeds the preset threshold of 0.2, triggering additional risk deduction and indicating a high risk of conflict propagation in the solution.

[0148] Step 6 generates integration and correction suggestions: "An architectural style conflict (microservices vs. direct connection) has been detected, resulting in the absence of API Gateway and Service Registry. It is recommended to refactor the architecture diagram and add Spring Cloud Gateway and Nacos components." Step 7 outputs correction suggestions.

[0149] In one embodiment, a conflict detection task that collaborates with an external system is provided. The detection content of the task is as follows: Project Background: In a project bidding proposal, an external longitudinal verification system (D2) detected "overcommitment" (claiming 8000 QPS but lacking architectural support); an external image consistency check system (D3) detected "image-text contradiction" (text describes microservices, but the architecture diagram shows monoliths). This example demonstrates how to optionally receive these outputs as input.

[0150] Processing procedure: (Steps 2-3 here are the same as in the three embodiments above) In step 1 of this embodiment, you may optionally receive the overcommitment results and the list of graphic contradictions output by an external system.

[0151] In step 4, contradiction detection, overcommitment is used as evidence of "commitment-realization rupture" type contradictions, and text-image contradictions are used as input for cross-modal contradictions.

[0152] Step 5: The input features of the dispute prediction model include feature dimensions from external systems, which improves the accuracy of conflict classification.

[0153] The final CDI calculation result incorporated evidence from multiple sources, and the overall risk was determined to be high.

[0154] When generating correction suggestions in step 6, output evidence from external systems is referenced to form a cross-system collaborative evidence chain.

[0155] It should be noted that this embodiment is only an optional enhanced implementation. The core solution of this invention does not depend on the output of any external system, and can still independently complete the entire process from multimodal response extraction to contradiction detection, propagation graph construction, risk quantification, and correction suggestions even when no such information is received.

[0156] In one embodiment, a closed-loop feedback and model update task is provided, and the detection content of the task is as follows: Project Background: Following a project review, experts adopted some of the suggested revisions generated by this system, and the project was successfully accepted. The closed-loop feedback cycle is assumed to be 90 days.

[0157] Processing procedure: (Steps 1-6 here are the same as in the three embodiments above) Step 7: Collect feedback signals: The suggestion to "supplement Redis configuration" was adopted, but the suggestion to "add a message queue" was not adopted (reason: the project does not require asynchronous processing).

[0158] Evidence chain weight model: With the increase of positive samples with consistent configuration files, the information entropy weight is fine-tuned from 0.40 to 0.41 (soft feedback update: Δs=0.01×(1+historical adoption rate deviation)).

[0159] Dispute prediction model: This project is added to the training set as a non-dispute case, and the classification boundary is slightly adjusted.

[0160] Generative model fine-tuning: Adopted suggestions are used as positive samples, and unadopted suggestions are used as negative samples for LoRA incremental fine-tuning.

[0161] Knowledge graph update: Since the "high concurrency requirements implicitly require caching design" has been validated, the confidence decay coefficient of this rule has been increased. In the granular mapping knowledge base, if new mapping relationships are confirmed in this project, they will be added to the database.

[0162] It should be understood that, although Figure 1 The steps in the flowchart are shown sequentially as indicated by the arrows, but these steps are not necessarily executed in the order indicated by the arrows. Unless otherwise specified herein, there is no strict order in which these steps are executed, and they can be performed in other orders. Figure 1 At least some of the steps in the process may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these sub-steps or stages is not necessarily sequential, but can be executed in turn or alternately with other steps or at least some of the sub-steps or stages of other steps.

[0163] In one embodiment, such as Figure 2 As shown, a bid conflict detection device based on multimodal evidence and conflict propagation graph is provided, including: a response evidence extraction module 202, a conflict list module 204, a graph construction module 206, a conflict density index calculation module 208, an integrity scoring module 210, and a detection and evaluation module 212, wherein: The response evidence extraction module 202 is used to obtain the technical requirements in the tender documents and extract response evidence to the technical requirements from multiple locations, multiple modalities, and multiple granularities in the same tender documents.

[0164] The Conflict List module 204 is used to perform conflict detection from three dimensions: cross-location, cross-modality, and cross-granularity, based on technical requirements and response evidence, to identify deep semantic conflicts between multiple source responses within the same tender document and generate a conflict list.

[0165] Graph construction module 206 is used to construct a contradiction propagation graph based on the causal relationships between contradictions in the contradiction list. The contradiction propagation graph uses contradictions as nodes and causal relationships as directed edges.

[0166] The contradiction density index calculation module 208 is used to calculate the cumulative impact coefficient of each contradiction based on the contradiction propagation diagram, and calculate the contradiction density index, which reflects the degree of contradiction density within the bidding proposal, based on the cumulative impact coefficient.

[0167] The integrity scoring module 210 is used to calculate an evidence chain integrity score that reflects the integrity of multimodal technical evidence based on the response evidence.

[0168] The detection and evaluation module 212 is used to integrate the contradiction density index with the evidence chain integrity score, calculate the comprehensive contradiction risk value, and output the comprehensive contradiction risk value and contradiction classification list.

[0169] Specific limitations regarding the bid conflict detection device based on multimodal evidence and conflict propagation graphs can be found in the limitations of the bid conflict detection method based on multimodal evidence and conflict propagation graphs mentioned above, and will not be repeated here. Each module in the aforementioned bid conflict detection device based on multimodal evidence and conflict propagation graphs can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device, or stored in the memory of a computer device as software, so that the processor can call and execute the corresponding operations of each module.

[0170] Those skilled in the art will understand that Figure 2 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0171] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), Synchlink, DRAM (SLDRAM), RAMbus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and RAMbus dynamic RAM (RDRAM), etc.

[0172] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0173] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of the invention. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A bid conflict detection method based on multimodal evidence and conflict propagation graph, characterized in that, The method includes: Obtain the technical requirements in the tender documents, and extract evidence of response to the technical requirements from multiple locations, modalities, and granularities in the same tender document; Based on the technical requirements and the response evidence, contradiction detection is performed from three dimensions: cross-location, cross-modality, and cross-granularity, to identify deep semantic contradictions among multiple source responses within the same tender document and generate a contradiction list; A contradiction propagation graph is constructed based on the causal relationships between the contradictions in the contradiction list, wherein the contradiction propagation graph has contradictions as nodes and causal relationships as directed edges; Based on the aforementioned contradiction propagation diagram, the cumulative impact coefficient of each contradiction is calculated, and based on the cumulative impact coefficient, a contradiction density index reflecting the intensity of contradictions within the bidding proposal is calculated. Based on the response evidence, calculate the evidence chain integrity score, which reflects the integrity of multimodal technology evidence; The contradiction density index is integrated with the evidence chain integrity score to calculate a comprehensive contradiction risk value, and the comprehensive contradiction risk value and contradiction classification list are output.

2. The method according to claim 1, characterized in that, Construct a conflict propagation diagram based on the causal relationships between the conflicts in the conflict list, including: Obtain a predefined technology dependency knowledge base, which stores the dependency relationships and causal strength weights between technical elements in software engineering; If there are dependency rules in the technology dependency knowledge base that connect the missing technical elements reflected by the first contradiction to the functional realization of the second contradiction, then a directed edge is established from the first contradiction to the second contradiction, and the causal strength weight is assigned to each directed edge. Using all detected contradictions as nodes and the directed edges as edges, the contradiction propagation graph is constructed according to the causal strength weights.

3. The method according to claim 1, characterized in that, Based on the aforementioned contradiction propagation diagram, calculate the cumulative impact coefficient of each contradiction, including: Extract the feature vector for each contradiction. The feature vector includes the contradiction type, the number of modalities involved, the number of missing architectural elements, the difference in declaration strength, the depth across granularities, and the degree of mandatory nature of the bidding requirements. The feature vector is input into the weighted PageRank algorithm to iteratively calculate the cumulative influence coefficient of each conflict: in, Let be the cumulative impact coefficient of the j-th contradiction. To control the propagation ratio of each node's weight in the contradiction propagation graph during the iteration process, For the edge Causal strength weights Let be the cumulative impact coefficient of the i-th contradiction. From The total number of directed edges from which a point originates; The initial weights of the nodes are determined based on the contradiction level system, and the damping coefficients are adaptively adjusted according to the contradiction propagation graph density.

4. The method according to claim 3, characterized in that, Based on the response evidence, calculate the evidence chain integrity score reflecting the integrity of multimodal technology evidence, including: During the cold start phase, the preset default weights determined based on the analytic hierarchy process are used as the initial fixed weights for each mode. Once the number of accumulated historical projects reaches a preset threshold, the system switches to dynamic learning weights based on information entropy, calculating the information content of each modality based on the consistency probability between the evidence from each modality and the final acceptance result. in, For modality The amount of information, For modality The probability of consistency; Update the weights to normalized values ​​that are inversely proportional to the amount of information: in, These are the normalized weight values. For the set of all modalities, For traversing the set Each mode in; Calculate the evidence chain integrity score based on the normalized value: in, This is the original value for the chain of evidence integrity score. For the completeness of valid evidence for modality m, For modality The completeness of evidence is determined by a value of 1 if the completeness of evidence exists and is consistent, and 0 if the completeness of evidence exists but is inconsistent. Scoring for the completeness of the chain of evidence. The sum of the normalized weights for all modes. This represents the confidence level for modal detection.

5. The method according to claim 4, characterized in that, The contradiction density index is integrated with the evidence chain integrity score to calculate a comprehensive contradiction risk value. The comprehensive contradiction risk value and a contradiction classification list are then output, including: The contradiction density index is combined with the evidence chain integrity score to calculate the comprehensive contradiction risk value: in, To comprehensively assess the risk of contradictions, To integrate weights, Scoring for the completeness of the chain of evidence. The contradiction density index, This represents the total number of responses. For the first The cumulative impact coefficient of the contradiction; Output the comprehensive contradiction risk value and contradiction classification list.

6. The method according to any one of claims 1 to 5, characterized in that, After the steps of integrating the contradiction density index with the evidence chain integrity score to calculate the comprehensive contradiction risk value and outputting the comprehensive contradiction risk value and the contradiction classification list, the method further includes: Based on retrieval enhancement generation technology, similar contradictions are retrieved from the historical case database, and prompt words containing contradiction type, original text of bidding requirements, bid response fragments and missing elements are constructed. These prompt words are then input into a pre-trained large language model to dynamically generate natural language correction suggestions. The generated correction suggestions are subjected to de-illusion verification, including verifying that the cited locations are consistent with the chain of evidence and that the mentioned technical components exist in the knowledge graph; The adoption of revision suggestions by review experts and the final project acceptance results are used as feedback signals, which are then fed back to the evidence chain weight model and knowledge graph with different update intensities to achieve continuous optimization of model parameters.

7. A bid conflict detection device based on multimodal evidence and conflict propagation graph, characterized in that, The device includes: The response evidence extraction module is used to obtain the technical requirements in the tender document and extract response evidence to the technical requirements from multiple locations, multiple modalities and multiple granularities in the same tender document. The contradiction list module is used to perform contradiction detection from three dimensions—cross-location, cross-modality, and cross-granularity—based on the technical requirements and the response evidence, to identify deep semantic contradictions among multiple source responses within the same tender document and generate a contradiction list. The graph construction module is used to construct a contradiction propagation graph based on the causal relationships between contradictions in the contradiction list. The contradiction propagation graph uses contradictions as nodes and causal relationships as directed edges. The contradiction density index calculation module is used to calculate the cumulative impact coefficient of each contradiction based on the contradiction propagation diagram, and calculate the contradiction density index, which reflects the degree of contradiction intensity within the bidding proposal, based on the cumulative impact coefficient. The integrity scoring module is used to calculate an evidence chain integrity score that reflects the integrity of multimodal technical evidence based on the response evidence. The detection and evaluation module is used to integrate the contradiction density index with the evidence chain integrity score, calculate the comprehensive contradiction risk value, and output the comprehensive contradiction risk value and the contradiction classification list.

Images