Document retrieval augmented with multi-agent reasoning for auditable legal document generation system

Abstract

The application relates to the technical field of legal information processing and intelligent document generation, and discloses an auditable legal document generation system with graph search enhancement and multi-agent reasoning. The system comprises a data access and preprocessing module, a legal knowledge graph construction and correlation mapping module, a case fact analysis and case subgraph generation module, a graph search enhancement module, a multi-agent arrangement and collaborative reasoning module, a legal document generation module, a consistency verification and manual revision module, and an audit record and feedback updating module. Through structured modeling of case materials, search enhancement, collaborative reasoning, segmented generation, verification and revision, and audit tracing, the generation, review and closed-loop updating of legal documents are realized, and the system is suitable for litigation, arbitration, administrative law enforcement and enterprise legal document processing scenarios.

Description

Technical Field

[0001] This application relates to the field of intelligent generation and review of legal documents, and in particular to an auditable legal document generation system that combines graph retrieval enhancement and multi-agent reasoning. Background Technology

[0002] With the continuous development of artificial intelligence, big data, natural language processing, knowledge graphs, and legal information technology, the demand for intelligent legal document generation technology is increasing in fields such as legal services, judicial assistance, corporate legal affairs, and compliance review. Legal documents such as complaints, answers, legal opinions, review opinions, and compliance review documents typically possess strong standardization, rigor, and professionalism. Their formation process relies not only on the accurate extraction of case facts but also on the comprehensive support of multi-source legal knowledge, including laws and regulations, judicial interpretations, adjudication rules, typical cases, contractual agreements, and industry standards. Against the backdrop of the continuous advancement of digital rule of law and intelligent legal affairs, how to utilize computer technology to achieve automatic understanding of case materials, accurate matching of legal basis, standardized generation of document content, and transparent record-keeping throughout the entire process has become a significant technological requirement in the legal technology field. Especially given the increasing complexity of case types, the rapid increase in the number of documents processed, and the increasingly refined requirements for legal application, traditional methods relying on manual retrieval, summarization, and drafting suffer from low efficiency, long cycles, inconsistent standards, and high review costs, making it difficult to meet the current practical requirements of intelligent, standardized, and auditable legal business processing scenarios.

[0003] Among related technologies, some legal document generation solutions primarily automate document processing through template filling, keyword retrieval, rule matching, or general large-scale model text generation. For example, one type of solution uses preset document templates and fixed field extraction methods to fill the target document with information such as case name, party information, litigation claims, and factual summaries, thereby improving the efficiency of basic document generation. Another type of solution constructs a retrieval system using legal databases, case databases, and historical document databases, providing users with referable legal provisions and similar case content through keyword matching or semantic similarity matching. Still other solutions introduce large-scale language models to generate summaries, question-and-answer formats, or paragraphs from case materials, achieving more flexible document drafting functions. These technologies, to a certain extent, improve the efficiency of legal text processing, reduce basic repetitive labor, and provide initial support for the intelligentization of legal services.

[0004] However, existing technologies still have significant shortcomings. First, current solutions lack a unified structured organization method for multi-source heterogeneous data such as laws and regulations, judicial interpretations, similar case rules, evidentiary materials, contractual agreements, and historical documents. The relationships between data are not adequately expressed, making it difficult to form a stable mapping chain of "case facts—legal relationship—point of contention—legal basis—judgment rules—document structure," resulting in limited overall understanding of complex cases by the system. Second, relying solely on keyword retrieval is easily affected by differences in expression, synonym substitution, and textual noise. While semantic retrieval can improve the recall scope, it usually fails to fully reflect the hierarchical relationships, citation relationships, and application paths within legal knowledge, leading to unstable relevance of search results, unclear sources of evidence, and insufficient depth of similar case comparison, thus affecting the accuracy and persuasiveness of the legal document generation results. Third, existing generative systems mostly adopt single-round or end-to-end text output modes. There is a lack of clear task division and coordination mechanisms between case fact identification, extraction of points of contention, legal provision matching, similar case comparison, document organization, and result review, which easily leads to problems such as omission of facts, miscitation of legal provisions, jumps in argumentation, non-standard format, and inconsistencies in expression. Especially in complex legal business scenarios, without specialized intelligent agents for different processing tasks and a unified orchestration mechanism, the system's generated results often struggle to balance completeness, standardization, and stability. Finally, existing technologies generally lack a traceable recording mechanism for the entire document generation process. They typically cannot fully preserve the retrieval source, reasoning path, model version, call order, generated draft, and manual revision process, resulting in insufficient transparency of the basis for the output results. This makes it difficult to meet the practical needs of legal documents in terms of review, examination, accountability, and quality improvement, and also hinders subsequent experience accumulation and continuous system optimization.

[0005] To address the aforementioned issues, we now design an auditable legal document generation system that combines graph retrieval enhancement with multi-agent reasoning. Summary of the Invention

[0006] This application provides an auditable legal document generation system with graph retrieval enhancement and multi-agent reasoning to solve the problems of scattered data sources, opaque retrieval basis, unverifiable reasoning chain, poor consistency of output results, and difficulty in accumulating and reusing manual revisions in the automatic generation of legal documents in related technologies.

[0007] Firstly, an auditable legal document generation system with graph retrieval enhancement and multi-agent reasoning is provided, comprising the following modules:

[0008] The data access and preprocessing module performs unified access, format standardization, and fragment indexing of case materials, laws and regulations, judicial interpretations, similar case documents, evidence materials, and template documents;

[0009] The Legal Knowledge Graph Construction and Association Mapping Module is a core innovative module. It constructs a heterogeneous legal knowledge graph based on elements such as subjects, events, evidence, legal provisions, similar cases, points of contention, and document structure, and establishes association mappings from fragments to graph nodes.

[0010] The case fact analysis and case subgraph generation module extracts facts, assembles events, identifies points of contention, and binds evidence to the current case text, and generates a case subgraph corresponding to the current case.

[0011] The graph retrieval enhancement module is a core innovative module. Based on the case subgraph, it performs joint retrieval, path expansion, and fusion sorting in the graph database, vector index library, and keyword inverted index library to generate an enhanced basis package.

[0012] The multi-agent orchestration and collaborative reasoning module is the core innovative module. It organizes agents such as fact extraction, dispute identification, legal provision matching, case comparison, document generation and review to carry out collaborative reasoning according to a preset task graph.

[0013] The legal document generation module constructs a document skeleton based on the target document type and writes the case fact chain, dispute chain, basis chain, and evidence chain into the corresponding paragraph slots to generate a structured legal document draft.

