Artificial intelligence scene application deployment method based on industry knowledge graph

Abstract

The application discloses an artificial intelligence scene application deployment method based on an industry knowledge graph and belongs to the technical field of artificial intelligence. The method constructs an industry knowledge graph that fuses business rules and field entities, performs task decomposition and feature labeling on natural language scene requirements, and generates a structured scene requirement feature set. The method maps the scene requirements to knowledge graph entity nodes through semantic matching, forms a scene-graph association graph, automatically completes model retrieval and reasoning strategy synthesis based on the association graph, and generates a lightweight deployment scheme. Finally, a dynamic scheduling engine completes model loading, data docking and effect verification, and realizes end-to-end automatic deployment. The application takes the knowledge graph as a bridge, reduces the technical threshold of AI deployment through automatic mapping and arrangement in the whole process, and improves deployment efficiency and scene adaptability.

Description

Technical Field

[0001] This invention relates to the field of artificial intelligence technology, and in particular to a method for deploying artificial intelligence applications in scenarios based on industry knowledge graphs. Background Technology

[0002] With the rapid development of artificial intelligence technology, the demand for AI applications across various industries is growing daily. However, implementing AI technology in specific business scenarios still faces numerous challenges. Business scenarios are complex and diverse, involving different data sources, business rules, and constraints, which places high demands on the selection and adaptation of AI models. However, existing AI deployment methods mostly rely on manual model selection, data adaptation, parameter configuration, and code integration. This process is cumbersome, time-consuming, and requires a high level of technical expertise from deployment personnel, resulting in high deployment costs and long implementation cycles.

[0003] While existing technologies have explored the integration of knowledge graphs and AI models, significant shortcomings remain. For example, existing technology CN115470360B utilizes knowledge graphs for model management, but the input-output relationships of the model still require manual specification by the user, failing to automatically complete associations based on business scenario needs, and focusing only on model construction without addressing the deployment phase. Similarly, existing technology CN118193751B matches operation and maintenance rules through knowledge graphs, but its application is limited to the optical network operation and maintenance field, with its core focus on fault rule matching rather than general model deployment. Existing technology CN118446300B uses knowledge graphs to extract key features to build lightweight models, but focuses on data compression during model training, lacking a systematic design for automating the deployment phase. Finally, existing technology CN119598867B orchestrates a rule generation engine using knowledge graphs, but rule orchestration still requires manual drag-and-drop configuration in a graphical interface, lacking automatic conversion capabilities based on scenario intent. For example, the existing technology CN120654025A involves hierarchical deployment and parameter updates, but focuses on the model synchronization mechanism under the distributed architecture and does not provide solutions for the deployment front-end scenario analysis, model selection and other aspects.

[0004] In summary, there is an urgent need for an end-to-end solution that can automatically complete model selection, data association, strategy generation, and deployment based on business scenario requirements. Summary of the Invention

[0005] To address the technical problems existing in the prior art, this invention provides a method for deploying artificial intelligence scenario applications based on industry knowledge graphs, comprising the following steps: Receive scenario requirements input in natural language text, decompose the scenario requirements into a task list to generate a sub-task list, and perform feature annotation on each sub-task to generate a scenario requirement feature set containing sub-task feature vectors and key element labels. The text of each element label in the scenario demand feature set is mapped to a query vector through a graph embedding model. The cosine similarity between the query vector and the pre-trained embedding vector of each entity node in the industry knowledge graph is calculated. Entity nodes with similarity exceeding a preset threshold are selected as candidate mapping nodes. A scenario-graph association graph containing task nodes, entity nodes and semantic mapping edges between them is constructed based on the sub-task list and candidate mapping nodes. Starting with the entity nodes associated with the prediction and inference subtask in the scene-graph association graph, a breadth-first search-based subgraph matching is performed in the industry knowledge graph to find model nodes connected by specified relation edges and labeled as artificial intelligence models, as well as data nodes and rule nodes associated with the model nodes. Each model node and its associated nodes are treated as a subgraph. The matching degree between the subgraph and the corresponding part in the scene-graph association graph is calculated using a weighted scoring function. The model node with the highest matching degree is selected as the selected AI model, and the rule nodes associated with the model node are extracted to generate an inference strategy.

[0006] As a preferred embodiment of this application, the construction of the industry knowledge graph includes: obtaining raw data from heterogeneous data sources through a data access submodule and converting it into a set of key-value pairs; extracting entities and relationships from the set of key-value pairs through a deep neural network model based on a transformer architecture, and extracting attribute information of the entities; writing the extracted entities and relationships into a graph database, setting globally unique identifiers and labels for entity nodes, creating directed edges for relationships, and creating indexes for node labels and attribute fields.

[0007] As a preferred embodiment of this application, the task decomposition is implemented through a sequence-to-sequence neural network model, which includes an encoder composed of a multi-layer bidirectional long short-term memory network and a decoder composed of a multi-layer long short-term memory network. The task decomposition specifically includes: converting the natural language text required by the scenario into a word vector sequence and inputting it into the encoder to generate a context vector; the decoder generates an output sequence word by word with the context vector as the initial state; and the output sequence constitutes a sub-task list.

[0008] As a preferred embodiment of this application, the feature annotation is implemented through a bidirectional encoder representation transformer model, specifically including: inputting the text description of each subtask into the model, taking the first vector in the vector sequence output by the model as the feature vector of the subtask; inputting the feature vector in parallel into multiple output branches, the output branches including an input data type branch, an output target branch, a business constraint branch, and a performance index branch, each branch outputting a corresponding element label; aggregating the feature vector and element label of each subtask to form a subtask feature object, and all subtask feature objects constitute a scenario requirement feature set.

[0009] As a preferred embodiment of this application, the construction of the scenario-graph association graph further includes: creating a virtual task node for each subtask, creating a semantic mapping edge between the task node and the candidate mapping node and recording a similarity score in the attributes of the edge, adding directed edges between the task nodes according to the execution order of the subtasks, and creating edges between the candidate mapping nodes according to the existing relationships in the industry knowledge graph.

