System documentation generation method, apparatus, and computer program product

Abstract

The application discloses a system document generation method, device and computer program product. It relates to the field of software document generation, and the method comprises the following steps: receiving input document data and a target template, generating a plurality of evidence units based on the document data; constructing an evidence graph based on the plurality of evidence units; splitting the target template into a plurality of chapter slots, and selecting a candidate evidence set of each chapter slot from the evidence graph; determining the evidence coverage of the chapter slot based on the candidate evidence set, and generating the chapter content of the chapter slot based on the candidate evidence set in the case where the evidence coverage is greater than or equal to a first coverage threshold; and generating the target document based on the chapter content of each chapter slot. Through the application, the problem that the document of a software system generated by a large model is inaccurate in the related art is solved.

Description

Technical Field

[0001] This application relates to the field of software documentation generation, and more specifically, to a method, apparatus, and computer program product for generating system documentation. Background Technology

[0002] As enterprise IT infrastructure development deepens, many business systems evolve into complex legacy software systems, characterized by complex code assets, scattered historical data, inconsistent version status, and incomplete knowledge transfer. During requirements analysis, change reviews, or system refactoring, enterprises need to quickly generate requirements, design, and change impact analysis documents based on multi-source heterogeneous materials such as code, old documents, and new requirements. These documents must have a standardized structure, reflect the true state of the system, connect with historical decisions, and support the entire R&D process.

[0003] Document generation solutions in related technologies rely on manual compilation and comparison of materials, which is costly, time-consuming, and easily influenced by human experience, making it difficult to adapt to the rapid iteration needs of complex existing systems. Code scanning has a narrow coverage, only extracting local code structure information and failing to cover high-level semantic content. The generation of general large models has low reliability and lacks structured constraints, resulting in distorted content or inconsistencies with the actual system. Requirements and design are disconnected, impact analysis lacks traceability, and there are even instances of fictitious entities or conflicting descriptions between documents.

[0004] There is currently no effective solution to the problem of inaccurate documentation in software systems generated from large models in related technologies. Summary of the Invention

[0005] The main objective of this application is to provide a method, apparatus, and computer program product for generating system documents, in order to solve the problem of inaccurate documents generated by software systems using large models in related technologies.

[0006] To achieve the above objectives, according to one aspect of this application, a method for generating system documents is provided. The method includes: receiving input document data and a target template; generating multiple evidence units based on the document data, wherein each evidence unit is a reference information object parsed from the document data; constructing an evidence graph based on the multiple evidence units, wherein the evidence graph contains multiple nodes and multiple edges, where nodes represent evidence units and edges between nodes represent the relationships between the evidence units corresponding to the nodes; splitting the target template into multiple chapter slots; selecting a candidate evidence set for each chapter slot from the evidence graph, wherein each chapter slot is a structured unit split from the target template according to semantic logic, and the candidate evidence units in the candidate evidence set are used to generate document content for the chapter slot; determining the evidence coverage rate of the chapter slot based on the candidate evidence set; and generating chapter content for the chapter slot based on the candidate evidence set if the evidence coverage rate is greater than or equal to a first coverage threshold, wherein the evidence coverage rate is the ratio of the target number to the total number of evidence types required by the chapter slot, and the target number is the number of evidence types in the candidate evidence set that meet the requirements of the chapter slot; and generating a target document based on the chapter content of each chapter slot.

[0007] Optionally, after generating the target document based on the chapter content of each chapter slot, the method further includes: extracting new and / or change requirements from the document data, and identifying target nodes affected by the new and / or change requirements from the evidence graph; generating a change impact analysis report based on the target nodes, new and / or change requirements; performing reverse parsing on the change impact analysis report and the target document to obtain multiple entities and their relationships; performing reverse consistency verification through multiple entities, relationships, and the evidence graph, wherein the reverse consistency verification includes at least one of the following: entity existence verification, interface path verification, entity-corresponding relationship verification, business process closed-loop verification, constraint consistency verification, and scope of impact integrity verification; publishing the target document if the reverse consistency verification passes; and issuing a first prompt message if the reverse consistency verification fails, wherein the first prompt message is used to indicate that the target document has evidence defects.

[0008] Optionally, generating multiple evidence units based on document data includes: if the document data contains a code directory, extracting code elements from the code directory, wherein the code elements include at least one of the following: directory structure, module name, interface path, function name, configuration item, and database access statement; if the document data contains historical documents or knowledge documents, extracting semantic elements from the historical documents or knowledge documents, wherein the semantic elements include at least one of the following: chapter title, entity name, business process, boundary conditions, terminology definition, and rule description; if the document data contains new requirements, extracting requirement intent elements from the new requirements, wherein the requirement intent elements include at least one of the following: target function, change point, constraint conditions, scope of impact, and expected output; identifying code elements, or semantic elements, or requirement intent elements as entities of evidence units; obtaining relevant information about the entities from the document data, and generating evidence units based on the entities and their relevant information, wherein the relevant information includes at least one of the following: evidence identifier, source type, source path, source location, entity category, entity name, content summary, time information, and credibility index value.

[0009] Optionally, constructing an evidence graph based on multiple evidence units includes: determining the relationships based on the relevant information of multiple evidence units, wherein the relationships include at least one of the following: code call relationship, document reference relationship, interface and implementation relationship, entity naming correspondence relationship, directory proximity relationship, semantic similarity relationship, version relationship, conflict relationship, and supplementary relationship; constructing nodes corresponding to the evidence units, and connecting edges between nodes corresponding to evidence units with relationships; and constructing an evidence graph based on the nodes and edges.

[0010] Optionally, selecting the candidate evidence set for each chapter slot from the evidence graph includes: obtaining the configuration information for each chapter slot, wherein the configuration information includes at least one of the following: slot name, slot order, required evidence type set, optional evidence type set, minimum evidence coverage, evidence conflict adjudication rules, output structure requirements, and prohibited output items; determining candidate indicator values ​​for evidence units based on the relevance between chapter slots and evidence units; and selecting the candidate evidence set from the evidence graph based on the configuration information and candidate indicator values.

[0011] Optionally, selecting a candidate evidence set from the evidence graph based on configuration information and candidate indicator values ​​includes: determining the evidence unit set corresponding to the evidence graph; removing evidence units from the evidence unit set that do not match the entity category and are prohibited from output, to obtain an updated evidence unit set; removing evidence units from the updated evidence unit set whose candidate indicator values ​​are less than the indicator value threshold, to obtain a pending evidence set; determining whether the evidence units in the pending evidence set cover the required evidence type set; if the evidence units in the pending evidence set do not cover the required evidence type set, issuing a second prompt message, wherein the second prompt message is used to indicate insufficient evidence; if the evidence units in the pending evidence set cover the required evidence type set, determining the pending evidence set as a candidate evidence set.

[0012] Optionally, determining candidate index values ​​for evidence units based on the relevance between chapter slots and evidence units includes: determining relevance index values ​​between chapter slots and evidence units, wherein the relevance index values ​​include at least one of the following: semantic relevance, structural relevance, source credibility, time freshness, and multi-source corroboration; and determining candidate index values ​​based on each type of relevance index value and its corresponding preset weight.

[0013] Optionally, after determining the evidence coverage rate of the chapter slot based on the candidate evidence set, the method further includes: issuing a third prompt message when the evidence coverage rate is greater than or equal to a second coverage threshold and less than or equal to a first coverage threshold, wherein the third prompt message is used to indicate that the chapter content of the chapter slot needs to be verified; and issuing a fourth prompt message when the evidence coverage rate is less than the second coverage threshold, wherein the fourth prompt message is used to indicate that the chapter slot needs to supplement evidence.

[0014] To achieve the above objectives, according to another aspect of this application, a system document generation apparatus is provided. The device includes: a receiving unit for receiving input document data and a target template, and generating multiple evidence units based on the document data, wherein each evidence unit is a reference information object parsed from the document data; a construction unit for constructing an evidence graph based on the multiple evidence units, wherein the evidence graph contains multiple nodes and multiple edges, where nodes represent evidence units and edges between nodes represent the relationships between the corresponding evidence units; a splitting unit for splitting the target template into multiple chapter slots, and selecting a candidate evidence set for each chapter slot from the evidence graph, wherein each chapter slot is a structured unit split from the target template according to semantic logic, and the candidate evidence units in the candidate evidence set are used to generate the document content of the chapter slot; a first determining unit for determining the evidence coverage rate of the chapter slot based on the candidate evidence set, and generating the chapter content of the chapter slot based on the candidate evidence set if the evidence coverage rate is greater than or equal to a first coverage rate threshold, wherein the evidence coverage rate is the ratio of the target number to the total number of evidence types required by the chapter slot, and the target number is the number of evidence types in the candidate evidence set that meet the requirements of the chapter slot; and a generation unit for generating a target document based on the chapter content of each chapter slot.

[0015] To achieve the above objectives, according to another aspect of this application, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps of the system document generation method described in various embodiments of this application.

