Executable ontology automatic construction and compilation method for agent system

Abstract

The application provides an executable ontology automatic construction and compilation method for an agent system, wherein multi-source task documents for a target business scenario are acquired, and ontology extraction processing is performed thereon to extract ontology constituent elements and determine an ontology extraction result accordingly; an ontology classification base is constructed according to the ontology extraction result; action semantic construction processing is performed on the ontology classification base to generate an action semantic chain; and the action semantic chain is fused with the ontology classification base to generate an agent task execution module. Compared with a traditional static configuration scheme, the method effectively associates business knowledge classification and dynamic execution logic, has high environmental perception responsiveness and fast task chain driving speed.

Description

Technical Field

[0001] This application relates to the fields of knowledge engineering and artificial intelligence technology, and more specifically, to an executable ontology automatic construction and compilation method for intelligent agent systems. Background Technology

[0002] With the development of artificial intelligence technology, intelligent agent systems are being used more and more widely in complex scenarios. The daily operation of intelligent agent systems involves perceiving the external environment and executing task-related behaviors. System modeling for target business scenarios involves processing multi-source task documents and extracting structured knowledge elements. The underlying control system supports intelligent agents in responding to changes in business scenarios by reconstructing domain knowledge logic.

[0003] In existing intelligent agent ontology construction schemes, the industry typically employs a static semantic graph transformation architecture to generate the system's logical model. This scheme first establishes a static text processing platform. The text processing platform extracts isolated entity dictionaries from documents based on manually defined keyword rules. Subsequently, the system uses a preset static mapping template to transform the dictionary into a static relational graph. Finally, the system generates a stateless, time-series static configuration script according to the fixed node hierarchy of the static relational graph. The control system ultimately distributes the aforementioned static script to the front-end execution end.

[0004] However, this static semantic graph transformation scheme has significant technical drawbacks. Due to the strong temporal dependencies in task execution within business scenarios, the static extraction model struggles to identify environmental constraints before and after action execution. This results in the generated system logic model lacking a description of the sequential dependencies between task actions. Furthermore, static configuration scripts cannot couple domain concept classification with dynamic execution logic. The execution end cannot adaptively implement chained responses based on task state changes. This leads to low adaptability of the intelligent agent system for task processing in complex environments, failing to meet the technical requirements of highly flexible, dynamic task-driven execution in the target business scenario. Summary of the Invention

[0005] This application provides an executable ontology automatic construction and compilation method for intelligent agent systems, so as to at least alleviate the above-mentioned technical problems.

[0006] An automatic method for constructing and compiling an executable ontology for intelligent agent systems includes: Step 1: Obtain multi-source task documents for the target business scenario, perform ontology extraction processing on them to extract ontology components and determine the ontology extraction result accordingly. The ontology components are used to characterize the conceptual expression of equipment category, environmental state category and task action category, the attribute expression of equipment operation characteristics, environmental state characteristics and task action constraints, and the relationship expression of the association between equipment objects and environmental state objects, task action objects and equipment objects, and task action objects and environmental state objects. The ontology extraction result is used to characterize the ontology extraction content of the target business scenario composed of the ontology components. Step 2: Based on the ontology extraction results, construct an ontology classification framework; Step 3: Perform action semantic construction processing on the ontology classification base to generate an action semantic chain, which is used to represent the sequential dependency relationship between multiple action execution units; Step 4: Integrate the action semantic chain with the ontology classification base to generate an agent task execution module. The agent task execution module is used to drive the executable code units to perform chained execution according to the action semantic chain.

[0007] Optionally, step 1 includes: Semantic segmentation is performed on the multi-source task documents to obtain segmented document entries; Semantic indexing is performed on the segmented document entries to identify domain semantic elements; Based on the semantic elements of the domain, semantic indexing results are generated, and targeted extraction is performed on the semantic indexing results to extract ontology constituent elements.

[0008] Optionally, the domain semantic elements include: equipment objects representing equipment entities, environmental state objects representing external situation and operating conditions, task action objects representing task handling behavior, and constraint descriptions representing task triggering restrictions.

[0009] Optionally, step 2 includes: The ontology extraction results are subjected to concept attribution determination to obtain concept attribution determination results, which include: distinguishing equipment category concepts, environmental state category concepts, and task action category concepts; Based on the concept attribution determination results, concept attribution results are generated, which include equipment category concepts, environmental state category concepts, and task action category concepts. The concept attribution results are used to determine the attribute attribution to obtain the attribute attribution results, which include the attribute expressions corresponding to the equipment category concept, the environmental state category concept, and the task action category concept, respectively. Based on the attribute attribution determination results, an ontology classification framework is constructed.

[0010] Optionally, based on the attribute attribution determination results, an ontology classification framework is constructed, including: Based on the attribute attribution determination results, attribute attribution results are generated. The attribute attribution results include the expression of equipment operation characteristic attributes corresponding to the equipment category concept, the expression of environmental state characteristic attributes corresponding to the environmental state category concept, and the expression of task action constraint attributes corresponding to the task action category concept. The attribute attribution results are subjected to relationship attribution determination to obtain relationship attribution determination results, which include distinguishing the state association relationship between equipment objects and environmental state objects, the action association relationship between task action objects and equipment objects, and the constraint association relationship between task action objects and environmental state objects. Based on the relationship attribution determination result, a relationship attribution result is generated, which includes state association, function association, and constraint association. The relationship attribution results are hierarchically merged to determine the concept hierarchy relationship, which includes the hierarchical relationship between equipment category concepts, environmental state category concepts, and task action category concepts. Based on the aforementioned conceptual hierarchy, an ontology classification framework is constructed.

[0011] Optionally, based on the aforementioned conceptual hierarchy, an ontology classification framework is constructed, including: Based on the aforementioned concept hierarchy, a concept hierarchy result is generated, which is used to characterize the hierarchical merging structure of equipment category concepts, environmental state category concepts, and task action category concepts. The conceptual hierarchy results are linked and organized to determine the linkage relationships, which include the linkage relationships between the conceptual hierarchy results and the state association relationships, the action association relationships, and the constraint association relationships; Based on the aforementioned connection relationships, a connection relationship result is generated. The connection relationship result is used to characterize the corresponding connection structure between the concept hierarchy result and the state association relationship, the action association relationship, and the constraint association relationship. Based on the relationship connection results, an ontology classification base is constructed.

[0012] Optionally, step 3 includes: Action extraction is performed on the ontology classification base to identify the action description content corresponding to the task execution process; Based on the action description content, generate action description entries; Constraint parsing is performed on the action description entries to identify the environmental state object constraints that the task action object needs to satisfy before execution; Based on the constraints of the environmental state object, generate prerequisite constraint entries; Dependency identification is performed on the aforementioned prerequisite constraint items to determine the equipment objects and environment state objects that the task action object depends on during execution; An action semantic chain is generated based on the equipment object and the environment state object.

[0013] Optionally, based on the equipment object and the environment state object, an action semantic chain is generated, including: Based on the equipment object and the environment state object, generate input dependency entries; The input dependency entries are parsed to identify the task handling results directly generated after the task action object is executed; Based on the task processing results, output result entries are generated; The output entries are parsed for state changes to identify changes in the environmental state objects caused by the execution of the task action object. Based on the changes in the environmental state object, effect change entries are generated; An action semantic chain is generated based on the aforementioned premise constraint entries, the aforementioned input dependency entries, the aforementioned output result entries, and the aforementioned effect change entries.

[0014] Optionally, based on the premise constraint entries, the input dependency entries, the output result entries, and the effect change entries, an action semantic chain is generated, including: Assemble the premise constraint entry, the input dependency entry, the output result entry, and the effect change entry into the corresponding action description entry; Based on the assembled action description entries, action execution units are formed; Dependency orchestration is performed on the action execution units to determine the sequential dependencies between multiple action execution units; Based on the aforementioned sequential dependency relationship, an action semantic chain is formed.

[0015] Optionally, step 4 includes: Based on the fusion results, an extended ontology expression is formed, which is used to characterize the dynamic execution semantics of the action execution unit after fusion with the classification relationship and the attachment relationship; Based on the extended ontology expression, a task execution module for generating intelligent agents is generated.

[0016] Optionally, based on the extended ontology expression, a generative agent task execution module is generated, including: Based on code generation rules, the extended ontology expression is compiled and mapped to generate code components, which include state verification code, input processing code, result generation code, and state rewriting code. Generate executable code units based on the aforementioned code components; The executable code units are arranged in a chain according to the action semantic chain; Based on the chained orchestration results, an agent task execution module is generated.

[0017] Technical advantages of the technical solution provided in this application This application presents an executable ontology automatic construction and compilation method for intelligent agent systems. Addressing the technical shortcomings of traditional static solutions in identifying state constraints, this method extracts ontology components encompassing multiple dimensions, including equipment, environmental states, and task actions. Based on this, an ontology classification foundation is constructed. This resolves the issues of isolated entity extraction and missing attribute associations in traditional solutions. Compared to the structural limitations of traditional solutions relying on static mapping templates, this method comprehensively represents the association between equipment objects and task action objects. This method lays a solid foundation for the classification foundation of subsequent dynamic logic generation. The logical relevance of business knowledge extraction and the completeness of system state representation are both significantly improved.

[0018] Based on the constructed ontology classification framework, this application performs action semantic construction processing. Based on this, an action semantic chain is generated. This overcomes the technical deficiency of traditional static extraction methods that lack characterization of the sequential dependencies of task actions. Traditional solutions present static relationships based on a fixed node hierarchy. This application deeply analyzes the sequential dependencies between multiple action execution units. Compared to the lack of temporal state information in traditional static scripts, the action semantic chain generated by this solution can accurately map the state transition paths during task execution. The temporal rigor and dynamic applicability of the agent task modeling dimension are significantly enhanced.

[0019] This method further integrates action semantic chains and ontology classification frameworks. This application generates an agent task execution module. This solves the technical challenge of traditional static configuration scripts being unable to couple domain concept classification with dynamic execution logic. Static scripts in traditional system architectures cannot support end-to-end adaptive driving. This application utilizes the agent task execution module to drive executable code units according to the logical constraints of action semantic chains. The execution units then perform adaptive chained execution. Compared to the traditional discrete scheduling mode requiring manual intervention, this fusion mechanism empowers the agent to execute coherent tasks based on changes in environmental state. The agent's front-end agility in responding to business changes and the efficiency of chained collaboration demonstrate a high level of technical sophistication. Attached Figure Description

[0020] Figure 1 This application provides an embodiment of an executable ontology automatic construction and compilation method for intelligent agent systems.

[0021] Figure 2 This application provides an executable ontology automatic construction and compilation device for intelligent agent systems.

[0022] Figure 3 This is an electronic device according to an embodiment of the present application. Detailed Implementation

[0023] Figure 1 This application provides an embodiment of an executable ontology automatic construction and compilation method for intelligent agent systems, such as... Figure 1 As shown, an executable ontology automatic construction and compilation method for intelligent agent systems includes: Step 1: Obtain multi-source task documents for the target business scenario, perform ontology extraction processing on them to extract ontology components and determine the ontology extraction result accordingly. The ontology components are used to characterize the conceptual expression of equipment category, environmental state category and task action category, the attribute expression of equipment operation characteristics, environmental state characteristics and task action constraints, and the relationship expression of the association between equipment objects and environmental state objects, task action objects and equipment objects, and task action objects and environmental state objects. The ontology extraction result is used to characterize the ontology extraction content of the target business scenario composed of the ontology components. Step 2: Based on the ontology extraction results, construct an ontology classification framework; Step 3: Perform action semantic construction processing on the ontology classification base to generate an action semantic chain, which is used to represent the sequential dependency relationship between multiple action execution units; Step 4: Integrate the action semantic chain with the ontology classification base to generate an agent task execution module. The agent task execution module is used to drive the executable code units to perform chained execution according to the action semantic chain.

[0024] Optionally, step 1 includes: Semantic segmentation is performed on the multi-source task documents to obtain segmented document entries; Semantic indexing is performed on the segmented document entries to identify domain semantic elements; Based on the semantic elements of the domain, semantic indexing results are generated, and targeted extraction is performed on the semantic indexing results to extract ontology constituent elements.

[0025] Preferably, a specific implementation of the semantic segmentation processing of multi-source task documents in step 1 is as follows. After the multi-source task documents are aggregated, adaptive segmentation processing oriented towards semantic integrity is first performed on each multi-source task document. This adaptive segmentation processing is not a simple mechanical cutting according to a fixed number of characters or a fixed number of lines, but rather uses a pre-trained domain semantic boundary detection module to scan the multi-source task documents segment by segment. The domain semantic boundary detection module calculates the semantic coherence score between adjacent text blocks. When a topic switch, operation stage transition, or description object change is detected, the semantic coherence score will drop. At this time, the domain semantic boundary detection module inserts a segmentation mark at the breakpoint where the score is lower than the adaptive coherence threshold. For example, when parsing an aircraft maintenance manual, the domain semantic boundary detection module can automatically identify the switching points between different semantic topic paragraphs such as "fault phenomenon description", "isolation procedure", "maintenance steps" and "functional check", thereby dividing the aircraft maintenance manual into multiple semantically independent and complete segmented document entries. Each segmented document entry revolves around a single operational intent or knowledge topic, avoiding the forced separation of operational descriptions that have causal or temporal relationships.

[0026] Preferably, after obtaining segmented document entries, semantic indexing is performed on each segmented document entry to identify domain semantic elements. This semantic indexing process does not employ a single model, but rather a multi-dimensional semantic indexing framework composed of multiple annotation modules working in parallel. Specifically, segmented document entries are synchronously distributed to entity annotation modules, state annotation modules, action annotation modules, and constraint annotation modules. The entity annotation module incorporates a named entity recognition submodule fine-tuned from the domain corpus, specifically designed to identify and label equipment objects representing physical or logical entities from the segmented document entries, such as engines, missile fuses, and radar transceiver components, and assigns a unique entity identifier to each identified equipment object. The state annotation module utilizes a state pattern matching rule set based on dependency parsing to extract environmental state objects representing system operating conditions or environmental situations from the segmented document entries, such as engine temperature, weapon safety status, and target lock indication, and records the name and expected value type of the environmental state object. The action annotation module, through a combination of verb dictionary matching and semantic role annotation techniques, locates task action objects representing disposal behaviors or operational processes from segmented document entries, such as launch, self-detection, unlocking, and power switching, and extracts the names of the actions. The constraint annotation module, through a combination of template matching and prompt-driven semantic reasoning, identifies constraint descriptions that are bound to the task action objects. These constraint descriptions, in natural language, specify the state conditions that must be met before the task action object can be executed, such as "only when the hydraulic pressure is greater than a preset threshold" or "after the fire control radar has completed stable target tracking." The processing results of these four annotation modules for the same segmented document entry are aligned based on the starting character offset and the unique entity identifier, forming a structured semantic indexing result.

[0027] Preferably, after the semantic indexing results are generated, they contain explicit tags for equipment objects, environmental state objects, task action objects, and constraint descriptions. To further extract ontology components from the semantic indexing results, this application instantiates an element extraction pipeline driven by capability questions. This pipeline first automatically generates a set of capability questions oriented towards the target business scenario. The logic for automatically generating capability questions is as follows: iterate through each pair of task action objects and their bound constraint descriptions in the semantic indexing results, constructing capability questions that inquire about the prerequisites for action execution. For example, for the task action object "launch" and the constraint description "radar locks onto target," the capability question "Before the launch action is executed, has the radar completed target lock and established a stable tracking state?" is automatically generated. At the same time, based on the co-occurrence relationship between equipment objects and environmental state objects, capability questions inquiring about equipment state attributes are automatically generated. For example, if the co-occurrence of the equipment object "engine" and the environmental state object "temperature" is parsed, the capability question "What is the current temperature state of the engine?" is automatically generated. These automatically generated capability questions are compiled into a capability question set, which constitutes a precise questioning of the knowledge contained in the segmented document entries, clarifying the key semantic elements that must be extracted from the segmented document entries.

