A knowledge graph-based multi-agent cluster collaborative decision-making method and system

Abstract

This invention relates to a multi-agent cluster collaborative decision-making method and system based on knowledge graphs, belonging to the field of knowledge graph construction and multi-agent collaborative decision-making technology. The method includes: collecting data from the multi-agent cluster and its deployment environment to construct a preliminary knowledge graph; collecting operational data in real time, identifying differences between the collected data and the preliminary knowledge graph, executing update rules according to type, and outputting a dynamic knowledge graph; receiving user task requests, generating multi-agent collaborative decision-making results based on the dynamic knowledge graph; and returning the decision results to the user terminal and updating the dynamic knowledge graph accordingly. This addresses the problems of insufficient real-time performance and accuracy in existing multi-agent collaborative decision-making technologies.

Description

Technical Field

[0001] This invention relates to the field of technology, and in particular to a multi-agent cluster collaborative decision-making method and system based on knowledge graphs. Background Technology

[0002] With the widespread application of multi-agent systems in industrial manufacturing, intelligent transportation, and drone swarms, multi-agent swarm collaboration has become an important direction in current artificial intelligence research. Knowledge graphs, as a structured knowledge representation method, can effectively organize and manage entity, relation, and attribute information in multi-agent systems, providing data support for multi-agent collaborative decision-making. Currently, knowledge graph construction technology is relatively mature, typically including entity recognition, relation extraction, triple construction, and graph database storage. In multi-agent collaborative decision-making, existing technologies mainly employ rule-based or probabilistic reasoning methods to generate collaborative strategies and implement task scheduling through resource allocation mechanisms.

[0003] Existing knowledge graph construction methods are mostly static, making it difficult to adapt to scenarios where data changes dynamically during the operation of multi-agent clusters, resulting in a lag between the knowledge graph and the actual operating state. Existing incremental update mechanisms typically use full comparison, which has high computational overhead and poor real-time performance, failing to meet the high-frequency data update needs of multi-agent clusters. Existing collaborative decision-making methods lack fine-grained identification of query semantic types, making it difficult to adaptively select the optimal strategy generation method for different query scenarios, resulting in low decision-making efficiency. In addition, in existing technologies, collaborative strategy generation and knowledge graph updates are independent of each other, and the decision results are not fed back to the knowledge graph in a timely manner for closed-loop optimization, which restricts the continuous improvement of the collaborative capabilities of multi-agent clusters. Summary of the Invention

[0004] Based on the above analysis, the embodiments of the present invention aim to provide a multi-agent cluster collaborative decision-making method and system based on knowledge graphs, so as to solve the problems of insufficient real-time performance and accuracy of multi-agent collaborative decision-making in the prior art.

[0005] On one hand, embodiments of the present invention provide a multi-agent cluster collaborative decision-making method based on knowledge graphs, including: Multi-agent data is collected from the multi-agent cluster and its deployment environment, and a preliminary knowledge graph is constructed based on the collected multi-agent data; The system collects operational data from a multi-agent cluster in real time, identifies the differences between the preliminary knowledge graph and the operational data, executes corresponding update rules based on the identified difference types, updates the preliminary knowledge graph in real time, and outputs a dynamic knowledge graph. Receive a task request input from the user terminal, and generate a multi-agent collaborative decision-making result based on the dynamic knowledge graph and the task request; The multi-agent collaborative decision-making results are returned to the user terminal, and the dynamic knowledge graph is updated based on the collaborative decision-making results.

[0006] Furthermore, constructing a preliminary knowledge graph based on the collected multi-agent data includes: Extract target text lines from the multi-agent data, match the content marked in the target text lines according to the agreed format with the preset entity identifiers, identify the successfully matched content as entities, and associate the attribute data corresponding to the entities in the multi-agent data with the entities; Analyze the relationships between entities using a relationship identification model; Construct a set of triples based on the identified entities and the relationships between them; The set of triples is imported into a graph database, and a preliminary knowledge graph is constructed with entities as nodes and relationships between entities as edges.

[0007] Furthermore, the output dynamic knowledge graph includes: A temporary map is constructed based on the aforementioned operational data; An incremental comparison algorithm based on set operations is used to compare the temporary graph with the preliminary knowledge graph to identify entities or relationships that have changed. Based on the identified entities or relationships that have changed, perform the corresponding update processing to obtain the update processing result; The application programming interface of the graph database is called to modify the initial knowledge graph based on the update processing results, thereby obtaining a dynamic knowledge graph.

[0008] Furthermore, the generation of multi-agent collaborative decision-making results includes: Based on the task request input by the user and the dynamic knowledge graph, a candidate collaboration strategy is generated by selecting the corresponding method according to the semantic type of the task request. Check if there are conflicts between different candidate collaboration strategies. If so, resolve the conflicts according to predefined priority rules to obtain a conflict-free collaboration strategy. Based on the conflict-free cooperation strategy, specific tasks are assigned to each agent, and the multi-agent cooperative decision-making results are generated.

