An emergency plan generation method, device and system based on a large language model

Abstract

The application belongs to the technical field of emergency plan generation, and relates to an emergency plan generation method, device and system based on a large language model. The method comprises the following steps: obtaining a natural language description of user input; clarifying the requirements of the user input to obtain structured input meeting preset information density requirements; generating prompt words according to the structured input; obtaining a regulation file library and an emergency case library, wherein the regulation file library stores laws, regulations and normative documents, and the emergency case library stores full texts of emergency plans and historical disposal cases; generating independent regulation indexes and case indexes by using a search engine according to the regulation file library and the emergency case library; using a large language model to take the prompt words as input, and respectively searching according to the regulation indexes and the case indexes to obtain regulation search results and case search results; and generating an emergency plan according to the regulation search results and the case search results. The application can dynamically generate an emergency plan.

Description

Technical Field

[0001] This application relates to the field of emergency response plan generation technology, and in particular to an emergency response plan generation method, apparatus and system based on a large language model. Background Technology

[0002] With the increasing frequency of emergencies and the continuous expansion of their consequences, emergency management capabilities have become one of the core issues in the modernization of the national governance system. Various emergencies, such as natural disasters, industrial accidents, and public health incidents, are showing a significant upward trend in terms of frequency, scope of impact, and complexity of handling. Traditional emergency response models relying on manual assessment are facing severe challenges. AI-assisted emergency response systems that integrate IoT sensing, machine learning, and multi-source data fusion can significantly improve the accuracy of disaster prediction and the efficiency of emergency resource allocation.

[0003] Emergency response plans, as the core institutional tool of the emergency management system, play a crucial role in standardizing handling procedures, clarifying response responsibilities, and guiding resource allocation. They serve as the core basis for handling emergencies.

[0004] In existing technologies, Large Language Models (LLMs) have made breakthrough progress in natural language understanding, instruction following, and complex text generation, and there are already solutions for deploying Large Language Models in emergency response plan generation scenarios.

[0005] However, the above solution faces two independent bottlenecks: First, the emergency response plan knowledge system itself has the characteristics of dynamic evolution. The revision of laws and standards, the accumulation of new events, and the iteration of handling experience all require the knowledge base to be continuously updated. However, the existing emergency response plans are mostly static text archives with static knowledge structures with parameterized models. They are difficult to quickly customize and generate according to specific scenarios, have insufficient scenario adaptability, and cannot meet the needs of incremental learning. Secondly, although large language models have the ability to generate structured text, there is a significant discrepancy between the knowledge they store and the professional knowledge of the specific field of emergency response. The model has a high rate of illusion in professional domain issues, making it difficult to guarantee the compliance and operability of the generated solutions. It is prone to errors in key elements such as institutional responsibilities, response time limits, and regulatory references, and the cost of continuously updating model parameters after deployment is high. Summary of the Invention

[0006] Therefore, it is necessary to provide an emergency plan generation method, device, and system based on a large language model to address the aforementioned technical problems. This method can dynamically generate emergency plans and simultaneously improve the efficiency and accuracy of emergency plan generation.

[0007] An emergency response plan generation method based on a large language model includes: Obtain user input in natural language description; Clarify user input requirements to achieve progressive structuring of user input and obtain structured input that meets preset information density requirements; Based on structured input that meets preset information density requirements, generate prompt words; The system acquires a legal document repository and an emergency case repository. The legal document repository stores laws, regulations, and normative documents, while the emergency case repository stores the full text of emergency plans and historical handling cases. Based on the legal document repository and the emergency case repository, an independent legal index and a case index are generated using the Elasticsearch search engine. Using a large language model with prompt words as input, searches are performed based on the legal index and the case index respectively to obtain legal search results and case search results. Emergency response plans are generated based on the results of legal and case searches.

[0008] In one embodiment, after generating the emergency response plan, the following is also included: The generated emergency response plans are evaluated, and when they meet the preset requirements, they are written into the emergency case database to dynamically update the database, forming a self-growing closed loop of generation and retrieval.

[0009] In one embodiment, the generated emergency response plan is written into the emergency case library, including: Based on JSON structured parsing and text cleaning strategies, the core elements of the generated emergency response plan are extracted. An incremental write mechanism for Elasticsearch is adopted to write the core elements of the generated emergency plan into the emergency case library.

[0010] In one embodiment, user input is clarified to achieve progressive structuring of the user input, resulting in structured input that meets preset information density requirements, including: When user input is underdefined in terms of applicable subject, response level, or geographical scope, multiple rounds of structured question-and-answer sessions are conducted to clarify user needs, confirm intent, and complete information, thereby achieving progressive structuring of user input and obtaining structured input that meets preset information density requirements.

[0011] In one embodiment, an emergency response plan is generated based on regulatory and case search results, including: Based on the results of regulatory and case searches, a multi-agent collaborative generation framework is adopted. The regulatory search results provide a chain of evidence for the compliance of the provisions, and the case search results provide a framework for the contingency plan structure and a reference for handling, thereby generating an emergency plan.

[0012] In one embodiment, the multi-agent collaborative generation framework includes: a clarifying agent, a supervisory agent, a research agent, a compressing agent, and a generating agent; The clarifying agent is used to obtain user input described in natural language, clarify the user input requirements, and achieve progressive structuring of the user input to obtain structured input that meets the preset information density requirements. The supervisory agent is used to concurrently delegate to multiple research agent instances, each instance independently completing a retrieval task for a subtopic; The research agent is used to employ a large language model, taking prompt words as input, and to retrieve legal and case search results based on the legal index and case search index respectively. The compressed agent is used to condense the retrieval results of the research agent and report them to the regulatory agent; The generated intelligent agent is used to generate emergency plans based on the results of regulatory and case searches.

[0013] In one embodiment, the regulatory index and the case index are configured with different word segmentation strategies and retrieval weights, respectively.

[0014] In one embodiment, the regulatory index uses a standard analyzer to maintain the retrieval stability of precise terms such as regulatory numbers; The case index uses an IK dual-mode segmenter to ensure retrieval accuracy for terminology-intensive case texts.