[0028] Preferably, after obtaining the capability question set, the feature extraction pipeline performs attention-guided targeted feature extraction on the semantic indexing results for each capability question in the set. This targeted extraction is centered on an extraction decoder with a cross-attention mechanism. The extraction decoder uses the text embedding representation corresponding to the capability question as the query vector, and the embedding representations of all labeled equipment objects, environment state objects, task action objects, and constraint descriptions in the semantic indexing results as the query key and value vectors. By calculating the similarity between the query vector and each key vector, the extraction decoder can accurately focus attention weights on the tokenized semantic units most relevant to answering the capability question. For example, when processing the capability question "Before the launch action is executed, has the radar completed target lock?", the extraction decoder's attention distribution will be highly concentrated on the embedding representation regions corresponding to the task action object "launch", the constraint description "radar locks target", and the related environment state objects "radar operating mode" and "target tracking identifier". Based on the ranking of attention weights, the extraction decoder extracts the tokenized semantic units corresponding to high weights, aggregates and formats them into a candidate ontology component.

[0029] Preferably, the candidate ontology components generated by the aforementioned attention-guided element-oriented extraction process are fed into a concept, attribute, and relation decoupling module based on rule constraints and semantic type inference. This module first determines whether a candidate ontology component belongs to a concept expression, attribute expression, or relation expression based on its internal syntactic structure (e.g., subject-verb-object, attributive-head, adverbial-head) and semantic role label. If a candidate ontology component is marked as an equipment object in the semantic indexing results and syntactically functions as a subject or object, the module classifies it as an equipment category concept; if marked as an environment state object, it is classified as an environment state category concept; if marked as a task action object, it is classified as a task action category concept. If a candidate ontology component describes a quantifiable feature or state of a concept, it is classified as an attribute expression; for example, the temperature value related to the environment state object "engine temperature" is extracted as an equipment operation feature attribute expression. If a candidate ontology component connects two or more concepts or attributes, such as semantically expressing a "detection" relationship between the equipment object "radar" and the environmental state object "target," the three-element decoupling module will assign it a relation expression type and further subdivide it through syntactic path analysis into state relationships expressing the association between the equipment object and the environmental state object, or action relationships between the task action object and the equipment object, or constraint relationships between the task action object and the environmental state object. After this three-element decoupling process, the originally semantically intertwined semantic indexing results are transformed into clearly categorized and clearly categorized concept expressions, attribute expressions, and relation expressions. These concept expressions, attribute expressions, and relation expressions together constitute the ontology extraction result representing the target business scenario knowledge system. Each element in this ontology extraction result has its origin in the original document and is supported by extraction logic driven by capability issues as its semantic source.

[0030] Preferably, the domain semantic boundary detection module is structurally composed of three stacked layers: a text embedding layer, a semantic coherence calculation layer, and a boundary determination layer, which together complete the adaptive semantic segmentation processing of multi-source task documents.

[0031] Preferably, the text embedding layer serves as the first structural layer of the domain semantic boundary detection module, used to convert the original text fragments in the input multi-source task document into a dense vector representation containing domain semantics. This text embedding layer internally includes a word embedding sublayer and a domain feature projection sublayer. The word embedding sublayer employs the first-stage encoder of a pre-trained language model further trained on aerospace and military domain corpora. This first-stage encoder receives a text block consisting of several consecutive lexical units as the processing object, performs context semantic encoding on each lexical unit in the text block, outputs the context semantic vector corresponding to each lexical unit, and performs mean pooling on the context semantic vectors of all lexical units to obtain a text block embedding vector that can represent the overall semantics of the text block. The domain feature projection sublayer receives the text block embedding vectors output by the word embedding sublayer as its processing object. It performs an affine transformation on these vectors and a pre-stored domain feature matrix. The row vectors in the pre-stored matrix correspond to the distribution centers of known typical semantic topics within the aerospace and military domains in the embedding space. The affine transformation results in a bias correction of the text block embedding vectors towards the most relevant domain semantic topic centers, yielding a domain-enhanced embedding vector with a domain semantic bias. The text embedding layer traverses the multi-source task documents using a non-overlapping or preset-step sliding window. Each slide outputs the domain-enhanced embedding vector of the text block covered by that window, forming a sequence of domain-enhanced embedding vectors.

[0032] Preferably, the semantic coherence calculation layer receives the domain-enhanced embedding vector sequence output by the text embedding layer as the processing object, and uses it to quantitatively evaluate the semantic coherence between two adjacent domain-enhanced embedding vectors in the sequence. This semantic coherence calculation layer internally deploys a designed coherence dual-head metric module, which includes a semantic cosine metric head and a topic transition metric head. The semantic cosine metric head receives two adjacent domain-enhanced embedding vectors and calculates the cosine similarity between these two vectors. The cosine similarity value ranges from -1 to +1. When the cosine similarity is close to +1, it indicates that the semantics of the two text blocks are relatively coherent; when the cosine similarity is close to -1, it indicates that there is a significant semantic conflict or abrupt change. The topic transition metric also receives two adjacent domain-enhanced embedding vectors, but concatenates them into a single concatenated vector. This concatenated vector is then input into a pre-trained binary perceptron, which outputs a topic transition probability score. This score represents the probability that two consecutive text blocks belong to different semantic topics. The coherence dual-head metric module weights and fuses the cosine similarity output from the semantic cosine metric with the topic transition probability score output from the topic transition metric. The weights for this weighting are pre-determined based on performance evaluation on the domain validation set. The fused result is a comprehensive semantic coherence score. The semantic coherence calculation layer performs the above processing on each pair of adjacent domain-enhanced embedding vectors in the domain-enhanced embedding vector sequence, outputting a global coherence score sequence composed of all comprehensive semantic coherence scores arranged in order.

[0033] Preferably, the boundary decision layer receives the global coherence score sequence output by the semantic coherence calculation layer as the processing object. Based on the changing trend and magnitude of the comprehensive semantic coherence score in the global coherence score sequence, it determines whether to insert segmentation markers at corresponding positions, thereby dividing the multi-source task document into multiple segmented document entries. This boundary decision layer internally includes an adaptive threshold calculation module and a segmentation decision module. The adaptive threshold calculation module receives the global coherence score sequence, performs statistical distribution analysis on it, calculates the mean and standard deviation of the global coherence score sequence, and defines the adaptive coherence threshold as the mean minus a certain number of standard deviations. This adaptive coherence threshold can automatically adjust according to the overall semantic coherence of the multi-source task document. When the semantic topic switching within the document is frequent, the adaptive coherence threshold will automatically decrease to maintain a reasonable segmentation granularity; when the semantics within the document are relatively coherent, the adaptive coherence threshold will automatically increase to avoid over-segmentation. The segmentation decision module receives a global coherence score sequence and an adaptive coherence threshold. It iterates through each comprehensive semantic coherence score in the global coherence score sequence, comparing each score with the adaptive coherence threshold. When a comprehensive semantic coherence score is lower than the threshold, the segmentation decision module inserts a segmentation marker at the breakpoint between adjacent text blocks corresponding to that score. If multiple consecutive comprehensive semantic coherence scores are all lower than the adaptive coherence threshold, the module inserts a segmentation marker at the point where the semantic coherence score reaches a local minimum, ignoring other points below the threshold to avoid inserting multiple redundant segmentation markers within the same topic transition area. After the boundary determination layer completes processing, the multi-source task document is segmented into several text fragments by all segmentation markers, each text fragment being a segmented document entry.

[0034] In summary, the three structural layers work together to realize the overall function of the domain semantic boundary detection module. The domain-enhanced embedding vector sequence output by the text embedding layer serves as the direct input to the semantic coherence calculation layer, and the global coherence score sequence output by the semantic coherence calculation layer serves as the direct input to the boundary determination layer. The three form an end-to-end continuous processing path in data flow. The domain feature projection sublayer in the text embedding layer enhances the alignment between document content and domain semantic topics through bias correction, making the comprehensive semantic coherence score calculated by the subsequent semantic coherence calculation layer highly sensitive to topic switching in the aerospace and military fields. The dual-head metric mechanism in the semantic coherence calculation layer combines the ability of cosine similarity to capture subtle changes in semantic direction with the sensitivity of topic shift probability to large jumps in topic boundaries, enabling the output global coherence score sequence to identify gradual boundaries in slow topic evolution and to generate obvious troughs at abrupt topic jumps. The adaptive threshold calculation module in the boundary determination layer enables the segmentation granularity to automatically adapt to different types of multi-source task documents, without setting different threshold parameters for different types of multi-source task documents such as aircraft maintenance manuals, weapon operation specifications, or combat mission instructions. The segmentation decision module avoids fragmented segmentation in single topic transition areas through a local minimum point strategy. In the intelligent support scenario of aviation equipment, when the text content of the aircraft maintenance manual changes from "fault phenomenon description" to "isolation procedure", the semantic distance between the two domain-enhanced embedding vectors output by the text embedding layer will increase significantly. The comprehensive semantic coherence score calculated by the semantic coherence calculation layer will drop below the adaptive coherence threshold. The boundary judgment layer inserts a segmentation mark between the "fault phenomenon description" paragraph and the "isolation procedure" paragraph, thereby dividing the two thematic paragraphs that semantically revolve around fault manifestation and fault troubleshooting logic into two independent segmented document entries.

[0035] Optionally, the domain semantic elements include: equipment objects representing equipment entities, environmental state objects representing external situation and operating conditions, task action objects representing task handling behavior, and constraint descriptions representing task triggering restrictions.

[0036] Preferably, the aforementioned domain semantic elements are explicitly identified and given structured representations during the semantic indexing process of segmented document entries. These domain semantic elements do not exist in isolation, but are collaboratively extracted through four parallel annotation modules in a multi-dimensional semantic indexing framework. Together, they constitute the semantic basis for the subsequent targeted extraction of ontology components. The technical essence of these four types of domain semantic elements and their specific manifestations in the target business scenario of intelligent support for aviation equipment are described below.

[0037] Preferably, the domain semantic elements first include equipment objects that represent equipment entities. These equipment objects correspond to physical or logical entities described in multi-source mission documents that are operated or monitored during maintenance or combat missions. When semantically indexing segmented document entries, the named entity recognition submodule within the entity annotation module, fine-tuned by the domain corpus, identifies the text fragments describing these entities and assigns them a unique entity identifier. In the intelligent support scenario for aviation equipment, equipment objects can specifically encompass the entire aircraft, aircraft subsystems, weapon mounting devices, radar transceiver components, engine units, landing gear assemblies, or flight control computers, etc. For example, taking a description in an aircraft maintenance manual, "Check the turbine inlet temperature of the left engine," the entity annotation module will mark "left engine" as an equipment object and assign it a unique entity identifier, such as "Entity Identifier: Engine Left." Unlike traditional solutions that can only extract isolated entity dictionaries, the equipment objects identified in this application are subsequently used as subjects or objects of state associations and function associations, participating in the construction of relation expressions. This makes the equipment object no longer an isolated word, but rather anchored to a node in the knowledge network.

[0038] Preferably, the domain semantic elements include environmental state objects that represent external situation and operating conditions. These environmental state objects are used to quantitatively or qualitatively describe the internal operating conditions or external environmental situation of the equipment object. They form the basis for determining whether an action can be executed and what changes the action will bring to the world state. When processing segmented document entries, the state annotation module uses a set of state pattern matching rules based on dependency parsing to extract environmental state objects. For example, in the operational mission description of an avionics system, the state annotation module identifies "radar lock indication," "missile safety device status," "current flight altitude," "hydraulic system pressure value," and "target relative position vector" as environmental state objects based on the rule set. This state annotation module not only extracts the names of environmental state objects but also records the expected value type of the environmental state object based on its contextual quantitative modifiers or value descriptions. For example, it determines that the value type of "turbine inlet temperature" is a continuous numerical type, while the value type of "safety device status" is a discrete enumeration type. These environmental state objects then serve as defined evaluation criteria, participating in the subsequent construction of attribute representations and the description of constraints before action execution, providing the agent with basic state variables that can be computed and compared for dynamic state perception.

[0039] Preferably, the domain semantic elements also include task action objects representing task handling behaviors. These task action objects originate from verbal structures describing operational procedures, handling instructions, or task steps in multi-source task documents, defining a purposeful operation that an agent may perform within its operational cycle. When extracting task action objects, the action annotation module combines verb dictionary matching with semantic role annotation technology based on deep semantics. Verb dictionary matching first locates the action trigger words in the text, while semantic role annotation technology further analyzes the core semantic roles carried by these trigger words in the sentence, such as agent and patient. In application scenarios such as weapon operation specifications and combat mission descriptions, the extracted task action objects may include "launch," "lock," "unlock safety," "connect power," "start self-detection," and "execute evasion maneuvers." For example, from the description "the fire control computer loads target parameters into the missile," the action annotation module will use verb dictionary matching to locate the action trigger word "load," and use semantic role annotation technology to identify "fire control computer" as the agent and "target parameters" as the patient, thereby extracting the core action of this knowledge fragment as the task action object "load target parameters." This task action object forms the core of the action execution unit in the subsequent action semantic graph. All constraints, inputs, outputs, and effects related to this action will be organized around this task action object.

[0040] Preferably, the last element in the domain semantic elements is a constraint description representing the task triggering restrictions. This constraint description, embedded in the multi-source task document in natural language, explicitly specifies the state conditions that must be met before the aforementioned task action object can be executed, and is crucial to ensuring the correctness and security of the agent's behavioral logic. The constraint annotation module identifies the constraint description through a combination of template matching and prompt-driven semantic reasoning. The template matching part scans for sentence templates in the text that indicate conditional logic, such as "only when...", "under the condition of satisfying...", and "if...then not allowed"; the prompt-driven semantic reasoning part inputs the text fragment after removing the template tags into a constraint reasoning module based on a large language prompt design, which is prompted to focus on extracting the logical expression of the state constraints. For example, in the mission description text "The launch procedure can only be executed when the fire control radar is in a stable tracking state and the missile safety has been disengaged," the constraint annotation module first identifies the conditional phrase "when...and...only then" through template matching. Then, the constraint inference module parses out two constraint descriptions bound to the mission action object "launch," namely "the fire control radar is in a stable tracking state" and "the missile safety has been disengaged." These constraint descriptions directly provide semantic material for the subsequent generation of preconditions in the action execution unit, enabling the agent to perform runtime verification based on the environment state object before executing the action.

[0041] Preferably, the pre-training process of the domain semantic boundary detection module aims to enable the text embedding layer, semantic coherence calculation layer, and boundary determination layer to collaboratively achieve the optimal parameter state for semantic segmentation tasks within the target domain of aviation and military industry, rather than training the three structural layers as isolated units separately. This pre-training process uses a collected and labeled multi-source document corpus from the aviation and military industry domain as its basic training data. This corpus contains document samples from aircraft maintenance manuals, weapon operating procedures, and operational mission descriptions. Each document sample undergoes segmentation annotation processing; that is, domain experts pre-annotate the positions of standard segmentation markers at various semantic topic switching points within the document sample. These standard segmentation markers are used as supervision signals during the pre-training process.

