Multi-agent collaborative query method, system, device and medium for aviation manufacturing xBOM

Abstract

This invention belongs to the field of artificial intelligence application technology and discloses a multi-agent collaborative query method, system, device, and medium for aerospace manufacturing xBOM. Based on query complexity assessment results, the query task is routed to different specialized agents for processing. The query intent is parsed, and the query task is decomposed into sub-tasks. A task dependency graph is constructed based on the dependencies between sub-tasks, and the sub-tasks are mapped to atomic tools of each specialized agent. Corresponding atomic tools are matched to the sub-tasks, and the sub-tasks are executed one by one according to the dependencies between them, outputting the query results. The query complexity is quantified through complexity features, and different processing modes are used for each sub-task. Different agent combinations / cooperative methods are employed in different processing modes to achieve adaptive resource allocation. Aerospace validity inference rules are encapsulated in the EVA agent to ensure that the same query yields consistent and accurate results at different times.

Description

Technical Field

[0001] This invention belongs to the field of artificial intelligence application technology, specifically relating to a multi-agent collaborative query method, system, device and medium for aerospace manufacturing xBOM. Background Technology

[0002] In aerospace manufacturing enterprises, xBOM (a mixed bill of materials, including multiple views such as EBOM / MBOM / SBOM) is the core data foundation that runs through the entire life cycle of product design, process planning, manufacturing execution and after-sales service. Unlike general data queries, aerospace xBOM has the following characteristics: (1) Multiple views coexist, the same material has different attribute sets and relationships in EBOM (design view), MBOM (manufacturing view), SBOM (supplier view) and VCBOM (version view); (2) Strong validity constraints, each BOM entry is strictly constrained by multi-dimensional validity conditions such as configuration baseline, flight range, effective date, engineering change package; (3) Hierarchical graph structure, BOM is essentially a tree / network assembly structure with a depth of up to dozens of layers; (4) Multi-source heterogeneous data fusion, xBOM data is scattered in multiple independent systems such as PLM (product lifecycle management), ERP (enterprise resource planning), MES (manufacturing execution system), supplier portal, etc., and the data models, update frequencies and authority of each system are different.

[0003] With the advancement of enterprise digital transformation, xBOM data query requirements have evolved from simple transactional retrieval to complex cross-view, multi-constraint relational analysis. However, existing technical solutions have the following problems when handling aviation xBOM queries: (a) Traditional PLM / ERP system retrieval method: Relying on the xBOM data query capability provided by the PLM or ERP system, the typical query process includes the following steps: (1) The user logs into the PLM / ERP system and enters the BOM management module; (2) Enters keywords such as part number, material name, and material in the search interface to perform a full-text search; (3) Manually filters the target material in the search results list; (4) Views the assembly relationship level by level through the BOM structure tree expansion function; (5) Sets the filtering conditions such as material status, process version, and supplier through the multi-condition filtering panel; (6) The system returns the filtered BOM subset; (7) If cross-view comparison is required (such as the difference between EBOM and MBOM), the user needs to switch to different view modules, export Excel and then manually compare. The problem with this method is that the system can only perform precise filtering based on primary key matching and predefined SQL predicates, and cannot understand the semantics of "flight validity" and "configuration baseline" unique to the aviation field. Users must accurately grasp the field names and logical relationships within the system to complete the query.

[0004] (ii) Predefined report method: In addition to interactive retrieval, it still relies heavily on pre-configured BOM reports for periodic queries. The process is as follows: (1) Process or quality engineers configure query parameters in the report tool according to fixed requirements such as a list of key parts for a certain aircraft model or a material arrival list for a certain supplier; (2) The report contains hard-coded multi-table JOIN logic, aggregate functions and filtering conditions; (3) The report is executed periodically to obtain results; (4) When new query requirements are added, such as cross-aircraft BOM comparison or historical configuration tracing of a certain part, IT personnel need to modify the SQL or write a new report, which usually takes several days. The query logic of this method is completely fixed and cannot adapt to the dynamic query requirements brought about by frequent engineering changes, configuration switching and flight adjustments in aviation manufacturing.

[0005] (III) Knowledge Graph BOM Query Based on Graph Database: The BOM structure is stored in a graph database, and a basic BOM knowledge graph is constructed to support graph traversal query. The typical process is as follows: (1) Import the BOM structure into the graph database and establish part nodes and parent-child assembly edges; (2) The user writes graph query statements such as Cypher and performs graph traversal operations such as BOM expansion and tracing; (3) Return the graph query results. Although this solution solves the problem of poor performance of recursive query in relational database, the following problems still exist: 1. The ontology modeling of the validity dimensions such as configuration baseline, flight range, and validity code unique to aviation manufacturing is not performed. They are still filtered as ordinary node attributes and do not support automatic validity reasoning; 2. It does not support the parsing of complex intentions in natural language. Professionals need to write graph query statements, which has a high query threshold; 3. There is no multi-step task orchestration and verification mechanism. Complex cross-view and multi-constraint queries still require manual splicing of multiple query results.

[0006] (iv) NL2SQL / Text2SQL query method based on large model: The LLM-driven natural language query method is adopted. Its typical process includes: (1) receiving the user's natural language query; (2) obtaining the relevant table structure from the metadata through pattern linking or semantic retrieval; (3) generating SQL statements by LLM; (4) executing SQL in the relational database and returning the results. This method has the following problems in the aviation xBOM scenario: 1. The validity dimensions such as ECP (Engineering Change Package), configuration baseline, and flight range are not modeled as explicit constraints, which makes it easy for the generated SQL to miss key validity filtering conditions. The query results may contain BOM entries that are not effective or not applicable to the target flight; 2. The graph traversal semantics such as BOM parent-child relationship, multi-level expansion, and upstream tracing are not explicitly provided to the large language model, which makes it difficult to stably generate recursive queries with validity constraints; 3. When querying across design BOM, manufacturing BOM, supplier BOM and other views, only simple table joins can usually be performed. There is a lack of semantic mapping between views and cross-view aggregation capabilities.

[0007] Therefore, existing aviation xBOM query solutions are still based on a passive mode of human-defined query logic and system-executed filtering. This results in the system being unable to understand the structured semantics, validity constraints, multi-view mapping relationships, and temporal dimensions of aviation xBOM, and thus unable to achieve autonomous reasoning and orchestration of complex queries. Summary of the Invention

[0008] The purpose of this invention is to provide a multi-agent collaborative query method, system, device and medium for aerospace manufacturing xBOM, which solves the problem that existing query methods cannot achieve autonomous complex query reasoning and arrangement, and cannot guarantee the accuracy and reliability of aerospace manufacturing xBOM queries.

[0009] This invention is achieved through the following technical solution: A multi-agent collaborative query method for aerospace manufacturing xBOM includes the following steps: The system acquires user natural language queries, evaluates their complexity, and routes the query tasks to different dedicated intelligent agents for processing based on the evaluation results. These dedicated intelligent agents include a structure navigation agent, a validity verification agent, and a compliance arbitration agent. The structure navigation agent includes atomic tools for node localization, structure filtering, upward traversal, downward traversal, and cross-view comparison. The validity verification agent includes atomic tools for effective scope detection, validity conflict checking, and validity analysis. During validity analysis, it calls the corresponding propagation operator based on the query type to perform downward expansion, upward tracing, and cross-view mapping validity analysis, and outputs the filtered set of valid nodes. The compliance arbitration agent includes atomic tools for certification status confirmation, in-process status confirmation, supplier compliance confirmation, and change impact confirmation. The query intent is parsed, the query task is decomposed into subtasks, each subtask corresponds to an executable atomic operation, a task dependency graph is constructed based on the dependencies between subtasks, and the subtasks are mapped to the atomic tools of each professional agent. Match the corresponding atomic tools to the subtasks and execute the subtasks one by one according to the dependencies between them, and output the query results.

[0010] In some embodiments, node positioning is used to locate all occurrences of a specified part number in the xBOM knowledge graph and return the node ID, the view it belongs to, and the node attributes; the xBOM knowledge graph includes nodes and edges, and the node represents an instance of a material under a certain BOM view, version, configuration baseline, and data source. The structural filtering is to perform structural dimension filtering on a specified set of nodes, including node type filtering, view filtering, and hierarchy filtering; the specified set of nodes is the set of candidate nodes output through node positioning. The upward traversal is to trace upwards from the specified node along the BOM parent relationship and return all parent nodes and their assembly relationships within the specified depth. The downward traversal is to expand downwards from the specified node along the BOM sub-relationships and return all child nodes and their assembly relationships within the specified depth. The cross-view comparison involves comparing the differences between specified nodes in different types of BOM views and returning the differences in BOM data between the views.

