Method and system for customs emergency decision based on multi-agent large language model
By constructing a customs emergency knowledge graph through a multi-agent collaborative framework, the problems of unreliability in knowledge extraction and disconnect between knowledge and application in customs emergency decision-making are solved. This achieves high-fidelity and traceable emergency decision support, breaks through the limitations of a single large language model, and ensures the reliability and completeness of decision-making.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- QINGDAO UNIV OF TECH
- Filing Date
- 2025-12-30
- Publication Date
- 2026-04-21
AI Technical Summary
Existing technologies in customs emergency decision-making suffer from problems such as factual illusion, unreliability, and a disconnect between knowledge construction and application. They are difficult to effectively extract procedural knowledge from emergency plans, and single large language models or general multi-agent systems lack adaptability and reliability in the customs field.
A multi-agent collaborative framework is adopted, including a procedure parsing agent, a key point filtering agent, an emergency element extraction agent, and a logic construction agent, to build a high-fidelity knowledge graph. Dynamic decision support is provided through the graph navigation agent to ensure the accuracy and traceability of knowledge.
It has achieved high-fidelity automated construction of customs emergency knowledge graph, ensuring the accuracy and completeness of knowledge. The generated emergency suggestions are accurate, reliable and have complete traceability, opening up the entire chain from unstructured procedural documents to intelligent decision support.
Smart Images