[0042] Preferably, the pre-training process of the text embedding layer is a key step in enabling the word embedding sublayer and the domain feature projection sublayer to acquire domain semantic expression capabilities. For the word embedding sublayer, a two-stage pre-training strategy is adopted: In the first stage, the first-stage encoder of the pre-trained language model is initialized and trained using a large-scale general corpus to enable it to have basic contextual semantic encoding capabilities; In the second stage, text from a multi-source document corpus in the aerospace and military industry domain is input into the first-stage encoder in the form of a word sequence, and training is continued using a masked language model training task. This masked language model training task randomly masks some words in the input word sequence, requiring the first-stage encoder to predict the original words of the masked words based on the unmasked context words, and update the parameters of the first-stage encoder by minimizing the cross-entropy loss between the predicted words and the real words. After this second stage of training, the word embedding sublayer can capture the collocation rules and sentence features of the aerospace and military industry domain. For the domain feature projection sublayer, the pre-stored domain feature matrix is ​​obtained as follows: First, several representative document fragments are extracted from the multi-source document corpus of the aviation and military industry. These document fragments are then classified according to their semantic topics. The classified semantic topic categories include fault phenomenon description, isolation procedure, maintenance procedure, functional inspection, weapon operation process, and combat mission instruction. Then, for each semantic topic category, the text block embedding vectors of all document fragments belonging to that category are collected. The text block embedding vectors of the same category are then clustered using the mean, and the cluster center vector is taken as the domain semantic topic center vector of that category. Finally, the domain semantic topic center vectors corresponding to all semantic topic categories are arranged in rows to form a pre-stored domain feature matrix. Each row vector of this domain feature matrix corresponds to the distribution center of a domain semantic topic in the embedding space.

[0043] Preferably, the pre-training process of the semantic coherence computation layer aims to enable the semantic cosine metric head and topic transfer metric head in the coherence dual-head metric module to acquire discriminative capabilities for segment boundary detection. The pre-training process first constructs training sample pairs from a multi-source document corpus in the aerospace and military industry domain. The construction method is as follows: traverse each labeled document sample, divide the document sample into multiple standard segment document entries according to the standard segmentation label, and for two adjacent standard segment document entries, extract their domain-enhanced embedding vectors through the text embedding layer. If the content of these two standard segment document entries is identified as belonging to different topic paragraphs under the standard segmentation label, then the topic transfer label is assigned to this pair of domain-enhanced embedding vectors as true; if these two standard segment document entries are two consecutive text blocks randomly extracted from the same topic paragraph, then the topic transfer label is assigned to this pair of domain-enhanced embedding vectors as false. The pre-training of the topic transfer metric uses training sample pairs and their topic transfer labels as supervision signals. The concatenated vector of the two domain augmentation embedding vectors is input into a binary perceptron, and cross-entropy loss is used as the loss function for binary classification training. This enables the topic transfer metric to learn to determine whether consecutive text blocks belong to different semantic topics. The pre-training of the semantic cosine metric does not directly use classification labels but employs a contrastive learning strategy: sample pairs with false topic transfer labels are used as positive pairs, and sample pairs with true topic transfer labels are used as negative pairs. By minimizing the cosine distance between positive pairs and maximizing the cosine distance between negative pairs, the parameters of the domain feature projection sublayer are adjusted, thereby indirectly optimizing the measurement performance of the semantic cosine metric. This contrastive learning strategy enables the semantic cosine metric to produce a continuous response to the gradual evolution of semantic topics, rather than simply outputting a binary judgment.

[0044] Preferably, the pre-training process of the boundary decision layer focuses on matching the adaptive threshold coefficient of the segmentation decision module with the segmentation characteristics of multi-source documents in the aerospace and military industry. The pre-training process selects a batch of complete document samples labeled with standard segmentation tags from a multi-source document corpus in the aerospace and military industry. These complete document samples are sequentially input into the pre-trained text embedding layer and semantic coherence calculation layer to obtain a global coherence score sequence corresponding to each complete document sample. For each global coherence score sequence, the adaptive threshold calculation module in the boundary decision layer first calculates its mean and standard deviation. The segmentation decision module substitutes a preset initial multiple coefficient to calculate an initial adaptive coherence threshold, and uses this initial adaptive coherence threshold to perform segmentation decisions on the global coherence score sequence, obtaining a pre-segmentation result. The segmentation tag positions inserted in the pre-segmentation result are compared with the standard segmentation tag positions of the complete document sample, and segmentation accuracy, segmentation recall, and segmentation harmonic score are calculated as segmentation performance evaluation indicators. The pre-training process uses grid search or Bayesian optimization to find the multiplier coefficient that maximizes the average harmonic score of all document samples within a preset range of multiplier coefficient values ​​(e.g., between one and three standard deviations). This multiplier coefficient is then used as the standard deviation multiplier coefficient in the adaptive coherence threshold calculation formula in the boundary decision layer. After this pre-training, this multiplier coefficient enables the adaptive coherence threshold to achieve a relatively balanced segmentation effect across multiple document types in the aerospace and military fields.

[0045] In summary, after each of the aforementioned structural layers completes its pre-training process, the domain semantic boundary detection module undergoes an end-to-end joint fine-tuning phase. This phase treats the text embedding layer, semantic coherence calculation layer, and boundary determination layer as a whole. Using document samples with standard segmentation tags from a multi-source document corpus in the aerospace and military industry domain, and with the segmentation harmonic score as the optimization objective, it performs small-scale joint updates to the adjustable parameters in all structural layers. This end-to-end joint fine-tuning enables the text embedding layer to consider the preferences of subsequent coherence calculations when extracting domain-enhanced embedding vectors, and allows the semantic coherence calculation layer to adapt to the threshold judgment logic of the boundary determination layer when generating the comprehensive semantic coherence score. Thus, the three structural layers achieve globally better segmentation consistency through collaboration. After the above pre-training and joint fine-tuning, the domain semantic boundary detection module can achieve adaptive semantic segmentation with high accuracy and high recall for multi-source task documents such as aircraft maintenance manuals, weapon operation specifications and combat mission instructions in the aviation and military fields without setting threshold parameters for each type of multi-source task document. This provides semantically complete and clearly defined segmented document entries for subsequent semantic indexing processing.

[0046] Optionally, step 2 includes: The ontology extraction results are subjected to concept attribution determination to obtain concept attribution determination results, which include: distinguishing equipment category concepts, environmental state category concepts, and task action category concepts; Based on the concept attribution determination results, concept attribution results are generated, which include equipment category concepts, environmental state category concepts, and task action category concepts. The concept attribution results are used to determine the attribute attribution to obtain the attribute attribution results, which include the attribute expressions corresponding to the equipment category concept, the environmental state category concept, and the task action category concept, respectively. Based on the attribute attribution determination results, an ontology classification framework is constructed.

[0047] Preferably, the specific processing method for determining the concept affiliation of the ontology extraction results in step 2 is as follows: the ontology extraction results output in step 1 are used as the processing object and input into a concept affiliation determination framework composed of a multi-model classification voting mechanism. This concept affiliation determination framework includes three parallel determination models: a hierarchical classifier based on a bidirectional encoding representation transformer, a hierarchical relationship prediction model based on a graph neural network, and a zero-shot inference module based on a large language model. These three determination models evaluate the affiliation of each concept expression in the ontology extraction results from different semantic dimensions. Specifically, the hierarchical classifier based on the bidirectional encoding representation transformer extracts the contextual semantic features of the concept expression and calculates its similarity with a pre-constructed domain concept hierarchy prototype; the hierarchical relationship prediction model based on the graph neural network constructs a graph of the concept expression and the initially formed concept nodes, and determines its hierarchical position in the entire concept topology graph through a message passing mechanism; the zero-shot inference module based on the large language model constructs inference prompts and directly asks whether the concept expression belongs to the equipment category, the environmental state category, or the task action category. Each of the three decision models outputs a category label and its corresponding confidence score. The concept attribution decision framework integrates the outputs of the three models through a weighted voting mechanism, with the weights dynamically adjusted based on the evaluation scores of each model on the validation set. Finally, for each concept representation, a clear concept attribution decision result is output, which classifies the concept representation into one of the following categories: equipment category, environmental state category, or mission action category.

[0048] Preferably, after obtaining the concept attribution determination result, the clearly distinguished equipment category concepts, environmental state category concepts, and mission action category concepts are extracted from the concept attribution determination result to form the concept attribution result. This concept attribution result formation process is not a simple aggregation, but rather a structured reorganization of the concept attribution determination result. The concept attribution result organizes equipment category concepts into equipment concept subsets, environmental state category concepts into environmental state concept subsets, and mission action category concepts into action concept subsets. Taking the intelligent support scenario for aviation equipment as an example, the equipment concept subset includes equipment category concepts such as "engine," "radar transceiver assembly," and "weapon mounting device" extracted from the aircraft maintenance manual; the environmental state concept subset includes environmental state category concepts such as "engine temperature," "target lock-on indication," and "hydraulic system pressure value" extracted from weapon operating specifications and combat mission descriptions; and the action concept subset includes mission action category concepts such as "launch," "setting target parameters," "unlocking safety," and "performing evasive maneuvers." The concept attribution results provide a clear and well-defined processing object for subsequent attribute attribution determination, enabling the attribute attribution determination to invoke different attribute extraction strategies for different categories of concepts.

[0049] Preferably, the processing logic for determining the attribute attribution of the concept attribution results in step 2 is as follows: Equipment category concepts, environmental state category concepts, and task action category concepts in the concept attribution results are treated as processing objects, and differentiated attribute extraction processing is performed. For equipment category concepts, the attribute attribution determination will backtrack to the semantic indexing results generated in step 1. Numerical or state-type descriptions that have a modifying or being modified relationship with each equipment category concept will be searched in the semantic indexing results, and these descriptions will be extracted as equipment operation characteristic attribute expressions. For example, for the equipment category concept "engine," descriptions such as "exhaust temperature," "rotor speed," and "remaining life" that co-occur with it in the semantic indexing results will be extracted as its equipment operation characteristic attribute expressions. For environmental state category concepts, the attribute attribution determination also relies on the semantic indexing results, extracting information describing its quantification range or value space as environmental state characteristic attribute expressions. For example, the environmental state characteristic attribute expression of "target lock indication" is its possible enumerated values ​​"unlocked, scanning, stable tracking." For the concept of task action categories, attribute attribution determination extracts constraint information such as execution time, priority, and resource requirements from the semantic indexing results as task action constraint attribute expressions. For example, the task action constraint attribute expression for the "launch" action may include "maximum preparation time limit" and "uninterruptible flag". After the attribute extraction and processing of the above three dimensions are completed, the equipment operation characteristic attribute expression, environmental state characteristic attribute expression, and task action constraint attribute expression together constitute the attribute attribution determination result. This attribute attribution determination result establishes a mapping relationship between the concept and its measurable characteristics.

[0050] Preferably, the process of constructing an ontology classification base based on attribute attribution determination results first involves associating and binding the three types of attribute expressions in the attribute attribution determination results with the corresponding three types of concepts in the concept attribution results, forming concept-attribute association pairs. On this basis, relationship attribution determination is performed on the concepts involved in these concept-attribute association pairs, that is, based on the semantic associations already marked between concepts in the semantic indexing results, three types of relationship expressions are distinguished. Specifically, the semantic association between equipment category concepts and environmental state category concepts is determined as a state association relationship, for example, "engine" and "engine temperature" are state association relationships; the semantic association between task action category concepts and equipment category concepts is determined as an action association relationship, for example, "setting target parameters" and "fire control computer" are action association relationships; the semantic association between task action category concepts and environmental state category concepts is determined as a constraint association relationship, for example, "launch" and "target lock-on indication" are constraint association relationships. After the relationship attribution determination is completed, a relationship attribution result consisting of state association relationships, action association relationships, and constraint association relationships is obtained.

[0051] Preferably, after the relationship attribution results are generated, hierarchical merging is performed on the three types of concepts in the concept attribution results to construct hierarchical relationships between concepts. The hierarchical merging process adopts a bottom-up semantic clustering algorithm. This algorithm first uses a sentence-based bidirectional encoding representation transformer to calculate the semantic similarity between any two concepts. Concept pairs with semantic similarity exceeding the merging threshold are assigned to the same candidate hierarchical cluster. Subsequently, the hierarchical merging process combines the aforementioned relationship attribution results to make constraint adjustments: if two concepts have been determined by the relationship attribution results to have a state association, function association, or constraint association, they will not be merged into a hierarchical relationship, but will maintain their horizontal association. Through this constrained adjustment, the hierarchical merging process ultimately forms a conceptual hierarchy, which defines the parent-child hierarchy between equipment category concepts (e.g., "aircraft" is the superior concept of "fixed-wing aircraft"), the parent-child hierarchy between environmental state category concepts (e.g., "flight state parameters" is the superior concept of "current flight altitude"), and the parent-child hierarchy between mission action category concepts (e.g., "weapon operation" is the superior concept of "launch").

[0052] Preferably, the method for constructing the ontology classification base based on the conceptual hierarchy is as follows: the conceptual hierarchy is used as a skeleton, and the state associations, function associations, and constraint associations in the relationship attribution results are attached to the corresponding nodes of the skeleton, forming a connection structure between the conceptual hierarchy results and the relationship attribution results. This connection structure is the ontology classification base. The ontology classification base consists of three layers: the top layer is a tree-like or graph-like conceptual classification system defined by the conceptual hierarchy, with nodes representing equipment category concepts, environmental state category concepts, and task action category concepts; the middle layer consists of attribute expressions bound to each conceptual node, including equipment operation characteristic attribute expressions, environmental state characteristic attribute expressions, and task action constraint attribute expressions; the bottom layer is a relationship expression network connecting the conceptual nodes, including state associations, function associations, and constraint associations. In the intelligent support scenario of aviation equipment, this ontology classification base fully represents the static knowledge structure such as "what temperature state a certain engine of a certain aircraft is in" and "under what radar lock-on conditions a certain type of missile can be launched", providing a structured knowledge source that can be directly indexed and queried for the subsequent step 3 to extract action descriptions and construct action semantic chains.

[0053] Preferably, the hierarchical classifier based on the bidirectional encoding representation transformer is structurally composed of three stacked layers: a concept context encoding layer, a domain prototype projection layer, and a hierarchical matching determination layer, which together complete the determination of the category of each concept representation in the ontology extraction result.

[0054] Preferably, the concept context encoding layer, as the first structural layer of a hierarchical classifier based on a bidirectional encoding representation transformer, is used to convert the input concept expression and its context text in the semantic indexing result into a dense vector representation containing concept category information. This concept context encoding layer internally includes a context extraction sublayer and a bidirectional encoding sublayer. The context extraction sublayer receives a concept expression and its source text description field in the semantic indexing result as processing objects, concatenates the concept expression and the source text description field into a continuous lexical sequence, marks the positions of concept expression lexical elements in the lexical sequence, and outputs an input lexical sequence with concept position labels. The bidirectional encoding sublayer uses a bidirectional encoding representation transformer fine-tuned with corpora from the aerospace and military industries as the encoding backbone. This bidirectional encoding sublayer receives the input lexical sequence with concept position labels output by the context extraction sublayer as processing objects, performs context semantic interactive encoding processing on each lexical element in the input lexical sequence through a multi-layer bidirectional self-attention mechanism, and outputs the context semantic vector corresponding to each lexical element in the input lexical sequence. After encoding all lexical units, the bidirectional encoding sublayer extracts the context semantic vector corresponding to the position of the concept expression lexical unit from the output context semantic vector sequence, and uses this context semantic vector as the concept semantic vector of the concept expression. The concept context encoding layer outputs a concept semantic vector for each input concept expression, which integrates the concept expression itself and the contextual information of its occurrence in the original text.