[0011] In some embodiments, the effective range detection is to resolve the effective range of nodes based on a specified configuration baseline, including an applicable flight list and an effective date range; The validity conflict check is to detect validity conflicts between two node sets; the node set is a collection of candidate nodes from different BOM views, different configuration baselines, different data sources, or different traversal paths. The expansion validity analysis is based on the validity constraints of the BOM structure. When expanding downwards, the valid range of a sub-component is the intersection of the valid range of the parent component and the valid range of the sub-component. If the intersection is empty, the sub-component is filtered. When tracing upwards, the valid range of the parent component is the union of the valid ranges of all sub-components to determine which flights and / or date ranges the parent component is valid for.

[0012] In some embodiments, the propagation operator includes: Downward propagation operator: Input the valid range of the parent component and the valid range of the child component, and output the intersection of the valid ranges of the parent component and the valid range of the child component; if the intersection is empty, the child component is automatically filtered in the current query; Uppropagation operator: Input the set of valid ranges of all child components, output the union of the valid ranges of all child components, and obtain the valid range of the parent component; Cross-view mapping propagation operator: Input the valid range of materials in the source view and the valid conditions in the mapping table, and output the valid range of materials in the target view.

[0013] In some embodiments, the validity verification agent includes a multidimensional validity representation layer for explicitly encoding aviation-related validity terms into a computable data structure.

[0014] In some embodiments, the validity verification agent includes a data source priority arbitrator, which, when validity information from different data sources conflicts, decides which data source to accept based on the data type and according to a set priority rule.

[0015] In some embodiments, the intent confirmation gate is triggered based on the query complexity. Once the intent confirmation gate is triggered, the intent parsing result is output, and the corresponding processing method is selected manually based on the intent parsing result. And / or, during the query execution process, determine whether to trigger the entity disambiguation confirmation gate based on the set entity triggering conditions. After the entity disambiguation confirmation gate is triggered, output the query information of all entities that are semantically similar to the queried entity object, and manually select the corresponding processing method based on the query information. And / or, before outputting the final query results, determine whether to trigger the key result confirmation gate based on the set key result trigger conditions. After the key result confirmation gate is triggered, output the evaluation results for the query situation, and manually select the corresponding processing method based on the evaluation results.

[0016] In some embodiments, when a subtask fails to execute, the cause of failure is analyzed and the failure type is output based on the cause of failure. An alternative execution strategy is selected based on the failure type and the subtask is re-executed.

[0017] In some embodiments, when a query strategy is successfully executed more than a set number of times within a set time window, a query skill draft is generated based on the query strategy to form a query skill library that can be directly invoked by users; the query strategy includes an intent structure, a dependency graph structure, and a tool invocation sequence.

[0018] On the other hand, the present invention also provides a multi-agent collaborative query system for aerospace manufacturing xBOM, used to execute the aforementioned multi-agent collaborative query method for aerospace manufacturing xBOM, including: The query complexity assessment and dynamic routing module is used to assess the complexity of user natural language queries and dynamically route query tasks to different query processing modes. The intent parsing agent is used to parse the user's query intent, decompose the query task into subtasks and build a task dependency graph; The multi-agent execution layer includes a structural navigation agent, a validity verification agent, and a compliance arbitration agent; Human-assisted confirmation gating includes intent confirmation gating, entity disambiguation confirmation gating, and key result confirmation gating set at different decision points in the query process; The multi-source result fusion engine is used to perform consistency verification and fusion of query results from different views, different data sources, and different atomic tools.

[0019] On the other hand, the present invention also provides an electronic device, comprising: Processor; and Memory for storing the executable instructions of the processor; The processor is configured to execute a multi-agent collaborative query method for aerospace manufacturing xBOM by executing the executable instructions.

[0020] On the other hand, the present invention also provides a computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements a multi-agent collaborative query method for aerospace manufacturing xBOM.

[0021] Compared with the prior art, the present invention has the following advantages and beneficial effects: This invention quantifies the complexity of queries through complexity features and routes them to different processing modes. Different agents and combinations / cooperative approaches are used in different processing modes to process the queries. This achieves adaptive resource configuration that minimizes overhead for simple queries and provides sufficient inference resources for complex queries, thus avoiding the problem of insufficient complexity adaptability caused by a one-size-fits-all processing mode.

[0022] To address the unique characteristics of aviation xBOM data and the unreliability of query results caused by the lack of native understanding of validity in existing query schemes, this invention encapsulates aviation validity inference rules within the EVA agent. Through EVA's three deterministic propagation operators, the validity inference of aviation xBOM data is transformed from an unstable mode relying on LLM's repeated reinterpretation to a rule-driven deterministic computation mode, ensuring consistent and accurate results for the same query executed at different times. Simultaneously, EVA's data source priority adjudicator provides deterministic adjudication criteria when multi-source validity information conflicts via a hierarchical credibility matrix, avoiding unreliable fusion caused by simple splicing or LLM's self-judgment. In typical xBOM queries with combined constraints of flight range, configuration baseline, and effective date, EVA can automatically exclude invalid entries, resolving the adaptation failure problem of existing schemes in aviation xBOM scenarios.

[0023] This invention employs a three-layer gating mechanism to upgrade "single-point interaction" to a "three-layer progressive interception defense": The first layer verifies "whether the query direction is correct" after intent understanding, preventing subsequent computational resources from being wasted on incorrect targets; the second layer verifies "which specific object has been identified" after entity recognition, preventing subsequent graph traversal from being performed on incorrect entities due to confusion between multiple versions of general / borrowed components; the third layer verifies "whether the result quality meets the standards" after multi-source fusion, preventing unreliable conclusions from being accepted by users. This three-layer gating mechanism covers the entire process from "input → process → output," balancing query efficiency and accuracy through dynamic triggering strategies.

[0024] This invention employs a three-tiered mechanism of failure type diagnosis, strategy replacement, and limited-redirection. This allows the system to continue executing other subtasks even when faced with partial failures, and to return partial results whenever possible, rather than returning a query failure, thus improving the system's usability in real-world, complex scenarios. Through a process of automatically identifying high-frequency query patterns, automatically generating skill drafts, administrator review and database entry, and automatic matching for subsequent queries, the system becomes increasingly faster at handling repetitive queries, achieving continuous optimization of query efficiency. Attached Figure Description

[0025] To more clearly illustrate the technical solutions of the embodiments of the present invention, the accompanying drawings in the embodiments will be briefly described below. It should be understood that the following drawings only show some embodiments of the present invention and should not be regarded as a limitation on the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0026] Figure 1 This is a flowchart of the multi-agent collaborative query method according to an embodiment of the present invention. Detailed Implementation

[0027] To make the objectives, technical solutions, and advantages of this application clearer, specific embodiments of this application will be described in further detail below with reference to the accompanying drawings. It should be understood that the specific embodiments described herein are merely for explaining this application and not for limiting it. It should also be noted that, for ease of description, only the parts relevant to this application are shown in the drawings, not all of them. Before discussing exemplary embodiments in more detail, it should be mentioned that some exemplary embodiments are described as processes or methods depicted as flowcharts. Although the flowcharts describe operations (or steps) as sequential processes, many of these operations can be performed in parallel, concurrently, or simultaneously. Furthermore, the order of the operations can be rearranged. The process can be terminated when its operation is completed, but may also have additional steps not included in the drawings. The process can correspond to a method, function, procedure, subroutine, subprogram, etc.

[0028] Due to the unique characteristics of aerospace manufacturing xBOM data, such as multiple views, multiple flights, multiple states, strong validity constraints, and high compliance requirements, the existing xBOM data query solutions have the following problems and their causes are analyzed: (1) Lack of native understanding of aviation validity dimensions leads to insufficient reliability of query results. The aviation manufacturing xBOM has unique validity management dimensions, including configuration baseline, validity code, flight range, engineering change package, airworthiness status, etc. When dealing with these dimensions, existing query solutions usually treat them as ordinary database fields, requiring users to select conditions one by one on the interface. When the user's query intent involves validity inference, such as "query which flights this part is applicable to under the current service configuration", the system cannot understand the semantic mapping relationship between "current service configuration" and the specific configuration baseline, nor can it automatically infer the flight range, resulting in query results that either omit applicable entries or return too many irrelevant results.

[0029] The problem stems from the fact that existing systems lack the ability to model and reason about the semantics of validity in the aviation field, and can only rely on users to fully understand the system terminology for precise configuration.

