A heterogeneous AI algorithm module standardization information intercommunication adaptation method

Abstract

The application discloses a heterogeneous AI algorithm module standardized information intercommunication adaptation method, which comprises the following steps: step one, module registration and meta information extraction, step two, standardized interface generation, step three, data format standardized conversion, step four, protocol adaptation and communication conversion, step five, intelligent routing and load distribution, step six, execution result feedback and format reverse conversion, and step seven, adaptive strategy dynamic updating. The method provided by the application realizes plug and play of AI algorithm modules under different technical frameworks by uniformly registering and extracting meta information of the heterogeneous AI algorithm modules, and automatically generating a standardized interface packaging layer for each module, thereby greatly reducing system integration difficulty and development cost. By establishing a standard intermediate data format and performing standardized conversion on numerical data based on a normalization formula, the accuracy and integrity of information transmission between modules are ensured.

Description

Technical Field

[0001] This invention relates to the field of artificial intelligence algorithm integration and heterogeneous system interoperability technology, specifically to a standardized information exchange and adaptation method for heterogeneous AI algorithm modules. Background Technology

[0002] With the rapid development of artificial intelligence technology, various AI algorithm modules have emerged, including deep learning inference modules, traditional machine learning classification modules, natural language processing modules, and computer vision modules. These algorithm modules are often implemented by different development teams based on different technical frameworks (such as TensorFlow, PyTorch, PaddlePaddle, ONNXRuntime, etc.), and their input and output data formats, interface calling methods, parameter passing specifications, and communication protocols all have significant differences.

[0003] In scenarios where multiple heterogeneous AI algorithm modules need to be integrated into the same business system to work collaboratively, developers typically need to write dedicated adaptation code for each algorithm module, performing point-to-point interface connections and data format conversions. This traditional integration method has significant limitations:

[0004] On the one hand, when the system needs to add or replace algorithm modules, the adaptation logic must be redeveloped, resulting in poor system scalability and high maintenance costs;

[0005] On the other hand, the lack of a unified semantic standard for data exchange between different algorithm modules makes it easy for information to become ambiguous or lost when it is transmitted between modules, making it difficult to guarantee the consistency and integrity of the data.

[0006] Furthermore, when heterogeneous AI algorithm modules undergo version iterations, their interface parameter structures, input and output field definitions, and even communication protocol versions may change accordingly. Traditional point-to-point adaptation code needs to be modified one by one, resulting in high maintenance costs and a high risk of system downtime or runtime anomalies, posing a significant risk to the continuous and stable operation of the production environment.

[0007] While there are some unified computing methods or interface adaptation solutions for heterogeneous computing devices in the existing technology, such as ONNX (Open Neural Network Exchange) which provides the ability to convert model file formats between different deep learning frameworks, NVIDIA Triton inference server which provides a unified HTTP / gRPC service interface for a variety of deep learning backends, and CUDA (Compute Unified Device Architecture) which provides a unified abstraction of parallel computing instruction sets at the hardware layer.

[0008] However, these solutions each focus on cross-framework conversion at the model file level, unified interface encapsulation for inference servers, or hardware-level computation instruction scheduling. When facing business integration scenarios of heterogeneous AI algorithm modules, they still lack a standardized information exchange mechanism covering the entire chain, from data format semantic alignment and automatic conversion of heterogeneous communication protocols to dynamic adaptation of interface versions. This makes it difficult to fundamentally solve the aforementioned scalability, consistency, and maintainability issues faced when integrating heterogeneous modules. Summary of the Invention

[0009] To address this, the present invention provides a standardized information interoperability and adaptation method for heterogeneous AI algorithm modules, in order to solve the problem that the existing technology lacks a standardized information interoperability mechanism covering the entire chain from data format semantic alignment and automatic conversion of heterogeneous communication protocols to dynamic adaptation of interface versions, making it difficult to fundamentally solve the aforementioned problems of scalability, consistency and maintainability faced when integrating heterogeneous modules.

[0010] To achieve the above objectives, the present invention provides the following technical solution:

[0011] A method for standardized information exchange and adaptation of heterogeneous AI algorithm modules includes the following steps:

[0012] Step 1: Module Registration and Meta-information Extraction: Receive registration requests from at least one AI algorithm module, which originates from different technical frameworks or development environments; parse the module description file of each AI algorithm module, extracting its meta-information, including module name, input parameter structure, output parameter structure, dependent computing resource type, and communication protocol type; assign a globally unique module identifier to each AI algorithm module and store the meta-information in the registration information database.

[0013] Step 2: Standardized Interface Generation: Based on the metadata of each AI algorithm module extracted in Step 1, the standardized interface template library is called to generate a standardized interface encapsulation layer for each AI algorithm module. The standardized interface encapsulation layer includes an input parameter conversion sublayer, an output parameter conversion sublayer, and a calling protocol adaptation sublayer. The input parameter conversion sublayer converts standard format input parameters passed from external callers into the native format input parameters of each AI algorithm module. The output parameter conversion sublayer converts the native format output parameters of each AI algorithm module into standard format output parameters. The calling protocol adaptation sublayer converts standard protocol calls from external callers into native protocol calls of each AI algorithm module.