[0055] Preferably, the domain prototype projection layer receives the concept semantic vectors output by the concept context encoding layer as processing objects. These vectors are projected onto a pre-constructed domain concept hierarchy prototype space within the aerospace and military industry domain to obtain matching features of the concept representation in various domain concept category directions. Internally, this domain prototype projection layer stores a pre-constructed domain concept hierarchy prototype set, which consists of three prototype vector sets: equipment category prototype vector set, environmental state category prototype vector set, and mission action category prototype vector set. Each prototype vector in the equipment category prototype vector set corresponds to the distribution center of a typical equipment category concept within the aerospace and military industry domain in the concept semantic vector space; each prototype vector in the environmental state category prototype vector set corresponds to the distribution center of a typical environmental state category concept; and each prototype vector in the mission action category prototype vector set corresponds to the distribution center of a typical mission action category concept. The domain prototype projection layer calculates the cosine similarity between the concept semantic vector and each prototype vector in the domain concept hierarchy prototype set, outputting a prototype matching score vector. The dimension of this prototype matching score vector is equal to the total number of prototype vectors in the domain concept hierarchy prototype set. Each element in the prototype matching score vector records the degree of semantic matching between the concept semantic vector and the corresponding prototype vector. This prototype matching score vector is the projection feature of the concept representation in the domain concept hierarchy prototype space.

[0056] Preferably, the hierarchical matching determination layer receives the prototype matching score vector output by the domain prototype projection layer as the processing object, and uses it to perform hierarchical determination of the concept category to which the concept expression belongs based on the distribution of scores in each dimension of the prototype matching score vector. This hierarchical matching determination layer internally includes a coarse-grained category determination sublayer and a fine-grained hierarchical matching sublayer. The coarse-grained category determination sublayer first groups the prototype matching score vector into equipment category prototype vector groups, environmental state category prototype vector groups, and task action category prototype vector groups. It then performs max pooling on the prototype matching scores within each group to obtain three coarse-grained category attribution scores, corresponding to the attribution probability of the equipment category concept, the environmental state category concept, and the task action category concept, respectively. The coarse-grained category determination sublayer selects the category with the highest score among the three coarse-grained category attribution scores as the first-level attribution category of the concept expression, and uses the coarse-grained category attribution score corresponding to this first-level attribution category as the first-level confidence score. The fine-grained hierarchical matching sublayer receives the first-level attribution category output by the coarse-grained category determination sublayer. Within the prototype vector group corresponding to the first-level attribution category, the scores of each dimension belonging to that group in the prototype matching score vector are sorted in descending order. The top few prototype vectors with the highest scores are selected, and the domain category names corresponding to these prototype vectors are used as candidate hierarchical path nodes. Based on the hierarchical position of these candidate hierarchical path nodes in the pre-constructed domain concept hierarchy tree, a hierarchical path from the root node to the specific concept node is constructed. This hierarchical path is the fine-grained hierarchical attribution result of the concept expression. Finally, the hierarchical matching determination layer uses the first-level attribution category as the attribution category label and the weighted average of the first-level confidence score and the highest matching score in the fine-grained hierarchical matching sublayer as the confidence score, outputting the concept attribution determination result.

[0057] Preferably, the three structural layers mentioned above are implemented in a serial pipeline manner to realize the overall function of the hierarchical classifier based on the bidirectional encoding representation transformer. The concept semantic vector output by the concept context encoding layer serves as the direct input to the domain prototype projection layer, and the prototype matching score vector output by the domain prototype projection layer serves as the direct input to the hierarchical matching decision layer. The three form an end-to-end continuous processing path in data flow. The pre-built domain concept hierarchical prototype set in the domain prototype projection layer is a bridge for mapping concepts from the general semantic space to the domain category space. It allows the hierarchical matching decision layer to compress the decision space to a limited domain category prototype dimension instead of directly performing category determination in the vast open semantic space. The two-layer decision mechanism of coarse-grained category determination and fine-grained hierarchical matching enables the hierarchical matching decision layer not only to distinguish the three primary concept categories, but also to locate the concept in the domain concept hierarchy tree as accurately as possible. In the intelligent support scenario for aviation equipment, when the concept expression "a certain type of fighter jet's forward fuselage skin temperature sensor" is input into the classifier at this level, the concept context encoding layer obtains the contextual association between "a certain type of fighter jet" and "skin temperature sensor" from the contextual description of the semantic indexing results, and outputs a concept semantic vector that integrates the temperature monitoring context; the domain prototype projection layer matches this concept semantic vector with the equipment category prototype vector group in the pre-constructed domain concept hierarchical prototype set, and obtains a prototype matching score vector with a high matching score on the equipment category prototype vector group; the hierarchical matching determination layer determines that the first-level category of this concept expression is an equipment category concept, and matches the concept expression to the fine-grained hierarchical path of "aircraft-fixed-wing aircraft-a certain type of fighter jet-fuselage structure-skin temperature sensor" within the equipment category prototype vector group.

[0058] Preferably, the training process of the hierarchical classifier based on the bidirectional encoding representation transformer is divided into three stages: domain adaptation training of the concept context encoding layer, prototype space construction training of the domain prototype projection layer, and end-to-end fine-tuning training of the full classifier. In the domain adaptation training stage of the concept context encoding layer, text from a multi-source document corpus in the aerospace and military industry is first used to train the bidirectional encoding representation transformer using a masked language model. This masked language model is then trained to randomly mask some words in the input word sequence. The bidirectional encoding representation transformer is required to predict the original words of the masked words based on the unmasked context words. By minimizing the cross-entropy loss between the predicted words and the real words, all encoding parameters of the bidirectional encoding representation transformer are updated, enabling the bidirectional encoding representation transformer to learn the collocation rules and sentence features of the aerospace and military industry. In the prototype space construction and training phase of the domain prototype projection layer, domain concept samples labeled with standard concept category tags and standard hierarchical path tags are collected from a multi-source document corpus in the aerospace and military industry domain. Each domain concept sample is converted into a concept semantic vector through a concept context encoding layer that has been trained for domain adaptation. For all concept semantic vectors belonging to the same standard concept category, their mean vector is calculated as the initial prototype vector for that category. For domain concept samples of different fine-grained levels under the same standard concept category, hierarchical clustering is performed according to the hierarchical depth of their standard hierarchical paths. The vector of the cluster center of each level is used as the fine-grained prototype vector corresponding to that level. The initial prototype vectors and fine-grained prototype vectors of all standard concept categories are grouped and stored by category to form a pre-constructed set of domain concept hierarchical prototypes. In the end-to-end fine-tuning training phase, the concept context encoding layer, domain prototype projection layer, and hierarchical matching decision layer are concatenated into a single unit. Domain concept samples with standard concept category labels and standard hierarchical path labels are used as training data. These samples are input into the concept context encoding layer. After forward propagation through the domain prototype projection layer and the hierarchical matching decision layer, the predicted first-level attribution category and fine-grained hierarchical path are obtained. Cross-entropy loss is used to calculate the error between the predicted first-level attribution category and the standard concept category label. Ranking loss, oriented towards hierarchical paths, is used to calculate the matching error between each node in the predicted fine-grained hierarchical path and each node in the standard hierarchical path label. The weighted sum of the cross-entropy loss and the ranking loss is used as the total loss. Backpropagation is used to update the adjustable parameters in all structural layers. After end-to-end fine-tuning training, the hierarchical classifier based on the bidirectional encoding representation transformer can output relatively accurate first-level attribution categories and fine-grained hierarchical paths for various concept representations in the aerospace and military industries.

[0059] Preferably, the training process of the hypernym / hypernym prediction model based on graph neural networks first requires constructing a concept topology graph sample for training from the ontology extraction results. Concept pairs labeled with standard hypernym / hypernym tags are traversed in a multi-source document corpus of the aerospace and military industries. For each concept pair, the two concepts are treated as nodes, and directed edges are established between them according to the standard hypernym / hypernym tags, with the direction of the directed edges pointing from the hypernym / hypernym to the hyponym / hypernym. Simultaneously, semantic co-occurrence relationships between concepts are extracted from the semantic indexing results as auxiliary edges. All these concept nodes, directed edges, and auxiliary edges are organized into a training concept topology graph. The training concept topology graph is then input into the graph neural network-based hypernym / hypernym prediction model for training. This model consists of an input embedding layer, a graph attention message passing layer, and a hypernym / hypernym prediction layer stacked sequentially. The input embedding layer uses a domain-adapted bidirectional encoding representation transformer to convert each concept node in the training concept topology graph into an initial node embedding vector. The graph attention message passing layer receives all the initial node embedding vectors and the adjacency relationships of the training concept topology graph as processing objects, and performs several rounds of graph attention message passing. In each round of message passing, for each concept node, the attention weights between the concept node and its neighbors are calculated. The embedding vectors of the neighbors are weighted and aggregated using the attention weights. The result of the weighted aggregation is then fused with the current embedding vector of the concept node to update the embedding vector of the concept node. After multiple rounds of message passing, the graph augmented embedding vector for each concept node is output. The hierarchical relationship prediction layer receives the graph augmented embedding vector output by the graph attention message passing layer as its processing object. For concept pairs labeled with standard hierarchical relationship tags in the training set, the graph augmented embedding vectors of the two concept nodes are concatenated and input into a feedforward binary classification network. This network outputs the predicted probability that the concept pair has a hierarchical relationship. The error between the predicted probability and the standard hierarchical relationship tag is calculated using the binary cross-entropy loss function. All parameters of the input embedding layer, graph attention message passing layer, and hierarchical relationship prediction layer are updated through backpropagation. After this training, the hierarchical relationship prediction model based on graph neural networks can determine whether there is a hierarchical relationship between any two concepts based on the concept's position in the graph structure of the entire concept topology graph and the semantic information of its neighboring nodes.

[0060] Preferably, the training process of the zero-shot inference module based on the large language model differs from the previous two models. Its core is not to extensively update model parameters, but rather to construct a reasoning prompt template library for concept attribution determination, enabling the finely tuned large language model to directly execute classification tasks through contextual reasoning. This training process first collects a batch of typical concept expression samples covering equipment category concepts, environmental state category concepts, and task action category concepts from a multi-source document corpus in the aerospace and military industry. Each typical concept expression sample is labeled with its corresponding standard attribution category label and hierarchical description. Based on these typical concept expression samples and their standard attribution category labels, a concept attribution determination inference prompt template is constructed. The structure of this template includes: a fixed task instruction prefix, which describes the task requirements and output format for concept attribution determination in natural language form understandable to the large language model; a concept expression placeholder, used to replace the concept expression to be determined during inference; and an inductive suffix, which requires the large language model to provide a brief classification reason while outputting the attribution category label. All typical concept expression samples and their corresponding concept attribution judgment inference prompt templates are organized as a few-sample example library. A large language model is subjected to instruction fine-tuning training for domain concept recognition. This instruction fine-tuning training uses the few-sample examples in the concept attribution judgment example library as training data. Each time, several examples are randomly selected from the concept attribution judgment example library and filled into the concept attribution judgment inference prompt template along with the concept expression to be judged, forming a complete inference prompt. This inference prompt is input into the large language model, which is required to output the attribution category label and classification reason. The autoregressive loss of the language model is used as the training loss function to update the parameters of the large language model. After instruction fine-tuning training, the large language model can determine the attribution category of new concept expressions based solely on the task instructions in the inference prompt template and the few-sample examples. After training, when calling the zero-shot reasoning module based on the large language model in the concept attribution determination framework, the concept expression to be determined is directly filled into the concept attribution determination reasoning prompt template. Then, one or a few examples with the closest semantic distance from the pre-selected concept attribution determination example library are selected as guiding context to form a complete reasoning prompt. The prompt is then input into the large language model to obtain its output attribution category label and confidence score.

[0061] Optionally, based on the attribute attribution determination results, an ontology classification framework is constructed, including: Based on the attribute attribution determination results, attribute attribution results are generated. The attribute attribution results include the expression of equipment operation characteristic attributes corresponding to the equipment category concept, the expression of environmental state characteristic attributes corresponding to the environmental state category concept, and the expression of task action constraint attributes corresponding to the task action category concept. The attribute attribution results are subjected to relationship attribution determination to obtain relationship attribution determination results, which include distinguishing the state association relationship between equipment objects and environmental state objects, the action association relationship between task action objects and equipment objects, and the constraint association relationship between task action objects and environmental state objects. Based on the relationship attribution determination result, a relationship attribution result is generated, which includes state association, function association, and constraint association. The relationship attribution results are hierarchically merged to determine the concept hierarchy relationship, which includes the hierarchical relationship between equipment category concepts, environmental state category concepts, and task action category concepts. Based on the aforementioned conceptual hierarchy, an ontology classification framework is constructed.

[0062] Preferably, the process of generating attribute attribution results based on attribute attribution determination results involves structurally aggregating and encapsulating the mappings already established in the attribute attribution determination results between equipment category concepts and equipment operational characteristic attribute expressions, environmental state category concepts and environmental state characteristic attribute expressions, and task action category concepts and task action constraint attribute expressions, according to the organizational structure of the equipment concept subsets, environmental state concept subsets, and action concept subsets already divided in the concept attribution results. Specifically, each mapping record in the attribute attribution determination results is traversed, and based on which concept subset the mapping record points to, the mapping record is assigned to the corresponding attribute expression group. After this aggregation process, all equipment operational characteristic attribute expressions corresponding to the equipment category concept are organized into an equipment attribute group, all environmental state characteristic attribute expressions corresponding to the environmental state category concept are organized into an environmental attribute group, and all task action constraint attribute expressions corresponding to the task action category concept are organized into an action attribute group. These three attribute groups together constitute the attribute attribution results. Taking the intelligent support scenario for aviation equipment as an example, the equipment attribute group in the attribute attribution results includes the equipment operation characteristic attributes such as "exhaust temperature," "rotor speed," and "remaining life" corresponding to the equipment category concept of "engine," as well as the equipment operation characteristic attributes such as "operating frequency band," "transmit power," and "noise figure" corresponding to "radar transceiver components." The environmental attribute group includes the continuous numerical value space definition corresponding to the environmental state category concept of "engine temperature," and the enumerated value set definition corresponding to "target lock indication." The action attribute group includes the task action constraint attributes such as "maximum preparation time" and "uninterruptible flag" corresponding to the task action category concept of "launch." This attribute attribution result provides a complete query basis with concepts as indexes and attributes as content for subsequent relationship attribution determination.

[0063] Preferably, the method for determining the relationship attribution of the attribute attribution results is as follows: The equipment category concept, environmental state category concept, and task action category concept associated with the attribute attribution results are used as nodes. The semantic indexing results generated in step 1 are traced back to extract the marked semantic relationships between these concept nodes, and these semantic relationships are then type-determined. The type determination is based on the category combination of the concept nodes connected at both ends of the semantic relationship. When a semantic relationship connects an equipment category concept node and an environmental state category concept node, the semantic relationship is determined to be a state relationship. This state relationship represents a certain state that the equipment object is in or possesses. For example, the semantic relationship between the equipment category concept "engine" and the environmental state category concept "engine temperature" is determined to be a state relationship. When a semantic relationship connects a task action category concept node and an equipment category concept node, the semantic relationship is determined to be an action relationship. This action relationship represents that the task action uses the equipment object as the operating subject or object. For example, the semantic relationship between the task action category concept "setting target parameters" and the equipment category concept "fire control computer" is determined to be an action relationship. When a semantic association connects a task action category concept node and an environment state category concept node, the semantic association is determined to be a constraint association. This constraint association represents that the environment state constitutes a prerequisite or limitation for the execution of the task action. For example, the semantic association between the task action category concept "launch" and the environment state category concept "target lock indication" is determined to be a constraint association. After traversing all semantic associations of all concept nodes involved in the attribute attribution result and completing the above type determination for each one, the relationship attribution determination result is obtained, consisting of all state associations, all action associations, and all constraint associations.