[0030] (2) The inability to independently arrange heterogeneous operations such as graph traversal and timing filtering makes it impossible for general solutions to adapt to the hierarchical structure of xBOM. xBOM is essentially a hierarchical graph structure. The BOM view expands from top to bottom in a tree-like manner, and the components are traced from bottom to top. It is accompanied by rich timing constraints such as process route timing, assembly timing, and supplier delivery timing. In the existing solution, when the query involves cross-level structure navigation such as "trace the previous level assembly of this part and its supplier" or timing association such as "the work-in-process status of this part in the current manufacturing process", the system cannot understand the semantics of "trace" and "current" and can only return the results of direct association. Users need to iterate the query multiple times, first querying the direct parent, then the parent's parent, and then the parent's supplier to complete a reasoning across multiple levels.

[0031] The problem stems from the fact that existing systems lack the ability to orchestrate graph traversal operations. Each query can only perform a single filtering or expansion action, and cannot perform multi-step reasoning in the mind like human experts.

[0032] (3) The system cannot adapt to query complexity, and high-complexity queries face a sharp drop in accuracy. xBOM queries in aerospace manufacturing can be categorized by complexity into four levels: simple retrieval of single-part information, filtering with multiple conditions, cross-view association, cross-flight comparison and association analysis, inference involving validity range, and compliance verification. Existing systems can only meet the needs of low-complexity queries, but when query complexity is high, query quality drops drastically. When a query involves multiple related dimensions, such as simultaneously involving flight number, configuration, process route, and supplier, the LLM context window is filled with a large amount of metadata, compressing the effective inference space and increasing the error rate of generated SQL.

[0033] The problem stems from the fact that existing solutions lack a mechanism for evaluating and routing query complexity. All queries are processed uniformly, lacking the adaptive capability of "complexity grading - strategy adaptation".

[0034] (4) Lack of cross-validation and intermediate result transmission control leads to wasted computing power and error propagation. In queries involving the fusion of multi-source BOM data, such as the joint analysis of MBOM, SBOM, ERP inventory data, and MES work-in-process data, existing solutions usually directly convert the query into a single large SQL or LLM single call, lacking control in the following aspects: First, the intermediate node set of the intermediate results shown in the figure and the intermediate mapping relationship of the view alignment are passed down without any verification. If there is a deviation in the early steps, the subsequent steps will continue to calculate on the basis of the error, and the final result is unreliable; Second, in the scenario of large model call, the erroneous results cause users to need to repeatedly correct prompts and regenerate, and a lot of computing power is consumed on invalid iterations; Third, there is a lack of consistency verification mechanism in the multi-source result fusion stage, and conflicts between different data sources, such as the inconsistency between the inventory shown in ERP and the work-in-process quantity shown in MES, cannot be automatically detected and reported.

[0035] The above analysis reveals that existing general data analysis methods typically assume that the data is a relational table or general knowledge text, and that queries employ single-round exact matching or semantic retrieval. However, the characteristics of aviation xBOM data, including hierarchical graph structures, multi-dimensional validity rules, multi-view heterogeneous semantics, and multi-source temporal associations, fundamentally contradict this assumption. Therefore, the agent collaboration employed in existing query schemes remains a "general query process" rather than "xBOM domain reasoning logic," failing to fundamentally address the accuracy and reliability issues of xBOM queries.

[0036] This invention addresses the problem that existing general query methods cannot adapt to the query requirements of aviation xBOM data by constructing a multi-agent collaborative query method for aviation xBOM data.

[0037] like Figure 1This is a flowchart illustrating the overall processing flow of the collaborative query method in this invention. It takes user natural language queries as input and uses an xBOM knowledge graph containing EBOM / MBOM / SBOM / VCBOM multi-view nodes, parent-child assembly relationships, supplier associations, validity attributes, process relationships, and work-in-process status information as the underlying data foundation. The overall process revolves around "multi-agent collaborative orchestration + skill reuse + human-machine confirmation gating." Specifically, the input query is first evaluated for complexity and dynamically routed. Then, the intent parsing agent automatically decomposes the query task and constructs a task dependency graph. Each sub-task query is executed by a corresponding dedicated agent scheduling atomic tools. Human-machine collaborative confirmation is set at three key gates during execution. The query results are output in an interpretable manner after multi-source fusion, and high-frequency query patterns are automatically precipitated as reusable query skills.

[0038] In this embodiment of the invention, an established aviation xBOM knowledge graph is used as the underlying data base and the data foundation for multi-agent collaborative queries. This knowledge graph consists of the following node types: (1) Material node: Represents parts, components, and finished products, and has attributes such as material code, name, version, and material type; (2) View node: Represents different BOM views such as EBOM, MBOM, SBOM, VCBOM, etc., and has attributes such as view type and view version; (3) Validity node: Represents the validity constraint entity such as configuration baseline, effective flight range, effective date range, etc., and has attributes such as applicable aircraft type, flight range, effective start and end date; (4) Supplier node: Represents the supplier entity and has attributes such as supplier name, qualification type, qualification validity period, and historical quality records; (5) Process node: Represents process, process route, work station, etc., and has attributes such as process number, process name, process parameters, and work-in-process status; (6) Document Node: Represents the technical documents associated with materials or views, including engineering drawings, process specifications, airworthiness directives, quality inspection standards, etc., and has attributes such as document number, document name, version, release date, and applicable aircraft model. This node is connected to material nodes and view nodes through associated document edges, supporting query scenarios that require document traceability, such as querying airworthiness directives associated with a certain part; (7) Change Node: Represents an Engineering Change Package (ECP / ECO), and has attributes such as change number, change type, change reason, release date, and applicable configuration scope. This node is connected to the material node and validity node through the "Change Impact" edge, supporting change impact analysis scenarios such as "analyzing the impact of a change package on work-in-process shelves"; (8) Flight Node: Represents a specific aircraft flight and has attributes such as flight number, production status, delivery date, and aircraft type. This node is connected to the validity node and process node through the flight applicable edge, supporting precise flight-level queries such as the part version currently used for a certain flight.

[0039] The edge types of knowledge graphs include parent-child assembly relationships, view mapping relationships, validity constraint relationships, supply relationships, process operation relationships, work-in-process status associations, associated documents, change impacts, and shelf applicability.

[0040] Aviation xBOM data is constantly changing. To ensure the timeliness of query results, a change data capture component monitors the data change logs of upstream PLM / ERP / MES systems, parses change event types, and synchronously updates the corresponding nodes and edges in the knowledge graph according to preset mapping rules. A transactional update strategy is employed to ensure that changes to multiple tables within the same change package take effect atomically in the knowledge graph. For complex changes that cannot be automatically mapped, the system generates a pending task, prompting the data administrator for manual intervention and confirmation before the changes take effect.

[0041] To implement the multi-agent collaborative query method of this invention, this invention proposes a multi-agent collaborative query system for aerospace manufacturing xBOM, comprising: The query complexity assessment and dynamic routing module receives user natural language queries, extracts query complexity feature vectors, calculates a comprehensive complexity score, and dynamically routes query tasks to different query processing modes. Intent Resolution Agent (IPA): As the core of the system's pre-inference, it is responsible for understanding the user's query intent, decomposing it into sub-tasks, and constructing a task dependency graph; Multi-agent execution layer: It includes three dedicated agents—Structured Navigation Agent (SNA), Validity Verification Agent (EVA), and Compliance Arbitration Agent (CA). Each dedicated agent has specific tool invocation capabilities and decision-making permissions. Human-machine collaborative confirmation gating: Manual confirmation steps are set at the three key decision points of the query process, including intent confirmation gating, entity disambiguation confirmation gating, and key result confirmation gating; Skills database: Stores automated skills with high-frequency query patterns, including skills registration, matching and reuse mechanisms; Multi-source result fusion engine: performs consistency verification and fusion of query results from different views, different data sources, and different tools.

[0042] Based on the aforementioned multi-agent collaborative query system, referring to Figure 1 The multi-agent collaborative query method for aerospace manufacturing xBOM according to embodiments of the present invention includes the following steps: S1. Query Complexity Evaluation and Dynamic Route Allocation After a user enters a natural language query, the system first performs a query complexity evaluation. The complexity evaluation feature vector used to evaluate query complexity includes the following dimensions: (1) Entity quantity dimension: The number of named entities involved in the query, such as part number, order number, component model, supplier name, etc. |E|; (2) Constraint type dimension: The number of types of validity constraints involved in the query, such as configuration baseline, effective date, flight range, structural constraints (such as BOM level depth), and cross-view constraints (such as the number of view pairs to be associated) |C|; (3) Inference depth dimension: This mainly refers to the graph traversal depth inferred from the query verbs. For example, "tracing back / looking up" indicates bottom-up traversal, "expanding" indicates top-down traversal, "compare / difference" indicates cross-view alignment, and "apply / cover" indicates validity range inference. The inference depth |D| is estimated through semantic analysis of the query verbs using LLM.

