Knowledge scheduling method and device of intelligent agent, electronic equipment and storage medium

Abstract

Embodiments of the present disclosure provide a knowledge scheduling method and device of an agent, an electronic device and a storage medium. The method comprises: for each task stage in a task sequence comprising a plurality of task stages: determining a target domain knowledge unit corresponding to the task stage from a plurality of domain knowledge units; loading the target domain knowledge unit into a context of the agent, so that the agent executes a task in the task stage based on the context, wherein the context does not include other domain knowledge units in the plurality of domain knowledge units except the target domain knowledge unit; in response to completion of execution of the task in the task stage, unloading the target domain knowledge unit from the context of the agent, and an execution environment of the agent remains running in the execution process of all task stages in the task sequence. The method can reduce information forgetting and illusion caused by context overflow of the agent, and realize complete end-to-end model adaptation within a limited agent context budget.

Description

Technical Field

[0001] Embodiments of this disclosure relate to the field of artificial intelligence, specifically to a knowledge scheduling method and apparatus for an intelligent agent, an electronic device, and a storage medium. Background Technology

[0002] With the continuous development of Artificial Intelligence (AI) technology, AI processors have become crucial hardware devices supporting the training and inference of deep learning models. Operators are the basic units for building deep learning models, and their execution efficiency determines the overall performance of the model. Existing underlying hardware architectures exhibit significant diversity and heterogeneity, making efficient cross-hardware adaptation of models a problem that needs to be solved. Summary of the Invention

[0003] This disclosure provides at least one embodiment of a knowledge scheduling method for an intelligent agent. The method is applied to a single intelligent agent and includes: for each task stage in a task sequence comprising multiple task stages: determining a target domain knowledge unit corresponding to the task stage from multiple domain knowledge units; loading the target domain knowledge unit into the context of the intelligent agent, so that the intelligent agent executes the task in the task stage based on the context, wherein the context does not include other domain knowledge units besides the target domain knowledge unit from the multiple domain knowledge units; and unloading the target domain knowledge unit from the context of the intelligent agent in response to the completion of task execution in the task stage, wherein the execution environment of the intelligent agent remains operational throughout the execution of all task stages in the task sequence.

[0004] In the method provided in at least one embodiment of this disclosure, at least one of the plurality of domain knowledge units includes business processing rules for the corresponding domain, a list of reference documents, and a list of external skill packs.

[0005] In a method provided in at least one embodiment of this disclosure, the domain knowledge unit is configured to invoke reference documents in the reference document list and external skill packages in the external skill package list according to the business processing rules.

[0006] In the method provided in at least one embodiment of this disclosure, different domain knowledge units correspond to different lists of reference documents.

[0007] The method provided in at least one embodiment of this disclosure further includes: determining the task sequence based on the forward propagation running state of the model to be adapted on the target hardware device.

[0008] In at least one embodiment of the method provided in this disclosure, when the task stage corresponds to multiple target domain knowledge units, the step of loading the target domain knowledge units into the context of the agent so that the agent can execute the task in the task stage based on the context includes: loading the multiple target domain knowledge units into the context of the agent so that the agent can execute the tasks corresponding to the multiple target domain knowledge units in parallel based on the context.

[0009] In the method provided in at least one embodiment of this disclosure, the plurality of domain knowledge units correspond one-to-one with a plurality of domains, and the plurality of domains are divided according to the degree of correlation between multiple links in the model adaptation process.

[0010] In the method provided in at least one embodiment of this disclosure, the plurality of fields include: model evaluation field, framework integration field, distributed strategy field, operator routing field, communication library field, and toolchain field.

[0011] In at least one embodiment of the method provided in this disclosure, the method is performed by the intelligent agent.

[0012] The method provided in at least one embodiment of this disclosure further includes: in response to the completion of task execution in the task phase, writing the execution result of the task into a status log file for reading in subsequent task phases.

[0013] At least one embodiment of this disclosure provides a knowledge scheduling apparatus for an intelligent agent. The apparatus, applied to a single intelligent agent, includes: a determination module configured to determine a target domain knowledge unit corresponding to each task stage from a plurality of domain knowledge units for each task stage in a task sequence comprising multiple task stages; a loading module configured to load the target domain knowledge unit into the context of the intelligent agent, so that the intelligent agent executes the task in the task stage based on the context, wherein the context does not include other domain knowledge units besides the target domain knowledge unit from the plurality of domain knowledge units; and an unloading module configured to unload the target domain knowledge unit from the context of the intelligent agent in response to the completion of task execution in the task stage, wherein the execution environment of the intelligent agent remains operational throughout the execution of all task stages in the task sequence.

[0014] At least one embodiment of this disclosure provides an electronic device including at least one processor and at least one memory, wherein the at least one memory stores program code that, when executed by the at least one processor, causes the at least one processor to perform the method according to at least one embodiment of this disclosure.

[0015] At least one embodiment of this disclosure provides a non-transitory computer-readable storage medium having computer-readable instructions stored thereon, which, when executed by at least one processor, cause the at least one processor to perform the method according to at least one embodiment of this disclosure.

[0016] In the knowledge scheduling method, apparatus, electronic device, and storage medium for intelligent agents provided in at least one embodiment of this disclosure, the adaptation knowledge in the AI ​​model adaptation pipeline is decomposed into multiple independent domain knowledge units according to the business domain. A scheduler without any domain knowledge loads each domain knowledge unit into the context of the intelligent agent on demand with delayed loading, eliminating the need to load all knowledge at once. This reduces information forgetting and illusions caused by context overflow, improving the adaptation success rate and achieving complete end-to-end model adaptation within a limited intelligent agent context budget. Furthermore, the intelligent agent maintains its running state throughout the entire process, dynamically loading and unloading knowledge only from its context, without frequently rebuilding the execution environment. This mechanism not only effectively avoids resource fragmentation caused by frequent creation and destruction of the execution environment but also ensures the continuity of the intelligent agent's inference state, thereby solving the problems of state loss and context breakage during long task execution.

[0017] Furthermore, this scheme enables communication between domain knowledge units through structured pipeline states and supports the parallel execution of independent domain knowledge units, further improving model adaptation efficiency. Moreover, domain knowledge units can be maintained independently, effectively reducing the maintenance cost of the knowledge system; new domains can be added by expanding the domain knowledge units within the agent's context, without modifying the scheduler logic or creating new agents or execution environments. Attached Figure Description

[0018] To more clearly illustrate the technical solutions of the embodiments of this disclosure, the accompanying drawings of the embodiments will be briefly described below. Obviously, the drawings described below only relate to some embodiments of this disclosure and are not intended to limit this disclosure.

[0019] Figure 1 This is a flowchart of a knowledge scheduling method for an intelligent agent provided in at least one embodiment of the present disclosure.

[0020] Figure 2 A flowchart of another knowledge scheduling method for an intelligent agent provided in at least one embodiment of this disclosure.

[0021] Figure 3 This is a schematic block diagram of a model adaptation system provided for at least one embodiment of the present disclosure.

[0022] Figure 4 An interaction sequence diagram of a model adaptation system provided in at least one embodiment of this disclosure.

[0023] Figure 5 This is a schematic block diagram of a knowledge scheduling device for an intelligent agent, provided for at least one embodiment of the present disclosure.

[0024] Figure 6 This is a schematic block diagram of an electronic device provided for at least one embodiment of the present disclosure.

[0025] Figure 7 This is a schematic block diagram of another electronic device provided for at least one embodiment of the present disclosure.

[0026] Figure 8 This is a schematic block diagram of a non-transitory computer-readable storage medium provided for at least one embodiment of the present disclosure. Detailed Implementation

[0027] To make the objectives, technical solutions, and advantages of the embodiments of this disclosure clearer, the technical solutions of the embodiments of this disclosure will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this disclosure. All other embodiments obtained by those skilled in the art based on the described embodiments of this disclosure without creative effort are within the scope of protection of this disclosure.

[0028] Unless otherwise defined, the technical or scientific terms used in this disclosure shall have the ordinary meaning understood by one of ordinary skill in the art to which this disclosure pertains. The terms “first,” “second,” and similar terms used in this disclosure do not indicate any order, quantity, or importance, but are merely used to distinguish different components. Terms such as “comprising” or “including” mean that the element or object preceding the word encompasses the elements or objects listed following the word and their equivalents, without excluding other elements or objects. Terms such as “connected” or “linked” are not limited to physical or mechanical connections, but can include electrical connections, whether direct or indirect. Terms such as “upper,” “lower,” “left,” and “right” are used only to indicate relative positional relationships, and these relative positional relationships may change accordingly when the absolute position of the described objects changes.

[0029] The present disclosure will now be described through several specific embodiments. To keep the following description of the embodiments of the present disclosure clear and concise, detailed descriptions of known functions and known components may be omitted. When any component of an embodiment of the present disclosure appears in more than one drawing, the component is represented by the same or similar reference numerals in each drawing.