[0064] Preferably, the process of generating relational attribution results based on relational attribution determination results involves deduplication, merging, and structured index construction for the three types of relational expressions in the relational attribution determination results. Deduplication merges the same type of semantic association between the same pair of concept nodes that may appear multiple times in the semantic indexing results into a single relational expression record. Merging unifies two relational expressions with opposite directions but semantically equivalent relationships (e.g., the state association from concept node A to concept node B and the passive state association from concept node B to concept node A) into a one-way state association from equipment category concept nodes to environment state category concept nodes, a one-way action association from task action category concept nodes to equipment category concept nodes, and a one-way constraint association from task action category concept nodes to environment state category concept nodes. Structured index construction uses the unique entity identifier of each concept node as the key and all relational expression records in which that concept node participates as the value to construct an index structure that allows for rapid indexing from a concept to all its associations. After the deduplication, merging, and structured indexing processes described above, the relation attribution determination results are transformed into relation attribution results. These results contain a complete set of three types of relations and their corresponding concept-relationship indexes. The state associations, function associations, and constraint associations in these results will be linked to the concept hierarchy relations in subsequent steps, thereby forming a relation expression network within the ontology classification framework.

[0065] Preferably, the hierarchical merging of the relationship attribution results to determine the concept hierarchy employs a bottom-up hierarchical construction algorithm based on semantic similarity clustering and relational constraints. This algorithm first uses all equipment category concepts, environment state category concepts, and task action category concepts from the concept attribution results as initial concept nodes to be merged. Then, for any two concept nodes within each category, a sentence-based bidirectional encoding representation transformer is used to calculate their semantic similarity. Semantic similarity is obtained by encoding the text descriptions of the two concept nodes into semantic vectors and calculating the cosine distance between the two semantic vectors. Concept node pairs with semantic similarity exceeding a preset merging threshold are marked as candidate parent-child pairs, where concepts with broader semantic coverage are preset as parent concepts, and concepts with more specific semantics are preset as child concepts. Following this, hierarchical merging introduces relational attribution results as constraints to filter candidate parent-child pairs: if two concept nodes in a candidate parent-child pair are already recorded as having a state association, function association, or constraint association in the relational attribution results, then the two concept nodes are identified as having a horizontal association rather than a hierarchical association, and the candidate parent-child pair is removed from the candidate parent-child pair set. The candidate parent-child pairs retained after this relational constraint filtering are used to construct a concept hierarchy relationship, which presents a tree-like or forest-like hierarchical structure, defining the parent-child hierarchy between equipment category concepts (e.g., "aircraft" is the superior concept of "fixed-wing aircraft," and "fixed-wing aircraft" is the superior concept of "a certain type of fighter jet"), the parent-child hierarchy between environmental state category concepts (e.g., "flight state parameters" is the superior concept of "current flight altitude"), and the parent-child hierarchy between mission action category concepts (e.g., "weapon operation" is the superior concept of "launch," and "launch" is the superior concept of "missile launch").

[0066] Preferably, the process of constructing an ontology classification base based on the conceptual hierarchy relationship involves using the conceptual hierarchy relationship as the vertical skeleton of the ontology classification base, using the state association, function association, and constraint association relationships in the relationship attribution results as the horizontal connecting network linking different skeleton branches in the ontology classification base, and using the equipment operation characteristic attribute expression, environmental state characteristic attribute expression, and task action constraint attribute expression in the attribute attribution results as attribute layers attached to the skeleton nodes. These three are then integrated into a unified knowledge structure through a structured attachment process. This structured attachment process first traverses each equipment category concept node, environmental state category concept node, and task action category concept node in the conceptual hierarchy relationship. Based on the unique entity identifier of each concept node, it finds the attribute expression corresponding to that concept node from the attribute attribution results and attaches these attribute expressions as attribute slots to that concept node. Subsequently, the structured linking process, based on each state association in the relational attribution results, locates the two concept nodes connected by that state association in the conceptual hierarchy, and establishes a state association edge with a type label between these two concept nodes. For each action association, an action association edge is established between the corresponding task action category concept node and the equipment category concept node. For each constraint association, a constraint association edge is established between the corresponding task action category concept node and the environment state category concept node. After the above linking process, the conceptual hierarchy evolves from a purely tree-like structure into a multidimensional knowledge network with vertical hierarchy and horizontal association, which serves as the ontology classification foundation.

[0067] Preferably, in the target business scenario of intelligent support for aviation equipment, the constructed ontology classification base has the structured knowledge representation capability to directly support the generation of subsequent action semantic chains. The equipment category concept and its equipment operation characteristic attributes in this ontology classification base fully define the physical resources that the agent can perceive and operate, and their measurement parameters; the environmental state category concept and its environmental state characteristic attributes fully define the evaluation dimensions and value space required for the agent to perform state assessment; the task action category concept and its task action constraint attributes fully define the executable behaviors of the agent and their inherent attributes; and the state association, action association, and constraint association establish semantic bridges between the above three types of concepts. Unlike traditional solutions that can only provide isolated entity dictionaries or static tree-like classification structures, the ontology classification base of this application can directly answer complex knowledge queries such as "What is the current exhaust temperature of a certain engine?" and "What equipment is required to perform a launch action and what environmental constraints must be met?" This enables step 3, when extracting actions from the ontology classification base, to directly locate the environmental state objects on which the action execution depends based on constraint relationships, and to locate the equipment objects on which the action execution depends based on action relationship relationships. This provides complete static knowledge support for the dynamic element modeling of the action semantic graph.

[0068] Optionally, based on the aforementioned conceptual hierarchy, an ontology classification framework is constructed, including: Based on the aforementioned concept hierarchy, a concept hierarchy result is generated, which is used to characterize the hierarchical merging structure of equipment category concepts, environmental state category concepts, and task action category concepts. The conceptual hierarchy results are linked and organized to determine the linkage relationships, which include the linkage relationships between the conceptual hierarchy results and the state association relationships, the action association relationships, and the constraint association relationships; Based on the aforementioned connection relationships, a connection relationship result is generated. The connection relationship result is used to characterize the corresponding connection structure between the concept hierarchy result and the state association relationship, the action association relationship, and the constraint association relationship. Based on the relationship connection results, an ontology classification base is constructed.

[0069] Preferably, the processing method for generating conceptual hierarchy results based on the aforementioned conceptual hierarchy relationship is to convert the tree-like or forest-like hierarchical structure implied by the constructed conceptual hierarchy relationship into a structured representation that facilitates rapid indexing and attachment. This process traverses each equipment category conceptual node, each environment state category conceptual node, and each task action category conceptual node in the conceptual hierarchy relationship, assigning a hierarchical path identifier to each conceptual node. This hierarchical path identifier records the sequential sequence of all superior concepts traversed from the root concept to that conceptual node. Subsequently, using the unique entity identifier of the conceptual node as the key, and its hierarchical path identifier, the list of its directly subordinate child conceptual nodes, and its corresponding conceptual category as values, a hierarchical index dictionary is constructed. This hierarchical index dictionary is the conceptual hierarchy result. This conceptual hierarchy fully characterizes the hierarchical merging structure of equipment category concepts, environmental state category concepts, and mission action category concepts. For example, in the intelligent support scenario for aviation equipment, the hierarchical path identifier for the equipment category concept "a certain type of fighter jet" records the complete inheritance chain of "aircraft - fixed-wing aircraft - a certain type of fighter jet," the hierarchical path identifier for the environmental state category concept "current flight altitude" records the inheritance chain of "flight status parameters - current flight altitude," and the hierarchical path identifier for the mission action category concept "missile launch" records the inheritance chain of "weapon operation - launch - missile launch." The conceptual hierarchy clearly defines the vertical position of each concept within the entire ontology classification system, providing directly locatable coordinates for establishing subsequent linkage relationships.

[0070] Preferably, the process of linking and organizing the conceptual hierarchy results to determine the linking relationship between the state associations and the conceptual hierarchy results involves extracting all state associations contained in the relationship attribution results one by one. For each state association, the equipment category concept and the environmental state category concept connected to its two ends are parsed. The hierarchical path identifier and node position of these two concept nodes are found in the conceptual hierarchy results, and a state association linking edge is created between these two concept nodes. This state association linking edge is assigned a relationship type label "state association", and the source identifier of this state association in the relationship attribution results is recorded. At the same time, the linking and organizing process also determines whether the state association is a cross-level state inheritance or a same-level state binding based on the vertical hierarchy of these two concept nodes in the conceptual hierarchy results. For example, the state association "engine-engine temperature" connects the equipment category concept "engine" and the environmental state category concept "engine temperature". The linking and organizing process establishes a state association linking edge for these two nodes in the conceptual hierarchy results. After traversing all state relationships, this process determines the attachment position and attachment method of all state relationships in the conceptual hierarchy result.

[0071] Preferably, the next step in the attachment and sorting process is to attach the functional relationships. The processing logic is similar to that of attaching state relationships. All functional relationships contained in the relationship attribution result are extracted one by one. For each functional relationship, the task action category concept and equipment category concept connected to its two ends are analyzed. These two concept nodes are located in the concept hierarchy result, and a functional relationship attachment edge is created between them, assigning the relationship type label "functional relationship". In the intelligent support scenario for aviation equipment, a functional relationship attachment edge is established between the task action category concept "setting target parameters" and the equipment category concept "fire control computer", and between the task action category concept "locking target" and the equipment category concept "fire control radar". Similarly, the attachment and sorting process also marks the applicable action hierarchy range of the functional relationship based on the hierarchical position of the task action category concept in the concept hierarchy result. For example, it marks "setting target parameters" as a specific sub-action of the higher-level action "weapon operation", thereby attaching the functional relationship to the correct action hierarchy node. This connection process clarifies the operating subject or operating object equipment that the task action depends on during execution.

[0072] Preferably, the final step in the attachment and sorting process is to attach the constraint associations. All constraint associations in the relationship attribution result are extracted one by one. For each constraint association, the task action category concept and the environmental state category concept connected to its two ends are parsed. These two concept nodes are located in the concept hierarchy result, and a constraint association attachment edge is created between them, assigning the relationship type label "constraint association". For the constraint association between the task action category concept "launch" and the environmental state category concept "target lock indication", the attachment and sorting process establishes a constraint association attachment edge for the "launch" node and the "target lock indication" node in the concept hierarchy result. If the environmental state category concept has a hierarchical inheritance relationship in the concept hierarchy result, the attachment and sorting process will automatically propagate the constraint association downwards to its subordinate concept nodes based on the hierarchical path identifier of the environmental state category concept. For example, if the environmental state category concept "target lock indication" has more granular concepts such as "radar lock" and "electro-optical lock", then the constraint association attachment edge will also be attached between these subordinate concept nodes and "launch". After the above three rounds of processing of state association, action association, and constraint association, the concept nodes in the concept hierarchy are now densely covered with association edges with clear type labels. The set of these association edges and their correspondence with the concept nodes constitute the association relationship.

[0073] Preferably, the process of generating relationship attachment results based on the attachment relationships involves formatting and encapsulating the attachment relationships to form a structured dataset that can be directly queried and used later. Specifically, each concept node in the concept hierarchy result is taken as the subject, and all state-related attachment edges, function-related attachment edges, and constraint-related attachment edges connected to the concept node through attachment relationships are collected. The information of these attachment edges (including the connected target concept node, relationship type label, source identifier, etc.) is organized into an attachment edge list, and this attachment edge list is used as an attachment attribute field of the concept node. The collection of all concept nodes and their corresponding attachment edge lists constitutes the relationship attachment result. This relationship attachment result intuitively represents the corresponding attachment structure between the concept hierarchy result and state-related, function-related, and constraint-related relationships. For example, in the relationship attachment result, the attachment edge list of the task action category concept node "launch" will simultaneously include function-related attachment edges pointing to the equipment category concept "missile weapon system," constraint-related attachment edges pointing to the environmental state category concept "target locking indication," and multiple attachment edges that may point to other related concepts. The relationship connection results provide a graph structure data that can be directly traversed for constructing the ontology classification base.

[0074] Preferably, the process of constructing the ontology classification base based on the relationship attachment results involves a final structured fusion of the relationship attachment results, concept hierarchy results, and attribute attribution results. This fusion process first uses the vertical hierarchical skeleton defined by the concept hierarchy results as a foundation. Each associated edge in the relationship attachment results is instantiated between the corresponding concept nodes in the skeleton, drawing horizontal connections with type labels. This expands the original tree-like hierarchical skeleton into a multi-dimensional concept network with horizontal semantic connections. Subsequently, based on the unique entity identifier of each concept node, the fusion process queries the attribute attribution results to find the corresponding equipment operation characteristic attribute expression, environmental state characteristic attribute expression, or task action constraint attribute expression for that concept node, and binds these attribute expressions to the concept node as its attribute description. Through these two fusion steps, the concept hierarchy relationships, relationship attachment results, and attribute attribution results are seamlessly integrated into a unified ontology classification base. This ontology classification base is a multi-level, interconnected knowledge network. Its top layer is the hierarchical classification system of concepts, the middle layer is the attribute set of concept nodes, and the bottom layer is the relationship network connecting concept nodes. In the context of intelligent support for aviation equipment, this ontology classification base enables intelligent agents to start from the equipment category concept of "a certain type of fighter jet", search down the hierarchical path to find its engine subsystem, then find the temperature state variable of the engine through state correlation, find the maintenance actions acting on the engine through action correlation, and find the environmental state constraints that these maintenance actions need to meet through constraint correlation, thereby realizing an integrated index and support from static knowledge to dynamic behavioral logic.

[0075] Optionally, step 3 includes: Action extraction is performed on the ontology classification base to identify the action description content corresponding to the task execution process; Based on the action description content, generate action description entries; Constraint parsing is performed on the action description entries to identify the environmental state object constraints that the task action object needs to satisfy before execution; Based on the constraints of the environmental state object, generate prerequisite constraint entries; Dependency identification is performed on the aforementioned prerequisite constraint items to determine the equipment objects and environment state objects that the task action object depends on during execution; An action semantic chain is generated based on the equipment object and the environment state object.

[0076] Preferably, the specific implementation of action extraction from the ontology classification base to identify the action description content corresponding to the task execution process is as follows: The ontology classification base constructed in step 2 is used as input, and all task action category concept nodes stored in the ontology classification base are traversed. Since the task action category concept has already been associated and bound with equipment category concept and environment state category concept through linkage relationships in the ontology classification base, the action extraction process can directly query all semantic information associated with the task action category concept from the ontology classification base based on the unique entity identifier of the task action category concept. The action extraction process starts from each task action category concept node and collects association information along the action association edges and constraint association edges connected to the task action category concept node in the ontology classification base. The collected association information includes the set of all equipment category concepts connected to the task action category concept through action association edges, and the set of all environment state category concepts connected through constraint association edges. Simultaneously, the action extraction process traces back to the semantic indexing results generated in step 1. It retrieves the original text fragment from the semantic indexing results, identifying the source of the task action category concept. This original text fragment, along with the task action category concept and its associated equipment category and environmental state category concepts, is then encapsulated into a single action description. In the intelligent support scenario for aviation equipment, when the action extraction process reaches the task action category concept "launch," it queries the ontology classification base and finds that "launch" is connected to equipment category concepts such as "missile weapon system" and "fire control radar" through action-related edges, and to environmental state category concepts such as "target lock-on indication" and "missile safety device status" through constraint-related edges. Combining this with the original descriptive text containing "launch" in the semantic indexing results, a complete action description is encapsulated. Each action description corresponds to a specific task action instance. All action descriptions obtained after action extraction from all task action category concepts constitute the action description content set.

