Hierarchical memory multi-round interaction geotechnical report structured generation system and method

Abstract

The application discloses a hierarchical memory multi-round interactive geotechnical report structured generation system and method, which comprises a template analysis and structure task graph construction module, a data binding and evidence summary generation module, a global constraint management module, a prompt arrangement and generation execution module, a consistency checking and conflict disposal module and a hierarchical memory management module. The template analysis and structure task graph construction module analyzes a geotechnical report structure template into a chapter task graph and allocates SlotID to each field of the report. The data binding and evidence summary generation module binds project survey data to SlotID and generates evidence objects. The global constraint management module generates global constraint items based on the evidence object set and the chapter task graph. The prompt arrangement and generation execution module outputs a structured reference list to a generation model. The consistency checking and conflict disposal module implements incremental consistency checking and outputs a conflict list. The hierarchical memory management module is used for maintaining memory. The evidence chain and audit module generates and stores a chain hash audit log. The application can write the effective version of the hierarchical memory gate into the chain hash audit log, realize cross-round consistency and traceable generation revision.

Description

Technical Field

[0001] This invention relates to the field of engineering document processing, specifically to a hierarchical memory multi-round interactive geotechnical report structure generation system and method. Background Technology

[0002] Geotechnical investigation reports are crucial for engineering design, construction organization, and risk control. They typically consist of multiple chapters and require data from various sources, including borehole drilling, in-situ testing, and laboratory experiments, to form engineering geological evaluations and recommendations. With increasing engineering complexity and data volume, the report preparation process is characterized by frequent data citations, strong interdependencies between chapters, and multiple version iterations. Engineering practice places higher demands on the accuracy, consistency, and traceability of report texts.

[0003] Current report preparation typically employs the following methods: First, technical personnel manually write reports based on specifications, experience, and project data, using templates for formatting; second, they use document automation or rule / template filling methods to write structured survey data into pre-set tables and some fixed paragraphs; third, they introduce large language models to assist writing, generating chapter drafts by inputting project overview and some data, which are then proofread, revised, and integrated into the final draft by personnel. These methods can reduce repetitive work or accelerate the formation of initial drafts to varying degrees and have been applied in engineering practice.

[0004] However, in the generation of extremely long, multi-chapter, and data-dependent geotechnical reports, existing technologies typically lack a unified, machine-readable global constraint mechanism to continuously ensure consistency and traceability of data citations and conclusions across chapters under segmented generation and multiple revisions. For example, when reports are written separately by chapter or generated in segments by models, the lack of unified management and verification of elements such as data sources, indicator units, applicable chapters, cited fragments, and verification status can lead to inconsistencies in citation standards, inconsistent expressions, or difficulty in tracing the basis of citations when reusing the same exploration data or key judgments across chapters. In private deployments or scenarios with limited computing power, the generation process often struggles to carry a complete context over a long period, making it even more difficult to maintain global consistency and the continuous link of citations. Therefore, there is an urgent need for a structured generation system and method that can provide a unified constraint on the consistency of data citations and conclusions and offer a traceable chain of evidence during segmented, layered generation and multiple rounds of interaction to solve the above problems. Summary of the Invention

[0005] Based on the above description, the present invention provides a hierarchical memory multi-round interactive structured generation system and method for geotechnical reports, in order to solve the problem that the existing technology lacks a mechanism to uniformly constrain cross-chapter data references and conclusion statements and provide evidence chain traceability during the segmented generation and multi-round revision of geotechnical engineering investigation reports, which leads to the difficulty in continuously ensuring consistency.

[0006] The technical solution of this invention to solve the above-mentioned technical problems is as follows: A hierarchical memory multi-round interactive geotechnical report structure generation system, comprising:

[0007] The template parsing and structural task graph construction module is used to parse the geotechnical report structural template into a chapter task graph. The chapter task graph includes a set of chapter nodes and a directed acyclic topology structure built based on data dependency edges and conclusion dependency edges. It also assigns a globally unique slot identifier SlotID to each field slot in the report.

[0008] The data binding and evidence summary generation module is used to bind project survey data to SlotID and generate evidence objects. Based on preset unit mapping rules and dimensional conversion formulas, the module normalizes the units of the evidence objects and calculates the evidence summary hash EvidenceHash.

[0009] The global constraint management module is used to generate global constraint items based on the generated set of evidence objects and the chapter task graph, compile the constraint rules into an executable sequence of constraint operators and a constraint execution plan, and establish an inverted index for incremental consistency verification.

[0010] The prompt arrangement and generation execution module is used to output chapter text prompt input containing anchor point ID boundary markers to the generation model and receive the generated chapter content and the structured reference list corresponding to the anchor point ID. The structured reference list serves as the only reliable reference source for consistency verification.

[0011] The consistency verification and conflict handling module is used to perform incremental consistency verification based on the constraint execution plan and structured reference list according to the change impact set and chapter task graph closure, output machine-readable conflict list and drive only the specified conflict anchor point ID fragment to be partially rewritten and out-of-bounds rejection in differential prompt mode;

[0012] The hierarchical memory management module is used to maintain short-term and long-term memory, and submits the candidate version as the effective version only when the associated constraint item passes the verification and the EvidenceHash matches the execution plan requirements.

[0013] The evidence chain and audit module is used to generate and store chained hash audit logs containing anchor IDs, EvidenceHash, and verification results.

[0014] The above technical solution parses the report template into a chapter task DAG and assigns a globally unique SlotID to each field slot, using dependency edges to control the generation order and achieve field-level positioning; it binds the survey data to the SlotID and performs unit normalization, calculating the EvidenceHash to solidify the data caliber; it generates global constraints based on the evidence and task graph and compiles them into an execution plan, combining an inverted index to achieve incremental consistency verification driven by the change impact set; it establishes a text fragment-evidence mapping using anchor ID tags, and in case of conflict, only differentially rewrites the specified fragments and rejects out-of-bounds errors; it uses hierarchical memory gating to control the effective version and writes it to the chained hash audit log, achieving consistent and traceable generation and revision across rounds.

[0015] Based on the above technical solution, the present invention can be further improved as follows.

[0016] Furthermore, the evidence object is a machine-readable structure used for cross-chapter citation and verification. Its fields include evidence identifier, SlotID, data source identifier, indicator name, original indicator unit, normalized unit, original value, normalized value, unit conversion formula identifier, precision strategy, applicable chapter set, citation fragment identifier set, verification status, and EvidenceHash. The precision strategy includes rounding rules and error thresholds, and the EvidenceHash is a hash value calculated by deterministically serializing the fields, which at least include the evidence identifier, SlotID, normalized unit, normalized value, and unit conversion formula identifier, for citation mismatch detection and audit anti-tampering verification.

[0017] Furthermore, the global constraint set consists of multiple global constraint items, which are machine-readable constraint units. The fields of each global constraint item include constraint identifier, constraint object identifier, constraint type, applicable chapter set, intermediate representation of constraint rules, compiled constraint operator identifier set, constraint execution plan, and verification status. The constraint object identifier is used to point to a single evidence identifier, EvidenceHash, or conclusion key. The constraint type includes unit consistency, numerical consistency, conclusion consistency, and reference completeness. The consistency verification and conflict handling module outputs machine-readable verification conclusions and conflict reason codes based on the constraint execution plan.

[0018] Furthermore, the evidence chain record is a structured record used to achieve traceability and auditability of the generated results. Its fields include chapter node identifier, output fragment identifier anchor ID, output fragment position identifier, SlotID, evidence identifier, EvidenceHash, constraint identifier, normalized value of reference, normalized unit of reference, verification result identifier, version identifier, timestamp, previous chain digest PrevChainHash, and chain digest ChainHash. The chain digest ChainHash is calculated deterministically by performing serialization calculation on this evidence chain record and the previous chain digest PrevChainHash to support auditing and anti-tampering verification.