[0009] Furthermore, selecting the corresponding method to generate candidate collaboration strategies based on the semantic type of the task request includes: Identify the semantic type of the task request, which includes allocation, scheduling, evaluation, and reasoning; When the semantic type of the task request is allocation or scheduling, the first method is used to generate candidate cooperation strategies; When the semantic type of the task request is evaluation or reasoning, a second approach is used to generate candidate collaborative strategies.

[0010] Furthermore, the first approach for generating candidate collaborative strategies includes: Calculate the depth of an entity node in the hierarchical tree of the dynamic knowledge graph, where the depth is equal to the number of ancestor nodes of the entity node; Arrange the entity nodes in the hierarchical tree structure in ascending order of depth, and assign tasks level by level according to the arrangement order. The task allocation results are output as candidate collaborative strategies.

[0011] Furthermore, the task allocation in order of priority includes: Each level of entity node is processed sequentially in ascending order of depth; the entity node with the smallest depth is assigned the total task; the entity node at the next higher level decomposes the assigned task into N sub-tasks and assigns them to the entity nodes at the next lower level; if the current node does not have a next-level entity node, then the current node is the termination node for task assignment.

[0012] Furthermore, the second approach to generating candidate collaborative strategies includes: The formation type of the current multi-agent cluster is determined based on the entity relationships in the dynamic knowledge graph; Based on the training samples, calculate the conditional probability of each decision made by each agent in the formation under the current formation type and the preset action; The calculated conditional probabilities are normalized, sorted in descending order of probability, and the decision with the highest probability is output as the decision of the agent. Combine the decisions of all agents in the formation into candidate cooperative strategies.

[0013] Furthermore, the conditional probability of each decision under the current formation type and preset action is calculated as shown in the following formula; ; in, For the current formation type, For preset actions, For decision-making, The Laplace smoothing coefficient is... The total number of decision categories; The frequency of the simultaneous occurrence of the current formation type, preset action, and decision in the training samples. This represents the frequency of the current formation type and the preset action occurring simultaneously in the training samples.

[0014] On the other hand, embodiments of the present invention provide a multi-agent cluster collaborative decision-making system based on knowledge graphs, including: A construction module is used to collect multi-agent data from the multi-agent cluster and its deployment environment, and to construct a preliminary knowledge graph based on the collected multi-agent data; The identification module is used to collect the operation data of the multi-agent cluster in real time, identify the differences between the preliminary knowledge graph and the operation data, execute the corresponding update rules according to the identified difference type, update the preliminary knowledge graph in real time, and output a dynamic knowledge graph. The decision module is used to receive task requests input from the user terminal and generate multi-agent collaborative decision results based on the dynamic knowledge graph and the task requests. The update module is used to return the collaborative decision-making results of the multi-agent system to the user terminal and update the dynamic knowledge graph based on the collaborative decision-making results.

[0015] Compared with the prior art, the present invention can achieve at least one of the following beneficial effects: 1. This invention collects operational data from a multi-agent cluster in real time, uses an incremental comparison algorithm based on set operations to identify the differences between the preliminary knowledge graph and the newly added data, and executes corresponding update rules according to the type of difference, thereby realizing the dynamic real-time update of the knowledge graph and solving the problem of lag between the static construction of the knowledge graph and the actual operating state in the prior art.

[0016] 2. This invention identifies the semantic type of user task requests, generates candidate collaborative strategies based on resource hierarchy allocation for allocation and scheduling queries, and generates candidate collaborative strategies based on probabilistic reasoning for evaluation and reasoning queries. Furthermore, it checks for strategy conflicts, resolves conflicts according to priority rules, and assigns specific tasks to each agent, thus solving the problem of insufficient accuracy in multi-agent collaborative decision-making in the prior art.

[0017] In this invention, the above-described technical solutions can be combined with each other to achieve more preferred combinations. Other features and advantages of this invention will be set forth in the following description, and some advantages may become apparent from the description or be learned by practicing the invention. The objects and other advantages of this invention can be realized and obtained from what is particularly pointed out in the description and drawings. Attached Figure Description

[0018] The accompanying drawings are for illustrative purposes only and are not intended to limit the invention. Throughout the drawings, the same reference numerals denote the same parts. Figure 1 is a schematic flowchart of a multi-agent cluster collaborative decision-making method based on knowledge graph provided in an embodiment of the present invention. Figure 2 This is a schematic diagram of a multi-agent cluster collaborative decision-making system based on knowledge graphs, provided as an embodiment of the present invention. Detailed Implementation

[0019] Preferred embodiments of the present invention will now be described in detail with reference to the accompanying drawings, which form part of this application and are used together with the embodiments of the present invention to illustrate the principles of the present invention, but are not intended to limit the scope of the present invention.

[0020] A specific embodiment of the present invention discloses a multi-agent cluster collaborative decision-making method based on knowledge graphs, such as... Figure 1 As shown.

[0021] S1: Collect multi-agent data from the multi-agent cluster and its deployment environment, and construct a preliminary knowledge graph based on the collected multi-agent data.