[0077] Preferably, the process of generating action description entries based on the action description content involves structuring and formatting each action description in the action description content set. Specifically, the name of the task action category concept is extracted from the action description content as the action name field of the action description entry; the set of equipment category concepts associated with the action description content is extracted as the associated equipment list field of the action description entry; the set of environmental state category concepts associated with the action description content is extracted as the associated environmental state list field of the action description entry; and the original text fragment in the action description content is extracted as the original text description field of the action description entry. After the above field-based organization, each action description is transformed into an action description entry with a fixed field structure. For example, in the action description entry corresponding to the task action category concept "launch", the value of the action name field is "launch", the value of the associated equipment list field is "missile weapon system" and "fire control radar", the value of the associated environmental state list field is "target lock indication" and "missile safety device status", and the value of the original text description field is a natural language sentence containing "launch" in the semantic indexing result. All action description entries constitute a structured set of action description entries. Each record in this set fully describes the equipment context and environmental state context associated with the task action object, providing a structured input that can be directly traversed for subsequent constraint resolution processing.

[0078] Preferably, the implementation logic for performing constraint parsing on the action description entries to identify the environmental state object constraints that the task action object needs to satisfy before execution is as follows: Each action description entry in the action description entry set is treated as a processing object in turn. For each environmental state category concept associated with the environmental state list in the action description entry, the constraint association edge between the environmental state category concept node and the task action category concept node corresponding to the current action description entry is located from the ontology classification base. Then, the source identifier of the constraint association relationship is extracted from the constraint association edge. Based on the source identifier, the original natural language expression of the constraint description corresponding to the constraint association relationship is retrieved from the semantic indexing results. Subsequently, the constraint parsing process inputs the retrieved original natural language expression of the constraint description into a constraint formalization module based on prompt design. This constraint formalization module converts the natural language constraint description into a state judgment expression with environmental state category concepts as variables and comparison operators as operators through semantic parsing. The specific form of the state determination expression can be a Boolean expression formed by connecting an environmental state category concept with a value condition using a comparison operator. For example, for the environmental state category concept "target lock indication" associated with the task action category concept "launch," the constraint parsing process retrieves the corresponding constraint description "radar has completed target lock and established stable tracking state" from the semantic indexing results. The constraint formalization module converts this constraint description into the state determination expression "target lock indication equals stable tracking." After parsing all environmental state category concepts in the action description entry one by one, all environmental state object constraints corresponding to the action description entry are identified, forming a set of environmental state object constraints corresponding to the action description entry. Each environmental state object constraint in this set records the constrained environmental state category concept, the constraint determination operator, and the constraint value condition.

[0079] Preferably, the processing method for generating prerequisite constraint entries based on the environmental state object constraints is as follows: The set of environmental state object constraints corresponding to each action description entry obtained from the aforementioned constraint parsing process is used as input, and logical combination and formatted encapsulation are performed on all environmental state object constraints in this set. This logical combination process determines the conjunction or disjunction relationship between these environmental state object constraints based on the logical connection relationship between them in the original text. For example, when the semantic indexing result shows that the constraint description is "when the fire control radar is in a stable tracking state and the missile safety device has been released," the two environmental state object constraints are in a conjunction relationship, and the combined comprehensive state determination expression is "target lock indication equals stable tracking and safety device status equals released." This comprehensive state determination expression is used as the core content, and the action name field of the action description entry corresponding to the prerequisite constraint entry is added as the index key, encapsulating it into a prerequisite constraint entry. In the intelligent support scenario for aviation equipment, the prerequisite constraint entry corresponding to the mission action category concept "launch" includes the comprehensive state judgment expression "target lock indication equals stable tracking and safety device status equals released." This prerequisite constraint entry completely defines all the environmental state conditions that must be met before the mission action "launch" can be executed. After traversing all action description entries and performing the above processing, a set of prerequisite constraint entries is obtained, consisting of all prerequisite constraint entries. Each prerequisite constraint entry corresponds one-to-one with an action description entry, establishing a complete mapping from the mission action to its execution prerequisites.

[0080] Preferably, the specific process of dependency identification for the prerequisite constraint entries to determine the equipment objects and environment state objects that the task action object depends on during execution is accomplished by taking the set of prerequisite constraint entries and their corresponding action description entries as joint inputs and backtracking the relationship attachment results in the ontology classification base. For each prerequisite constraint entry, the dependency identification process first obtains the associated equipment list field and associated environment state list field from the action description entry indexed by the prerequisite constraint entry. Then, based on each equipment category concept in the associated equipment list, the dependency identification process searches the relationship attachment results in the ontology classification base for action association attachment edges that are connected to both the equipment category concept and the current task action category concept, confirming that the equipment category concept is indeed the operating subject or operating object that the task action category concept depends on during execution, and marking the confirmed equipment category concept as the equipment object that the task action object depends on during execution. Similarly, dependency identification processing, based on each environmental state category concept in the associated environmental state list, retrieves constraint association edges connected to both the environmental state category concept and the current task action category concept from the relational attachment results of the ontology classification base. This confirms that the environmental state category concept is indeed a state variable that needs to be verified before the task action object is executed, and marks the confirmed environmental state category concept as the environmental state object that the task action object depends on during execution. After dependency identification processing, each prerequisite constraint entry obtains a clear list of equipment objects and environmental state objects that its corresponding task action object depends on. This dependency information is appended to the prerequisite constraint entry in the form of attribute fields, providing a complete declaration of the resources required for action execution for the generation of the action semantic chain.

[0081] Preferably, the process of generating an action semantic chain based on the equipment object and the environmental state object involves structurally associating the equipment object, environmental state object, and prerequisite constraint entries generated in the aforementioned steps to form the initial skeleton of the action semantic chain. Specifically, taking the action description entry corresponding to each task action object as the core, the prerequisite constraint entries bound to the action description entry are used as its prerequisite condition field, the list of equipment objects determined by dependency identification processing is used as the initial content of its input dependency field, and the list of environmental state objects determined by dependency identification processing is used as the content of its state dependency field. Subsequently, all action description entries are traversed to establish a temporal or causal relationship between each action description entry and other upstream and downstream action description entries. The way to establish a temporal or causal relationship is to compare the environmental state object list and equipment object list corresponding to two action description entries. When a change in the effect of one action description entry will change the environmental state object on which the prerequisite condition of another action description entry depends, a sequential dependency relationship is determined between the two action description entries, and a directed edge is established between them, with the former action description entry being the upstream action and the latter action description entry being the downstream action. The set of all action description entries and their directed edges constitutes the initial form of the action semantic chain. Each node in this chain is bound to a prerequisite constraint entry and the dependent equipment and environmental state objects. The directed edges represent the sequential dependencies between action execution units. In the intelligent support scenario for aviation equipment, the change in the effect of the mission action object "radar locks onto target" alters the value of the environmental state object "target lock indication." The prerequisite for the mission action object "launch" depends on the value of this environmental state object. Therefore, the action semantic chain generates directed edges from "radar locks onto target" to "launch," forming an action chain representing temporal and conditional dependencies.

[0082] Optionally, based on the equipment object and the environment state object, an action semantic chain is generated, including: Based on the equipment object and the environment state object, generate input dependency entries; The input dependency entries are parsed to identify the task handling results directly generated after the task action object is executed; Based on the task processing results, output result entries are generated; The output entries are parsed for state changes to identify changes in the environmental state objects caused by the execution of the task action object. Based on the changes in the environmental state object, effect change entries are generated; An action semantic chain is generated based on the aforementioned premise constraint entries, the aforementioned input dependency entries, the aforementioned output result entries, and the aforementioned effect change entries.

[0083] Preferably, the processing method for generating input dependency entries based on the equipment object and the environment state object is as follows: The list of equipment objects and the list of environment state objects that the task action object, already determined by the dependency identification process, depends on during execution are used as initial inputs, and these two lists are encapsulated into structured entries. Specifically, for the task action object corresponding to the currently processed action description entry, all equipment objects confirmed by the dependency identification process are extracted one by one, and the unique entity identifier, equipment category concept name, and hierarchical path identifier of each equipment object in the ontology classification base are recorded, organizing them into an equipment dependency list. Simultaneously, all environment state objects confirmed by the dependency identification process for this task action object are extracted one by one, and the unique entity identifier, environment state category concept name, and value type and current value state placeholder defined in the constraint resolution process for each environment state object are recorded, organizing them into a state dependency list. Subsequently, the equipment dependency list and the state dependency list are merged and encapsulated, and the action name field of the task action object is used as the index key of this encapsulation structure to generate an input dependency entry. In the intelligent support scenario for aviation equipment, the input dependency entries corresponding to the mission action object "launch" include an equipment dependency list containing complete index information for two equipment objects: "missile weapon system" and "fire control radar," and a state dependency list containing complete index information for two environmental state objects: "target lock-on indication" and "missile safety device status." Each input dependency entry explicitly declares which equipment resources the corresponding mission action object needs to obtain from the external environment and which current values ​​of state variables it needs to read during execution.

[0084] Preferably, the process of parsing the input dependency entries to identify the task disposal results directly formed after the execution of the task action object involves jointly analyzing the input dependency entries and their corresponding action description entries, and extracting the output information of the action execution by backtracking and retrieving semantic indexing results. This result parsing process first obtains the original text description field of the action description entry pointed to by the input dependency entry, and uses this original text description field as the semantic context for result extraction. Then, the result parsing process performs output fragment recognition based on semantic role annotation within this semantic context, identifying noun phrases in the original text description that form the semantic role of "result" or "product" with the action trigger word, and extracting these noun phrases as candidate task disposal results. Next, the result parsing process matches and verifies the candidate task disposal results with existing concept nodes in the ontology classification base. If the candidate task disposal result can find a corresponding equipment category concept, environmental state category concept, or preset result category concept in the ontology classification base, it is confirmed as a valid task disposal result; if the candidate task disposal result cannot find a corresponding concept in the ontology classification base, it is registered as a new temporary result instance. In the intelligent support scenario for aviation equipment, for the original description of the task action object "launch," which states "Generate a launch record report after launching a missile," the result parsing process identifies the "launch record report" as an output fragment and confirms it as a valid task handling result. For the original description of the task action object "radar locks onto a target," which states "Output target data after locking onto the target," the result parsing process identifies the "target data" as an output fragment and confirms it as a valid task handling result. After traversing all input dependency entries and completing the above result parsing process one by one, each task action object obtains a clear record of its corresponding task handling result.

[0085] Preferably, the processing method for generating output result entries based on the task handling results is to format, organize, and encapsulate all task handling results corresponding to each task action object obtained from the result parsing process. For each task action object, the output result entry generation process first collects all valid task handling results corresponding to the task action object, assigns a result identifier to each task handling result, and records the name, data type, and concept affiliation information of the task handling result in the ontology classification base (if its affiliation has been confirmed through matching verification). Then, using the action name field of the task action object as the index key and the list of task handling results as the main content of the entry, it is encapsulated into an output result entry. Each output result entry answers the question "What will be directly produced after the task action object is executed?" in a structured form. In the intelligent support scenario of aviation equipment, the output result entry of the task action object "launch" includes a task handling result "launch record report", the data type of which is "document object"; the output result entry of the task action object "radar target lock" includes a task handling result "target metadata", the data type of which is "data block". The output result entries provide clear parameter definitions for the output ports of the action execution units in the action semantic chain. The task handling results listed in the output result entries of a task action object can serve as candidates for the data source of the equipment dependency list or state dependency list in the input dependency entries of its downstream task action objects, thereby providing a data flow level connection basis for the dependency orchestration between subsequent action execution units.

[0086] Preferably, the specific processing logic for performing state change parsing on the output result entries to identify changes in the environmental state objects caused by the execution of the task action object is as follows: The output result entries are jointly analyzed with their corresponding action description entries and prerequisite constraint entries to determine whether the execution of the task action object will cause a persistent change in the values ​​of certain environmental state objects. The state change parsing process first obtains the original description field of the action description entry, and searches for verbs or verb phrases representing state changes in this field, such as "set to," "switch to," "update to," "set to," etc. If such verbs representing state changes are found, the environmental state object affected by the verb and the new value assigned to it are extracted. Simultaneously, the state change parsing process also compares the task disposal results recorded in the output result entries with the prerequisite constraint entries corresponding to this action description entry to determine whether the task disposal results contain update operations for certain environmental state objects. In the intelligent support scenario for aviation equipment, the original description of the mission action object "Radar locks onto target" includes "Set the target lock indication to stable tracking." Based on this, the state change parsing process identifies the change in the environmental state object as follows: the value of the environmental state object "target lock indication" has been changed to "stable tracking." Similarly, the original description of the mission action object "Unlock safety" includes "Set the missile safety device status to disarmed." Based on this, the state change parsing process identifies the change in the environmental state object as follows: the value of the environmental state object "missile safety device status" has been changed to "disarmed." The state change parsing process records each identified change in the environmental state object as a change record. This change record includes the unique entity identifier of the changed environmental state object, the placeholder value before the change, and the new value after the change.

[0087] Preferably, the process of generating effect change entries based on changes in the environmental state objects involves integrating and encapsulating all environmental state object changes identified by the state change parsing process to form a structured effect description. For each task action object, the effect change entry generation process first gathers all change records identified by the state change parsing process for that task action object, and formalizes each change record, converting it into a state assignment expression. This state assignment expression consists of three parts: the name of the changed environmental state object, the assignment operator, and the new value. For example, the change record "target lock indication changed to stable tracking" is converted into the state assignment expression "target lock indication assigned to stable tracking"; the change record "missile safety device status changed to deactivated" is converted into the state assignment expression "missile safety device status assigned to deactivated". Then, the effect change entry generation process organizes all state assignment expressions corresponding to the task action object into an effect expression list, and uses the action name field of the task action object as the index key to encapsulate the effect expression list into an effect change entry. In the intelligent support scenario for aviation equipment, the effect change entry for the task action object "radar locks onto target" includes an effect "target lock indication assigned to stable tracking"; the effect change entry for the task action object "unlocks safety" includes an effect "missile safety device status assigned to released"; and the effect change entry for the task action object "launch" may include effects such as "missile inventory quantity reduced by a specified value". The effect change entries fully describe the persistent changes to the world state perceived by the agent after the task action object is executed. These changes will update the agent's internal world model in the form of state assignments and form a causal coupling with the premise verification of the next action execution unit.