[0016] This application employs the following steps: receiving input document data and a target template; generating multiple evidence units based on the document data, where each evidence unit is a reference information object parsed from the document data; constructing an evidence graph based on the multiple evidence units, where the evidence graph contains multiple nodes and edges, nodes representing evidence units, and edges representing the relationships between the corresponding evidence units; splitting the target template into multiple chapter slots; selecting candidate evidence sets for each chapter slot from the evidence graph, where each chapter slot is a structured unit split from the target template according to semantic logic, and candidate evidence units in the candidate evidence set are used to generate the document content for the chapter slot; determining the evidence coverage rate for the chapter slot based on the candidate evidence set; and generating chapter content for the chapter slot based on the evidence coverage rate when it is greater than or equal to a first coverage threshold, where the evidence coverage rate is the ratio of the target number to the total number of evidence types required for the chapter slot, and the target number is the number of evidence types in the candidate evidence set that meet the requirements of the chapter slot; and generating a target document based on the chapter content of each chapter slot, thus solving the problem of inaccurate documents generated by software systems using large models in related technologies. By parsing multi-source document data into structured evidence units, the generated content achieves strong traceability and support for the original multi-source data, effectively avoiding the illusion of a large model. The target template is then broken down into chapter slots, and candidate evidence screening and segmented generation are performed around each chapter slot, ensuring that the content of each chapter conforms to the template specifications while maintaining consistency with the logical relationships between system entities. Evidence coverage is introduced as a pre-generation verification condition; deterministic content is only generated when candidate evidence sufficiently covers the necessary types for the chapter. This suppresses unfounded generation or missing content, improving the completeness and standardization of the document. Ultimately, this improves the accuracy of document generation. Attached Figure Description

[0017] The accompanying drawings, which form part of this application, are used to provide a further understanding of this application. The illustrative embodiments and descriptions of this application are used to explain this application and do not constitute an undue limitation of this application. In the drawings:

[0018] Figure 1 This is a flowchart of a system document generation method provided according to an embodiment of this application;

[0019] Figure 2 This is a schematic diagram of chapter slotting and candidate evidence screening provided according to the embodiments of this application;

[0020] Figure 3 This is a schematic diagram illustrating the logical transition of document state according to an embodiment of this application;

[0021] Figure 4 This is a schematic diagram illustrating the propagation of the impact of the change impact analysis report provided in the embodiments of this application;

[0022] Figure 5 This is a flowchart of reverse consistency verification provided according to an embodiment of this application;

[0023] Figure 6 This is a schematic diagram of the evidence generation unit provided according to an embodiment of this application;

[0024] Figure 7 This is a schematic diagram of the system for generating system documents according to the embodiments of this application;

[0025] Figure 8 This is a schematic diagram of an optional system document generation method provided according to an embodiment of this application;

[0026] Figure 9 This is a schematic diagram of a system document generation apparatus provided according to an embodiment of this application;

[0027] Figure 10 This is a schematic diagram of an electronic device provided according to an embodiment of this application. Detailed Implementation

[0028] It should be noted that, unless otherwise specified, the embodiments and features described in this application can be combined with each other. This application will now be described in detail with reference to the accompanying drawings and embodiments.

[0029] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort should fall within the scope of protection of the present application.

[0030] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate for the embodiments of this application described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0031] The present invention will now be described in conjunction with preferred implementation steps. Figure 1This is a flowchart of a system document generation method provided according to an embodiment of this application, such as... Figure 1 As shown, the method includes the following steps:

[0032] Step S101: Receive input document data and target template, and generate multiple evidence units based on the document data. The evidence unit is a reference information object parsed from the document data.

[0033] In step S101, the system that needs to generate documents can be an existing system, that is, a software system that has been launched and is running or maintained for a long time, including multiple code repositories, multiple historical documents, multiple business constraints, and multiple evolution records. Document data can include multi-source heterogeneous evidence: a collection of information from different sources such as code files, interface definitions, database scripts, historical requirement documents, design documents, knowledge base documents, and manually entered requirements. An evidence unit is the smallest referenceable information object extracted and standardized from various information sources, and at least includes source, location, entity category, entity name, content summary, and credibility. An interface path ` / api / order / create` can be an evidence unit; a database field `approval_comment` can be an evidence unit; and an order approval process in an old design document can also be an evidence unit.

[0034] In a preferred embodiment, the system documentation generation method of this embodiment is deployed in an enterprise's internal R&D environment. The server provides workspace management capabilities, with each workspace corresponding to a complex existing system project to be analyzed. Each workspace contains at least the following directories or objects: code: one or more code repository directories; legacy_docs: original historical documents; converted_docs: converted Markdown documents; knowledge: supplementary knowledge documents or constraint documents; templates: requirement templates and design templates; requirement: manually added requirements or design points; prompt or other task description objects: used to trigger the generation task. This implementation environment can be implemented as a web application, or as a desktop application, command-line application, or service-oriented programming interface.

[0035] The system document generation system receives the following inputs associated with the target workspace: one or more code repository directories; one or more historical requirement documents, design documents, or specification documents; one or more knowledge documents, constraint documents, or specification documents; the target document template; and user-added requirements or design points. Historical documents can be in various formats and can be converted to Markdown (a lightweight markup language) before proceeding to subsequent processes.

[0036] Step S102: Construct an evidence graph based on multiple evidence units. The evidence graph contains multiple nodes and multiple edges. Nodes are used to represent evidence units, and edges between nodes are used to represent the association between the evidence units corresponding to the nodes.

[0037] In step S102, the evidence graph is a structured network composed of evidence units and their associated edges, used to express modules, interfaces, table structures, processes, constraints, and influence relationships. By establishing semantic, structural, or invocation relationships between evidence units, a structured network capable of expressing the relationships between modules, interfaces, table structures, and business processes in a complex existing system is formed, enabling logical connections between isolated evidence units and laying the topological foundation for subsequent evidence screening and consistency verification based on graph relationships.

[0038] Step S103: The target template is split into multiple chapter slots, and candidate evidence sets for each chapter slot are selected from the evidence graph. The chapter slot is a structured unit that is split from the target template according to semantic logic. The candidate evidence units in the candidate evidence set are used to generate the document content of the chapter slot.

[0039] In step S103, a chapter slot is a structured generation unit split from the target template by chapter, paragraph, or table. Each slot has input constraints, evidence type requirements, output format requirements, and validation rules. The target template is split into several chapter slots. For example, a requirements document template can be split into slots for background, objectives, business processes, functional requirements, non-functional requirements, boundary conditions, and implementation suggestions; a design document template can be split into slots for overall design, module design, interface design, data design, exception handling, and deployment impact.

[0040] Each chapter slot must be configured with at least: slot name; slot order; set of required evidence types; set of optional evidence types; minimum evidence coverage; conflict resolution rules; output structure requirements; and prohibited output items. Figure 2 This is a schematic diagram illustrating chapter slotting and candidate evidence screening according to embodiments of this application, such as... Figure 2 As shown, the evidence map contains candidate evidence set 1, candidate evidence set 2, candidate evidence set 3, and candidate evidence set 4. The target template is divided into slot 1: background; slot 2: module design; slot 3: interface design; and slot 4: data design. Each slot corresponds to a candidate evidence set. The candidate evidence set for each slot needs to undergo evidence coverage verification and conflict resolution. After the verification is passed, the corresponding chapter content for the slot is generated.

[0041] In one design document implementation, the template can be divided into the following slots: 1. Project Background, 2. Change Objectives, 3. Overall Solution, 4. Module Design, 5. Interface Design, 6. Data Design, 7. Exception and Boundary Handling, 8. Deployment and Compatibility Impact, and 9. Testing Recommendations. The Interface Design slot requires at least one interface entity evidence, one call relationship evidence, and one requirement change evidence; the Data Design slot requires at least one field or table structure evidence; and the Exception and Boundary Handling slot requires at least one rule-based evidence or exception scenario evidence from an older document. If the system finds that a Data Design slot only contains a description of a new requirement without table structure or field evidence, the slot will not directly output a specific field design conclusion. Instead, it will output "Based on the existing evidence, the field's storage method cannot be confirmed. It is recommended to supplement database design evidence or obtain manual confirmation," thus avoiding unfounded generation.

[0042] Step S104: Determine the evidence coverage rate of the chapter slot based on the candidate evidence set. If the evidence coverage rate is greater than or equal to the first coverage threshold, generate the chapter content of the chapter slot based on the candidate evidence set. Here, the evidence coverage rate is the ratio of the target number to the total number of evidence types required by the chapter slot, and the target number is the number of evidence types in the candidate evidence set that meet the requirements of the chapter slot.

[0043] In step S104, the evidence coverage rate is the target number of evidence units that have been cited and meet the constraints in a certain chapter, relative to the minimum number of evidence units required for that chapter, i.e., the total number of evidence types required for the chapter slots. The system does not generate the entire document at once, but rather in segments by chapter slot. For each chapter slot, the system provides the generation engine with: current slot requirements; a set of candidate evidence; generation constraints prohibiting fictitious entities; output format and word count requirements; and dependencies on previously generated content in previous chapters. When the evidence coverage rate of a slot is below a threshold, the system does not directly generate complete content, but instead outputs a prompt for supplementary evidence, a low-confidence chapter prompt, or a prompt requiring manual confirmation, thereby suppressing unfounded generation. The paragraph fragment-evidence unit mapping relationship is recorded synchronously when generating each chapter, enabling subsequent reverse verification to trace back the basis by paragraph and sentence. The evidence coverage rate of a chapter slot is calculated using the following formula: Evidence Coverage Rate = Number of Required Evidence Types Satisfied / Total Number of Required Evidence Types.

[0044] For example, interface design slots require at least four types of essential evidence: interface path evidence, request parameter evidence, response parameter evidence, and calling module evidence. If only three of these types are satisfied in the current candidate set, the evidence coverage rate for that slot is 3 / 4, or 0.75. When the evidence coverage rate is not lower than the first coverage threshold of 0.80, the system allows the output of definitive chapter content; when the evidence coverage rate is between 0.60 and 0.80, the system allows the output of low-confidence chapter content with a hint requiring manual confirmation; when the evidence coverage rate is lower than 0.60, the system does not output a definitive conclusion, but only outputs a hint requiring supplementary evidence. Chapter generation can employ a large language model, rule templates, statistical generation models, or retrieval-enhanced generation models.