[0014] The consistency verification and manual revision module verifies the factual elements, legal basis, evidence chain, format number, and source correspondence in the draft item by item, and records the differences in manual revisions;

[0015] The audit record and feedback update module records the retrieval source, graph path, agent call order, generated version, revision record and final result in a structured manner, forming a traceable audit chain and feedback update queue.

[0016] In some embodiments, the legal knowledge graph construction and association mapping module uses a heterogeneous graph model to uniformly organize legal knowledge units, case fact units, evidence units, and document structure units: Among them, the set of nodes It includes at least the main node, event node, evidence node, legal provision node, similar case node, disputed point node, and document structure node, and the edge set. It includes at least referencing edges, applicable edges, supporting edges, conflicting edges, similarity edges, hierarchical edges, and temporal edges.

[0017] In some embodiments, the subjects, behaviors, evidence and disputes in the same case in the legal knowledge graph construction and association mapping module are aggregated through case identifiers. Laws, regulations, judicial interpretations and similar case rules from different sources are mapped through legal source level, validity level, applicable conditions and update time. A one-to-one or one-to-many correspondence is established between text fragment identifiers and graph node identifiers.

[0018] In some embodiments, the legal knowledge graph construction and association mapping module uses a graph node table, graph edge table, node attribute table, fragment mapping table and graph version table for persistent storage;

[0019] Among them, the graph node table stores node identifier, node type and source identifier; the graph edge table stores start node, end node and relationship type; the node attribute table stores legal provision number, legal source level, cause of action label, dispute label, applicable conditions and statute of limitations status; the fragment mapping table stores fragment number, node number, page number and paragraph number; and the graph version table stores graph construction batch, rule template version and update time.

[0020] Each mapping record in the fragment mapping table contains at least a source document identifier, fragment location identifier, node identifier, and mapping type identifier to maintain traceable associations between legal provisions, similar cases, evidence, and document paragraphs.

[0021] In some embodiments, the graph retrieval enhancement module employs a three-pronged recall approach combining keyword retrieval, semantic retrieval, and graph path retrieval to recall candidate legal provisions, similar case nodes, rule nodes, and evidence nodes associated with the case subgraph, and determines the comprehensive ranking result of the candidate criteria based on the fusion score. , + + =1; where, Indicates the first The combined score of each candidate result. This indicates the keyword retrieval score. Indicates the semantic retrieval score. Indicates the graph path score;

[0022] The graph path retrieval uses the dispute nodes, event nodes, and legal relationship nodes in the case subgraph as the path starting point, performs path expansion within a preset number of jumps in the legal knowledge graph, and outputs the node path sequence, relationship path sequence, and path endpoint type.

[0023] In some embodiments, the enhanced basis package output by the graph retrieval enhancement module includes at least the source fragment identifier, graph path identifier, candidate node identifier, applicable label, legal source level label, similar case identifier, and scoring result;

[0024] The scoring results consist of at least the text relevance, graph path matching degree, legal source authority, timeliness and validity, and evidence support.

[0025] In some embodiments, the graph retrieval enhancement module merges the legal provision numbers for different excerpts of the same legal provision, merges the case numbers for different summary excerpts of the same type of case, and retains the original source identifier, merge identifier, and sorting position identifier for candidate evidence with source conflicts, so as to form a traceable set of candidate evidence; the output method of this joint retrieval, result fusion, and enhanced evidence package is consistent with that of the document.

[0026] In some embodiments, the multi-agent orchestration and collaborative reasoning module includes at least a fact extraction agent, a dispute identification agent, a legal provision matching agent, a case comparison agent, a document generation agent, and a proofreading agent;

[0027] Each intelligent agent executes the task in the order of execution or in parallel according to the preset task graph. The task graph defines at least the preceding task identifier, the succeeding task identifier, the input context field, the output result field, and the trigger condition identifier.

[0028] In some embodiments, the multi-agent orchestration and collaborative reasoning module further includes a unified task context container, which stores at least the case number, fact chain identifier, dispute chain identifier, evidence chain identifier, candidate evidence package identifier, target document type identifier, and current version identifier.

[0029] Intermediate results are passed between agents via message queues and written to a cache table to maintain the continuity of states and the reusability of results in the inference chain.

[0030] In some embodiments, when conflicts arise in the outputs of different agents, the multi-agent orchestration and collaborative reasoning module determines the retention result based on the conflict arbitration score: , + + =1; where, Indicates the first The arbitration score for each candidate conclusion. This indicates that the score is based on the quality score. This indicates the historical adoption stability score. This indicates the score based on consistency with the current case context;

[0031] The conflict arbitration result shall at least record the candidate result identifier, conflict type identifier, arbitration score, retention identifier, and arbitration time identifier, and write the candidate results that are not retained, along with their source basis, calling agent identifier, and conflict reason, into the arbitration record table; the task graph, message interaction, and conflict arbitration shall be consistent with the documentation. Attached Figure Description

[0032] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0033] Figure 1 A flowchart illustrating the overall processing flow of the auditable legal document generation system provided in this application embodiment;

[0034] Figure 2 A flowchart of multi-source legal data access and preprocessing provided for embodiments of this application;

[0035] Figure 3 A flowchart illustrating the construction and association mapping of legal knowledge graphs provided in this application embodiment;

[0036] Figure 4 A flowchart for case fact analysis and case sub-graph generation provided in this application embodiment;

[0037] Figure 5 A flowchart of graph retrieval enhancement and multi-agent collaborative reasoning provided for embodiments of this application;

[0038] Figure 6 This is a schematic diagram of the relationship between nodes in the legal knowledge graph provided in the embodiments of this application;

[0039] Figure 7 A schematic diagram illustrating the binding relationship between legal document paragraphs, legal basis, and evidence fragments provided in this application embodiment;

[0040] Figure 8 A flowchart for audit record and feedback update provided for embodiments of this application;

[0041] Figure 9 Legal knowledge generation graph provided for embodiments of this application;

[0042] Figure 10 This application provides a multi-source data quality score distribution map for its embodiments.

[0043] Figure 11 This is a diagram illustrating the optimized text segment length distribution and segmentation effect provided in an embodiment of this application.

[0044] Figure 12 Confidence distribution diagram of spectral relationships provided in the embodiments of this application;

[0045] Figure 13 A multi-channel retrieval contribution statistics chart provided for embodiments of this application;

[0046] Figure 14 A comprehensive score distribution chart of candidate criteria provided for embodiments of this application;

[0047] Figure 15 A consistency scoring chart for legal document paragraphs provided in this application embodiment. Detailed Implementation

