Pluggable man-machine collaborative decision edge and evidence snapshot bid invitation demand processing method and system, and medium

Abstract

The invention discloses a pluggable man-machine collaborative decision edge and evidence snapshot bid invitation demand processing method and system and a medium, and relates to the technical field of bid invitation purchasing, and the method comprises the steps: loading a predefined graphical workflow; obtaining an original bid invitation demand text; preprocessing the original bid invitation demand text; based on the preprocessed original bid invitation demand text, circulation is carried out according to a threshold value; if the threshold value is met, entering an automatic processing path; if the threshold value is not met, shunting to an HITL path for processing; and outputting a structured result by taking the global constraint consistency as a judgment basis, and archiving and snapshooting the structured result. The method is used for carrying out lacking item identification, conflict resolution and consistency repair on the bid invitation demand, and triggering the minimization HITL when the confidence or contradiction is low.

Description

Technical Field

[0001] This invention relates to the field of bidding and procurement technology, and more specifically to a method, system, and medium for processing bidding requirements with a pluggable human-machine collaborative decision-making edge and evidence snapshot. Background Technology

[0002] For the intelligent process of "user input of bidding requirements → identification of missing / conflict items → clarification → structured output", existing systems mostly use large language model dialogue combined with retrieval and rule verification. The common practice is to have human intervention (HITL) to correct errors in the dialogue, but there is a lack of clear intervention points and verifiable state machines; the decisions in each round also lack evidence archiving and replay mechanisms, resulting in insufficient consistency and traceability.

[0003] Therefore, how to provide a pluggable human-machine collaborative decision-making edge and evidence snapshot bidding requirement processing method, system and medium is a problem that urgently needs to be solved by those skilled in the art. Summary of the Invention

[0004] In view of this, the present invention provides a method, system, and medium for handling bidding requirements with pluggable human-machine collaborative decision-making edges and evidence snapshots. Any decision can be reproduced from the experimental path using snapshots. GCC is used to ensure consistency of "duration / amount / unit / terminology" across rounds, significantly reducing the conflict residual rate. HITL minimization is used to focus human attention on disputed slots, reducing the average dwell time.

[0005] To achieve the above objectives, the present invention adopts the following technical solution: a method for processing bidding requirements with pluggable human-machine collaborative decision-making edges and evidence snapshots, comprising: Load a predefined graphical workflow; Obtain the original tender requirements text; The original tender requirement text is preprocessed; Based on the preprocessed original tender requirements text, the process is streamlined according to a threshold. If the threshold is met, the process will proceed to the automatic processing path; otherwise, it will be routed to the HITL path for processing. Based on the consistency of global constraints, output structured results and archive snapshots.

[0006] Preferably, the graph editor calls the detector node to perform pre-detection of missing items and conflict resolution on the original bidding requirements text; Output slot set and confidence level.

[0007] Preferably, the graph arranger uses both confidence level and GCC conflict status as dual criteria to determine the path along the decision edge; If the detected confidence level is greater than or equal to the decision edge threshold τ, and the slot set does not conflict with the constraints in GCC, then proceed to the automatic processing path. If the detected confidence level is less than the decision edge threshold τ, or if the slot set conflicts with GCC, then proceed to the HITL path; If the conflict count κ > δ, prioritize performing consistency repair and reassessment.

[0008] Preferably, the automatic processing path includes: The graph arranger calls the auto-repairer node, which, based on GCC's constraint rules, treats the slot set as a constraint satisfaction problem and performs consistency repair.

[0009] Preferably, the HITL path includes: The graphic arranger triggers HITL to minimize the UI, presenting only disputed slots to humans, with each slot accompanied by key information; The results of human decision-making are recorded in a structured manner, fed back into GCC to update variables and their evolution, and simultaneously triggers consistency check nodes.

[0010] Preferably, after the automatic path and HITL path processing are completed, Return to the graph orchestrator and re-perform the routing decision; If the consistency check passes, proceed to the output stage; If conflicts still exist or the confidence level is less than the decision edge threshold τ, then the path processing is repeated until the consistency requirement is met.