[0030] A neural network model can be viewed as a directed acyclic graph (DAG) composed of multiple nodes, where each node corresponds to an operator. Operators in a neural network typically refer to the basic mathematical operations or processes used in the network layers. These operators are used to construct the various layers and components of the network, enabling data transfer, transformation, and computation. Operators are the fundamental building blocks of a network model, defining its structure and computational flow, including inputs, outputs, and intermediate computations. In the model, the connections between operators form a directed graph, reflecting the order of computation for different operations. By combining these operators, complex and powerful neural network models can be constructed to handle various complex tasks and data. Some examples of operators include convolution, pooling, loops, activation functions, normalization, matrix multiplication, and element-wise operations.

[0031] The operator kernel is the underlying implementation of the operator. It can be written in a low-level language (such as C++) and manifested as a device program (for example, it can be executed on hardware devices such as graphics processing units, GPUs) that describes the operator's execution process. It is the logic that drives the operator's function to run efficiently on the specified hardware and is responsible for translating the mathematical definition of the operator into an actual sequence of hardware instructions.

[0032] With the rapid development of AI applications such as Large Language Models (LLM), visual models, and diffusion models, the demand for computing power in AI inference and training is growing exponentially. Currently, the operator ecosystem of mainstream AI frameworks (such as PyTorch) is highly dependent on specific computing libraries and programming models. When migrating existing AI models from general-purpose GPU platforms to heterogeneous hardware platforms (such as dedicated accelerator chips), a severe bottleneck in operator compatibility is generally encountered. Because the operator libraries of target hardware devices often cannot fully cover all computational primitives of the model, some operators are forced to fall back to execution by the central processing unit (CPU) or even fail to run, thus severely restricting the deployment efficiency and performance release of models in heterogeneous computing environments.

[0033] A flattened multi-agent pipeline model adaptation method decomposes model adaptation into multiple steps (e.g., environment verification, operator analysis, coverage checking, operator generation, framework integration, verification, deployment, and optimization), with each step executed by a dedicated agent, scheduled linearly by an orchestration agent. However, this method leads to domain knowledge fragmentation. Specifically, the flattened multi-agent architecture divides agents according to steps, but the steps do not correspond one-to-one with the business domain. For example, "distributed strategy selection" and "cluster performance simulation" belong to the same business domain but are split into different step agents, resulting in domain knowledge fragmentation. Maintenance requires simultaneous updates of multiple non-cohesive files. Furthermore, in the aforementioned flattened architecture, the maintenance and accuracy verification of multi-domain reference documents are not clearly defined, leading to a lack of responsible parties during document updates. When information becomes outdated or content conflicts arise, effective handling is impossible, reducing the efficiency and accuracy of data management. Moreover, the aforementioned multi-agent architecture relies on complex interaction protocols, distributed state consistency maintenance, and cross-node resource scheduling, resulting in high communication overhead, environment switching overhead, and computational latency.

[0034] One model adaptation method based on monolithic skill documents compiles all model adaptation knowledge into a single skill document (e.g., a SKILL.md file with over 1000 lines), and the agent loads all knowledge at once during execution. However, the monolithic skill document method leads to the context explosion problem. Specifically, as the model adaptation knowledge grows to a certain scale, it exceeds the agent's context window capacity (typically 128K-200K vocabularies), causing key information to be truncated or forgotten. For example, if reference documents from all domains (e.g., inference deployment, internal implementation of communication libraries, accuracy standards, etc.) are loaded simultaneously, it may consume over a million vocabularies, far exceeding the agent's context window capacity, causing the model adaptation task to fail.

[0035] Furthermore, the linear pipelines of the two methods described above force sequential execution, which means that even if operator development and communication library configuration are completely independent, they must still be executed sequentially, increasing the total adaptation time.

[0036] Furthermore, existing schedulers typically embed domain-specific decision logic (e.g., "hybrid expert models require expert parallelism"), necessitating synchronous modifications when domain knowledge is updated. This unnecessary coupling violates the separation of concerns principle, blurring the boundaries between functional modules and making independent maintenance and expansion difficult.

[0037] In summary, as the complexity of AI accelerator chip model adaptation tasks continues to increase, traditional linear pipeline or flat multi-agent architectures face severe context management problems: for single-skill document solutions, the complete model adaptation knowledge far exceeds the context window capacity of large language model agents, and loading at once leads to context explosion; at the same time, in flat multi-agent architectures, each step agent exists independently, lacking business domain cohesion, resulting in problems such as knowledge fragmentation, unclear attribution of referenced materials, and difficulty in independent evolution.

[0038] This disclosure provides at least one embodiment of a knowledge scheduling method and apparatus for an intelligent agent, an electronic device, and a storage medium.

[0039] The knowledge scheduling method for an intelligent agent provided in at least one embodiment of this disclosure includes: for each task stage in a task sequence comprising multiple task stages: determining a target domain knowledge unit corresponding to the task stage from multiple domain knowledge units; loading the target domain knowledge unit into the context of the intelligent agent so that the intelligent agent executes the task in the task stage based on the context, wherein the context does not include other domain knowledge units besides the target domain knowledge unit from the multiple domain knowledge units; and unloading the target domain knowledge unit from the context of the intelligent agent in response to the completion of the task execution in the task stage, wherein the execution environment of the intelligent agent remains running throughout the execution of all task stages in the task sequence.

[0040] The knowledge scheduling method for intelligent agents provided in at least one embodiment of this disclosure can be applied to single-agent scenarios where the agent operates independently and the context state is centrally managed. Unlike multi-agent architectures (i.e., distributed systems in which multiple agents work collaboratively through communication mechanisms), this solution does not need to handle common state conflicts, communication delays, and environment switching overheads among multiple agents, and focuses on the dynamic loading and unloading of knowledge within the context of a single agent.

[0041] In the knowledge scheduling method for intelligent agents provided in at least one embodiment of this disclosure, the adaptation knowledge in the AI ​​model adaptation pipeline is decomposed into multiple independent domain knowledge units according to the business domain. A scheduler without any domain knowledge loads each domain knowledge unit into the intelligent agent's context on demand with a delay, eliminating the need to load all knowledge at once. This reduces information forgetting and illusions caused by context overflow, improving the adaptation success rate and achieving complete end-to-end model adaptation within a limited intelligent agent context budget. Furthermore, the intelligent agent maintains its running state throughout the entire process, dynamically loading and unloading knowledge only from its context, without frequently rebuilding the execution environment. This mechanism not only effectively avoids resource fragmentation caused by frequent creation and destruction of the execution environment but also ensures the continuity of the intelligent agent's inference state, thus solving the problems of state loss and context breakage during long task execution.

[0042] Figure 1 This is a flowchart of a knowledge scheduling method for an intelligent agent provided in at least one embodiment of the present disclosure.

[0043] For example, such as Figure 1 As shown, the knowledge scheduling method for an intelligent agent provided in at least one embodiment of this disclosure is applied to a single intelligent agent and may include: performing the following steps S101 to S103 for each task stage in the task sequence, wherein the execution environment of the intelligent agent remains running during the execution of all task stages in the task sequence.

[0044] S101: Determine the target domain knowledge unit corresponding to this task stage from multiple domain knowledge units.

[0045] S102: Load the target domain knowledge unit into the agent's context so that the agent can perform the task in this task phase based on the context, wherein the context does not include other domain knowledge units besides the target domain knowledge unit among the multiple domain knowledge units.

[0046] S103: In response to the completion of the task in this task phase, unload the target domain knowledge unit from the agent's context.

[0047] For example, each task stage in the task sequence can be traversed, and steps S101 to S103 can be executed sequentially for the currently traversed task stage. During this process, the agent's execution environment remains running and is not rebuilt or destroyed when task stages are switched. This means that the agent does not need to repeatedly initialize the execution environment between task stages, but only dynamically loads and unloads the knowledge in the context. The agent itself remains online and is not affected by task stage switching.

[0048] For example, an agent, also known as an AI agent, is an intelligent entity capable of environmental perception, autonomous planning, task execution, result reflection, and tool invocation. Its context represents the agent's dynamic state space during operation, used to store and maintain state information including short-term memory, historical interaction records, environmental observation data, and current task objectives, to support continuous logical reasoning and decision generation. In other words, the agent's context can be the set of information that the agent relies on when making decisions, reasoning, or executing tasks at a specific moment.

[0049] For example, in step S101, the task sequence may consist of multiple task stages, and different task stages may correspond to different domain knowledge units. In other words, tasks in different task stages need to be executed based on different domain knowledge units. In some examples, multiple task stages may correspond to the same domain knowledge unit, and this disclosure does not limit this. For example, a domain knowledge unit can be used to instruct an agent to perform tasks related to the corresponding domain. In some examples, a domain knowledge unit may include a structured skill description file, such as an instruction configuration file written in a markup language (markdown). After being loaded into the agent context, it can instruct the agent to perform tasks related to the domain corresponding to the domain knowledge unit. Hereinafter, this skill description file will also be referred to as a business processing rule.