[0045] Step S105: Generate the target document based on the chapter content of each chapter slot.

[0046] In step S105, the content of each chapter slot that has been filtered and verified for coverage is assembled into the final target document, ensuring that the output document not only has a standardized chapter structure, but also that each part of the content has been supported by evidence and logically reviewed, thereby achieving the automatic generation of high-quality and highly credible complex stock system documents.

[0047] It should be noted that the system determines the document status based on a comprehensive assessment of the document generation result, evidence coverage, consistency verification results, and conflict status. Statuses include, but are not limited to: Not generated; Generating; Generated but awaiting verification; Verification passed; Insufficient evidence; Conflicts exist and require confirmation; Published. The final document status is determined according to the following priority:

[0048] 1. When no generation task has been received, the status is "Not Generated";

[0049] 2. When a generation task has been received but the chapter generation process has not yet ended, the status is "Generating";

[0050] 3. When the target document file has been generated but reverse consistency verification has not yet been completed, the status is "Generated and pending verification";

[0051] 4. When there is at least one Level 3 conflict, or at least three Level 2 conflicts, the status is "Conflict exists and needs confirmation";

[0052] 5. When the overall evidence coverage of the document is below 0.80, or the evidence coverage of any key chapter is below 0.60, the status is "insufficient evidence";

[0053] 6. When the overall evidence coverage of the document is not less than 0.80, the chapter review pass rate is not less than 0.90, and there are no level 3 conflicts, the status is "verification passed";

[0054] 7. When a document is in the "Validation Passed" status and the release confirmation has been completed, the status is "Released".

[0055] The overall document evidence coverage is calculated as a weighted average of the evidence coverage of each chapter's slots, with key chapters having a higher weight than ordinary chapters. For example, the weight of the chapters on overall solution, interface design, data design, and exception handling can be 2, while the weight of other chapters can be 1. The final output includes the target document, a CIA (Change Impact Analysis Report), a status object, and an evidence traceability index. The document status is linked to the following information: whether the target document was successfully generated; whether a corresponding CIA report exists; whether the evidence coverage of each chapter meets the standard; whether there is high-conflict evidence; whether reverse consistency verification has been completed; and whether it is bound to the current requirement version. Therefore, even if a document file already exists, if the file does not correspond to the current requirement version, fails verification, or has insufficient evidence coverage, the system will not classify it as "finally generated," thus avoiding misleading users. This status expression method is preferably used to display the execution results of the main technical solution, rather than existing independently of the main solution.

[0056] For example, in one embodiment, a design document contains 8 chapter slots. The evidence coverage rates for the three key chapters—"Overall Scheme," "Interface Design," and "Data Design"—are 0.90, 0.75, and 0.50, respectively. The evidence coverage rates for the remaining five ordinary chapters are 0.90, 0.85, 0.80, 0.95, and 0.90, respectively. If the weight of the key chapters is 2 and the weight of the ordinary chapters is 1, then the overall evidence coverage rate of the document is:

[0057] (0.90 2+0.75 2+0.50 2+0.90+0.85+0.80+0.95+0.90) / (2+2+2+1+1+1+1+1)=8.70 / 11=0.7909. Since the overall evidence coverage of the document is less than 0.80, and the coverage of the "Data Design" section is less than 0.60, even though the target file has been created, the system will still determine the document status as "insufficient evidence" instead of "verification passed".

[0058] Figure 3 This is a schematic diagram of document state logic transition according to the embodiments of this application, such as... Figure 3As shown, the state machine can transition according to the following logic: 1. The initial state is "Not Generated"; 2. After the system receives the generation task, it enters "Generating"; 3. After the document file is generated, it enters "Generated and Awaiting Verification"; 4. If high-conflict evidence is found, such as at least one Level 3 conflict, or at least three Level 2 conflicts, it enters "Conflict Exists and Awaiting Confirmation"; 5. If the overall document evidence coverage is insufficient, such as below 0.80, or the evidence coverage of any key chapter is below 0.60, it enters "Insufficient Evidence"; 6. If the reverse consistency check passes, the overall document evidence coverage meets the standard (not less than 0.80), the chapter back-check pass rate is not less than 0.90, and there are no Level 3 conflicts, it enters "Verification Passed"; 7. If it passes manual review, it enters "Published". This state machine can effectively solve the problem of displaying "Generated" as long as the file exists, enabling the system to correctly reflect the true usable state.

[0059] The system document generation method provided in this application receives input document data and a target template, generates multiple evidence units based on the document data, where each evidence unit is a reference information object parsed from the document data; constructs an evidence graph based on the multiple evidence units, where the evidence graph contains multiple nodes and multiple edges, nodes are used to represent evidence units, and edges between nodes are used to represent the association relationship between the evidence units corresponding to the nodes; splits the target template into multiple chapter slots, and selects a candidate evidence set for each chapter slot from the evidence graph, where each chapter slot is a structured unit split from the target template according to semantic logic, and the candidate evidence units in the candidate evidence set are used to generate the document content of the chapter slot; determines the evidence coverage rate of the chapter slot based on the candidate evidence set, and generates the chapter content of the chapter slot based on the candidate evidence set if the evidence coverage rate is greater than or equal to a first coverage rate threshold, where the evidence coverage rate is the ratio of the target number to the total number of evidence types required by the chapter slot, and the target number is the number of evidence types in the candidate evidence set that meet the requirements of the chapter slot; and generates a target document based on the chapter content of each chapter slot, thus solving the problem of inaccurate documents generated by software systems using large models in related technologies. By parsing multi-source document data into structured evidence units, the generated content achieves strong traceability and support for the original multi-source data, effectively avoiding the illusion of a large model. The target template is then broken down into chapter slots, and candidate evidence screening and segmented generation are performed around each chapter slot, ensuring that the content of each chapter conforms to the template specifications while maintaining consistency with the logical relationships between system entities. Evidence coverage is introduced as a pre-generation verification condition; deterministic content is only generated when candidate evidence sufficiently covers the necessary types for the chapter. This suppresses unfounded generation or missing content, improving the completeness and standardization of the document. Ultimately, this improves the accuracy of document generation.

[0060] After generating the target document, it is necessary to verify it. Optionally, in the system document generation method provided in this application embodiment, after generating the target document based on the chapter content of each chapter slot, the method further includes: extracting new requirements and / or change requirements of the system from the document data, and determining the target nodes affected by the new requirements and / or change requirements from the evidence graph; generating a change impact analysis report based on the target nodes, new requirements and / or change requirements; performing reverse parsing on the change impact analysis report and the target document to obtain multiple entities and the relationships between entities; performing reverse consistency verification through multiple entities, relationships and evidence graph, wherein the reverse consistency verification includes at least one of the following: entity existence verification, interface path verification, entity corresponding relationship verification, business process closed-loop verification, constraint consistency verification and scope of influence integrity verification; publishing the target document if the reverse consistency verification passes; and issuing a first prompt message if the reverse consistency verification fails, wherein the first prompt message is used to indicate that the target document has evidence defects.

[0061] In some embodiments, the document generation method of this system can also be used for requirement document generation. The system focuses on business objectives, user scenarios, functional requirements, non-functional requirements, and boundary constraints. It identifies existing capability boundaries in old requirements through evidence graphs and then combines this with new requirements to generate updated requirement documents. If a conflict is found between a new requirement and an old constraint—for example, if an old knowledge document stipulates that the approval chain cannot exceed one level, while a new requirement requires two levels of approval—the system will simultaneously alert the system to this conflict in the requirement document and the CIA report. Reverse consistency verification involves extracting entities and descriptions from the generated document content and then reviewing the evidence graph to verify whether the content has traceable support. A change impact analysis report is used to explain the impact of new requirements, design adjustments, or code changes on modules, interfaces, databases, upstream and downstream systems, and the testing scope.

[0062] Starting with new requirements or design changes, the impact propagation is performed on the evidence graph to obtain a set of affected objects. During the propagation process, the following can be identified: directly affected modules; indirectly affected interfaces; and affected database tables or fields.

[0063] Affected upstream and downstream systems; scope requiring supplementary testing; conflict points requiring manual verification. Based on the above results, the system automatically generates a CIA report. The impact propagation in the CIA report can be accomplished using graph traversal, rule propagation, dependency analysis, or a combination thereof.

[0064] Figure 4 This is a schematic diagram illustrating the propagation of the impact of the change impact analysis report provided in the embodiments of this application, such as... Figure 4As shown, assume the new requirement is "to add a two-level approval and approval comment tracking function to the order system". Starting with "two-level approval" and "approval comments" as the initial entities, the impact propagation is performed in the evidence graph, resulting in the following objects: order submission process; approval service module; order status enumeration; approval comment field; message notification module; approval record query interface; upstream initiating system and downstream reporting system. Based on this, the system generates a CIA report, which may include: a list of affected functions; a list of affected modules; interfaces and parameters requiring adjustment; database tables and fields requiring adjustment; compatibility risks; regression testing recommendations; and deployment risk warnings.

[0065] The generated requirements documents, design documents, and CIA reports are reverse-analyzed to extract entities, processes, interfaces, table structures, constraints, and conclusions. The evidence graph is then reviewed. If a section cannot be traced back to sufficient evidence, or if it conflicts with highly credible evidence, it is marked as low-credibility or conflicting content. Reverse consistency verification includes: entity existence verification, interface path verification, entity-corresponding relationship verification, business process closure verification, constraint consistency verification, and scope of impact integrity verification. Verification conclusions are output per chapter slot. If the proportion of traceable content in a chapter is lower than a preset threshold, or if the chapter lacks the necessary evidence type's corresponding backtesting results, that chapter must not be included in the final release document. In this way, reverse consistency verification is no longer a post-generation prompt, but a control action for document content access.