[0043] (4) Data source quantity dimension: The number of data sources |S| that need to be associated in the query, including internal nodes of the xBOM graph, external ERP system, MES system, etc.

[0044] The query complexity score is represented as follows: S_complex=w1·E_norm+ w2·C_norm+ w3·D_norm+ w4·S_norm; Where w1, w2, w3, and w4 are empirical weights and w1 + w2 + w3 + w4 = 1, the scores for different data dimensions are assigned by the model and the range is [0,1]; E_norm, C_norm, D_norm, and S_norm are the normalized values ​​of |E|, |C|, |D|, and |S|, respectively.

[0045] The quantification methods for the values ​​of each dimension are as follows: The entity quantity dimension extracts entities such as part number, order number, component type, and supplier name from the query through the named entity recognition model, counts the entity quantity |E|, and normalizes it to the interval [0,1]. The normalization formula is E_norm = min(|E| / E_max, 1), where E_max is the preset maximum number of entities. The constraint type dimension classifies queries using a constraint type classifier, outputting the occurrence of four types of labels: validity constraints, structural constraints, cross-view constraints, and compliance constraints. It counts the number of constraint types |C| and normalizes it to the interval [0,1]. The normalization formula is C_norm =min(|C| / C_max, 1), where C_max is the preset maximum number of constraint types. The reasoning depth dimension uses LLM to perform semantic analysis on query verbs, dividing the reasoning depth into four levels: Level 0 is no-graph traversal, such as querying the attribute of a part; Level 1 is single-step traversal, such as querying the direct parent of a part; Level 2 is multi-step traversal, such as tracing the complete assembly chain of a part; Level 3 is cross-view multi-step traversal + reasoning, such as comparing the difference between EBOM and MBOM under baseline B, and normalizing the level values ​​to the [0,1] interval. The normalization formula is D_norm =min(|D| / D_max, 1), where D_max is the preset maximum value. The number of data sources required for the query is statistically analyzed, and the number of data sources |S| is normalized to the interval [0,1]. The normalization formula is S_norm = min(|S| / S_max, 1), where S_max is the preset maximum number of data sources.

[0046] The query complexity is divided into four levels based on the rating, and the query task is routed to different dedicated agents for processing according to the evaluation rating results: (1) Simple query (S_complex<0.3): Single entity single view query, directly routed to the Structure Navigation Agent (SNA), and completed in one step using the knowledge graph node query tool.

[0047] (2) Conditional filtering query (0.3≤S_complex<0.5): Multiple conditions are filtered but no cross-view is required. The route is routed to the Structure Navigation Agent (SNA) and the Validation Agent (EVA) for collaborative processing. The former performs structure filtering and the latter performs validity filtering.

[0048] (3) Association analysis query (0.5≤S_complex<0.8): Involves cross-view association or multi-step reasoning, which is routed to the Structural Navigation Agent (SNA), Validity Verification Agent (EVA) and Compliance Arbitration Agent (CA) for collaborative processing, constructing a dependency graph and arranging the execution order.

[0049] (4) Reasoning query (S_complex≥0.8): Involves complex reasoning such as configuration baseline inference and compliance verification, which is routed to multi-agent collaboration and introduces human feedback at intermediate nodes.

[0050] In some embodiments, query complexity can be evaluated using a rule-based evaluation method based on multi-dimensional feature weighted scoring. For example: 1) A machine learning classifier-based evaluation method; the query complexity evaluation is modeled as a multi-classification problem (simple / conditional filtering / association analysis / reasoning), using pre-trained models such as BERT to encode the query text, and outputting the complexity category through a Softmax classifier. 2) A rule-based decision tree evaluation method; a series of if-else rules, such as "query contains more than two part numbers → complexity ≥ medium," are manually defined to progressively determine the complexity level.

[0051] S2. Query intent parsing and automatic task decomposition The query intent is parsed and the task is automatically decomposed based on the Intent Parsing Intelligent Agent (IPA), including: Query intent understanding: Parsing user natural language queries into structured intent descriptions, including query objectives, query constraints, and query types; Subtask decomposition: Decompose complex queries into several subtasks, each subtask corresponding to an executable atomic operation or a simple combination of operations; Dependency graph construction: A directed acyclic graph (DAG) is built for each subtask, marking the data dependencies between them. For example, if the output of subtask A is the input of subtask B, then there is a dependency edge from A to B. Parallel regions are marked in the dependency graph, allowing subtasks without dependencies to execute concurrently. Tool Mapping: Each subtask is mapped to a corresponding dedicated agent and atomic tool. IPA maintains a tool description library, where each atomic tool includes a name, description, input parameter type, output result type, and applicable scenario. The most suitable atomic tool is selected through semantic matching.

[0052] S3, multi-agent cooperative execution and atomic tool invocation Three dedicated intelligent agents are employed to invoke corresponding atomic tools to execute subtasks; including: (1) Structured Navigation Agent (SNA) This tool is used for structured queries of aerospace xBOMs, including part location, BOM expansion, upstream tracing, and cross-view comparison; the included atomic tools implement the following functions respectively: Node location: Locate all occurrences of a specified part number in the xBOM knowledge graph and return the node ID, the view it belongs to, and the node attributes.

[0053] Structure filtering: Filters a specified set of nodes by structure, including node type filtering, view filtering, and hierarchy filtering.

[0054] Traverse upwards: Starting from the specified node, trace upwards along the BOM parent relationship to return all parent nodes and their assembly relationships within the specified depth.

[0055] Traverse downwards: Expand downwards from the specified node along the BOM sub-relationships, returning all child nodes and their assembly relationships within the specified depth.

[0056] Cross-view comparison: Compares the differences between different views of EBOM / MBOM / SBOM / VCBOM for a specified node, and returns the differences in BOM data between the views.

[0057] (2) Validity verification agent (EVA) This dimension is used for validity management of airline xBOMs, ensuring that query results are valid within the correct configuration, correct flight number, and correct time window; the included atomic tools implement the following functions respectively: Effective range detection: Analyze the effective range of nodes based on the specified configuration baseline, including the list of applicable flights and the effective date range.

[0058] Validity Conflict Check: Detects validity conflicts between two node sets, such as different effective ranges for the same part under different configurations. A node set refers to the collection of candidate nodes output by the structural navigation agent after node localization, structural filtering, upward traversal, downward traversal, or cross-view comparison, or the collection of sub-result nodes from different BOM views, different configuration baselines, different data sources, or different traversal paths before multi-source result fusion. Each node represents an instance of a material under a certain BOM view, version, configuration baseline, and data source, and includes at least node ID, view type, version, configuration baseline, effective rack range, and / or effective date range. For example, when querying the effective version of part WS-2024-A7 in the MBOM for rack 145, SNA node localization can obtain node set A: WS-2024-A7, MBOM-V2.1, configuration baseline B, effective racks 120-150; node set B: WS-2024-A7, MBOM-V2.2, configuration baseline C, effective racks 140-170. Flight 145 falls within the valid range of both node set A and node set B, but corresponds to different MBOM versions. EVA determines that there is a validity conflict between the two node sets and decides according to the data source priority or transfers the decision to the key result confirmation gate for manual adjudication.

[0059] Expanding Validity Analysis: Based on the validity constraints propagated through the BOM structure, when expanding downwards, the valid range of a sub-component is the intersection of the parent component's valid range and the sub-component's valid range. If the intersection is empty, the sub-component is filtered. When tracing upwards, the valid range of the parent component is the union of the valid ranges of all sub-components to determine which flight and / or date ranges the parent component is valid for. For example: Parent component P has valid flight ranges 100-200, sub-components C1 have valid ranges 120-150, and C2 has valid ranges 160-180. When expanding downwards from P, C1, after taking the intersection, becomes 120-150, and C2 becomes 160-180; if C3 is 220-250, and the intersection is empty, then C3 is filtered. When tracing upwards from C1 and C2, the valid range of P is the union of 120-150 and 160-180.

[0060] In the aerospace manufacturing industry, the "validity" of an aerospace xBOM is not simply a timestamp or status field, but a logical system with strict reasoning rules. Specifically, it manifests as follows: a) Nested structure of multidimensional validity space The validity of an aerospace component is defined by the following dimensions: Configuration baselines: such as "Baseline B" (applicable to sorties 100-200) and "Baseline C" (applicable to sorties 201-300). There is an "effective binding" relationship between part versions and configuration baselines; different versions of the same part number can belong to different baselines.