[0014] Step 3: Data Format Standardization and Conversion: Obtain the first data output from the source AI algorithm module. The first data has the native data format of the source module. According to the format mapping relationship recorded by the standardization interface encapsulation layer in Step 2, convert the first data into a standard intermediate data format to obtain the standardized second data. The standard intermediate data format uses a key-value pair structure to describe the data content. The key in the key-value pair is used to identify the data field name, and the value in the key-value pair is used to carry the specific numerical value of the data field. For numerical data fields, normalization is performed according to the formula V_std=(V_raw-V_min) / (V_max-V_min), where V_std is the standardized value, V_raw is the original value, V_min is the theoretical minimum value of the data field in the source AI algorithm module, and V_max is the theoretical maximum value of the data field in the source AI algorithm module. For non-numerical data fields, convert the non-numerical data into standardized coded values ​​according to a preset encoding mapping table.

[0015] Step 4, Protocol Adaptation and Communication Conversion: Obtain the target communication protocol type used by the target AI algorithm module. The target communication protocol type includes at least one of Hypertext Transfer Protocol, Message Queuing Telemetry Transfer Protocol, and Remote Procedure Call Protocol. Based on the communication protocol type information stored in the registration information database in Step 1, determine whether the source communication protocol and the target communication protocol are consistent. If they are inconsistent, call the protocol conversion engine to convert the data packet format of the source communication protocol to the data packet format of the target communication protocol according to the preset protocol conversion rules. The protocol conversion rules include the mapping relationship of data packet header fields and the mapping relationship of data payload fields. Send the converted data packet to the target AI algorithm module according to the transmission specifications of the target communication protocol.

[0016] Step 5, Intelligent Routing and Load Distribution: Based on the computing resource types relied upon by each AI algorithm module stored in Step 1, obtain the real-time load status information of each computing resource node in the current system. The real-time load status information includes at least one of the following: CPU utilization, memory utilization, and GPU utilization of each computing resource node. Calculate the matching degree between each AI algorithm module and each computing resource node based on the computing resource type requirements of each AI algorithm module and the real-time load status information of each computing resource node. Schedule the AI ​​algorithm modules to be executed to the computing resource node with the highest matching degree in descending order of matching degree.

[0017] Step Six: Execution Result Feedback and Format Reverse Conversion: Obtain the third data returned after the target AI algorithm module completes execution. This third data has the output data structure of the target module's native format. Based on the reverse format mapping relationship recorded in the standardized interface encapsulation layer in Step Two, convert the third data from the target module's native format to a standard intermediate data format to obtain the standardized fourth data. Perform reverse conversion on the fourth data according to the caller's data format requirements to obtain the fifth data for the caller to use directly. Return the fifth data to the caller.

[0018] Step 7: Dynamic Update of Adaptation Strategy: Monitor version change information of each AI algorithm module. When a version update of any AI algorithm module is detected, re-extract the updated metadata of that AI algorithm module; regenerate the standardized interface encapsulation layer of that AI algorithm module based on the updated metadata, and update the corresponding metadata record in the registration information database; publish the updated standardized interface encapsulation layer to the system configuration center in the form of an interface mapping rule set. Each relevant calling node subscribes to the change event of the configuration center, asynchronously pulls the updated mapping rules, and loads them into the local memory cache to achieve seamless hot update of the interface adaptation logic; for requests that are being processed, continue to use the old version of the mapping rules to complete the processing, and use the updated mapping rules for newly arrived requests to ensure the atomicity and consistency of request processing.

[0019] Preferably, the standardized interface template library in step two contains multiple types of interface templates. The type of the interface template is determined according to the functional category of the AI ​​algorithm module. The functional category includes at least one of image classification module, object detection module, natural language processing module, speech recognition module, and recommendation algorithm module. Each interface template predefines the standard input parameter format and standard output parameter format corresponding to the functional category.

[0020] Preferably, the format mapping relationship in step three includes a forward mapping relationship and a reverse mapping relationship; the forward mapping relationship is used to map the field names of the source module's native data format to the field names of the standard intermediate data format one-to-one, and the reverse mapping relationship is used to map the field names of the standard intermediate data format to the field names of the target module's native data format one-to-one; when there is no field in the standard intermediate data format that corresponds to a certain data field in the source module's native data format, the data field is marked as an extended field, and the extended field is appended to the end of the data structure of the standard intermediate data format in the form of an additional key-value pair.

[0021] Preferably, after normalizing the numerical data field in step three, the standardized value received by the receiving end is further denormalized according to the formula V_restored=V_std×(V_max-V_min)+V_min, where V_restored is the value after denormalization, V_std is the received standardized value, and V_min and V_max are the theoretical minimum and theoretical maximum values ​​of the corresponding data field in the target AI algorithm module, respectively.

[0022] Preferably, the protocol conversion engine in step four maintains a protocol conversion rule base. The protocol conversion rule base stores conversion rules between multiple protocol pairs. Each protocol pair consists of a source communication protocol type and a target communication protocol type. When it is determined that the source communication protocol and the target communication protocol are inconsistent, the protocol conversion engine searches the protocol conversion rule base for a conversion rule that matches the current source and target communication protocol types. If no matching conversion rule is found, a rule learning mode is triggered: the protocol conversion engine collects typical data packet examples of the source protocol and typical data packet examples of the target protocol, and automatically infers candidate mapping relationships between fields through field name similarity matching (such as using the edit distance algorithm to calculate the similarity of field names) and data structure hierarchy comparison. Candidate conversion rules are generated and output to the system operation and maintenance interface. After being reviewed and confirmed by the operation and maintenance personnel, they are stored in the protocol conversion rule base for automatic invocation during subsequent conversions of the same type of protocol.