[0022] Multi-agent swarms refer to heterogeneous systems composed of multiple drones and unmanned vehicles, deployed in environments including urban blocks and mountainous terrain. Multi-agent data comprises two categories: document-based text data, such as drone flight manuals, unmanned vehicle operating instructions, mission description documents, and sensor technical specifications; and initial state data, including parameters such as the multi-agent swarm's initial position, initial battery level, initial speed, payload configuration, initial communication link status, and initial formation structure before the mission begins. This data is collected through the agents' onboard computer interfaces or ground station systems. After collection, both document-based text data and initial state data are converted into structured text data in a pre-defined format.

[0023] The construction of a preliminary knowledge graph employs natural language processing and knowledge extraction techniques. Based on collected multi-agent data, the preliminary knowledge graph is constructed as follows: S11: Extract the target text line from the multi-agent data, match the content marked in the target text line according to the agreed format with the preset entity identifier, identify the successfully matched content as an entity, and associate the attribute data corresponding to the entity in the multi-agent data with the entity.

[0024] In this embodiment, the format is defined as entity names enclosed in angle brackets, such as <UAV A>, <Reconnaissance Mission>, and <Mobile Action>. The text file is read line by line. For lines like <UAV A> performing <Reconnaissance>, the characters "UAV A" and "Reconnaissance" within the angle brackets are extracted as candidate entities. Preset entity identifiers include categories such as UAV, unmanned vehicle, mission, location, action, and target. During matching, a string matching algorithm is used. If a candidate entity is identical to any identifier in the preset entity identifier library or identical after lemmatization, it is identified as an entity.

[0025] Attributes are numerical or textual information that describes the static or dynamic characteristics of an entity. For example, for entity UAV A, attributes might include flight speed, battery level, maximum payload, payload type, current location latitude and longitude, and current mission status. For entity reconnaissance missions, attributes might include priority, mission area radius, and estimated duration. For entity formations, attributes might include formation type, number of members, and communication frequency. Attribute data is associated with corresponding entities in the form of key-value pairs and stored in an in-memory entity-attribute mapping table.

[0026] S12: Analyze the relationships between entities using a relationship identification model.

[0027] Relation extraction can be performed using a BERT-based pre-trained language model. First, two entities from a line of text and their context are input into the model, which then outputs the relation category. For example, for the text "<drone A> performs <reconnaissance>", the model classifies it as an action relation, with the type being "task execution".

[0028] A relationship refers to a logical, spatiotemporal, or functional connection between entities. Types of relationships include: inclusion relationship (e.g., formation A includes UAV B), subordinate relationship (UAV A belongs to a reconnaissance formation), sequential relationship (maneuvering actions precede reconnaissance actions), parallel relationship (UAV A and UAV B perform reconnaissance simultaneously), execution relationship (UAV A performs a reconnaissance mission), communication relationship (UAV A communicates with the ground station), location relationship (UAV A is located in area B), causal relationship (low battery causes a return-to-base action), etc.

[0029] S13: Construct a set of triples based on the identified entities and the relationships between them.

[0030] Each triple is stored as a subject, predicate, and object entity, for example, the triple (drone A, execute, reconnaissance). Multiple triples form a list, which is stored in the system's Redis cache. During construction, all identified entity pairs are traversed, and a triple is generated for each valid relation.

[0031] S14: Import the set of triples into a graph database, use entities as nodes and relationships between entities as edges, and associate the attribute data with the corresponding nodes to construct a preliminary knowledge graph.

[0032] The Neo4j graph database can be used, and nodes and relationships can be created in batches using the Cypher statement through Neo4j's Python driver. For example, executing `CREATE (n:Entity {name:'UAV A', speed:15.2, battery:85, maxLoad:5.0, payload:'Electro-optical pod', lat:116.397, lon:39.908, status:'Standby'})` creates a node containing the above attributes.

[0033] Then execute MATCH (a:Entity {name:'Drone A'}), (b:Entity {name:'Reconnaissance'})CREATE (a)-[r:Execute]->(b) to create an execution relationship.

[0034] For containment relationships, execute MATCH (c:Entity {name:'Fleet A'}), (d:Entity {name:'Drone B'}) CREATE (c)-[r:containment]->(d).

[0035] Attribute data is stored as attribute fields of nodes. Relationships can also have attributes; for example, communication relationships can include attributes such as signal strength and communication latency. After construction, a preliminary knowledge graph is obtained.

[0036] S2: Collect the operational data of the multi-agent cluster in real time, identify the differences between the preliminary knowledge graph and the temporary graph constructed based on the operational data, execute the corresponding update rules according to the identified difference type, update the preliminary knowledge graph in real time, and output the dynamic knowledge graph.

[0037] Operational data refers to the real-time data generated by a multi-agent cluster during task execution, including agent state change data, environmental change data, and task execution feedback data.

[0038] The data on changes in the state of an agent includes changes in the agent's position, speed, battery level, and payload status. For example, the GPS position of drone A moves from (116.397, 39.908) to (116.405, 39.915), its flight speed changes from 15.2 m / s to 18.5 m / s, and its battery level drops from 85% to 82%.

[0039] Environmental change data includes changes in weather conditions detected by sensors, changes in the position of obstacles, and the appearance or disappearance of targets. For example, a weather sensor may detect that the wind speed increases from level 3 to level 5, or the camera of drone A may detect a new target at its current location and generate the target's position coordinates.