[0010] As a preferred embodiment of this application, the generation reasoning strategy further includes: extracting all rule nodes associated with the selected model node, parsing the rule description text stored in the attributes of each rule node; comparing the condition part in the rule description text with the element labels in the scene-graph association graph, and filtering out rules that match the conditions; arranging the action parts of the filtered rules according to their connection order with the model node in the knowledge graph, and generating a structured operation instruction sequence containing operation type and operation parameters as the reasoning strategy.

[0011] As a preferred embodiment of this application, the method further includes: querying the operating environment sub-nodes, input interface sub-nodes, and output interface sub-nodes of the selected AI model from the industry knowledge graph to generate a lightweight deployment configuration file and interface specification document; and automatically completing model loading, operating environment isolation, data pipeline connection, task scheduling execution, and effect verification based on the lightweight deployment configuration file and interface specification document through a dynamic scheduling engine to achieve automated deployment.

[0012] As a preferred embodiment of this application, the dynamic scheduling engine automatically completes the isolation of model loading and runtime environment, specifically including: the resource manager sets the resource usage limit for the model service process through the control group mechanism and creates an isolated file system namespace; the model loader dynamically loads the model parsing library, loads the model file into memory, and initializes the model's computation graph.

[0013] As a preferred embodiment of this application, the dynamic scheduling engine automatically completes the effect verification in the following ways: the effect verifier loads the verification rules attached to the inference strategy, and the verification rules are compiled into a set of assertion expressions; the final business result generated after the model is executed is obtained, and the truth value of each assertion expression is calculated; if all assertions are true, the business result is pushed to the target system; if any assertion is false, a verification report is generated and an alarm event is triggered.

[0014] Compared with the prior art, the beneficial effects of the present invention are as follows: 1) Achieve automatic parsing and transformation of scenario requirements into structured features. This invention uses a sequence-to-sequence neural network model to automatically break down user natural language requirements into a sequence of sub-tasks. A bidirectional encoder-representation transformer model extracts four types of element labels for each sub-task: input data type, output target, business constraints, and performance indicators, forming a structured set of scenario requirement features. This mechanism enables the system to accurately understand and process users' fuzzy requirements without requiring manual task analysis and element labeling, solving the problem of traditional methods relying on human experience for scenario understanding.

[0015] 2) Establish an intelligent graph association mechanism based on semantic matching. This invention calculates the semantic similarity between scene element tags and knowledge graph entity nodes through a semantic matching unit, automatically selecting matching entity nodes; it creates mapping edges between virtual task nodes and entity nodes through an association graph construction unit, and constructs a complete scene-graph association graph based on the subtask execution order and existing relationships in the knowledge graph. This mechanism eliminates the need for manual operation in associating scene requirements with the knowledge graph, achieving intelligent automatic mapping.

[0016] 3) Forming an end-to-end automated deployment closed loop. This invention automatically selects the optimal model and synthesizes inference strategies through a graph matching engine, automatically generates lightweight deployment configurations and interface specifications through a configuration and interface generation unit, and automatically completes resource isolation, model loading, data integration, task scheduling, and effect verification through a dynamic scheduling engine. This complete automated closed loop achieves unmanned operation throughout the entire process from requirement input to service launch, significantly shortening the deployment cycle and lowering the technical threshold. Attached Figure Description

[0017] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with the invention and, together with the description, serve to explain the principles of the invention.

[0018] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, those skilled in the art can obtain other drawings based on these drawings without creative effort.

[0019] Figure 1 This is a general flowchart of the artificial intelligence scenario application deployment method provided in the embodiments of the present invention.

[0020] Figure 2 This is a flowchart of knowledge graph construction provided in an embodiment of the present invention.

[0021] Figure 3 This is a flowchart of scenario requirement analysis and feature set generation provided in the embodiments of the present invention.

[0022] Figure 4 This is a schematic diagram illustrating the mapping between scenario requirements and knowledge graphs provided in an embodiment of the present invention.

[0023] Figure 5 This is a flowchart of the model selection and deployment scheme generation provided in the embodiments of the present invention.

[0024] Figure 6 This is a schematic diagram of the workflow and components of the dynamic scheduling engine provided in this embodiment of the invention.

[0025] Figure 7 This is a diagram showing the module composition and data flow of the artificial intelligence scenario application deployment system provided in this embodiment of the invention. Detailed Implementation

[0026] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of the present invention, and not all of them. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of the present invention.

[0027] It should be noted that all directional indications (such as up, down, left, right, front, back, etc.) in the embodiments of the present invention are only used to explain the relative positional relationship and movement of each component in a certain specific posture (as shown in the figure). If the specific posture changes, the directional indication will also change accordingly.

[0028] Furthermore, the use of terms such as "first" and "second" in this invention is for descriptive purposes only and should not be construed as indicating or implying their relative importance or implicitly specifying the number of technical features indicated. Therefore, features defined with "first" and "second" may explicitly or implicitly include at least one of those features. Additionally, the technical solutions of the various embodiments can be combined with each other, but only on the basis of being achievable by those skilled in the art. When the combination of technical solutions is contradictory or impossible to implement, such a combination of technical solutions should be considered non-existent and not within the scope of protection claimed by this invention.

[0029] Example 1 This invention provides a method for deploying artificial intelligence applications in various scenarios based on industry knowledge graphs. For example... Figure 1 As shown, the specific steps include: S101, Constructing an Industry Knowledge Graph In this step, the knowledge graph construction module integrates the target industry's business rules, domain entities, scenario processes, and constraints to build an industry knowledge graph. The industry knowledge graph is stored and represented using a directed labeled graph data structure. The graph contains entity nodes representing domain concepts, relationship edges describing the semantic connections between nodes, and attributes recording specific information about the entities. For example... Figure 2 As shown, the specific implementation is as follows: The knowledge graph construction module first initiates the data access submodule. This submodule connects to industry standard document libraries, technical specification databases, and business process management systems via pre-defined data source connectors. For each data source, the submodule invokes the corresponding parser based on its type. When processing structured data, such as tabular data in a relational database, the submodule directly reads each row of records from the table using a structured query language and converts each row into a key-value pair object containing field names and values. When processing semi-structured data, such as documents in Extensible Markup Language (XML) format, the submodule calls the Document Object Model (DOM) parser to load the entire document into a tree structure, then recursively traverses each node, using the node name as the key and the node text content as the value to generate key-value pair objects. When processing unstructured data, such as plain text documents, the submodule calls the text segmentation processor to divide the document into paragraphs and generates a key-value pair object containing a paragraph number and text content for each paragraph. All generated key-value pair objects are temporarily stored in a memory buffer, forming an intermediate data object set.