[0050] For example, in step S102, only the target domain knowledge unit determined in step S101 can be loaded into the agent's context, without loading other domain knowledge units besides the target domain knowledge unit. In other words, in step S102, only the domain knowledge units required for executing the currently traversed task stage (i.e., the target domain knowledge unit) are loaded, while domain knowledge units not needed for executing this task stage are not loaded into the agent's context, thus saving context space. The above steps are also called lazy loading, which is an on-demand loading strategy where resources are only loaded into memory (or context window) when they are first needed.

[0051] It should be noted that during the initialization phase, the agent's context does not include any domain knowledge units. Therefore, after executing step S102, the agent's context includes the target domain knowledge unit, but does not include other domain knowledge units besides the target domain knowledge unit among the multiple domain knowledge units.

[0052] In step S103, after the task in the currently traversed task stage has been completed, the target domain knowledge unit loaded in step S102 can be unloaded from the agent's context. In some examples, unloading can represent a normal removal operation, such as removing the target object (i.e., the target domain knowledge unit) from the context; in other examples, unloading can also represent a complete removal operation, which includes not only removing the target object from the context, but also clearing the storage space occupied by the target object in the context's state space, terminating the loading state of the instruction set or execution logic associated with the target object, and releasing the agent's reference relationship to the target object and its associated resources. It should be noted that in this embodiment, the unloading operation targets knowledge data and does not involve the destruction of the agent itself or its execution environment. The specific unloading method can be selected according to actual needs, and this embodiment does not limit this. Through the above unloading operation, the target object can be stripped from the agent's current running environment, thereby releasing the corresponding context window resources and restoring the agent to its initial state before the target object was loaded.

[0053] In the knowledge scheduling method provided in at least one embodiment of this disclosure, the adaptation knowledge in the AI ​​model adaptation pipeline is decomposed into multiple independent domain knowledge units according to business domains. A scheduler without any domain knowledge loads each domain knowledge unit into the agent's context on demand with a delay, eliminating the need to load all knowledge at once. This reduces information forgetting and illusions caused by context overflow, improving the adaptation success rate and achieving complete end-to-end model adaptation within the limited agent context budget. Furthermore, the agent maintains its running state throughout the entire process, dynamically loading and unloading knowledge only from its context, without frequently rebuilding the execution environment. This mechanism not only effectively avoids resource fragmentation caused by frequent creation and destruction of the execution environment but also ensures the continuity of the agent's reasoning state, thus solving the problems of state loss and context breakage during long task execution. Correspondingly, domain knowledge units can be maintained independently, effectively reducing the maintenance cost of the knowledge system; new domains can be added by expanding the context of the agent with new domain knowledge units, without modifying the scheduler logic or creating new agents or execution environments.

[0054] In some examples, assuming the total set of knowledge involved in the model adaptation is K, it can be divided into n pairwise disjoint domain knowledge units (subsets). : ,in

[0055] For example, the entire set of knowledge can be divided according to the cohesion of business domains to avoid the fragmentation of domain knowledge.

[0056] In some examples, the model adaptation process can be divided into multiple domains, with knowledge units in each domain corresponding one-to-one with the domain itself. For instance, following the principle of high cohesion and low coupling, multiple domains can be determined based on the degree of correlation between various stages in the model adaptation process. This maximizes the correlation between processing stages within the same domain while minimizing the correlation between different domains.

[0057] For example, taking the distributed strategy selection and cluster performance simulation in the model adaptation process as examples, cluster performance simulation can provide an evaluation basis for distributed strategy selection, while the selected distributed strategy is the input of cluster performance simulation. Therefore, the two are highly related and can be classified into the same domain (e.g., the distributed strategy domain).

[0058] In some examples, the aforementioned domains may include at least one of the following: model evaluation domain, framework integration domain, distributed strategy domain, operator routing domain, communication library domain, and toolchain domain.

[0059] In some examples, the aforementioned domains may include model evaluation, framework integration, distributed strategy, operator routing, communication library, and toolchain.

[0060] Correspondingly, the complete set of knowledge involved in model adaptation can be divided into 6 pairwise disjoint domain knowledge units. .in, For model evaluation of domain knowledge units, To integrate domain knowledge units into the framework. As a knowledge unit in the distributed strategy domain, For operator routing domain knowledge units, As a knowledge unit in the communication library domain, This is a knowledge unit in the toolchain domain.

[0061] It should be noted that the above number of subsets and the corresponding domains of each subset are only examples. Different division methods can be adopted according to actual needs, and this disclosure does not limit this.

[0062] For example, model-based evaluation of domain knowledge units can perform operations such as architecture analysis, weight preparation, operator analysis, operator coverage checking, operator probing, dataset validation, and acceptance gating.

[0063] For example, architecture analysis operations involve performing multi-level structural analysis on the model to be adapted. By traversing the model's computation graph, module partitioning, weight lists, parallel strategies, and operator extraction rules are extracted to construct a model topology description file, which clarifies the model's deployment form and resource mapping relationships on the target hardware device. Specifically, this can be achieved by identifying end-to-end pipeline stage decomposition to clarify the computational flow of each processing stage, analyzing the model structure (e.g., hybrid expert layer, visual backbone network, adapter injection points, etc.) to construct a refined module topology, statistically analyzing the parameter quantity and data type of each module to form a weight list, and combining computational characteristics to generate preliminary suggestions for parallel strategies such as pipeline parallelism, expert parallelism, and tensor parallelism. The output is a description file containing the model's deployment form and resource mapping relationships (e.g., in JSON or a mix of Markdown and JSON).

[0064] For example, the model can be a machine learning model, such as a deep learning model. Deep learning models can be neural network structures comprising multiple layers (3, 4, 8, or more), such as Convolutional Neural Networks (CNNs), Recurrent Neural Networks (RNNs), and Long Short-Term Memory (LSTM) networks. These neural network structures typically include input layers, hidden layers, and output layers. Hidden layers are those layers located between the input and output layers; they are also called processing layers. The input layer receives the data to be processed, such as the image to be processed, and the output layer outputs the processing result, such as the processed image. Processing layers can include convolutional layers, pooling layers, batch normalization layers, fully connected layers, etc. Depending on the structure of the neural network, the processing layers can include different content and combinations. In some examples, the model can be an artificial intelligence model with a large number of parameters built from an artificial intelligence network (also known as a large-scale artificial intelligence model, or simply a "large model"). Large-scale models can be content generation models based on prompt words, such as Large Language Models (LLMs), large-scale visual models, or large-scale multimodal models. Examples include models based on Transformer architectures, recurrent neural networks, attention mechanisms, diffusion models, and multimodal models. This disclosure does not limit the specific type, structure, or implementation of the model.

[0065] For example, the target hardware device refers to the hardware device that the operators in the model need to adapt to. The hardware device may be an artificial intelligence processor, which may include a graphics processing unit (GPU), a general-purpose graphics processing unit (GPGPU), a tensor processing unit (TPU), a deep learning processing unit (DPU), an accelerated processing unit (APU), a neural network processing unit (NPU), an application-specific integrated circuit (ASIC), or a field-programmable gate array (FPGA), etc. The embodiments disclosed herein do not impose any limitations on this.

[0066] For example, the weight preparation and format conversion operations involve adapting the weight list output by the architecture analysis to a new format and optimizing its memory layout. By using static conversion tools or runtime conversion operators, the source framework weight data is converted into a binary format supported by the target hardware. Memory alignment and quantization parameter embedding are then performed to eliminate weight storage differences between different hardware backends, ensuring parameter consistency and reading efficiency during model operation.

[0067] For example, operator analysis operations can represent a complete analysis of the model to be adapted, traversing the model computation graph to extract all operator nodes, constructing an operator list and counting the type, input and output shape and attribute parameters of each operator, which is used to identify the full set of operators in the model that need to be adapted, generated or require special processing, and to ensure the integrity of the model adaptation range.

[0068] For example, operator coverage checking can involve statistically analyzing the adaptation status of the entire operator list using at least one of dynamic and static analysis techniques. This calculates the ratio of supported operators to the total number of operators, quantitatively assessing the target hardware's support for the model to be adapted and identifying operator gaps that are not yet adapted. Static analysis, without executing code, involves parsing and pattern matching the model computation graph or operator source code to identify and statistically analyze the registered operator interfaces in the current runtime environment (e.g., deep learning framework or hardware backend), quickly assessing the static support of the operator list. Dynamic analysis, during the actual execution of test cases or simulated model forward propagation, uses runtime data acquisition mechanisms such as hardware performance counters (PFC) or profilers to track and record the actual call trajectory and execution status of operators in real time, identifying operator gaps that are not covered by runtime dependencies or conditional branches.