[0023] Preferably, the matching degree in step five is calculated as follows: A resource type list for each computing resource node is obtained, wherein the resource type list records whether each computing resource node is equipped with a graphics processor; the computing resource type on which the AI ​​algorithm module to be executed depends is compared with the resource type list of each computing resource node, and nodes that meet the required computing resource type are selected to form a candidate node set; weight coefficients are assigned to CPU utilization, memory utilization, and graphics processor utilization, and the sum of the weight coefficients equals 1; the comprehensive load value of each computing resource node in the candidate node set is calculated, wherein the comprehensive load value is the sum of the products of CPU utilization and its weight coefficient, memory utilization and its weight coefficient, and graphics processor utilization and its weight coefficient; the comprehensive load value of each computing resource node in the candidate node set is normalized after taking the reciprocal, to obtain the matching degree of each computing resource node; the AI ​​algorithm module to be executed is scheduled to the computing resource node with the highest matching degree.

[0024] Preferably, in step seven, monitoring the version change information of each AI algorithm module adopts either a polling detection method or an event notification method. The polling detection method involves periodically sending version query requests to each AI algorithm module at preset time intervals, receiving the current version number returned by each AI algorithm module, and comparing the current version number with the version number recorded in the registration information database. The event notification method involves receiving version update notification messages actively pushed by each AI algorithm module when its own version is updated. When a version number change is detected, it is determined that the AI ​​algorithm module has undergone a version update.

[0025] Preferably, the standard intermediate data format uses JavaScript object representation or Extensible Markup Language as the data carrier; the key in the key-value pair structure is a string type, and the value in the key-value pair structure is any one of string type, numeric type, boolean type, array type, or object type; the standard intermediate data format also includes a metadata description part, which is used to record the data generation timestamp, data source module identifier, data version number, and data checksum.

[0026] Preferably, the method further includes an exception handling step: when performing any data conversion or protocol conversion operation in steps three to six, if the conversion operation fails, a failure exception is captured and the exception type is parsed; the exception type includes data format exception and communication transient exception, wherein the data format exception is at least one of the following: source data lacks required fields, field type mismatch, or field value exceeds the valid range; and the communication transient exception is at least one of the following: connection timeout, connection interruption, or temporary lack of response from the target end; if it is determined to be a data format exception, the retry is terminated, an error code and error description information are directly returned to the caller, and the source data involved in the failed conversion operation are completely saved in the exception data cache for subsequent manual investigation; if it is determined to be a communication transient exception, the failed conversion operation is retried according to a preset retry strategy, wherein the retry strategy includes a maximum number of retries and a retry interval; if the conversion operation still fails after the maximum number of retries is reached, an error code and error description information are returned to the caller.

[0027] The present invention has the following advantages: The method provided by the present invention performs unified registration and metadata extraction of heterogeneous AI algorithm modules, automatically generates a standardized interface encapsulation layer for each module, realizes plug-and-play AI algorithm modules under different technical frameworks, and greatly reduces the difficulty of system integration and development cost.

[0028] By establishing a standard intermediate data format and standardizing numerical data based on a normalization formula, the problems of inconsistent data formats and semantics between heterogeneous algorithm modules are effectively solved, ensuring the accuracy and integrity of information transmission between modules.

[0029] By automatically adapting and converting different communication protocols through a protocol conversion engine, interconnection and interoperability between modules under heterogeneous communication protocols are realized, eliminating the problem of information silos caused by protocol differences.

[0030] By using intelligent routing and load distribution mechanisms to schedule algorithm modules to the most suitable computing resource nodes, the overall resource utilization and task execution efficiency of the system are effectively improved.

[0031] Through the dynamic update mechanism of the adaptation strategy, the interface encapsulation can be automatically updated and pushed when the algorithm module version changes. This avoids the high maintenance costs and system downtime risks caused by manually modifying the adaptation code item by item in the traditional way, and ensures the long-term maintainability and scalability of the system. Attached Figure Description

[0032] To more intuitively illustrate the prior art and this application, exemplary drawings are provided below. It should be understood that the specific shapes and structures shown in the drawings should not generally be regarded as limiting conditions for implementing this application; for example, based on the technical concept disclosed in this application and the exemplary drawings, those skilled in the art are able to easily make conventional adjustments or further optimizations to the addition / reduction / classification, specific shapes, positional relationships, connection methods, size ratios, etc. of certain units (components).

[0033] Figure 1 A flowchart illustrating a standardized information interoperability and adaptation method for heterogeneous AI algorithm modules provided in this application embodiment. Detailed Implementation

[0034] The following specific embodiments illustrate the implementation of the present invention. Those skilled in the art can easily understand other advantages and effects of the present invention from the content disclosed in this specification. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. It should be understood that these embodiments are merely for further explanation of the present invention and should not be construed as limiting the scope of protection of the present invention. Technical engineers in the field can make some non-essential improvements and adjustments to the present invention based on the above-described content. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0035] Please see Figure 1 A standardized information interoperability and adaptation method for heterogeneous AI algorithm modules includes the following steps:

[0036] Step 1: Module Registration and Meta-information Extraction: Receive registration requests from at least one AI algorithm module, which originates from different technical frameworks or development environments; parse the module description file of each AI algorithm module, extracting its meta-information, including module name, input parameter structure, output parameter structure, dependent computing resource type, and communication protocol type; assign a globally unique module identifier to each AI algorithm module and store the meta-information in the registration information database.