[0048] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0049] This application provides an auditable legal document generation system with graph retrieval enhancement and multi-agent reasoning, which can solve the problems of scattered data sources, opaque retrieval basis, unverifiable reasoning chain, poor consistency of output results, and difficulty in the accumulation and reuse of manual revisions in the automatic generation of legal documents in related technologies.

[0050] Please see Figures 1-10 The auditable legal document generation system based on graph retrieval enhancement and multi-agent reasoning includes the following modules:

[0051] The data access and preprocessing module completes the unified parsing and standardized organization of multi-source heterogeneous data; the legal knowledge graph construction and association mapping module completes the modeling of legal knowledge units and their relationship networks; the case fact analysis and case subgraph generation module completes the construction of local graphs of the core facts, points of contention, and evidence associations of the current case; the graph retrieval enhancement module completes the joint retrieval and sorting of legal provisions, similar cases, rules, and evidence fragments; the multi-agent orchestration and collaborative reasoning module completes the task allocation, message passing, and intermediate result organization among various agents; the legal document generation module completes the document skeleton assembly, paragraph generation, and full-text splicing; the consistency verification and manual revision module completes the item-by-item verification of facts, basis, evidence, and format; and the audit record and feedback update module completes the archiving of process logs, version chains, difference records, and feedback samples.

[0052] I. Data Access and Preprocessing Module

[0053] This module is deployed on the server side, and the input data includes PDF case files, Word versions of complaints, scanned evidence images, text extracted from legal web pages, and historical judgment documents. After integration, a unified document identifier is first generated according to the file type. A three-level index of page numbers, paragraph numbers, and line numbers is established. For scanned pages, character recognition is performed first, and then the recognition results are mapped back to the original page coordinates; for editable text, headings, paragraphs, tables, and attachment tags are directly read. During the text standardization phase, full-width characters are converted to half-width characters, consecutive spaces are compressed into single spaces, and similar terms such as "plaintiff / applicant" and "defendant / respondent" are written into a unified alias dictionary. To measure the usability of a single page of text, a page quality score can be defined as: ;in, Indicates the first Page quality score, This represents the average confidence level of character recognition. The score indicates the completeness of the layout. Indicates the clarity score. + + =1. For example, when a certain page... =0.96、 =0.90、 =0.84, take =0.5、 =0.3、 When =0.2, we can obtain This page will directly proceed to the subsequent segmentation process.

[0054] The segmentation stage uses the title, clause number, paragraph boundaries, and evidence number as joint segmentation points to generate a set of segments. The segment length can be expressed as: ;in, Indicates the first The length of each segment Indicates the starting character position. This indicates the position of the ending character. For example, if a factual passage begins at character 121 and ends at character 268, then... =148. When the fragment length is less than 20 characters, it is merged with adjacent fragments; when the fragment length is greater than 300 characters, it is split again by period, semicolon, and number.

[0055] To facilitate subsequent knowledge graph mapping, this module also writes structured coordinates for each segment. Segment location can be recorded as: ;in, Indicates page number, This represents the coordinates of the top-left corner of the segment. This indicates the width and height of the segment region.

[0056] After the above processing, Module 1 outputs a unified document object, a standardized text object, a fragment index table, and a quality tag table, which serve as inputs for the subsequent legal knowledge graph construction and association mapping module.

[0057] II. Legal Knowledge Graph Construction and Association Mapping Module

[0058] This module receives standardized text objects, fragment index tables, page layout coordinate tables, and quality marker tables output by the data access and preprocessing module. It then constructs a domain knowledge graph for legal document generation in the order of "node identification—relationship extraction—attribute attachment—consistent mapping—graph storage." The graph object in this module consists of a set of nodes and a set of edges. Nodes include legal knowledge nodes, case expression nodes, and document organization nodes. The graph can be represented as follows: ;

[0059] in, For a set of nodes, Let the set be the set of edges. Further, the set of nodes can be divided into: ;in, Represents the set of factual nodes in the case. Represents a set of legal relationship nodes. Represents the set of nodes at the core of the dispute. Represents the set of legal provision nodes. Represents the set of referee rule nodes. Represents the set of similar case nodes. Represents the set of evidence nodes. This represents the set of nodes in the document structure. The edge set is divided into referencing edges, applicable edges, supporting edges, conflicting edges, similar edges, containing edges, and sequential edges according to semantic connection methods, to ensure a stable structural relationship between the case facts, legal basis, judgment rules, and document paragraphs.

[0060] The node construction phase first performs legal entity identification on standardized fragments. The identification objects include the names of the parties, the cause of action, the event, the amount, the date, the legal provision number, the name of the regulation, the name of the evidence, the judgment conclusion, and the document chapter title. Each node is then written with a unified identifier. Node type Source fragment number Standardized names Original text and version number For example, when the same batch of materials contains three different versions of the text, namely "Article 157 of the Civil Code", "Article 157 of the Civil Code of the People's Republic of China", and "Article 157 of the Code", the module will uniformly link them to the same legal article node according to the dictionary of legal names and the article numbering rules, retain only one standard name field, and write the three source fragments into the alias attribute and source attribute respectively.

[0061] The relation extraction stage models the legal semantic connections between fragments. If a fact fragment contains expressions such as "signing a contract," "failure to fulfill payment obligations," or "incurrence of liability for breach of contract," then fact nodes, legal relationship nodes, and dispute focus nodes are generated respectively, and directed relationships are established among the three. The relation extraction result can be recorded as: ;in, Represents a node With nodes Relationship types This is a set of preset relation types.

[0062] To reduce the number of erroneous connections, the module calculates an association confidence score for candidate relationships, expressed as follows: ;in, Indicates the candidate relationship score. This indicates the text co-occurrence matching score. This indicates the score for matching the rule template. This indicates the score based on proximity in the layout. + + =1. For example, the text matching score between a factual passage and a legal provision passage is 0.82, the rule template matching score is 0.90, and the structural proximity score is 0.70. =0.4、 =0.4、 When =0.2, we can obtain =0.828. When this value is higher than the threshold of 0.75, an "applicable" relation edge is written into the graph.

[0063] The attribute linking stage writes fields such as legal level, publication time, validity status, adjudication level, regional label, dispute category, and document location into the node attribute table and edge attribute table. Taking a legal provision node as an example, attributes must at least include the legal provision name, provision number, chapter position, current status, and superior law information; taking a similar case node as an example, attributes must at least include the case number, year of judgment, level of adjudication, cause of action, and key points of judgment; taking a document structure node as an example, attributes must at least include the chapter name, paragraph order, slot number, and required field markers. After this construction, the graph not only preserves the legal knowledge ontology but also the organizational skeleton directly related to document generation.