[0019] Furthermore, the long-term memory stores long-term memory entries using conclusion keys and indicator keys as indexes. The long-term memory entries include conclusion keys or indicator keys, conclusion text or indicator values, a set of associated evidence identifiers, a set of associated EvidenceHash, a set of associated constraint identifiers, verification status, version identifier, and a candidate version pool and effective version. The hierarchical memory management module submits the candidate version as the effective version only when the associated constraint item passes the verification and the EvidenceHash set matches the constraint execution plan. Otherwise, the candidate version is kept in the candidate version pool and the conflict reason code is recorded.

[0020] This invention also provides a hierarchical memory multi-round interactive geotechnical report structure generation method, which, using the aforementioned hierarchical memory multi-round interactive geotechnical report structure generation system, includes the following steps:

[0021] Step 1) Parse the report structure template, generate a chapter task graph containing chapter nodes, data dependency edges, and conclusion dependency edges, and assign a globally unique SlotID to each field slot;

[0022] Step 2) Bind the survey data to SlotID according to the mapping rules to generate evidence objects and normalize the units, and calculate the EvidenceHash for the key fields of deterministic serialization;

[0023] Step 3) Generate global constraint terms based on the evidence object and task graph, construct the constraint rules into an executable IR / AST and compile them into a sequence of constraint operators to form a constraint execution plan, and establish an inverted index from EvidenceHash to constraint identifier and from constraint identifier to chapter node, SlotID and anchor ID.

[0024] Step 4) Initialize short-term memory and long-term memory containing candidate pools / effective versions;

[0025] Step 5) Select chapter nodes that satisfy the dependencies to build the input prompt, and limit the output to include the anchor ID boundary markers corresponding to the SlotID and the structured reference list that corresponds one-to-one with the anchor ID;

[0026] Step 6) Call the generation model to obtain the chapter text and structured citation list;

[0027] Step 7) Generate a chain of evidence record using the structured citation list as the sole citation basis and calculate the chain hash audit digest;

[0028] Step 8) Calculate the change impact set by inverted index and obtain the affected subgraph by finding the closure on the task graph. Perform incremental consistency check only on it and output the conflict list.

[0029] Step 9) Based on the conflict list differential prompts, only rewrite the specified anchor point ID and reject out-of-bounds requests. If it still fails after the preset number of rounds, regenerate.

[0030] Step 10) After the verification is passed, update the long-term memory entries according to the evidence chain record and the verification result. Submit the version that has passed the verification and whose reference EvidenceHash set meets the requirements of the constraint execution plan as the effective version. Otherwise, write it into the candidate pool and record the conflict reason code.

[0031] Step 11) After completing the target node of the chapter task diagram, export the report according to the structure template and output the audit log containing the evidence chain, global constraint verification results and conflict handling history.

[0032] Furthermore, in step 2), unit normalization includes converting the original indicator units into normalized units according to unit mapping rules, and converting the original values ​​into normalized values ​​according to dimensional conversion rules; the deterministic serialization of EvidenceHash includes at least SlotID, data source identifier, normalized unit, normalized value, and dimensional conversion formula identifier.

[0033] In step 8), the unit consistency check and the numerical consistency check use standardized units and standardized values ​​as the only comparison criteria, and output the conflict reason code using a preset absolute error threshold or relative error threshold.

[0034] Furthermore, in step 3), the executable IR / AST at least includes a unit normalization node, a numerical comparison node, a conclusion key matching node, and a reference completeness assertion node; the constraint execution plan at least includes a set of operator sequence identifiers, a set of dependent EvidenceHash, a set of covered SlotIDs, and a set of affected anchor IDs.

[0035] The out-of-bounds rejection in step 9) includes comparing the text summary or location summary within the boundary of the non-assigned anchor ID before and after rewriting. If there is a change or the anchor ID boundary marker is missing, the rejection is triggered and a second differential rewriting is initiated.

[0036] Furthermore, in step 5) or step 9), expert feedback is received and converted into a structured feedback object. The structured feedback object includes at least a feedback location identifier, a feedback type identifier, a modification instruction, an associated evidence identifier or a conclusion key and a priority identifier, and the output constraint rules, evidence object verification status, global constraint rules or long-term memory entries are updated accordingly.

[0037] Step 8) further includes duplication suppression verification: calculate the similarity between the newly generated paragraph and the already generated paragraph, and if the similarity reaches the threshold, generate a duplicate conflict item and write it into the conflict list. Step 9) triggers merging, rewriting or deletion accordingly, and writes the paragraph identifier, threshold and disposal action into the evidence chain and audit log.

[0038] Furthermore, it also includes saving breakpoint states during the chapter traversal generation process to support breakpoint continuation and version rollback. The breakpoint states at least include a set of completed chapter nodes, a set of chapter version identifiers, a set of evidence objects or their indexes, a set of global constraints or their indexes, evidence chain records and chained hash digests, short-term memory snapshots, long-term memory snapshots, and conflict list history. During rollback, the breakpoint states corresponding to the target version are restored, and steps 5) to 11) are continued.

[0039] Compared with the prior art, the technical solution of this application has the following beneficial technical effects:

[0040] 1. The generation order is unified through chapter task diagrams. Data sources and definitions are solidified by combining field slot binding, unit normalization, evidence objects, and EvidenceHash. Cross-chapter reuse rules are compiled into executable global constraints. The completeness of units, values, conclusions, and citations is continuously checked. This mechanism avoids different definitions of the same source data and the drift of conclusions, ensuring that the long multi-chapter reports remain consistent and reliable even under segmented generation and multiple revisions.

[0041] 2. Based on the constraint execution plan and inverted index, the affected segments are located, and the change impact set is calculated according to the dependency closure, so as to realize the incremental verification only for the affected chapters / segments; the conflict is output with the cause code, and the conflicting segments are rewritten only through differential hints. Combined with out-of-bounds rejection, irrelevant changes are suppressed to prevent the spread, avoiding full regeneration and full proofreading, significantly reducing the iteration cost, and adapting to private and computing-limited scenarios.

[0042] 3. A hierarchical memory and candidate-effective gating mechanism is adopted. Only content that passes the verification and matches the EvidenceHash can be solidified as the effective version to prevent errors from being remembered and propagating across chapters. At the same time, a chained hash audit log connects chapters, slots, evidence, constraints, reference fragments, verification results, and versions, supporting breakpoint continuation and rollback, so that conclusions can be reproduced, evidence can be traced back, and processes can be verified. Attached Figure Description

[0043] Figure 1 This is a schematic diagram of the overall framework of a hierarchical memory multi-round interactive geotechnical report structure generation system provided in an embodiment of the present invention;

[0044] Figure 2 This is a schematic diagram of the chapter task diagram and SlotID metadata constraints in an embodiment of the present invention. Detailed Implementation

[0045] To facilitate understanding of this application, a more complete description will be provided below with reference to the accompanying drawings, which illustrate embodiments of the present application. However, the present application can be implemented in many different forms and is not limited to the embodiments described herein. Rather, these embodiments are provided so that the disclosure of this application will be thorough and complete.

[0046] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the application.

[0047] Example 1:

[0048] refer to Figure 1 This embodiment provides a hierarchical memory-based multi-round interactive structured generation system for geotechnical reports. Specifically, it offers a structured generation system for generating ultra-long, multi-chapter, and data-dependent geotechnical reports. The system uses chapter task diagrams, machine-readable evidence objects, machine-readable global constraints, structured citation lists, and evidence chain auditing as its main framework. This enables consistency constraints and traceability of cross-chapter data citations and conclusion statements under segmented generation and multi-round revision conditions. The system as a whole includes modules such as template parsing and task diagram construction, data binding and evidence summary generation, global constraint management, prompt arrangement and generation execution, consistency verification and conflict resolution, hierarchical memory management, and evidence chain and auditing.

[0049] refer to Figure 2 The template parsing and structural task graph construction module is used to parse the geotechnical report structural template into a chapter task graph. The chapter task graph includes a set of chapter nodes and a directed acyclic topology structure built based on data dependency edges and conclusion dependency edges. It also assigns a globally unique slot identifier (SlotID) to each field slot in the report.