[0069] For example, operator probing can refer to loading and executing an operator in an actual hardware device (e.g., the target hardware device) or a simulation environment of the hardware device, collecting the low-level state of the operator during runtime through a hardware performance counter or performance monitor, diagnosing and classifying operator error types (e.g., hardware abnormal interruption, numerical overflow, or precision deviation), thereby locating the cause of operator execution failure.

[0070] For example, dataset verification can be performed at the end of the model adaptation process. Based on the complexity of the model adaptation task and the verification objective, the verification dataset is divided into multiple levels such as functional correctness dataset, accuracy alignment dataset, and performance stress test dataset. According to the preset verification strategy, model inference and result comparison are performed on each level of dataset in turn. This is used to determine the logical correctness, numerical accuracy consistency, and operational stability of the model on the target hardware in a hierarchical manner while controlling the verification cost.

[0071] For example, acceptance gating can represent setting a quality gating mechanism in the final stage before model adaptation and delivery. By using the output results of aggregation operator coverage checks, static and dynamic analysis, and dataset hierarchical verification, the adaptation completion rate and accuracy loss rate are calculated, and the indicators are compared with preset acceptance thresholds. This allows release when the model adaptation quality is confirmed to meet the standards, or prohibits release when problems such as missing operators or abnormal accuracy are found, thus ensuring the usability and reliability of the model on the target hardware device.

[0072] For example, integrating domain knowledge units based on a framework can perform operations such as operator integration and deployment.

[0073] For example, operator ensemble operations can represent registering the generated operator kernel code into the operator registry of a deep learning framework, establishing a mapping between model computation graph nodes and underlying operator implementations, and configuring operator scheduling strategies and dependency management. This enables the deep learning framework to correctly call the newly generated operators to participate in the model's inference or training process. As a bridge between software and hardware, the deep learning framework can drive the target hardware device to perform forward or backward propagation operations by accessing its computational resources.

[0074] For example, deployment operations can represent loading models and operators onto target hardware devices through a deep learning framework, configuring corresponding running strategies (such as memory management, parallel scheduling, data transfer, etc.) based on the resource characteristics of the target hardware device, and driving the target hardware device to perform forward inference or backward training tasks of the model through the runtime interface of the deep learning framework.

[0075] For example, distributed policy domain knowledge units can perform operations such as distributed policy selection, cluster performance simulation, and fault tolerance processing.

[0076] For example, distributed strategy selection operations may include determining the optimal parallel strategy based on the network architecture characteristics of the model to be adapted and the topology parameters of the target hardware cluster. For instance, one or more parallel strategies can be selected from data parallelism, tensor parallelism, pipelined parallelism, expert parallelism, and sequence parallelism.

[0077] For example, cluster performance simulation operations may include constructing a computation graph model based on the optimal parallel strategy, and performing simulations by combining the communication bandwidth and computing power of the target hardware cluster, in order to generate a performance evaluation report with estimated runtime, peak memory usage, and communication overhead percentage.

[0078] For example, fault tolerance can include real-time monitoring of node status and communication link status during model training or inference; when a node failure or communication anomaly is detected, a checkpoint rollback mechanism is triggered to restore task execution.

[0079] For example, operator generation and operator repair operations can be performed based on knowledge units in the operator routing domain.

[0080] For example, the operator generation operation can represent automatically generating corresponding operator kernel code based on operator attributes and target hardware instruction set for the unfit operators identified in the operator coverage check. This includes memory allocation logic, parallel computing strategies, and data transfer instructions, which are used to fill the operator gaps in the model adaptation process and make the model executable on the target hardware device.

[0081] For example, operator repair operations can represent targeted adjustments to the kernel code implementation, memory layout, parallel computing strategy, or hardware instruction configuration of an operator based on the operator error type determined by the operator detection operation, in order to resolve execution anomalies caused by the operator itself and enable the operator to run correctly on the target hardware device.

[0082] For example, after identifying an incompatible or erroneous operator, the existing library operator directory can be queried first. The incompatible or erroneous operator can be retrieved from the registry. If the operator library already has an implementation that covers it and meets performance requirements, it can be used directly as the operator generation or repair result without relying on an external skill package. If the operator is not covered or there is a phantom operator problem (static compilation succeeds, but actual runtime fails), a preset routing table needs to be queried. The routing table records the mapping relationship between operator gaps and external skill packages. By looking up the table, the corresponding external skill package can be determined and called to achieve operator generation or repair. Therefore, the operator routing domain knowledge unit itself does not contain any kernel development knowledge, and its skill description file size can be controlled to around 100 lines, so that the operator routing domain knowledge unit itself does not consume a large amount of context budget.

[0083] For example, based on domain knowledge units of communication libraries, it is possible to perform operations such as cascading of collection communication libraries, configuring dedicated communication libraries, managing environment variables, and debugging.

[0084] For example, cascading operations of the collection communication library can include detecting the heterogeneous network topology of the computing cluster and constructing hierarchical communication paths across nodes and within nodes; and integrating high-speed interconnect protocols within nodes with remote direct memory access protocols between nodes through cascading strategies to optimize the bandwidth utilization of all-reduce and all-to-all communication.

[0085] For example, dedicated communication library configuration operations may include loading the Expert Parallel Communication Kernel (DeepEP) for a hybrid expert model architecture.

[0086] For example, environment variable management operations may include parsing the transmission mode parameters and quantization precision identifiers required by the communication library; and injecting the corresponding environment variables into each node of the distributed process to activate asymmetric bandwidth forwarding optimization or low-precision data format scheduling functions.

[0087] For example, based on the domain knowledge units of the toolchain, operations such as environmental detection, target hardware device health diagnosis, and trajectory analysis processing (Trace Analytics Hub) can be performed.

[0088] For example, environment detection operations can represent a process of verifying the adaptability and compliance of the model's runtime environment. In some examples, target hardware device detection (e.g., target hardware device model, computing power, video memory capacity, etc.), compiler version verification, and deep learning framework availability verification can be performed, using a three-level check to determine whether the execution environment is ready. When an environment anomaly is detected, the anomaly information can be delegated to the graphics card driver diagnostic module for processing.

[0089] For example, target hardware device health diagnostic operations may include initial triage based on error identifiers and remote-gpu-diagnosis for multi-machine cluster environments.

[0090] In some examples, at least one of the aforementioned domain knowledge units may include business processing rules for the corresponding domain, a list of reference documents, and a list of external skill packages. This domain knowledge unit is configured to invoke reference documents from the list of reference documents and external skill packages from the list of external skill packages according to the business processing rules.

[0091] The aforementioned domain knowledge units include reference document paths and lists of external skill packages, but not the reference documents and external skill packages themselves. Only the reference documents and external skill packages that are invoked can be loaded into the agent's context, thereby effectively reducing context occupancy and avoiding responsibilities being mixed.

[0092] In some examples, business processing rules serve as a decision logic carrier, which can be used to implement one or more of the following routing and gating logics: indicating the task flow to be executed, indicating the reference documents to be invoked, indicating the external skill packages to be invoked, indicating the timing of invoking external skill packages, and indicating the interface contract for input / output data interaction specifications, etc. The size of the skill description file corresponding to the business processing rule can be controlled to around 100 lines, so that the domain knowledge unit itself does not consume a large amount of context budget.

[0093] In some examples, reference documents are used to provide agents with the basic judgment criteria for decision-making and reasoning (i.e., to determine the judgment basis in the field). By loading and parsing the reference documents, agents can obtain the evaluation criteria, constraints, or business logic in the current task scenario, thereby clarifying "how to judge" or "what criteria to use for decision-making".

[0094] In some examples, external skill packages are used to determine the specific executor of a task (i.e., who will execute the specific implementation). When an agent determines that a task needs to be delegated based on business processing rules or reference document criteria (e.g., a subtask exceeds the knowledge boundary of a knowledge unit in the domain), by invoking an external skill package, the agent can delegate the specific execution logic to the corresponding independent skill package, thus clarifying "who will execute" and "how to execute." For example, the list of external skill packages may include at least one external skill identifier (e.g., operator performance optimization skill identifier ai-op-master, kernel generation skill identifier kernel-gen, operator fusion skill identifier kernel-fuser, kernel migration and performance tuning skill identifier iteration-master, etc.). Each external skill identifier can serve as an addressing index or calling interface for the external skill package, and it is mapped and associated with an independent skill description file (e.g., SKILL.md) and a corresponding reference resource directory (e.g., references / directory) in the underlying data warehouse. Through the external skill identifiers in the list of external skill packages, the agent can locate and load the corresponding external skill package and its associated resources, thereby realizing the modular decomposition and collaborative execution of complex scheduling tasks.

[0095] Through the synergistic cooperation of the aforementioned reference documents and external skill packages, the intelligent agent can decouple decision-making logic from execution logic. That is, the reference documents provide domain knowledge and judgment benchmarks, while the external skill packages provide specific execution capabilities and implementation paths, thereby improving the scheduling efficiency and modularity of complex tasks.