[0015] An emergency response plan generation device based on a large language model, employing an emergency response plan generation method based on a large language model, includes: The first module is used to obtain user input in natural language description; The second module is used to clarify the user input requirements in order to achieve progressive structuring of the user input and obtain structured input that meets the preset information density requirements. The third module is used to generate prompt words based on structured input that meets preset information density requirements; The fourth module is used to obtain a legal document library and an emergency case library. The legal document library stores laws, regulations, and normative documents, while the emergency case library stores the full text of emergency plans and historical handling cases. Based on the legal document library and the emergency case library, an independent legal index and case index are generated using the Elasticsearch search engine. Using a large language model, with prompt words as input, searches are performed based on the legal index and case index respectively to obtain legal search results and case search results. The fifth module is used to generate emergency response plans based on the results of legal and case searches.

[0016] An emergency response plan generation system based on a large language model is provided, which employs an emergency response plan generation device based on a large language model, including: an input layer, a processing layer, and a data layer. The input layer includes: a first module, an input interface, and an output interface; The processing layer includes: a second module, a third module, a fourth module, and a fifth module; The data layer includes: a regulatory document library, an emergency case library, and a requirement clarification record; The first, second, third, fourth, and fifth modules are connected in sequence. The input interface is connected to the first module, the output interface is connected to the fifth module, the legal document library and the emergency case library are both connected to the fourth module, and the requirement clarification record is connected to the second module.

[0017] The aforementioned emergency response plan generation method, device, and system based on a large language model, combining "retrieval-enhanced plan generation" and "incremental learning based on external knowledge base updates," generates structured emergency response plans with logical coherence, element completeness, and scenario relevance. This eliminates semantic ambiguity at the input end, constrains illusions at the generation end, and maintains domain compliance at the knowledge end, ensuring that the generated emergency response plans simultaneously guarantee factual reliability, domain compliance, and logical coherence. Regarding retrieval-enhanced generation, case knowledge and regulatory knowledge are stored in semantically clear case and regulatory indexes respectively, according to document semantic type (the knowledge structure characteristics of the emergency response plan generation task). Accurate external knowledge is injected into the plan generation process through a multi-agent collaborative generation framework and a multi-turn human-computer dialogue mechanism. For continuous knowledge updates, an incremental update mechanism is designed to automatically extract plan elements and write them into the index, enabling high-quality generated plans to continuously enrich the knowledge base without retraining the model, forming a self-growing closed loop of generation and retrieval. Attached Figure Description

[0018] Figure 1 This is a flowchart illustrating an emergency response plan generation method based on a large language model in one embodiment. Figure 2 This is a multi-round clarification overall design logic diagram for one embodiment; Figure 3 This is a role relationship diagram of a multi-agent collaborative generation framework in one embodiment. Figure 4 This is a schematic diagram of a framework for evaluating an emergency response plan in one embodiment; Figure 5 This is a flowchart illustrating the mechanism for updating an external knowledge base in one embodiment. Figure 6 Here is a seven-dimensional distribution diagram of Q in a specific embodiment; Figure 7Here is a five-dimensional distribution diagram of RAG benefits in a specific embodiment; Figure 8 This is a composite score chart of four evaluation frameworks in a specific embodiment. Detailed Implementation

[0019] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application. All other embodiments obtained by those skilled in the art based on the embodiments in this application without inventive effort are within the scope of protection of this application.

[0020] Furthermore, the use of terms such as "first" and "second" in this application is for descriptive purposes only and should not be construed as indicating or implying their relative importance or implicitly specifying the number of technical features indicated. Therefore, a feature defined as "first" or "second" may explicitly or implicitly include at least one of those features. In the description of this application, "multiple sets" means at least two sets, such as two sets, three sets, etc., unless otherwise explicitly specified.

[0021] In this application, unless otherwise expressly specified and limited, the terms "connection," "fixed," etc., should be interpreted broadly. For example, "fixed" can mean a fixed connection, a detachable connection, or an integral part; it can mean a mechanical connection, an electrical connection, a physical connection, or a wireless communication connection; it can mean a direct connection or an indirect connection through an intermediate medium; it can mean the internal communication of two elements or the interaction between two elements, unless otherwise expressly limited. Those skilled in the art can understand the specific meaning of the above terms in this application according to the specific circumstances.

[0022] Furthermore, the technical solutions of the various embodiments of this application can be combined with each other, but only if they are based on the ability of those skilled in the art to implement them. When the combination of technical solutions is contradictory or cannot be implemented, it should be considered that such combination of technical solutions does not exist and is not within the scope of protection claimed by this application.

[0023] This application provides a method for generating emergency response plans based on a large language model, such as... Figure 1 As shown, in one embodiment, it includes: Step 101: Obtain user input in natural language description.

[0024] In this step, obtaining user input in natural language description is a matter of existing technology.

[0025] Step 102: Clarify the user input requirements to achieve progressive structuring of the user input and obtain structured input that meets the preset information density requirements.