[0050] The template parsing and structural task graph construction module is used to parse the target geotechnical report structural template and generate chapter task graphs. The chapter task graph contains a set of chapter nodes and a directed acyclic topology constructed from data dependency edges and conclusion dependency edges. Data dependency edges characterize the reference relationships between a chapter and exploration data fields in another chapter, while conclusion dependency edges characterize the dependencies between the conclusions of a chapter and the conclusions or judgment results of prior chapters. This module also assigns a globally unique slot ID (SlotID) to each field slot within the report template, ensuring a unified primary key for the reuse of the same indicator caliber across chapters. This limits the chapter generation order and provides a graph structure foundation for locating the scope of influence.

[0051] To enhance the executability of the task graph in engineering implementation, the system stores the nodes and edges of the chapter task graph in a structured manner. In addition to the chapter identifier and chapter level, each chapter node includes at least: a set of chapter input SlotIDs, a set of chapter output SlotIDs, a set of chapter conclusion keys, and chapter generation strategy parameters (e.g., whether table output is allowed, whether mandatory completeness of the reference list is required, etc.). Data dependency edges at least record: the source chapter identifier, the target chapter identifier, the set of dependent SlotIDs, and the dependency type (numerical reference / unit reference / statistical summary reference); conclusion dependency edges at least record: the source chapter conclusion key, the target chapter conclusion key, and the dependency direction.

[0052] In addition, the SlotID metadata table is fixed as a triple structure:

[0053] Using SlotID as the index key, record the field path, normalization unit, and precision strategy corresponding to that SlotID in the SlotID metadata table;

[0054] Using SlotID as the index key, the set of chapters to which the SlotID applies is recorded in the SlotID metadata table, which is used to limit the range of chapters that the indicator can be cited.

[0055] Using SlotID as the index key, the SlotID metadata table records the anchor ID types or ranges that the SlotID is allowed to reference, which is used to limit the boundaries of the output segments that the metric can be referenced; the precision strategy can be broken down into display precision. and verification accuracy This is used to resolve conflicts in the accuracy of the same indicator in report presentation and consistency verification.

[0056] The data binding and evidence summary generation module is used to bind project survey data to SlotID and generate evidence objects. Based on preset unit mapping rules and dimensional conversion formulas, the module normalizes the units of the evidence objects and calculates the evidence summary hash EvidenceHash.

[0057] The data binding and evidence summary generation module binds project survey data to SlotIDs according to field mapping rules and generates evidence objects. Then, it performs unit normalization on the evidence objects based on preset unit mapping rules and unit conversion formulas, obtaining normalized units and normalized values. Finally, it performs deterministic serialization of key fields of the evidence objects and calculates the evidence summary hash (EvidenceHash). EvidenceHash can detect mismatches in cross-chapter citation calibers and provide a tamper-proof verification benchmark for subsequent audits. Unit normalization employs a two-level mechanism of unit mapping and unit conversion: when the original unit is... Standardized units are At that time, the system obtains the conversion factor k from the unit mapping table. → ) and the necessary offset term b( → ), and calculate the normalized value using the following formula: When indicators need to be statistically summarized (such as average, standard deviation, stratified representative value), the system writes the statistical rules and sample range into the data source identifier / attached attribute of the evidence object to avoid inconsistencies when referencing the same statistical result across chapters. The deterministic serialization of EvidenceHash must at least meet the following constraints: fixed field order, unified numerical format (such as fixed-point representation with fixed decimal places p_chk), units encoded by standard enumeration, null values ​​using unified placeholders, and conversion formula identifiers including version numbers. This can avoid hash jitter caused by different ways of writing the same value, thereby reducing the probability of false alarms and collisions.

[0058] in, Represents the original value. Represents the technical normalization value, k( → b( represents the conversion factor from raw units to normalized units) → The ) indicates the offset term corresponding to the unit conversion, where the original unit is... Standardized units are .

[0059] When performing numerical consistency comparisons, the system prioritizes threshold comparisons over text string comparisons; for example, comparing two references to the same SlotID. and Either an absolute threshold or a relative threshold can be used: ;in, To prevent stable terms with a denominator of 0, Indicates the current reference value. Indicates the base reference value. Indicates the absolute error threshold. This represents the relative error threshold.

[0060] The global constraint management module generates global constraint items based on the evidence object set and the chapter task graph, compiles constraint rules into executable constraint operator sequences and constraint execution plans, and establishes an inverted index for incremental consistency verification. Specifically, global constraint items, as machine-readable constraint units, support at least the following constraint types: unit consistency, numerical consistency, conclusion consistency, and citation completeness. Constraint object identifiers can point to a single evidence identifier, EvidenceHash, or conclusion key to unify the constraint data caliber and conclusion caliber. The inverted index is used to associate EvidenceHash with constraint identifiers, and constraint identifiers with chapter nodes / SlotIDs / output fragments, etc., so as to quickly locate the affected constraints and fragment ranges after data or conclusion changes, and realize incremental execution that only checks the affected subgraphs. To ensure the reproducibility and schedulability of constraints, the system uniformly represents constraint rules as IR / AST, and records the IR version number and compilation version number when writing to the database. The IR / AST node types can include at least: unit normalization node, numerical comparison node, conclusion key matching node, reference completeness assertion node, and cause code generation node. During the compilation stage, the above nodes are mapped to a sequence of constraint operators, such as: LoadCitation→ResolveEvidence→CheckUnit→CheckValue→Assert→EmitReasonCode, where LoadCitation is used to load the reference corresponding to the target anchor ID from the structured reference list. The system includes three sets of constraint execution plans: Entries; ResolveEvidence is used to resolve the corresponding evidence object based on the evidence identifier or EvidenceHash in the referenced entry; CheckUnit is used to perform unit consistency checks; CheckValue is used to perform numerical consistency checks; Assert is used to assert the verification results and form pass / fail conclusions; EmitReasonCode is used to generate and output conflict reason codes and related information when an assertion fails, to be written into the conflict list and drive subsequent differential rewriting; In addition to the operator sequence, the constraint execution plan explicitly records three sets: Dependent Evidence Set: the set of EvidenceHashes that must be covered; Covered Slot Set: the set of SlotIDs that must be covered; Affected Fragment Set: the set of anchor IDs that may trigger repair; When the constraint execution plan changes (such as adjusting the threshold or adding a reference completeness rule), the system only updates the affected constraint items and inverted index entries, and maintains the traceability of old and new rules through the version field.

[0061] The prompt orchestration and generation execution module outputs chapter text prompts containing anchor ID boundary markers to the generation model and receives the generated chapter content and a structured citation list corresponding to the anchor IDs. The structured citation list serves as the sole reliable source of citations for consistency verification. In other words, the system divides the chapter output into locatable fragment units (anchor IDs) and requires each fragment to simultaneously generate machine-readable citation entries (such as SlotID, EvidenceHash, and normalized values). With standardized units (etc.), to prevent uncontrollable situations where text contains data / conclusions but lacks machine-readable citation evidence, thus laying the input foundation for subsequent automatic verification and evidence chain solidification; the generation of anchor IDs uses deterministic encoding of chapter ID and segment number or chapter ID and subheading path hash, ensuring the stability of anchor IDs for the same chapter in multiple revisions, thereby facilitating differential repair positioning. The system imposes strong constraints on the structured citation list in the prompts: each anchor ID must return a list of citation entries; each entry must contain at least SlotID, EvidenceHash, , Data source identification Optionally includes statistical rule identifiers Precision strategy identifier Location markers Meanwhile, the system can set a reference completeness threshold: when the anchor ID fragment contains a specific type of statement (such as containing numerical values, conclusion key trigger words, or normative clause reference trigger words), a corresponding reference entry must exist; otherwise, the cause code (such as R001) will be output directly and the conflict handling process will begin.

[0062] It should be noted that, in this embodiment, the generative model is used to generate the chapter content of the geotechnical report based on the prompt input. The generative model can be an existing text generation model or a large language model (such as a generative language model based on the Transformer architecture). This invention does not limit its specific network structure or parameter scale. The generative model can run locally or be called through a remote interface. The system submits prompt input to the generative model through the prompt orchestration module. The prompt input includes at least the chapter template skeleton, the summary of the evidence object associated with this chapter (including normalization units, normalization values, and EvidenceHash), the summary of the applicable global constraint items / constraint execution plans, and the output constraint rules. The output constraint rules require the generative model to write paired anchor ID boundary markers in the chapter text and simultaneously output a structured citation list corresponding to each anchor ID. The system uses this structured citation list as the only reliable citation source for consistency verification, and when conflicts occur, it uses differential prompts to only allow the rewriting of specified anchor ID fragments, thereby ensuring the consistency and traceability of cross-chapter citations.