[0066] The conflict resolution rules can be defined in the following order: 1. First, compare the source priority of conflicting evidence; 2. If the source priorities are the same, compare the freshness of time; 3. If the freshness of time is still the same, compare the corroboration of multiple sources; 4. If a resolution still cannot be reached, mark the relevant conclusion as a high-conflict conclusion and output a manual confirmation prompt. The source priorities, from highest to lowest, are: current version code file, interface definition file; current version database script; currently approved design document; currently approved requirement document; historical design document; historical requirement document; knowledge description document; ordinary manual input instructions. Conflicts are divided into three levels according to their severity: Level 1 conflict: only the textual descriptions differ but the entity objects are the same, which does not affect the conclusion; Level 2 conflict: differences exist in parameters, fields, module names, or constraints, which may affect the conclusion; Level 3 conflict: interface paths, database fields, business rules, or process directions are opposite, directly affecting the conclusion. When a Level 3 conflict exists, the output of the definitive conclusion for the corresponding section is stopped; when only a Level 1 conflict exists, high-priority conclusions are allowed to be retained and conflict descriptions are recorded in the retrospective index.

[0067] Figure 5 This is a flowchart of reverse consistency verification provided according to an embodiment of this application, such as... Figure 5As shown, suppose the system-generated design document contains the following description: "Add interface / api / order / approve / second for secondary approval submission". The system will perform reverse extraction on this description to obtain the entities "interface path" and "secondary approval submission function", and then check the evidence graph. If the graph contains corresponding evidence from code, old documents, or high-credibility requirements, it is considered to be verifiable; if the graph only contains weakly related natural language descriptions without any interface or module evidence, the content is marked as low-credibility; if the graph clearly contains conflicting evidence, such as an old interface design specification requiring the reuse of an existing approval interface, the content is marked as a conflict item and added to the pending confirmation list. The pass rate of each chapter is calculated. For example: the pass rate of the module design chapter is 92%; the pass rate of the interface design chapter is 76%; and the pass rate of the data design chapter is 61%. When the pass rate of a certain chapter is lower than the threshold, the overall status of the document is adjusted to "pending verification" or "insufficient evidence".

[0068] It should be noted that reverse consistency verification can employ rule-based field comparison, semantic similarity comparison, natural language inference model comparison, or multi-strategy fusion.

[0069] This embodiment ensures the accuracy and completeness of the change impact analysis report by introducing a change impact analysis report and a reverse consistency verification mechanism. Through multi-dimensional reverse verification methods, it avoids factual errors, logical contradictions, and missing evidence in the generated documents, thereby improving the credibility, traceability, and engineering usability of document generation in complex existing systems.

[0070] After obtaining the document data, structured evidence units are generated based on the document data. Optionally, in the system document generation method provided in this application embodiment, generating multiple evidence units based on the document data includes: if the document data contains a code directory, extracting code elements from the code directory, wherein the code elements include at least one of the following: directory structure, module name, interface path, function name, configuration item, and database access statement; if the document data contains historical documents or knowledge documents, extracting semantic elements from the historical documents or knowledge documents, wherein the semantic elements include at least one of the following: chapter title, entity name, business process, boundary conditions, terminology definition, and rule description; if the document data contains new requirements, extracting requirement intent elements from the new requirements, wherein the requirement intent elements include at least one of the following: target function, change point, constraint condition, scope of impact, and expected output; determining the code elements, or semantic elements, or requirement intent elements as entities of the evidence unit; obtaining relevant information about the entity from the document data, and generating evidence units based on the entity and the relevant information about the entity, wherein the relevant information includes at least one of the following: evidence identifier, source type, source path, source location, entity category, entity name, content summary, time information, and credibility index value.

[0071] In some embodiments, parsing is performed on different input sources: for code directories, the directory structure, module names, interface paths, function names, configuration items, database access statements, etc., are extracted; for historical documents and knowledge documents, chapter titles, entity names, business processes, boundary conditions, terminology definitions, rule descriptions, etc., are extracted; for new user requirements, the target function, change points, constraints, scope of impact, and expected output are extracted. The parsing results are then standardized into evidence units. Each evidence unit contains at least the following fields: evidence identifier; source type; source path; source location; entity category; entity name; content summary; time information; and credibility index value.

[0072] Figure 6 This is a schematic diagram of the evidence generation unit provided according to the embodiments of this application, such as... Figure 6 As shown, the target workspace contains the following materials: two code repositories, namely the business service repository and the front-end portal repository; three old documents, namely the old requirements specification, the old outline design, and the interface constraint document; one domain knowledge document, which records the approval rules; and one new requirement, which states "Add a second-level approval node after the order is submitted and record the approval comments".

[0073] First, the code repository was parsed to identify objects such as the order service, approval service, message notification service, order controller, approval status enumeration, and order table. Next, the old documents were parsed to identify sections such as "Order Flow," "Approval Process," and "Interface Access Control." Then, approval hierarchy rules and role definitions were extracted from the domain knowledge document, and two core change points were extracted from the new requirements: "Adding a Second-Level Approval Node" and "Recording Approval Comments." Afterwards, the following evidence units were formed: Evidence E1: From the business service repository `order_controller`, entity type is interface, entity name is order submission interface; Evidence E2: From the approval service code, entity type is module, entity name is approval process service; Evidence E3: From the database script, entity type is field, entity name is approval comment field; Evidence E4: From the old design document, entity type is process, entity name is order approval process; Evidence E5: From the knowledge document, entity type is rule, entity name is second-level approval rule; Evidence E6: From the new requirement, entity type is change point, entity name is adding a second-level approval node.

[0074] An evidence graph is constructed based on realization relationships, constraint relationships, and influence relationships. For example, a rule constraint relationship is established between E6 and E5, an influence relationship is established between E6 and E2, a call or dependency relationship is established between E2 and E1, a data change relationship is established between E2 and E3, and a process correspondence relationship is established between E4 and E2. The extraction of evidence units can be achieved through rule parsing, syntax tree analysis, and regular expression recognition, or through machine learning named entity recognition models, or a combination of both.

[0075] This embodiment extracts the technical implementation, business semantics, and change intent from code, historical documents, and new requirements respectively, and endows them with rich metadata attributes. This achieves efficient conversion from raw materials to structured, computable, and traceable evidence, providing a solid data foundation for the subsequent construction of high-quality evidence maps and the accurate generation of documents based on evidence constraints.

[0076] After obtaining the evidence units, an evidence graph is constructed. Optionally, in the system document generation method provided in this application embodiment, constructing an evidence graph based on multiple evidence units includes: determining the association relationship based on the relevant information of multiple evidence units, wherein the association relationship includes at least one of the following: code call relationship, document reference relationship, interface and implementation relationship, entity naming correspondence relationship, directory proximity relationship, semantic similarity relationship, version relationship, conflict relationship, and supplementary relationship; constructing nodes corresponding to the evidence units, and connecting edges between nodes corresponding to evidence units with association relationships; and constructing the evidence graph based on the nodes and edges.

[0077] In some embodiments, conflict evidence refers to evidence units that provide different descriptions, versions, or contradictory constraints for the same entity or business process. Association edges are established between evidence units based on at least one of the following relationships: code call relationship; document reference relationship; interface and implementation relationship; entity naming correspondence relationship; directory proximity relationship; semantic similarity relationship; version relationship; conflict relationship; and supplementary relationship. This results in an evidence graph. The evidence graph can indicate which code module implements a certain interface, which business process is described in a certain historical document section, and which modules, tables, and upstream and downstream systems are affected by a new requirement.

[0078] It should be noted that the evidence graph does not necessarily need to be explicitly stored in a graph database; instead, it can use a multi-table structure in a relational database to express the relationships between nodes and edges. Chapter generation does not necessarily require a unified large model; it can also use a combination of rule templates and local text generation. Consistency verification can be performed using rule verification, vector similarity verification, semantic implication verification, or a combination thereof. These alternative implementation methods do not affect the inventiveness of this invention, which is based on "chapter slot constraint-driven generation and reverse consistency verification to determine admission." The evidence graph can include time version information to form a temporal evolution evidence graph, which describes how a requirement gradually leads to design and code changes, thereby expanding the scope of protection of this invention.

[0079] This embodiment successfully constructs a structured knowledge network that comprehensively reflects the multidimensional relationships between code, documents, and requirements in a complex existing system by defining various types of associations and transforming evidence units into connections between nodes and edges. This achieves the organic integration of multi-source heterogeneous evidence and provides the necessary data structure and computational foundation for subsequent precise evidence screening, impact analysis, and consistency verification based on graph topology.

[0080] After constructing the evidence graph, candidate evidence sets for each chapter slot are selected from the evidence graph. Optionally, in the system document generation method provided in this application embodiment, selecting candidate evidence sets for each chapter slot from the evidence graph includes: obtaining configuration information for each chapter slot, wherein the configuration information includes at least one of the following: slot name, slot order, required evidence type set, optional evidence type set, minimum evidence coverage, evidence conflict adjudication rules, output structure requirements, and prohibited output items; determining candidate index values ​​for evidence units based on the relevance between chapter slots and evidence units; and selecting candidate evidence sets from the evidence graph based on the configuration information and candidate index values.

[0081] In some embodiments, each chapter slot is configured with at least: slot name; slot order; set of required evidence types, set of optional evidence types, minimum evidence coverage, evidence conflict adjudication rules, output structure requirements, and prohibited output items. For each chapter slot, candidate evidence is retrieved from the evidence graph. Candidate evidence selection may comprehensively consider the following factors: entity category matching degree; correlation strength with the user's new requirements; credibility of the evidence source; time freshness; semantic relevance to the template slot; graph adjacency depth; and degree of conflict.