[0030] Subsequently, the entity relation definition submodule retrieves intermediate data objects one by one from the memory buffer for processing. The submodule loads a pre-trained deep neural network model, built on a transformer architecture specifically designed for extracting entities and relations from text. For each intermediate data object, the submodule first inputs its text content into the encoder of the deep neural network model. The encoder, through multiple layers of self-attention computation, transforms each word in the text into a feature vector containing contextual semantic information. Next, the submodule calls the named entity recognition output layer of the deep neural network model. This layer is a fully connected network followed by a conditional random field layer. The named entity recognition output layer predicts an entity label for each word in the text, such as "algorithm entity," "device entity," "parameter entity," or "non-entity." By merging multiple consecutive words with the same entity label, the submodule obtains an entity and its positional boundaries within the text. Then, the entity relationship definition submodule calls the relationship extraction output layer of the deep neural network model. The relationship extraction output layer receives the location information of the entity pairs and the feature vector of the entire text, and outputs the type of relationship between the entity pairs through a classifier, such as "used for prediction", "as input", "belongs to", etc. For each extracted entity, the entity relationship definition submodule also extracts attribute information from its corresponding key-value pair object. For example, for an "algorithm entity", its attributes may include "algorithm version number", "algorithm author", and "number of algorithm input parameters".

[0031] After entity and relation extraction is complete, the knowledge storage submodule takes over the processing and establishes a connection with the graph database. For each entity, the knowledge storage submodule creates a node object in the graph database, assigns a globally unique identifier to the node, and uses the entity type as the node's label. Simultaneously, the knowledge storage submodule appends all attributes extracted by the entity relation definition submodule to the node as key-value pairs. For each relation, the knowledge storage submodule creates a directed edge in the graph database, with the starting node being the node corresponding to the head entity and the ending node being the node corresponding to the tail entity; the edge type is the relation type. After all nodes and edges are written to the graph database, the knowledge storage submodule calls the graph database's index building function to create indexes for node labels and attribute fields to accelerate subsequent query operations. At this point, the industry knowledge graph is constructed and persistently stored in the graph database.

[0032] S102. Analyze scenario requirements and generate scenario requirement feature sets. In this step, the user inputs their scenario requirements in natural language text, such as "I need to build an application that can predict results based on input data." The scenario parsing module receives the scenario requirements of the target application scenario, and performs task decomposition and feature annotation on the scenario requirements to generate a scenario requirement feature set. For example... Figure 3 As shown, the specific implementation is as follows: The scene parsing module first invokes its internal task decomposition unit. The task decomposition unit loads a finely tuned sequence-to-sequence neural network model. The encoder of this model is a multi-layer bidirectional long short-term memory network that splits the input text into word sequences, converts each word into a word vector, and feeds these vectors sequentially into the encoder network. The encoder network compresses the entire text sequence into a fixed-dimensional context vector through recursive computation in both forward and backward directions. This context vector is then passed to the decoder. The decoder, also a multi-layer long short-term memory network, starts generating the output sequence word by word, using the context vector as its initial state. At each step, the decoder predicts the probability distribution of the next word based on the current state and the words generated in the previous step, and selects the word with the highest probability as the output of the current step using a beam search strategy. The decoder continues generating until a special end marker is output. The word sequence output by the decoder is the decomposed subtask sequence, such as "data access subtask," "data preprocessing subtask," "feature engineering subtask," "predictive inference subtask," and "result output subtask." The task decomposition unit stores this subtask sequence as a subtask list.

[0033] Next, the scene parsing module calls its feature annotation unit. The feature annotation unit processes each subtask in the subtask list separately. For the text description of the current subtask, the feature annotation unit inputs it into a pre-trained bidirectional encoder-representation transformer model. The bidirectional encoder-representation transformer model converts each word in the subtask description into a feature vector, and through a multi-layer self-attention mechanism, it integrates the contextual information of the entire subtask description into the feature vector of each word. The bidirectional encoder-representation transformer model outputs a vector sequence, and the feature annotation unit uses the vector corresponding to the first word in this sequence (i.e., the aggregated representation of the entire sequence) as the feature vector of that subtask. Simultaneously, the feature annotation unit inputs this feature vector in parallel into multiple independent output branches, each corresponding to a key feature type. For example, the input data type branch is a fully connected network followed by a multi-class classifier. The multi-class classifier outputs a probability vector, representing the probability that the input data type of the subtask belongs to categories such as "time series data," "image data," "text data," and "numerical structured data." The feature annotation unit selects the category with the highest probability as the label for that feature. Similarly, the output target branch, business constraint branch, and performance indicator branch also output their corresponding feature labels. The feature annotation unit aggregates the feature vector of each subtask and its four feature labels to form a subtask feature object.

[0034] Finally, the scene parsing module places all subtask feature objects into an array and calls a structured data serialization method to convert the array into a text-formatted dataset, which is then stored in memory. This dataset is the scene requirement feature set, containing structured information extracted from the original scene requirements that can be directly used in subsequent steps.