[0063] The consistency verification and conflict resolution module performs incremental consistency verification based on the constraint execution plan and structured reference list, according to the change impact set and chapter task graph closure, and outputs a machine-readable conflict list. Simultaneously, it drives the partial rewriting of only specified conflict anchor point ID segments and performs out-of-bounds rejection using a differential hint mode. Specifically, when the evidence object or conclusion version changes, the system calculates the change impact set through an inverted index, obtains the affected subgraph by finding the closure on the chapter task graph, and executes the constraint operator sequence only on that subgraph. The verification results are output in machine-readable form, including conflict type and conflict cause code information, facilitating automated processing. During differential revision, the system only allows rewriting of anchor ID fragments assigned to the conflict and performs out-of-bounds rejection checks on unassigned fragments to ensure that the change boundaries are controllable and auditable during multiple revision rounds. The calculation of the change impact set follows the chain of evidence first, then constraints, and then fragments: when an EvidenceHash changes, the set of affected constraints is first obtained from the inverted index. Then by Mapped to the set of affected chapter nodes With the set of affected fragments ;in, This represents the set of constraints associated with the current EvidenceHash. This represents the set of chapter nodes affected by the aforementioned constraint. This indicates a set of anchor point ID fragments that need to be re-verified or rewritten; on the chapter task graph... The closure can be expressed as a formula: ;in, Represents the set of chapter nodes Dependency closure results in the chapter task graph; Indicates the affected chapter nodes; Indicates chapter nodes reachable through dependencies; symbol Indicates from chapter node To Chapter Node There is a dependent reachable path.

[0064] Furthermore, the dependency reachable path includes directed paths formed by data dependency edges or conclusion dependency edges, used to represent data reference relationships or conclusion derivation relationships between chapters; the system only... Incremental consistency checks are performed on internal nodes, thereby avoiding a full recalculation of all chapters and improving the efficiency and response speed of checks in multi-round revision scenarios.

[0065] In some implementations, the system may also be based on the set of affected fragments. Further restricting the scope of difference rewriting, only allowing the generative model to work on the set. The corresponding anchor ID fragment is partially regenerated, while those not included in the set are regenerated locally. The anchor ID fragment performs content locking and out-of-bounds rejection checks to reduce the risk of non-target content being mistakenly modified during multiple revisions.

[0066] In addition, the machine-readable conflict list has fixed fields: , , , , , , , (Normalized value / unit / version) , .in, This is used to indicate handling strategies such as re-reference / rewrite / rollback / regeneration, reducing subsequent interaction rounds. Specifically, (Conflict record identifier, used to uniquely identify a conflict record) (Constraint identifier, used to indicate the global constraint that triggered the conflict) (Conflict type, used to describe the category to which the conflict belongs, such as inconsistent units, inconsistent values, inconsistent conclusions, missing citations, or duplication and redundancy, etc.) (Conflict cause code, used to identify the specific cause of the conflict in an enumerated code form, which facilitates machine processing and statistics.) (Chapter identifier, used to locate the chapter node where the conflict occurred) (Output segment identifier, used to locate the specific output segment boundary unit where the conflict occurred) (Slot identifier or conclusion key, used to specify the primary key of the object with conflicting associations, where) Conflicting definitions of corresponding data indicators (Conflict in the corresponding conclusions) (Expected caliber information, used to record the normalized values, normalized units, or version information that should be met according to the constraint rules or effective version.) (Actual caliber information, used to record the actual values, units, or version information detected in the currently generated text or citation list), and (Action prompts are provided to suggest handling strategies, such as re-references, partial rewrites, version rollbacks, or regenerations, to reduce subsequent interaction rounds and accelerate conflict convergence).

[0067] The hierarchical memory management module maintains short-term and long-term memory, and submits candidate versions as effective versions only when the associated constraint items pass verification and the EvidenceHash matches the execution plan requirements. Short-term memory holds the intermediate state of the current generation / revision round, while long-term memory stores entries indexed by conclusion and indicator keys. Each long-term memory entry includes at least the conclusion text or indicator value, a set of associated evidence identifiers, a set of associated EvidenceHash values, a set of associated constraint identifiers, verification status, version identifier, a candidate version pool, and the effective version. When verification fails, the candidate version is retained in the candidate version pool, and the conflict reason code is recorded, thus maintaining cross-chapter consistency and backtracking under multi-round interactions and segmented generation conditions.

[0068] It should be noted that the submission of a candidate version as the effective version can adopt a combination of hard threshold and coverage verification rules: the hard threshold is that all associated constraints pass; the coverage verification is that the EvidenceHash set and SlotID set required by the execution plan are satisfied; the set inclusion relationship can be expressed as follows: ;in and These are the evidence set and slot set required by the execution plan, respectively. and This is the set of candidate versions actually covered in the citation list and evidence chain; if this condition is not met, the candidate version is retained in the candidate pool and the reason code and gap set are recorded, which facilitates automatic upgrades after subsequent supplementary evidence or partial repairs.

[0069] The evidence chain and auditing module is used to generate and store chained hash audit logs containing anchor IDs, EvidenceHash, and verification results. The system uses evidence chain records as traceable and auditable structured record units. Evidence chain record fields include at least the chapter node identifier, output fragment identifier (anchor ID), output fragment position identifier, SlotID, evidence identifier, EvidenceHash, constraint identifier, referenced normalized value and normalized unit, verification result identifier, version identifier, timestamp, PrevChainHash (prev chain digest), and ChainHash (chain digest). The ChainHash is obtained by deterministically serializing the current evidence chain record and the PrevChainHash to support auditing and anti-tampering verification. Therefore, the conclusion of any chapter fragment can be traced back to the version of the referenced evidence object (EvidenceHash) and the constraints and verification results it passed, achieving cross-chapter consistency and unified management of the evidence chain.

[0070] It should be noted that chained hashing calculates an immutable chain using record digests and preorder digests; for the... The evidence chain records are obtained by first performing deterministic serialization on key fields. Then calculate: ;in For hash functions, For serial operation, and When any historical record field (such as EvidenceHash, referenced normalized value, verification result) is tampered with, it will cause the entire ChainHash to mismatch, thus providing verifiable evidence for auditing.

[0071] Specifically, i: represents the sequence number of the evidence chain record; : indicates the first The record summary input for each chain of evidence is obtained by deterministically serializing the key fields in the record. Key fields may include anchor ID, SlotID, EvidenceHash, normalized value of the reference, normalized unit of the reference, verification result, version identifier, timestamp, etc. : indicates the first Each chain of evidence records a chain digest, which is used to uniquely represent the content of the current record and the state of its preceding chain. : indicates the first The digest of the preceding chain referenced by each chain of evidence record is equal to the value of the first chain. Chain summary of the chain of evidence records ; : Represents a hash function, used to map input content to a fixed-length digest value; : Indicates a serial operation, that is... and Concatenated in a preset order, the data is used as input to the hash function. : Represents the evidence digest hash, used to identify the normalized data caliber of the cited evidence object.

[0072] In this embodiment, the evidence object is a machine-readable structure used for cross-chapter citation and verification. Its fields include evidence identifier, SlotID, data source identifier, indicator name, original indicator unit, normalized unit, original value, normalized value, unit conversion formula identifier, precision strategy, applicable chapter set, citation fragment identifier set, verification status, and EvidenceHash. The precision strategy includes rounding rules and error thresholds. The EvidenceHash is a hash value calculated by deterministically serializing the fields, which at least include the evidence identifier, SlotID, normalized unit, normalized value, and unit conversion formula identifier, and is used for citation mismatch detection and audit anti-tampering verification.