[0064] The fragment-to-node binding process consists of two stages: candidate selection and final mapping. First, a candidate node set is formed based on a similarity threshold. Then, a comprehensive score is calculated by combining semantic similarity, node type priority, regulatory level, and contextual consistency, and the node with the highest score is selected as the final bound node for that fragment. The fragment-to-node mapping relationship can be represented as follows: ;in, Indicates the first A text fragment, This indicates the degree of matching between fragments and nodes. This represents the mapping threshold. When multiple candidate nodes are mapped to the same fragment, the module sorts them according to the level of regulatory authority, node type priority, and context consistency, and only retains the binding results of the highest-ranked nodes, writing them into the mapping table.

[0065] The graph storage phase employs a five-table structure—node table, edge table, attribute table, mapping table, and version table—for persistent storage. The node table stores node identifiers and type fields; the edge table stores start and end points and relationship types; the attribute table stores expandable fields; the mapping table stores the correspondence between text fragments and nodes; and the version table stores the graph update time, data source batch, and rule template version. After processing by this module, a unified legal knowledge graph is formed, encompassing case facts, legal relationships, points of contention, legal basis, judgment rules, similar case information, evidence chains, and document structure framework. This graph serves as the input basis for the case fact analysis and case subgraph generation modules.

[0066] III. Case Fact Analysis and Case Sub-graph Generation Module

[0067] This module receives graph data, node mapping tables, fragment index tables, and standardized case texts output by the legal knowledge graph construction and association mapping module. It then completes the structured representation of the current case in the order of "fact element identification—event chain assembly—dispute point merging—evidence binding—case subgraph trimming." The module first extracts basic fact fields from the case materials, such as parties, actions, time, place, amount, subject matter, procedural status, and liability claims, and merges discrete narratives within the same case into a unified case fact table. To ensure that the same fact can still be merged into the same record when it appears in different text locations, the module calculates a normalized representation for each fact, denoted as: ;in, Indicates the first A record of facts, The field representing the subject of the action. This indicates a behavior type field. Represents a time field. Fields indicating amount or quantity This field represents the factual content. Taking a sales contract dispute as an example, if the case materials contain two statements, "the equipment sales contract was signed on March 1, 2024" and "the two parties entered into a sales agreement on March 1, 2024", they can be merged into the same signing fact node after field unification.

[0068] Based on fact recognition, the module generates a chain of case events according to chronological order and behavioral logic. For segments whose chronological relationship cannot be directly determined, they are first sorted according to the time field; if the time field is missing, supplementary determination is made based on the order of evidence numbers, the order of paragraph positions, and behavioral dependencies.

[0069] The event chain can be represented as: ;in, Indicates the case The sequence of events, to This indicates that the facts are recorded in sequence. For example, in a contract dispute case, an event chain can be generated sequentially as follows: "Contract formation—Delivery of goods—Payment due—Partial payment—Demand for performance—Lawsuit filed." If the "Demand for performance" segment is on page 5 and the "Partial payment" segment is on page 3, but the date of the demand letter is later than the payment record date, the module will adjust the order in the chain based on the date field.

[0070] The dispute focus extraction phase, based on the event chain, merges conflicting claims, defenses, and evidence to form a set of disputed points. The score for each candidate disputed point is determined by the strength of the claim, the concentration of evidence, and the degree of legal relationship matching, which can be written as: ;in, Indicates the first The overall score of each candidate dispute point This indicates that the disputed claims have gained strength. Indicates the concentration of relevant evidence. Indicates the degree of matching with the legal relationship of the case. + + =1. For example, in a certain case, the claim of "whether a breach of contract has occurred" was repeatedly mentioned in the plaintiff's statement, the defendant's response, and the contract terms. =0.90、 =0.80、 =0.95, when =0.3、 =0.3、 When =0.4, we can obtain =0.89, which is used to identify it as the core point of contention.

[0071] The evidence binding phase maps fact records to evidence nodes one by one, forming a three-layer connection relationship of "fact—evidence—point of contention". If a fact is supported by multiple pieces of evidence, a one-to-many relationship is recorded in the mapping table; if multiple facts cite the same evidence, multiple fact citation records are retained under the evidence node. To control the binding scope, the module calculates a matching value between facts and evidence and retains only correspondences higher than a threshold. After evidence binding is completed, each fact record can be traced back to the corresponding evidence number, source page number, and original fragment location.

[0072] After completing fact extraction, event sorting, dispute identification, and evidence binding, the module generates a case subgraph from the global legal knowledge graph based on the current case. The case subgraph includes core fact nodes, disputed focus nodes, relevant legal provision candidate nodes, related similar case nodes, evidence nodes, and document template nodes, excluding distant nodes not directly related to the current case. The case subgraph can be represented as follows: ;in, Indicates the case Local subgraphs Represents the set of nodes related to the case. Represents a set of relationships related to a case. Node entry. The conditions include: direct association with the case subject, direct association with the core event chain, direct association with high-scoring points of contention, or direct association with the current document generation slot. After this processing, the subsequent graph retrieval enhancement module no longer faces the entire legal graph, but performs path retrieval and basis sorting within a local scope of the case, thereby narrowing the search space and improving the focus of the basis.

[0073] In a specific example, the original input materials for a sales contract dispute case totaled 42 pages. After processing by the module, 18 fact nodes, 6 evidence nodes, 3 disputed focus nodes, 5 highly relevant legal provision candidate nodes, and 4 similar case nodes were extracted, ultimately generating a case subgraph containing 36 nodes and 58 relational edges. This subgraph then serves as the direct input object for the graph retrieval enhancement module and the multi-agent orchestration and collaborative reasoning module.

[0074] IV. Graph Search Enhancement Module

[0075] This module receives the case subgraph, fact chain, dispute set, evidence binding table, and legal provision nodes, similar case nodes, adjudication rule nodes, and document template nodes from the case fact analysis and case subgraph generation module. It operates in the following order: "Search request construction—multi-channel candidate recall—graph path expansion—result fusion and sorting—base package output." Instead of performing a single-path search directly on the entire text database, this module constructs a joint search request around the core fact nodes, disputed focus nodes, and legal relationship nodes in the current case subgraph, and then enters the keyword search channel, semantic search channel, and graph path search channel respectively.