[0037] Step 2: Standardized Interface Generation: Based on the metadata of each AI algorithm module extracted in Step 1, the standardized interface template library is called to generate a standardized interface encapsulation layer for each AI algorithm module. The standardized interface encapsulation layer includes an input parameter conversion sublayer, an output parameter conversion sublayer, and a calling protocol adaptation sublayer. The input parameter conversion sublayer converts standard format input parameters passed from external callers into the native format input parameters of each AI algorithm module. The output parameter conversion sublayer converts the native format output parameters of each AI algorithm module into standard format output parameters. The calling protocol adaptation sublayer converts standard protocol calls from external callers into native protocol calls of each AI algorithm module.

[0038] Step 3: Data Format Standardization and Conversion: Obtain the first data output from the source AI algorithm module. The first data has the native data format of the source module. According to the format mapping relationship recorded by the standardization interface encapsulation layer in Step 2, convert the first data into a standard intermediate data format to obtain the standardized second data. The standard intermediate data format uses a key-value pair structure to describe the data content. The key in the key-value pair is used to identify the data field name, and the value in the key-value pair is used to carry the specific numerical value of the data field. For numerical data fields, normalization is performed according to the formula V_std=(V_raw-V_min) / (V_max-V_min), where V_std is the standardized value, V_raw is the original value, V_min is the theoretical minimum value of the data field in the source AI algorithm module, and V_max is the theoretical maximum value of the data field in the source AI algorithm module. For non-numerical data fields, convert the non-numerical data into standardized coded values ​​according to a preset encoding mapping table.

[0039] Step 4, Protocol Adaptation and Communication Conversion: Obtain the target communication protocol type used by the target AI algorithm module. The target communication protocol type includes at least one of Hypertext Transfer Protocol, Message Queuing Telemetry Transfer Protocol, and Remote Procedure Call Protocol. Based on the communication protocol type information stored in the registration information database in Step 1, determine whether the source communication protocol and the target communication protocol are consistent. If they are inconsistent, call the protocol conversion engine to convert the data packet format of the source communication protocol to the data packet format of the target communication protocol according to the preset protocol conversion rules. The protocol conversion rules include the mapping relationship of data packet header fields and the mapping relationship of data payload fields. Send the converted data packet to the target AI algorithm module according to the transmission specifications of the target communication protocol.

[0040] Step 5, Intelligent Routing and Load Distribution: Based on the computing resource types relied upon by each AI algorithm module stored in Step 1, obtain the real-time load status information of each computing resource node in the current system. The real-time load status information includes at least one of the following: CPU utilization, memory utilization, and GPU utilization of each computing resource node. Calculate the matching degree between each AI algorithm module and each computing resource node based on the computing resource type requirements of each AI algorithm module and the real-time load status information of each computing resource node. Schedule the AI ​​algorithm modules to be executed to the computing resource node with the highest matching degree in descending order of matching degree.

[0041] Step Six: Execution Result Feedback and Format Reverse Conversion: Obtain the third data returned after the target AI algorithm module completes execution. This third data has the output data structure of the target module's native format. Based on the reverse format mapping relationship recorded in the standardized interface encapsulation layer in Step Two, convert the third data from the target module's native format to a standard intermediate data format to obtain the standardized fourth data. Perform reverse conversion on the fourth data according to the caller's data format requirements to obtain the fifth data for the caller to use directly. Return the fifth data to the caller.

[0042] Step 7: Dynamic Update of Adaptation Strategy: Monitor version change information of each AI algorithm module. When a version update of any AI algorithm module is detected, re-extract the updated metadata of that AI algorithm module; regenerate the standardized interface encapsulation layer of that AI algorithm module based on the updated metadata, and update the corresponding metadata record in the registration information database; publish the updated standardized interface encapsulation layer to the system's configuration center (such as Nacos, Consul, or Etcd) in the form of an interface mapping rule set. Each relevant calling node subscribes to the change event of the configuration center, asynchronously pulls the updated mapping rules, and loads them into the local memory cache to achieve seamless hot update of the interface adaptation logic; for requests that are being processed, continue to use the old version of the mapping rules to complete the processing, and use the updated mapping rules for newly arrived requests to ensure the atomicity and consistency of request processing.

[0043] The heterogeneous AI algorithm module standardized information interoperability adaptation system method of the present invention can be deployed on an adaptation server, which communicates with the execution nodes where multiple AI algorithm modules reside. Each AI algorithm module can run on different physical servers, virtual machines, or container environments. These AI algorithm modules may be implemented based on different technical frameworks such as TensorFlow, PyTorch, PaddlePaddle, and ONNX Runtime, and may also be developed using different programming languages ​​(such as Python, C++, and Java). The adaptation server, as an information relay and adaptation hub between the various AI algorithm modules, is responsible for completing core functions such as module registration, interface generation, data conversion, protocol adaptation, and routing distribution.

[0044] In step one, when a new AI algorithm module needs to be integrated into the system, its developer must provide a module description file. The module description file can be written in JSON or YAML format and must include at least the module name, module version number, names and data types of input parameters, names and data types of output parameters, the type of computing resources required for the module to run (e.g., CPU only, GPU acceleration, large memory required), and the communication protocol types supported by the module (e.g., HTTP RESTful API, MQTT, gRPC). After receiving the registration request, the adaptation server first performs syntax validation and integrity checks on the module description file. Once confirmed to be correct, it assigns a globally unique module identifier (e.g., using UUID v4 format) to the module and then stores the metadata in the registration information repository. The registration information repository can be implemented using a relational database (e.g., MySQL) or a key-value database (e.g., Redis), chosen based on the concurrency and data volume of the actual deployment scenario.