[0011] Preferably, the diagram arranger calls the structured generation node to convert the final slot set into an editable document; The evidence snapshot service aggregates the entire process of decision-making records and generates a replayable chain of evidence. It also outputs full-process audit logs simultaneously.

[0012] Preferably, a tendering requirement processing system with pluggable human-machine collaborative decision-making edge and evidence snapshot includes: The initialization module is used to load predefined graphical workflows; The requirement text acquisition module is used to acquire the original bidding requirement text; The preprocessing module is used to preprocess the original tender requirement text; The judgment module is used to process the pre-processed original bidding requirements text according to a threshold. If the threshold is met, it enters the automatic processing path; if the threshold is not met, it is diverted to the HITL path for processing. The output module is used to output structured results and archive snapshots based on the consistency of global constraints.

[0013] Preferably, a computer-readable storage medium stores executable instructions thereon, which, when executed by a processor, cause the processor to perform the methods described above.

[0014] As can be seen from the above technical solutions, compared with the prior art, the present invention discloses a method, system and medium for processing bidding requirements with pluggable human-machine collaborative decision edges and evidence snapshots, and a pluggable human-machine collaborative "decision edge" and "evidence snapshot" mechanism based on graph workflow (represented by LangGraph), which is used to identify missing items, resolve conflicts and repair consistency in bidding requirements, and trigger the minimization of HITL when there is low confidence or contradiction. Attached Figure Description

[0015] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.

[0016] Figure 1 This is a schematic diagram of a tendering requirement processing method for a pluggable human-machine collaborative decision-making edge and evidence snapshot provided in an embodiment of the present invention.

[0017] Figure 2 This is a schematic diagram of the decision-side state machine workflow provided in an embodiment of the present invention.

[0018] Figure 3 This is a schematic diagram of the evidence snapshot data structure provided in an embodiment of the present invention.

[0019] Figure 4 This is a schematic diagram of the HITL minimized UI process provided in an embodiment of the present invention. Detailed Implementation

[0020] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0021] This invention discloses a method for processing bidding requirements using pluggable human-machine collaborative decision-making edges and evidence snapshots, including: Load a predefined graphical workflow; Obtain the original tender requirements text; The original tender requirement text is preprocessed; Based on the preprocessed original tender requirements text, the process is streamlined according to a threshold. If the threshold is met, the process will proceed to the automatic processing path; otherwise, it will be routed to the HITL path for processing. Based on the consistency of global constraints, output structured results and archive snapshots.

[0022] In one specific embodiment of the present invention, such as Figure 1 The diagram illustrates the overall modules, data, and control paths of the human-machine collaborative clarification system. The specific steps are as follows: 1. User Input / Web Interface: Receives original tender requirements text and user instructions.

[0023] 2. Orchestrator: The core scheduling module; it organizes the process using "nodes + decision edges". Each decision edge carries a threshold τ and evidence requirements.

[0024] 3. Support Services (two parallel sub-modules): Evidence snapshot service: Input fingerprints, retrieve evidence, model identifiers, inference parameters, output summaries, and timestamps for each edge decision record, for playback and auditing.

[0025] Global Constraint Context (GCC): Maintains commitment variables (such as duration, amount, unit, terminology), constraint sets, conflict list, and evolution record.

[0026] 4. Execution path (two sub-modules listed): Automatic Path: A human-free path consisting of nodes that are automatically repaired, generated, or reviewed.

[0027] HITL Minimal Interface: Only disputed slots (such as "Duration" and "Unit") are displayed, making it easy for manual selection / editing / rejection.

[0028] 5. Structured output: The final output is a clause-level JSON / document.

[0029] Specifically, data and control flow

[0030] Orchestrator → Automatic Path: When node confidence conf≥τ and there are no GCC conflicts.

[0031] Orchestrator → HITL: when conf < τ or a conflict exists.

[0032] Automatic path → Output: Generates structured results.

[0033] HITL → Orchestrator: After manual confirmation, return to the orchestrator to continue routing.

[0034] Decision Snapshot: The orchestrator records decisions to the Evidence Snapshot service; snapshots support playback / auditing and can then be returned to the orchestrator.