[0096] It should be noted that some domains may not require reference documents or external skill sets. Therefore, depending on actual needs, a domain knowledge unit may only include business processing rules; or a domain knowledge unit may include either a list of reference documents or a list of external skill sets, along with business processing rules. This disclosure does not impose any limitations on this. In some examples, some of the aforementioned domain knowledge units include business processing rules, a list of reference documents, and a list of external skill sets for the corresponding domain; the remaining domain knowledge units may only include business processing rules and a list of reference documents for the corresponding domain.

[0097] In some examples, as shown in Table 1, a domain knowledge unit descriptor can also be set for each domain knowledge unit to describe the meta-information of each domain knowledge unit.

[0098] Table 1. Fields corresponding to the domain knowledge unit descriptor

[0099] In some examples, different domain knowledge units correspond to different lists of reference documents. Each domain knowledge unit is responsible for maintaining and managing its corresponding list of reference documents. If other domain knowledge units need to access the list of reference documents managed by the current domain knowledge unit, they can do so through the pipeline state log file (described later) instead of direct access. In some examples, each domain knowledge unit descriptor can record a unique list of reference documents owned by that domain knowledge unit, effectively avoiding unclear attribution of reference materials due to many-to-many coupling between reference documents and agents.

[0100] For example, for a knowledge unit in the operator routing domain, the skill description file path corresponding to its business processing rules is, for example, layers / operator / SKILL.md, and the list of reference document paths it possesses is, for example, [dispatch template document (dispatch-templates.md), unsupported protocol document (unsupported-protocol.md), experimental platform description document (gym-proving-ground.md), …], and the list of external skill package names it delegates is, for example, [operator performance optimization (ai-op-master), kernel generation (kernel-gen), operator fusion (kernel-fuser), pipeline operator subgraph fusion (pipeline-subgraph-fused), end-to-end mega-kernel (mega-kernel), kernel migration and performance tuning (iteration-master), …]. For example, when the operator gap type is "adjacent operators can be fused", the operator routing domain knowledge unit can find and call the kernel-fuser skill package by looking up the routing table, and load kernel-fuser's SKILL.md into the agent context so that the agent can perform the operator fusion operation. After the operator fusion operation is completed, kernel-fuser's SKILL.md can be unloaded from the agent context.

[0101] The knowledge scheduling method provided in at least one embodiment of this disclosure can be executed by an intelligent agent, which can be the same intelligent agent as the one described in step S102.

[0102] For example, scheduling configuration information can be loaded into the context of the agent during the initialization phase, and the scheduling configuration information can be made to reside in the context of the agent to instruct the agent to execute the knowledge scheduling method provided in the embodiments of this disclosure.

[0103] In some examples, scheduling configuration information can also be encapsulated as a structured skill description file, such as an instruction configuration file written in a markup language. The instruction information recorded in the skill description file can instruct the agent to execute the knowledge scheduling method provided in at least one embodiment of this disclosure.

[0104] In some examples, the agent executing the knowledge scheduling method described above and the agent described in step S102 can be different agents. In this example, although there are two agents, only one agent actually performs the task, and the other agent only implements the scheduling function. Therefore, it is still different from a multi-agent architecture in which multiple agents cooperate to perform tasks.

[0105] It's important to note that the scheduling configuration information does not include any specific domain knowledge; it is only responsible for scheduling and state management. In other words, the scheduling configuration information has no overlap with the multiple domain knowledge units mentioned above. For example, the scheduling configuration information will not include domain knowledge such as "the hybrid expert model needs to adopt an expert parallel strategy." Such judgments are performed by the corresponding domain knowledge units, and the scheduling configuration information is only responsible for routing requests to the correct domain knowledge unit (i.e., loading the correct domain knowledge unit into the agent's context). Because the scheduling configuration information only contains scheduling logic and not domain knowledge, its skill description file size can be controlled to around 250 lines, so that the scheduling configuration information itself does not consume a large amount of context budget.

[0106] The knowledge scheduling method provided in at least one embodiment of this disclosure may further include step S104, which may be executed before step S101.

[0107] Step S104: Determine the task sequence based on the forward propagation running status of the model to be adapted on the target hardware device.

[0108] For a description of step S104, please refer to the relevant descriptions of adaptation mode routing and task sequence selection below.

[0109] In some examples, scheduling configuration information can be used to instruct agents to perform one or more of the following tasks: user input collection, model prototype classification, adaptation pattern routing, task sequence selection, domain knowledge unit loading and unloading, pipeline state management, and timeout control.

[0110] For example, user input collection may include obtaining information such as the model identifier (ID), usage scenario, target hardware device information, and target accuracy of the user input; domain knowledge unit loading and unloading can refer to steps S101 to S103, which will not be elaborated here; pipeline status management may include managing the lifecycle of pipeline status record files; timeout control may include monitoring task execution timeouts and triggering exception handling.

[0111] For example, model prototype classification can include determining the prototype category of a model based on its configuration information. For instance, models can be classified into several standard types based on their architectural features, each type having similar adaptation critical paths and optimization strategies. Alternatively, the prototype category can be determined based on architectural signals (such as the number of model parameters, model architecture type, and use case type) in the model's configuration information. An example classification is as follows: Hybrid Expert Large Language Model (MoE LLM), Visual Language Multimodal Model (VL Multimodal Model), Dense Large Language Model (Dense LLM), Large Dense Large Language Model (Large Dense LLM), Convolutional Neural Network or Computer Vision (CNN / CV) Model, and Diffusion Model. Building upon these classification examples, models can be further classified into training models and inference models based on the use case field in their configuration information.

[0112] Table 2 shows an example of determining the prototype category of a model based on architectural signals.

[0113] Table 2 Correspondence between Architecture Signals and Prototype Categories

[0114] For example, as shown in Table 2, if the configuration file includes the num_experts field, the prototype category of the model can be determined to be MoE LLM (the default is the inference model); if the configuration file includes the num_experts field and the use case is training, the prototype category of the model can be determined to be MoE LLM+trained model.

[0115] For example, if the configuration file includes the vision_config or image_size field, the prototype category of the model can be determined to be a VL multimodal model (the default is an inference model); if the configuration file includes the vision_config or image_size field and the use case is training, the prototype category of the model can be determined to be a VL multimodal model + training model.

[0116] For example, if the architecture class in the configuration file includes the ForCausalLM field and the number of parameters is less than 70B, the prototype category of the model can be determined to be dense LLM (the default is inference model); if the architecture class in the configuration file includes the ForCausalLM field and the number of parameters is less than 70B and the use case is training, the prototype category of the model can be determined to be dense LLM + training model.

[0117] The correspondence between other architectural signals and prototype categories follows the same pattern, as detailed in Table 2, and will not be elaborated upon here. It should be noted that the above classification method is merely an example; different classification methods and criteria can be adopted according to actual needs, and this disclosure does not impose any limitations on this.

[0118] For example, adaptation mode routing may include determining the target adaptation mode from multiple adaptation modes based on the forward propagation runtime state of the model to be adapted on the target hardware device, where the operation link lengths differ among the multiple adaptation modes. In some examples, the forward propagation runtime state of the model on the target hardware device can be obtained based on the results of a Quick Smoke Test. A Quick Smoke Test, for example, involves loading the model on the target hardware device and performing a minimum forward inference operation to quickly verify the basic usability of the model. In some examples, multiple adaptation modes may include a direct deployment mode, a targeted repair mode, and a full adaptation mode. The direct deployment mode includes deployment operations; the targeted repair mode includes operator probing operations, operator repair operations, and deployment operations; and the full adaptation mode includes operator analysis operations, operator coverage checking operations, operator generation operations, operator integration operations, and deployment operations.

[0119] In some examples, the target adaptation mode can be determined to be direct deployment mode in response to the model correctly completing forward propagation on the target hardware device; the target adaptation mode can be determined to be fixed-point repair mode in response to operator errors during the forward propagation of the model on the target hardware device; and the target adaptation mode can be determined to be full adaptation mode in response to an abnormal loading of the model on the target hardware device. For example, correctly completing forward propagation means that the forward propagation runs normally and the output result is correct. For example, operator errors can include dimension mismatch, data type incompatibility, index out of bounds, etc., that is, various errors caused by abnormal execution of the operator itself, which are not limited in this disclosure embodiment. For example, if the forward propagation of the model is interrupted due to an operator error, or the forward propagation output result does not meet expectations (e.g., is incorrect), it can be determined that an operator error exists. For example, loading anomalies can include loading failure (LOAD_FAIL) or memory overflow (OOM), etc.

[0120] For example, task sequence selection can include determining the task sequence based on the target adaptation mode. In some examples, different task sequences can be predefined for different adaptation modes. For example, as shown in Table 3, different task sequences can be defined for the direct deployment mode, the targeted repair mode, and the full adaptation mode, respectively. Each row in Table 3 represents the target domain knowledge unit corresponding to each task stage in the task sequence for different adaptation modes.