[0035] S103, Feature Set of Relational Mapping Scenarios and Industry Knowledge Graph In this step, the mapping module reads the scene requirement feature set generated in S102 from memory and establishes a connection with the graph database. It then maps the scene requirement feature set to entity nodes in the industry knowledge graph, generating a scene-graph association graph. For example... Figure 4 As shown, the specific implementation is as follows: The mapping module first invokes its internal semantic matching unit. The semantic matching unit performs semantic matching for each feature label of each subtask in the scene requirement feature set. Specifically, the semantic matching unit obtains the label text of the current feature and inputs it into a pre-trained graph embedding model, which maps the text to a low-dimensional vector space. Simultaneously, the semantic matching unit sends a query to the graph database to obtain a list of identifiers for all entity nodes and retrieves the pre-calculated embedding vector for each entity node, stored in the graph database. These embedding vectors are obtained by encoding the name, type, attributes, and relationships of each entity node using the same graph embedding model. The semantic matching unit calculates the cosine similarity between the embedding vector of the current feature label and the embedding vector of each entity node; the closer the cosine similarity value is to 1, the more semantically similar the two are. The semantic matching unit sorts all entity nodes from high to low similarity and selects the top few entity nodes with similarity exceeding a preset threshold as candidate mapping nodes. For each candidate mapping node, the semantic matching unit records its identifier, type, and similarity score.

[0036] After matching all elements, the mapping module calls its internal association graph construction unit. The association graph construction unit first creates an empty graph structure object, represented in memory as an adjacency list. It then traverses the subtask list, creating a virtual task node for each subtask. The task node's identifier includes the subtask's name and sequence number. Next, the association graph construction unit traverses all candidate mapping nodes matched by the semantic matching unit for the current subtask. For each candidate mapping node, the association graph construction unit creates a "semantic mapping" edge between the task node and the candidate mapping node, recording the similarity score in the edge's attributes. Finally, the association graph construction unit adds directed edges between task nodes according to the subtask execution order output by the task decomposition unit in S102. For example, if subtask A is executed before subtask B, a "successor" edge is created between task node A and task node B.

[0037] In addition, the association graph construction unit sends a series of queries to the graph database to obtain the existing relationships between candidate mapping nodes in the original industry knowledge graph. For each relationship edge returned from the graph database, the association graph construction unit also creates an edge of the same type between the corresponding two candidate mapping nodes. At this point, the association graph construction unit has built a directed graph in memory containing task nodes and knowledge graph entity nodes, as well as various types of relationship edges between them; this graph is the scene-knowledge graph association graph.

[0038] S104. Select a model and generate a deployment plan. In this step, the deployment scheme generation module obtains the scene-graph association graph generated by S103, automatically selects the appropriate AI model and inference strategy through the graph matching algorithm, and generates a lightweight deployment configuration and interface specification. For example... Figure 5 As shown, the specific implementation is as follows: The deployment scheme generation module first invokes its internal graph matching engine. The graph matching engine uses the scene-graph association graph as the query graph and performs subgraph matching searches within the underlying industry knowledge graph. Specifically, the graph matching engine employs a breadth-first search-based graph matching algorithm, starting with the entity node in the scene-graph association graph associated with the "predictive reasoning" subtask, using that node as the starting anchor. Then, in the graph database, the graph matching engine executes a series of graph queries, searching for all nodes connected to the anchor node via relational edges such as "used for," "realizable," or "associated with model," and these nodes are labeled as "artificial intelligence model." For each found model node, the graph matching engine continues to expand outwards, searching for data nodes and rule nodes connected to that model node via relational edges such as "requires input," "generates output," and "follows rules." The graph matching engine treats each model node and its associated data nodes and rule nodes as a subgraph and calculates the degree of matching between this subgraph and the corresponding part of the scene-graph association graph. The degree of matching is calculated based on a comparison of node type, relation type, and attribute values, quantified using a weighted scoring function. Ultimately, the graph matching engine returns a list containing several candidate subgraphs, each subgraph corresponding to a candidate deployment scheme fragment.

[0039] Next, the deployment scheme generation module invokes the model selection and strategy synthesis unit. The model selection and strategy synthesis unit first filters the candidate subgraphs returned by the graph matching engine based on the constraints of the "performance index" element in the scenario requirement feature set. For example, if the performance index requires "single inference latency less than 1 second," the model selection and strategy synthesis unit reads the benchmark latency data stored in the attributes of each candidate model node and eliminates candidate models with latencies exceeding 1 second. Among the remaining candidate models, the model selection and strategy synthesis unit then performs a comprehensive ranking based on other indicators such as accuracy and resource consumption, selecting the model node with the highest comprehensive score as the selected model. After selecting a model, the model selection and strategy synthesis unit extracts all rule nodes associated with that model node. For each rule node, the model selection and strategy synthesis unit parses the rule description text stored in its attributes, compares the conditional part of the text with the element labels in the scenario-graph association graph, and filters out rules that match the conditions. Then, the model selection and strategy synthesis unit arranges the action parts of these rules into a sequence according to their connection order with the model nodes in the knowledge graph, forming an inference strategy. The inference strategy is stored in the form of a list, where each entry is a structured instruction object containing the operation type (such as "filtering", "normalization", "call model", "threshold judgment") and operation parameters.

[0040] Then, the deployment scheme generation module calls the configuration and interface generation unit. The configuration and interface generation unit first queries the "Runtime Environment" child node from the graph database based on the selected model node. It reads the attributes of this child node to obtain the required configuration values ​​for the runtime environment, such as the base image name, the list of dependent libraries and their version numbers, the recommended memory size, and the number of CPU cores. The configuration and interface generation unit then populates these configuration values ​​into a predefined text-formatted configuration template, generating a complete lightweight deployment configuration file. Simultaneously, the configuration and interface generation unit queries the "Input Interface" and "Output Interface" child nodes of the selected model node from the graph database, reading the data structure information defined in these child nodes, including field names, field types, field descriptions, whether they are required, and value range constraints. The configuration and interface generation unit organizes this information according to a standard interface definition language format, generating an interface specification document. The interface specification document describes the input data format, output data format, and invocation method of the model service.