[0082] This embodiment introduces a dual screening mechanism that combines refined configuration information of chapter slots with quantified candidate indicator values. This enables the precise location of evidence subsets strongly related to specific chapters from a massive evidence graph. This not only ensures the relevance, compliance, and high quality of the generated content, but also reduces interference factors in the large model generation process through a pre-filtering mechanism, thereby improving the accuracy and efficiency of document generation.

[0083] Optionally, in the system document generation method provided in this application embodiment, selecting a candidate evidence set from the evidence graph based on configuration information and candidate indicator values ​​includes: determining the evidence unit set corresponding to the evidence graph; removing evidence units from the evidence unit set that do not match entity categories and are prohibited output items to obtain an updated evidence unit set; removing evidence units from the updated evidence unit set whose candidate indicator values ​​are less than the indicator value threshold to obtain a pending evidence set; determining whether the evidence units in the pending evidence set cover the required evidence type set; issuing a second prompt message if the evidence units in the pending evidence set do not cover the required evidence type set, wherein the second prompt message is used to indicate insufficient evidence; and determining the pending evidence set as a candidate evidence set if the evidence units in the pending evidence set cover the required evidence type set.

[0084] In some embodiments, candidate index values ​​are calculated for each evidence unit, and evidence with scores higher than a threshold is selected to enter the candidate set for that chapter slot. At least the following judgment rules are performed: first, evidence that does not match the entity category or hits a prohibited output item is removed; then, evidence with a comprehensive score not lower than a preset threshold is retained; then, it is calculated whether the retained evidence covers the set of required evidence types required for that chapter slot; if the required evidence types are not fully covered, the chapter slot is directly marked as "insufficient evidence" instead of continuing to generate a definitive conclusion.

[0085] This embodiment uses a screening mechanism that employs hard rule filtering, relevance threshold screening, and necessary type coverage detection to exclude irrelevant and illegal content, ensuring the integrity of core evidence types and guaranteeing the accuracy, compliance, and information integrity of the generated documents.

[0086] Optionally, in the system document generation method provided in this application embodiment, determining the candidate index value of the evidence unit based on the relevance between the chapter slot and the evidence unit includes: determining the relevance index value between the chapter slot and the evidence unit, wherein the relevance index value includes at least one of the following: semantic relevance, structural relevance, source credibility, time freshness, and multi-source corroboration; and determining the candidate index value based on each type of relevance index value and the corresponding preset weight.

[0087] In some embodiments, the relevance index value is uniformly converted to a score of 0 to 100, and the candidate index value of the candidate evidence is calculated according to the following formula, for example: candidate index value = 0.35 × semantic relevance + 0.20 × structural relevance + 0.20 × source credibility + 0.10 × time freshness + 0.15 × multi-source corroboration - conflict penalty value.

[0088] Among them: semantic relevance characterizes the degree of semantic matching between the evidence content and the chapter slot description; structural relevance characterizes the degree of matching between the evidence and the entity type, directory location, calling relationship or table structure location required by the slot; source credibility characterizes the reliability of the evidence source; time freshness characterizes the time proximity between the evidence version and the current target requirement version; multi-source corroboration characterizes the degree to which the same conclusion is supported by multiple independent sources; conflict penalty value characterizes the degree of conflict between the evidence and high-priority evidence.

[0089] For example, the chapter slot description and candidate evidence content are input into a semantic scoring model or a large language model, which then outputs a semantic relevance score from 0 to 100. If the candidate evidence directly supports the core content of the current chapter slot, the semantic relevance score can be 80 to 100; if the candidate evidence can only serve as supplementary explanation or background material, the semantic relevance score can be 60 to 80; if the candidate evidence has only a weak correlation with the current chapter slot, the semantic relevance score can be 30 to 60; and if the candidate evidence has no significant correlation with the current chapter slot, the semantic relevance score can be 0 to 30.

[0090] Structural relevance can be determined by a combination of path distance score, relation type weight, and entity type matching coefficient, and calculated using the following formula: Structural Relevance = 0.50 × Path Distance Score + 0.30 × Relation Type Weight + 0.20 × Entity Type Matching Coefficient. Here, the path distance score is determined by the shortest path hop count between the candidate evidence node and the target node in the current chapter slot; the relation type weight is determined by the relation types included in the path, such as influence, call, update, notification, data change, dependency, reference, semantic similarity, or conflict; and the entity type matching coefficient is determined by whether the entity category of the candidate evidence belongs to the required evidence type, recommended evidence type, background evidence type, or mismatch type of the current chapter slot. When the shortest path has 0 hops, the path distance score can be 100; 1 hop, 90; 2 hops, 75; 3 hops, 60; 4 hops, 40; if the two are not connected in the evidence graph, the path distance score can be 0. For relation type weights, a weight of 100 is used for direct impact relations, 95 for calling relations, 90 for update, notification, or data change relations, 75 for dependency relations, 60 for reference relations, and 50 for semantic similarity relations. Conflicting relations are not included in the positive structural relevance score but are instead used in conflict detection and penalty calculations. For entity type matching coefficients, a weight of 100 is used if the candidate evidence belongs to the required evidence type for the current chapter slot; 80 is used if it belongs to the recommended evidence type; 50 is used if it belongs to the background evidence type; and 20 is used if it belongs to the unsuitable type.

[0091] Source credibility can be assigned a value based on source type: 95 for current version code files, interface definition files, and database scripts; 85 for currently approved design documents; 80 for currently approved requirement documents; 70 for historical design documents or historical requirement documents; and 60 for knowledge documentation documents or manually supplemented explanations. Time freshness can be assigned a value based on the interval between the evidence timestamp and the current requirement version timestamp: 100 for no more than 30 days; 80 for 31 to 90 days; 60 for 91 to 180 days; and 40 for more than 180 days. Multi-source corroboration can be assigned a value based on the number of independent sources: 100 for at least 3 independent sources; 80 for 2 independent sources; 50 for 1 source; and 0 for no valid supporting source. Conflict penalty value can be assigned a value based on conflict severity: 0 for no conflict; 10 for Level 1 conflict; 20 for Level 2 conflict; and 40 for Level 3 conflict.

[0092] When a candidate indicator value is not lower than 75, the corresponding evidence is included in the high-confidence candidate set; when a candidate indicator value is not lower than 60 but lower than 75, the corresponding evidence is included in the low-confidence candidate set; when a candidate indicator value is lower than 60, the corresponding evidence is not included in the candidate set. Therefore, it is possible to determine whether the current chapter slot has a sufficient evidentiary basis for generation before chapter generation.

[0093] This embodiment constructs a multi-dimensional evaluation system that includes semantics, structure, source, time, and multi-source corroboration, and performs weighted calculations based on preset weights. This achieves a comprehensive and quantitative evaluation of the quality of evidence units, ensuring that the candidate evidence set is not only relevant in content, but also meets the requirements for high-quality document generation in terms of structure, authority, and timeliness, thereby improving the accuracy and credibility of the generated content.

[0094] Optionally, in the system document generation method provided in this application embodiment, after determining the evidence coverage rate of the chapter slot based on the candidate evidence set, the method further includes: issuing a third prompt message when the evidence coverage rate is greater than or equal to a second coverage threshold and less than or equal to a first coverage threshold, wherein the third prompt message is used to prompt that the chapter content of the chapter slot needs to be verified; and issuing a fourth prompt message when the evidence coverage rate is less than the second coverage threshold, wherein the fourth prompt message is used to prompt that the chapter slot needs to supplement evidence.

[0095] In some embodiments, the first coverage threshold can be 0.80 and the second coverage threshold can be 0.60. When the evidence coverage is between 0.6 and 0.80, low-confidence chapter content with a "pending human confirmation" prompt is allowed to be output. When the evidence coverage is below 0.60, no definitive conclusion is output, and only a prompt for supplementary evidence is output.

[0096] This embodiment constructs a flexible document generation quality control checkpoint by setting differentiated evidence coverage thresholds and corresponding hierarchical prompting mechanisms. This avoids the rigid situation where documents cannot be generated at all due to insufficient evidence. The hierarchical prompts clarify the timing and necessity of human intervention, achieving a dynamic balance between generation efficiency and content credibility, and improving the robustness and practicality of the system in complex existing system scenarios.

[0097] According to another embodiment of this application, a system for generating system documents is also provided. Figure 7 This is a schematic diagram of a system for generating system documents according to embodiments of this application. For example... Figure 7 As shown, the system includes:

[0098] Data acquisition module: used to collect code directories, historical document directories, knowledge document directories, template files, and user-entered requirement information from the target workspace.

[0099] Specifically, the system first acquires code, historical documents, knowledge documents, and user input through a data acquisition module. For the code directory, the system can identify different repository names, directory levels, configuration files, interface definition files, and database scripts. For historical and knowledge documents, the system can identify titles, chapters, tables, and constraint descriptions. For user input, the system supports Markdown, form input, or other text input methods.

[0100] Heterogeneous parsing module: Used to parse code files, Markdown documents, conversion results of various documents, interface descriptions, database scripts, etc., and extract entity information such as modules, interfaces, tables, processes, constraints, and roles.

[0101] Specifically, the heterogeneous parsing module executes different parsing strategies for different sources. For example, for various code or front-end scripts, it can extract and identify module names, interface paths, function definitions, and dependencies through syntax analysis or rule extraction; for Markdown documents, it can extract business processes, design specifications, and constraints based on heading levels and key terms; for converted documents, it can first organize paragraphs and headings before performing entity recognition. The parsing results are uniformly handed over to the evidence standardization module.