[0076] In the retrieval request construction phase, retrieval anchor points are first extracted from the case subgraph. The set of anchor points can be written as: ;in, This represents the set of search anchor points for the current case. Indicates the first Each search anchor point contains keywords related to the disputed issue, behavioral events, legal relationships, monetary amounts, and evidentiary tags. For cases involving "sales contract disputes," the module can extract anchor points such as "contract formation," "payment obligation," "overdue performance," and "liability for breach of contract" from the case subgraph and write these anchor points into the inverted index search request and the vector search request, respectively. To prevent individual high-frequency words from affecting the quality of results, the module assigns different weights to different anchor points, with core disputed keywords having a higher weight than general factual words, and legal provision numbers having a higher weight than ordinary behavioral description words.

[0077] The keyword retrieval channel operates based on an inverted index. The index pre-establishes a term mapping table using law names, article numbers, dispute keywords, case cause terms, and judgment summary terms. During retrieval, candidate legal article fragments, similar case fragments, and rule fragments are retrieved item by item based on anchor terms. The keyword matching score for a candidate text fragment is recorded as follows: ;in, Indicates the first Keyword retrieval scores for each candidate segment. Indicates the first The weight of each anchor word, This indicates the frequency of the anchor word in the candidate fragment. For example, if a candidate adjudication rule fragment contains the three anchor words "payment obligation," "overdue performance," and "liability for breach of contract," with corresponding frequencies of 2, 1, and 1 respectively, and if the three weights are 0.4, 0.3, and 0.3 respectively, then the keyword score for this fragment is 1.4. Based on this, the module forms a keyword candidate set and retains the source document number, fragment number, and original page number.

[0078] The semantic retrieval channel operates based on a vector index library. The module pre-encodes legal provision fragments, case summaries, judgment rule fragments, and template fragments into vectors and saves them as vector records of a uniform dimension. The retrieval request for the current case is also encoded as a query vector, and its similarity is calculated with each candidate vector. Semantic similarity is represented using the vector angle similarity as follows: ;in, Represents the query vector. This represents a candidate fragment vector. For a query vector asking "Does overdue payment constitute a fundamental breach of contract?", if its similarity to a certain type of case summary vector is 0.87, and its similarity to another legal interpretation fragment is 0.79, the module prioritizes retaining the former in the highly relevant candidate set. To control the recall scale, the semantic retrieval channel generally retains the top 20 candidate results and records the similarity value, node number, and fragment source.

[0079] The graph path retrieval channel operates between the case subgraph and the global legal knowledge graph. The module starts with a disputed node or legal relationship node in the case subgraph and ends with a legal provision node, adjudication rule node, or similar case node, performing a path expansion of a limited length in the graph database. The path length is generally limited to 1 to 4 hops to avoid generating excessively long weakly related paths. Any path can be represented as: ;in, Indicates the first Candidate paths, As the starting node, For the termination node, to This represents the sequence of relation types along the path. The module prioritizes paths containing relation edges such as "applicable," "supportive," "similar," and "reference," and downgrades the weight of paths containing "conflict" or low-confidence edges. For two-hop paths starting from the "breach of contract" dispute node, passing through the "sales contract relationship" node, and connecting to the "relevant provisions of the Civil Code Contract Law" node, the system typically assigns higher priority; while paths that pass through multiple intermediate generalization nodes before connecting to the provision node are ranked lower.

[0080] After generating multi-channel candidate results, the module merges and sorts the keyword score, semantic score, and graph path score. The comprehensive ranking score can be written as: ;in, Indicates the first The combined score of each candidate result. This indicates the keyword retrieval score. Indicates the semantic retrieval score. Indicates the graph path score. + + =1. For example, a certain legal provision has a keyword score of 1.20, a semantic score of 0.83, and a graph path score of 0.90. Take... =0.3、 =0.3、 When the score is 0.4, the overall score is 0.975. The module sorts the overall scores from highest to lowest, selects the top few legal provisions, similar cases, and rules, and writes them into the candidate basis table.

[0081] In the results fusion stage, the module further performs deduplication and source merging. For different expressions of the same legal provision, only the highest-scoring fragment corresponding to the standardized legal provision node is retained; for multiple highly similar summary fragments in the same type of case, the fragment with the most complete judgment summary is retained, and the remaining fragments are merged into auxiliary sources. The final output basis package includes: basis type, node number, source fragment number, original text, keyword score, semantic score, graph path number, comprehensive score, and ranking position. This basis package is then input into the multi-agent orchestration and collaborative reasoning module for use by the legal provision matching agent, the case comparison agent, and the document generation agent.

[0082] In a specific example, after a contract dispute case is processed by the graph retrieval enhancement module, 36 candidate legal provisions are retrieved from the legal database, 24 candidate case summaries are retrieved from the case database, and 18 candidate rule fragments are retrieved from the adjudication rule database. After multi-channel fusion and sorting, 5 core legal provisions, 3 highly similar case bases, and 2 adjudication rule bases are finally retained. Each base is accompanied by a source path and node mapping record for subsequent inference chain calls.

[0083] V. Multi-agent orchestration and collaborative reasoning module

[0084] This module receives the basis package, case subgraph, fact chain, dispute set, and evidence binding table output by the graph retrieval enhancement module. It then completes the sequential collaboration and state transfer between the fact extraction agent, dispute identification agent, legal provision matching agent, similar case comparison agent, document generation agent, and review agent according to the pre-configured task graph. This module does not adopt a single-model, one-time generation approach; instead, it breaks down the legal document formation process into multiple independently executable reasoning subtasks, and then links these subtasks into a traceable execution chain through orchestration rules. To describe the agent collaboration relationships, the task graph can be represented as follows: Where T represents the task graph, A represents the set of agent nodes, and D represents the set of dependencies between agents.

[0085] Furthermore, the set of agent nodes can be written as: ;in, This represents a fact-extracting agent. This indicates a dispute-recognition agent. This indicates that the legal provisions are matched with the intelligent agent. Indicates the intelligent agent for case comparison. This refers to the intelligent agent that generates the document. This represents the reviewing agent. The dependency set is used to limit the execution order. For example, the output of the fact extraction agent enters the dispute identification agent, the output of the dispute identification agent enters the legal provision matching agent and the case comparison agent respectively, and the legal provision matching result and the case comparison result enter the document generation agent together, and the document generation result finally enters the reviewing agent.

[0086] After task execution begins, the module first establishes a unified context container for transmitting structured information among agents. The context container contains at least the case number, fact chain identifier, dispute chain identifier, evidence chain identifier, basis package identifier, document type identifier, current execution stage, and version number. When any agent executes, it reads the previous results from the context container and writes the content generated in the current stage back into the container. The context state of a certain execution stage can be represented as: ;in, Indicates the first The context state at each moment, Represents the set of factual results. Represents the set of disputed results. This represents the result set of legal provisions matching. This represents the set of comparison results for similar cases. This represents a collection of document drafts. This represents the set of review results. With this setting, each agent only processes the data fields corresponding to the current stage, without directly modifying the core structure that has been locked in other stages, thereby reducing result drift.