[0041] S105, dynamic scheduling engine completes automated deployment In this step, the dynamic scheduling engine, as an independent, persistent service process, receives the lightweight deployment configuration file and interface specification document generated by S104, and automatically completes model loading, runtime environment isolation, data pipeline integration, task scheduling and execution, and effect verification, thereby achieving fully automated deployment from requirements to online services. Figure 6 As shown, the specific implementation is as follows: The dynamic scheduling engine first launches its resource manager component, reading the resource configuration requirements from the deployment configuration file. The resource manager initiates a system call to the host operating system kernel, requesting the creation of a new process to run the model service. Through a control group mechanism, the resource manager sets resource usage limits for this new process, including CPU usage share, memory usage limits, and I / O read / write rate limits. The resource manager also creates an isolated file system namespace, mounting the model files from the storage repository to a specified directory within that namespace. Subsequently, the resource manager calls the model loader, which dynamically loads the corresponding model parser library based on the model file format specified in the configuration file, loading the model files from disk into memory and initializing the model's computation graph.

[0042] The data source adapter component of the dynamic scheduling engine handles data integration. First, the data source adapter parses the input data format defined in the interface specification document. Then, it reads the attributes of the data nodes in the S103 scenario-graph association diagram to obtain the data source connection information. Based on the protocol type in the connection information, the data source adapter loads the corresponding connector plugin from the plugin library. For example, if the data source is a message queue, the message queue connector plugin is loaded. This plugin implements the message queue client protocol stack, enabling it to establish a long connection with the message queue server and subscribe to specified topics. If the data source is a time-series database, the database connector plugin is loaded. This plugin establishes a database connection pool and prepares to execute query statements. The data source adapter starts a background thread to continuously pull raw data from the data source. For each piece of raw data pulled, the data source adapter calls a data converter. The data converter maps the raw data to the target format according to the definitions in the interface specification document. The converter uses reflection to extract the values ​​of the corresponding fields from the raw data object based on the field names in the interface specification, converts them according to the data types defined in the specification, and finally generates a unified data object, which is then pushed into the engine's internal data pipeline.

[0043] The task scheduler component of the dynamic scheduling engine is responsible for task scheduling and execution. The task scheduler maintains a priority blocking queue. It listens for data arrival events in the data pipeline. Whenever a new data object is pushed into the pipeline, the task scheduler encapsulates it as a task instance, calculates its priority based on urgency, and places the task instance in the queue. The task scheduler runs multiple worker threads simultaneously. Each worker thread cyclically retrieves a task instance from the head of the queue and begins execution according to the inference strategy generated by S104. Each operation in the inference strategy is encapsulated as an executable unit, which the worker threads call sequentially. For example, the first executable unit calls a signal processing library to perform moving average smoothing on the numerical sequence in the data object, generating a new data object; the second executable unit takes the processed data object as input, calls the inference interface of the model instance loaded by the model loader, performs forward propagation calculation, and the model inference interface returns the calculation result; the third executable unit receives the calculation result, judges it according to the threshold rules defined in the inference strategy, and generates the final business result.

[0044] The effect validator component of the dynamic scheduling engine performs effect validation. The effect validator loads the validation rules attached to the inference strategy generated by S104. These validation rules are compiled into a set of assertion expressions, each containing an lvalue, a comparison operator, and an rvalue. The effect validator obtains the final business result generated after model execution, using the final business result as the context of the lvalue. For each assertion expression, the effect validator evaluates the truth value of the expression. For example, for an assertion expression "result confidence greater than 0.9", the effect validator extracts the value of the "confidence" field from the business result object and compares it with the rvalue 0.9. If all assertion expressions evaluate to true, the effect validator marks the business result as valid and pushes the result to the target system through the output adapter. The connection information of the target system is also obtained from the scene-graph association graph. If any assertion expression evaluates to false, the effect validator generates a validation report containing the error code, error description, and failed assertion information. The report is written to the task log file, and an alarm event is triggered. The alarm event is sent to the administrator via email or instant messaging through the engine's built-in notification plugin.

[0045] Through the above steps, the dynamic scheduling engine completes the entire process from model loading, data integration, task execution to effect verification, realizing the automated deployment of AI scenario applications.

[0046] Example 2 This invention also provides an artificial intelligence scenario application deployment system based on industry knowledge graphs, such as... Figure 7 As shown, it specifically includes: Knowledge graph construction module The knowledge graph construction module is the data foundation of the system, and it contains a data access unit, an entity relationship extraction unit, and a knowledge storage unit.

[0047] The data access unit is responsible for collecting raw data from various heterogeneous data sources. Internally, the data access unit maintains a plugin manager. This manager scans a specified directory during system startup and dynamically loads all dynamic link library files that implement the standard connector interface. Each connector plugin corresponds to a data source type, such as a database connector plugin, a file system connector plugin, or a message queue connector plugin. When the data access unit receives a configuration command, it retrieves the corresponding connector instance from the plugin manager based on the data source type specified in the configuration command. This connector instance establishes a connection with the data source based on the connection parameters (such as network address, port, and authentication credentials) provided in the configuration command. After establishing the connection, the data access unit calls the connector's data retrieval method. This method internally implements a protocol stack for interacting with the specific data source and retrieves the raw byte stream from the data source. The retrieved byte stream is then passed to the corresponding parser. The parser also employs a pluggable design, with one parser plugin corresponding to each data format. The data access unit selects the appropriate parser based on the data source's format type. The parser performs syntactic analysis on the byte stream, converting it into a collection of key-value pair objects in memory, where each key-value pair object represents a record or an entity.

[0048] The entity relation extraction unit receives a set of key-value pairs from the data access unit. The unit loads a pre-trained deep learning model based on a transformer architecture, fine-tuned for the entity relation extraction task. First, the unit concatenates the text fields of each key-value pair into a string, which serves as the model's input. The model's embedding layer maps each word in the input string to a word vector. The model's multi-layer transformer encoder performs self-attention computation on these word vectors, generating a context vector for each word that incorporates contextual information. Above the encoder's output, the entity relation extraction unit connects two independent output layers. The first output layer is a named entity recognition layer, a linear chain conditional random field layer that predicts a sequence of entity labels for each word's context vector. The conditional random field layer uses a transition probability matrix to ensure that the predicted label sequence conforms to grammatical rules. Based on the predicted label sequence, the entity relation extraction unit merges consecutive words with the same label into a single entity and records the entity's type and text content. The second output layer is the relation extraction layer. It receives all entity pairs and their context information, calculates the probability of each entity pair belonging to each of the predefined relation types using a bilinear function, and selects the relation type with the highest probability as the prediction result. The entity-relation extraction unit extracts attribute information from the corresponding original key-value pair object for each extracted entity. For example, it retrieves version information from the "version number" field and input parameter information from the "parameter list" field.