Figure CN121413787B_ABST
Abstract
Description
Technical Field
[0001] This application belongs to the field of artificial intelligence knowledge graph technology, and specifically relates to a customs emergency decision-making method and system based on a multi-agent large language model. Background Technology
[0002] While existing technologies have explored the application of artificial intelligence techniques such as large language models and knowledge graphs to address the intelligent needs of customs emergency decision-making, several limitations remain. On the one hand, directly applying large language models faces fundamental flaws such as the illusion of fact and the untraceability of the decision-making process. On the other hand, the process of automatically constructing high-quality knowledge graphs is itself challenging. Traditional natural language processing methods struggle to effectively extract core "procedural knowledge" from emergency plans, and the reliability, consistency, and adaptability to customs-specific knowledge are difficult to guarantee when using single large language models or general multi-agent systems for knowledge extraction. Furthermore, existing technologies generally suffer from a disconnect between knowledge construction and application, failing to effectively transform the constructed static knowledge graphs into practical tools that support dynamic, multi-step decision-making processes.
[0003] It should be noted that the information disclosed in the background section above is only used to enhance the understanding of the background of this application, and therefore may include information that does not constitute prior art known to those skilled in the art. Summary of the Invention
[0004] To address or at least alleviate one or more of the above problems, a customs emergency decision-making method and system based on a multi-agent large language model is provided. This method can achieve high-fidelity automated construction of a customs emergency knowledge graph, ensuring the accuracy and completeness of the knowledge. It can also transform static knowledge graphs into interactive dynamic decision support tools, ensuring that the generated emergency recommendations are accurate, reliable, and have complete traceability, truly connecting the entire chain from unstructured procedural documents to intelligent decision support.
[0005] To achieve the above objectives, according to the first aspect of this application, a customs emergency decision-making method based on a multi-agent large language model is provided, comprising the following steps:
[0006] Knowledge graph construction phase:
[0007] A knowledge graph is constructed from unstructured customs emergency response procedure documents using a multi-agent collaborative framework. This framework includes at least a procedure parsing agent, a key point filtering agent, an emergency element extraction agent, and a logic construction agent.
[0008] The procedure parsing agent is used to perform standardized preprocessing on the original document and extract document type metadata; the key point filtering agent is used to perform semantic segmentation and relevance scoring on the document to filter out high-value paragraphs; the emergency element extraction agent and the logic construction agent work together to extract entities and relations from the high-value paragraphs respectively, and the head entity and tail entity of the relation are constrained to come from the set of entities extracted in the same paragraph.
[0009] Intelligent decision support stage:
[0010] Based on the constructed knowledge graph, a graph navigation agent driven by a large language model provides support and answers to users' emergency decision-making problems; among them,
[0011] The graph navigation agent dynamically retrieves and constructs a context subgraph that logically matches the question intent from the knowledge graph through iterative graph traversal. Based on the context subgraph, a constraint generation mechanism is adopted to generate a decision answer containing disposal steps and tracing information. The constraint generation mechanism forces that the content of the decision answer originates from the verified knowledge triples in the context subgraph.
[0012] To achieve the above objectives, according to a second aspect of this application, an emergency decision-making system based on a multi-agent large language model is provided, the customs emergency decision-making system comprising:
[0013] Knowledge graph construction module: The knowledge graph construction module includes at least a parsing module and an extraction module; the knowledge graph construction module constructs a knowledge graph from unstructured customs emergency procedure documents through a multi-agent collaborative framework; the parsing module deploys at least a procedure parsing agent and a key point filtering agent, and the extraction module deploys at least an emergency element extraction agent and a logic construction agent;
[0014] The multi-agent collaboration framework includes at least a procedure parsing agent, a key point filtering agent, an emergency element extraction agent, and a logic construction agent. The procedure parsing agent performs standardized preprocessing on the original document and extracts document type metadata. The key point filtering agent performs semantic segmentation and relevance scoring on the document to filter out high-value paragraphs. The emergency element extraction agent and the logic construction agent work together to extract entities and relationships from the high-value paragraphs, respectively, and the head and tail entities of the relationships are constrained to originate from the same set of extracted entities within the same paragraph.
[0015] Intelligent Decision Support Module: Based on the constructed knowledge graph, a graph navigation agent driven by a large language model provides support and answers to users' emergency decision-making problems. The graph navigation agent dynamically retrieves and constructs a context subgraph that logically matches the problem intent from the knowledge graph through iterative graph traversal. Based on the context subgraph, a constraint generation mechanism is used to generate a decision answer containing handling steps and tracing information. This constraint generation mechanism mandates that the content of the decision answer originates from verified knowledge triples in the context subgraph.
[0016] To achieve the above objectives, in accordance with the third aspect of this application, a computer-readable storage medium is provided, storing a computer program that, when executed by a processor, implements the emergency decision-making method based on a multi-agent large language model as described above.
[0017] By adopting the above technical solution, this application has the following beneficial effects compared with the prior art:
[0018] This application addresses the "illusion" and unreliability issues inherent in existing technologies where single large language models are applied to high-risk customs decision-making. It introduces a multi-agent framework with clearly defined roles and cross-verifiable capabilities. Through task decomposition and a multi-stage quality control mechanism, it overcomes the flaw of single large language models easily generating factual errors when independently handling complex tasks. This pipeline, through conflict resolution and multi-dimensional evaluation, effectively suppresses and filters "illusion" content generated by the large language model during extraction, thereby ensuring that the knowledge ultimately incorporated into the knowledge graph possesses high reliability and factual consistency.
[0019] This application addresses the technical challenge of effectively extracting "procedural knowledge" from customs emergency response plans using existing Natural Language Processing (NLP) methods. It employs a specially designed emergency element extraction agent to achieve the complete extraction and structuring of long operational instructions. This design overcomes the limitations of traditional Named Entity Recognition (NER) models, which can only handle short, discrete entities, and can capture complete operational instructions containing time, actions, and objects as a coherent semantic unit. This direct modeling of procedural knowledge allows this application to fully preserve the core handling procedures of the emergency response plan, laying a solid foundation for subsequent process-based decision support.
[0020] This application addresses the problem in existing technologies where knowledge construction and application are disconnected, making it difficult to provide traceable and complete dynamic decision support. It designs a graph traversal question-answering framework based on dynamic reasoning using a large language model to achieve a closed-loop technology of "knowledge construction - knowledge application." This method breaks through the traditional knowledge graph question-answering model that relies on static, one-time retrieval, and can adaptively explore and construct logical subgraphs containing multi-step reasoning within the graph based on user questions. The answers generated based on this mechanism have each key information point directly anchored to a validated knowledge graph path, thereby achieving high traceability and interpretability of decision recommendations and providing emergency command personnel with complete and practically valuable decision support.
[0021] The specific embodiments of this application will be described in further detail below with reference to the accompanying drawings. Attached Figure Description
[0022] The accompanying drawings, which form part of this application, are used to provide a further understanding of the application. The illustrative embodiments and descriptions of the application are used to explain the application, but do not constitute an undue limitation of the application. Obviously, the drawings described below are merely some embodiments, and those skilled in the art can obtain other drawings based on these drawings without creative effort.
[0023] In the attached diagram:
[0024] Figure 1 This is a schematic diagram of the architecture of the customs emergency decision-making method based on a multi-agent large language model in this specific embodiment;
[0025] Figure 2 This is a flowchart illustrating the document ingestion and standardization preprocessing flow of the customs emergency decision-making method based on a multi-agent large language model in this specific embodiment.
[0026] Figure 3 This is a schematic diagram of the document parsing and relevance screening process of the customs emergency decision-making method based on a multi-agent large language model in this specific embodiment;
[0027] Figure 4 This is a flowchart illustrating the two-stage semantic alignment process of global knowledge normalization and standardization in the customs emergency decision-making method based on a multi-agent large language model in this specific implementation.
[0028] Figure 5 This is a schematic diagram of the quality control and integration process of the customs emergency decision-making method based on a multi-agent large language model in this specific embodiment;
[0029] Figure 6This is a schematic diagram of the user question analysis and dynamic reasoning retrieval process of the customs emergency decision-making method based on a multi-agent large language model in this specific embodiment;
[0030] Figure 7 This is a schematic diagram of the constraint answer generation and decision tracing process of the customs emergency decision-making method based on a multi-agent large language model in this specific embodiment.
[0031] Figure 8 This is a schematic diagram of the relevant sub-graphs of the customs emergency decision-making method based on a multi-agent large language model in this specific embodiment;
[0032] Figure 9 This is a schematic diagram of the customs emergency decision-making system based on a multi-agent large language model in this specific embodiment. Detailed Implementation
[0033] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions in the embodiments will be clearly and completely described below with reference to the accompanying drawings and taking a customs emergency decision-making scenario as an example. The following embodiments are used to illustrate this application, but are not intended to limit the scope of this application.
[0034] Please refer to Figure 1 This application provides a customs emergency decision-making method based on a multi-agent large language model, comprising the following steps:
[0035] Knowledge graph construction phase:
[0036] A knowledge graph is constructed from unstructured customs emergency response procedure documents using a multi-agent collaborative framework. This framework includes at least a procedure parsing agent, a key point filtering agent, an emergency element extraction agent, and a logic construction agent.
[0037] The procedure parsing agent is used to perform standardized preprocessing on the original document and extract document type metadata; the key point filtering agent is used to perform semantic segmentation and relevance scoring on the document to filter out high-value paragraphs; the emergency element extraction agent and the logic construction agent work together to extract entities and relations from the high-value paragraphs respectively, and the head entity and tail entity of the relation are constrained to come from the set of entities extracted in the same paragraph.
[0038] Intelligent decision support stage:
[0039] Based on the constructed knowledge graph, a graph navigation agent driven by a large language model provides support and answers to users' emergency decision-making problems; among them,
[0040] The graph navigation agent dynamically retrieves and constructs a context subgraph that logically matches the question intent from the knowledge graph through iterative graph traversal. Based on the context subgraph, a constraint generation mechanism is adopted to generate a decision answer containing disposal steps and tracing information. The constraint generation mechanism forces that the content of the decision answer originates from the verified knowledge triples in the context subgraph.
[0041] It should be noted that the executing entity of the customs emergency decision-making method based on a multi-agent large language model in this embodiment is a customs emergency decision-making system based on a multi-agent large language model. This system can be an electronic device, a component in an electronic device, an integrated circuit, or a chip. The electronic device can be a mobile electronic device or a non-mobile electronic device. For example, mobile electronic devices can be mobile phones, tablets, laptops, PDAs, vehicle-mounted electronic devices, wearable devices, etc., and non-mobile electronic devices can be servers and personal computers, etc., which are not specifically limited in this application. The following description uses a server as the executing entity to illustrate the emergency decision-making method based on a multi-agent large language model in this embodiment.
[0042] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Therefore, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of the embodiments of this application, "multiple" means two or more, unless otherwise explicitly specified.
[0043] In some embodiments, the first phase involves the automated construction of a customs emergency knowledge graph.
[0044] Specifically, the goal of the first phase is to process the massive amount of unstructured customs emergency procedure documents. Transform it into a structured, logically consistent, and content-rich knowledge graph. This process can be formally represented as an analysis of existing knowledge graphs. Expansion:
[0045] ;
[0046] ;
[0047] in, This represents a knowledge extraction function that obtains a set of validated, valid knowledge triples extracted from the document. This indicates that the knowledge graph augmentation function will extract data from the document set. All knowledge extracted from it is incorporated into the graph. . Represents a collection of documents The first in One emergency procedure document, Indicates a document index. This indicates the total number of documents.
[0048] To achieve this goal, this phase employs a collaborative framework consisting of multiple functionally specialized agents driven by a large language model, specifically including the following steps:
[0049] S1: Document Ingestion and Standardization Preprocessing:
[0050] S1 is executed by the procedure parsing agent. Its role is to serve as the entry point for the data processing pipeline, responsible for standardizing and performing preliminary semantic tagging on raw documents of various formats, laying a solid foundation for the accurate processing of all downstream agents.
[0051] In some embodiments, the procedure parsing agent is used to perform standardized preprocessing on the original document and extract document type metadata, including:
[0052] Text extraction: Extracting raw text content from a raw document format;
[0053] Document type determination: By calling a large language model to analyze the document content, it is classified into a certain type in a predefined emergency category system;
[0054] Metadata extraction: Extract macro-level attribute information from the document, including the plan name, responsible department, and release date;
[0055] Contact Information Extraction: Emergency contact information is independently extracted from documents and compiled into a queryable contact database; among which,
[0056] The extracted document types, metadata, and contact information together constitute a standardized data object for the document, providing context for subsequent knowledge extraction and decision support.
[0057] For example, the process of S1 is shown in Figure 2, and specifically includes the following sub-steps:
[0058] Step 1: Text Extraction: The procedure parsing agent first processes input documents in various formats (such as PDF, Word documents, etc.), converting them into a plain text stream using optical character recognition (OCR) or a text parsing library. During this process, preliminary text cleaning is performed, including correcting obvious OCR errors, handling text disorder caused by tables and multi-column layouts, and removing irrelevant information such as headers, footers, and page numbers to generate a clean, linear text content.
[0059] Step 2: Document Type Determination: To assign high-level semantic tags to the documents, the procedure parsing agent submits the extracted text titles and summaries to a large language model specifically designed for classification tasks. This model is instructed to select the best-matching category from a predefined emergency category system. This classification result serves as document-level metadata, assigning source types to entities and relationships in subsequent steps and supporting more precise, category-based graph queries in the second phase.
[0060] Step 3: Metadata Extraction: The procedure parsing agent further calls the large language model to analyze the full text of the document or a representative part of it to extract macro-level attributes at the document level, such as the plan name, the main responsible department, the release or revision date, the document version number, the applicable region, and the emergency response level covered by the plan (such as "Level I, Level II").
[0061] Step 4: Contact Information Extraction: This step aims to separate the "tasks" (processes, responsibilities) from the "people" (contact information) in the emergency plan. A procedure parsing agent is specifically instructed to scan the entire document, particularly the appendix, to extract all emergency contact information in a structured format (e.g., a JSON object containing fields for "name," "role / department," and "phone number"). This information is stored in a separate, easily searchable contact database. This decoupling design ensures that updates to contact information do not affect the stability of the core knowledge graph and enables the direct attachment of executable contact information to decision-making instructions in the second phase.
[0062] This process can be formally defined as a transformation function. , represented as:
[0063] ;
[0064] in, This represents the raw, unprocessed input document. Represents text content, Indicates document category, Represents the meta-dataset, This represents the contact information database.
[0065] First, the procedure parsing agent losslessly extracts plain text from formats such as PDF, obtaining clean text content. Secondly, the procedure parsing intelligent system extracts document-level metadata, such as the plan name and responsible department, to form a structured metadata dataset. Next, the procedure parsing agent, based on text and metadata, quickly categorizes the contingency plan into predefined emergency categories, thereby determining the document category. Finally, to ensure data security and application flexibility, the procedure parsing intelligence independently and structurally extracts all emergency contact information, encrypts the extraction results, and generates a secure contact information database. .
[0066] S2: Document parsing and relevance filtering.
[0067] S2 is executed by the key point filtering agent. Its core task is to filter key information and redundancy in the entire document, intelligently identify and filter out effective content fragments containing core emergency knowledge, thereby focusing the subsequent expensive large language model computing resources on high-value information.
[0068] In some embodiments, the key point filtering agent is used to perform semantic segmentation and relevance scoring on the document to filter out high-value paragraphs, including:
[0069] The input text is preprocessed to convert non-standard format symbols into standard format symbols.
[0070] The text is parsed into multiple semantic paragraphs based on the document structure;
[0071] A relevance score is calculated for each semantic paragraph using a large language model. The relevance score is based on the degree of association between the paragraph content and the core elements of customs emergency response.
[0072] High-value semantic segments are selected based on the relevance score and then sent to the downstream emergency element extraction agent and logic construction agent for processing.
[0073] For example, the process of S2 is as follows: Figure 3 As shown, the specific steps include the following:
[0074] Step 1: Text Preprocessing: Receives standardized text from S1 and performs critical fine-grained preprocessing. For example, it normalizes all forms of Roman numeral grades (such as "II", "I") to the standard Unicode format (such as "Ⅱ", "Ⅰ") through character normalization, and uses regular expressions to fix sentence breaks caused by line breaks, ensuring the semantic integrity of the text.
[0075] Step 2: Semantic Segmentation: Based on the document's internal structure, such as heading levels (e.g., "Article X", "3.1.2"), clause numbers, or consecutive blank lines, long texts are intelligently segmented into multiple logically coherent and context-complete semantic paragraphs. Each paragraph serves as an independent processing unit with a moderate amount of information, making it ideal for in-depth analysis using large language models.
[0076] Step 3: Relevance Scoring: Using a batch processing approach, semantic paragraphs are submitted in batches to the key point screening agent. The key point screening agent is required to act as a customs emergency expert, evaluating the semantic relevance of each paragraph to core emergency elements (such as "activation conditions," "response level," "organization and command," "handling procedures," and "departmental responsibilities"). The scoring process can be formalized as follows:
[0077] ;
[0078] in, It is the first One paragraph, This is the key value score of the paragraph, with a value range of [0.0, 1.0]. This represents a large language model that has been specially configured to receive a text segment. In document categories The level of information contained below that enables emergency response.
[0079] Step 4: Paragraph Filtering: The system filters paragraphs based on preset relevance score thresholds. (A hyperparameter that can be adjusted according to domain requirements, such as 0.2), automatically filters out all that meet the requirements. > The high-value paragraphs are designated as "relevant paragraphs." The full text of these high-value paragraphs is then passed to the next stage, while low-value paragraphs are filtered out, thereby greatly improving the efficiency and accuracy of the entire knowledge extraction pipeline.
[0080] S3: Local context entity and relation extraction.
[0081] This step is performed independently within the local context of each "relevant paragraph" selected by S2, and is completed collaboratively by the emergency element extraction agent and the logic construction agent. The core innovation of this step lies in ensuring the extraction quality through strict contextual constraints.
[0082] In some embodiments, the emergency element extraction agent and the logic construction agent work collaboratively to extract entities and relationships from the high-value segments, including:
[0083] The emergency element extraction agent extracts entities from the currently processed semantic paragraphs. The extracted entity types include a "programmed step" composite entity used to fully represent operation instructions. The "programmed step" composite entity is a semantic unit that encapsulates a long text instruction containing time constraints, core actions, execution subject, and object as a whole.
[0084] The intelligent agent is constructed through the aforementioned logic. Within the currently processed semantic segment, relations are extracted based on the extracted entity set to generate knowledge triples.
[0085] In the process of relation extraction, a local context constraint mechanism is enforced, meaning that the head and tail entities of any generated knowledge triple are all derived from the list of fact entities extracted by the emergency element extraction agent in the current semantic paragraph.
[0086] For example, this step specifically includes the following sub-steps:
[0087] Step 1: Entity Extraction This indicates that the emergency element extraction agent performs this task by sending prompt words and relevant data to a large language model. This follows the entity extraction pattern strategy. Based on the defined entity types, the paragraph text is processed. Analyze and extract from paragraphs The extracted, localized, unnormalized collection of raw element references. This process can be formally represented as:
[0088] ;
[0089] A key innovation of this embodiment lies in the fact that the emergency element extraction agent is specifically instructed to prioritize the extraction of a composite entity type called a procedural step. This entity type aims to capture complete and atomically long operational instructions (e.g., "Report to the office and supervisor by phone within 10 minutes") that include time constraints, core actions, and executing entities or objects. This method overcomes the fundamental deficiency of traditional named entity recognition, which breaks down a complete instruction into multiple fragmented entities (such as "10 minutes," "report by phone," and "office"), thus losing process semantics. Simultaneously, the emergency element extraction agent also extracts other key entity types such as "trigger conditions" and "departments."
[0090] Step 2: Relation Extraction: Logically construct the agent within the same paragraph. Execution within the system. The logic constructs the agent to receive the original text of the paragraph. And the unnormalized original elements extracted in Step 1. As input, according to the relation extraction strategy To extract relationships. The logic-building agent performs this task by sending prompt words and relevant data to a large language model. This relation extraction process under "local context constraints" can be formally represented as:
[0091] ;
[0092] Its large language model hints include a strict "local context constraint" mechanism: when generating knowledge triples (head entity, relation, tail entity), the head and tail entities must be precisely selected from the currently provided list of local entities, and the entity names cannot be generated or modified. This constraint limits the reasoning space of the large language model to entities that have been verified to exist in the current paragraph, greatly improving the accuracy and reliability of the extracted relations and effectively suppressing the generation of "relation illusion".
[0093] After reviewing all relevant paragraphs For the processing of (j=1, ..., m), the system aggregates all locally extracted original entity sets and original knowledge triple sets into two global sets, namely the global original element set. and the global original logical relationship set This is for unified processing by S4.
[0094] S4: Two-stage semantic alignment of global knowledge normalization and standardization.
[0095] S4 is the central component for resolving knowledge heterogeneity and ensuring the consistency and integrity of the final knowledge graph. It is completed collaboratively by the knowledge normalization agent and the knowledge standardization agent.
[0096] In some embodiments, the knowledge graph construction phase further includes a step of global knowledge normalization and standardization of the extracted entities and relations, which is performed collaboratively by a knowledge normalization agent and a knowledge standardization agent, including:
[0097] The knowledge normalization agent performs atomization and canonical mapping: the extracted original entity mentions are split into atomic mentions, and a globally unique canonical name is generated for each atomic mention, thus constructing a mapping relationship from the original mentions to the canonical names;
[0098] The knowledge standardization agent performs knowledge fusion and context refinement: using the mapping relationship, entity mentions in the original knowledge triples are replaced with corresponding canonical names to achieve the standardization of relational entities; based on metadata extracted from documents, the canonical names are semantically refined to add descriptive information; entity types and relational predicates are uniformly mapped to predefined standard patterns to ensure the structural consistency of the knowledge graph.
[0099] For example, the process of this step is as follows: Figure 4 As shown, the specific steps include the following:
[0100] Step 1: Mention Atomization: Knowledge Normalization Intelligent Sense processes all original element mentions. ∈ This is especially true for compound references containing multiple entities. An extension function is defined. It is responsible for atomically decomposing composite entities. For example, it will split "Level I and II events" into two independent atomic mentions: {"Level I event", "Level II event"}; and split "Level III and above events" into {"Level I event", "Level II event", "Level III event"} based on the domain knowledge base. The output of this step is a set containing all atomic mentions. :
[0101] ;
[0102] Step 2: Canonical Name Generation: Next, the goal of the knowledge normalization agent is to generate canonical names for each atomized mention. Find its corresponding unique specification name This process involves constructing a globally normalized mapping function. This is implemented. The function will specify each atomic mention. Mapping to its unique canonical name c. This process can be formally represented as:
[0103] ;
[0104] in, It is a single atomized mention to be normalized. It is the set of all atomic references, providing global contextual information to the LLM to help it determine synonyms. The function's internal mechanism includes implicit clustering and representative selection: it groups semantically equivalent references into a single class within its inference space and outputs the most formal and unambiguous name as the canonical name for each class. By applying this constructed function... Each atomized reference is uniquely mapped to its canonical name.
[0105] Step 3: Standardize entity construction: using formulas A unique canonical name for each entity was determined. Then, NA will construct the final standardized entity object. This process can be formalized as follows:
[0106] ;
[0107] Among them, id is a specification name The globally unique identifier generated by the hash operation, 'name' is the canonical name. `type` is defined by a type aggregation function. It's determined. This function will collect all maps that map to the same canonical name. Atomization mentions The original type is determined, and type conflicts are resolved according to preset domain rules to determine the final unique type. Embedding is done by calling a pre-trained sentence vector model to define the canonical name. The semantic vectors obtained through encoding are used for subsequent similarity calculations and graph reasoning.
[0108] Through this "atomicization-generation-construction" process, the knowledge normalization agent not only unifies entity names, but also, through type aggregation and vectorization, assigns each entity a clear type and machine-understandable semantic representation, laying a solid foundation for building a high-quality knowledge graph.
[0109] Step 4: Relational Entity Normalization: The knowledge normalization agent uses a global mapping table to traverse all the original knowledge triples extracted in S3, replacing the head and tail entity references with their corresponding final normalized names. After the replacement, all triples are deduplicated. Subsequently, for each deduplicated normalized triple, the system concatenates the text of its head entity, relation, and tail entity into a single string, and similarly calls the sentence vector model to generate an embedding vector for it.
[0110] Step 5: Entity Context Refinement: The knowledge standardization agent uses the document-level metadata extracted in S1 (especially the "applicable event category") to perform secondary semantic enhancement on the standardized entities. For example, an entity with a standardized name of "Level I (Extremely Important)" can be automatically refined to "Level I, Category X Event" if the category of its source document is "Event Type X," thereby eliminating potential ambiguity. This refinement process can be represented as a functional transformation of the standardized name to obtain the refined name. :
[0111] ;
[0112] in, It is a new entity specification name that is more semantically clear after being refined from contextual information; It is a context refinement function. It takes a base canonical name and a context category as input and generates an enhanced name according to preset rules; It is the category metadata of the current document extracted from S1.
[0113] After refinement, this update will be applied synchronously to all knowledge triples containing that entity.
[0114] Step 6: Pattern Alignment: After the entity names and relational structures are finalized, the knowledge normalization agent performs the final alignment step. It invokes the large language model to force all entity types to be mapped to a predefined list of standard types. This entity type alignment process aims to find the optimal standard types. :
[0115] ;
[0116] in, This indicates the final standard entity type determined after pattern alignment; Represents a predefined, closed set of standard entity types; Represents traversal Candidate standard entity types that appear during collection; The knowledge-standardizing agent performs this task by sending prompt words and relevant data to a large language model.
[0117] Simultaneously, an internal, hard-coded mapping dictionary is used to uniformly map various relational verbs (such as "dispose of", "respond to", "be responsible") to a standard predicate. For complex relations that require model judgment, the standardization process... It can also be expressed as:
[0118] ;
[0119] in, This indicates the final standard relation type determined after pattern alignment; It represents a predefined set of standard relation types. Represents traversal Candidate standard relation types that appear when setting up a set.
[0120] By standardizing the processing of entities and relationships, we ensure the consistency of the entire knowledge graph and the ease of querying.
[0121] S5: Quality Control and Integration.
[0122] This step is the final "quality gatekeeper" in the knowledge graph construction pipeline. By simulating expert review, it ensures that only high-quality, conflict-free knowledge is ultimately adopted.
[0123] In some embodiments, the final stage of the knowledge graph construction phase also includes a quality control and integration step, jointly performed by the verification agent and the integration agent, specifically including:
[0124] Conflict resolution: When a newly extracted knowledge triplet has a potential conflict with existing knowledge in the knowledge graph, the verification agent calls the large language model to perform reasoning to resolve the logical conflict and decide whether to update, retain, or submit the knowledge for review.
[0125] Multi-dimensional quality assessment: The integrated intelligent agent quantifies and scores the knowledge triplets resolved through conflict from multiple dimensions, including credibility, clarity, and relevance.
[0126] Integration Decision: Based on the results of the quantitative scoring, calculate the comprehensive score of the knowledge triples, and decide whether to formally incorporate them into the global knowledge graph according to the preset integration threshold.
[0127] Knowledge persistence: The approved knowledge triples, along with their vector representations and source information, are persistently stored in the graph database, and indexes are built for key attributes to support subsequent dynamic reasoning.
[0128] For example, S5 is jointly managed by the verification agent and the integration agent, and its process is as follows: Figure 5 As shown, the specific steps include the following:
[0129] Step 1: Conflict Resolution: The verification agent is responsible for handling logical contradictions between new knowledge and the existing knowledge graph. When a newly generated triple... With existing triples in knowledge graphs When potential logical conflicts exist (e.g., the beginning and end entities are the same but their relationships contradict each other), the system constructs a "debate-style" prompt, presenting both triples to the large language model simultaneously and requiring it to make a judgment based on domain common sense. The decision-making process of the large language model can be represented as follows:
[0130] ;
[0131] The system returns or or decision making To guide knowledge updating strategies. It is an evidence-based adjudication function.
[0132] Step 2: Multi-dimensional quality assessment: Integrating the agent to evaluate each triple that has passed conflict resolution. The audit process employs independent quantitative scoring across three orthogonal dimensions. It focuses on three core indicators specifically designed for customs emergency response: factual accuracy. Evaluation of Triples Whether the document is faithful to the source material reflects the reliability of the knowledge. The operability of the instructions... Assess whether this knowledge point constitutes a clear, actionable instruction or assignment of responsibility. Emergency Criticality Assess the importance and priority of this knowledge point in the emergency response process.
[0133] First, multiple specially configured LLMs are invoked in parallel to process the triples from three orthogonal dimensions. Perform quantitative scoring within the range of [0.0, 1.0]:
[0134] Step 3: Integrated Decision-Making: The system makes decisions based on preset weights ( , , By aggregating the scores from the three dimensions mentioned above, a final overall quality score is calculated. :
[0135] ;
[0136] Only when Exceeding the preset integration threshold Only when the value is 0.6 is the triple considered high-quality knowledge and formally incorporated into the overall customs emergency knowledge graph. This decision-making process can be represented as:
[0137] ;
[0138] This formula indicates that only when... hour, The result is 1 (integration) only if the result is 0 (discarding). Through this rigorous quantitative evaluation and decision-making mechanism, IA ensures that only high-quality knowledge can be included in the final knowledge graph.
[0139] Step 4: Persistent storage and index building of knowledge graph: This step aims to efficiently store high-quality knowledge units that have undergone complete pipeline processing, verification and integration into a graph database such as Neo4j, and build the necessary indexes for them to enable rapid retrieval and reasoning in the second stage.
[0140] Entity node storage: For each globally unique, vectorized, and normalized entity generated in S4, the system performs a MERGE operation. This operation uses the entity's unique canonical name (entity_id) as the key to ensure that each entity node in the knowledge graph is unique.
[0141] Initial creation (ON CREATE): If the entity is added to the database for the first time, the system will store all attributes of the node, including its name, type, normalizedId, embedding (vector), and source_type of the source document (as an initial element of a list).
[0142] On-Match Update: If the entity already exists, the system updates its name and embedding to reflect the latest information and checks whether the source_type being processed is already in the node's source_types attribute list. If not, it is appended. This method allows an entity node to record its appearance in multiple types of emergency plans.
[0143] Storage of relation edges: For each knowledge triple that is ultimately integrated in S5, the system first finds the corresponding entity node in the database based on the entity_id of its head and tail entities. Then, the system performs a MERGE operation to create a directed relation edge between these two nodes.
[0144] Dynamic relation types: The type (label) of relation edges is dynamically generated based on the relation attribute of the triple and is standardized (e.g., converted to uppercase, spaces replaced with underscores) to conform to the syntax of graph databases.
[0145] Relationship attributes are stored as follows: the confidence, clarity, relevance scores of triples, and embedding vectors are stored as attributes of the relation edges. Similar to entity nodes, the `source_types` attribute is also maintained to record the source of the relation in different document types.
[0146] Index building: To accelerate query efficiency in the second stage, the system creates database indexes on the name and id attributes of entity nodes. This is crucial for quickly locating the starting node for graph traversal after extracting entities from user questions.
[0147] Phase Two: Dynamic Reasoning and Intelligent Decision Support Based on Knowledge Graphs.
[0148] This phase aims to transform the static knowledge graph built in the first phase into a dynamic application tool capable of intelligent interaction with users, proactive logical reasoning, and providing explainable decision-making. This phase is implemented through a graph traversal framework based on dynamic reasoning using a large language model, specifically including the following steps:
[0149] S6: User Question Analysis and Dynamic Reasoning Retrieval.
[0150] S6 is driven by a large language model that acts as a graph navigation agent. Its core function is to simulate the thought process of human experts when solving problems. Based on the user's question, it conducts a purposeful and adaptive deep exploration of the knowledge graph to construct a highly relevant contextual subgraph.
[0151] In some embodiments, the iterative graph traversal in the dynamic reasoning mechanism specifically performs the following steps:
[0152] Initial analysis: The graph navigation agent analyzes the user's question, identifies its intent, and extracts the core entity that serves as the starting node for graph traversal;
[0153] Iterative exploration and dynamic pruning: Starting from the initial node, a multi-step iterative graph traversal process is initiated; in each iteration step, the graph navigation agent combines the user question with the currently explored graph path, evaluates the logical relevance of all candidate extension paths in real time, and dynamically prunes irrelevant path branches.
[0154] Context subgraph construction: Paths evaluated as relevant and their corresponding nodes are continuously incorporated into a dynamically growing context subgraph until the graph navigation agent determines that the subgraph has completely covered the knowledge logic required to answer the user's question;
[0155] The context subgraph is a set of knowledge that is dynamically constructed in response to a specific user question, and is both informative and logically compact.
[0156] For example, the process of S6 is shown in Figure 6, and specifically includes the following sub-steps:
[0157] Step 1: Question Intent Recognition and Entity Extraction: When a user asks a natural language question... (For example, when faced with the question, "What should be done after a Level I, Category X incident occurs at Customs B?", the graph navigation agent first determines the category of the question.) Then extract the core entity from it. (e.g., "Customs B", "Level I X Event"), these entities will serve as the starting nodes for graph traversal.
[0158] This process can be formally represented as:
[0159] ;
[0160] in, This indicates that the graph navigation agent performs the task by sending prompts and user questions to a large language model.
[0161] Step 2: Iterative Graph Traversal and Dynamic Pruning: The system initializes an exploration queue with a starting node. In each iteration, a current node is removed from the queue, and all unexplored candidate paths (i.e., triples) connected to that node at one time are retrieved from the knowledge graph. Subsequently, the graph navigation agent receives the user's original question, the history of explored paths, and all candidate paths as context, evaluates the logical relevance of each candidate path to the final answer to the original question in real time, and selects one or more of the most relevant paths to retain. This selection and pruning process, directly driven by the large language model, can be formally represented as:
[0162] ;
[0163] in, This indicates that the graph navigation agent performs this task by sending cue words and relevant data to a large language model. This means that in the k-th iteration, it is finally... The selected set of paths. This represents the historical record of all selected paths up to the k-th iteration. This represents the set of all candidate paths originating from the current node in the k-th iteration. The representative represents the selection strategy within the graph navigation agent, evaluating it in real time and directly deciding to retain one or more of the most relevant paths.
[0164] All paths that were not selected but Both the plural branches and their subsequent branches will be dynamically pruned, thus avoiding ineffective global searches within the vast knowledge graph.
[0165] Step 3: Subgraph Construction and Queue Update: All relevant paths selected by the graph navigation agent are added to the final context subgraph. If these paths point to a new, unvisited node, that node is added as a new task to the end of the exploration queue. This iterative process continues until the exploration queue is empty or the preset maximum exploration depth K is reached, ultimately constructing a minimal context subgraph that accurately reflects the complete logical chain required to solve the user's problem. It consists of the set of paths selected in all iterations, and can be represented in the form of:
[0166] ;
[0167] in, This means that in the k-th iteration, it is finally... The selected set of paths; This represents the total number of iterations, where k represents the k-th iteration.
[0168] S7: Constraint-based answer generation and decision tracing.
[0169] The role of S7 is based on the high-reliability context subgraph retrieved by S6. This generates a complete, actionable, and fully traceable emergency response plan, ultimately completing the closed loop from data to decision-making.
[0170] In some embodiments, the step of generating a traceable decision answer specifically includes:
[0171] Contact information matching: Based on the department or role entities involved in the context subgraph, query the emergency contact database that was stored independently during the knowledge graph construction phase to obtain the corresponding contact information;
[0172] Constraint-based answer generation: The knowledge triples contained in the context subgraph and the matched contact information are used together as hard constraints and input into the large language model. In this process, the large language model is limited to the role of information integrator and is required to generate the final decision answer based on the constraints.
[0173] Decision-making process visualization: The context subgraph is presented to the user in an interactive graph format;
[0174] This ensures that every piece of information in the decision answer can be traced back to a record in the database of specific entities, relationships, or contacts in the knowledge graph, achieving full traceability of the decision-making process.
[0175] For example, the S7 process is as follows: Figure 7 As shown, the specific steps include the following:
[0176] Step 1: Relevant Contact Matching: Context Subgraph Built by the System from S6 Extract all entities of type "department" or "role". Use these entity names as query keys to access the emergency contact database established in step S1. This allows for efficient matching and the generation of a set of all relevant contacts. .
[0177] Its formal definition is as follows:
[0178] ;
[0179] in, This represents a query function that takes a set of entity names and a contact database as input and returns information for all matching contacts.
[0180] Step 2: Visualization of the context subgraph: To enhance the interpretability and transparency of the decision-making process, the system will visualize the context subgraph finally constructed in Step 3 of S6. Real-time visualization is provided. The system utilizes a visualization library, using entities in the subgraph as nodes and relationships as labeled edges to generate an interactive network graph. This graph clearly displays all knowledge paths from the starting entity to the final answer, enabling emergency commanders not only to see "what to do" but also to intuitively understand "why to do it," greatly improving the credibility of decision-making. This visualization result can be presented to users as part of the user interface, showing the subgraph content as follows: Figure 8 As shown.
[0181] by Figure 8 For example, this diagram visually illustrates the logical sub-diagram constructed by the system in response to the user's question: "How should Customs B handle a Level I Category X incident?" The sub-diagram clearly defines the emergency response responsibility system in this scenario: the "Level I Category X incident" node is explicitly handled by "Superior Department C," triggering a mechanism of "reporting progress at least daily." Regarding Customs B's frontline handling responsibilities, the diagram uses "responsible for handling" lines to point to specific time limits: "submitting a formal written report within 50 minutes" and "reporting to Superior Department C, Customs A, and collaborating department D by phone within 1 hour." It further demonstrates the internal rapid response process of its subordinate "office," which requires "reporting to the department head by phone within 10 minutes." Simultaneously, the diagram fully presents the subordinate relationship between Customs B and "Center O," as well as the specific response measures implemented by "Collaborating Department D" for "implementing on-site handling" and "conducting classified handling," thus providing clear and visible end-to-end support for emergency decision-making.
[0182] Step 3: Constrained Answer Generation: The core of this step is to address the "illusion" problem that may occur when a large language model directly generates answers. The system employs a strict constraint generation mechanism.
[0183] Customs emergency decision The generation process can be formally represented as:
[0184] ;
[0185] in, This represents a large language model specifically designed to integrate information and generate the final answer. This represents a constrained response strategy. This strategy is implemented through specific prompt templates, and its core instruction is to... Its role is strictly limited to "information integrator and summarizer," and all content it generates must directly originate from the subgraph that serves as contextual input. and contact information .
[0186] This approach ensures that every key step, every responsible department, every time limit, and every contact method in the emergency response recommendations can be directly traced back to one or more specific paths in the knowledge graph, thereby achieving high accuracy, high reliability, and full traceability of the final answer, perfectly meeting the stringent requirements of emergency decision-making scenarios.
[0187] In some embodiments, to comprehensively verify the performance of this method, the evaluation is divided into two core phases. First, the output quality of the first phase, namely the "automated construction of the customs emergency knowledge graph," is evaluated in detail, as a high-quality knowledge graph is a fundamental prerequisite for achieving reliable intelligent decision-making. The experiments in this phase aim to measure the capabilities of the multi-agent framework of this invention in knowledge extraction, integration, and quality control. Multi-agent frameworks based on different large language model bases (DeepSeekV3, GLM-4, GPT-4o) are compared, and a simplified single-agent method is introduced as a baseline, which completes all extraction tasks in a single process.
[0188] The evaluation metrics draw on standardized metrics from the knowledge graph construction field, including: core metrics ( Accuracy of facts Command operability Emergency criticality), statistical indicators of the map ( Coverage gain, i.e., the number of newly added entities. Connectivity gain (i.e., the number of new relations) and quality metrics ( The accuracy of LLM validation (Question-answer consistency). The experimental results are shown in Table 1.
[0189] Table 1: Experimental Results
[0190]
[0191] The experimental data in Table 1 clearly demonstrate that the multi-agent collaborative framework used in this embodiment has significant advantages in knowledge graph construction. Compared to the single-agent baseline, the coverage gain of this method ( The improvement was approximately 375%, demonstrating that the refined task decomposition and collaboration processes in S1-S4 can extract knowledge from the original documents more deeply and comprehensively.
[0192] In a horizontal comparison of different model bases, although the GLM-4-based framework has a slightly higher number of entities extracted, the DeepSeekV3-based framework has better question-answering consistency. This method achieved the highest score, demonstrating that it not only pursues a large quantity of knowledge but also emphasizes the internal logical consistency and usability of that knowledge. The quality control and integration mechanisms in step S5 played a crucial role in this regard. Overall, this method ensures a high accuracy rate. At the same time, it achieved the best balance between the breadth and quality of knowledge, and successfully constructed a high-quality and highly reliable customs emergency knowledge graph, laying a solid foundation for intelligent decision support in the second phase.
[0193] After verifying the superior performance of knowledge graph construction, this paper further quantitatively evaluates the final application effect of the second phase of this application, "Dynamic Reasoning and Intelligent Decision Support Based on Knowledge Graphs." The method described in this embodiment utilizes the DeepSeekV3 large language model as its core multi-agent collaborative framework, achieving automated knowledge graph construction and dynamic reasoning. In the experiments, this method is compared with methods that directly generate answers using mainstream large language models such as DeepSeekV3, GLM4, and GPT4o as baseline methods.
[0194] To simulate real-world customs emergency decision-making scenarios, this embodiment meticulously designed an evaluation set containing 50 typical questions, and all comparisons are based on this evaluation set. The evaluation dimensions cover factuality, completeness, understandability, simplicity, and guidance.
[0195] To ensure the objectivity and fairness of the evaluation process, this experiment employed a blind evaluation mechanism based on a large language model. Specifically, this embodiment anonymized the responses generated by each method for the same question and submitted them simultaneously to an independent evaluation language model. The model was required to perform a comprehensive score based on the aforementioned evaluation dimensions without being informed of the specific sources of each response. The experimental scoring results are shown in Table 2.
[0196] Table 2: Experimental Scoring Results
[0197]
[0198] The data clearly shows that our method significantly outperforms other comparative methods in several key metrics. This strongly demonstrates that our application, through a multi-agent collaborative pipeline and a constrained answer generation mechanism in step S7, can effectively suppress the "illusion" problem of large language models, ensuring the accuracy and reliability of the generated content, perfectly meeting the high rigor requirements of customs emergency decision-making.
[0199] Furthermore, this approach also significantly outperforms others in terms of completeness and guidance, demonstrating its ability to provide comprehensive and highly actionable disposal recommendations based on the high-quality knowledge graph constructed from S1-S5, thus achieving a technical closed loop from unstructured data to actionable decisions.
[0200] In summary, the experimental results directly demonstrate the significant technical effectiveness of this application in improving the intelligence level of customs emergency decision-making and ensuring the quality of decision-making.
[0201] Based on the same inventive concept, please refer to Figure 9 This application also provides a customs emergency decision-making system based on a multi-agent large language model, the customs emergency decision-making system comprising:
[0202] Knowledge graph construction module: The knowledge graph construction module includes at least a parsing module and an extraction module; the knowledge graph construction module constructs a knowledge graph from unstructured customs emergency procedure documents through a multi-agent collaborative framework; the parsing module deploys at least a procedure parsing agent and a key point filtering agent, and the extraction module deploys at least an emergency element extraction agent and a logic construction agent;
[0203] The multi-agent collaboration framework includes at least a procedure parsing agent, a key point filtering agent, an emergency element extraction agent, and a logic construction agent. The procedure parsing agent performs standardized preprocessing on the original document and extracts document type metadata. The key point filtering agent performs semantic segmentation and relevance scoring on the document to filter out high-value paragraphs. The emergency element extraction agent and the logic construction agent work together to extract entities and relationships from the high-value paragraphs, respectively, and the head and tail entities of the relationships are constrained to originate from the same set of extracted entities within the same paragraph.
[0204] Intelligent Decision Support Module: Based on the constructed knowledge graph, a graph navigation agent driven by a large language model provides support and answers to users' emergency decision-making problems. The graph navigation agent dynamically retrieves and constructs a context subgraph that logically matches the problem intent from the knowledge graph through iterative graph traversal. Based on the context subgraph, a constraint generation mechanism is used to generate a decision answer containing handling steps and tracing information. This constraint generation mechanism mandates that the content of the decision answer originates from verified knowledge triples in the context subgraph.
[0205] The knowledge graph construction module also includes a refining module, which deploys at least a knowledge standardization agent, a verification agent, and an integration agent. The knowledge standardization agent is used to perform global knowledge normalization and standardization on the extracted entities and relations, while the verification agent and the integration agent are used for quality control and integration.
[0206] Based on the same inventive concept, this application also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the emergency decision-making method based on a multi-agent large language model as described above.
[0207] The program product of this application for implementing the above method may employ a portable compact disk read-only memory and include program code, and may run on a terminal device, such as a personal computer. However, the program product of this application is not limited thereto. In this application, the readable storage medium may be any tangible medium containing or storing a program that may be used by or in conjunction with an instruction execution system, apparatus, or device.
[0208] It should be noted that a computer-readable storage medium may include data signals propagated in baseband or as part of a carrier wave, carrying readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A readable storage medium may also be any readable medium other than a readable storage medium, capable of transmitting, propagating, or transmitting programs for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the readable storage medium may be transmitted using any suitable medium, including but not limited to wireless, wired, optical fiber, RF, etc., or any suitable combination thereof.
[0209] The above are merely preferred embodiments of this application and are not intended to limit this application in any way. Although this application has disclosed preferred embodiments as described above, it is not intended to limit this application. Any person skilled in the art can make some modifications or alterations to the above-mentioned technical content to create equivalent embodiments without departing from the scope of the technical solution of this application. The implementation schemes in the above embodiments can also be further combined or replaced. Any simple modifications, equivalent changes and alterations made to the above embodiments based on the technical essence of this application without departing from the content of the technical solution of this application shall still fall within the scope of this application.
Claims
1. A customs emergency decision-making method based on a multi-agent large language model, characterized in that, Includes the following steps: Knowledge graph automated construction phase: A knowledge graph is constructed from unstructured customs emergency response procedure documents using a multi-agent collaborative framework. This framework includes at least a procedure parsing agent, a key point filtering agent, an emergency element extraction agent, and a logic construction agent. The procedure parsing agent is used to perform standardized preprocessing on the original documents in the customs emergency procedure documents and extract document type metadata; the key point filtering agent is used to perform semantic segmentation and relevance scoring on the documents to filter out high-value paragraphs; the emergency element extraction agent and the logic construction agent work together to extract entities and relations from the high-value paragraphs respectively, and the head entity and tail entity of the relation are constrained to come from the set of entities extracted in the same paragraph. The emergency element extraction agent and the logic construction agent work together to extract entities and relationships from the high-value segments, including: The emergency element extraction agent extracts entities from the currently processed semantic paragraphs. The extracted entity types include a composite entity of programmed steps used to fully represent operation instructions. The intelligent agent is constructed through the logic described above. Within the semantic segment being processed, relations are extracted based on the extracted entity set to generate a knowledge triple containing a head entity, a relation, and a tail entity. In the process of relation extraction, a local context constraint mechanism is enforced, meaning that the head and tail entities of any generated knowledge triple are all derived from the list of fact entities extracted by the emergency element extraction agent in the current semantic paragraph. The knowledge graph construction phase also includes a step of global knowledge normalization and standardization of the extracted entities and relations, which is executed collaboratively by a knowledge normalization agent and a knowledge standardization agent, including: The knowledge normalization agent performs atomization and canonical mapping: the extracted original entity mentions are split into atomic mentions, and a globally unique canonical name is generated for each atomic mention, thus constructing a mapping relationship from the original mentions to the canonical names; The knowledge standardization agent performs knowledge fusion and context refinement: using the mapping relationship, entity mentions in the original knowledge triples are replaced with corresponding canonical names to achieve the standardization of relational entities; based on metadata extracted from documents, the canonical names are semantically refined to add descriptive information; entity types and relational predicates are uniformly mapped to predefined standard patterns to ensure the structural consistency of the knowledge graph. The final stage of the knowledge graph construction phase includes a quality control and integration step, jointly executed by the verification agent and the integration agent, specifically including: Conflict resolution: When a newly extracted knowledge triplet has a potential conflict with existing knowledge in the knowledge graph, the verification agent calls the large language model to perform reasoning to resolve the logical conflict and decide whether to update, retain, or submit the knowledge for review. Multi-dimensional quality assessment: The integrated intelligent agent quantifies and scores the knowledge triplets resolved through conflict from multiple dimensions, including credibility, clarity, and relevance. Integration Decision: Based on the results of the quantitative scoring, calculate the comprehensive score of the knowledge triple and, according to the preset integration threshold, decide whether to formally integrate it into the global knowledge graph; Knowledge persistence: The approved knowledge triples, along with their vector representations and source information, are persistently stored in the graph database, and indexes are built for key attributes to support subsequent dynamic reasoning; Dynamic Reasoning and Intelligent Decision-Making Stage: Based on the constructed knowledge graph, a graph navigation agent driven by a large language model provides support and answers to users' customs emergency decision-making questions. The graph navigation agent dynamically retrieves and constructs a contextual subgraph logically matching the question's intent from the knowledge graph through iterative graph traversal, including: Initial analysis: The graph navigation agent analyzes the user's question, identifies the user's intent, and extracts the core entity that serves as the starting node for graph traversal; Iterative exploration and dynamic pruning: Starting from the initial node, a multi-step iterative graph traversal process is initiated; in each iteration step, the graph navigation agent combines the user question with the currently explored graph path, evaluates the logical relevance of all candidate extension paths in real time, and dynamically prunes irrelevant path branches. Context subgraph construction: Paths evaluated as relevant and their corresponding nodes are continuously incorporated into a dynamically growing context subgraph until the graph navigation agent determines that the subgraph has completely covered the knowledge logic required to answer the user's question; The context subgraph is a set of knowledge that is dynamically constructed in response to a specific user question, and is both information-complete and logically compact. Based on the context subgraph, a constraint generation mechanism is adopted to generate a decision answer that includes disposal steps and tracing information. The constraint generation mechanism requires that the content of the decision answer originates from the verified knowledge triples in the context subgraph.
2. The method according to claim 1, characterized in that, The procedure parsing intelligent agent is used to perform standardized preprocessing on the original documents in the customs emergency procedure documents and extract document type metadata, including: Text extraction: Extracting raw text content from a raw document format; Document type determination: By calling a large language model to analyze the document content, the document is classified into a certain type in a predefined emergency category system; Metadata extraction: Extract macro-level attribute information from the document, including the plan name, responsible department, and release date; Contact Information Extraction: Emergency contact information is independently extracted from documents and compiled into a queryable contact database; among which, The extracted document types, metadata, and contact information together constitute a standardized data object for the document, providing context for subsequent knowledge extraction and decision support.
3. The method according to claim 2, characterized in that, The key point filtering agent is used to perform semantic segmentation and relevance scoring on documents to filter out high-value paragraphs, including: The input text is preprocessed to convert non-standard format symbols into standard format symbols. The text is parsed into multiple semantic paragraphs based on the document structure; A relevance score is calculated for each semantic paragraph using a large language model. The relevance score is based on the degree of association between the paragraph content and the core elements of customs emergency response. High-value semantic segments are selected based on the relevance score and then sent to the downstream emergency element extraction agent and logic construction agent for processing.
4. The method according to claim 1, characterized in that, Based on the context subgraph, a constraint-based generation mechanism is used to generate a decision answer containing handling steps and tracing information, including: Contact information matching: Based on the department or role entities involved in the context subgraph, query the emergency contact database that was stored independently during the knowledge graph construction phase to obtain the corresponding contact information; Constraint-based answer generation: The knowledge triples contained in the context subgraph and the matched contact information are used together as hard constraints and input into the large language model. In this process, the large language model is limited to the role of information integrator and is required to generate the final decision answer based on the constraints. Decision-making process visualization: The context subgraph is presented to the user in an interactive graph format; This ensures that every piece of information in the decision answer can be traced back to a record in the database of specific entities, relationships, or contacts in the knowledge graph, achieving full traceability of the decision-making process.
5. A customs emergency decision-making system based on a multi-agent large language model, characterized in that: For implementing the customs emergency decision-making method based on a multi-agent large language model as described in any one of claims 1-4, the customs emergency decision-making system includes: Knowledge graph construction module: The knowledge graph construction module includes at least a parsing module and an extraction module; the knowledge graph construction module constructs a knowledge graph from unstructured customs emergency procedure documents through a multi-agent collaborative framework; the parsing module deploys at least a procedure parsing agent and a key point filtering agent, and the extraction module deploys at least an emergency element extraction agent and a logic construction agent; The multi-agent collaboration framework includes at least a procedure parsing agent, a key point filtering agent, an emergency element extraction agent, and a logic construction agent. The procedure parsing agent performs standardized preprocessing on the original document and extracts document type metadata. The key point filtering agent performs semantic segmentation and relevance scoring on the document to filter out high-value paragraphs. The emergency element extraction agent and the logic construction agent work together to extract entities and relationships from the high-value paragraphs, respectively, and the head and tail entities of the relationships are constrained to originate from the same set of extracted entities within the same paragraph. Intelligent Decision Support Module: Based on the constructed knowledge graph, a graph navigation agent driven by a large language model provides support and answers to users' emergency decision-making problems. The graph navigation agent dynamically retrieves and constructs a context subgraph that logically matches the problem intent from the knowledge graph through iterative graph traversal. Based on the context subgraph, a constraint generation mechanism is used to generate a decision answer containing handling steps and tracing information. This constraint generation mechanism mandates that the content of the decision answer originates from verified knowledge triples in the context subgraph.
6. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by the processor, it implements the customs emergency decision-making method based on a multi-agent large language model as described in any one of claims 1-4.
Citation Information
Patent Citations
Intelligent question and answer method based on cooperation of large language model and knowledge graph
CN118797017A
Large language model retrieval enhancement generation method for cyberspace security emergency intelligent analysis
CN120104649A