[0087] The fact extraction agent first reads the fact nodes, evidence nodes, and event chain information in the case subgraph, reconfirming the subjects, actions, time, amount, subject matter, and procedural status in the case materials, and forming a standardized fact list. The dispute identification agent then merges and sorts the core disputed matters in the case based on the fact list, evidence binding table, and conflict relationship edges in the case subgraph, outputting a dispute list and dispute priorities. The legal provision matching agent reads the dispute list and the legal provision basis package output by the graph retrieval enhancement module, filtering, sorting, and binding legal provision nodes to generate a "dispute-legal provision" correspondence table. The similar case comparison agent uses the dispute and case facts as input to compare the recalled similar case nodes, outputting a "dispute-similar case" correspondence table and a summary of similar fragments. The document generation agent then constructs a draft document based on the fact list, dispute list, legal provision correspondence table, and similar case correspondence table. Finally, the review agent verifies the consistency of facts, the consistency of citations, structural completeness, and the standardization of expression in the draft item by item.

[0088] During execution, the module uses a message passing mechanism to exchange intermediate results among the agents. Each message contains a task number, sender identifier, receiver identifier, input version number, and output version number. A message object can be represented as: ;in, Indicates the first Message Indicates the message number. Indicates the sender's agent identifier. Indicates the identifier of the receiving intelligent agent. Indicates the message payload content. This indicates the version identifier. Taking the handling of a contract dispute case as an example, after the fact extraction agent completes the structured fact organization, it sends a message with the version number [version identifier missing] to the dispute identification agent. The message payload contains 18 fact records, 6 evidence correspondences, and the current version number. =3; Based on this, the dispute identification agent generates 3 core disputes and sends the results to the legal provision matching agent and the case comparison agent respectively.

[0089] To avoid inconsistent conclusions from multiple agents on the same issue, the module implements a conflict arbitration mechanism. Conflicts typically manifest as differing adjudication rules between legal provision matching results and similar case comparison results, or inconsistencies between the factual statements cited during document generation and the fact extraction results. The module calculates arbitration scores for candidate conflicting results and selects the result with the higher score to write into the context container. The arbitration score can be written as: ;in, Indicates the first The arbitration score for each candidate conclusion. This indicates that the score is based on the quality score. This indicates the historical adoption stability score. This indicates the score based on consistency with the current case context. + + =1. For example, among the two candidate legal provisions, Scheme 1 has a basis quality score of 0.92, historical stability score of 0.81, and contextual consistency score of 0.88, while Scheme 2 has scores of 0.85, 0.86, and 0.79 respectively. Then take... =0.4、 =0.2、 With a score of 0.4, Option 1 has a higher arbitration score, so Option 1 is retained for the subsequent document generation stage.

[0090] At the orchestration and execution level, the module also sets rules for handling abnormal branches. When the fact extraction result lacks a key time field, the task graph automatically reverts to the case fact analysis stage and rereads the original fragment; when the candidate legal provisions output by the legal provision matching agent are less than the preset number, the system automatically expands the graph path retrieval depth and regenerates the basis package; when the review agent identifies that a document paragraph lacks evidence binding, the task flow reverts to the document generation agent and supplements the corresponding paragraph with citation information. In this way, the entire collaborative process forms a closed-loop mechanism of "forward generation - backward verification - partial revert - regeneration", but each revert retains the original version record and does not overwrite the previous results.

[0091] In a specific example, after inputting a sales contract dispute case, the module first calls the fact extraction agent to generate 18 standardized fact records, then calls the dispute identification agent to form 3 core disputes, followed by the legal provision matching agent outputting 5 candidate legal provisions, and the case comparison agent outputting 3 highly similar case summaries. Based on this, the document generation agent generates a first draft containing 12 structured paragraphs. The review agent identifies 2 inconsistencies in the factual time descriptions and 1 missing legal provision number. The system then triggers a partial rollback, corrects the errors, generates a second draft, and writes it into the version chain. After processing by this module, the output includes an agent call sequence table, an intermediate result cache table, a conflict arbitration record table, and a structured document draft available for use by the next module.

[0092] VI. Legal Document Generation Module

[0093] This module receives the fact set, dispute set, legal provision matching set, similar case comparison set, review constraints, and document type identifier from the multi-agent orchestration and collaborative reasoning module. It then generates structured legal documents according to the sequence of "document skeleton determination—paragraph slot allocation—segment generation—basis binding—full-text assembly." This module pre-stores template skeletons corresponding to complaints, answers, agency opinions, review opinions, and compliance review documents. Different document types correspond to different chapter orders, field combinations, and paragraph rules. The document skeleton can be represented as: ;in, Indicates the structure of the target document. Represents a collection of chapters. This represents a collection of paragraphs. For a complaint, the collection of paragraphs typically includes a title section, a party information section, a claims section, a facts and reasons section, a list of evidence section, and a signature section; for a legal opinion, it includes a case overview section, a focus of the dispute section, the legal opinion section, a legal basis section, and a conclusion section.

[0094] After the framework is determined, the module assigns paragraph slots to each chapter based on the document type and case content, and writes the factual results, disputed results, legal basis, and similar case summaries into the corresponding slots. Each paragraph retains its corresponding source identifier upon generation, and the paragraph binding relationship can be represented as follows: ;in, Indicates the first Segment binding records, Indicates the fact fragment number, Indicates the evidence node number, Indicates the node number of the legal provision. This indicates the case node number. Thus, when a breach of contract is entered in the "Facts and Reasons" paragraph, its corresponding evidence and legal source can be recorded simultaneously; similarly, when legal provisions are entered in the "Legal Basis" paragraph, the correspondence between those provisions and the points of contention can be recorded simultaneously.

[0095] To control the consistency between the generated text and the input, the module calculates a structural completeness score for the paragraph content, expressed as: ;in, Indicates the first Segment completeness score Indicates the coverage of fact fields. This indicates that the data is based on field coverage. This indicates the satisfaction rate of the format field. + + =1. When a section lacks a corresponding legal provision or supporting evidence, it will not be directly included in the final draft. Instead, it will remain in draft status, awaiting further processing by the review module or manual revision module.