[0121] Table 3 Domain Knowledge Unit Scheduling Table

[0122] Based on the knowledge scheduling method provided in at least one embodiment of this disclosure, approximately 91% of the context budget can be saved in the direct deployment mode, approximately 70% of the context budget can be saved in the fixed-point repair mode, and approximately 40% of the context budget can be saved in the direct deployment mode (due to lazy loading + unloading, not occupying all domain knowledge units at the same time).

[0123] In some examples, a single task phase can correspond to multiple target domain knowledge units. For instance, in Table 3, task phase 1 of the full adaptation pattern corresponds to two target domain knowledge units.

[0124] For example, if the current traversed task stage corresponds to multiple target domain knowledge units, one example of step S102 may include: loading multiple target domain knowledge units into the agent's context so that the agent can execute the tasks corresponding to the multiple target domain knowledge units in parallel based on the context.

[0125] In this way, the agent can execute multiple tasks in parallel without data dependencies, eliminating serial blocking and idle waiting states between tasks, thus significantly improving the processing efficiency of model adaptation. For example, the above method achieves parallelism of operators and communication, as well as full parallelism of the toolchain, reducing the total adaptation time by approximately 30%.

[0126] It should be noted that, since the model to be adapted is generally loadable in the fixed-point repair mode, task phase 1 can focus on model evaluation operations first, and then perform environment detection in parallel during the distributed policy selection in task phase 2. However, in the full-scale adaptation mode, the model to be adapted is unknown, and environment detection needs to be performed in the initial stage (task phase 1). Therefore, as shown in Table 3, in the fixed-point repair mode, for task phase 2, the agent executes the tasks corresponding to the distributed policy domain knowledge units and toolchain domain knowledge units in parallel; while in the full-scale adaptation mode, for task phase 1, the agent executes the tasks corresponding to the model evaluation domain knowledge units and toolchain domain knowledge units in parallel.

[0127] The knowledge scheduling method provided in at least one embodiment of this disclosure may further include step S105.

[0128] Step S105: In response to the completion of task execution in the task phase, write the task execution result to the status log file for later reading in subsequent task phases.

[0129] Data flow between all domain knowledge units is transmitted through a structured pipeline state log file (e.g., a JSON object). For example, the state log file can serve as the sole communication medium between domain knowledge units throughout the entire pipeline lifecycle. No domain knowledge unit depends on the natural language output of other domain knowledge units, eliminating information loss and ambiguity caused by natural language transmission.

[0130] Table 4 shows an example of a data structure for a status log file.

[0131] Table 4 Data Structure of Status Log File

[0132] It should be noted that Table 4 is only an example, and more or fewer fields may be included depending on actual needs. This disclosure does not limit this.

[0133] The knowledge scheduling method provided in at least one embodiment of this disclosure may further include the following step S106.

[0134] Step S106: In response to the existence of an operation interruption, determine the next operation to be executed based on the operation corresponding to the last execution result written in the status record file.

[0135] In the knowledge scheduling method provided in at least one embodiment of this disclosure, a pipeline state persistence mechanism can be employed to ensure the continuity and reliability of tasks. For example, after each atomic step in the pipeline (each step executed by the agent based on the target domain knowledge unit) is completed, its execution result is synchronously written to a predefined structured pipeline state record file. When the pipeline operation is interrupted due to an anomaly or external intervention, the structured state can be read, the breakpoint of any step can be accurately located, and execution can be resumed from the point of interruption. Since the execution results of historical steps have been persistently recorded, the resumed pipeline will directly load the existing results, thereby avoiding redundant repetitive calculations and significantly enhancing the robustness of the system in complex operating environments.

[0136] Figure 2 A flowchart of another knowledge scheduling method for an intelligent agent provided in at least one embodiment of this disclosure.

[0137] For example, such as Figure 2 As shown, the knowledge scheduling method for an intelligent agent provided in at least one embodiment of this disclosure may include the following steps S201 to S212.

[0138] Step S201: Obtain the configuration information of the model to be adapted.

[0139] For example, in step S201, the model's configuration information can be obtained by parsing the model's configuration file.

[0140] Step S202: Determine the prototype category of the model to be adapted based on the configuration information of the model to be adapted.

[0141] Step S203: Based on the forward propagation running state of the model to be adapted on the target hardware device, determine the target adaptation mode from multiple adaptation modes.

[0142] Step S204: Determine the task sequence based on the target adaptation mode.

[0143] Step S205: Traverse multiple task stages in the task sequence.

[0144] Step S206: Determine the target domain knowledge unit corresponding to the current task stage from multiple domain knowledge units.

[0145] Step S207: Determine how many target domain knowledge units correspond to the current task stage. If there are multiple units, proceed to step S208; if there is only one unit, proceed to step S209.

[0146] Step S208: Load multiple target domain knowledge units into the context of the agent, so that the agent can execute the tasks corresponding to the multiple target domain knowledge units in parallel based on the context.

[0147] Step S209: Load the target domain knowledge unit into the agent's context so that the agent can execute the task in the current task phase based on the context.

[0148] Step S210: In response to the completion of the task in the current task phase, write the task execution result to the status log file.

[0149] Step S211: Unload the target domain knowledge unit from the agent's context.

[0150] Step S212: Determine if the traversal is complete. If yes, end the process; otherwise, return to step S205 and continue processing the next task stage.

[0151] For a description of steps S201 to S212, please refer to the above embodiment; they will not be repeated here.

[0152] It should also be noted that the execution order of the steps in the knowledge scheduling method is not limited in the various embodiments of this disclosure. Although the execution process of each step has been described in a specific order above, this does not constitute a limitation on the embodiments of this disclosure. The steps in the knowledge scheduling method can be executed serially or in parallel, depending on actual needs.

[0153] For example, compared to the above description, the knowledge scheduling method provided in at least one embodiment of this disclosure may include more or fewer steps, and the embodiments of this disclosure do not limit this.

[0154] Figure 3 This is a schematic block diagram of a model adaptation system provided for at least one embodiment of the present disclosure.

[0155] For example, such as Figure 3As shown, the model adaptation system provided in at least one embodiment of this disclosure includes a user interface layer, a scheduler layer, and a set of domain knowledge units.

[0156] For example, the user interface layer is used to receive model adaptation requests submitted by users (including model identifiers, usage scenarios, target hardware device information) and pass them to the scheduler layer.

[0157] For example, scheduling configuration information can be loaded into the agent's context, and this scheduling configuration information can be made persistent in the agent's context, serving as... Figure 3 The scheduler layer is shown. The scheduler layer may include a prototype classification module, an adaptation pattern routing module, a domain scheduling module, and a pipeline state management module. The scheduler layer may also include an input collection module, configured to receive model adaptation requests submitted by users through the user interface layer, and to receive confirmation information from users.

[0158] The domain knowledge unit set comprises six distinct domain knowledge units, each capable of accessing specific reference documents and can be lazily loaded into the agent's context as needed. For example... Figure 3 As shown, the model evaluation domain knowledge unit can call reference documents such as cross-model adaptation experience documents (model-lessons.md) and precision grading standard documents (precision-standards.md); the framework integration domain knowledge unit can call reference documents such as inference deployment experience documents (inference-deployment.md) and tensor computation framework internal mechanism documents (pytorch-internals.md); the distributed policy domain knowledge unit can call reference documents such as training deployment experience documents (training-deployment.md) and hardware optimization rule documents (hardware-opt-rules.md); the operator routing domain knowledge unit can call reference documents such as operator knowledge base documents (gym_knowledge.md) and operator optimization documents (perf-optimization.md); the communication library domain knowledge unit can call reference documents such as collection communication algorithm documents (communication.md); and the toolchain domain knowledge unit can call reference documents such as environment detection documents (troubleshooting.md) and software stack knowledge documents (software-stack.md). Communication between all domain knowledge units is conducted through state log files maintained by the pipeline state management module. No domain knowledge unit depends on the natural language output of other domain knowledge units, thus eliminating information loss and ambiguity caused by natural language transmission.

[0159] Figure 4An interaction sequence diagram of a model adaptation system provided in at least one embodiment of this disclosure.

[0160] During the initialization phase, scheduling configuration information can be loaded into the agent's context, and this configuration information can be made persistent in the agent's context, serving as... Figure 4 The scheduler layer is shown.

[0161] Figure 4 In For model evaluation of domain knowledge units, To integrate domain knowledge units into the framework. As a knowledge unit in the distributed strategy domain, As a knowledge unit in the operator routing domain, As a knowledge unit in the communication library domain, This is a knowledge unit in the toolchain domain.