[0102] Evidence Standardization Module: This module converts the analysis results into evidence units in a unified format, with unified naming, timestamps, source descriptions, and a credibility score.

[0103] Specifically, the evidence standardization module normalizes entities with the same name. For example, an interface might be written as ` / api / order / create` in the code, "order creation interface" in the old documentation, and "order placement service entry" in the knowledge documentation. The system can group them into the same entity cluster using a terminology dictionary, naming mapping rules, and contextual semantic similarity. Then, a unique identifier is assigned to each evidence unit and written to a unified field.

[0104] Evidence Graph Construction Module: Used to establish graph connections between evidence units based on naming similarity, directory structure relationships, calling relationships, referencing relationships, and semantic associations.

[0105] Specifically, the evidence graph construction module establishes edges based on code call chains, file proximity, entity naming correspondence, document reference relationships, and time relationships. For example, if a requirement mentions "adding an approval status field," and the code contains an order entity class, an order table migration script, and an approval service module, the system can establish relationships such as "impact," "implementation," and "dependency" between these evidence units.

[0106] Template Slot Management Module: This module is used to split requirement templates and design templates into several chapter slots, and to define the types of evidence allowed, minimum coverage requirements, conflict resolution rules, and output format requirements for each slot.

[0107] Specifically, the template slot management module reads the requirement template or design template and converts it into structured slot definitions within the system. Taking design documents as an example, the "Interface Design" slot can require at least evidence of the interface path, the calling module, and the input / output parameters; the "Database Design" slot can require at least evidence of table structure or field changes; and the "Exception Handling" slot can require at least evidence of boundary conditions or error codes.

[0108] Chapter generation module: Used to generate document content one by one according to chapter slots, and record the mapping relationship between chapter content and evidence units.

[0109] Specifically, the chapter generation module reads the current slot definition and candidate evidence set, and generates text separately for each chapter. Preferably, the system synchronously records the mapping between paragraphs and evidence units when generating text, so as to facilitate subsequent reverse verification and traceability display.

[0110] Consistency verification module: used to reverse-engineer entity and constraint information from the generated document content, back-check the evidence graph, and identify unsubstantiated content, conflicting content, missing content, and low-confidence content.

[0111] Specifically, the consistency verification module performs a second parsing operation after the document generation is complete. For example, for the generated "Interface Design" section, it can extract the interface name, path, method, parameters, and return value, and compare them item by item with the interface evidence in the evidence graph. If the document mentions a non-existent interface or omits key parameters, it is marked as an anomaly.

[0112] Impact Analysis Module: Used to analyze the impact of new demands and their associated evidence within an evidence graph, and automatically generate a CIA report.

[0113] Specifically, the impact analysis module starts with key change points in the new requirements, propagates through several layers of evidence graph, identifies directly and indirectly affected entities, and ultimately outputs a CIA report. This CIA report may include affected modules, databases, interfaces, upstream and downstream systems, testing scope, and implementation risks.

[0114] Status Management Module: This module is used to divide the document generation process into states such as "not generated, generating, pending verification, verification passed, insufficient evidence, conflict exists, and published", avoiding the simple use of file existence as the sole criterion for judgment.

[0115] Specifically, the status management module calculates the final status based on information such as whether generation is complete, whether verification has passed, whether conflicts exist, and whether evidence is sufficient. Preferably, the status management module first determines whether there are level 3 conflicts or whether the cumulative number of level 2 conflicts has reached a threshold, then determines whether the overall document evidence coverage rate and key chapter evidence coverage rate meet the standards, and finally determines whether verification and release confirmation have been completed. For example, if the requirements document file has been generated, but the overall document evidence coverage rate is 0.78, or the "Data Design" chapter coverage rate is only 0.55, the system determines its status as "insufficient evidence"; if the overall evidence coverage rate of the design document is not less than 0.80, the chapter review pass rate is not less than 0.90, and there are no level 3 conflicts, the status is determined as "verification passed" or "released".

[0116] The results output module is used to output requirements documents, design documents, CIA reports, evidence traceability indexes, and status information, and supports querying, downloading, and secondary review.

[0117] The chapter generation module can be implemented based on a rule engine, a retrieval-enhanced generation engine, or a large language model; the evidence graph can be implemented using graph databases, relational databases with associated tables, in-memory graph structures, etc.; and the evidence credibility score can be implemented using rule scores, statistical scores, or machine learning model scores.

[0118] The system document generation system in this embodiment first transforms information such as code, historical documents, knowledge files, and manually added requirements from complex existing systems into referenceable, computable, and traceable evidence units. Then, based on the target document template, the document is divided into multiple chapter slots, and the required evidence types, minimum coverage, prohibited output items, and output structure requirements are predefined for each chapter slot. Subsequently, relevant evidence is dynamically selected from the evidence graph for each chapter slot, and constrained content generation is performed. Finally, evidence review, conflict detection, and coverage evaluation are performed on the generated results. Only chapter content that meets the review conditions is included in the final document, improving the accuracy of document generation.

[0119] According to another embodiment of this application, an optional method for generating system documents is also provided, applied to a system document generation system. Figure 8 This is a schematic diagram illustrating an optional system document generation method provided according to an embodiment of this application. For example... Figure 8 As shown, the method includes:

[0120] The system collects input from multiple sources, receives the target workspace identifier, and loads various input materials from that workspace. If non-Markdown historical documents exist, format conversion is performed first.

[0121] The system generates evidence units by parsing code, legacy documents, knowledge documents, and user requirements to obtain preliminary parsed objects. For code objects, they can be organized hierarchically by directory, module, class, function, interface, configuration item, and database access statement; for document objects, they can be organized hierarchically by title, paragraph, table, and terminology definition. The system converts the preliminary parsed objects into evidence units. Preferably, in addition to storing the entity content, the evidence unit also records the source path and source location, enabling subsequent displays in the interface or output results to directly show "which part of which file this content originates from".

[0122] The system constructs an evidence graph. It generates a vector representation for each evidence unit and establishes edges by combining structural and semantic relationships. This allows it to handle both strongly structured information and natural language descriptions with significant differences in expression.

[0123] Template slotting involves the system reading the target document template and performing slotting processing. If the template has a fixed chapter order, the system retains that order; if the template contains table items, list items, or required chapter fields, it converts them into structured output constraints.

[0124] Candidate evidence screening involves the system retrieving candidate evidence for each slot. Preferably, the system calculates a comprehensive score for the candidate evidence: Comprehensive score = 0.35. Semantic relevance +0.20 Structural relevance +0.20 Source credibility +0.10 Freshness of time +0.15 Multi-source corroboration degree - conflict penalty value.

[0125] Semantic relevance, structural relevance, source credibility, time freshness, and multi-source corroboration are all standardized to a range of 0 to 100, with conflict penalty values ​​of 0, 10, 20, or 40. Preferably, a comprehensive score of 75 or higher is considered high-credibility candidate evidence; a comprehensive score of 60 to 75 is considered low-credibility candidate evidence; and a comprehensive score below 60 is considered invalid candidate evidence.

[0126] For example, in the "Interface Design" slot, the system retrieved three relevant pieces of evidence. Evidence E1 comes from the current version of the interface definition file, with a semantic relevance of 92, structural relevance of 95, source credibility of 95, time freshness of 100, multi-source corroboration of 80, and conflict penalty of 0, resulting in a comprehensive score of 92.2. Evidence E2 comes from an older design document from three months ago, with a semantic relevance of 88, structural relevance of 70, source credibility of 70, time freshness of 60, multi-source corroboration of 80, and conflict penalty of 10, resulting in a comprehensive score of 66.8. Evidence E3 comes from the current requirements document, with a semantic relevance of 85, structural relevance of 50, source credibility of 80, time freshness of 100, multi-source corroboration of 50, and conflict penalty of 0, resulting in a comprehensive score of 73.25. Therefore, the system includes E1 in the high-credibility candidate set, E3 in the low-credibility candidate set, and does not include E2 in the subsequent definitive conclusion.

[0127] For constrained chapter generation, the system determines whether candidate evidence meets the minimum coverage requirement. If it does, the system proceeds to generate the corresponding chapter content; otherwise, it outputs a "needs supplementary evidence" prompt in the chapter results and reflects this in the final status. Preferably, the evidence coverage rate for a chapter slot is calculated as "number of required evidence types satisfied / total number of required evidence types". When the "interface design" slot requires 4 types of required evidence but only 3 types are currently satisfied, its evidence coverage rate is 0.75. Therefore, the system only outputs a low-confidence chapter with a manual confirmation prompt and does not output a deterministic interface parameter conclusion. The system generates documents in chapter order. During the generation process, context is created for the generated chapters to ensure consistent terminology and content flow in subsequent chapters.

[0128] The system generates a CIA report based on new user requests and graph relationships. For example, when a new request involves the order approval workflow, the system can propagate along the related edges such as the order module, approval service, message notification, database tables, and external interfaces to form an impact list.

[0129] Reverse consistency verification is performed by the system. Preferably, if the proportion of unsubstantiated content in a certain chapter exceeds 0.10, the chapter is marked as a "low-confidence chapter"; if there is at least one level 3 conflict or at least three level 2 conflicts in the document, the overall document status is marked as "conflict exists and needs confirmation". If the overall evidence coverage of the document is lower than 0.80, or the evidence coverage of any key chapter is lower than 0.60, the overall document status is marked as "insufficient evidence".

[0130] Status determination and result output: The system generates a final result object and outputs a document file, a CIA report, status metadata, and an evidence traceability index.