[0096] During the full-text assembly phase, the module outputs a complete legal document according to chapter order, paragraph order, and numbering rules, and simultaneously generates a paragraph index table, a basis binding table, and a version identifier. In a specific example, a contract dispute case, after processing, generates a draft complaint containing 6 chapters and 11 paragraphs. Nine paragraphs have completed the binding of facts and evidence, while two paragraphs only retain template fields awaiting manual addition. The output of this module serves as the input for the next module, the consistency verification and manual revision module.

[0097] VII. Consistency Verification and Manual Revision Module

[0098] This module receives the draft document, paragraph binding table, factual result set, legal provision matching result set, similar case comparison result set, and evidence binding table output by the legal document generation module, and operates in the order of "fact verification—basis verification—format verification—difference annotation—manual revision and rewrite." This module compares each item in the draft document—name of the subject, date, amount, statement of responsibility, legal provision number, evidence number, paragraph level, and numbering format—and writes any inconsistencies into the verification result table. The verification result can be represented as: ;in, Indicates the first Verification record, Indicates the verification type. Indicates the corresponding paragraph position. This indicates the verification result. Verification types include factual consistency, legal provision consistency, evidentiary consistency, and format consistency.

[0099] The fact verification phase compares the subject, action, time, and amount fields in the draft paragraph with the fact result set item by item; the basis verification phase matches the legal provision names, provision numbers, and case references in the paragraph with the binding table; the format verification phase checks whether the heading level, clause number, citation style, and signature format conform to the preset template. To quantify the verification status of a single paragraph, the module calculates a paragraph consistency score: ;in, Indicates the first Segment consistency score, Indicates the degree of consistency of facts. Indicating consistency between legal provisions Indicating the consistency of evidence, Indicates consistency in formatting. + + + =1. When When the value is below a preset threshold, the segment is marked as a segment to be revised.

[0100] During the manual revision phase, the interface displays the original paragraph, validation prompts, binding basis, and candidate revision content. Revision personnel can add, delete, or modify content at corresponding locations. Each revision generates a difference record, which saves the text before revision, the text after revision, the revision location, the revision type, the reviser's identifier, and the revision time. The revision record can be represented as: ;in, Indicates the first Revision record, This indicates the content before revision. This indicates the revised content. Indicates the reviser's identifier. This indicates the revision time stamp. After the revision is complete, the module will rewrite the updated paragraphs into the document draft and update the paragraph binding table and version number simultaneously, without overwriting the original draft version.

[0101] In one specific instance, a draft complaint contained 11 paragraphs. The module identified two inconsistencies in time descriptions, one missing legal provision number, and one incorrect numbering format. After manual revision, four discrepancy records were generated, forming a revised draft for further processing by the subsequent audit record and feedback update module.

[0102] VIII. Audit Record and Feedback Update Module

[0103] This module receives search results from the graph retrieval enhancement module, execution chain data from the multi-agent orchestration and collaborative reasoning module, draft documents from the legal document generation module, and verification and revision records from the consistency verification and manual revision module. It operates in the order of "process archiving—source tracing—version management—difference summarization—feedback write-back." This module uniformly saves search requests, candidate evidence, graph paths, agent call order, model versions, prompt word versions, document versions, and manual revision records throughout the entire case handling process, forming a traceable audit chain.

[0104] The audit log first establishes a log object using the case number as the primary key. Each retrieval, reasoning, generation, verification, and revision operation is written to the corresponding log entry. A single log record can be represented as: ;in, Indicates the first One audit record, Indicates the operation category identifier. Indicates the source object identifier, Indicates version identifier, This indicates a time stamp. Operation categories include retrieval, path expansion, agent execution, document generation, verification, and manual revision. This allows for the chronological reconstruction of each processing step once the case reaches the final draft stage.

[0105] The source tracing stage establishes a correspondence between each paragraph in the final document and factual fragments, evidence nodes, legal provision nodes, and similar case nodes, and writes this correspondence into a tracing table. If a paragraph originates from multiple sources, multiple binding records are retained in the tracing table; if a source is cited by multiple paragraphs, the corresponding paragraph number is recorded on the source side. This allows for reverse tracing of the original input fragments, graph nodes, and retrieval paths from the final draft paragraphs.

[0106] The version control phase assigns independent version numbers to draft, proofread, revised, and final versions, and preserves the evolutionary relationship between versions. A version chain can be represented as: ;in, This indicates a sequence of document versions corresponding to the same case. to This indicates multiple versions generated in chronological order. Each version retains its generation time, generation source, change summary, and associated audit record number, without directly overwriting the previous version.

[0107] During the difference aggregation phase, the module categorizes and statistically analyzes manually revised content and automatically rolled-back corrections, extracting revision location, revision type, revision frequency, and corresponding module source, and forming a feedback sample. To measure the degree of change of a particular version relative to the previous version, the module calculates the version difference rate: ;in, This indicates the difference rate of the current version. Indicates the number of paragraphs that have been changed. This indicates the total number of paragraphs in this version. For example, if 3 out of 12 paragraphs in a legal document were revised after review, the discrepancy rate is 25%. This indicator can be used to identify high-frequency revision stages and serve as a basis for subsequent rule optimization and sample updates.

[0108] During the feedback write-back phase, frequently revised items, low-confidence retrieval items, duplicate and conflicting items, and missing template items are written into the update queue. The content in the update queue is categorized and stored as data updates, rule updates, template updates, and sample updates: data updates correspond to newly added regulations, similar cases, and historical documents; rule updates correspond to graph relationship rules, sorting rules, and verification rules; template updates correspond to document chapter structure, paragraph slots, and field constraints; and sample updates correspond to high-quality paragraphs revised manually and verification results. Feedback content that has passed review can re-enter the aforementioned modules, forming a closed-loop update chain.

[0109] In a specific example, a contract dispute case generated four versions from initial input to final draft, accumulating 26 audit logs, 8 source tracing records, and 5 manual revision records. Two revisions were categorized as missing legal citations, two as inconsistent factual statements, and one as a formatting issue. The module writes these five records to the rule update queue and sample update queue, respectively, for use in subsequent system iterations. After processing by this module, the system ultimately outputs an auditable document version chain, a source tracing table, a difference statistics table, and a feedback update queue.