[0049] The knowledge storage unit is responsible for persisting the output of the entity relation extraction unit to the graph database. First, the knowledge storage unit establishes a network connection with the graph database service and authenticates. Then, for each entity, the knowledge storage unit performs a graph database write operation, creating a new node object. It assigns a globally unique identifier to the node, calculated using a hash algorithm based on the entity type and content, ensuring that the same entity is not created repeatedly. The knowledge storage unit uses the entity type as the node's primary label and the attributes extracted by the entity relation extraction unit as the node's attribute key-value pairs. For each relation, the knowledge storage unit performs another write operation, creating a directed edge. It first looks up the internal database identifiers of the head and tail entity nodes using the identifier, then creates an edge from that identifier to the head identifier, using the relation type as the edge's type label. After all write operations are complete, the knowledge storage unit sends a command to the graph database requesting indexes to be created for the node's primary label and frequently used attribute fields to improve subsequent query performance.

[0050] Scene Analysis Module The scene parsing module is responsible for transforming users' natural language requirements into structured data. Internally, the scene parsing module includes task decomposition units and feature annotation units.

[0051] The task decomposition unit (DMU) loads a sequence into a sequence neural network model. The encoder and decoder of this model consist of multiple layers of gated recurrent units (GRUs), and an attention mechanism is introduced. The DMU receives the user-input text and first performs word segmentation, dividing the text into word sequences. Then, it maps each word to a word vector using a word embedding matrix and inputs the word vector sequence sequentially into the encoder network. Each GRU layer in the encoder network updates its hidden state, and the hidden state of the last time step of the last GRU layer is used as the context vector for the entire input sequence. The decoder starts generating with this context vector as its initial hidden state. At each generation step, the decoder calculates the probability distribution of the next word based on the current hidden state and the word generated in the previous step, using a linear layer and a normalized exponential function. The attention mechanism calculates the matching degree between all encoder hidden states and the current decoder hidden state at each generation step, generating a weight vector. This weight vector is then used to sum the encoder's hidden states to obtain a context vector, which is concatenated with the decoder's hidden states to predict the next word. The decoder continues generating until the end-of-line character is output. The task decomposition unit removes special markers from the word sequence output by the decoder to obtain a list of subtask names.

[0052] The feature annotation unit processes each subtask output by the task decomposition unit. The feature annotation unit loads a pre-trained bidirectional encoder-representation transformer model and adds multiple task-specific output layers on top of it. For the input subtask text, the feature annotation unit first feeds it into the bidirectional encoder-representation transformer model, which outputs a vector sequence. The feature annotation unit takes the first vector in this sequence, which represents the aggregate vector describing the entire subtask, as the feature vector for that subtask. Then, the feature annotation unit inputs this feature vector in parallel into four output layers. The first output layer is a fully connected network followed by a normalized exponential function classifier to predict the input data type; its output is a probability vector representing the likelihood of belonging to each predefined input data type. The second output layer predicts the output target and has a similar structure. The third output layer is a fully connected network followed by multiple independent binary classifiers to predict business constraints; each binary classifier determines whether a specific constraint is present, such as "real-time constraint," "accuracy constraint," or "security constraint." The fourth output layer predicts performance metrics and has a similar structure to the business constraint output layer. The feature annotation unit aggregates the prediction results of the four output layers with the feature vectors of the subtasks to form a structured data object, which is stored in memory.

[0053] Mapping module The mapping module is used to establish the connection between scenario requirements and the knowledge graph. This module includes a semantic matching unit and a connection graph construction unit.

[0054] The semantic matching unit maintains a vector index that stores vector representations of all entity nodes in the knowledge graph. These vector representations are obtained through offline training using a graph embedding model, which encodes each entity node as a fixed-dimensional vector, ensuring that semantically similar nodes are closer together in the vector space. When the semantic matching unit receives a feature set representing a scenario requirement, it iterates through each feature label for each subtask. For each feature label text, the semantic matching unit first converts it into a query vector using a text encoder that employs the same encoding method as the graph embedding model. Then, the semantic matching unit performs a nearest neighbor search in the vector index. The nearest neighbor search algorithm calculates the distance between the query vector and all vectors in the index and returns the entity node identifiers corresponding to the top few vectors with the smallest distances. Based on these identifiers, the semantic matching unit sends a query to the graph database to obtain detailed information about the corresponding entity nodes, including node type, node attributes, and node relationships. The semantic matching unit stores this information, along with the query vector and distance scores, into a matching result object.

[0055] The association graph construction unit receives all matching result objects output by the semantic matching unit and the subtask list output by the task decomposition unit. First, the association graph construction unit creates a graph structure object in memory, using an adjacency list as the underlying storage. It traverses the subtask list, creating a virtual root node for each subtask, with the node attributes containing the subtask's name and sequence number. Then, the association graph construction unit traverses the matching result objects. For each matching result, it creates a directed edge between the corresponding subtask root node and the matched entity node. The edge type is "semantic mapping," and its attributes record the matched feature label and similarity score. Next, based on the subtask execution order provided by the task decomposition unit, the association graph construction unit creates directed edges between the subtask root nodes, with the edge type being "execution order." Finally, based on the relationship information between entity nodes obtained from the graph database, the association graph construction unit creates directed edges between the matched entity nodes, with the edge type consistent with the relationship type in the graph database. After all nodes and edges are created, the association graph construction unit outputs this in-memory graph structure object as the scene-graph association graph.