[0026] Specifically: When user input is underdefined in terms of applicable subject, response level, or geographic scope, multiple rounds of structured question-and-answer sessions are conducted on the user input (each question-and-answer session only allows one aspect of the question to be asked, and does not ask questions in the form of a numbered list to reduce the user's cognitive load and improve the accuracy of the answer) in order to clarify the user's needs, confirm the intent, and complete the information. By employing a Large Language Model (LLM), the clarified user input is transformed from natural language intent into structured research instructions, achieving progressive structuring of the clarified user input to obtain structured input that meets the preset information density requirements while ensuring parsability.

[0027] In this step, the requirement clarification provides sufficiently precise semantic constraints to handle the diversity of natural language descriptions, avoids the problems of scattered ES search results and inaccurate semantic anchoring of research_brief, converges the semantic uncertainty at the input end, and improves the recall accuracy of ES search.

[0028] like Figure 2 The diagram shows the overall design logic of the multi-round clarification mode. The two modes differ fundamentally in their input transformation paths. The immediate generation mode directly generates a `research_brief` from the user's original description, with search keywords derived from the model's self-completion of the verbal expression; accuracy relies on the model's parameterized knowledge. The multi-round clarification mode gradually confirms key elements such as the applicable subject, event level, and geographical scope through structured question-and-answer sessions. The constraint information in the `research_brief` is more precise, thus improving the recall accuracy of the Elasticsearch search. The counting of clarification rounds does not depend on the `AgentState.clarification_round` field, which is reset to 0 with each API call and cannot accumulate across sessions. Therefore, the system dynamically infers from the structural patterns of the message history: iterating through the message list, when it detects that "an AI non-tool call message is immediately followed by a Human reply, and the AI ​​message content does not contain confirmation keywords," it is counted as a valid clarification match. This criterion can be reconstructed at any session recovery point and does not depend on the completeness of the state serialization. After reaching the MAX_CLARIFY_TURNS round, the node is forced to route to write_research_brief to prevent the system from getting stuck in infinite follow-up questions; if the user actively replies with confirmation keywords in any round, the node will also exit early. These two exit paths together ensure that the interaction process is completed within bounded time.

[0029] Step 103: Generate prompt words based on the structured input that meets the preset information density requirements.

[0030] Specifically: Based on structured input that meets the preset information density requirements, prompt words are generated and used as semantic anchors for ES search keyword construction and content generation.

[0031] In this step, the core of the prompt is a "binding layer" that binds {structured input + retrieval results} to {generative behavior of the large model} (i.e., constraining how the agent constructs the ES retrieval expression and limiting the content constrained by the two-way knowledge in the generation process). It is first generated in the briefing generation node and repeatedly instantiated in each agent node as the state accumulates.

[0032] Generate prompt words, which means filling in several placeholders in the pre-set prompt word templates for different generation stages (in the code, these are lead_researcher_prompt, research_system_prompt, final_report_generation_prompt, etc. in prompts.py). The content to be filled in includes: the runtime status of the flow graph and the control content of the double-indexed fixed domain.

[0033] Step 104: Obtain the regulatory document repository and the emergency case repository. The regulatory document repository stores laws, regulations, and normative documents, while the emergency case repository stores the full text of emergency plans and historical handling cases. Based on the regulatory document repository and the emergency case repository, use the Elasticsearch search engine to generate independent regulatory indexes and case indexes. Using a large language model, with prompt words as input, perform searches based on the regulatory index and case index respectively to obtain regulatory search results and case search results.

[0034] Specifically: Access the legal document library and the emergency case library. The legal document library stores laws, regulations and normative documents, while the emergency case library stores the full text of emergency plans and historical handling cases. The two types of documents are fundamentally different in terms of content nature, information granularity and purpose. Based on the regulatory document repository and emergency case repository, an independent regulatory index and case index are generated using the Elasticsearch search engine; The regulatory index and case index are configured with different word segmentation strategies and retrieval weights to ensure that each type of knowledge achieves appropriate retrieval accuracy. The regulatory index uses the standard analyzer to reduce interference from the segmentation of regulatory numbers and proper abbreviations and to maintain the retrieval matching stability of precise terms such as regulatory numbers (specifically, the field structure of the regulatory index is the same as that of the case index, and the dynamic: strict constraint prevents any undeclared fields from being written, ensuring the stability of the index schema). The case index uses the IK dual-mode word segmenter (ik_max_word during indexing and ik_smart during querying) to ensure retrieval accuracy for terminology-intensive draft texts (specifically, the case index can be set to 6 primary shards and 1 replica shard, with refresh_interval set to 30 seconds, so that new documents can be retrieved within 30 seconds after being written, providing timeliness assurance for subsequent incremental writing mechanisms). Using a large language model and prompt words as input, the system performs searches based on both the regulatory index and the case index, resulting in regulatory search results and case search results with different semantic tags.

[0035] In this step, a dual-index retrieval architecture is constructed based on document semantic types. Elasticsearch is used as the retrieval platform, LLM is used as the generation engine, and RAG is used as the main architectural backbone connecting LLM generation capabilities with external domain knowledge for retrieval.

[0036] The two indexes have clear semantic boundaries and isomorphic field structures, both containing five fields: id, title, content, level, and validity. The level field carries different semantics in the two indexes: in the regulatory index, it takes the values ​​"country" and "location," supporting hierarchical filtering during the retrieval phase; in the case index, it takes the province name, supporting region-weighted recall. The validity field is an integer field, taking values ​​of 0 or 1, assigned by the validity filtering process before data insertion. Entries with validity=0 are still written to the index but do not participate in normal retrieval sorting, and are only used for data review. Both indexes have dynamic set to strict to prevent any undeclared fields from being written, ensuring schema consistency during the three-level gradient scaling experiment and eliminating interference from index structure differences on retrieval results.

[0037] Dual indexes coexist in Elasticsearch and can be called in parallel or sequentially, which limits the boundaries of generated knowledge, ensures the accuracy of the retrieval target and the controllability of the retrieval result injection method, and has stronger adaptability to professional texts such as emergency plans that are both terminologically dense and semantically complex, thus solving the problem of insufficient semantic coverage of emergency plan texts by existing retrieval indexes.

[0038] RAG does not exist as an independent service, but rather dynamically reshapes the entire multi-agent collaborative topology through a unified integer configuration parameter `rag_mode`. Unlike clarification mechanisms, which converge on the semantic uncertainty of the input, RAG retrieval converges on the knowledge source of the generated content. `rag_mode` takes values ​​of 1, 2, and 3, corresponding to three operating modes: no RAG, single index, and dual index (using both case and regulatory libraries). This design allows the same LangGraph structure to serve as both a controlled baseline for ablation experiments and an experimental group, without modifying any node logic, providing structurally reliable control conditions for quantitative analysis. RAG's intervention is not a single-point "retrieval and splicing" operation, but rather an explicit binding of agent behavior at three levels: the Prompt layer, the tool layer, and the query layer. (The Prompt layer is the dynamic injection of cognitive premises; the tool layer is the explicit switch for retrieval capabilities; and the query layer is the semantically oriented injection of retrieval results. The specific Prompt layer, tool layer, and query layer belong to existing technologies.) These three layers jointly define the knowledge boundaries that the agent can acquire when generating plans and determine its response method when facing knowledge gaps. In other words, RAG decouples and co-orchestrates Prompt instructions, tool calls, and query planning through engineering design.

[0039] By using different semantic tags, we can clarify the digestion methods of the two types of retrieval results, prevent the intelligent agent model from mixing case texts with legal provisions, ensure the functional division of case knowledge for building chapter frameworks and legal knowledge for filling compliance basis, and ensure that LLM can direct the two types of knowledge to different generation tasks.

[0040] It should be noted that the regulatory document repository, emergency case repository, Elasticsearch search engine, standard analyzer, IK dual-mode tokenizer, and large language model are all existing technologies and will not be elaborated upon here.

[0041] Step 105: Generate an emergency response plan based on the results of the legal and case searches.

[0042] Specifically: Based on the results of regulatory and case searches, a multi-agent collaborative generation framework is adopted. The regulatory search results provide a chain of evidence for the compliance of the provisions, and the case search results provide a framework for the contingency plan and a reference for handling, thereby generating an emergency plan.

[0043] The multi-agent collaborative generation framework utilizes the LangGraph directed graph framework. It orchestrates the collaborative division of labor between supervisory and research agents using LangGraph, decomposing the complex generation process into traceable explicit reasoning trajectories. LangGraph is an agent workflow orchestration framework built on the LangChain ecosystem. Using a directed graph as the formal representation of the workflow, it decouples agent collaboration logic from specific LLM calls, supporting the construction of complex execution topologies containing branches, loops, and conditional jumps. In the LangGraph programming model, a node corresponds to an executable unit, which can be an LLM call, a tool call, or any Python function; edges define the state transition relationships between nodes, divided into unconditional edges (sequential execution) and conditional edges (dynamic routing based on state values); and the state is a structured dictionary shared and passed among all nodes. Each node reads its current state, updates it, and passes it to downstream nodes. This design makes the information flow in the multi-agent system completely explicit, avoiding the problems of black-box chained calls that are difficult to trace and debug. LangGraph natively supports cyclic graphs: conditional edges can direct control flow to any visited node in the graph, enabling a feedback loop of generation, evaluation, and correction. This satisfies business logic that requires re-retrieval or modification when the quality of emergency solutions fails to meet standards. LangGraph's built-in breakpoint and streaming mechanisms also allow for human intervention and review at critical nodes, meeting the basic requirements of human-machine collaboration in emergency decision-making scenarios.

[0044] Based on the LangGraph directed graph framework, the emergency response plan generation process is mapped as a three-layer collaborative topology consisting of a main graph and two nested subgraphs. The main graph defines the global execution sequence, the supervisory subgraph carries the iterative scheduling of the research phase, and the researcher subgraph is responsible for in-depth retrieval and information extraction on a single topic. The three layers are logically isolated from each other. The subgraphs are embedded in the main graph nodes as compiled objects, and their internal states are not exposed. The layers exchange data through a shared AgentState object, and the Command object is used to complete the state update and routing jump between nodes.

[0045] The main graph is compiled by PlanGenerationBuilder and registers four nodes in sequence: requirement clarification, briefing generation, regulatory research and contingency plan generation. The execution order is constrained by directed edges, and finally a callable graph object is generated by graph.compile(). (1) The requirement clarification node (clarify_with_user) is the first gate for user input to enter the system. Its core behavior is controlled by the clarify_mode parameter. When the value is 1, the node skips all clarification logic and directly routes to the briefing generation node. When the value is 2, the node calls LLM to evaluate the completeness of the current information. If the judgment is insufficient, it asks the user for follow-up questions. It will only be allowed after the information is sufficient or the round limit is reached. The clarification round is dynamically estimated by the number of "AI message-user reply" pairings in the statistical message history. It does not rely on state variables that are easily invalidated due to session reconstruction. At the structured output level, the node implements a three-level JSON parsing fallback mechanism, trying function call mode, JSON mode and regular expression extraction mode in sequence to ensure the stability of cross-model output. (2) The briefing generation node (write_research_brief) undertakes the task of converting natural language intent into structured research instructions. The node takes the complete dialogue history as input, and outputs the structured research_brief field after LLM refinement. Then, it injects this field along with the six placeholder contents returned by get_rag_prompt_sections(rag_mode) into the supervisory agent system prompt words, and initializes supervisor_messages in override mode to establish a cognitive starting point for the supervisory subgraph without historical noise. (3) The plan generation node (final_report_generation) takes over the control flow after the supervisory subgraph exits. The node takes research_brief, dialogue history and notes accumulated in the research stage as input, and constructs complete prompt words by combining the three report-specific fields injected by get_rag_prompt_sections(rag_mode). It calls the generation model to output the plan text (max_tokens is set to 65536). The node has a built-in token over-limit retry mechanism: when the limit is exceeded for the first time, the initial truncation length is estimated based on the model capacity. In each subsequent round, it is reduced by 10% on this basis, and retried up to 3 times to ensure that a valid plan text can still be output when the research results are too long.

[0046] The supervisory subgraph consists of two nodes, `supervisor` and `supervisor_tools`, forming an iterative closed loop. The maximum number of iterations is constrained by `max_researcher_iterations`. The `supervisor` node is the decision-making center for the research phase. In the ReAct paradigm, it passes the current `supervisor_messages` to the LLM bound to the tool list. The tool list is dynamically configured according to `rag_mode`, and `es_search` is added in RAG mode. Each round of the LLM outputs tool call decisions: `think_tool` is used for policy reasoning and leaves a traceable reflection record; `ConductResearch` concurrently delegates subtasks to the researcher subgraph, with the concurrency controlled by `max_concurrent_research_units`; `es_search` performs direct retrieval at the supervisory layer, and the results are injected into the context after semantic labeling; the `ResearchComplete` trigger phase exits. Simultaneously, the node has a built-in context window protection mechanism. When the estimated number of tokens exceeds the model's safety threshold, it automatically truncates from the oldest `ToolMessage` to retain recent research results. The `supervisor_tools` node is responsible for the actual execution of tool calls and subsequent routing. The node first checks three termination conditions: the iteration rounds exceed the limit, the recent messages do not contain tool calls, and ResearchComplete has already been called. If any condition is met, the node exits the supervision phase; otherwise, it executes all tool calls concurrently, imports the results into supervisor_messages in the form of ToolMessage, and then routes them back to the supervisor node to start the next iteration.

[0047] The researcher subgraph consists of three nodes connected in series: researcher, researcher_tools, and compress_research. The researcher node takes a research_topic as input and, under the ReAct paradigm, invokes the LLM using system prompts injected by get_rag_prompt_sections(rag_mode), generating a tool invocation sequence. Available toolsets are dynamically loaded at runtime by get_all_tools(config). The researcher_tools node executes all tool invocations concurrently and then checks the validity of the results: if the search results are all empty and the iteration count has not exceeded the limit, a retry is triggered and keyword adjustments are injected; if the results are valid or have exceeded the limit, the route is routed to the compress node. The compress_research node invokes an independent compression model, condensing all researcher_messages into a compressed_research summary field, and writes it along with the raw notes into the ResearcherOutputState, which is then returned to the upper-level supervisor_tools node for collection.

[0048] In this step, a multi-agent collaborative generation framework is used throughout the entire method, including: a clarifying agent, a supervisory agent, a research agent, a compression agent, and a generating agent. Based on a LangGraph-based multi-agent collaborative orchestration scheme, the task is decomposed into sub-tasks such as task planning, multi-source retrieval, content generation, and quality assessment. Different sub-tasks are undertaken by different agents and uniformly scheduled by a central coordinator. This role division ensures that each agent only processes its corresponding sub-task within its own capability boundaries. This mechanism keeps the inference load and context length of each agent within a controllable range, thereby improving the overall system's controllability and maintainability, and solving the logical consistency defects of existing multi-agent architectures in the generation of structured long texts. Figure 3 As shown, all agents exchange state information through a shared AgentState object. Solid lines in the figure represent active delegation and result reporting, while dashed lines represent read and write operations on the shared state.

[0049] The clarifying agent forms a closed-loop dialogue with the user and is responsible for confirming intent and completing information. Specifically, the clarifying agent is used to obtain user input described in natural language, clarify the user input requirements, and achieve progressive structuring of user input to obtain structured input that meets the preset information density requirements. The regulatory agent concurrently delegates research tasks to multiple research agent instances through Conduct Research, with each instance independently completing a retrieval task for a subtopic. The research focuses on using a large language model, taking prompt words as input, to retrieve legal and case search results based on both the legal and case search indices. The compressed agent is used to condense the search results of the research agent and report them to the regulatory agent using the compressed_research field. The generated intelligent agent is used to summarize all search fields and generate structured emergency response plans based on the results of legal and case searches.

[0050] It should be noted that LangGraph is a directed graph framework, which is existing technology and will not be elaborated on here.

[0051] In another embodiment, after generating the emergency plan, the method further includes: evaluating the generated emergency plan; and when the preset requirements are met, writing the core elements of the generated emergency plan into the emergency case library to dynamically update the emergency case library, forming a self-growing closed loop of generation and retrieval.

[0052] Specifically: After generating the emergency response plan, the generated emergency response plan is evaluated (e.g., Figure 4 As shown, only the scheme quality assessment indicators and RAG benefit assessment indicators are displayed; multi-round clarification assessment indicators are not displayed. When the plan quality assessment indicators, RAG benefit assessment indicators, and multi-round clarification assessment indicators all meet the preset requirements, the core elements of the generated emergency plan are extracted based on JSON structured parsing and text cleaning strategies. An incremental write mechanism for Elasticsearch is adopted to write the core elements of the generated emergency plan into the emergency case library, so as to dynamically update the emergency case library and form a self-growing closed loop of generation and retrieval.

[0053] The automatic extraction process is based on JSON structured parsing. The core of the extraction process is to construct a Prompt with field constraints, which guides the LLM to map unstructured pre-planned text into structured JSON objects. A three-level Prompt engineering system drives the LLM to complete entity and relation extraction. Its core design principles are: field definition before examples, constraints declared in enumeration form, and failure fallback paths explicitly declared. The organization name suffix rules are consistent with the construction logic of the organization noun pool in the ES retrieval mechanism, ensuring that the organization names identified in the extraction stage are correctly recalled in the retrieval stage, and avoiding systematic missed matches of high-frequency organization names. The JSON string output by LLM is first validated using syntax (Python json.loads and pydantic field type checks). Samples with invalid syntax are retried a second time, up to a maximum of two retries. Samples that still fail are downgraded to regular expression extraction: the two key fields event_type and response_level are retained first, and the rest are set to null. The entry can still be added to the database, but the validity flag is reduced to 0. The design intention of the downgrade path is "retrieval availability takes precedence over field integrity": in the small to medium KB range of 7 to 70, retaining low-quality samples is more conducive to maintaining recall diversity than discarding them directly.

[0054] The design incorporates a structured Prompt that includes element definitions and output format constraints, ensuring the integrity and logical order of the generated solution. Specifically, a dynamic Prompt assembly mechanism and a structured output constraint layer are adopted, and both are uniformly deployed in three core nodes: lead_researcher_prompt, research_system_prompt, and final_report_generation_prompt, forming a three-level Prompt engineering system. This is existing technology and will not be elaborated further here.

[0055] The text cleaning strategy includes: Unicode cleaning and encoding standardization, and validity filtering rules. Unicode cleaning and encoding standardization include: mapping full-width whitespace and tabs (U+3000, U+2000–U+200A, U+00A0) to half-width spaces; directly deleting zero-width characters (U+200B–U+200F, U+FEFF); and compressing consecutive repeated spaces into single spaces using regular expressions. The complete cleaning logic is encapsulated in Python functions and used as a unified preprocessing hook before database entry, called by all extraction processes. Validity filtering rules include: retaining the validity field in the ES index; reducing the weight of entries marked with 0 during the sorting stage and excluding them from normal retrieval; assigning the validity field value using a four-tiered heuristic criterion cascade, setting it to 0 if any criterion fails.

[0056] The core elements of the emergency response plan serve as semantic anchors for retrieval, including the following structured fields: (1) Event type and response level fields: The event_type field stores the major categories of emergencies to which the plan applies, and the value range is limited to the four major categories and their 35 subcategories; the response_level field records the number of response levels preset in the plan, and the value is 2, 3, 4 or 5, reflecting the grading granularity of the plan; Level 4 response is the mainstream grading design of China's emergency plans, and some special plans adopt Level 3 or Level 5; these two fields act as hard filtering conditions in the retrieval stage: given the constraint of "municipal special / Level 4 response", the index can exclude more than 90% of irrelevant entries before recall, which significantly improves the retrieval accuracy; (2) Command System and Institutional Responsibilities: The command_system field stores the command institutions explicitly named in the plan in a list form, including the emergency command headquarters, office and various professional working groups; the agencies field is a set of institution names extracted from the full text of the plan, identified according to regular boundary rules. The institution names must end with one of the suffixes "Bureau / Department / Commission / Ministry / Office / Center / General Team / Brigade"; the quality of institution name extraction is directly related to the reliability of the calculation of the C1 dimension in the IL evaluation system, because C1 depends on the dynamic density of institution names in the ES word pool, and the word pool density is determined by the cumulative frequency of occurrence of each institution name in the case library. Institution names that are missed in the extraction are not visible in the word pool, which will systematically lower the C1 score; (3) Handling process and time limit fields: The response_steps field stores the handling sequence with the skeleton nodes of receiving the report, evaluation, initiation, handling, and termination. Each step is recorded as a triple of "action + subject + time limit". The time_limits field is a flattened extraction of all time limit specifications in the handling process, such as "verbal report within 30 minutes after receiving the report". These two fields are the most concentrated sources of RAG incremental benefits: LLM's parameterized knowledge tends to output vague descriptions such as "report in time" and "handle as soon as possible", while the precise time limit specifications in the local plan are exactly in the long-tail missing area of ​​the parameter space, which can only be injected through external retrieval.

[0057] The incremental write mechanism includes: calling the `write_scheme_to_es_if_qualified` function to perform the write operation. The first step is to establish an Elasticsearch connection and verify that the target index case exists. If the index does not exist or the Elasticsearch service is unreachable, the process is aborted and an error is logged, without affecting the main workflow status.

[0058] The second step involves calling the `get_max_keyword_id` function to query the maximum value of the `id` field in the current index, and then incrementing that value by one to obtain the ID of the new document. The ID is stored as a `keyword` type. `get_max_keyword_id` aggregates values ​​from terms, sorts them lexicographically in descending order, retrieves the value from the first bucket, and then converts it to an integer and increments it. This mechanism ensures the global monotonicity of the ID during concurrent writes.

[0059] The third step is to construct and write the document. The field structure is completely isomorphic to the legal and case indexes: id is the newly assigned integer ID, title is the name of the generated plan, content is the complete text of the generated plan, level is assigned the default value "general" (which can be overridden by the regional value inferred from the query context later), and validity is always 1, indicating that the entry has passed quality gating and can participate in normal retrieval and sorting.

[0060] The fourth step is to call `es.index(index=ES_INDEX_CASES_NAME, body=doc, id=str(next_id))` to perform the write operation. Elasticsearch's index API is an atomic operation: documents are immediately visible to subsequent search requests after being written, without the need to manually refresh the index (the default refresh interval for ES 7.x and above is 1 second, which can be configured to refresh immediately in an experimental environment).

[0061] The three engineering properties and mechanism design promises of write operations directly correspond to: immediate effect, new entries can be retrieved immediately after the es.index call is completed, without the need to rebuild the index; independent operation, new documents are written with independent IDs, without affecting any existing entries' fields and scores; scale-independent, the API call format for single and batch writes is consistent, and the latency is only linearly related to the document size, and is independent of the total index size.

[0062] like Figure 5 As shown, the external knowledge base update mechanism consists of three interconnected stages: quality gating, incremental writing, and closed-loop verification. All three are triggered asynchronously after the main process is completed, having no impact on user-side response latency. The external knowledge base update mechanism is designed with "generation closed loop" as its core principle: high-quality generation plans are not only the final output of the task but also constitute a knowledge source usable for the next round of retrieval.

[0063] Evaluating the generated contingency plans can prevent the retrieval pool from continuously introducing low-quality samples with each generation call, thus avoiding a gradual decline in the A1 recall rate and C2 program detail density metrics, thereby improving the accuracy of incremental learning.

[0064] By structurally defining the core elements of emergency response plans, the semantic boundaries of fields such as event type, response level, command system, handling procedures, and time limits can be clearly defined. Furthermore, a method for automatic element extraction based on JSON structured parsing, combined with text cleaning and validity filtering strategies, transforms the unstructured original text of the plan into structured entries that can be indexed by search engines. This establishes a semantically matching correspondence between search requests (event scenario descriptions) and knowledge entries (plan element fields), aligning knowledge granularity with search granularity and improving the accuracy of search retrieval.

[0065] The write-back operation is executed within the Python asyncio coroutine _async_evaluate. This coroutine is scheduled immediately after the main process returns a response by asyncio.create_task and is not on the critical path of request and response. Its execution order is: V5 quality assessment → write-back eligibility determination → incremental writing → incremental learning evaluation. This execution order forms a self-growing closed loop with the knowledge base as the hub: high-quality generated plans are written back to the index, the index size increases, and the A1 recall rate and A2 regional hit rate of subsequent similar queries (how to calculate the A1 recall rate and A2 regional hit rate are all existing technologies) improve accordingly, the generation quality is improved, and new high-quality plans are written back again.

[0066] It should be noted that the quality assessment indicators, RAG benefit assessment indicators, multi-round clarification assessment indicators, and their corresponding calculation methods are all existing technologies and will not be elaborated here.

[0067] In a specific embodiment, the method of this application is simulated and verified with RAG_MODE=3 (dual index), CLARIFY_MODE=2 (multi-round clarification), KB=700 (complete knowledge base) as the configuration, and the disaster type input is "Changsha City Flood Control and Disaster Relief Emergency Plan". This configuration is the complete operating state in which the three technical lines of the system are activated at the same time, and it is also the parameter combination with the most full benefit of the method.

[0068] The evaluation indicator system includes: quality evaluation indicator Q, RAG benefit evaluation indicator, multi-round clarification evaluation indicator, and incremental learning evaluation indicator. The results are as follows: Figures 6 to 8 As shown.

[0069] The overall quality score generated this time is Q=90.37. Among the seven-dimensional indicators, ISI, RCP and QDD are all close to full marks, reflecting the direct contribution of retrieval injection to the specification of institution names and the accuracy of regulatory citations.

[0070] The overall RAG benefit score was 85.08, with RTD and LKA being the highest among the five dimensions. This reflects that the search results are fully cited and anchored to local legal basis, which is a concentrated manifestation of the localized knowledge injection of dual-index RAG.

[0071] The overall clarification benefit score was 79.20, with both IDG and ECR exceeding 80 points, confirming the effective coverage of the core constraint dimensions by the two rounds of clarification. In this case, only two rounds of clarification were actually performed before the user confirmed entry into the generation stage. The number of clarification rounds was far below the marginal utility saturation inflection point (around three rounds), indicating that when the user can clearly express the hierarchical positioning and the system can infer other scenario elements based on the pre-generated research brief, the multi-round clarification mechanism has the ability to adaptively exit early without imposing unnecessary cognitive load on the user.

[0072] The incremental learning score (IL_Score) was 56.81, with outstanding performance in A1 and C3 at a knowledge base size of 700 KB. The A2 dimension measures the contribution of the case index channel to the structural borrowing of similar plans; the absence of case sources in this recall directly limited the score for this dimension. Under the condition of missing cases, the system instead completed chapter organization through the regulatory index channel and horizontal migration of cross-regional regulations. The Q score and RAG benefit score remained excellent, reflecting the robustness of the dual-index architecture when single-channel recall is insufficient.

[0073] Based on the above four-dimensional assessment, this generation achieved the expected state of "the three main technical lines of the system working synergistically": the regulatory index channel of the dual-index RAG enabled the accurate injection of local provincial regulations and cross-regional regulations of the same type; multiple rounds of clarification completed the semantic constraints of hierarchical positioning with adaptive rounds; and the incremental knowledge base provided sufficient legal basis support at a scale of 700 entries. The Q score and RAG benefit score both reached excellent levels.

[0074] The aforementioned emergency response plan generation method based on a large language model combines "retrieval-enhanced plan generation" and "incremental learning based on external knowledge base updates" to generate structured emergency response plans with logical coherence, complete elements, and scenario relevance. It eliminates semantic ambiguity at the input end, constrains illusions at the generation end, and maintains domain compliance at the knowledge end, ensuring that the generated emergency response plans simultaneously guarantee factual reliability, domain compliance, and logical coherence. Regarding retrieval-enhanced generation, case knowledge and legal knowledge are stored in semantically clear case and legal indexes respectively, according to document semantic type (the knowledge structure characteristics of the emergency response plan generation task). Accurate external knowledge is injected into the plan generation process through a multi-agent collaborative generation framework and a multi-turn human-computer dialogue mechanism. For continuous knowledge updates, an incremental update mechanism is designed to automatically extract plan elements and write them into the index, enabling high-quality generated plans to continuously enrich the knowledge base without retraining the model, forming a self-growing closed loop between generation and retrieval.

[0075] Specifically: 1. In the direction of enhanced solution generation, a dual-index hybrid retrieval mechanism was designed to address the semantic heterogeneity of emergency plans. A solution generation framework was constructed with RAG as the skeleton, ES dual-index hybrid retrieval as the retrieval engine, and LangGraph multi-agent collaborative orchestration as the generation control layer. This framework is deeply and dynamically coupled with the task structure, which can accurately perceive the internal element structure of the emergency plan, avoid the dilution of retrieval accuracy caused by recalling a large amount of irrelevant content during the query, and ensure the semantic integrity of the injected context. After parallel invocation of the dual indexes, the retrieval results are injected into the generation model through channels after semantic tagging, so that the generated solution can obtain external knowledge support in both the structural framework reference and the legal compliance basis. At the same time, a multi-round clarification mechanism and structured Prompt engineering are introduced to form a complete closed loop of human-machine collaborative optimization. Based on the event description input by the user, relevant emergency plan knowledge can be quickly retrieved after multiple rounds of clarification and a structured response plan can be generated. This improves the generation efficiency and accuracy of emergency plans and has the practical effect of assisting front-line emergency commanders in quickly forming response ideas.

[0076] 2. In the area of ​​incremental learning from external knowledge bases, a non-parametric incremental learning mechanism based on dynamic expansion of external knowledge bases was designed: A domain knowledge base covering basic regulations and emergency cases was constructed. A method for mining core elements of emergency plans based on JSON structured parsing and text cleaning strategies was proposed. An incremental writing mechanism for Elasticsearch was designed, using JSON structured parsing and cascading validity filtering as pre-processing for data entry, quality gating as the admission condition, and atomic writing for Elasticsearch as the update channel. High-quality generated emergency plans are automatically written back as the knowledge source for subsequent retrieval, so that newly accumulated cases and revised regulatory texts are continuously written into the knowledge base and continuously included in the retrieval scope without retraining the model, modifying model parameters, or rebuilding the full index. This forms a self-growing closed loop of generation and retrieval, reducing the maintenance cost of the system in real business scenarios and demonstrating engineering feasibility for integration into actual emergency information systems.

[0077] Experiments show that after introducing the dual-index retrieval enhancement mechanism, the average comprehensive quality score of the contingency plan reached 92.45 points, an improvement of 7.1% compared to the baseline without retrieval enhancement. The traceable citation density increased by 81.1 points, and the traceability of knowledge sources was significantly enhanced. In the multi-round dialogue clarification experiment, the demand information expansion gain index increased by 140.1%, and the output stability was also greatly improved. The knowledge base scale gradient experiment (7 / 70 / 700 cases) shows that the comprehensive learning score increases logarithmically with the scale, and different types of knowledge have fundamentally different dependencies on scale: the general chapter structure can saturate with a small number of cases, while the precise program time limit requires continuous scale accumulation to be stable and effective. Based on this, the prototype system integrates the complete process from demand clarification to incremental write-back, and the end-to-end feasibility was verified with the flood emergency plan generation case.

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

[0079] This application also provides an emergency response plan generation device based on a large language model, employing an emergency response plan generation method based on a large language model. In one embodiment, it includes: The first module is used to obtain user input in natural language description; The second module is used to clarify the user input requirements in order to achieve progressive structuring of the user input and obtain structured input that meets the preset information density requirements. The third module is used to generate prompt words based on structured input that meets preset information density requirements; The fourth module is used to obtain the legal document repository and the emergency case repository. The legal document repository stores laws, regulations, and normative documents, while the emergency case repository stores the full text of emergency plans and historical handling cases. Based on the legal document repository and the emergency case repository, the Elasticsearch search engine is used to generate independent legal indexes and case indexes. Using a large language model, prompt words are used as input to perform searches based on the legal index and case index respectively, and legal search results and case search results are obtained. The fifth module is used to generate emergency response plans based on the results of legal and case searches.

[0080] For specific limitations regarding the emergency response plan generation device based on a large language model, please refer to the limitations of the emergency response plan generation method based on a large language model mentioned above, which will not be repeated here. Each module in the above device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device in hardware form, or stored in the memory of a computer device in software form, so that the processor can call and execute the operations corresponding to each module.

[0081] This application also provides an emergency plan generation system based on a large language model, which employs an emergency plan generation device based on a large language model. In one embodiment, it includes: an input layer, a processing layer, and a data layer. The input layer includes: a first module, an input interface, and an output interface; The processing layer includes: the second module, the third module, the fourth module, and the fifth module; The data layer includes: a regulatory document library, an emergency case library, and a requirement clarification record; The connection relationships include: the first module, the second module, the third module, the fourth module, and the fifth module are connected in sequence; the input interface is connected to the first module; the output interface is connected to the fifth module; the legal document library and the emergency case library are both connected to the fourth module; and the requirement clarification record is connected to the second module.

[0082] The contents not described in detail in this specification are existing technologies known to those skilled in the art.

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

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

Claims

1. A method for generating emergency response plans based on a large language model, characterized in that, include: Obtain user input in natural language description; Clarify user input requirements to achieve progressive structuring of user input and obtain structured input that meets preset information density requirements; Based on structured input that meets preset information density requirements, generate prompt words; The system acquires a legal document repository and an emergency case repository. The legal document repository stores laws, regulations, and normative documents, while the emergency case repository stores the full text of emergency plans and historical handling cases. Based on the legal document repository and the emergency case repository, an independent legal index and a case index are generated using the Elasticsearch search engine. Using a large language model with prompt words as input, searches are performed based on the legal index and the case index respectively to obtain legal search results and case search results. Emergency response plans are generated based on the results of legal and case searches.

2. The emergency response plan generation method based on a large language model according to claim 1, characterized in that, After generating the emergency response plan, it also includes: The generated emergency response plans are evaluated, and when they meet the preset requirements, they are written into the emergency case database to dynamically update the database, forming a self-growing closed loop of generation and retrieval.

3. The emergency response plan generation method based on a large language model according to claim 2, characterized in that, The generated emergency response plan will be written into the emergency case library, including: Based on JSON structured parsing and text cleaning strategies, the core elements of the generated emergency response plan are extracted. An incremental write mechanism for Elasticsearch is adopted to write the core elements of the generated emergency plan into the emergency case library.

4. A method for generating emergency response plans based on a large language model according to any one of claims 1 to 3, characterized in that, Clarify user input requirements to achieve progressive structuring of user input, resulting in structured input that meets preset information density requirements, including: When user input is underdefined in terms of applicable subject, response level, or geographical scope, multiple rounds of structured question-and-answer sessions are conducted to clarify user needs, confirm intent, and complete information, thereby achieving progressive structuring of user input and obtaining structured input that meets preset information density requirements.

5. A method for generating emergency response plans based on a large language model according to any one of claims 1 to 3, characterized in that, Based on the results of regulatory and case searches, an emergency response plan is generated, including: Based on the results of regulatory and case searches, a multi-agent collaborative generation framework is adopted. The regulatory search results provide a chain of evidence for the compliance of the provisions, and the case search results provide a framework for the contingency plan structure and a reference for handling, thereby generating an emergency plan.

6. The emergency response plan generation method based on a large language model according to claim 5, characterized in that, The multi-agent collaborative generation framework includes: clarifying agent, supervisory agent, research agent, compression agent, and generative agent; The clarifying agent is used to obtain user input described in natural language, clarify the user input requirements, and achieve progressive structuring of the user input to obtain structured input that meets the preset information density requirements. The supervisory agent is used to concurrently delegate to multiple research agent instances, each instance independently completing a retrieval task for a subtopic; The research agent is used to employ a large language model, taking prompt words as input, and to retrieve legal and case search results based on the legal index and case search index respectively. The compressed agent is used to condense the retrieval results of the research agent and report them to the regulatory agent; The generated intelligent agent is used to generate emergency plans based on the results of regulatory and case searches.

7. A method for generating emergency response plans based on a large language model according to any one of claims 1 to 3, characterized in that, The regulatory index and the case index are configured with different word segmentation strategies and retrieval weights.

8. The emergency response plan generation method based on a large language model according to claim 7, characterized in that, The regulatory index uses the standard analyzer to maintain the retrieval stability of precise terms such as regulatory numbers; The case index uses an IK dual-mode segmenter to ensure retrieval accuracy for terminology-intensive case texts.

9. An emergency response plan generation device based on a large language model, characterized in that, An emergency response plan generation method based on a large language model, as described in any one of claims 1 to 8, includes: The first module is used to obtain user input in natural language description; The second module is used to clarify the user input requirements in order to achieve progressive structuring of the user input and obtain structured input that meets the preset information density requirements. The third module is used to generate prompt words based on structured input that meets preset information density requirements; The fourth module is used to obtain a legal document library and an emergency case library. The legal document library stores laws, regulations, and normative documents, while the emergency case library stores the full text of emergency plans and historical handling cases. Based on the legal document library and the emergency case library, an independent legal index and case index are generated using the Elasticsearch search engine. Using a large language model, with prompt words as input, searches are performed based on the legal index and case index respectively to obtain legal search results and case search results. The fifth module is used to generate emergency response plans based on the results of legal and case searches.

10. An emergency response plan generation system based on a large language model, characterized in that, The emergency response plan generation device based on a large language model as described in claim 9 includes: an input layer, a processing layer, and a data layer; The input layer includes: a first module, an input interface, and an output interface; The processing layer includes: a second module, a third module, a fourth module, and a fifth module; The data layer includes: a regulatory document library, an emergency case library, and a requirement clarification record; The first, second, third, fourth, and fifth modules are connected in sequence. The input interface is connected to the first module, the output interface is connected to the fifth module, the legal document library and the emergency case library are both connected to the fourth module, and the requirement clarification record is connected to the second module.

Images