[0110] 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. An auditable legal document generation system with graph retrieval enhancement and multi-agent reasoning, characterized in that, Includes the following modules: The data access and preprocessing module performs unified access, format standardization, and fragment indexing of case materials, laws and regulations, judicial interpretations, similar case documents, evidence materials, and template documents; The Legal Knowledge Graph Construction and Association Mapping Module is a core innovative module. It constructs a heterogeneous legal knowledge graph based on elements such as subjects, events, evidence, legal provisions, similar cases, points of contention, and document structure, and establishes association mappings from fragments to graph nodes. The case fact analysis and case subgraph generation module extracts facts, assembles events, identifies points of contention, and binds evidence to the current case text, and generates a case subgraph corresponding to the current case. The graph retrieval enhancement module is a core innovative module. Based on the case subgraph, it performs joint retrieval, path expansion, and fusion sorting in the graph database, vector index library, and keyword inverted index library to generate an enhanced basis package. The multi-agent orchestration and collaborative reasoning module is the core innovative module. It organizes agents such as fact extraction, dispute identification, legal provision matching, case comparison, document generation and review to carry out collaborative reasoning according to a preset task graph. The legal document generation module constructs a document skeleton based on the target document type and writes the case fact chain, dispute chain, basis chain, and evidence chain into the corresponding paragraph slots to generate a structured legal document draft. The consistency verification and manual revision module verifies the factual elements, legal basis, evidence chain, format number, and source correspondence in the draft item by item, and records the differences in manual revisions; The audit record and feedback update module records the retrieval source, graph path, agent call order, generated version, revision record and final result in a structured manner, forming a traceable audit chain and feedback update queue.

2. The graph retrieval enhancement and multi-agent reasoning auditable legal document generation system as described in claim 1, characterized in that: The legal knowledge graph construction and association mapping module adopts a heterogeneous graph model to uniformly organize legal knowledge units, case fact units, evidence units, and document structure units: G=(V,E); where the node set V includes at least subject nodes, event nodes, evidence nodes, legal provision nodes, similar case nodes, dispute nodes, and document structure nodes, and the edge set E includes at least citation relationship edges, application relationship edges, support relationship edges, conflict relationship edges, similarity relationship edges, hierarchical relationship edges, and temporal relationship edges.

3. The system for generating auditable legal documents with graph retrieval enhancement and multi-agent reasoning as described in claim 1, characterized in that: In the legal knowledge graph construction and association mapping module, the subjects, behaviors, evidence and disputes in the same case are aggregated through case identifiers. Laws, regulations, judicial interpretations and similar case rules from different sources are mapped through legal source level, validity level, applicable conditions and update time. A one-to-one or one-to-many correspondence is established between text fragment identifiers and graph node identifiers.

4. The system for generating auditable legal documents with graph retrieval enhancement and multi-agent reasoning as described in claim 1, characterized in that: The legal knowledge graph construction and association mapping module uses a graph node table, graph edge table, node attribute table, fragment mapping table and graph version table for persistent storage; Among them, the graph node table stores node identifier, node type and source identifier; the graph edge table stores start node, end node and relationship type; the node attribute table stores legal provision number, legal source level, cause of action label, dispute label, applicable conditions and statute of limitations status; the fragment mapping table stores fragment number, node number, page number and paragraph number; and the graph version table stores graph construction batch, rule template version and update time. Each mapping record in the fragment mapping table contains at least a source document identifier, fragment location identifier, node identifier, and mapping type identifier to maintain traceable associations between legal provisions, similar cases, evidence, and document paragraphs.

5. The system for generating auditable legal documents with graph retrieval enhancement and multi-agent reasoning as described in claim 1, characterized in that: The graph retrieval enhancement module employs a three-pronged approach of keyword retrieval, semantic retrieval, and graph path retrieval to retrieve candidate nodes related to legal provisions, similar cases, rules, and evidence within the case subgraph. The module then determines a comprehensive ranking of the candidate nodes based on a fusion score. , + + =1; where, Indicates the first The combined score of each candidate result. This indicates the keyword retrieval score. Indicates the semantic retrieval score. Indicates the graph path score; The graph path retrieval uses the dispute nodes, event nodes, and legal relationship nodes in the case subgraph as the path starting point, performs path expansion within a preset number of jumps in the legal knowledge graph, and outputs the node path sequence, relationship path sequence, and path endpoint type.

6. The system for generating auditable legal documents with graph retrieval enhancement and multi-agent reasoning as described in claim 1, characterized in that: The enhanced basis package output by the graph retrieval enhancement module includes at least the source fragment identifier, graph path identifier, candidate node identifier, applicable label, legal source level label, similar case identifier, and scoring result; The scoring results consist of at least the text relevance, graph path matching degree, legal source authority, timeliness and validity, and evidence support.

7. The graph retrieval enhancement and multi-agent reasoning auditable legal document generation system as described in claim 1, characterized in that: The graph retrieval enhancement module merges different excerpts of the same legal provision by legal provision number, merges different summary excerpts of the same type of case by case number, and retains the original source identifier, merge identifier, and sorting position identifier for candidate evidence with source conflicts, so as to form a traceable set of candidate evidence; the output method of this joint retrieval, result fusion, and enhanced evidence package is consistent with that of the document.

8. The system for generating auditable legal documents with graph retrieval enhancement and multi-agent reasoning as described in claim 1, characterized in that: The multi-agent orchestration and collaborative reasoning module includes at least a fact extraction agent, a dispute identification agent, a legal provision matching agent, a case comparison agent, a document generation agent, and a review agent; Each intelligent agent executes the task in the order of execution or in parallel according to the preset task graph. The task graph defines at least the preceding task identifier, the succeeding task identifier, the input context field, the output result field, and the trigger condition identifier.

9. The system for generating auditable legal documents with graph retrieval enhancement and multi-agent reasoning as described in claim 1, characterized in that: The multi-agent orchestration and collaborative reasoning module also includes a unified task context container, which stores at least the case number, fact chain identifier, dispute chain identifier, evidence chain identifier, candidate evidence package identifier, target document type identifier, and current version identifier. Intermediate results are passed between agents via message queues and written to a cache table to maintain the continuity of states and the reusability of results in the inference chain.

10. The graph retrieval enhancement and multi-agent reasoning auditable legal document generation system as described in claim 1, characterized in that: When conflicts arise in the outputs of different agents, the multi-agent orchestration and collaborative reasoning module determines the retention result based on the conflict arbitration score: , + + =1; where, Indicates the first Arbitration scores for each candidate conclusion; This indicates that the score is based on the quality score. This indicates the historical adoption stability score. This indicates the score based on consistency with the current case context; The conflict arbitration result shall at least record the candidate result identifier, conflict type identifier, arbitration score, retention identifier, and arbitration time identifier, and write the candidate results that are not retained, along with their source basis, calling agent identifier, and conflict reason, into the arbitration record table; the task graph, message interaction, and conflict arbitration shall be consistent with the documentation.

Images