[0073] It should be noted that the evidence object, as the smallest reliable data unit reused across chapters, plays a core role in unifying and solidifying the data source, unit caliber, numerical caliber, applicable range, verification status, and tamper-proof summary, making it machine-readable. This allows any chapter to cite the evidence using SlotID as the primary key and normalized units / normalized values ​​as the unique comparison criteria. The evidence identifier is used to uniquely identify the evidence object and can use a globally unique code or a combination of the source primary key and version number. The data source identifier points to the survey point number, sample number, test number, database record primary key, or file summary. Waiting is required to allow evidence to be traced back to the original record; indicator names are for human-readable interpretation, but internal system consistency checks primarily use SlotID with indicator names as a secondary measure to avoid mismatches caused by identical text names; original indicator units and original values ​​are used to retain input standards, standardized units and standardized values ​​are used to solidify consistent standards across chapters, and dimensional conversion formula identifiers are used to point to unit mapping / conversion rules and their versions, ensuring that when conversion rules are updated, the formula and version used can still be traced back; to avoid drift caused by mixing presentation precision and verification precision, the precision strategy preferably includes display rounding rules (used for...). The report output includes a verification error threshold (used for consistency judgment), where the error threshold can be configured as an absolute threshold or a relative threshold, and is preferably configured by SlotID to maintain consistency across chapters; the applicable chapter set is used to constrain which chapters the evidence is allowed to be cited in, and the citationable fragment identifier set is used to further constrain which anchor ID fragment types or ranges are allowed to be cited (e.g., allowed to enter the indicator summary section but not allowed to directly enter the conclusion section), to reduce the logical risk caused by the misuse of evidence; the verification status is used to record whether the evidence object has completed unit normalization, field legality verification, and locking status (e.g., not verified). ( / Standardized / Locked / Deprecated), and used as an access condition for subsequent generation and verification processes; in addition, EvidenceHash is calculated after deterministic serialization to ensure that the hash of the same evidence caliber is stable in multiple rounds of interaction, preferably satisfying: fixed field order, fixed numerical format (such as fixed decimal places or unified scientific notation), enumeration encoding of units, consistent null value placeholder rules, and conversion formula identifiers including version numbers; thus, EvidenceHash can be used simultaneously for reference mismatch detection and audit anti-tampering verification; optionally, EvidenceHash calculation can be expressed as: Where Serialize is the deterministic serialization process, and H is the hash function. This indicates the dimensional conversion formula identifier, including the version number, so as to distinguish different calculation methods when the conversion rules are updated.

[0074] In addition, the global constraint set consists of multiple global constraint items, which are machine-readable constraint units. The fields include constraint identifier, constraint object identifier, constraint type, applicable chapter set, intermediate representation of constraint rules, compiled constraint operator identifier set, constraint execution plan, and verification status. The constraint object identifier is used to point to a single evidence identifier, EvidenceHash, or conclusion key. The constraint type includes unit consistency, numerical consistency, conclusion consistency, and reference completeness. The consistency verification and conflict handling module outputs machine-readable verification conclusions and conflict reason codes based on the constraint execution plan.

[0075] It should be noted that, in this embodiment, the global constraint term elevates the requirement for consistency across chapters from a natural language description to a machine-readable, compileable, and executable constraint unit; the constraint identifier is used to uniquely locate a constraint, and can be derived from the constraint type, constraint object identifier, and summary of the applicable chapter set to improve retrieval and reuse efficiency; the constraint object identifier is used to uniformly point to three types of constrained objects: first, it points to the evidence identifier, used to constrain the consistency of the same evidence when cited in multiple places; second, it points to the EvidenceHash, used to force the citation to be bound to a specific evidence version to avoid citation drift; third, it points to the conclusion key, used to constrain the consistency of the expression of the same conclusion in different chapters and to align with the effective version; the constraint type includes at least unit consistency, numerical consistency, conclusion consistency, and citation completeness: unit consistency is used to assert that the citation unit is equal to the normalized unit of the evidence object; numerical consistency is used to assert that the normalized value of the citation is consistent within a threshold range; conclusion consistency is used to assert that the text version corresponding to the conclusion key is consistent with the effective version in long-term memory; citation completeness is used to assert that... When key data or key conclusions trigger statements, the corresponding evidence object / EvidenceHash entry must be provided in the structured citation list; the applicable chapter set is used to limit the execution boundary, so that the constraints can be executed with differentiated strategies for different semantic domains such as indicator chapters / conclusion chapters / table chapters; the intermediate representation of constraint rules preferably adopts the IR / AST structure, and at least explicitly includes threshold parameters, unit enumeration, dependency object set, failure short-circuit strategy and reason code generation strategy; the compiled constraint operator identifier set is used to record the operator sequence (such as citation retrieval, evidence parsing, unit checking, numerical comparison, conclusion key matching, assertion and reason code output, etc.) compiled by IR / AST, so as to ensure that the constraints are reproducible and auditable; the constraint execution plan is used to support incremental verification scheduling, and preferably explicitly records the EvidenceHash set that must be covered, the SlotID set that must be covered, the set of affected chapter nodes and anchor IDs, execution priority and failure short-circuit strategy (for example, execute the citation completeness assertion first and then execute the numerical comparison to avoid misjudgment due to lack of citations). The verification status is used to record whether the constraint is executable, the most recent verification result, and the failure reason code, so that the system can quickly determine the range of constraints that need to be recalculated after data or rule updates. The consistency verification and conflict handling module outputs machine-readable verification conclusions and conflict reason codes after executing the constraint execution plan. The conflict reason codes are preferably enumerated and managed, and written into the conflict list and evidence chain to support the accurate positioning and traceable closed loop of subsequent differential repair.

[0076] In this embodiment, the evidence chain record is a structured record used to achieve traceability and auditability of the generated results. Its fields include chapter node identifier, output fragment identifier anchor ID, output fragment position identifier, SlotID, evidence identifier, EvidenceHash, constraint identifier, normalized value of reference, normalized unit of reference, verification result identifier, version identifier, timestamp, previous chain digest PrevChainHash, and chain digest ChainHash. The chain digest ChainHash is calculated deterministically by performing a serialization calculation on the current evidence chain record and the previous chain digest PrevChainHash to support auditing and anti-tampering verification.

[0077] It should be noted that the evidence chain record is used to solidify text fragments, cited evidence, constraint verification, and version evolution into an auditable structure, thereby achieving traceability and tamper-proof verification of any report fragment; the chapter node identifier is used to point to the chapter task graph node, ensuring that the fragment can be located on the generation scheduling graph; the output fragment identifier anchor ID is used to split the chapter text into the smallest controllable revision unit, which is also the boundary between differential rewriting and out-of-bounds rejection; the output fragment position identifier is used to accurately locate the position of the anchor ID in the report, which can be one or a combination of chapter ID-anchor ID-character range, row and column number, or sentence number; SlotID, evidence identifier, and EvidenceHash are used to reference the fragment to the evidence object. Evidence versions are bound and locked, allowing for quick location of segments requiring re-verification / rewriting when EvidenceHash changes; constraint identifiers record the set of constraints effective for the segment, while referenced normalized values ​​and units record the actual reference scope of the segment and serve as input for consistency verification; verification result identifiers record verification pass / fail and corresponding reason code summaries, and can also point to conflict list entries; version identifiers record chapter and conclusion versions, supporting rollback and parallel auditing; timestamps form the audit timeline; PrevChainHash and ChainHash implement chained hash auditing, with the system deterministically serializing key fields of this record to obtain a message digest. And calculate: ;in Any tampering with any historical record field will cause the entire ChainHash to mismatch, thus achieving tamper-proof verification and verifiable traceability.

[0078] In this embodiment, long-term memory stores long-term memory entries using conclusion keys and indicator keys as indexes. Long-term memory entries include conclusion keys or indicator keys, conclusion text or indicator values, a set of associated evidence identifiers, a set of associated EvidenceHash, a set of associated constraint identifiers, verification status, version identifier, a candidate version pool, and an effective version. The hierarchical memory management module submits the candidate version as the effective version only when the associated constraint item passes the verification and the EvidenceHash set matches the constraint execution plan. Otherwise, the candidate version is kept in the candidate version pool and the conflict reason code is recorded.