[0045] In step two, the standardized interface template library pre-stores interface templates for AI algorithm modules of different functional categories. For example, for the image classification module, the standard input parameter format can be defined as containing two fields: "image data" (binary or base64 encoded) and "top_k" (integer type, indicating the return of the top k classification results). The standard output parameter format can be defined as containing two fields: "classification label list" (string array) and "confidence score list" (floating-point array).

[0046] Based on the module function category extracted in step one (which can be obtained from the "Function Category" field in the module description file), the adaptation server selects the corresponding interface template from the template library, and then generates standardized interface encapsulation layer code specific to the module by combining the specific input and output parameter structure of the module. The generated encapsulation layer code can be implemented in languages ​​such as Python, Java, or C++, and deployed as a dynamic link library or a standalone service.

[0047] The input parameter conversion sublayer is responsible for mapping input parameters in standard format (such as parameters conforming to the image classification template format mentioned above) to the parameter format accepted by the module's native interface (such as the JSON or Protobuf structure that the module actually expects); the output parameter conversion sublayer has a similar function but in the opposite direction; the call protocol adaptation sublayer is responsible for converting standard protocol calls (such as unified HTTP calls) to the protocol calls that the module actually supports (such as gRPC calls).

[0048] Step three will be illustrated using an image classification scenario as an example. Assume the source AI algorithm module A outputs a Python dictionary-type data, containing a "predictions" field. The value of this field is a list, where each element is a dictionary containing "label" and "score". The standardized interface encapsulation layer of the adaptation server first converts this data into a standard intermediate data format based on the forward mapping relationship. The standard intermediate data format uses a JSON structure, for example:

[0049] {"result":[{"label":"cat","confidence":0.92},{"label":"dog","confidence":0.05}],"timestamp":"2026-08-06T10:30:00Z","source_module":"module_A"}.

[0050] For numerical data fields such as a confidence level of 0.92, if the theoretical minimum confidence level for this module is 0 and the theoretical maximum confidence level is 1, then according to the normalization formula...

[0051] V_std=(0.92-0) / (1-0)=0.92 is normalized.

[0052] If the theoretical minimum and maximum values ​​of a certain data field cannot be directly obtained from the module description file, they can be obtained by performing pre-run sampling statistics on the module. That is, during the module registration phase, multiple sets of test inputs are sent to the module, and the minimum and maximum values ​​of the field in the output data are collected as approximate values ​​of V_min and V_max. For non-numerical data fields such as the category label "cat", they are converted into the standardized code value 1 according to a preset encoding mapping table (such as {"cat":1, "dog":2, "bird":3,...}). The encoding mapping table can be uniformly generated and maintained during system initialization based on the label set reported by each module.

[0053] After the data standardization transformation is completed in step three to obtain the second data, the second data is temporarily stored in the memory buffer or message queue of the adaptation server in a standard intermediate data format, awaiting subsequent route distribution. Specifically, before the standardized second data goes through the protocol adaptation and communication conversion processing in step four, the routing management module of the adaptation server can first determine the target AI algorithm module according to the scheduling decision in step five, and then pass the second data to step four for protocol-level adaptation processing.

[0054] It should be noted that the normalization and denormalization processes described herein are applicable to scenarios where data fields only have relative magnitude comparisons between different modules and do not involve semantic judgments based on pre-trained fixed thresholds. If the target AI algorithm module has a strong dependency on a specific threshold in the input value (such as a classification confidence threshold of 0.5), this method further performs a threshold calibration step after denormalization: based on the statistical characteristics of the confidence distributions of the source and target modules, a nonlinear calibration is performed on the denormalized values ​​using a preset semantic mapping rule to ensure the validity of the threshold judgment logic of the target module. The semantic mapping rule is obtained during the module registration phase by fitting the output distributions of the source and target modules on the same test dataset.

[0055] In step four, assuming the source communication protocol is HTTP and the target communication protocol is gRPC, the protocol conversion engine first queries the registration information database from step one to find that the target module's communication protocol type is gRPC. After determining that this is inconsistent with the source HTTP protocol, it searches the protocol conversion rule base for HTTP-to-gRPC conversion rules. These rules define how fields in the HTTP request header (such as Content-Type and Authorization) are mapped to gRPC metadata, and how the JSON data structure in the HTTP request body is mapped to the gRPC Protobuf message structure.

[0056] After the protocol conversion engine completes the data packet format conversion according to these rules, it sends the converted data packet to the target AI algorithm module through the gRPC client. During the protocol conversion process, if some HTTP header fields do not have a direct corresponding field in the gRPC protocol, these fields are appended to the gRPC request in the form of custom metadata to ensure the integrity of the information.

[0057] In step five, the adaptation server first obtains a list of resource types for each computing resource node. This list clearly records whether each node is equipped with a graphics processing unit (GPU) and the specific model of the GPU. Taking the image classification module to be executed as an example, its module description file records that the type of computing resource it depends on is "requires GPU acceleration".

[0058] The adaptation server compares all nodes in the system with the requirement. Assuming the system has four nodes, if node D is not equipped with a GPU, it does not meet the hard constraint and is directly removed from the scheduling candidate list, not participating in the subsequent matching degree calculation. The remaining nodes A, B, and C constitute the candidate node set.