[0088] Preferably, the final processing of generating the action semantic chain based on the premise constraint entries, the input dependency entries, the output result entries, and the effect change entries involves uniformly assembling these four types of entries onto the corresponding action description entries to form a complete action execution unit, and establishing dependency edges between all action execution units. Specifically, using each action description entry as a container, the comprehensive state judgment expression of the premise constraint entry corresponding to the action description entry is used as the precondition slot of the action execution unit; the equipment dependency list and state dependency list of the input dependency entry corresponding to the action description entry are used as the input slot of the action execution unit; the task disposal result list of the output result entry corresponding to the action description entry is used as the output slot of the action execution unit; and the effect expression list of the effect change entry corresponding to the action description entry is used as the effect slot of the action execution unit. After the assembly processing of the above four elements, each action description entry is expanded into an action execution unit with four standardized slots. Subsequently, the dependency orchestration process iterates through all action execution units. For any two action execution units, Unit A and Unit B, if Unit A's effect slot contains an assignment operation to a certain environmental state object, and the comprehensive state judgment expression in Unit B's precondition slot happens to reference that environmental state object, and Unit A's assignment result to that environmental state object makes Unit B's comprehensive state judgment expression true, then a directed edge is established between these two action execution units, pointing from Unit A to Unit B. This directed edge represents that Unit A is a precondition action of Unit B. In the intelligent support scenario for aviation equipment, the effect slot of the action execution unit "Radar locks onto target" contains "Target lock indication assigned to stable tracking," while the comprehensive state judgment expression in the precondition slot of the action execution unit "Launch" is "Target lock indication equals stable tracking and safety device status equals released." Therefore, a directed edge from "Radar locks onto target" to "Launch" will be generated in the action semantic chain. Similarly, a directed edge from "Unlock safety" to "Launch" will also be generated in the action semantic chain. All action execution units and their directed edges together constitute an action semantic chain. This action semantic chain, in the form of a graph structure, fully represents the sequential dependencies between multiple action execution units in the target business scenario. It clarifies not only the prerequisite constraints that need to be verified and the input resources that need to be acquired before each action execution unit is executed, but also the results produced after its execution and the effects on the environmental state.

[0089] Optionally, based on the premise constraint entries, the input dependency entries, the output result entries, and the effect change entries, an action semantic chain is generated, including: Assemble the premise constraint entry, the input dependency entry, the output result entry, and the effect change entry into the corresponding action description entry; Based on the assembled action description entries, action execution units are formed; Dependency orchestration is performed on the action execution units to determine the sequential dependencies between multiple action execution units; Based on the aforementioned sequential dependency relationship, an action semantic chain is formed.

[0090] Preferably, the process of assembling the prerequisite constraint entries to the corresponding action description entries involves retrieving the prerequisite constraint entries corresponding to the action name field from the prerequisite constraint entry set, using the action name field of the action description entry as the matching key. After retrieving the corresponding prerequisite constraint entry, the comprehensive state judgment expression in the prerequisite constraint entry is extracted, and this comprehensive state judgment expression is used as the value of the precondition slot of the action description entry. This precondition slot is defined as a Boolean expression slot, the content of which is a logical combination of one or more environmental state object constraints. In the intelligent support scenario of aviation equipment, the action description entry with the action name field "launch" is filled with the comprehensive state judgment expression "target lock indication equals stable tracking and safety device status equals released" after this assembly process. This assembly action establishes a direct binding between the task action object and the state conditions that must be met before its execution.

[0091] Preferably, the process of assembling the input dependency entries into the corresponding action description entries involves retrieving the corresponding input dependency entries from the set of input dependency entries, using the action name field as the matching key. The equipment dependency list and state dependency list from these input dependency entries are extracted and used as the values ​​for the equipment input sub-slot and state input sub-slot in the input slot of the action description entry, respectively. The equipment input sub-slot records the index information of the equipment objects that need to be operated or monitored when executing the task action object, including the unique entity identifier, equipment category concept name, and hierarchical path identifier for each equipment object; the state input sub-slot records the index information of the environmental state objects that need to be read when executing the task action object, including the unique entity identifier, environmental state category concept name, value type, and value status placeholder for each environmental state object. For the action description entry "launch," the equipment input sub-slot in its input slot is filled with a list containing index information for "missile weapon system" and "fire control radar," and the state input sub-slot is filled with a list containing index information for "target lock indication" and "missile safety device status."

[0092] Preferably, the process of assembling the output result entries to the corresponding action description entries involves retrieving the corresponding output result entries from the set of output result entries using the action name field as the matching key, extracting the task handling result list from the output result entry, and filling the output slot of the action description entry with this list. The output slot records a list of task handling results directly generated after the task action object is executed. Each task handling result includes a result identifier, result name, data type, and concept attribution information in the ontology classification base. In the intelligent support scenario for aviation equipment, the output slot of the action description entry "launch" is filled with a list containing a task handling result "launch record report," whose data type is "document object"; the output slot of the action description entry "radar target lock" is filled with a list containing a task handling result "target metadata," whose data type is "data block."

[0093] Preferably, the process of assembling the effect change entry into the corresponding action description entry involves retrieving the corresponding effect change entry from the effect change entry set using the action name field as the matching key, extracting the effect expression list from the effect change entry, and filling the effect slot of the action description entry with this list. The effect slot records the persistent changes to the environmental state object caused by the execution of the task action object. Each effect is described in the form of a state assignment expression, including the name of the changed environmental state object, the assignment operator, and the new value. For the action description entry "Radar locks onto target," its effect slot is filled with a list of effect expressions containing "Target lock indication assigned to stable tracking"; for the action description entry "Unlock safety," its effect slot is filled with a list of effect expressions containing "Missile safety device status assigned to unlocked."

[0094] Preferably, the process of forming an action execution unit based on the assembled action description entries involves encapsulating the action description entries that have been filled with precondition slots, input slots, output slots, and effect slots as a whole, and formally naming the encapsulated data structure an action execution unit. This action execution unit is a core data structure with a standardized four-element structure, composed of precondition slots, input slots, output slots, and effect slots. Specifically, the precondition slots correspond to the Boolean expressions that must be verified at runtime before the action execution unit is executed; the input slots declare the list of equipment resources and state variable reads required by the action execution unit during execution; the output slots declare the list of task disposal results that the action execution unit will produce after execution; and the effect slots declare the list of assignment operations that the action execution unit will perform on the environmental state objects after execution. Each action execution unit is derived from a corresponding action description entry and inherits the action name field of that action description entry as its unique identifier. In the intelligent support scenario for aviation equipment, the action description item "launch" is assembled into the action execution unit "launch" after being assembled with four elements. This action execution unit fully defines the prerequisites, required resources, outputs and state effects of the launch action.

[0095] Preferably, the method for performing dependency orchestration on the action execution units to determine the sequential dependencies between multiple action execution units is to take the entire set of action execution units as input and perform effect-prerequisite matching analysis on each pair of action execution units in the set. The specific logic of this matching analysis is as follows: for any first and second action execution units, extract all effect expressions contained in the effect slots of the first action execution unit, extract the comprehensive state judgment expression in the prerequisite slots of the second action execution unit, and determine whether the environmental state object assigned to a certain effect expression in the effect slot of the first action execution unit appears in the comprehensive state judgment expression of the second action execution unit, and whether the new value assigned to the effect expression makes the part of the comprehensive state judgment expression related to the environmental state object true. If so, a sequential dependency is determined between the first and second action execution units, and this sequential dependency means that the first action execution unit is executed before the second action execution unit. In the intelligent support scenario for aviation equipment, the effect slot of the action execution unit "radar lock target" includes "target lock indication is assigned to stable tracking", and the precondition slot of the action execution unit "launch" includes "target lock indication equals stable tracking". Therefore, there is a sequential dependency between the two, and "radar lock target" is a prerequisite action for "launch".

[0096] Preferably, the process of forming an action semantic chain based on the sequential dependencies involves establishing directed edges between action execution units, with each pair of action execution units identified as having sequential dependencies as the foundation. These directed edges point from the action execution unit of the preceding action to the action execution unit of the following action, and the dependency type can be labeled on the edges, such as "state dependency" or "resource dependency." All action execution units serve as nodes, and all established directed edges serve as edges, collectively forming a directed graph structure, which is the action semantic chain. Each directed path in the action semantic chain represents a possible task execution sequence, which progresses from front to back according to the direction of the directed edge. In the intelligent support scenario of aviation equipment, the action execution units "radar target lock" and "unlock insurance" each have directed edges pointing to "launch", and "launch" may in turn point to downstream action execution units such as "assess damage effect", thus forming a complete action semantic chain. This action semantic chain fully represents the combat mission process from target lock to weapon launch and then to effect assessment in the form of a graph, and each node clearly defines its execution premise, input, output and effect with a four-element standardized structure.

[0097] Optionally, step 4 includes: Based on the fusion results, an extended ontology expression is formed, which is used to characterize the dynamic execution semantics of the action execution unit after fusion with the classification relationship and the attachment relationship; Based on the extended ontology expression, a task execution module for generating intelligent agents is generated.

[0098] Preferably, the process of forming an extended ontology expression based on the fusion result involves performing a deep semantic association and unified encapsulation of the action semantic chain generated in step 3 and the ontology classification base constructed in step 2. This process first traverses each action execution unit in the action semantic chain. For each equipment object referenced in the input slot of the action execution unit, the corresponding equipment category concept node is located in the ontology classification base based on the unique entity identifier of the equipment object, and an equipment reference association edge is established between the action execution unit and the equipment category concept node. Similarly, for each environmental state object referenced in the input slot and effect slot, the corresponding environmental state category concept node is located in the ontology classification base, and state reading association edges and state rewriting association edges are established between the action execution unit and the environmental state category concept node, respectively. Simultaneously, this process matches and verifies the environmental state objects involved in the comprehensive state judgment expression in the precondition slot of the action execution unit with the existing constraint associations in the ontology classification base, confirming the semantic consistency between the preconditions declared by the action execution unit and the constraint associations defined in the ontology classification base, and establishing precondition association edges between the action execution unit and the environmental state category concept node. After the aforementioned associated edges are established, the action semantic chain and the ontology classification base are merged into a unified multi-layer semantic graph structure. This multi-layer semantic graph structure is the fusion result, which includes the original equipment category concept, environment state category concept, task action category concept and their state association, action association and constraint association relationships in the ontology classification base, as well as the dynamic behavior slots introduced by the action execution unit and the sequential dependency relationships represented by the directed edges between the action execution units.

[0099] Preferably, the specific implementation of formally encapsulating the fusion result to generate an extended ontology expression is as follows: using the multi-layer semantic graph structure in the fusion result as material, and formatting and restating all nodes and edges in the graph according to a preset extended ontology formalization specification. This extended ontology formalization specification defines a five-tuple expression structure, which consists of a concept set, an attribute set, a relation set, an action set, and a logical rule set. Specifically, the concept set directly inherits from all equipment category concepts, environment state category concepts, and task action category concepts in the ontology classification base; the attribute set inherits from the equipment operation characteristic attribute expression, environment state characteristic attribute expression, and task action constraint attribute expression bound to each concept node in the ontology classification base; the relation set not only includes the original state association relationships, action association relationships, and constraint association relationships in the ontology classification base, but also adds dynamic relation types corresponding to equipment reference association edges, state read association edges, state rewrite association edges, and precondition association edges established during the fusion process. These dynamic relations include usage relationships between actions and equipment, read relationships and precondition dependencies between actions and environment states, and rewrite relationships; actions... The set consists of all action execution units in the action semantic chain. Each action execution unit is expressed as an action node, which includes a comprehensive state judgment expression in the precondition slot, an equipment dependency list and a state dependency list in the input slot, a task disposal result list in the output slot, and an effect expression list in the effect slot. The logical rule set transforms the causal relationship between preconditions and effects in the action execution unit into conditional rules. Specifically, it uses the comprehensive state judgment expression in the precondition slot as the rule antecedent and the effect expression list in the effect slot as the rule consequent, forming one or more conditional rules to describe how executing the action will lead to the state transition described by the consequent when the environmental state satisfies the antecedent. After the above formatted restatement, the fusion result is transformed into an extended ontology expression that simultaneously contains static domain knowledge and dynamic behavioral logic. This extended ontology expression fully represents the dynamic execution semantics after the fusion of the action execution unit and the classification and attachment relationships in the ontology classification base.

[0100] Preferably, the first step in generating the intelligent agent task execution module based on the extended ontology expression is to perform a compilation mapping on the extended ontology expression to generate code components. This compilation mapping process traverses each action execution unit in the action set of the extended ontology expression and generates a state verification code based on the comprehensive state judgment expression in the precondition slot of that action execution unit. The generation logic of the state verification code is as follows: each environmental state object constraint in the comprehensive state judgment expression is converted into a read and compare operation of an environmental state variable. For example, "target lock indication equals stable tracking" is compiled into a code snippet that reads the current value of the target lock indication and compares it with "stable tracking". The comparison results of all environmental state object constraints are combined into a single conditional statement according to the logical connection relationship in the comprehensive state judgment expression. Simultaneously, the compilation mapping process generates an input processing code based on the equipment dependency list and state dependency list in the input slot of the action execution unit. The logic for generating input processing code is as follows: each equipment object in the equipment dependency list is compiled into a code snippet for resource acquisition or reference declaration; each environment state object in the state dependency list is compiled into a code snippet for state variable reading; and these code snippets are encapsulated into the input parameter acquisition part of the executable code for the action execution unit. Furthermore, the compilation mapping process generates a result generation code based on the task disposal result list in the output slot of the action execution unit. This result generation code declares each task disposal result as an output variable and assigns it a result identifier and data type. Finally, the compilation mapping process generates a state rewriting code based on the effect expression list in the effect slot of the action execution unit. This state rewriting code compiles each state assignment expression into a state variable assignment statement; for example, "assign target lock indicator to stable tracking" is compiled into a code statement that assigns the target lock indicator variable to "stable tracking". After traversing all action execution units, each action execution unit obtains state verification code, input processing code, result generation code, and state rewriting code corresponding to its four elements. These four elements together constitute the code components of the action execution unit.

[0101] Preferably, the processing method for generating executable code units based on the aforementioned code components is as follows: the state verification code, input processing code, result generation code, and state rewriting code corresponding to each action execution unit are combined and encapsulated according to a predetermined execution order to form a complete executable code unit. The predetermined execution order is as follows: first, the state verification code is executed; if the state verification fails, an exception indicating that the precondition is not met is thrown, or the process waits until the condition is met; if the state verification passes, the input processing code is executed to obtain the required equipment resources and the current state variable values; then, the core business logic of the action execution unit is executed (the core business logic can be mapped from the action name field to a pre-defined execution function, or supplemented by the developer after compilation); after the core business logic is executed, the result generation code is executed to output the task handling result; finally, the state rewriting code is executed to update the value of the environment state object. In the intelligent support scenario for aviation equipment, the executable code unit corresponding to the action execution unit "launch" has the following characteristics: its state verification code determines whether "target lock indication" equals "stable tracking" and whether "missile safety device status" equals "disarmed"; its input processing code obtains references to "missile weapon system" and "fire control radar" as well as the current values ​​of the two state variables; its result generation code declares the generation of a "launch record report" document object; and its state rewriting code decrements "missile inventory quantity" by a specified value and resets "missile safety device status" to "not disarmed". Each action execution unit is compiled into such a structured executable code unit, and all executable code units constitute the executable code unit set.

[0102] Preferably, the process of chaining the executable code units according to the action semantic chain is based on the directed graph structure defined by the action semantic chain, establishing trigger-call relationships between the executable code units. The orchestration process traverses each directed edge in the action semantic chain, where each directed edge points from the action execution unit of the preceding action to the action execution unit of the following action. For each directed edge, the orchestration process inserts a call instruction to the executable code unit of the preceding action before the state verification code of the executable code unit of the following action, or registers the completion event of the state rewriting code in the executable code unit of the preceding action as a trigger event of the executable code unit of the following action. The orchestration process also marks executable code units without predecessors as entry executable code units and executable code units without successors as exit executable code units. In the intelligent support scenario of aviation equipment, there is a directed connection in the action semantic chain from "radar locks onto target" to "launch". The orchestration process sets a trigger mechanism in the executable code unit corresponding to "launch". After the executable code unit corresponding to "radar locks onto target" is executed and the state is rewritten, the trigger mechanism automatically starts the state verification of the executable code unit corresponding to "launch", thereby realizing the chain drive between action execution units.