[0061] Flight range: such as "flights SN120 to SN180". Flight ranges can be continuous or discontinuous (such as "SN120-150 and SN160-170"), and flight ranges may overlap or alternate between different configuration baselines.

[0062] Effective date: e.g., "Effective from 2025-01-01". There may be cross-validation logic between date constraints and flight range (e.g., "Effective on flights delivered after January 2025 for a certain configuration").

[0063] Engineering Change Package (ECP / ECO): The approval date and applicable configuration scope of a change package directly affect the validity status of the materials affected. An ECP may involve different version changes for multiple materials simultaneously.

[0064] The four dimensions mentioned above are not independent and parallel, but rather mutually constrained by specific domain rules. For example, "the effective sortie range of a certain part under baseline B = the sortie range of baseline B ∩ the sorties covered by the effective date of the part version".

[0065] b) Propagation rules of validity constraints in the BOM structure The aerospace xBOM is a tree-like assembly structure, and validity constraints follow a specific propagation logic between parent and child nodes: When expanding from top to bottom, to query all valid child components under a given component: the valid scope of a child component must intersect with the valid scope of its parent component. That is, if the parent component is valid for a certain flight, the child component will only be included in the expanded result if it is also valid for that flight.

[0066] When tracing from bottom to top, query all valid parent components of a given part: the valid range of a parent component is the union of the valid ranges of all its child components. That is, when a part is used on a certain flight, its direct parent component must have at least one version valid on the same flight.

[0067] When mapping across views, the mapping relationship between EBOM node and MBOM node is also valid. For example, the same EBOM material may be mapped to different MBOM materials or different MBOM process versions in different shelf ranges.

[0068] Such intersection / union propagation rules cannot be achieved through simple attribute equality queries and require a dedicated inference engine. While general-purpose LLM solutions have inference capabilities, they lack deterministic encapsulation of the aforementioned propagation rules. Each query relies on the LLM's "temporary understanding" to generate propagation logic, resulting in unstable output.

[0069] c) Heterogeneity of validity markers among multiple data sources In PLM, the validity marker uses "configuration baseline + version effective number" as the key; in MES, the validity marker uses "aircraft type + batch + process version" as the key; and in the supplier BOM, the validity marker uses "contract number + delivery batch" as the key.

[0070] The validity expressions for the same material may be completely different in different data sources, and the authority of each data source varies.

[0071] To address the complexity of BOM data, EVA's design no longer treats validity as a filterable attribute, but rather models it as a reasonable constraint system. EVA internally encapsulates the following three layers of capabilities: 1) Multidimensional validity representation layer (knowledge encoding) EVA maintains a validity rules table that explicitly encodes aviation-related validity terms into a computable data structure.

[0072] For example, terms such as “baseline B”, “flight 120-150”, and “effective from 2025-01-01” will be encoded as fields that can be intersected / unified, such as configuration baseline, flight range, and effective date; examples of validity rules are shown in Table 1.

[0073] Table 1 Validity Rules

[0074] EVA's multidimensional validity representation layer explicitly models the validity dimension as independent constraint nodes, connected to material nodes and view nodes via "valid constraint" edges. This allows EVA to perform set operations between constraints, rather than simple string matching. For example, during modeling, "baseline B" and "flights 120-150" are built as independent constraint nodes and connected to material / view nodes via "valid constraint" edges. During set operations, the intersection and union of the flight or date ranges of the constraint nodes are calculated. For example, material node M is associated with three constraint nodes: C1 (configuration baseline B, flights 100-200), C2 (flight range 120-150), and C3 (effective date from 2025-01-01). EVA extracts the intersection of the flight ranges of C1 and C2 to obtain 120-150, and then intersects it with the date range of C3 to obtain that M is valid under baseline B, after 2025-01-01, and within flights 120-150. If the query is for flight 145, it is considered valid; if material M2 is associated with C1 and C4 (flights 160-180) and the intersection is empty, then M2 is invalid for flight 145. This multidimensional validity representation layer changes validity checking from string matching to constraint set operations, enabling EVA to automatically validate, propagate, and adjudicate, with a definitive result.

[0075] 2) Validity Propagation Engine (Inference Execution) EVA has three built-in propagation operators, corresponding to the three types of propagation rules mentioned above: It should be noted that the three propagation operators are internal calculation logic of EVA and are not used as separate external atomic tools; externally, they are selected and called by the "Expand Validity Analysis" atomic tool based on the query type. Specifically, the downward propagation operator is called when expanding downwards, the upward propagation operator is called when tracing upwards, and the cross-view mapping propagation operator is called when mapping across views. For example, parent component P has 100-200 valid flights, child component C1 has 120-150 valid flights, C2 has 160-180 valid flights, and C3 has 220-250 valid flights. When expanding P downwards, the intersection of C1 is 120-150, the intersection of C2 is 160-180, and the intersection of C3 is empty and filtered. When tracing C1 and C2 upwards, the effective range of the parent item P is the union of 120-150 and 160-180. If the effective range of EBOM material E is 100-200, and the mapping rule specifies that the shipment 120-150 is mapped to MBOM material M-V2.1, then the effective range of M-V2.1 output by cross-view mapping propagation is 120-150.

[0076] Downward propagation: Input the parent scope R_parent and the child scope R_child, and output R_parent∩R_child; if the intersection is empty, the child is automatically filtered in the current query; Upward propagation: Input the set of valid ranges of all child components {R_child1, R_child2, ...}, output the union of the valid ranges of all child components R_union, and obtain the valid range of the parent component. The valid range of the parent component is dynamically calculated through this union. Cross-view mapping propagation: Input the valid range of materials in the source view and the valid conditions in the mapping table, and output the valid range of materials in the target view.

[0077] In this system, the source view is the BOM view from which the mapping begins, such as EBOM; the target view is the BOM view to which the mapping reaches, such as MBOM; the mapping relationship table stores the mapping relationship between materials in the source view and materials in the target view, as well as the valid conditions for the mapping. For example, EBOM material E is mapped to MBOM material M-V2.1 in shipments 120-150, and to M-V2.2 in shipments 151-200. Cross-view mapping propagation means: valid range of source view material ∩ valid conditions in the mapping relationship table = valid range of target view material.

[0078] These three propagation operators generate execution validity reasoning in a deterministic manner, rather than relying on LLM, ensuring that the same query produces consistent results when executed at different times.

[0079] The reasoning process of EVA is as follows: Receive the node set output by the Structured Navigation Agent (SNA) → Extract the effective range of each node → Select the propagation operator according to the query type (expand / trace / compare) → Output the filtered effective node set.

[0080] 3) Data source priority arbiter When validity information from different data sources conflicts, such as PLM showing that a part is valid in shipment SN150, but MES showing that the process version corresponding to that part in shipment SN150 is obsolete, EVA does not adopt a simple "voting" or "averaging of all confidence levels" strategy. Instead, it makes a graded decision based on the data type according to the following rules: For structural relationship data, parent-child assembly, view mapping: the authority of PLM / EBOM map > the authority of MES / MBOM map; Regarding the validity related to the status of being in operation, whether a certain process is still applicable to a certain flight: the authority of MES / MBOM > the authority of PLM; Regarding the validity of supplier delivery, whether a supplier is still authorized to supply a certain part: the authority of the supplier portal data > the authority of the PLM.

[0081] If the conflict cannot be resolved after the above adjudication, EVA marks the conflict as "pending manual adjudication" and submits it along with the query results to the key result confirmation gate, where the user makes the final decision. This "hierarchical credibility matrix" design directly addresses the conflict detection requirements in multi-source heterogeneous scenarios of aviation xBOM.

[0082] Atomic tools are the functional interfaces that EVA can call externally, while the three-layer capability is the implementation module that supports these atomic tools within EVA. The multidimensional validity representation layer provides valid data, the validity propagation engine implements validity analysis, and the data source priority adjudicator is used for validity conflict checking.

[0083] (3) Compliance Arbitration Agent (CA) This tool is used to handle compliance requirements in aerospace manufacturing, ensuring that query results meet airworthiness, quality, and process specifications. The included atomic tools implement the following functions: Certification status confirmation: Query the airworthiness certification status of the node, such as AS9100 certification and airworthiness approval label.

[0084] In-process status confirmation: Query the in-process status of the node under the current process route, such as processing, awaiting inspection, inspected, or rework.

[0085] Supplier compliance verification: Check the compliance of suppliers at each node, the validity of their qualifications, and their records of historical quality issues.