[0035] Constraint Interaction: The orchestrator is bidirectionally associated with GCC; the automatic path will patch the differential backflow to GCC; HITL will backflow the manual decision to GCC.

[0036] Specifically, the graph editor calls the detector node to perform pre-detection of missing items and conflict resolution on the original bidding requirements text; Output the slot set and confidence level. The confidence level is obtained by fusing the detection results through a monotonic aggregator and reflects the reliability of the slot value.

[0037] Specifically, the graph arranger uses both confidence level and GCC conflict status as dual criteria to determine the path along the decision edge; If the detected confidence level is greater than or equal to the decision edge threshold τ, and the slot set does not conflict with the constraints in GCC, then proceed to the automatic processing path. If the detected confidence level is less than the decision edge threshold τ, or if the slot set conflicts with GCC, then proceed to the HITL path; If the conflict count κ > δ, prioritize performing consistency repair and reassessment.

[0038] Specifically, confidence aggregation: The confidence of the detector / sampling unit is aggregated using a monotonic aggregator (such as calibrated logistic or z-score fusion) to obtain conf.

[0039] Routing rules: If conf ≥ τ and does not conflict with GCC, flow to the automatic edge; otherwise, flow to the HITL edge. If the conflict count κ > δ, prioritize consistency repair and re-evaluation.

[0040] Consistency Repair: Treat variables as a constraint satisfaction problem (CSP) with the goal of minimizing the cost of constraint violation; a heuristic greedy algorithm or ILP approximation can be used to produce RepairDiff and refeed GCC.

[0041] Playback guarantee: Snapshots record model version and parameters; controlled sampling seeds can be enabled for generated nodes or recorded output summaries can be reused to achieve replay with the same parameters.

[0042] The specific process of consistency repair includes: 1) Collect conflicts: Obtain problematic variables and constraints from the detector and GCC.

[0043] 2) Alternative values: Provide 2-3 candidates for each variable column (evidence extraction, rule normalization, historical values).

[0044] 3) Selecting a solution: Prioritize the combination that "minimizes changes and satisfies the most constraints" (use heuristic greedy algorithms for small-scale applications and approximate solutions for large-scale applications).

[0045] 4) Generate the difference: Output [{path, before, after, reason, evidence_refs}].

[0046] 5) Reflow review: Write back to GCC and review automatically; if there are still conflicts, transfer to HITL for manual review.

[0047] Specifically, the automatic processing path includes: The graph arranger calls the auto-repairer node, which, based on GCC's constraint rules, treats the slot set as a constraint satisfaction problem and performs consistency repair.

[0048] Specifically, the HITL path includes: The graph arranger triggers a minimized UI using HITL, presenting only disputed slots to human users. Each slot is accompanied by key information, including: candidate value, link to supporting evidence fragments, model suggestions, and historical background. The results of human decision-making are recorded in a structured manner, fed back into GCC to update variables and their evolution, and simultaneously triggers consistency check nodes.

[0049] Specifically, the UI only presents "disputed slots" (such as project duration / amount), each slot containing: candidate value, link to supporting evidence fragments, model suggestions, and historical background; manual actions (selection / editing / rejection + reasons) are structured and fed back into the process. The front-end components automatically generate layouts along with the evidence_requirements.

[0050] like Figure 2 The diagram shown is a schematic of a decision-side state machine, used to depict the state transitions of "detection—triage—repair—re-evaluation—output".

[0051] Specifically, states and transitions

[0052] Startup → Detector: Analyze requirements, identify missing items / conflicts, and calculate confidence level (conf).

[0053] Detector → Auto-repairer: when conf ≥ τ and there are currently no consistency conflicts.

[0054] Detector → HITL: when conf < τ or a conflict exists.

[0055] Automatic Repairer → Consistency Check (Branch): Consistent → Execute JSON (output).

[0056] Inconsistency → Return to detector (trigger backtracking or re-evaluation).

[0057] HITL → Patching and Updating GCC: Manually select / edit / reject in the disputed slot; then re-pour GCC.

[0058] Repair and update GCC → detector: review with new context, proceed to launch if it passes; otherwise, loop again.

[0059] Execute JSON → Terminate: Output structured results and end the current round.