[0103] Preferably, the processing method for generating the agent task execution module based on the chained orchestration result is as follows: all executable code units that have undergone chained orchestration, along with their trigger call relationships, are encapsulated into an independent agent task execution module. This agent task execution module exposes a set of environment state read / write interfaces. Through these interfaces, the agent task execution module can read the current values ​​of the equipment state and environment state variables perceived by the agent in real time, and update the values ​​of these state variables through state rewriting code during the execution of the executable code units. During runtime, the agent task execution module starts from the entry executable code unit and executes each executable code unit sequentially according to the trigger order of the chained orchestration. Before the execution of each executable code unit, its state verification code is automatically called to verify the preconditions. After successful verification, the core logic is executed and the state is rewritten, thereby driving the automatic advancement of the entire task sequence. In the intelligent support scenario of aviation equipment, after the generated intelligent agent task execution module is deployed to the runtime environment of the intelligent agent, it can automatically drive a series of action execution units from the initial state, such as "radar lock target", "unlock insurance" to "launch" and subsequent "assess damage effect", realizing end-to-end automated transformation from unstructured documents to executable intelligent agent behavior.

[0104] Optionally, based on the extended ontology expression, a generative agent task execution module is generated, including: Based on code generation rules, the extended ontology expression is compiled and mapped to generate code components, which include state verification code, input processing code, result generation code, and state rewriting code. Generate executable code units based on the aforementioned code components; The executable code units are arranged in a chain according to the action semantic chain; Based on the chained orchestration results, an agent task execution module is generated.

[0105] Preferably, the process of compiling and mapping the extended ontology expression based on code generation rules to generate code components involves reading action execution units one by one from the action set of the extended ontology expression, and converting the four element slot contents of each action execution unit into code fragments that can be directly called by the intelligent agent's runtime environment. This compilation and mapping process uses a preset type mapping table, which maps the value types of environment state objects defined in the extended ontology expression to the corresponding programming language data types. For example, it maps continuous numeric types to floating-point types, and discrete enumeration types to enumeration or string types. For each action execution unit in the action set, the compiler mapping process first extracts the synthesized state decision expression from its precondition slot, parses the synthesized state decision expression into an abstract syntax tree, traverses each leaf node of the abstract syntax tree, and if the leaf node is an environment state object constraint, then according to the unique entity identifier and environment state category concept name recorded in the extended ontology expression of the environment state object, it retrieves the corresponding data type from the type mapping table, and generates code statements to read and compare the runtime values ​​of the environment state object. Then, it generates condition judgment code fragments by using the logical connectors in the abstract syntax tree according to the comparison results of each leaf node. These condition judgment code fragments are the state verification code corresponding to the action execution unit.

[0106] Preferably, after generating the state verification code, the compilation mapping process then generates corresponding input processing code based on the equipment dependency list and state dependency list in the input slot of the action execution unit. Specifically, it iterates through each equipment object in the equipment dependency list, retrieves the resource handle type corresponding to the equipment object at runtime from the type mapping table based on the unique entity identifier and equipment category concept name of the equipment object, and generates a code statement for resource acquisition or reference declaration. For example, for an equipment object named "missile weapon system", it generates a code call or declaration to "obtain an available instance of the missile weapon system". It iterates through each environment state object in the state dependency list, generates a code statement for reading the current state value, which reads the latest value of the environment state object in the runtime environment and assigns it to a local variable. The resource acquisition statements for these equipment objects and the state reading statements for the environment state objects are combined sequentially into a code block, which is the input processing code corresponding to the action execution unit.

[0107] Preferably, the compilation mapping process continues to generate result generation code based on the task disposal result list in the output slot of the action execution unit. The generation logic of the result generation code is as follows: traverse each task disposal result in the task disposal result list, and based on the result name and data type of the task disposal result, generate a declaration or creation statement for a result object, and a statement to mark the result object as an action output. For example, for the task disposal result "launch record report" and the data type "document object", generate a code statement to create a document object and name it "launch record report", and simultaneously generate code to register it to the current action output channel. Combine all the generation statements for task disposal results to form the result generation code.

[0108] Preferably, the compiler mapping process generates state rewriting code based on the list of effect expressions in the effect slots of the action execution unit. It iterates through each state assignment expression in the effect expression list, which contains the name of the changed environment state object, the assignment operator, and the new value. For each state assignment expression, the compiler mapping process finds the corresponding state variable in the runtime environment based on the name of the environment state object and generates a code statement to assign a value to that state variable. For example, for "assigning the target lock indicator to stable tracking," it generates a statement to assign the variable "target lock indicator" to the enumeration constant "stable tracking." If the effect expression contains arithmetic operations (e.g., "reducing the missile inventory by a specified value"), it generates code that first reads, calculates, and then assigns the value. All the code statements for the state assignment expressions are combined to form the state rewriting code. At this point, each action execution unit has obtained corresponding state verification code, input processing code, result generation code, and state rewriting code. These four parts of code together constitute the code components of the action execution unit.

[0109] Preferably, the processing method for generating executable code units based on the code constituent elements involves combining and encapsulating the code constituent elements of each action execution unit according to a preset execution order to form a structurally complete executable function. This preset execution order is as follows: First, state verification code is placed at the function entry point. If the state verification fails, a precondition failure exception or blocking wait is triggered. After the state verification passes, input processing code is executed to obtain equipment resources and the current state variable values. Subsequently, a core business logic placeholder is reserved. This placeholder corresponds to the specific operation indicated by the action name field of the action execution unit and can be filled in by the developer after compilation or linked from a pre-built action library. After the core business logic is executed, execution result generation code is used to produce the task handling result. Finally, state rewriting code is executed to persistently update the value of the environment state object. This executable function is the executable code unit corresponding to the action execution unit. In the intelligent support scenario for aviation equipment, for the action execution unit "launch", the generated executable code unit is in the form of a function. Internally, it first checks whether the target lock indication is equal to stable tracking and whether the missile safety device status is equal to disengaged. If not, it throws an exception; if they are satisfied, it obtains references to the missile weapon system and fire control radar, reads the current target lock indication and safety device status, then executes the core logic of launch; next, it generates a launch record report; finally, it subtracts a specified value from the missile inventory and resets the missile safety device status to not disengaged.

[0110] Preferably, the chained orchestration of the executable code units according to the action semantic chain is based on a directed graph structure defined by the action semantic chain, establishing a trigger call chain between the executable code units. The orchestration process traverses each directed edge in the action semantic chain, where each directed edge points from the action execution unit of the preceding action to the action execution unit of the following action. For each directed edge, the orchestration process inserts a call or dependency registration code for the executable code unit of the preceding action before the state verification code of the executable code unit of the corresponding following action, or registers the completion of the state rewriting code in the executable code unit of the preceding action as a trigger condition for the executable code unit of the following action. Through this orchestration, multiple executable code units are chained together according to the direction of the action semantic chain, forming a chained structure that can be triggered sequentially. In addition, the orchestration process marks the executable code unit corresponding to the action execution unit without a predecessor in the action semantic chain as the starting executable code unit, and marks the one without a successor as the ending executable code unit.

[0111] Preferably, the processing method for generating the agent task execution module based on the chained orchestration result involves encapsulating all executable code units obtained from the chained orchestration, their trigger call chains, and start and end markers into an independent agent task execution module. This agent task execution module provides an environment state read / write interface, which can interact with the agent's state awareness module during runtime, reading the current values ​​of all environment state objects and writing the new values ​​back to the state awareness module after the state rewriting code of the executable code unit is executed. The agent task execution module also includes an execution scheduler. Upon startup, the execution scheduler starts from the initial executable code unit and sequentially calls each executable code unit according to the trigger order of the chained orchestration. Before calling each executable code unit, its state verification code is automatically executed to determine preconditions. If the determination passes, the subsequent logic is executed to complete the state rewriting, and its subsequent executable code units are automatically activated until the terminating executable code unit is reached. In the intelligent support scenario of aviation equipment, the generated intelligent agent task execution module can automatically drive a series of action execution units in sequence, such as radar target locking, unlocking safety, launching weapons, and assessing damage effects, starting from the start of the combat mission. This realizes the end-to-end automated construction from domain documents to deployable intelligent agent decision execution modules.

[0112] Figure 2 This application provides an executable ontology automatic construction and compilation device for intelligent agent systems. For example... Figure 2 As shown, it includes: The first program unit is used to acquire multi-source task documents for the target business scenario, perform ontology extraction processing on them, extract ontology components and determine the ontology extraction result accordingly. The ontology components are used to characterize the conceptual expression of equipment category, environmental state category and task action category, the attribute expression of equipment operation characteristics, environmental state characteristics and task action constraints, and the relationship expression of the association between equipment objects and environmental state objects, task action objects and equipment objects, and task action objects and environmental state objects. The ontology extraction result is used to characterize the ontology extraction content of the target business scenario composed of the ontology components. The second program unit is used to construct an ontology classification base based on the ontology extraction results; The third program unit is used to perform action semantic construction processing on the ontology classification base to generate an action semantic chain, which is used to represent the sequential dependency relationship between multiple action execution units. The fourth program unit is used to fuse the action semantic chain with the ontology classification base to generate an agent task execution module. The agent task execution module is used to drive the executable code unit to perform chained execution according to the action semantic chain.

[0113] like Figure 3 The image shows an electronic device that includes a processor and a memory. The memory is used to store computer programs; When the processor executes the program stored in the memory, it implements the functions of each module of the device described in the embodiments of this application, or implements the steps of the method described.

[0114] Figures 2-3 For an exemplary description, please refer to the above. Figure 1 This will not be elaborated upon here.

Claims

1. A method for automatically constructing and compiling an executable ontology for intelligent agent systems, characterized in that, include: Step 1: Obtain multi-source task documents for the target business scenario, perform ontology extraction processing on them to extract ontology components and determine the ontology extraction result accordingly. The ontology components are used to characterize the conceptual expression of equipment category, environmental state category and task action category, the attribute expression of equipment operation characteristics, environmental state characteristics and task action constraints, and the relationship expression of the association between equipment objects and environmental state objects, task action objects and equipment objects, and task action objects and environmental state objects. The ontology extraction result is used to characterize the ontology extraction content of the target business scenario composed of the ontology components. Step 2: Based on the ontology extraction results, construct an ontology classification framework; Step 3: Perform action semantic construction processing on the ontology classification base to generate an action semantic chain, which is used to represent the sequential dependency relationship between multiple action execution units; Step 4: Integrate the action semantic chain with the ontology classification base to generate an agent task execution module. The agent task execution module is used to drive the executable code units to perform chained execution according to the action semantic chain.

2. The method according to claim 1, characterized in that, Step 1 includes: Semantic segmentation is performed on the multi-source task documents to obtain segmented document entries; Semantic indexing is performed on the segmented document entries to identify domain semantic elements; Based on the semantic elements of the domain, semantic indexing results are generated, and targeted extraction is performed on the semantic indexing results to extract ontology constituent elements.

3. The method according to claim 2, characterized in that, The domain semantic elements include: equipment objects representing equipment entities, environmental state objects representing external situation and operating conditions, task action objects representing task handling behavior, and constraint descriptions representing task triggering restrictions.

4. The method according to claim 1, characterized in that, Step 2 includes: The ontology extraction results are subjected to concept attribution determination to obtain concept attribution determination results, which include: distinguishing equipment category concepts, environmental state category concepts, and task action category concepts; Based on the concept attribution determination results, concept attribution results are generated, which include equipment category concepts, environmental state category concepts, and task action category concepts. The concept attribution results are used to determine the attribute attribution to obtain the attribute attribution results, which include the attribute expressions corresponding to the equipment category concept, the environmental state category concept, and the task action category concept, respectively. Based on the attribute attribution determination results, an ontology classification framework is constructed.

5. The method according to claim 4, characterized in that, Based on the attribute attribution determination results, an ontology classification framework is constructed, including: Based on the attribute attribution determination results, attribute attribution results are generated. The attribute attribution results include the expression of equipment operation characteristic attributes corresponding to the equipment category concept, the expression of environmental state characteristic attributes corresponding to the environmental state category concept, and the expression of task action constraint attributes corresponding to the task action category concept. The attribute attribution results are subjected to relationship attribution determination to obtain relationship attribution determination results, which include distinguishing the state association relationship between equipment objects and environmental state objects, the action association relationship between task action objects and equipment objects, and the constraint association relationship between task action objects and environmental state objects. Based on the relationship attribution determination result, a relationship attribution result is generated, which includes state association, function association, and constraint association. The relationship attribution results are hierarchically merged to determine the concept hierarchy relationship, which includes the hierarchical relationship between equipment category concepts, environmental state category concepts, and task action category concepts. Based on the aforementioned conceptual hierarchy, an ontology classification framework is constructed.

6. The method according to claim 5, characterized in that, Based on the aforementioned conceptual hierarchy, an ontology classification framework is constructed, including: Based on the aforementioned concept hierarchy, a concept hierarchy result is generated, which is used to characterize the hierarchical merging structure of equipment category concepts, environmental state category concepts, and task action category concepts. The conceptual hierarchy results are linked and organized to determine the linkage relationships, which include the linkage relationships between the conceptual hierarchy results and the state association relationships, the action association relationships, and the constraint association relationships; Based on the aforementioned connection relationships, a connection relationship result is generated. The connection relationship result is used to characterize the corresponding connection structure between the concept hierarchy result and the state association relationship, the action association relationship, and the constraint association relationship. Based on the relationship connection results, an ontology classification base is constructed.

7. The method according to claim 1, characterized in that, Step 3 includes: Action extraction is performed on the ontology classification base to identify the action description content corresponding to the task execution process; Based on the action description content, generate action description entries; Constraint parsing is performed on the action description entries to identify the environmental state object constraints that the task action object needs to satisfy before execution; Based on the constraints of the environmental state object, generate prerequisite constraint entries; Dependency identification is performed on the aforementioned prerequisite constraint items to determine the equipment objects and environment state objects that the task action object depends on during execution; An action semantic chain is generated based on the equipment object and the environment state object.

8. The method according to claim 7, characterized in that, Based on the equipment object and the environment state object, an action semantic chain is generated, including: Based on the equipment object and the environment state object, generate input dependency entries; The input dependency entries are parsed to identify the task handling results directly generated after the task action object is executed; Based on the task processing results, output result entries are generated; The output entries are parsed for state changes to identify changes in the environmental state objects caused by the execution of the task action object. Based on the changes in the environmental state object, effect change entries are generated; An action semantic chain is generated based on the aforementioned premise constraint entries, the aforementioned input dependency entries, the aforementioned output result entries, and the aforementioned effect change entries.

9. The method according to claim 8, characterized in that, Based on the aforementioned premise constraint entries, input dependency entries, output result entries, and effect change entries, an action semantic chain is generated, including: Assemble the premise constraint entry, the input dependency entry, the output result entry, and the effect change entry into the corresponding action description entry; Based on the assembled action description entries, action execution units are formed; Dependency orchestration is performed on the action execution units to determine the sequential dependencies between multiple action execution units; Based on the aforementioned sequential dependency relationship, an action semantic chain is formed.

10. The method according to claim 6, characterized in that, Step 4 includes: Based on the fusion results, an extended ontology expression is formed, which is used to characterize the dynamic execution semantics after the fusion of action execution units with classification relationships and attachment relationships; Based on the extended ontology expression, an intelligent agent task execution module is generated.

Images