[0162] like Figure 4 As shown, the user submits a model adaptation request to the scheduler layer through the user interface layer. The scheduler layer performs prototype classification and adaptation mode selection operations, and returns the determined prototype category and target adaptation mode (full adaptation mode in this example) as a summary to the user for confirmation. After receiving the confirmation information returned by the user, the scheduler layer can determine the task sequence according to the target adaptation mode. Referring to the example in Table 3, the task sequence includes task phases 1 to 5. Task phase 1 corresponds to the model evaluation domain knowledge unit and the toolchain domain knowledge unit; task phase 2 corresponds to the distributed policy domain knowledge unit; task phase 3 corresponds to the operator routing domain knowledge unit and the communication library domain knowledge unit; task phase 4 corresponds to the framework integration domain knowledge unit; and task phase 5 corresponds to the dataset verification part of the model evaluation domain knowledge unit.

[0163] For task phase 1, model evaluation domain knowledge units and toolchain domain knowledge units can be loaded into the agent's context. The agent then executes model evaluation and environment detection operations in parallel based on this context. After the model evaluation and environment detection operations are completed, the model evaluation and toolchain domain knowledge units are unloaded from the agent's context. For example, model evaluation operations may include performing architecture analysis (involving module structure, weight list, parallel structure, operator extraction strategy, etc.), full operator analysis, and operator coverage checks based on the model to be adapted, model configuration file, and target hardware device information. The execution results of model evaluation operations may include architecture analysis results (arch_memo) and a list of missing operators (gap_list). In some examples, architecture analysis can be performed based on prototype classification. That is, after prototype classification is completed at the scheduler layer, architecture analysis can be performed for that specific prototype category, thereby significantly improving analysis efficiency and targeting. For example, environment detection operations may include performing target hardware device detection, compiler version verification, and deep learning framework availability verification based on target hardware device information to determine whether the execution environment is ready. The execution results of environment detection operations may include the environment status (env_status). The execution results of the above operations can be written to the status log file in the pipeline status management module for reading in subsequent task stages.

[0164] For task phase 2, distributed policy domain knowledge units can be loaded into the agent's context, allowing the agent to execute distributed policy selection and cluster simulation operations based on this context. After these operations are completed, the distributed policy domain knowledge units are unloaded from the agent's context. For example, after loading the distributed policy domain knowledge units, the architecture analysis results (arch_memo) can be read from the state log file. The distributed policy selection operation may include determining the distributed policy (distributed_strategy) based on the architecture analysis results. The distributed policy can be written to the state log file in the pipeline state management module for later retrieval in subsequent task phases.

[0165] For task phase 3, operator routing domain knowledge units and communication library domain knowledge units can be loaded into the agent's context. The agent then executes operator generation and communication library configuration operations in parallel based on this context. After the operator generation and communication library configuration operations are completed, the operator routing domain knowledge units and communication library domain knowledge units are unloaded from the agent's context. For example, after loading the operator routing domain knowledge units and communication library domain knowledge units, the missing operator list (gap_list) and distributed strategy (distributed_strategy) can be read from the state log file. Operator generation operations can be performed based on the missing operator list to obtain the generated operator list (ops_fixed); communication library configuration operations can be performed based on the distributed strategy to generate communication library configuration information (comm_config). The execution results of the above operations can be written to the state log file in the pipeline state management module for later reading in subsequent task phases.

[0166] For task phase 4, the framework integration domain knowledge unit can be loaded into the agent's context, allowing the agent to execute operator integration and deployment operations based on the context. After the operator integration and deployment operations are completed, the framework integration domain knowledge unit is unloaded from the agent's context. For example, after loading the framework integration domain knowledge unit, the generated operator list (ops_fixed), communication library configuration information (comm_config), and distributed strategy (distributed_strategy) can be read from the status log file, and operator integration and deployment operations can be executed based on this information. The execution results of the operator integration and deployment operations can include the deployment status (deploy_status). The deployment status can be written to the status log file in the pipeline state management module for later reading in subsequent task phases.

[0167] For task phase 5, the dataset verification portion of the model evaluation domain knowledge unit can be loaded into the agent's context, allowing the agent to perform dataset verification operations based on the context. After the dataset verification operation is completed, the model evaluation domain knowledge unit is unloaded from the agent's context. For example, after loading the dataset verification portion of the model evaluation domain knowledge unit, the deployment status (deploy_status) can be read, and dataset verification and acceptance gating operations can be performed based on the deployment status to obtain accuracy results (accuracy_results) and acceptance. The execution results of the above operations can be written to the status log file in the pipeline state management module for generating a model adaptation report for the user.

[0168] Figure 5This is a schematic block diagram of a knowledge scheduling device for an intelligent agent, provided for at least one embodiment of the present disclosure.

[0169] For example, the knowledge scheduling device is applied to a single intelligent agent and can be implemented as a processor or set in a processor. The processor may include a central processing unit, a graphics processing unit, a general-purpose graphics processing unit, a tensor processor, a deep learning processor, an accelerator processor, a neural network processor, an application-specific integrated circuit, or a field-programmable gate array, etc. Of course, the embodiments of this disclosure are not limited to this, and the processor may also be any other type of processor.

[0170] For example, such as Figure 5 As shown, the knowledge scheduling device 500 provided in at least one embodiment of this disclosure may include a determining module 501, a loading module 502, and an unloading module 503.

[0171] For example, the determination module 501 is configured to determine the target domain knowledge unit corresponding to the task stage (i.e. the currently traversed task stage) from multiple domain knowledge units for each task stage in a task sequence that includes multiple task stages.

[0172] For example, loading module 502 is configured to load target domain knowledge units into the context of an agent so that the agent can perform tasks in the task phase based on the context, wherein the context does not include other domain knowledge units besides the target domain knowledge unit among multiple domain knowledge units.

[0173] For example, the unloading module 503 is configured to unload the target domain knowledge unit from the agent's context in response to the completion of task execution in the task phase.

[0174] The execution environment of the agent remains operational throughout the execution of all task stages in the task sequence.

[0175] In some examples, at least one of the multiple domain knowledge units includes business processing rules for the corresponding domain, a list of reference documents, and a list of external skill packs.

[0176] In some examples, the domain knowledge unit is configured to invoke reference documents from the reference document list and external skill packages from the external skill package list based on business processing rules.

[0177] In some examples, different domain knowledge units correspond to different lists of reference documents.

[0178] In some examples, the determination module is further configured to determine the task sequence based on the forward propagation running state of the model to be adapted on the target hardware device.

[0179] In some examples, where multiple target domain knowledge units correspond to a task phase, the loading module is further configured to load multiple target domain knowledge units into the agent's context, so that the agent can execute the tasks corresponding to the multiple target domain knowledge units in parallel based on the context.

[0180] In some examples, multiple domain knowledge units correspond one-to-one with multiple domains, which are divided according to the degree of correlation between multiple stages in the model adaptation process.

[0181] In some examples, multiple domains include: model evaluation, framework integration, distributed strategy, operator routing, communication library, and toolchain.

[0182] In some examples, the knowledge dispatching device is an agent or a device that carries an agent.

[0183] In some examples, the knowledge scheduling apparatus may also include a pipeline state management module. The pipeline state management module is configured to write the task execution result to a state log file in response to the completion of a task in a task phase, for retrieval in subsequent task phases.

[0184] It should be noted that the above-mentioned modules can be implemented by software, hardware, firmware or any combination thereof. For example, the determining module can be implemented as a determining circuit, the loading module can be implemented as a loading circuit, and the unloading module can be implemented as an unloading circuit. The embodiments of this disclosure do not limit their specific implementation.

[0185] It should be understood that the knowledge scheduling apparatus provided in at least one embodiment of this disclosure can be used to implement the aforementioned knowledge scheduling method, and can also achieve similar technical effects as the aforementioned knowledge scheduling method, which will not be elaborated here.

[0186] It should be noted that, in the embodiments of this disclosure, the knowledge scheduling device may include more or fewer modules or units, and the connection relationship between the various modules or units is not limited and can be determined according to actual needs. The specific configuration of each module or unit is not limited; it can be constructed from analog devices according to circuit principles, or from digital chips, or in other applicable ways.

[0187] Figure 6 This is a schematic block diagram of an electronic device provided for at least one embodiment of the present disclosure.

[0188] For example, such as Figure 6As shown, the electronic device 600 includes at least one processor 601 and at least one memory 602. The at least one memory 602 includes one or more computer program modules. These computer program modules are stored in the memory 602 and configured to be executed by the at least one processor 601. The one or more computer program modules include instructions for performing the knowledge scheduling method described above. When executed by the at least one processor 601, they can perform one or more steps of the knowledge scheduling method provided in at least one embodiment of this disclosure. The memory 602 and the processor 601 can be interconnected via a bus system and / or other forms of connection mechanisms (not shown).