[0040] The task execution feedback data includes updates to the task completion progress, changes in task status, and newly generated task execution results. For example, if UAV A has completed the first reconnaissance scan of area B, the task completion progress is updated from 0% to 30%, or the reconnaissance relationship of UAV A is updated from "in progress" to "completed".

[0041] Real-time collection of operational data is achieved and accessed via a Kafka message queue at a frequency of 1Hz. Upon receiving each batch of data, e.g., 10 data entries, a temporary graph is immediately constructed. This temporary graph contains only the entities and relationships corresponding to the newly added operational data. Further, S2 includes: S21: Construct a temporary map based on the running data.

[0042] The construction method for the temporary map is the same as in S11-S14, but it is limited to newly added operational data. For real-time acquired data, relationships are determined by preset rules. For example, based on GPS coordinates, if the Euclidean distance between UAV A and UAV B is less than 50 meters, a proximity relationship is established, indicating that the two UAVs are currently in a state of mutual proximity; if UAV A's sensors detect a target, a detection relationship is established, connecting UAV A with the target entity; if UAV A's remaining battery power is less than 15%, a causal relationship is established, connecting UAV A with the return-to-home action, indicating that the return-to-home action was triggered by low battery power. The temporary map is temporarily stored in a Python dictionary structure in memory and is deleted periodically.

[0043] S22: Using an incremental comparison algorithm based on set operations, the temporary graph is compared with the preliminary knowledge graph to identify entities or relationships that have changed.

[0044] The incremental comparison algorithm works as follows: Extract the entity node set and triplet set from the temporary graph and the preliminary knowledge graph, respectively. Then calculate the symmetric difference between the two sets. For an entity node, compare its unique identifier (e.g., name ID). If it exists in the temporary graph but not in the preliminary knowledge graph, it is a newly added entity; otherwise, it is a deleted entity. If it exists in both but the attribute values ​​are different, it is a modified entity.

[0045] For triples, the hash values ​​of (subject, predicate, object) are compared to determine whether a relationship has been added, deleted, or modified. For example, if (drone B, neighbor, drone C) exists in the temporary knowledge graph but not in the initial knowledge graph, it is identified as a new relationship. The incremental comparison algorithm can be obtained using Python's set data type for difference operations.

[0046] S23: When an entity that has changed is identified, perform operations to add, delete, or modify the attributes of the entity node; when a relationship that has changed is identified, perform operations to add, delete, or modify the relationship; call the application programming interface of the graph database, and modify the preliminary knowledge graph according to the results of the above operations to obtain a dynamic knowledge graph.

[0047] For changes to entities, the specific procedures are as follows: If it is a newly added entity, such as a new unmanned vehicle D appearing in the temporary graph, a node is created directly without processing relationships.

[0048] If an entity is deleted, the system will cascade the deletion of all relationships associated with that entity. In Neo4j, the DETACHDELETE statement automatically deletes all relationships originating from or ending with that entity, preventing dangling relationships. For example, when deleting drone A, all execution, membership, and proximity relationships related to drone A are also deleted.

[0049] If the modification is to an attribute, only the attribute fields of the node are updated, without altering the graph structure; therefore, the original relationships remain unchanged. For example, if the speed attribute of drone A is changed from 15.2 to 18.5, all execution, membership, and other relationships related to drone A will still be valid.

[0050] The specific handling for changes in relationships is as follows: If a new relationship is being created, for example, if drone B is identified as a neighbor of drone C, check if the nodes at both ends of the relationship exist. If they do, the relationship is created; if neither node exists, the node is created first, and then the relationship is created.

[0051] If the relationship is to be deleted, for example, if the original relationship between drone B and drone C no longer holds due to increased distance, then the DELETE statement can be used to delete the relationship directly without modifying the nodes at both ends.

[0052] If you are modifying a relationship, such as changing an executing relationship to one that is currently being executed, first delete the old relationship, then create a new relationship, and copy the original attributes.

[0053] All change operations are completed within a single Neo4j transaction to ensure consistency. After the change is completed, the initial knowledge graph is updated to a dynamic knowledge graph. The dynamic knowledge graph can reflect the latest state of the multi-agent cluster, including the latest attribute values, newly added or disappeared entities, and changed relationships.

[0054] S3: Receive a task request input from the user terminal, and generate a multi-agent collaborative decision result based on the dynamic knowledge graph and the task request.

[0055] The user end can be ground station software or a mobile app. Users input natural language queries, such as assigning tasks to reconnaissance formations or assessing the current situation and recommending actions. Specifically, S3 includes: S31: Select the corresponding method to generate candidate collaboration strategies based on the semantic type of the task request.

[0056] Semantic type recognition employs a FastText-based text classifier, which can be trained on 2000 pre-labeled query samples. The output categories are allocation semantics, scheduling semantics, evaluation semantics, and reasoning semantics. Allocation semantics refers to tasks involving assigning specific resources or tasks to concrete agents, such as assigning a reconnaissance task to drone A or assigning drone B to perform target tracking. Allocation semantics typically includes verbs such as allocate, assign, and hand over.