[0079] It should be noted that long-term memory is used to maintain a stable caliber of the same conclusion key / indicator key under multi-round interaction and segmented generation conditions, and to prevent the solidification and propagation of content that has not been globally verified through candidate-effective governance; the conclusion key or indicator key serves as the primary index key, used to aggregate the same conclusion or indicator across chapters into the same long-term memory entry; the conclusion text or indicator value is used to store reusable output, where the indicator value is preferably stored in normalized units and normalized values ​​and the presentation template is retained to balance machine-readable verification and human-readable output; the associated evidence identifier set and the associated EvidenceHash set are used to record the evidence set and evidence version locking relationship that the entry depends on. When the EvidenceHash changes, it can trigger the impact set calculation and prevent implicit caliber drift; the associated constraint identifier set is used to record the set of global constraints that the entry must satisfy, the verification status is used to record the verification conclusion under the current evidence version and rule version, and the version identifier is used for version governance and rollback; the candidate version pool is used to store versions that have not yet met the submission conditions, and the effective version is used for cross-chapter default reference, thereby ensuring consistency. When submitting candidate versions, the hierarchical memory management module uses a combination of criteria: all associated constraints pass and evidence version coverage matches the execution plan. The preferred method for matching the execution plan is to express it using a set inclusion relationship. ; The execution plan requires the coverage of the EvidenceHash set. This is the set of EvidenceHash actually referenced by the candidate version; if the conditions are not met, the candidate version is retained in the candidate version pool and the conflict reason code and gap information are recorded so that it can be submitted again after subsequent supplementary verification or differential repair.

[0080] Example 2:

[0081] This embodiment provides a hierarchical memory multi-round interactive geotechnical report structure generation method, which applies the hierarchical memory multi-round interactive geotechnical report structure generation system of Embodiment 2, and includes the following steps:

[0082] Step 1) Parse the report structure template, generate a chapter task graph containing chapter nodes, data dependency edges, and conclusion dependency edges, and assign a globally unique SlotID to each field slot;

[0083] In this step, the chapter task graph is a directed acyclic topology. In addition to the chapter identifier and hierarchy, the chapter nodes preferably further solidify the chapter input SlotID set, chapter output SlotID set, chapter conclusion key set, and chapter generation strategy parameters. Data dependency edges preferably record the source chapter, target chapter, dependent SlotID set, and dependency type (numerical reference / unit reference / statistical summary reference). Conclusion dependency edges preferably record the conclusion key dependency direction. SlotID serves as a unified primary key for reusing the same indicator caliber across chapters, providing a foundation for subsequent evidence object binding, constraint generation, and influence closure calculation.

[0084] Step 2) Bind the survey data to SlotID according to the mapping rules to generate evidence objects and normalize the units. Calculate the EvidenceHash for the key fields of the deterministic serialization. The unit normalization includes converting the original indicator units to normalized units according to the unit mapping rules and converting the original values ​​to normalized values ​​according to the dimensional conversion rules. The deterministic serialization of EvidenceHash includes at least SlotID, data source identifier, normalized units, normalized values, and dimensional conversion formula identifiers.

[0085] This step preferably employs a two-level mechanism combining unit mapping and dimensional conversion to solidify a unique comparison caliber; let the original unit be... Standardized units are The conversion factor is Offset item is The normalized value can be obtained by the following formula: For statistical summary indicators (such as mean, standard deviation, stratified representative value), it is preferable to write the statistical rules and sample range into the data source identifier or additional attributes to avoid inconsistencies in the interpretation of the same statistical result across chapters; EvidenceHash, by including at least SlotID, data source identifier, , The fields containing the unit conversion formula identifier (including version) are deterministically serialized before calculation. The serialization process preferably satisfies the following requirements: fixed field order, fixed numerical format, unit enumeration, and consistent null value placeholders. This reduces hash jitter and supports subsequent reference mismatch detection and audit anti-tampering verification.

[0086] Step 3) Generate global constraint terms based on the evidence object and task graph, construct the constraint rules into an executable IR / AST and compile them into a sequence of constraint operators to form a constraint execution plan, and establish an inverted index from EvidenceHash to constraint identifier and from constraint identifier to chapter node, SlotID and anchor ID; wherein the executable IR / AST shall at least contain unit normalization node, numerical comparison node, conclusion key matching node and reference completeness assertion node; the constraint execution plan shall at least contain a set of operator sequence identifiers, a set of dependent EvidenceHash, a set of covered SlotIDs and a set of affected anchor IDs;

[0087] In this step, global constraints must at least cover unit consistency, numerical consistency, conclusion consistency, and citation completeness. IR / AST is used to machine-readable and compile-executable constraint logic, forming an operator sequence (e.g., loading citations → parsing evidence → unit check → numerical comparison → assertion → outputting reason code) and writing it into the constraint execution plan to support reproducible verification. The inverted index establishes at least two links: one is EvidenceHash → constraint identifier set, used to quickly locate affected constraints when data changes; the other is constraint identifier → (chapter node, SlotID, anchor ID) set, used to directly locate the segment range that needs to be verified and repaired, thereby supporting subsequent incremental consistency verification to be performed only on the affected subgraph.

[0088] Step 4) Initialize short-term memory and long-term memory containing candidate pools / effective versions; short-term memory is used to carry the intermediate state of the current round of generation and revision (e.g., current chapter summary, candidate conclusions, set of anchor IDs to be fixed, and outstanding conflicts); long-term memory is indexed by conclusion key and indicator key, and contains candidate version pool and effective version, used for cross-chapter reuse and cross-round consistency maintenance; this initialization should also load the constraint rule version and evidence object index corresponding to this project to ensure that the subsequent execution plan and verification criteria are consistent.

[0089] Step 5) Select chapter nodes that satisfy the dependencies to construct the prompt input, limiting the output to include the anchor ID boundary markers corresponding to the SlotID and a structured reference list that corresponds one-to-one with the anchor ID; and in step 5), receive expert feedback and convert it into a structured feedback object. The structured feedback object should at least include a feedback location identifier, a feedback type identifier, a modification instruction, an associated evidence identifier or conclusion key, and a priority identifier, and update the output constraint rules, evidence object verification status, and global constraint rules or long-term memory entries accordingly; in this step, the chapter selection should satisfy the topological dependency of the chapter task graph; the prompt input preferably includes: a summary of the evidence objects required for this chapter, a summary of the relevant effective conclusion keys, and a summary of the constraint execution plan that this chapter must satisfy, and calls the generation model to force the output anchor. The ID boundaries correspond one-to-one with the structured citation list; the structured citation list items preferably include at least SlotID, EvidenceHash, normalized unit, normalized value, and data source identifier, ensuring that the citations are machine-readable and traceable from a mechanism perspective; for expert feedback, this embodiment uses it as an external constraint input for structured access: the feedback location identifier can point to the chapter ID / anchor ID / sentence number, the feedback type identifier is used to distinguish data correction / expression adjustment / redundancy removal / supplementary citation / threshold adjustment, etc., the modification instruction is used to describe the expected action, the associated evidence identifier or conclusion key is used to determine the affected object, and the priority identifier is used for the order of handling conflicts; the system updates the constraint rules or evidence status accordingly and triggers the corresponding impact set calculation, providing a basis for subsequent incremental verification and differential repair.

[0090] Step 6) Call the generation model to obtain the chapter text and structured citation list; this step should output the chapter text and structured citation list as the same transaction and submit them to the subsequent process; when the citation list is missing, the format is illegal, or it cannot correspond one-to-one with the anchor ID, it is preferable to directly determine that the citation completeness has failed and enter the conflict handling process to avoid the presence of data in the text but the citation basis is not machine readable.

[0091] Step 7) Generate an evidence chain record and calculate a chain hash audit digest using the structured reference list as the sole reference basis; this step uses the anchor ID as the smallest audit unit, writes the SlotID, EvidenceHash, normalized value / unit, association constraint identifier, and verification result of the referenced segment into the evidence chain record, and calculates the chain hash digest to achieve tamper-proof auditing; optionally, for the first The key fields of the evidence chain records are serialized deterministically. The chain digest can then be calculated using the following formula: ;in Therefore, any alteration of a historical fragment will lead to a mismatch in the subsequent chain digest, thus enabling verifiable traceability.