[0059] Subsequently, the adaptation server obtains the real-time load status of each node in the candidate node set. Assume that node A has a CPU utilization of 30%, memory utilization of 40%, and GPU utilization of 20%; node B has a CPU utilization of 70%, memory utilization of 50%, and GPU utilization of 60%; and node C has a CPU utilization of 10%, memory utilization of 20%, and GPU utilization of 5%.

[0060] For the image classification module requiring GPU acceleration, the system sets the scheduling weight allocation strategy as follows: CPU utilization weight coefficient is 0.2, memory utilization weight coefficient is 0.1, and GPU utilization weight coefficient is 0.7. The adaptation server calculates the overall load value of each node.

[0061] The overall load value of node A is

[0062] 0.2×30%+0.1×40%+0.7×20%=0.06+0.04+0.14=0.24

[0063] The overall load value of node B is

[0064] 0.2×70%+0.1×50%+0.7×60%=0.14+0.05+0.42=0.61,

[0065] The overall load value of node C is

[0066] 0.2×10%+0.1×20%+0.7×5%=0.02+0.02+0.035=0.075.

[0067] The adaptation server takes the reciprocals of each comprehensive load value, which are 4.17, 1.64, and 13.33 respectively. These reciprocals are then normalized by dividing the reciprocal of each node by the sum of all node reciprocals. The resulting matching scores are: 4.17 / (4.17+1.64+13.33) = 0.218 for node A, 1.64 / 19.14 = 0.086 for node B, and 13.33 / 19.14 = 0.696 for node C. Since node C has the highest matching score, the adaptation server schedules the image classification module to be executed on node C.

[0068] By employing the aforementioned mechanism of screening before calculation, the common-sense error of scheduling GPU-dependent modules to nodes without GPUs is effectively avoided. At the same time, weighted load calculation ensures that the node with the lightest current load is always selected among nodes that meet the resource type requirements.

[0069] In step six, the third data returned by the target AI algorithm module after execution is in its native format. For example, if the target module is an image classification module implemented in PyTorch, it might return a PyTorch Tensor object. The standardized interface encapsulation layer of the adaptation server first converts the Tensor object into Python native data types (such as lists and floating-point numbers), and then converts these data into the fourth data in a standard intermediate data format according to the reverse mapping relationship. Finally, according to the data format requirements specified by the caller when initiating the call (such as the caller requiring XML format), the fourth data is converted from JSON format to XML format to obtain the fifth data, which is then returned to the caller. If the caller does not specify a specific return format, the standard intermediate data format (JSON) is returned by default.