[0057] Scheduling semantics refers to the operations involved in the timing arrangement or coordination of multiple tasks or agents in a task request. For example, scheduling unmanned vehicles A, B, and C to sequentially perform delivery tasks at station α. ​​Scheduling semantics typically involves the collaboration and ordering of multiple agents.

[0058] Evaluation semantics refers to the operation of judging and analyzing the state, attributes, feasibility, and risks of external target objects, tasks, or overall situations in a task request. The basis for judgment comes from existing actual data in the dynamic knowledge graph or objective information collected in real time. The evaluation objects are usually targets, tasks, or environmental elements outside the intelligent agent cluster, such as evaluating whether there are obstructions on the planned route or evaluating the distance from the station location to the target delivery location.

[0059] Inferential semantics refers to task requests involving predictive judgments about future states, trends, or unknowns, such as predicting a target's movement path or inferring its next location after it disappears. Inferential semantics typically includes terms such as reasoning, prediction, inference, and deduction.

[0060] Based on the identified semantic type, the system selects the corresponding candidate collaborative strategy generation method. Further, the selected candidate collaborative strategy generation method includes: S311: When the semantic type of the task request is allocation or scheduling, a candidate cooperation strategy is generated using the first method.

[0061] The overall task is parsed from the user's task request and then decomposed and assigned to entity nodes at each level according to the hierarchical structure of the dynamic knowledge graph. Entity nodes in the dynamic knowledge graph form a hierarchical tree based on their affiliation. Entity nodes participating in task allocation include cluster nodes, formation nodes, agent nodes (drones, unmanned vehicles, etc.), and functional module nodes (sensors, actuators, etc.). Starting from the cluster node, the task is decomposed level by level down to the lowest level, the functional module node. Target nodes, location nodes, etc., are not involved in task allocation within the hierarchical tree structure and are not subject to deep computation or task allocation. S311 includes: S3111: Calculate the depth of each entity node in the hierarchical tree in the dynamic knowledge graph, where the depth is equal to the number of ancestor nodes of the entity node.

[0062] The first approach uses a resource-level allocation method, where nodes form a hierarchical structure based on their affiliation. For example, a cluster hierarchy contains a formation hierarchy, a formation hierarchy contains an agent hierarchy, and agent nodes contain functional module nodes. For instance, the depth of a cluster node is 0, the depth of a formation node is 1, the depth of a drone node is 2, and the depth of a sensor node is 3. Neo4j's path lookup function is used to calculate the number of ancestor nodes of an entity node in the hierarchical structure; this number represents the depth of that node.

[0063] S3112: Arrange the entity nodes in the hierarchical tree structure in ascending order of depth, and assign tasks level by level according to the arrangement order.

[0064] Using Python's built-in `sorted` function, all entity nodes in the hierarchical tree structure are arranged in ascending order of depth, with the node's depth as the sorting key. The sorting order starts from the cluster node, proceeds to the formation node, agent node, and functional module node, processing each node level by level in this order. This ensures that upper-level nodes first receive the overall task, then decompose the task into subtasks and assign them to lower-level nodes, thus guaranteeing that task allocation starts from the overall task and is refined layer by layer to the specific execution nodes.

[0065] Starting with the entity node with the smallest depth, process each level of entity nodes in ascending order of depth. The entity node with the smallest depth is assigned the total task. The entity node at the next higher level decomposes the assigned task into N sub-tasks and assigns them to the entity nodes at the next lower level. If the current node does not have a next-level entity node, then the current node is the termination node for task assignment, and no further task decomposition and assignment will be performed.

[0066] The task decomposition is based on the entity type of the current node and the capability tags of its child nodes. In the dynamic knowledge graph, capability tags are predefined for each entity node to describe the types of tasks that the node can perform. For example, the capability tags for a formation node include aerial reconnaissance, ground reconnaissance, and material transport; the capability tags for a UAV node include electro-optical reconnaissance, radar reconnaissance, and communication relay; and the capability tags for a sensor node include wide-area scanning, target classification, and signal acquisition.

[0067] The specific allocation process is as follows: The overall task is parsed from the user's task request. For example, if the task is to perform reconnaissance in area B, the overall task is first assigned to the cluster node with the lowest depth. The cluster node then decomposes the overall task into sub-tasks suitable for each formation based on the capability tags of its child nodes. For instance, if the reconnaissance formation has an air reconnaissance capability tag and the transport formation has a material transport capability tag, the area B reconnaissance is decomposed into two sub-tasks: area B air reconnaissance and area B material delivery, which are assigned to the reconnaissance formation node and the transport formation node, respectively.

[0068] After a reconnaissance formation node obtains the aerial reconnaissance sub-task for area B, it further decomposes the task into sub-tasks suitable for each UAV based on the capability tags of its child nodes (UAV nodes). For example, if UAV A has an electro-optical reconnaissance capability tag and UAV B has a radar reconnaissance capability tag, the aerial reconnaissance of area B is decomposed into two sub-tasks: electro-optical reconnaissance and radar reconnaissance, which are then assigned to UAV A and UAV B respectively.