[0092] Step 8) Calculate the change impact set by inverted index and obtain the affected subgraph by calculating the closure on the task graph. Perform incremental consistency checks only on the affected subgraph and output a conflict list. The unit consistency check and numerical consistency check use normalized units and normalized values ​​as the sole comparison criteria, and output conflict reason codes using preset absolute or relative error thresholds. Step 8) further includes a duplication suppression check: calculate the similarity between newly generated paragraphs and already generated paragraphs; if the similarity reaches a threshold, generate duplicate conflict items and write them to the conflict list. In this step, the impact set calculation preferably follows the chain of evidence first, then constraints, then fragments: EvidenceHash change → locate the affected constraint set → map to the affected chapter and anchor ID set; subsequently, calculate the closure on the affected chapter on the chapter task graph, and perform checks only on the closure subgraph to reduce the cost of full recalculation. The closure can be represented as: ;in This indicates the existence of a dependent reachable path; unit consistency check is performed using... It is a unique caliber; numerical consistency verification is based on It uses a unique caliber and employs a threshold judgment, for example, for two referenced values. and Either an absolute threshold or a relative threshold can be used: or ;in If the condition is not met, the corresponding conflict reason code is output and written to the conflict list; the duplication suppression check is used to manage cross-chapter redundancy: by calculating the similarity between the newly generated paragraph and the already generated paragraph, if the similarity reaches the threshold, a duplication conflict item is formed, and the paragraph identifier, threshold and suggested handling action are recorded in the conflict list to provide input for subsequent differential handling.

[0093] Step 9) Based on the conflict list differential prompts, only the specified anchor ID is rewritten, and out-of-bounds rejection is allowed. If it still fails after a preset number of rounds, it is regenerated. Out-of-bounds rejection includes comparing the text summary or location summary within the boundary of the non-assigned anchor ID before and after rewriting. If there are changes or the anchor ID boundary marker is missing, it is rejected and another differential rewriting is triggered. In step 9), expert feedback is received and converted into a structured feedback object, and the output constraint rules, evidence object verification status, global constraint items, or long-term memory entries are updated accordingly. When the conflict list contains duplicate conflict items, step 9) triggers merging, rewriting, or deletion accordingly, and writes the paragraph identifier, threshold, and handling action into the evidence chain and audit log. This step is driven by the conflict list and performs a minimum range of differential repair on the conflict anchor ID fragment: The input hints preferably include the original text of the conflicting fragment, the relevant EvidenceHash and normalized value / unit, a summary of applicable constraints, and the expected output boundary, thereby enabling only the fragments that need to be modified to be changed; out-of-bounds rejection is used to ensure that the boundary of forced revision is controllable: the system compares the text summary (or position summary) of the non-assigned anchor ID before and after rewriting. If there is a change or the anchor ID is missing, it is determined to be out of bounds and rejected, triggering a differential rewrite to avoid introducing unaudited changes; for the closed-loop handling of expert feedback, this step can directly map the feedback into differential repair instructions or constraint update instructions; for duplicate conflict items, it is preferred to perform merging / rewriting / deletion according to the action_hint of the conflict list, and solidify the handling action and threshold into the evidence chain to ensure that the redundancy removal is also auditable and traceable.

[0094] It should be noted that expert feedback refers to corrective opinions provided by personnel with geotechnical engineering review capabilities (such as project chief engineers, review experts, or project leaders) for generated or differentially rewritten chapter fragments. This feedback addresses the difficulty of automatically determining corrective actions based solely on data when the generated model faces multiple reasonable engineering interpretations or requires adherence to standardized terminology. Expert feedback is preferably integrated into the system in the form of structured feedback objects to ensure machine readability, traceability, and reusability. Structured feedback objects should include at least: a feedback location identifier (used to locate the chapter node and output fragment identifier anchor ID, and further to the sentence number or character range if necessary), a feedback type identifier (used to distinguish between categories such as interpretation correction, evidence replacement, description rewriting, redundancy removal and merging, threshold adjustment, or supplementary citations), modification instructions (used to describe the specific editing actions or generation constraints to be performed), associated evidence identifiers or conclusion keys (used to indicate the EvidenceHash / evidence object to be bound or replaced, or the long-term memory effective conclusion version to be aligned), and a priority identifier (used to determine the execution order when multiple feedbacks conflict). After receiving structured feedback, the system preferentially performs at least one of the following actions: First, it maps the feedback to differential prompt input, partially rewrites only the anchor ID segment pointed to by the feedback location identifier, and re-triggers consistency verification after rewriting; Second, it updates the intermediate representation and execution plan of the output constraint rules or global constraint items according to the feedback, so as to solidify the expert's statements into constraints for subsequent generation and verification; Third, it updates the verification status or long-term memory entries (including candidate version pool / effective version) of the evidence object according to the feedback, so that subsequent chapter generation prioritizes the reuse of effective statements and expressions. Through the above mechanisms, expert feedback is not only used to correct the current segment, but can also be precipitated as global constraints and memory entries in a machine-readable manner, thereby reducing the probability of the same conflict recurring in multiple rounds of interaction and maintaining cross-chapter consistency and traceability of the evidence chain.

[0095] Step 10) After verification, update the long-term memory entries based on the evidence chain record and verification results. Submit the version that passes verification and whose referenced EvidenceHash set meets the constraint execution plan requirements as the effective version. Otherwise, write it into the candidate pool and record the conflict reason code. This step uses verification as the hard threshold for effective submission and uses evidence coverage matching the execution plan as the coverage threshold: only when the EvidenceHash set referenced by the candidate version covers the set required by the execution plan is it submitted as the effective version; otherwise, it is retained in the candidate pool and the conflict reason code and gap information are recorded, which is convenient for subsequent supplementary verification or automatic upgrade after differential repair. This governance strategy is consistent with the hierarchical memory submission rules in the system embodiment and is used to continuously maintain the stability of cross-chapter conclusions and indicator calibers.

[0096] Step 11) After completing the target node of the chapter task diagram, export the report according to the structure template and output the audit log containing the evidence chain, global constraint verification results and conflict handling history. The output of this step preferably includes at least: the report text, the compilation of the structured reference list, the global constraint verification results, the conflict handling history (including the cause code and handling action), the evidence chain and the chain hash digest, so as to form a complete delivery that is readable, machine-readable, and traceable.

[0097] It should also be noted that breakpoint states are saved during the chapter traversal generation process to support breakpoint continuation and version rollback. The breakpoint state includes at least the set of completed chapter nodes, the set of chapter version identifiers, the set of evidence objects or their indexes, the set of global constraints or their indexes, the evidence chain record and chain hash digest, short-term memory snapshot, long-term memory snapshot and conflict list history. During rollback, the breakpoint state corresponding to the target version is restored and steps 5) to 11) are continued. In this embodiment, the breakpoint state is used as a recoverable snapshot of the chapter traversal generation, preferably saved to disk after each chapter is completed, each differential rewrite is completed, or each round of verification is completed. When rollback trigger conditions occur (such as expert feedback requiring rollback, key evidence updates causing large-scale conflicts, or exceeding the preset repair rounds), the system restores the breakpoint state corresponding to the target version and re-enters the generation-verification-repair closed loop from step 5) to ensure that the generation of ultra-long reports and multiple rounds of interactive revisions can still be stably executed in private deployments or computing power-limited scenarios.