[0056] Deployment scheme generation module The deployment scheme generation module is responsible for generating the final deployment scheme. This module includes a graph matching engine, a model selection and strategy synthesis unit, and a configuration and interface generation unit.

[0057] The graph matching engine receives a scene-graph association graph and transforms it into a series of graph database query statements. Specifically, the graph matching engine parses the scene-graph association graph and identifies "model" type entity nodes. For each identified model node, the graph matching engine constructs a subgraph query pattern that requires finding all data nodes and rule nodes connected to the current model node through relationships such as "as input," "produce output," and "follow rules." The graph matching engine sends these query patterns to the graph database for execution using the graph database's native query language. The graph database executes the query and returns all matching subgraph structures. The graph matching engine encapsulates each returned subgraph into a candidate deployment scheme fragment object, containing the model nodes, data nodes, rule nodes, and all relationships between them in that scheme fragment.

[0058] The model selection and strategy synthesis unit receives a list of candidate deployment scheme fragments from the graph matching engine. First, the unit parses the performance indicator constraints related to the "predictive inference" subtask from the set of scenario requirement features. For each candidate scheme fragment, the unit reads the baseline performance data stored in the model node attributes, such as average inference latency, peak resource consumption, and accuracy. The unit compares this baseline data with the performance indicator constraints, filtering out candidate schemes that meet all hard constraints. For the remaining schemes, the unit calculates a score for each scheme according to a pre-defined comprehensive scoring formula. This formula weights and sums indicators such as accuracy, latency, and resource consumption. The unit selects the scheme with the highest score as the final selected scheme. After selecting a scheme, the unit extracts the attributes of all rule nodes in that scheme, arranges the rule description text according to its connection order in the scheme, and parses it into a structured sequence of operation instructions. Each operation instruction is an object containing an operation name and a dictionary of operation parameters.

[0059] The configuration and interface generation unit receives the selected scheme and the generated sequence of operation instructions. First, it queries the "Runtime Environment" child node of the selected model node from the knowledge graph. The unit reads the attributes of this child node and obtains the storage path of the runtime environment configuration template. It loads the template file from the file system, which contains variable placeholders. This unit fills the variable placeholders in the template with the attribute values ​​of the model node (such as model name and model version) and environment configuration values ​​(such as dependency library versions), generating the final lightweight deployment configuration file. For the interface specification, the unit queries the "Input Interface" and "Output Interface" child nodes of the selected model node from the knowledge graph. It reads the data structure descriptions defined in these child nodes, including field names, field types, and field constraints. The unit organizes this descriptive information into a document object according to the interface definition language format and then calls a serialization method to convert the document object into a text-formatted interface specification file.

[0060] Dynamic scheduling engine The dynamic scheduling engine is the core of the system's execution, and internally it is a microservice architecture composed of multiple components.

[0061] The resource manager component is responsible for preparing the runtime environment for model instances. Upon startup, the resource manager component reads the resource configuration from the deployment configuration file. It then starts a new process as the runtime container for the model service by calling the operating system's process creation interface. Before creating the process, the resource manager sets resource limits for the new process through control group system calls. Specifically, it sets a CPU usage share to ensure the model service doesn't consume excessive processor resources; it sets a memory usage limit to prevent memory leaks from causing system crashes; and it sets an I / O read / write rate limit to avoid disk I / O overload. The resource manager also mounts the model storage path from the configuration file into the new process's file system namespace, enabling the process to access model files.

[0062] The data source adapter component is responsible for establishing connections with external data sources. During initialization, the data source adapter component parses the interface specification document to obtain the input data format definition. Then, it reads the connection attributes of data nodes in the scene-graph association graph. Based on the protocol type in the connection attributes, the data source adapter dynamically loads the corresponding connector class through a service loader mechanism. The connector class implements a unified data retrieval interface. The data source adapter instantiates the connector and passes in the connection parameters. Internally, the connector establishes a network connection based on the protocol type. For message queue protocols, the connector establishes a Transmission Control Protocol connection and sends a subscription request; for database protocols, the connector establishes a database session and prepares the query statement. The data source adapter starts a loop thread that repeatedly calls the connector's data retrieval method to obtain raw data. For each piece of raw data obtained, the data source adapter calls a reflection-based data converter to convert the raw data into a standard data object according to the field mapping rules in the interface specification and places it in a blocking queue.

[0063] The task scheduler component manages task execution. It maintains a priority queue, where each element is a pending task instance. The scheduler starts a background thread that continuously monitors the data source adapter's blocking queue. Whenever a new data object appears in the blocking queue, the scheduler creates a new task instance, encapsulates the data object within it, calculates the task's priority based on the data object's priority field, and inserts the task instance into the priority queue. The scheduler also maintains a fixed-size thread pool. Each worker thread in the thread pool performs the following operations in a loop: retrieves a task instance from the head of the priority queue; obtains the list of inference policy operation instructions associated with the task instance; iterates through the operation instruction list sequentially, and for each instruction, obtains the corresponding operation executor instance using a factory pattern based on the operation name in the instruction; calls the operation executor's execution method, passing in the instruction parameters and the current data object; the operation executor performs the specific calculations and returns a new data object; the returned data object is used as input for the next operation; after all operations are completed, the final data object is passed to the effect validator.

[0064] The effect validator component receives the final data object from the task scheduler. It loads the validation rules from the inference strategy, stored as assertion expressions. The validator iterates through all assertion expressions, evaluating each one using an expression evaluator within the context of the data object. If all assertions evaluate to true, the validator marks the data object as valid and pushes it to the target system via the output adapter. The output adapter functions similarly to the data source adapter, loading the appropriate connector based on the target system's type and serializing the data object before sending it. If any assertion evaluates to false, the validator generates an error report object containing a description of the failed assertion, key information about the current data object, and a timestamp. The validator writes the error report to a log file and invokes the alert manager. The alert manager reports the deployment anomaly to the administrator via email through a simple mail transfer protocol or a message through an instant messaging bot, based on pre-configured notification channels.

[0065] Through the collaborative work of the above modules and their internal components, this system achieves complete functionality from knowledge graph construction to automated deployment of scenario applications.