[0060] Specifically, after the automatic path and HITL path processing are completed, Return to the graph orchestrator and re-perform the routing decision; If the consistency check passes, proceed to the output stage; If conflicts still exist or the confidence level is less than the decision edge threshold τ, then the path processing is repeated until the consistency requirement is met.

[0061] Specifically, the graph arranger calls the structured generation nodes to convert the final slot set into an editable document; The evidence snapshot service aggregates the entire process of decision-making records and generates a replayable chain of evidence. It also outputs full-process audit logs simultaneously.

[0062] Specifically, such as Figure 3 As shown, evidence snapshots are used to provide key data objects, fields, and their relationships.

[0063] Specifically, objects and fields

[0064] DecisionEdge: Fields: edge_id, source_node, target_auto, target_hitl, threshold_tau, evidence_requirements[], aggregator, created_at.

[0065] Meaning: Starting from the source node, route to the automatic or HITL target based on the threshold τ and the evidence requirements.

[0066] Evidence Snapshot: Fields: edge_id, inputs_sha256, retrieved_citations[], model_id, params{…}, output_digest, decision, timestamp.

[0067] Meaning: A replayable record of an edge decision (including input / evidence / model and parameters / output summary / timestamp / decision conclusion).

[0068] GlobalConstraintContext (GCC): Fields: variables[], constraints[], conflicts[], lineage[].

[0069] Meaning: A unified container for global commitment variables and constraints, storing current conflicts and historical context.

[0070] Variable: Fields: name, type, value, conf, proofance (variable name / type / value / confidence / source).

[0071] RepairDiff (Minimum Repair Difference): Fields: path, before, after, reason, evidence_refs[] (modification location, before and after values, reason, evidence citations).

[0072] object relationship

[0073] DecisionEdge→EvidenceSnapshot: A snapshot is generated and associated with each decision.

[0074] EvidenceSnapshot…→GCC: The snapshot references the variable / constraint context information on which it is based.

[0075] RepairDiff…→GCC: Repair differential recharge GCC, update variable values ​​and evolution, and clear or mitigate conflicts.

[0076] Specifically, Figure 4 This is a schematic diagram of the minimized UI in HITL, used to illustrate the closed loop of minimized operations for manual intervention in disputed slots. The specific process is as follows: 1. Start → Display the “Disputed Slot” card: The card includes the slot name, candidate value, evidence link (page number / fragment), and historical background.

[0077] 2. Branch selection: Accept candidates → Directly generate structured decisions; Edit Custom → Enter New Value and Generate Decision; Rejection → Fill in the reasons and generate a decision.

[0078] 3. Write back snapshot: Write the current manual action and selected evidence into an evidence snapshot.

[0079] 4. Update GCC: Feed the decision results back into the global constraint context and refresh the variable and constraint states.

[0080] 5. Return to the orchestrator: The graph orchestrator continues routing to subsequent nodes; if there is still a dispute, proceed to the next slot; if consistency is satisfied, output and end / proceed to the next slot.

[0081] Specifically, the key data structures are as follows: DecisionEdge:={edge_id, source_node, target_auto, target_hitl, threshold_tau, evidence_requirements[], aggregator, created_at} EvidenceSnapshot:={edge_id, inputs_sha256, retrieved_citations[], model_id, params{temperature, top_p,...}, output_digest, decision, timestamp} GlobalConstraintContext:={variables[{name, type, value, conf, provenance}], constraints[expr], conflicts[], lineage[]} RepairDiff:=[{path, before, after, reason, evidence_refs[]}] The definition is as follows: DecisionEdge: {edge_id, source_node, target_auto (automatic processing target node), target_hitl (HITL target node, the original text "target_hitl" is a typo, corrected based on the document context), threshold_tau, evidence_requirements, aggregator, creation_at} Evidence Snapshot: {edge_id, input_sha256 hash, retrieved_citations, model_id, inference parameters {temperature, top_p, ...}, output_digest, decision, timestamp} GlobalConstraintContext: {variables[{name,type,value,conf,provenance}], constraint set[constraints[expr]], conflict set[], lineage set[]} RepairDiff: [{path, before, after, reason, evidence_refs[]}].