[0131] The optional system document generation method in this embodiment first limits the allowed evidence types, minimum coverage, and prohibited output items for each chapter through chapter slot constraints. This makes the ability to generate documents a pre-judgmentable question, reducing unfounded generation and content drift. Reverse consistency verification checks the evidence sources of generated content chapter by chapter, changing document output from completion upon generation to acceptance only after verification, thereby improving the credibility, verifiability, and traceability of the results. This closed-loop design of slot-constrained generation and reverse verification is suitable for scenarios where code, old documents, and new requirements are often inconsistent in complex existing systems. It can output documents that match the existing system more stably than general document generation solutions. For large existing systems, it can reduce the workload of manually retrieving, organizing, and reviewing documents, improving the efficiency of requirements analysis, solution design, and change review.

[0132] It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions, and although a logical order is shown in the flowchart, in some cases the steps shown or described may be executed in a different order than that shown here.

[0133] This application also provides a system document generation apparatus. It should be noted that the system document generation apparatus of this application can be used to execute the system document generation method provided in this application. The system document generation apparatus provided in this application will be described below.

[0134] Figure 9 This is a schematic diagram of a system document generation apparatus provided according to an embodiment of this application. For example... Figure 9 As shown, the device includes:

[0135] The receiving unit 901 is used to receive input document data and target template, and generate multiple evidence units based on the document data. The evidence unit is a reference information object parsed from the document data.

[0136] Construction unit 902 is used to construct an evidence graph based on multiple evidence units. The evidence graph contains multiple nodes and multiple edges. Nodes are used to represent evidence units, and edges between nodes are used to represent the association relationship between the evidence units corresponding to the nodes.

[0137] The splitting unit 903 is used to split the target template into multiple chapter slots and filter the candidate evidence set for each chapter slot from the evidence graph. The chapter slot is a structured unit split from the target template according to semantic logic. The candidate evidence units in the candidate evidence set are used to generate the document content of the chapter slot.

[0138] The first determining unit 904 is used to determine the evidence coverage rate of the chapter slot based on the candidate evidence set. When the evidence coverage rate is greater than or equal to the first coverage rate threshold, the chapter content of the chapter slot is generated based on the candidate evidence set. The evidence coverage rate is the ratio of the target number to the total number of evidence types required by the chapter slot. The target number is the number of evidence types in the candidate evidence set that meet the requirements of the chapter slot.

[0139] Generation unit 905 is used to generate target documents based on the chapter content of each chapter slot.

[0140] The system document generation apparatus provided in this application embodiment receives input document data and a target template through a receiving unit 901, and generates multiple evidence units based on the document data. Each evidence unit is a reference information object parsed from the document data. A construction unit 902 constructs an evidence graph based on the multiple evidence units. The evidence graph contains multiple nodes and edges; nodes represent evidence units, and edges represent the relationships between the evidence units corresponding to the nodes. A splitting unit 903 splits the target template into multiple chapter slots and selects candidate evidence sets for each chapter slot from the evidence graph. Each chapter slot is a structured unit split from the target template according to semantic logic, and the candidate evidence units in the candidate evidence set are used to generate the document content for the chapter slot. A first determining unit 904 determines the chapter slot content based on the candidate evidence set. Evidence coverage rate: When the evidence coverage rate is greater than or equal to a first coverage rate threshold, chapter content for each chapter slot is generated based on the candidate evidence set. Evidence coverage rate is the ratio of the target number to the total number of evidence types required for each chapter slot, and the target number is the number of evidence types in the candidate evidence set that meet the chapter slot requirements. Generation unit 905 generates the target document based on the chapter content of each chapter slot. This solves the problem of inaccurate documents generated by large models in related technologies. It parses multi-source document data input into structured evidence units, achieving strong traceability and support of the generated content to the original multi-source data, effectively avoiding the illusion of a large model. The target template is then split into chapter slots, and candidate evidence screening and segmented generation are performed around each chapter slot, ensuring that the content of each chapter conforms to the template specifications and maintains consistency with the logical relationships between system entities. Introducing evidence coverage rate as a pre-generation verification condition ensures that deterministic content is generated only when candidate evidence fully covers the required types of the chapter. This suppresses unfounded generation or missing content, improving the completeness and standardization of the document, thereby improving the accuracy of document generation.

[0141] Optionally, in the system document generation apparatus provided in this application embodiment, the apparatus further includes: an extraction unit, used to extract new requirements and / or change requirements of the system from document data, and determine target nodes affected by the new requirements and / or change requirements from the evidence graph; a report generation unit, used to generate a change impact analysis report based on the target nodes, new requirements and / or change requirements; a reverse parsing unit, used to perform reverse parsing on the change impact analysis report and the target document to obtain multiple entities and the relationships between entities; a verification unit, used to perform reverse consistency verification through multiple entities, relationships and evidence graph, wherein the reverse consistency verification includes at least one of the following: entity existence verification, interface path verification, entity corresponding relationship verification, business process closed-loop verification, constraint consistency verification and impact scope integrity verification; a publishing unit, used to publish the target document if the reverse consistency verification passes; and a first prompt unit, used to issue a first prompt message if the reverse consistency verification fails, wherein the first prompt message is used to indicate that the target document has evidence defects.

[0142] Optionally, in the system document generation apparatus provided in this application embodiment, the receiving unit 901 includes: a first extraction module, configured to extract code elements from the code directory when the document data contains a code directory, wherein the code elements include at least one of the following: directory structure, module name, interface path, function name, configuration item, and database access statement; a second extraction module, configured to extract semantic elements from historical documents or knowledge documents when the document data contains historical documents or knowledge documents, wherein the semantic elements include at least one of the following: chapter title, entity name, business process, boundary conditions, terminology definition, and rule description; and a third extraction module. This module is used to extract the intent elements of new requirements from the new requirements when the document data contains new requirements. The intent elements include at least one of the following: target function, change point, constraint, scope of impact, and expected output. The first determination module is used to determine the code element, semantic element, or intent element as the entity of the evidence unit. The generation module is used to obtain relevant information of the entity from the document data and generate the evidence unit based on the entity and the relevant information of the entity. The relevant information includes at least one of the following: evidence identifier, source type, source path, source location, entity category, entity name, content summary, time information, and credibility index value.

[0143] Optionally, in the system document generation apparatus provided in this application embodiment, the construction unit 902 includes: a second determining module, used to determine the association relationship based on the relevant information of multiple evidence units, wherein the association relationship includes at least one of the following: code call relationship, document reference relationship, interface and implementation relationship, entity naming correspondence relationship, directory proximity relationship, semantic similarity relationship, version new and old relationship, conflict relationship and supplementary relationship; a first construction module, used to construct the node corresponding to the evidence unit and connect the edges between the nodes corresponding to the evidence units with the association relationship; and a second construction module, used to construct the evidence graph based on the nodes and edges.

[0144] Optionally, in the system document generation apparatus provided in this application embodiment, the splitting unit 903 includes: a configuration information acquisition module, used to acquire configuration information for each chapter slot, wherein the configuration information includes at least one of the following: slot name, slot order, required evidence type set, optional evidence type set, minimum evidence coverage, evidence conflict adjudication rules, output structure requirements, and prohibited output items; a third determination module, used to determine candidate index values ​​for evidence units based on the relevance between chapter slots and evidence units; and a filtering module, used to filter out a set of candidate evidence from the evidence graph based on the configuration information and candidate index values.

[0145] Optionally, in the system document generation apparatus provided in this application embodiment, the filtering module includes: a first determining submodule, used to determine the set of evidence units corresponding to the evidence map, and remove evidence units from the set of evidence units that do not match the entity category and are prohibited output items to obtain an updated set of evidence units; a removing submodule, used to remove evidence units from the updated set of evidence units whose candidate index values ​​are less than the index value threshold to obtain a set of pending evidence; a judging submodule, used to judge whether the evidence units in the set of pending evidence cover the set of required evidence types; a prompting submodule, used to issue a second prompting message when the evidence units in the set of pending evidence do not cover the set of required evidence types, wherein the second prompting message is used to indicate insufficient evidence; and a second determining submodule, used to determine the set of pending evidence as a set of candidate evidence when the evidence units in the set of pending evidence cover the set of required evidence types.

[0146] Optionally, in the system document generation device provided in this application embodiment, the third determining module includes: a third determining submodule, used to determine the relevance index value between chapter slots and evidence units, wherein the relevance index value includes at least one of the following: semantic relevance, structural relevance, source credibility, time freshness, and multi-source corroboration; and a fourth determining submodule, used to determine candidate index values ​​based on the relevance index value of each type and the corresponding preset weight.

[0147] Optionally, in the system document generation apparatus provided in this application embodiment, the apparatus further includes: a second prompting unit, configured to issue a third prompting message when the evidence coverage rate is greater than or equal to a second coverage threshold and less than or equal to a first coverage threshold, wherein the third prompting message is used to prompt that the chapter content of the chapter slot needs to be verified; and a third prompting unit, configured to issue a fourth prompting message when the evidence coverage rate is less than the second coverage threshold, wherein the fourth prompting message is used to prompt that the chapter slot needs to be supplemented with evidence.

[0148] The system document generation device includes a processor and a memory. The receiving unit 901, the building unit 902, the splitting unit 903, the first determining unit 904, and the generating unit 905 are all stored in the memory as program units. The processor executes the program units stored in the memory to realize the corresponding functions.

[0149] The processor contains a kernel, which retrieves the corresponding program units from memory. One or more kernels can be configured, and adjusting kernel parameters can improve the accuracy of document generation.

[0150] The memory may include non-permanent memory in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM, and the memory includes at least one memory chip.

[0151] This invention provides a computer-readable storage medium storing a program that, when executed by a processor, implements a method for generating system documents.

[0152] This invention provides a processor for running a program, wherein the program executes a method for generating system documents during runtime.