[0098] The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A hierarchical memory-based multi-round interactive structured generation system for geotechnical reports, characterized in that, include: The template parsing and structural task graph construction module is used to parse the geotechnical report structural template into a chapter task graph. The chapter task graph includes a set of chapter nodes and a directed acyclic topology structure built based on data dependency edges and conclusion dependency edges. It also assigns a globally unique slot identifier SlotID to each field slot in the report. The data binding and evidence summary generation module is used to bind project survey data to SlotID and generate evidence objects. Based on preset unit mapping rules and dimensional conversion formulas, the module normalizes the units of the evidence objects and calculates the evidence summary hash EvidenceHash. The global constraint management module is used to generate global constraint items based on the generated set of evidence objects and the chapter task graph, compile the constraint rules into an executable sequence of constraint operators and a constraint execution plan, and establish an inverted index for incremental consistency verification. The prompt arrangement and generation execution module is used to output chapter text prompt input containing anchor point ID boundary markers to the generation model and receive the generated chapter content and the structured reference list corresponding to the anchor point ID. The structured reference list serves as the only reliable reference source for consistency verification. The consistency verification and conflict handling module is used to perform incremental consistency verification based on the constraint execution plan and structured reference list according to the change impact set and chapter task graph closure, output machine-readable conflict list and drive only the specified conflict anchor point ID fragment to be partially rewritten and out-of-bounds rejection in differential prompt mode; The hierarchical memory management module is used to maintain short-term and long-term memory, and submits the candidate version as the effective version only when the associated constraint item passes the verification and the EvidenceHash matches the execution plan requirements. The evidence chain and audit module is used to generate and store chained hash audit logs containing anchor ID, EvidenceHash, and verification results; The evidence object is a machine-readable structure used for cross-chapter citation and verification. Its fields include evidence identifier, SlotID, data source identifier, indicator name, original indicator unit, normalized unit, original value, normalized value, unit conversion formula identifier, precision strategy, applicable chapter set, set of citationable fragment identifiers, verification status, and EvidenceHash. The precision strategy includes rounding rules and error thresholds. The EvidenceHash is a hash value calculated by deterministically serializing the fields, which at least include the evidence identifier, SlotID, normalized unit, normalized value, and unit conversion formula identifier, and is used for citation mismatch detection and audit anti-tampering verification. The evidence chain record is a structured record used to achieve traceability and auditability of the generated results. Its fields include chapter node identifier, output fragment identifier anchor ID, output fragment position identifier, SlotID, evidence identifier, EvidenceHash, constraint identifier, normalized value of reference, normalized unit of reference, verification result identifier, version identifier, timestamp, previous chain digest PrevChainHash, and chain digest ChainHash. The chain digest ChainHash is calculated deterministically by performing serialization calculation on this evidence chain record and the previous chain digest PrevChainHash to support auditing and anti-tampering verification. The long-term memory stores long-term memory entries using conclusion keys and indicator keys as indexes. Each long-term memory entry includes a conclusion key or indicator key, conclusion text or indicator value, a set of associated evidence identifiers, a set of associated EvidenceHash, a set of associated constraint identifiers, verification status, version identifier, a candidate version pool, and an effective version. The hierarchical memory management module submits the candidate version as the effective version only when the associated constraint item passes the verification and the EvidenceHash set matches the constraint execution plan. Otherwise, the candidate version is kept in the candidate version pool and the conflict reason code is recorded.

2. The hierarchical memory multi-round interactive geotechnical report structure generation system according to claim 1, characterized in that, The global constraint set consists of multiple global constraint items, which are machine-readable constraint units. The fields of each global constraint item include constraint identifier, constraint object identifier, constraint type, applicable chapter set, intermediate representation of constraint rule, compiled constraint operator identifier set, constraint execution plan, and verification status. The constraint object identifier is used to point to a single evidence identifier, EvidenceHash, or conclusion key. The constraint type includes unit consistency, numerical consistency, conclusion consistency, and citation completeness. The consistency verification and conflict handling module outputs machine-readable verification conclusions and conflict reason codes based on the constraint execution plan.

3. A hierarchical memory multi-round interactive geotechnical report structure generation method, using the hierarchical memory multi-round interactive geotechnical report structure generation system as described in claim 1 or 2, characterized in that, Includes the following steps: Step 1) Parse the report structure template, generate a chapter task graph containing chapter nodes, data dependency edges, and conclusion dependency edges, and assign a globally unique SlotID to each field slot; Step 2) Bind the survey data to SlotID according to the mapping rules to generate evidence objects and normalize the units, and calculate the EvidenceHash for the key fields of deterministic serialization; Step 3) Generate global constraint terms based on the evidence object and task graph, construct the constraint rules into an executable IR / AST and compile them into a sequence of constraint operators to form a constraint execution plan, and establish an inverted index from EvidenceHash to constraint identifier and from constraint identifier to chapter node, SlotID and anchor ID. Step 4) Initialize short-term memory and long-term memory containing candidate pools / effective versions; Step 5) Select chapter nodes that satisfy the dependencies to build the input prompt, and limit the output to include the anchor ID boundary markers corresponding to the SlotID and the structured reference list that corresponds one-to-one with the anchor ID; Step 6) Call the generation model to obtain the chapter text and structured citation list; Step 7) Generate a chain of evidence record using the structured citation list as the sole citation basis and calculate the chain hash audit digest; Step 8) Calculate the change impact set by inverted index and obtain the affected subgraph by finding the closure on the task graph. Perform incremental consistency check only on it and output the conflict list. Step 9) Based on the conflict list differential prompts, only rewrite the specified anchor point ID and reject out-of-bounds requests. If it still fails after the preset number of rounds, regenerate. Step 10) After the verification is passed, update the long-term memory entries according to the evidence chain record and the verification result. Submit the version that has passed the verification and whose reference EvidenceHash set meets the requirements of the constraint execution plan as the effective version. Otherwise, write it into the candidate pool and record the conflict reason code. Step 11) After completing the target node of the chapter task diagram, export the report according to the structure template and output the audit log containing the evidence chain, global constraint verification results and conflict handling history.

4. The hierarchical memory multi-round interactive geotechnical report structure generation method according to claim 3, characterized in that, In step 2), unit normalization includes converting the original indicator units into normalized units according to unit mapping rules, and converting the original values ​​into normalized values ​​according to dimensional conversion rules; the deterministic serialization of EvidenceHash includes at least SlotID, data source identifier, normalized units, normalized values, and dimensional conversion formula identifiers. In step 8), the unit consistency check and the numerical consistency check use standardized units and standardized values ​​as the only comparison criteria, and output the conflict reason code using a preset absolute error threshold or relative error threshold.

5. The hierarchical memory multi-round interactive geotechnical report structure generation method according to claim 4, characterized in that, The executable IR / AST in step 3) includes at least a unit normalization node, a numerical comparison node, a conclusion key matching node, and a reference completeness assertion node; the constraint execution plan includes at least a set of operator sequence identifiers, a set of dependent EvidenceHash, a set of covered SlotIDs, and a set of affected anchor IDs. The out-of-bounds rejection in step 9) includes comparing the text summary or location summary within the boundary of the non-assigned anchor ID before and after rewriting. If there is a change or the anchor ID boundary marker is missing, the rejection is triggered and a second differential rewriting is initiated.

6. The hierarchical memory multi-round interactive geotechnical report structure generation method according to claim 5, characterized in that, In step 5) or step 9), expert feedback is received and converted into a structured feedback object. The structured feedback object includes at least a feedback location identifier, a feedback type identifier, a modification instruction, an associated evidence identifier or a conclusion key and a priority identifier, and the output constraint rules, evidence object verification status, global constraint rules or long-term memory entries are updated accordingly. Step 8) further includes duplication suppression verification: calculate the similarity between the newly generated paragraph and the already generated paragraph, and if the similarity reaches the threshold, generate a duplicate conflict item and write it into the conflict list. Step 9) triggers merging, rewriting or deletion accordingly, and writes the paragraph identifier, threshold and disposal action into the evidence chain and audit log.

7. The hierarchical memory multi-round interactive geotechnical report structure generation method according to claim 6, characterized in that, This also includes saving breakpoint states during chapter traversal generation to support breakpoint continuation and version rollback. The breakpoint states at least include a set of completed chapter nodes, a set of chapter version identifiers, a set of evidence objects or their indexes, a set of global constraints or their indexes, evidence chain records and chained hash digests, short-term memory snapshots, long-term memory snapshots, and conflict list history. During rollback, the breakpoint states corresponding to the target version are restored, and steps 5) to 11) are continued.

Images