[0082] The specific operation flow of this invention embodiment is as follows: S1: Load the graph and threshold configuration, and create a GCC; S2: Perform missing and conflict detection on user bidding requirements to obtain slot set and conf; S3: Based on the threshold and conflict state, route along the decision edge to the automatic edge or HITL edge; S4: Present evidence snapshots in HITL UI, collect human choices and structure records; S5: Perform consistency repair based on GCC, generate RepairDiff and re-pump it; S6: Output structured results (JSON Schema) and end-to-end audit / snapshot.

[0083] The embodiments of the present invention have the following technical effects: (1) Playback and verification: Any decision can be reproduced by snapshot of the experimental path (consistent with the same reference and version).

[0084] (2) Improved consistency: GCC ensures consistency of “duration / amount / unit / term” across rounds; conflict residual rate is significantly reduced.

[0085] (3) Reduced human time: HITL minimization focuses human attention on disputed slots, resulting in a decrease in average dwell time.

[0086] (4) End-to-end time reduction: Automatic edge hit rate is improved, reducing repetitive manual correction.

[0087] In one specific embodiment of the present invention, a tendering requirement processing system with pluggable human-machine collaborative decision-making edge and evidence snapshot includes: The initialization module is used to load predefined graphical workflows; The requirement text acquisition module is used to acquire the original bidding requirement text; The preprocessing module is used to preprocess the original tender requirement text; The judgment module is used to process the pre-processed original bidding requirements text according to a threshold. If the threshold is met, it enters the automatic processing path; if the threshold is not met, it is diverted to the HITL path for processing. The output module is used to output structured results and archive snapshots based on the consistency of global constraints.

[0088] Specifically, (1) Workflow orchestration engine: Nodes represent operators such as detection / generation / review, and decision edges are bound to thresholds and evidence requirements; if the threshold is met, the flow is automatically transferred through the edge, otherwise it is diverted to the HITL edge.

[0089] (2) Evidence snapshot service: For each edge decision record, input fingerprint, retrieve evidence, model identifier and inference parameters, output summary and timestamp to form a replayable vector.

[0090] (3) Global Constraint Context (GCC): Maintains commitment variables and constraint sets such as "duration, amount, unit, terminology"; when any node output conflicts with the context, it triggers consistency repair and produces the minimum repair difference.

[0091] (4) HITL Minimal UI: Only presents candidate values ​​and evidence comparison cards for "disputed slots", supporting one-click confirmation / editing / rejection.

[0092] (5) Structured output and audit: Output clause-level JSON Schema and evidence chain; full-process audit log and replayability.

[0093] In one specific embodiment of the present invention, a computer-readable storage medium is provided having executable instructions stored thereon, which, when executed by a processor, cause the processor to perform the above-described method.

[0094] In a specific embodiment of the present invention, the specific process of a method for processing tender requirements of a pluggable human-machine collaborative decision-making edge and evidence snapshot is as follows: S1: Create a graph (Detector / Generator / Reviewer / Router), and configure edge thresholds and evidence requirements; S2: The Detector performs missing item detection (such as construction period, qualification, payment, default, etc.) on the text and gives a conf; S3: The Router judges: conf≥τ and there is no GCC conflict → Auto-Fixer; otherwise → HITL; S4: HITL presents a dispute slot card for manual selection or editing; the result is written back in a structured manner; S5: The Auto-Fixer performs repair based on GCC and outputs RepairDiff; S6: Output clause-level JSON and evidence chain, and generate an audit log and snapshot.

[0095] In a specific embodiment of the present invention, the specific process of consistency repair is as follows: Model with {construction period = 30 days, payment nodes = T1 / T2 / T3, amount unit = ten thousand yuan} as a variable set; Constraint examples: T2≥T1+10d, unit consistency (ten thousand yuan), total amount = sum of sub-items. If the Reviewer detects mixed use of units "ten thousand / ten thousand yuan" and T2<T1, the repairer calculates the solution with the minimum violation cost and generates: RepairDiff: [{path: " / unit", before: "ten thousand", after: "ten thousand yuan"}, {path: " / T2", before: "7d", after: "12d"}]; After repair, backfill GCC and re-evaluate.