[0153] Figure 10 This is a schematic diagram of an electronic device provided according to an embodiment of this application. For example... Figure 10As shown, the electronic device 1001 includes a processor, a memory, and a program stored in the memory and executable on the processor. When the processor executes the program, it performs the following steps: receiving input document data and a target template; generating multiple evidence units based on the document data, wherein each evidence unit is a reference information object parsed from the document data; constructing an evidence graph based on the multiple evidence units, wherein the evidence graph contains multiple nodes and multiple edges, where nodes represent evidence units and edges between nodes represent the relationships between the evidence units corresponding to the nodes; splitting the target template into multiple chapter slots; selecting a candidate evidence set for each chapter slot from the evidence graph, wherein each chapter slot is a structured unit split from the target template according to semantic logic, and the candidate evidence units in the candidate evidence set are used to generate the document content of the chapter slot; determining the evidence coverage rate of the chapter slot based on the candidate evidence set; and generating the chapter content of the chapter slot based on the candidate evidence set if the evidence coverage rate is greater than or equal to a first coverage threshold, wherein the evidence coverage rate is the ratio of the target number to the total number of evidence types required by the chapter slot, and the target number is the number of evidence types in the candidate evidence set that meet the requirements of the chapter slot; and generating a target document based on the chapter content of each chapter slot. The devices mentioned in this article can be servers, PCs, tablets, mobile phones, etc.

[0154] This application also provides a computer program product, which, when executed on a data processing device, is suitable for executing an initialization program with the following method steps: receiving input document data and a target template; generating multiple evidence units based on the document data, wherein each evidence unit is a reference information object parsed from the document data; constructing an evidence graph based on the multiple evidence units, wherein the evidence graph contains multiple nodes and multiple edges, where nodes are used to represent evidence units and edges between nodes are used to represent the association relationship between the evidence units corresponding to the nodes; splitting the target template into multiple chapter slots; selecting a candidate evidence set for each chapter slot from the evidence graph, wherein each chapter slot is a structured unit split from the target template according to semantic logic, and the candidate evidence units in the candidate evidence set are used to generate the document content of the chapter slot; determining the evidence coverage rate of the chapter slot based on the candidate evidence set; and generating the chapter content of the chapter slot based on the candidate evidence set if the evidence coverage rate is greater than or equal to a first coverage rate threshold, wherein the evidence coverage rate is the ratio of the target number to the total number of evidence types required by the chapter slot, and the target number is the number of evidence types in the candidate evidence set that meet the requirements of the chapter slot; and generating a target document based on the chapter content of each chapter slot.

[0155] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0156] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0157] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0158] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0159] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0160] Memory may include non-persistent memory in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0161] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information using any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0162] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0163] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0164] The above are merely embodiments of this application and are not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.

Claims

1. A method for generating system documents, characterized in that, include: The system receives input document data and a target template, and generates multiple evidence units based on the document data, wherein the evidence unit is a reference information object parsed from the document data; An evidence graph is constructed based on the multiple evidence units, wherein the evidence graph contains multiple nodes and multiple edges, the nodes are used to represent the evidence units, and the edges between the nodes are used to represent the association relationship between the evidence units corresponding to the nodes; The target template is split into multiple chapter slots, and a set of candidate evidence for each chapter slot is selected from the evidence graph. The chapter slot is a structured unit split from the target template according to semantic logic, and the candidate evidence units in the set of candidate evidence are used to generate the document content of the chapter slot. Based on the candidate evidence set, the evidence coverage rate of the chapter slot is determined. If the evidence coverage rate is greater than or equal to a first coverage threshold, the chapter content of the chapter slot is generated based on the candidate evidence set. The evidence coverage rate is the ratio of the target number to the total number of evidence types required by the chapter slot. The target number is the number of evidence types in the candidate evidence set that meet the requirements of the chapter slot. The target document is generated based on the chapter content of each chapter slot.

2. The method according to claim 1, characterized in that, After generating the target document based on the chapter content of each chapter slot, the method further includes: Extract new and / or change requirements from the document data, and identify target nodes affected by the new and / or change requirements from the evidence graph. A change impact analysis report is generated based on the target node, the new requirements, and / or the change requirements. The change impact analysis report and the target document are reverse-parsed to obtain multiple entities and the relationships between them. Reverse consistency verification is performed using the multiple entities, the relationships, and the evidence graph. The reverse consistency verification includes at least one of the following: entity existence verification, interface path verification, entity-corresponding relationship verification, business process closed-loop verification, constraint consistency verification, and scope of influence integrity verification. If the reverse consistency check passes, the target document is published. If the reverse consistency check fails, a first prompt message is issued, wherein the first prompt message is used to indicate that the target document has evidence defects.

3. The method according to claim 1, characterized in that, Generating multiple evidence units based on the document data includes: If the document data contains a code directory, extract the code elements of the code directory, wherein the code elements include at least one of the following: directory structure, module name, interface path, function name, configuration item, and database access statement; If the document data includes historical documents or knowledge documents, extract semantic elements from the historical documents or knowledge documents, wherein the semantic elements include at least one of the following: chapter title, entity name, business process, boundary conditions, term definition, and rule description; When the document data contains new requirements, extract the requirement intent elements from the new requirements, wherein the requirement intent elements include at least one of the following: target function, change point, constraints, scope of impact, and expected output; The code element, or the semantic element, or the demand intent element is identified as the entity of the evidence unit; The relevant information of the entity is obtained from the document data, and the evidence unit is generated based on the entity and the relevant information of the entity. The relevant information includes at least one of the following: evidence identifier, source type, source path, source location, entity category, entity name, content summary, time information and credibility index value.

4. The method according to claim 3, characterized in that, Constructing an evidence map based on the multiple evidence units includes: The association relationship is determined based on the relevant information of the multiple evidence units, wherein the association relationship includes at least one of the following: code call relationship, document reference relationship, interface and implementation relationship, entity naming correspondence relationship, directory proximity relationship, semantic similarity relationship, version relationship, conflict relationship, and supplementary relationship; Construct nodes corresponding to the evidence units, and connect edges between nodes corresponding to evidence units that have the associated relationship; The evidence graph is constructed based on the nodes and edges.

5. The method according to claim 1, characterized in that, The candidate evidence set for each chapter slot selected from the evidence map includes: Obtain the configuration information for each chapter slot, wherein the configuration information includes at least one of the following: slot name, slot order, required evidence type set, optional evidence type set, minimum evidence coverage, evidence conflict adjudication rules, output structure requirements, and prohibited output items; The candidate index values ​​of the evidence unit are determined based on the degree of correlation between the chapter slot and the evidence unit; The candidate evidence set is selected from the evidence graph based on the configuration information and the candidate indicator values.

6. The method according to claim 5, characterized in that, The candidate evidence set is selected from the evidence graph based on the configuration information and the candidate indicator values, including: Determine the set of evidence units corresponding to the evidence graph, and remove the evidence units from the set of evidence units that do not match the entity category and are prohibited from output, to obtain the updated set of evidence units; The evidence units whose candidate index values ​​are less than the index value threshold are removed from the updated set of evidence units to obtain the set of pending evidence. Determine whether the evidence units in the set of pending evidence cover the set of required evidence types; If the evidence units in the set of pending evidence do not cover the set of required evidence types, a second prompt message is issued, wherein the second prompt message is used to indicate insufficient evidence; If the evidence units in the set of pending evidence cover the set of required evidence types, the set of pending evidence will be determined as the set of candidate evidence.

7. The method according to claim 5, characterized in that, The candidate index values ​​for the evidence unit are determined based on the correlation between the chapter slot and the evidence unit, including: The relevance index value between the chapter slot and the evidence unit is determined, wherein the relevance index value includes at least one of the following: semantic relevance, structural relevance, source credibility, time freshness, and multi-source corroboration. The candidate index value is determined based on the relevance index value of each type and the corresponding preset weight.

8. The method according to claim 1, characterized in that, After determining the evidence coverage of the chapter slot based on the candidate evidence set, the method further includes: If the evidence coverage is greater than or equal to the second coverage threshold and less than or equal to the first coverage threshold, a third prompt message is issued, wherein the third prompt message is used to indicate that the chapter content of the chapter slot needs to be verified; If the evidence coverage is less than the second coverage threshold, a fourth prompt message is issued, wherein the fourth prompt message is used to indicate that the chapter slot needs to be supplemented with evidence.

9. A system document generation apparatus, characterized in that, include: A receiving unit is used to receive input document data and a target template, and generate multiple evidence units based on the document data, wherein the evidence unit is a reference information object parsed from the document data; A construction unit is used to construct an evidence graph based on the plurality of evidence units, wherein the evidence graph contains multiple nodes and multiple edges, the nodes are used to represent the evidence units, and the edges between the nodes are used to represent the association relationship between the evidence units corresponding to the nodes; A splitting unit is used to split the target template into multiple chapter slots and filter out a set of candidate evidence for each chapter slot from the evidence graph. The chapter slot is a structured unit split from the target template according to semantic logic, and the candidate evidence units in the set of candidate evidence are used to generate the document content of the chapter slot. The first determining unit is configured to determine the evidence coverage rate of the chapter slot based on the candidate evidence set, and generate chapter content of the chapter slot based on the candidate evidence set if the evidence coverage rate is greater than or equal to a first coverage threshold. The evidence coverage rate is the ratio of the target number to the total number of evidence types required by the chapter slot, and the target number is the number of evidence types in the candidate evidence set that meet the requirements of the chapter slot. A generation unit is used to generate a target document based on the chapter content of each chapter slot.

10. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the system document generation method according to any one of claims 1 to 8.

Images