[0069] Finally, the task allocation results are output as candidate collaboration strategies. The task allocation results are in hierarchical tree form, for example: Cluster: {Task: Reconnaissance in Area B}, Reconnaissance Formation: {Mission: Aerial reconnaissance in Area B} Drone A: {Mission: Electro-optical reconnaissance} Optoelectronic pod: {Mission: Wide-area scanning} Target recognition module: {Task: Target classification} Unmanned Aerial Vehicle B: {Mission: Radar Reconnaissance} Transport convoy: {Mission: Deliver supplies to Area B}.

[0070] S312: When the semantic type of the task request is evaluation or reasoning, a second method is used to generate candidate cooperative strategies, including: S3121: Determine the formation type of the current multi-agent cluster based on the entity relationships in the dynamic knowledge graph.

[0071] The second approach learns the conditional probability relationships between formation types, preset actions, and decisions based on historical data, thereby predicting the optimal decision based on the current formation type and user intent. Formation type refers to the organizational structure classification of a multi-agent cluster based on task requirements and agent capabilities. By querying the relationships between entities in a dynamic knowledge graph—for example, searching all nodes of each formation type and their constituent agents—the current formation type can be determined. Different types of formations tend to make different decisions when faced with the same action. If a reconnaissance formation node exists in the graph, and it is associated with 3 drones and 2 unmanned vehicles, then the current formation type is determined to be a reconnaissance formation. Common formation types include: reconnaissance formations (mainly composed of agents carrying reconnaissance payloads such as electro-optical and radar), transport formations (mainly composed of heavy-duty unmanned vehicles and transport drones), and hybrid formations (composed of a mixture of different types of agents). Formation types can be predefined in the knowledge graph's rule base, and the current formation type is determined by matching it against the predefined formation type rule base.

[0072] S3122: Based on the training samples, calculate the conditional probability of each possible decision made by each agent in the formation under the current formation type and preset actions.

[0073] Training samples are derived from historical mission data. Each sample is formatted as (formation type, action performed, decision made, agent identifier executing the decision). For example, (reconnaissance formation, reconnaissance, activation of electro-optical pod, UAV A). Preset actions include maneuvering, reconnaissance, and communication. Decisions refer to all historically occurring or predefined executable decisions for the current formation type and given action. For example, for a reconnaissance formation performing a reconnaissance action, possible decisions include: UAV A activates its electro-optical pod, activates its synthetic aperture radar, decreases its flight altitude to 100 meters, increases its flight speed to 20 meters per second, releases its sonobuoy, and maintains its current state. For a transport formation performing a maneuvering action, possible decisions include: transport vehicle C chooses route A, chooses route B, accelerates through a danger zone, waits for escort, and avoids obstacles.

[0074] For each agent in the formation, extract all historical decision records of that agent from the selected samples, count the frequency of each decision, and calculate the conditional probability of each decision for that agent under the current formation type and preset actions, as shown in the following formula:

[0075] in, Indicates the current formation type, such as a reconnaissance formation; Indicates a pre-set action, such as reconnaissance; It indicates a specific decision, such as activating the photoelectric pod. This refers to the frequency of the simultaneous occurrence of the formation type, action, and decision in the training samples, such as the number of times a reconnaissance formation has historically chosen to activate the electro-optical pod when performing reconnaissance actions. This represents the total number of times that formation type and action occur simultaneously in the training samples. This is the Laplace smoothing coefficient, typically set to 1, used to avoid zero-probability issues. This represents the total number of decision categories; for example, there are 6 possible decisions for a reconnaissance operation.

[0076] The calculated conditional probabilities are normalized and sorted in descending order of probability. The decision with the highest probability is then output as the decision of the agent.

[0077] After calculating the conditional probability of each decision, the softmax function is used to normalize these probabilities so that the sum of the probabilities of all decisions is 1. Sorting is performed using Python's `sorted` function, specifying the probability as the key, sorting in descending order, and selecting the decision with the highest probability as the agent's decision.

[0078] It can also output the top N decisions with the highest probabilities, such as 3. The decision with the highest probability is executed by default. When the decision with the highest probability cannot be executed, other decisions are selected in descending order of probability. For example, for a reconnaissance formation to perform a reconnaissance action, the output results may be: Decision 1 activates the electro-optical pod with a probability of 0.65, Decision 2 activates the synthetic aperture radar with a probability of 0.25, and Decision 3 remains in standby with a probability of 0.10. Decision 1 is selected by default as the decision for this agent.

[0079] After obtaining the decisions of all agents in the formation, the decisions of all agents in the formation are combined into candidate cooperative strategies.

[0080] S32: Check if there is a conflict between different candidate collaborative strategies. If so, resolve the conflict according to the predefined priority rules to obtain a conflict-free collaborative strategy.

[0081] Conflict refers to a situation where different agents involved in candidate cooperative strategies are mutually constrained or contradictory in terms of time, space, resources, or logic, preventing these strategies from being executed simultaneously. Examples include the same agent being assigned two mutually exclusive tasks at the same time, or multiple agents interfering with each other while executing their respective tasks. A rule engine based on the RETE algorithm is used as a conflict resolution engine to execute predefined priority rules.