[0086] Impact Confirmation of Changes: Analyze the impact of a specified engineering change package on the node and its upstream and downstream components.

[0087] Collaboration between dedicated intelligent agents is achieved through information exchange via a shared query workspace. The query workspace stores the global state of the current query, including: a list of executed subtasks and their results, a list of unexecuted subtasks, the current progress of the task dependency graph, and pending human-machine confirmations.

[0088] The Intent Resolution Agent (IPA) acts as an orchestrator, continuously reading the workspace state and scheduling the next executable subtask to the corresponding agent based on the task dependency graph. After the agent completes its execution, it writes the result back to the workspace. The IPA then updates the dependency graph's progress state based on the result and schedules the next subtask.

[0089] The metadata format for each tool in the tool library is as follows: { "tool_id": "EVA_scope_check", "tool_name": "Scope of Validation Detection", "description": "Resolves the valid range of nodes based on the specified configuration baseline", "input": { "node_ids": "Array <string>(List of node IDs) "config_baseline": "String (configuration baseline number, can be empty to indicate currently valid)" }, "output": { "effective_ranges": "Array<{node_id, valid_aircraft_range, valid_date_range}>" }, "applicable_scenarios": ["Validity Filtering", "Configuration Comparison", "Change Impact Analysis"], "timeout_ms": 5000, "retry_limit": 3 } S4, Key Node Human-Machine Collaborative Confirmation Gating The human-computer interaction in existing query methods is "single-point," with intent confirmation or concept clarification only occurring during the query input stage. Subsequent processes are executed completely in a black box, and any errors in the intermediate steps are transmitted unchecked to the final output. Users can only re-initiate the query after seeing the final erroneous result, forming an invalid loop of "generation-failure-regeneration."

[0090] In this embodiment of the invention, a three-layer gating mechanism is used to upgrade "single-point interaction" to "three-layer progressive interception defense line". Gating is set at the three key decision points of the query process. Each layer is responsible for intercepting errors of different types and severity levels, forming a complete protection chain of "input verification → process verification → output verification".

[0091] like Figure 1 As shown, the triggering conditions, confirmation content, and fallback behaviors for each gating are defined below; details are as follows: (1) Intent to confirm gate control At the starting point of query execution, ensure that the system understands the user's intent in the correct direction to avoid "going astray from the beginning." Incorrect intent understanding is the most costly error in a multi-agent system. Once an incorrect intent is decomposed into subtasks and started, the consumed computing power and time cannot be recovered.

[0092] Triggering conditions: Query complexity score S_complex ≥ 0.5; queries involving association analysis or higher have a high risk of ambiguous intent. If the intent resolution confidence of the intent resolution agent (IPA) is <0.85, the LLM is uncertain about its own resolution results.

[0093] The system displays the following parsing summary to the user in the form of structured cards, as shown in Table 2.

[0094] Table 2 Intent Analysis Summary Table

[0095] User operation options: (1) Confirm, the system enters the execution phase; (2) Modify, the user corrects any field in the parsed summary and submits, the IPA replans the execution path based on the corrected structured description; (3) Reject, the user believes that the parsing is completely wrong and re-enters the query.

[0096] The first layer of gating serves to intercept errors before execution costs occur. Existing intent verification schemes only verify the paraphrasing of natural language at the user input level, while this gating requires IPA to explicitly convert natural language into structured query elements, forcing users to verify item by item "which elements the system truly understands" before actual execution, significantly reducing the probability of "going off track" due to LLM parsing bias.

[0097] (2) Entity disambiguation confirmation gate During query execution, when the system encounters ambiguity that requires domain knowledge to resolve, it promptly requests manual adjudication to avoid all subsequent subtasks being executed ineffectively on the wrong entity due to "misidentification of the object".

[0098] Ambiguity is particularly prominent in aviation xBOMs. Due to the generic / borrowed part mechanism, the same part number may appear in multiple BOM views at the same time, and the attributes may be completely different.

[0099] Triggering conditions: The part number involved in the query has ≥2 instances in different views or different versions in the xBOM knowledge graph; Alternatively, if the part name / model involved in the query has ≥2 matching candidates with a semantic similarity > 0.85, for example, if the system finds at least two candidate entities for the part name / model in the query, and both candidate entities have a semantic similarity greater than 0.85 with the query object, making it impossible to automatically determine a unique object, then the entity disambiguation confirmation gate is triggered. For example, if the query "WS-2024-A7" finds two candidate entities "WS-2024-A7" and "WS-2024-A7-01", and the semantic similarity of "WS-2024-A7" is 0.98 while that of "WS-2024-A7-01" is 0.90, both of which have a similarity greater than 0.85, then the entity disambiguation confirmation gate needs to be triggered for manual confirmation.

[0100] The system presents the disambiguation recommendations in the form of a comparison table, as shown in Table 3.

[0101] Table 3 Comparison of Candidate Instances

[0102] It should be noted that the candidate instance table output by the entity disambiguation confirmation gating is not the final query result, but an intermediate disambiguation suggestion for manual confirmation. After manual confirmation, the system uses the selected instance as the input for subsequent structure navigation and validity verification to continue executing the query task.

[0103] For example, a user might query: "Query the MBOM process information and supplier qualifications for part WS-2024-A7 in flight 128." Trigger gating: The system query found that WS-2024-A7 has multiple instances in the knowledge graph: MBOM-V2.1 (flights 120-150), MBOM-V2.2 (flights 130-160), and EBOM-V1.3 (flights 100-180), which meets the triggering condition of "≥2 different view or version instances", triggering entity disambiguation confirmation gating; Output disambiguation suggestions: The system displays Table 2, listing candidate instances, their views, and key attribute differences; Manual confirmation: If the user sees that flight number 128 falls within the 120-150 range of MBOM-V2.1, they can select Instance 1; or select other candidates; or cancel and resubmit the query after adding the flight number and version number. Subsequent execution: The system uses the selected MBOM-V2.1 instance as input for SNA and EVA, and continues to perform process decomposition and supplier compliance checks, finally outputting the query results.

[0104] User operation options: (1) The system continues to execute according to the recommended match; (2) Select other candidates, and the user manually selects the correct instance in the table; (3) Cancel and modify the query, and the user adds more precise constraints such as adding flight number and version number and then resubmits.

[0105] The second layer of gating serves to intercept erroneous entities before they enter subsequent subtasks. Existing query solutions typically employ strategies such as "taking the first matching result" or "letting the LLM determine the most likely option" when handling entity ambiguity. Both of these strategies are unreliable in the aviation xBOM scenario. The existence of multiple versions of generic / borrowed parts is not a model "illusion" but a real data characteristic that must be decided by human engineers who have a grasp of the actual flight context.

[0106] This gating ensures that subsequent SNA graph traversal and EVA validity propagation are always performed on the correct set of entities by explicitly bringing decision points forward, thus avoiding wasted computing power due to "misidentification of objects".

[0107] (3) Key Result Confirmation Gating Before the final output of the query results, a final "quality check" is performed to ensure the completeness and consistency of the output. This layer is designed to meet the high compliance requirements of aircraft manufacturing. If the query results are used for airworthiness review or quality traceability, and the results omit key flights or contain incorrect compliance conclusions, the output will contain serious errors.

[0108] Triggering conditions: The query involves compliance conclusions, such as "Is the supplier's AS9100 qualification valid?" or "Does the part meet the requirements of Airworthiness Directive AD-2025-XXX?" The query results contain safety-critical components, and the system's pre-set list of safety-critical components is matched. Conflicts were detected during the multi-source data fusion process and could not be automatically resolved.

[0109] The system displays the following three evaluation results to the user, as shown in Table 4.

[0110] Table 4 Evaluation Results

[0111] User operation options: (1) Confirm output, the system returns the final result; (2) Request supplementary query, the user specifies the data source to be supplemented or the constraints to be relaxed / tightened, the system performs incremental query; (3) Abort query, the user thinks the result is unreliable, abandons the query and records the reason.

[0112] The third-layer gating mechanism serves to complete a final round of verification before the final conclusion is accepted by the user. Existing query solutions typically only perform simple set merging or field concatenation during the multi-source fusion stage, lacking automatic detection of xBOM-specific conflict types.

[0113] This gating system enforces the display of three indicators: coverage, integrity, and conflict detection. This ensures that users have a clear understanding of the "bottom line" of the results before accepting them, thus preventing erroneous conclusions from being used as facts.

[0114] S5, Query Failure-Driven Adaptive Redirection like Figure 1 As shown, when a subtask fails, such as a tool call timeout, a knowledge graph query returning an empty result, or a validity constraint having no matching node, this embodiment of the invention does not directly return an error to the user, but instead initiates an adaptive redirection mechanism, including: (1) Failure type diagnosis: Analyze the reasons for failure. a. The constraints are too strict, and the filtering conditions result in empty results; b. The tool is unavailable. The required tool does not have a corresponding API in the skill list; c. Data is missing. The node in the knowledge graph is missing the required attribute; d. Logical error. The dependency relationship judgment is wrong, which leads to abnormal return results.

[0115] (2) Strategy replacement: Select an alternative strategy based on the failure type. Automatically relax constraints when they are too strict; select a similar alternative tool or create a new tool when the tool is unavailable; supplement data from related data sources when data is missing; rerun IPA to adjust the task dependency graph when there is a logical error.

[0116] (3) Maximum number of retries: Each subtask can be redirected a maximum of 3 times. If the number of retries is exceeded, it will be marked as an infeasible subtask. This will not affect the execution of other subtasks. The final output will include partial results and the missing parts will be marked.

[0117] S6. Multi-source result fusion and interpretable output Multi-source result fusion enables consistency verification and fusion of query results from different views, agents, and data sources: (1) Consistency check: Conflict detection is performed on each sub-result set before fusion, including part number conflicts such as inconsistent material codes for the same part in different views, and validity conflicts such as inconsistent effective scope of the same part in different configurations. Here, consistency check is a cross-check between sub-results across views, data sources, and intelligent agents. It checks whether the descriptions of the same part, the same sortie, and the same validity in the output results are consistent, which is different from the location and validity checks within a single view or single data source mentioned above.

[0118] (2) Integration Strategy: For conflicting results, a credibility matrix categorized by data type is used for adjudication, rather than a single global priority. Specifically: for structural relationship data, the credibility ranking is xBOM map > ERP system; for in-process data, the credibility ranking is MES system > xBOM map; for inventory / supply data, the credibility ranking is ERP system > supplier portal; for compliance qualification data, the credibility ranking is supplier portal > xBOM map. If the conflict cannot be resolved after the above adjudication, the conflict information is recorded and reported to the user along with the results, and a final decision is made manually at the key result confirmation gate.

[0119] For example, there is a structural relationship conflict: MBOM shows that part A's parent is P1, while ERP shows it as P2; by clicking "xBOM Knowledge Graph > ERP System", the MBOM's P1 is accepted. In-process status conflict: MES shows part A as "in processing" in shipment 128, while xBOM shows "inspected"; click "MES System > xBOM" and accept the "in processing" status from MES. Inventory / supply conflict: The ERP system shows 100 units in stock, while the supplier portal shows 80 units; by clicking "ERP System > Supplier Portal", the 100 units shown in the ERP system are accepted. Compliance qualification conflict: The supplier portal shows that AS9100 is valid, but the xBOM diagram shows that it has expired; click "Supplier Portal > xBOM Diagram" to accept the valid supplier portal qualification.

[0120] If the conflict cannot be eliminated by following the above rules, for example, if the two authoritative data sources still conflict, then the conflict is recorded and a key result confirmation gate is triggered based on the result, which is then manually adjudicated.

[0121] (3) Interpretable output: The final output includes not only the query results data, but also: a. Query path; each subtask, the tools used, and the filtering conditions executed; b. Decision basis; the reasoning process and basis for key decision points.

[0122] S7. Automatic accumulation and matching reuse of query skills This invention employs a mechanism for the automatic accumulation and reuse of query skills, enabling high-frequency query patterns to be automatically accumulated and accelerating subsequent similar queries; including: (1) Automatic generation of skill drafts When a query strategy, comprising intent structure, dependency graph structure, and tool call sequence, is successfully executed more than N times within a time window of M days, it is automatically identified as a high-frequency query, and a query skill draft is generated. The intent structure refers to the structured representation of the query intent, including the query target, involved views, validity constraints, and association analysis type. The tool call sequence refers to the order in which atomic tools are invoked when executing subtasks according to the dependency graph. For example, a high-frequency query is "Query the MBOM process information and supplier qualifications for part WS-2024-A7 in shipment 128". Its intent structure is: {Query target: part WS-2024-A7; View: MBOM; Validity constraint: shipment 128; Association analysis type: downstream process expansion + supplier compliance check}. Its dependency graph structure is: T1 locate part → T2 validity filtering → T3 expand process downwards, and T1 → T4 supplier compliance check. Its tool call sequence is: SNA.node location → EVA.scope detection → SNA.downward traversal → CA.supplier compliance confirmation. When the strategy is successfully executed more than 5 times within 30 days, the system automatically identifies it as a high-frequency query, generates a query skill draft, and parameterizes the specific values, such as "querying the MBOM process information and supplier qualifications of part {part_id} in shipment {sn}".

[0123] The query skill draft includes: a. query intent template, including configurable parameter placeholders; b. execution task dependency graph, including fixed tool call sequence; c. description of applicable scenarios; d. average execution time.

[0124] (2) Administrator approves entry into the database Once a skill draft is reviewed by the administrator, it is officially added to the database. The administrator can view the skill's execution history, confirm the accuracy of the query intent template, adjust the meaning of parameter placeholders, and once approved, the skill becomes a "published skill," visible and selectable by users.

[0125] (3) Skill matching and rapid execution When a new query is input, the system first searches the skill library. Semantic similarity is calculated as follows: the new query and the query intent template are encoded into semantic vectors, and cosine similarity is calculated. Simultaneously, the parameter slots of the new query are extracted and compared with the parameter placeholders of the query intent template for matching degree evaluation. The overall similarity is calculated as: 0.7 × semantic vector cosine similarity + 0.3 × parameter slot matching degree. When the overall similarity is ≥ 0.85, the skill is directly matched, skipping the task decomposition stage of IPA. When the overall similarity is between 0.6 and 0.85, the matched skill is used as a reference template, and IPA performs rapid adaptation based on this template. When the overall similarity is < 0.6, the normal multi-agent collaborative query process is followed.

[0126] The following detailed description of the query process implemented by the method of the present invention is based on a specific embodiment.

[0127] A process engineer in the final assembly workshop of an aircraft manufacturing company discovered an assembly interference problem with a wing rib part, serial number WS-2024-A7, while assembling the 128th aircraft of model XX. The engineer needs to find out which aircraft batches this part is currently in use.

[0128] The query process is as follows: Step 1, User Input: Enter "I am processing aircraft number 128. I would like to query which aircraft are using part WS-2024-A7 and trace its MBOM process information, while also confirming its supplier qualifications." on the query interface.

[0129] Step 2, Query Complexity Assessment: The system extracts features: |E|=0.96, including part number WS-2024-A7, flight number, MBOM; |C|=0.92, including manufacturing status, MBOM process, supplier qualifications; D=0.92, downstream expansion + upstream traceability; |S|=0.48, including xBOM map, MES system, supplier portal; calculate S_complex=0.96×0.25+0.92×0.25+0.92×0.25+0.48×0.25=0.82, which is determined to be a reasoning query, and routed to the multi-agent collaborative mode.

[0130] Step 3, Intent Confirmation Gating Execution: Since S_complex=0.82≥0.8, intent confirmation gating is triggered. The system displays the parsing results: Target=Part WS-2024-A7; Involved View=MBOM; Validity Constraint=In-Process Status; Association Analysis=Downstream Deployment + Supplier Compliance Check.

[0131] Step 4, Intent Resolution and Task Decomposition: IPA decomposes the query into 4 sub-tasks: T1 = Locate all instances of WS-2024-A7 in the MBOM; T2 = Filter the in-process status of the T1 results, retaining only the currently in-process shipments; T3 = Expand the downstream process of the MBOM on the filtered results; T4 = Perform supplier compliance checks on WS-2024-A7.

[0132] Generate a task dependency graph: T1→T2→T3, T1→T4.

[0133] Step 5: Entity Disambiguation Confirmation and Gating Execution: The system detects that WS-2024-A7 also appears in the EBOM, triggering gating feedback. The system displays the attribute differences between the two versions; for example, the MBOM version adds process route attributes, while the EBOM version lacks process parameters. Engineer confirmation is pending.

[0134] Step 6: Multi-agent collaborative execution: IPA routes T1 to SNA, and SNA calls the node location tool, which returns multiple instances: Instance 1, MBOM-V2.1, flights 120-150; Instance 2, MBOM-V2.2, flights 130-160; Instance 3, MBOM-V2.3, flights 140-170.

[0135] After T1 is completed, IPA schedules T2 and T4 simultaneously according to the dependency graph: T2 is routed to EVA, and T4 is routed to CA, and the two are executed in parallel.

[0136] EVA invokes the scope detection tool, filters based on the user-specified 128th instance, retains instance 1, and excludes instances 2 and 3.

[0137] SNA calls the downward traversal tool and returns the MBOM process chain: Process 010 blanking → Process 020 forming → Process 030 drilling → Process 040 polishing.

[0138] The CA invokes the certification status verification tool and the supplier compliance verification tool, and returns the validity period of the AS9100 qualification of supplier "XX Company", which is currently valid.

[0139] Step 7, Multi-source result fusion: The fusion engine merges the results of T2's work-in-process shelf 128, the results of T3's MBOM process chain, and the valid results of T4's supplier qualifications.

[0140] Step 8, Key Result Confirmation Gating: The system displays 100% coverage of results, including all relevant MBOM versions checked; 100% data source integrity, including xBOM, MES, and supplier portals; and 0 conflict detections. Awaiting confirmation.

[0141] Step 9, Return Interpretable Output: The system returns structured results. Part WS-2024-A7 is currently in production. MBOM process chain: Process 010 Blanking → Process 020 Forming → Process 030 Drilling → Process 040 Grinding; Supplier "XX Company" AS9100 qualification validity period 2024-01-01 to 2026-12-31; Query path and decision basis are attached.

[0142] Step 10, Skill Accumulation: If the system determines that the query pattern has been executed more than 5 times by the user in the past 30 days, it automatically generates a draft query skill and submits it to the administrator for review. After review and inclusion in the database, subsequent queries with the same intent will directly match the skill.

[0143] On the other hand, the present invention also provides an electronic device, comprising: Processor; and Memory for storing the executable instructions of the processor; The processor is configured to execute a multi-agent collaborative query method for aerospace manufacturing xBOM by executing the executable instructions.

[0144] On the other hand, the present invention also provides a computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements a multi-agent collaborative query method for aerospace manufacturing xBOM.

[0145] The above description is merely a preferred embodiment of the present invention and is not intended to limit the present invention in any way. Any simple modifications or equivalent changes made to the above embodiments based on the technical essence of the present invention shall fall within the protection scope of the present invention.< / string>

Claims

1. A multi-agent collaborative query method for xBOM in aerospace manufacturing, characterized in that, Includes the following steps: The system acquires user natural language queries, evaluates their complexity, and routes the query tasks to different dedicated intelligent agents for processing based on the evaluation results. These dedicated intelligent agents include a structure navigation agent, a validity verification agent, and a compliance arbitration agent. The structure navigation agent includes atomic tools for node localization, structure filtering, upward traversal, downward traversal, and cross-view comparison. The validity verification agent includes atomic tools for effective scope detection, validity conflict checking, and validity analysis. During validity analysis, it calls the corresponding propagation operator based on the query type to perform downward expansion, upward tracing, and cross-view mapping validity analysis, and outputs the filtered set of valid nodes. The compliance arbitration agent includes atomic tools for certification status confirmation, in-process status confirmation, supplier compliance confirmation, and change impact confirmation. The query intent is parsed, the query task is decomposed into subtasks, each subtask corresponds to an executable atomic operation, a task dependency graph is constructed based on the dependencies between subtasks, and the subtasks are mapped to the atomic tools of each professional agent. Match the corresponding atomic tools to the subtasks and execute the subtasks one by one according to the dependencies between them, and output the query results.

2. The multi-agent collaborative query method for aerospace manufacturing xBOM according to claim 1, characterized in that, The node positioning is to locate all occurrences of a specified part number in the xBOM knowledge graph and return the node ID, the view it belongs to, and the node attributes. The xBOM knowledge graph includes nodes and edges. The node represents an instance of a material under a certain BOM view, version, configuration baseline, and data source. The structural filtering is to perform structural dimension filtering on a specified set of nodes, including node type filtering, view filtering, and hierarchy filtering; the specified set of nodes is the set of candidate nodes output through node positioning. The upward traversal is to trace upwards from the specified node along the BOM parent relationship and return all parent nodes and their assembly relationships within the specified depth. The downward traversal is to expand downwards from the specified node along the BOM sub-relationships and return all child nodes and their assembly relationships within the specified depth. The cross-view comparison involves comparing the differences between specified nodes in different types of BOM views and returning the differences in BOM data between the views.

3. The multi-agent collaborative query method for aerospace manufacturing xBOM according to claim 1, characterized in that, The effective range detection is based on the effective range of the nodes analyzed according to the specified configuration baseline, including the list of applicable flights and the effective date range; The validity conflict check is used to detect validity conflicts between two node sets; The node set is a collection of candidate nodes from different BOM views, different configuration baselines, different data sources, or different traversal paths. The expansion validity analysis is based on the validity constraints of the BOM structure. When expanding downwards, the valid range of a sub-component is the intersection of the valid range of the parent component and the valid range of the sub-component. If the intersection is empty, the sub-component is filtered. When tracing upwards, the valid range of the parent component is the union of the valid ranges of all sub-components to determine which flights and / or date ranges the parent component is valid for.

4. The multi-agent collaborative query method for aerospace manufacturing xBOM according to claim 1 or 3, characterized in that, The propagation operator includes: Downward propagation operator: Input the valid range of the parent component and the valid range of the child component, and output the intersection of the valid ranges of the parent component and the valid range of the child component; if the intersection is empty, the child component is automatically filtered in the current query; Uppropagation operator: Input the set of valid ranges of all child components, output the union of the valid ranges of all child components, and obtain the valid range of the parent component; Cross-view mapping propagation operator: Input the valid range of materials in the source view and the valid conditions in the mapping table, and output the valid range of materials in the target view.

5. The multi-agent collaborative query method for aerospace manufacturing xBOM according to claim 1, characterized in that, The validity verification agent includes a multi-dimensional validity representation layer for explicitly encoding aviation-related validity terms into a computable data structure.

6. The multi-agent collaborative query method for aerospace manufacturing xBOM according to claim 1, characterized in that, The validity verification agent includes a data source priority arbitrator, which is used to decide the data source to be accepted based on the data type and according to the set priority rules when validity information from different data sources conflicts.

7. The multi-agent collaborative query method for aerospace manufacturing xBOM according to claim 1, characterized in that, The query complexity determines whether to trigger the intent confirmation gate. Once the intent confirmation gate is triggered, the intent parsing result is output, and the corresponding processing method is selected manually based on the intent parsing result. And / or, during the query execution process, determine whether to trigger the entity disambiguation confirmation gate based on the set entity triggering conditions. After the entity disambiguation confirmation gate is triggered, output the query information of all entities that are semantically similar to the queried entity object, and manually select the corresponding processing method based on the query information. And / or, before outputting the final query results, determine whether to trigger the key result confirmation gate based on the set key result trigger conditions. After the key result confirmation gate is triggered, output the evaluation results for the query situation, and manually select the corresponding processing method based on the evaluation results.

8. The multi-agent collaborative query method for aerospace manufacturing xBOM according to claim 1, characterized in that, When a subtask fails, analyze the reason for the failure and output the failure type based on the reason. Select an alternative execution strategy based on the failure type and re-execute the subtask.

9. The multi-agent collaborative query method for aerospace manufacturing xBOM according to claim 1, characterized in that, When a query strategy is successfully executed more than a set number of times within a set time window, a query skill draft is generated based on the query strategy, forming a query skill library that can be directly called by users; the query strategy includes intent structure, dependency graph structure and tool call sequence.

10. A multi-agent collaborative query system for xBOM in aerospace manufacturing, characterized in that, The multi-agent collaborative query method for aerospace manufacturing xBOM as described in any one of claims 1-9 includes: The query complexity assessment and dynamic routing module is used to assess the complexity of user natural language queries and dynamically route query tasks to different query processing modes. The intent parsing agent is used to parse the user's query intent, decompose the query task into subtasks and build a task dependency graph. The multi-agent execution layer includes a structural navigation agent, a validity verification agent, and a compliance arbitration agent; Human-assisted confirmation gating includes intent confirmation gating, entity disambiguation confirmation gating, and key result confirmation gating set at different decision points in the query process; The multi-source result fusion engine is used to perform consistency checks and fusion on query results from different views, different data sources, and different atomic tools.

11. An electronic device, characterized in that, include: processor; as well as Memory for storing the executable instructions of the processor; The processor is configured to execute the multi-agent collaborative query method for aerospace manufacturing xBOM as described in any one of claims 1-9 by executing the executable instructions.

12. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the multi-agent collaborative query method for aerospace manufacturing xBOM as described in any one of claims 1-9.

Images