[0070] In step seven, the adaptation server monitors the version changes of each AI algorithm module through a polling detection method. Specifically, every 30 seconds, the adaptation server sends a version query request (such as an HTTP GET request to access the module's " / version" endpoint) to each registered AI algorithm module, and each module returns its current version number (such as "v2.1.3"). The adaptation server compares the returned version number with the version number recorded in the registration information database.

[0071] If a version number change is detected, such as from "v2.1.3" to "v2.2.0", the adaptation server requests the latest module description file from the module again, extracts the updated metadata (focusing on whether the input and output parameter structures have changed), and then re-executes the standardized interface generation process in step two to generate new standardized interface encapsulation layer code and update the records in the registration information database. Subsequently, the adaptation server pushes the new standardized interface encapsulation layer to all caller nodes communicating with the module via hot update, ensuring that subsequent calls use the latest interface adaptation logic.

[0072] Regarding exception handling, the adaptation server uses a try-catch mechanism to catch all types of exceptions when performing data conversion or protocol conversion operations. After catching an exception, the adaptation server first parses the exception type to determine the subsequent handling strategy.

[0073] If the captured data format anomaly is, for example, during the data format standardization conversion in step three, the first data returned by the source AI algorithm module is missing a required field necessary for the mapping relationship (e.g., the image classification module should return the "predictions" field but it does not), or the returned field type does not match the expectation (e.g., the expected numerical type is received but the actual received type is the string "abc"), or the value of the numerical field is significantly beyond the preset valid range of the field (e.g., the confidence field is expected to be between 0 and 1 but the actual received value is 2.5), then the adaptation server determines that the anomaly is a deterministic error.

[0074] For this type of data format anomaly, no matter how many times it is retried, the conversion operation will never succeed as long as the source data itself is not corrected. Therefore, the adaptation server directly terminates the retry process, does not perform any retry operations, returns the error code "E008" and the error description "Data format conversion failed: Field XXX is missing or type mismatch" to the caller, and at the same time, completely saves all the original data involved in this failed conversion operation in the abnormal data cache.

[0075] The exception data cache uses a first-in-first-out queue structure for storage. Each exception record includes the exception occurrence time, source module identifier, target module identifier, original data content, exception type label, and stack trace information, which facilitates manual investigation and data repair by maintenance personnel.

[0076] If the captured exception is a transient communication anomaly, such as a connection timeout, unexpected TCP connection interruption, or the target end returning a service unavailable status code (e.g., HTTP 503) when the adaptation server sends the converted data packet to the target AI algorithm module during the protocol adaptation and communication conversion process in step four, then the adaptation server determines that the exception is a transient error. In most cases, such exceptions do not require modification of data or code; simply waiting for the network to recover or the target end's pressure to ease before resending will resolve the issue.

[0077] The adaptation server performs retry operations according to a preset retry policy. The retry policy sets a maximum of 3 retries, with retry intervals of 1 second, 2 seconds, and 4 seconds respectively, employing an exponential backoff algorithm to reduce network congestion risk. Before each retry, the adaptation server checks the connectivity status of the target device. If the target device remains unresponsive, it continues to wait for the next retry interval. If the conversion operation still fails after 3 retries, the adaptation server abandons the retry, returns error code "E009" and error description "Constant communication anomaly: Target device unresponsive within the maximum number of retries" to the caller, and records the failed operation in the system log for monitoring and alerting by operations and maintenance personnel.

[0078] By using the differentiated exception handling mechanism that distinguishes error types as described above, this invention effectively avoids wasting system resources and time on deterministic errors, while ensuring the system's self-recovery capability when facing non-fatal failures such as network jitter through the retry mechanism for transient errors.

[0079] The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A method for standardized information exchange and adaptation of heterogeneous AI algorithm modules, characterized in that, Includes the following steps: Step 1: Module Registration and Meta-information Extraction: Receive registration requests from at least one AI algorithm module, which originates from different technical frameworks or development environments; parse the module description file of each AI algorithm module, extracting its meta-information, including module name, input parameter structure, output parameter structure, dependent computing resource type, and communication protocol type; assign a globally unique module identifier to each AI algorithm module and store the meta-information in the registration information database. Step 2: Standardized Interface Generation: Based on the metadata of each AI algorithm module extracted in Step 1, the standardized interface template library is called to generate a standardized interface encapsulation layer for each AI algorithm module. The standardized interface encapsulation layer includes an input parameter conversion sublayer, an output parameter conversion sublayer, and a calling protocol adaptation sublayer. The input parameter conversion sublayer converts standard format input parameters passed from external callers into the native format input parameters of each AI algorithm module. The output parameter conversion sublayer converts the native format output parameters of each AI algorithm module into standard format output parameters. The calling protocol adaptation sublayer converts standard protocol calls from external callers into native protocol calls of each AI algorithm module. Step 3: Data Format Standardization and Conversion: Obtain the first data output from the source AI algorithm module. The first data has the native data format of the source module. According to the format mapping relationship recorded by the standardization interface encapsulation layer in Step 2, convert the first data into a standard intermediate data format to obtain the standardized second data. The standard intermediate data format uses a key-value pair structure to describe the data content. The key in the key-value pair is used to identify the data field name, and the value in the key-value pair is used to carry the specific numerical value of the data field. For numerical data fields, normalization is performed according to the formula V_std=(V_raw-V_min) / (V_max-V_min), where V_std is the standardized value, V_raw is the original value, V_min is the theoretical minimum value of the data field in the source AI algorithm module, and V_max is the theoretical maximum value of the data field in the source AI algorithm module. For non-numerical data fields, convert the non-numerical data into standardized coded values ​​according to a preset encoding mapping table. Step 4, Protocol Adaptation and Communication Conversion: Obtain the target communication protocol type used by the target AI algorithm module. The target communication protocol type includes at least one of Hypertext Transfer Protocol, Message Queue Telemetry Transfer Protocol, and Remote Procedure Call Protocol. Based on the communication protocol type information stored in the registration information database in Step 1, determine whether the source communication protocol and the target communication protocol are consistent. If there is a discrepancy, the protocol conversion engine is invoked to convert the data packet format of the source communication protocol into the data packet format of the target communication protocol according to the preset protocol conversion rules. The protocol conversion rules include the mapping relationship between the data packet header field and the data payload field. The converted data packet is then sent to the target AI algorithm module according to the transmission specifications of the target communication protocol. Step 5, Intelligent Routing and Load Distribution: Based on the computing resource types relied upon by each AI algorithm module stored in Step 1, obtain the real-time load status information of each computing resource node in the current system. The real-time load status information includes at least one of the following: CPU utilization, memory utilization, and GPU utilization of each computing resource node. Calculate the matching degree between each AI algorithm module and each computing resource node based on the computing resource type requirements of each AI algorithm module and the real-time load status information of each computing resource node. Schedule the AI ​​algorithm modules to be executed to the computing resource node with the highest matching degree in descending order of matching degree. Step Six: Execution Result Feedback and Format Reverse Conversion: Obtain the third data returned after the target AI algorithm module completes execution. This third data has the output data structure of the target module's native format. Based on the reverse format mapping relationship recorded in the standardized interface encapsulation layer in Step Two, convert the third data from the target module's native format to a standard intermediate data format to obtain the standardized fourth data. Perform reverse conversion on the fourth data according to the caller's data format requirements to obtain the fifth data for the caller to use directly. Return the fifth data to the caller. Step 7: Dynamic Update of Adaptation Strategy: Monitor version change information of each AI algorithm module. When a version update of any AI algorithm module is detected, re-extract the updated metadata of that AI algorithm module; regenerate the standardized interface encapsulation layer of that AI algorithm module based on the updated metadata, and update the corresponding metadata record in the registration information database; publish the updated standardized interface encapsulation layer to the system configuration center in the form of an interface mapping rule set. Each relevant calling node subscribes to the change event of the configuration center, asynchronously pulls the updated mapping rules, and loads them into the local memory cache to achieve seamless hot update of the interface adaptation logic; for requests that are being processed, continue to use the old version of the mapping rules to complete the processing, and use the updated mapping rules for newly arrived requests to ensure the atomicity and consistency of request processing.

2. The method for standardized information interoperability and adaptation of heterogeneous AI algorithm modules according to claim 1, characterized in that, The standardized interface template library mentioned in step two contains various types of interface templates. The type of the interface template is determined according to the functional category of the AI ​​algorithm module. The functional category includes at least one of the following: image classification module, object detection module, natural language processing module, speech recognition module, and recommendation algorithm module. Each interface template predefines the standard input parameter format and standard output parameter format corresponding to the functional category.

3. The method for standardized information interoperability and adaptation of heterogeneous AI algorithm modules according to claim 2, characterized in that, The format mapping relationship described in step three includes a forward mapping relationship and a reverse mapping relationship; the forward mapping relationship is used to map the field names of the source module's native data format to the field names of the standard intermediate data format one-to-one, and the reverse mapping relationship is used to map the field names of the standard intermediate data format to the field names of the target module's native data format one-to-one. When there is no field in the standard intermediate data format that corresponds to a certain data field in the original data format of the source module, the data field is marked as an extended field, and the extended field is appended to the end of the data structure of the standard intermediate data format in the form of an additional key-value pair. This applies to numerical fields with fixed value domain semantics, such as classification confidence or probability values.

4. The method for standardized information interoperability and adaptation of heterogeneous AI algorithm modules according to claim 3, characterized in that, In step three, after normalizing the numerical data fields, the standardized values ​​received by the receiving end are denormalized according to the formula V_restored=V_std×(V_max-V_min)+V_min, where V_restored is the value after denormalization, V_std is the received standardized value, and V_min and V_max are the theoretical minimum and maximum values ​​of the corresponding data fields in the target AI algorithm module, respectively.

5. The method for standardized information interoperability and adaptation of heterogeneous AI algorithm modules according to claim 1, characterized in that, The protocol conversion engine described in step four maintains a protocol conversion rule base. This rule base stores conversion rules between multiple protocol pairs. Each protocol pair consists of a source communication protocol type and a target communication protocol type. When it is determined that the source communication protocol and the target communication protocol are inconsistent, the protocol conversion engine searches the rule base for a conversion rule that matches the current source and target communication protocol types. If no matching conversion rule is found, a rule learning mode is triggered: the protocol conversion engine collects typical data packet examples of the source protocol and the target protocol, automatically infers candidate mapping relationships between fields through field name similarity matching and data structure hierarchy comparison, generates candidate conversion rules, and outputs them to the system operation and maintenance interface. After review and confirmation by the operation and maintenance personnel, these rules are stored in the protocol conversion rule base for automatic invocation during subsequent conversions of the same type of protocol.

6. The method for standardized information interoperability and adaptation of heterogeneous AI algorithm modules according to claim 1, characterized in that, The matching degree in step five is calculated as follows: Obtain a resource type list for each computing resource node, which records whether each computing resource node is equipped with a graphics processor; compare the computing resource types that the AI ​​algorithm module to be executed depends on with the resource type list of each computing resource node, and filter out nodes that meet the required computing resource types to form a candidate node set; assign weight coefficients to CPU utilization, memory utilization, and graphics processor utilization, with the sum of the weight coefficients equal to 1; calculate the comprehensive load value of each computing resource node in the candidate node set, where the comprehensive load value is the sum of the products of CPU utilization and its weight coefficient, memory utilization and its weight coefficient, and graphics processor utilization and its weight coefficient; normalize the comprehensive load value of each computing resource node in the candidate node set by taking the reciprocal of the total load value to obtain the matching degree of each computing resource node; schedule the AI ​​algorithm module to be executed to the computing resource node with the highest matching degree.

7. The method for standardized information interoperability and adaptation of heterogeneous AI algorithm modules according to claim 1, characterized in that, Step seven involves monitoring version change information of each AI algorithm module using either polling or event notification methods. The polling method involves periodically sending version query requests to each AI algorithm module at preset time intervals, receiving the current version number returned by each module, and comparing this current version number with the version number recorded in the registration information database. The event notification method involves receiving version update notification messages proactively pushed by each AI algorithm module when its own version is updated. When a version number change is detected, it is determined that the AI ​​algorithm module has undergone a version update.

8. The method for standardized information interoperability and adaptation of heterogeneous AI algorithm modules according to claim 1, characterized in that, The standard intermediate data format uses JavaScript object representation or Extensible Markup Language as the data carrier; the keys in the key-value pair structure are of string type, and the values ​​in the key-value pair structure are any one of string type, numeric type, boolean type, array type, or object type; the standard intermediate data format also includes a metadata description part, which is used to record the data generation timestamp, data source module identifier, data version number, and data checksum.

9. The method for standardized information interoperability and adaptation of heterogeneous AI algorithm modules according to claim 1, characterized in that, It also includes an exception handling step: when performing any data conversion or protocol conversion operation in steps three to six, if the conversion operation fails, the failure exception is captured and the exception type is parsed; the exception type includes data format exception and communication transient exception. The data format exception is at least one of the following: source data is missing a required field, field type mismatch, or field value exceeds the valid range. The communication transient exception is at least one of the following: connection timeout, connection interruption, or no response from the target end. If it is determined to be a data format exception, the retry is terminated, and an error code and error description information are directly returned to the caller. The source data involved in the failed conversion operation is completely saved in the exception data cache area for subsequent manual investigation. If it is determined to be a communication transient exception, the failed conversion operation is retried according to a preset retry strategy, which includes a maximum number of retries and a retry interval. If the conversion operation still fails after the maximum number of retries has been reached, an error code and error description will be returned to the caller.

Images