[0096] In this specification, each embodiment is described in a progressive manner. The key point of each embodiment is to illustrate the differences from other embodiments. The same or similar parts among the embodiments can be referred to each other. For the device disclosed in the embodiment, since it corresponds to the method disclosed in the embodiment, the description is relatively simple, and the relevant parts can be referred to the description of the method part.

[0097] The above description of the disclosed embodiments enables those skilled in the art to make or use the invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the invention. Therefore, the invention is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A method for processing bidding requirements with pluggable human-machine collaborative decision-making edges and evidence snapshots, characterized in that, include: Load a predefined graphical workflow; Obtain the original tender requirements text; The original tender requirement text is preprocessed; Based on the preprocessed original tender requirements text, the process is streamlined according to a threshold. If the threshold is met, the process will proceed to the automatic processing path; otherwise, it will be routed to the HITL path for processing. Based on the consistency of global constraints, output structured results and archive snapshots.

2. The method for processing bidding requirements with pluggable human-machine collaborative decision-making edges and evidence snapshots according to claim 1, characterized in that, The graph editor calls the detector node to perform pre-detection of missing items and conflict resolution on the original bidding requirements text; Output slot set and confidence level.

3. The method for processing bidding requirements with pluggable human-machine collaborative decision-making edges and evidence snapshots according to claim 2, characterized in that, The graph arranger uses both confidence level and GCC conflict status as dual criteria to determine the path along the decision edge; If the detected confidence level is greater than or equal to the decision edge threshold τ, and the slot set does not conflict with the constraints in GCC, then proceed to the automatic processing path. If the detected confidence level is less than the decision edge threshold τ, or if the slot set conflicts with GCC, then proceed to the HITL path; If the conflict count κ > δ, prioritize performing consistency repair and reassessment.

4. The method for processing bidding requirements with pluggable human-machine collaborative decision-making edges and evidence snapshots according to claim 3, characterized in that, The automatic processing path includes: The graph arranger calls the auto-repairer node, which, based on GCC's constraint rules, treats the slot set as a constraint satisfaction problem and performs consistency repair.

5. The method for processing bidding requirements with pluggable human-machine collaborative decision-making edges and evidence snapshots according to claim 3, characterized in that, The HITL path includes: The graphic arranger triggers HITL to minimize the UI, presenting only disputed slots to humans, with each slot accompanied by key information; The results of human decision-making are recorded in a structured manner, fed back into GCC to update variables and their evolution, and simultaneously triggers consistency check nodes.

6. The method for processing bidding requirements with pluggable human-machine collaborative decision-making edges and evidence snapshots according to claim 3, characterized in that, After automatic path and HITL path processing is completed, Return to the graph orchestrator and re-perform the routing decision; If the consistency check passes, proceed to the output stage; If conflicts still exist or the confidence level is less than the decision edge threshold τ, then the path processing is repeated until the consistency requirement is met.

7. The method for processing bidding requirements with pluggable human-machine collaborative decision-making edges and evidence snapshots according to claim 3, characterized in that, The diagram arranger calls structured generation nodes to convert the final slot set into an editable document; The evidence snapshot service aggregates the entire process of decision-making records and generates a replayable chain of evidence. It also outputs full-process audit logs simultaneously.

8. A tendering requirement processing system with pluggable human-machine collaborative decision-making edges and evidence snapshots, employing the tendering requirement processing method with pluggable human-machine collaborative decision-making edges and evidence snapshots as described in any one of claims 1-7, characterized in that, include: The initialization module is used to load predefined graphical workflows; The requirement text acquisition module is used to acquire the original bidding requirement text; The preprocessing module is used to preprocess the original tender requirement text; The judgment module is used to process the pre-processed original bidding requirements text according to a threshold. If the threshold is met, it enters the automatic processing path; if the threshold is not met, it is diverted to the HITL path for processing. The output module is used to output structured results and archive snapshots based on the consistency of global constraints.

9. A computer-readable storage medium having stored thereon executable instructions that, when executed by a processor, cause the processor to perform the method according to any one of claims 1-7.

Images