[0082] The predefined priority rules are evaluated in the following order: Rule 1: Task Priority Comparison. Different task types have preset priority values, with higher values ​​indicating higher priority. For example, a reconnaissance task has a priority of 8, while a transport task has a priority of 5. When two strategies correspond to different task priorities, the reconnaissance task strategy with the higher priority is retained.

[0083] Rule 2: Priority Comparison of Agent Hierarchy. In the hierarchical tree of a knowledge graph, nodes with lower depth, i.e., those closer to the root node, have higher decision priority. For example, the policy priority of a formation is higher than the policy priority of the drones within that formation.

[0084] Rule 3: Urgency Comparison. For tasks with time constraints, the earlier the deadline, the higher the priority.

[0085] Rule 4: Resource Demand Comparison. When multiple strategies compete for the same resource, the strategy with the lower resource demand is given priority.

[0086] For example: Strategy 1 decisions include: scheduling UAV A to conduct reconnaissance at point P from 10:00 to 10:30, with a priority of 8, a depth of 2, and the required resource being an electro-optical pod, with a deadline of 10:30.

[0087] Strategy 2's decision includes: scheduling drone B to perform surveillance at point P from 10:10 to 10:40, with a priority of 8, a depth of 3, the required resources for surveillance equipment, and a deadline of 10:40.

[0088] Strategy 3's decision includes: scheduling drone A to patrol point Q from 10:20 to 10:50, with a priority of 6, a depth of 2, and a required resource of an electro-optical pod, with a deadline of 10:50.

[0089] Both Strategy 1 and Strategy 3 schedule UAV A, and their time windows overlap, constituting a time conflict. Based on Rule 1, the reconnaissance mission priority 8 of Strategy 1 is higher than the patrol mission priority 6 of Strategy 3; therefore, Strategy 1 is preferred.

[0090] Strategy 1 and Strategy 2 have overlapping time windows and both target point P, constituting a spatial conflict. Based on Rule 1, the priority 8 of Strategy 1 and Strategy 2 is the same, so Rule 1 cannot distinguish between them. Based on Rule 2, the depth 2 of Strategy 1 is less than the depth 3 of Strategy 2, and based on Rule 3, the deadline 10:30 of Strategy 1 is earlier than the deadline 10:40 of Strategy 2. Therefore, Strategy 1 is retained.

[0091] S33: Based on the conflict-free cooperative strategy, assign specific tasks to each agent and generate multi-agent cooperative decision results.

[0092] The conflict-free cooperative strategy has already specified a specific action type for each agent. After all tasks are aggregated, a multi-agent cooperative decision result is generated. The action entries for each agent are parsed from the strategy, including fields such as agent identifier, action type, target location, and time constraints. The actions are then transformed into specific executable tasks and issued to the corresponding agents.

[0093] Furthermore, the decision results are pushed to the user interface in real time via WebSocket, where the task list and map path are displayed. Simultaneously, the system adds the task allocation information from the decision results as new triples to the dynamic knowledge graph, for example, creating a (UAV A, assigned to, reconnaissance task) relationship, and updating the current task attributes of the nodes.

[0094] Users can also directly edit the knowledge graph through the interface, such as adding a new agent or modifying a relationship. Update suggestions are sent to the server in JSON format. The JSON is parsed to extract entity identifiers or relationship identifiers. Based on the change type specified in the update suggestion, the corresponding entity node's attribute is modified, the corresponding entity node is added, the corresponding entity node is deleted, or the corresponding relationship is changed in the preliminary knowledge graph.

[0095] This invention provides a knowledge graph-based multi-agent cluster collaborative decision-making system, the system comprising: The construction module 201 is used to collect multi-agent data from the multi-agent cluster and its deployment environment, and to construct a preliminary knowledge graph based on the collected multi-agent data; The identification module 202 is used to collect the operation data of the multi-agent cluster in real time, identify the differences between the preliminary knowledge graph and the operation data, execute the corresponding update rules according to the identified difference type, update the preliminary knowledge graph in real time, and output a dynamic knowledge graph. The decision module 203 is used to receive task requests input by the user terminal and generate multi-agent collaborative decision results based on the dynamic knowledge graph and the task requests.

[0096] It is understandable that the modules and references recorded in this knowledge graph-based multi-agent cluster collaborative decision-making system are... Figure 1 The steps described in the knowledge graph-based multi-agent cluster collaborative decision-making method correspond to each other. Therefore, the operations, features, and beneficial effects described above for the knowledge graph-based multi-agent cluster collaborative decision-making method are also applicable to the knowledge graph-based multi-agent cluster collaborative decision-making system and its constituent modules, and will not be repeated here.

[0097] The above detailed embodiments describe each step of the method of this application. Those skilled in the art can implement the technical solution of this application based on these embodiments, achieving the effect of dynamically constructing, updating, and applying knowledge graphs to support collaborative decision-making among multi-agent clusters. Those skilled in the art will understand that all or part of the processes of the above embodiments can be implemented by a computer program instructing related hardware, and the program can be stored in a computer-readable storage medium. The computer-readable storage medium may be a disk, optical disk, read-only memory, or random access memory, etc.