[0189] For example, processor 601 can be a central processing unit (CPU), digital signal processor (DSP), graphics processing unit (GPU), general-purpose graphics processing unit (GPGPU), artificial intelligence (AI) accelerator, or other form of processing unit with data processing and / or program execution capabilities, such as a field-programmable gate array (FPGA); for example, the central processing unit (CPU) can be an x86, ARM, or RISC-V architecture. Processor 601 can be a general-purpose processor or a special-purpose processor, capable of controlling other components in electronic device 600 to perform desired functions.

[0190] For example, memory 602 may include any combination of one or more computer program products, which may include various forms of computer-readable storage media, such as volatile memory and / or non-volatile memory. Volatile memory may include, for example, random access memory (RAM) and / or cache memory. Non-volatile memory may include, for example, read-only memory (ROM), hard disk, erasable programmable read-only memory (EPROM), portable compact disc read-only memory (CD-ROM), USB memory, flash memory, etc.

[0191] Figure 7 This is a schematic block diagram of another electronic device provided for at least one embodiment of the present disclosure.

[0192] The electronic devices in at least one embodiment of this disclosure may include, but are not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, personal digital assistants (PDAs), tablet computers (PADs), portable multimedia players (PMPs), in-vehicle terminals (e.g., in-vehicle navigation terminals), wearable electronic devices, and fixed terminals such as digital TVs and desktop computers. Figure 7 The electronic device shown is merely an example and should not be construed as limiting the functionality and scope of the embodiments disclosed herein.

[0193] The electronic device includes at least one processor and a memory. The processor may be referred to as processing device 701 as described below, and the memory may include at least one of ROM 702, RAM 703, and storage device 708 as described below. The memory is used to store programs for performing the methods described in the various method embodiments above; the processor is configured to execute the programs stored in the memory. The processor may include a central processing unit (CPU) or other forms of processing unit having data processing capabilities and / or instruction execution capabilities, and may control other components in the electronic device to perform desired functions.

[0194] like Figure 7 As shown, the electronic device 700 may include a processing unit 701 (e.g., a central processing unit, a graphics processor, etc.), which can perform various appropriate actions and processes according to a program stored in ROM 702 or a program loaded from storage device 708 into RAM 703. RAM 703 also stores various programs and data required for the operation of the electronic device 700. The processing unit 701, ROM 702, and RAM 703 are interconnected via bus 704. Input / output (I / O) interfaces are also connected to bus 704.

[0195] Typically, the following devices can be connected to I / O interface 705: input devices 706 including, for example, touchscreens, touchpads, keyboards, mice, cameras, microphones, accelerometers, gyroscopes, etc.; output devices 707 including, for example, displays, speakers, vibrators, etc.; storage devices 708 including, for example, magnetic tapes, hard disks, etc.; and communication devices 709. Communication device 709 allows electronic device 700 to communicate wirelessly or wiredly with other devices to exchange data. Although Figure 7 An electronic device 700 with various devices is shown; however, it should be understood that it is not required to implement or possess all of the devices shown. More or fewer devices may be implemented or possessed alternatively.

[0196] In particular, according to at least one embodiment of this disclosure, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, at least one embodiment of this disclosure includes a computer program product comprising a computer program carried on a non-transitory computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such an embodiment, the computer program can be downloaded and installed from a network via a communication device 709, or installed from a storage device 708, or installed from a ROM 702. When the computer program is executed by a processing device 701, it performs the functions defined in the methods of at least one embodiment of this disclosure.

[0197] It should be noted that the computer-readable medium described above in this disclosure can be a computer-readable signal medium or a computer-readable storage medium, or any combination thereof. A computer-readable storage medium can be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In at least one embodiment of this disclosure, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. In at least one embodiment of this disclosure, a computer-readable signal medium can include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A computer-readable signal medium may be any computer-readable medium other than a computer-readable storage medium, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to: wires, optical fibers, radio frequency (RF), etc., or any suitable combination thereof.

[0198] The aforementioned computer-readable medium may be included in the aforementioned electronic device 700; or it may exist independently and not assembled into the electronic device 700.

[0199] Figure 8 This is a schematic block diagram of a non-transitory computer-readable storage medium provided for at least one embodiment of the present disclosure.

[0200] For example, such as Figure 8 As shown, a non-transitory computer-readable storage medium 800 stores computer-readable instructions 801, which, when executed by at least one processor, perform one or more steps of the knowledge scheduling method described above.

[0201] For example, the storage medium may include a memory card for a smartphone, a storage component for a tablet computer, a hard drive for a personal computer, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), portable compact disc read-only memory (CD-ROM), flash memory, or any combination of the above storage media, or other suitable storage media. For example, the readable storage medium may also be... Figure 6 The memory 602 in the memory is described in the foregoing content and will not be repeated here.

[0202] Although the present disclosure has been described in detail above with general descriptions and specific embodiments, modifications or improvements can be made to the embodiments of the present disclosure, which will be obvious to those skilled in the art. Therefore, all such modifications or improvements made without departing from the spirit of the present disclosure are within the scope of protection claimed by the present disclosure.

[0203] The following points should be noted regarding this disclosure: (1) The accompanying drawings of the embodiments of this disclosure only involve the structures involved in the embodiments of this disclosure. Other structures can be referred to the general design.

[0204] (2) For clarity, the thickness of layers or regions in the drawings used to describe embodiments of the present disclosure is enlarged or reduced, i.e., these drawings are not drawn to actual scale.

[0205] (3) Where there is no conflict, the embodiments of this disclosure and the features in the embodiments can be combined with each other to obtain new embodiments.

[0206] The above description is merely a specific embodiment of this disclosure, but the scope of protection of this disclosure is not limited thereto. The scope of protection of this disclosure should be determined by the scope of protection of the claims.

Claims

1. A knowledge scheduling method for an intelligent agent, characterized in that, The method is applied to a single intelligent agent, and the method includes: For each task stage in a task sequence that includes multiple task stages: Determine the target domain knowledge unit corresponding to the task stage from multiple domain knowledge units; The target domain knowledge unit is loaded into the context of the agent so that the agent can perform the task in the task phase based on the context, wherein the context does not include other domain knowledge units besides the target domain knowledge unit among the plurality of domain knowledge units; In response to the completion of the task execution in the task phase, the target domain knowledge unit is unloaded from the context of the agent. The execution environment of the intelligent agent remains operational throughout the execution of all task stages in the task sequence.

2. The method according to claim 1, characterized in that, At least one of the multiple domain knowledge units includes business processing rules, a list of reference documents, and a list of external skill packs for the corresponding domain.

3. The method according to claim 2, characterized in that, The domain knowledge unit is configured to invoke reference documents from the reference document list and external skill packages from the external skill package list according to the business processing rules.

4. The method according to claim 2, characterized in that, Different domain knowledge units correspond to different lists of reference documents.

5. The method according to claim 1, characterized in that, The method further includes: The task sequence is determined based on the forward propagation running state of the model to be adapted on the target hardware device.

6. The method according to claim 1, characterized in that, When a task phase corresponds to multiple target domain knowledge units, loading the target domain knowledge units into the agent's context so that the agent executes the task in the task phase based on the context includes: The multiple target domain knowledge units are loaded into the context of the agent, so that the agent can execute the tasks corresponding to the multiple target domain knowledge units in parallel based on the context.

7. The method according to claim 1, characterized in that, The multiple domain knowledge units correspond one-to-one with multiple domains, which are divided according to the degree of correlation between multiple stages in the model adaptation process.

8. The method according to claim 7, characterized in that, The aforementioned areas include: model evaluation, framework integration, distributed strategy, operator routing, communication library, and toolchain.

9. The method according to claim 1, characterized in that, The method is executed by the intelligent agent.

10. The method according to claim 1, characterized in that, The method further includes: In response to the completion of the task in the task phase, the execution result of the task is written to a status log file for later reading in subsequent task phases.

11. A knowledge scheduling device for an intelligent agent, characterized in that, The device is applied to a single intelligent agent, and the device includes: The determination module is configured to determine, for each task stage in a task sequence comprising multiple task stages, the target domain knowledge unit corresponding to the task stage from multiple domain knowledge units; A loading module is configured to load the target domain knowledge unit into the context of the agent, so that the agent can execute the task in the task phase based on the context, wherein the context does not include other domain knowledge units among the plurality of domain knowledge units besides the target domain knowledge unit; An unloading module is configured to unload the target domain knowledge unit from the context of the agent in response to the completion of task execution in the task phase. The execution environment of the intelligent agent remains operational throughout the execution of all task stages in the task sequence.

12. An electronic device, characterized in that, The electronic device includes: At least one processor; At least one memory, including one or more computer program modules; The one or more computer program modules are stored in the at least one memory and configured to be executed by the at least one processor, and the one or more computer program modules are used to implement the method according to any one of claims 1-10.

13. A non-transitory computer-readable storage medium, characterized in that, The non-transitory computer-readable storage medium stores computer-readable instructions, wherein the computer-readable instructions, when executed by at least one processor, perform the method according to any one of claims 1-10.

Images