[0066] Example 3 The present invention also provides an electronic device, including: a processor, a transmitting device, an input device, an output device, and a memory. The processor may be implemented using a general-purpose CPU (Central Processing Unit), a microprocessor, an application-specific integrated circuit, or one or more integrated circuits, and is used to execute relevant programs to implement the technical solutions provided in the embodiments of this application. The memory may be implemented using a read-only memory (ROM), a static storage device, a dynamic storage device, or a random access memory (RAM), and is used to store computer program code. The computer program code includes computer instructions. When the processor executes the computer instructions, the electronic device executes a method as described in any of the above possible implementation methods.

[0067] Example 4 The present invention also provides a computer-readable storage medium storing a computer program, the computer program including program instructions, which, when executed by a processor of an electronic device, cause the processor to perform a method as described in any of the above possible implementations.

[0068] In the description of this specification, the references to terms such as "an embodiment," "example," "specific example," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of the present invention. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples.

[0069] The above description is merely a specific embodiment of the present invention, enabling those skilled in the art to understand or implement the invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the invention. Therefore, the present invention is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features claimed herein.

Claims

1. A method for deploying artificial intelligence scenario applications based on industry knowledge graphs, characterized in that, Includes the following steps: Receive scenario requirements input in natural language text, decompose the scenario requirements into a task list to generate a sub-task list, and perform feature annotation on each sub-task to generate a scenario requirement feature set containing sub-task feature vectors and key element labels. The text of each element label in the scenario demand feature set is mapped to a query vector through a graph embedding model. The cosine similarity between the query vector and the pre-trained embedding vector of each entity node in the industry knowledge graph is calculated. Entity nodes with similarity exceeding a preset threshold are selected as candidate mapping nodes. A scenario-graph association graph containing task nodes, entity nodes and semantic mapping edges between them is constructed based on the sub-task list and candidate mapping nodes. Starting with the entity nodes associated with the prediction and inference subtask in the scene-graph association graph, a breadth-first search-based subgraph matching is performed in the industry knowledge graph to find model nodes connected by specified relation edges and labeled as artificial intelligence models, as well as data nodes and rule nodes associated with the model nodes. Each model node and its associated nodes are treated as a subgraph. The matching degree between the subgraph and the corresponding part in the scene-graph association graph is calculated using a weighted scoring function. The model node with the highest matching degree is selected as the selected AI model, and the rule nodes associated with the model node are extracted to generate an inference strategy.

2. The method according to claim 1, characterized in that, The construction of the industry knowledge graph includes: obtaining raw data from heterogeneous data sources through the data access submodule and converting it into a set of key-value pairs; extracting entities and relationships from the set of key-value pairs through a deep neural network model based on a transformer architecture, and extracting attribute information of the entities; writing the extracted entities and relationships into a graph database, setting globally unique identifiers and labels for entity nodes, creating directed edges for relationships, and creating indexes for node labels and attribute fields.

3. The method according to claim 1, characterized in that, The task decomposition is achieved through a sequence-to-sequence neural network model, which includes an encoder composed of a multi-layer bidirectional long short-term memory network and a decoder composed of a multi-layer long short-term memory network. The task decomposition specifically includes: converting the natural language text required by the scenario into a word vector sequence and inputting it into the encoder to generate a context vector; the decoder generates an output sequence word by word with the context vector as the initial state; and the output sequence constitutes a sub-task list.

4. The method according to claim 1, characterized in that, The feature annotation is implemented through a bidirectional encoder-representation transformer model, specifically including: inputting the text description of each subtask into the model, taking the first vector in the vector sequence output by the model as the feature vector of that subtask; inputting the feature vector in parallel into multiple output branches, the output branches including input data type branch, output target branch, business constraint branch, and performance index branch, each branch outputting a corresponding element label; aggregating the feature vector and element label of each subtask to form a subtask feature object, and all subtask feature objects constitute a scenario requirement feature set.

5. The method according to claim 1, characterized in that, The construction of the scenario-graph association graph further includes: creating a virtual task node for each subtask, creating a semantic mapping edge between the task node and the candidate mapping node and recording a similarity score in the attributes of the edge, adding directed edges between task nodes according to the execution order of the subtasks, and creating edges between candidate mapping nodes according to the existing relationships in the industry knowledge graph.

6. The method according to claim 1, characterized in that, The generation reasoning strategy further includes: extracting all rule nodes associated with the selected model node, parsing the rule description text stored in the attributes of each rule node; comparing the condition part in the rule description text with the element labels in the scene-graph association graph, and filtering out the rules that match the conditions; arranging the action part of the filtered rules according to their connection order with the model node in the knowledge graph, and generating a structured operation instruction sequence containing operation type and operation parameters as the reasoning strategy.

7. The method according to claim 1, characterized in that, The method further includes: querying the operating environment sub-nodes, input interface sub-nodes, and output interface sub-nodes of the selected AI model from the industry knowledge graph, and generating a lightweight deployment configuration file and interface specification document.

8. The method according to claim 7, characterized in that, The method also includes: using a dynamic scheduling engine, automatically completing model loading, runtime environment isolation, data pipeline connection, task scheduling and execution, and effect verification based on the lightweight deployment configuration file and interface specification document, thereby achieving automated deployment.

9. The method according to claim 8, characterized in that, The dynamic scheduling engine automatically completes the isolation of model loading and runtime environment, specifically including: the resource manager sets the resource usage limit for the model service process through the control group mechanism and creates an isolated file system namespace; the model loader dynamically loads the model parsing library, loads the model file into memory and initializes the model's computation graph.

10. The method according to claim 8, characterized in that, The dynamic scheduling engine automatically completes the effect verification in the following ways: the effect verifier loads the verification rules attached to the inference strategy, and the verification rules are compiled into a set of assertion expressions; the final business result generated after the model is executed is obtained, and the truth value of each assertion expression is calculated; if all assertions are true, the business result is pushed to the target system; if any assertion is false, a verification report is generated and an alarm event is triggered.

Images