[0098] The above description is only a preferred embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any changes or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in the present invention should be included within the scope of protection of the present invention.

Claims

1. A multi-agent cluster collaborative decision-making method based on knowledge graphs, characterized in that, include: Multi-agent data is collected from the multi-agent cluster and its deployment environment, and a preliminary knowledge graph is constructed based on the collected multi-agent data; The system collects operational data from a multi-agent cluster in real time, identifies the differences between the preliminary knowledge graph and the operational data, executes corresponding update rules based on the identified difference types, updates the preliminary knowledge graph in real time, and outputs a dynamic knowledge graph. Receive task requests input from the user terminal, and generate multi-agent collaborative decision results based on the dynamic knowledge graph and the task requests.

2. The method according to claim 1, characterized in that, The generated multi-agent collaborative decision-making results include: Based on the semantic type of the task request, a corresponding method is selected to generate candidate collaboration strategies; Check if there are conflicts between different candidate collaboration strategies. If so, resolve the conflicts according to predefined priority rules to obtain a conflict-free collaboration strategy. Based on the conflict-free cooperative strategy, specific tasks are assigned to each agent to generate multi-agent cooperative decision results.

3. The method according to claim 2, characterized in that, The selection of candidate collaboration strategies based on the semantic type of the task request includes: Identify the semantic type of the task request, which includes allocation, scheduling, evaluation, and reasoning; When the semantic type of the task request is allocation or scheduling, the first method is used to generate candidate cooperation strategies; When the semantic type of the task request is evaluation or reasoning, a second approach is used to generate candidate collaborative strategies.

4. The method according to claim 3, characterized in that, The first approach to generating candidate collaborative strategies includes: Calculate the depth of an entity node in the hierarchical tree of the dynamic knowledge graph, where the depth is equal to the number of ancestor nodes of the entity node; Arrange the entity nodes in the hierarchical tree structure in ascending order of depth, and assign tasks level by level according to the arrangement order. The task allocation results are output as candidate collaborative strategies.

5. The method according to claim 4, characterized in that, Task allocation is carried out hierarchically in order of arrangement, including: Each level of entity node is processed sequentially in ascending order of depth; the entity node with the smallest depth is assigned the total task; the entity node at the next higher level decomposes the assigned task into N sub-tasks and assigns them to the entity nodes at the next lower level; if the current node does not have a next-level entity node, then the current node is the termination node for task assignment.

6. The method according to claim 3, characterized in that, The second approach to generating candidate collaborative strategies includes: The formation type of the current multi-agent cluster is determined based on the entity relationships in the dynamic knowledge graph; Based on the training samples, calculate the conditional probability of each decision made by each agent in the formation under the current formation type and the preset action; The calculated conditional probabilities are normalized, sorted in descending order of probability, and the decision with the highest probability is output as the decision of the agent. Combine the decisions of all agents in the formation into candidate cooperative strategies.

7. The method according to claim 1, characterized in that, The preliminary knowledge graph constructed based on the collected multi-agent data includes: Extract target text lines from the multi-agent data, match the content marked in the target text lines according to the agreed format with the preset entity identifiers, identify the successfully matched content as entities, and associate the attribute data corresponding to the entities in the multi-agent data with the entities; Analyze the relationships between entities using a relationship identification model; Construct a set of triples based on the identified entities and the relationships between them; The set of triples is imported into a graph database, and a preliminary knowledge graph is constructed with entities as nodes and relationships between entities as edges.

8. The method according to claim 1, characterized in that, The output dynamic knowledge graph includes: A temporary map is constructed based on the aforementioned operational data; An incremental comparison algorithm based on set operations is used to compare the temporary graph with the preliminary knowledge graph to identify entities or relationships that have changed. Based on the identified entities or relationships that have changed, perform the corresponding update processing to obtain the update processing result; The application programming interface of the graph database is called to modify the initial knowledge graph based on the update processing results, thereby obtaining a dynamic knowledge graph.

9. The method according to claim 6, characterized in that, The conditional probability of each decision under the current formation type and preset action is calculated as shown in the following formula; ； in, For the current formation type, For preset actions, For decision-making, The Laplace smoothing coefficient is... The total number of decision categories; The frequency of the simultaneous occurrence of the current formation type, preset action, and decision in the training samples. This represents the frequency of the current formation type and the preset action occurring simultaneously in the training samples.

10. A multi-agent cluster collaborative decision-making system based on knowledge graphs, characterized in that, include: A construction module is used to collect multi-agent data from the multi-agent cluster and its deployment environment, and to construct a preliminary knowledge graph based on the collected multi-agent data; The identification module is used to collect the operation data of the multi-agent cluster in real time, identify the differences between the preliminary knowledge graph and the operation data, execute the corresponding update rules according to the identified difference type, update the preliminary knowledge graph in real time, and output a dynamic knowledge graph. The decision-making module is used to receive task requests input from the user terminal and generate multi-agent collaborative decision results based on the dynamic knowledge graph and the task requests.

Images