Model management system, method, electronic device and medium for supply chain management

Abstract

The application relates to the technical field of computers and provides a model management system and method for supply chain management and control, an electronic device and a medium. The system comprises: an application layer configured to deploy at least one artificial intelligence application for supply chain management and control; a conversion layer configured to convert input and output requirements of the artificial intelligence applications into a plurality of standardized data formats to obtain input and output requirements of the conversion layer, and transmit model return results to the application layer; and an adaptation layer comprising adaptation modules corresponding to the artificial intelligence models one by one, each adaptation module comprising a calling interface of the corresponding artificial intelligence model, and the adaptation modules being configured to perform bidirectional conversion between the respective calling interfaces and the plurality of standardized data formats. In this way, the complexity of model switching is simplified and the cost of model calling is reduced.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a model management system, method, electronic device, and medium for supply chain management. Background Technology

[0002] With the development of AI large-scale modeling technologies and the construction of infrastructure such as data centers, AI technology is being used to empower and improve efficiency in various application scenarios. Various types of AI large-scale models are available from vendors, some using paid models such as subscriptions or token-based billing, while others are open-source. This makes the cost of using large-scale models unpredictable. Furthermore, different large-scale models may have different focuses, security strategies, and privacy requirements. Upper-layer applications built on the underlying AI large-scale models provided by vendors face system operation risks. Changes in the large-scale model vendor's pricing strategy, service methods, or security and privacy aspects may lead to functional failures and increased costs. Developing and deploying localized or private models can mitigate the system operation risks associated with relying on large-scale model vendors, but developing large-scale models requires significant investment of time and resources, far exceeding the affordability of most upper-layer application developers. Additionally, switching from one large-scale model to another not only faces high switching costs but also risks that the application ecosystem built on the original large-scale model may not perform as well on the new one, posing a business quality risk.

[0003] To this end, this application proposes a model management system, method, electronic device, and medium for supply chain management. Targeting the intersection of artificial intelligence and supply chain management, it not only supports free switching between large models without modifying the upper-layer application, thereby effectively avoiding system operation risks caused by changes in pricing strategies or service interruptions of large model vendors, and helps to fully utilize free or low-cost quotas to reduce the cost of calling large models, but also simplifies the adaptation complexity of model switching and application ecosystem migration, which is conducive to ensuring effectiveness and controlling system operation risks. Summary of the Invention

[0004] Firstly, this application provides a model management system for supply chain management. The model management system includes: an application layer for deploying at least one artificial intelligence application for supply chain management; a conversion layer for converting the input / output requirements of the at least one artificial intelligence application into multiple standardized data formats to obtain the input / output requirements of the conversion layer, and transmitting model return results to the application layer, wherein the multiple standardized data formats cover all input / output types associated with the input / output requirements of the at least one artificial intelligence application; an adaptation layer, wherein the adaptation layer includes at least one adaptation module corresponding one-to-one with at least one artificial intelligence model, each of the at least one adaptation module including a calling interface for a corresponding artificial intelligence model in the at least one artificial intelligence model, and the at least one adaptation module being used for bidirectional conversion between its respective calling interface and the multiple standardized data formats; wherein the adaptation layer includes a business allocation engine, the business allocation engine being used to allocate the input / output requirements of the conversion layer in the at least one artificial intelligence model based on a business allocation strategy, and to obtain the model return results from the allocated artificial intelligence model and transmit the model return results to the conversion layer.

[0005] Through the first aspect of this application, by utilizing a three-layer architecture and modular design of application layer – transformation layer – adaptation layer, along with a two-layer transformation mechanism implemented separately in the transformation and adaptation layers, decoupling and isolation are achieved between the AI ​​application at the application layer and the underlying AI model. This ensures that the development of the AI ​​application and the adaptation development of the underlying AI model are independent of each other. Changes to the application layer code only affect the standardized data format, while changes to the calling details of the underlying AI model only affect the module parameters of the adaptation module. Thus, based on the decoupling and isolation between the AI ​​application at the application layer and the underlying AI model, combined with the business allocation engine of the adaptation layer, for the intersection of AI and supply chain management, this not only supports free switching between large models without modifying the upper-layer application, effectively mitigating system operation risks caused by changes in pricing strategies or service interruptions from large model vendors, and helping to fully utilize free or low-cost quotas to reduce the cost of calling large models, but also simplifies the adaptation complexity of model switching and application ecosystem migration, thus helping to ensure effectiveness and control system operation risks.

[0006] In one possible implementation of the first aspect of this application, the service allocation strategy includes a free quota priority routing strategy, which instructs the service allocation engine to prioritize the allocation of tasks in the input / output requirements of the conversion layer that meet the free mode quota to the at least one artificial intelligence model that has the free mode quota.

[0007] In one possible implementation of the first aspect of this application, the business allocation strategy includes a task type matching routing strategy, which instructs the business allocation engine to preferentially allocate tasks of a given type in the input / output requirements of the conversion layer to the artificial intelligence model in the at least one artificial intelligence model that has the processing capability for the given type of task.

[0008] In one possible implementation of the first aspect of this application, the given type of task includes at least one of the following: visual generation task, multimodal task, long text semantic parsing task, and context parsing task.

[0009] In one possible implementation of the first aspect of this application, the service allocation strategy includes a cost-optimal routing strategy, which instructs the service allocation engine to preferentially allocate the input / output requirements of the conversion layer to the AI ​​model with the lowest call cost among the at least one AI models.

[0010] In one possible implementation of the first aspect of this application, the service allocation strategy includes a fault-tolerant degradation routing strategy, which instructs the service allocation engine to allocate the input / output requirements of the conversion layer to a backup model associated with the target model in the at least one artificial intelligence model when the target model in the at least one artificial intelligence model is unavailable.

[0011] In one possible implementation of the first aspect of this application, the service allocation strategy includes a dual-model parallel verification routing strategy. The dual-model parallel verification routing strategy is used to instruct the service allocation engine to simultaneously submit representative tasks from the input / output requirements of the transformation layer to the current model and the model to be switched in the at least one artificial intelligence model. Furthermore, the model output results of the current model for the representative task and the model output results of the model to be switched for the representative task are used to realize model switching from the current model to the model to be switched.

[0012] In one possible implementation of the first aspect of this application, the adaptation layer further includes a result comparison engine. The dual-model parallel verification routing strategy is used to instruct the result comparison engine to compare the model output results of the current model for the representative task with the model output results of the model to be switched for the representative task to obtain a model difference index. Then, based on the model difference index, the module parameters of the adaptation module corresponding to the model to be switched in the at least one adaptation module are continuously adjusted until the model difference index converges to a preset threshold.

[0013] In one possible implementation of the first aspect of this application, the dual-model parallel verification routing strategy is optimized for supply chain intelligent management and control scenarios. The model difference indicators include supply chain business indicators, ROUGE-L similarity, and field-level accuracy. The supply chain business indicators include supply chain forecasting task accuracy, path optimality, and inventory turnover rate.

[0014] In one possible implementation of the first aspect of this application, the dual-model parallel verification routing strategy further indicates that when the model difference index exceeds the preset threshold, the model to be switched is determined to be unavailable and the current model is automatically switched to the backup model.

[0015] In one possible implementation of the first aspect of this application, the module parameters of each of the at least one adapter module include: call interface encapsulation format, data packet size limit, handshake protocol, and data retransmission mechanism, and the at least one adapter module is maintained separately and independently of each other.

[0016] In one possible implementation of the first aspect of this application, the plurality of standardized data formats includes visual data formats, text data formats, structured data formats, and hybrid task package data formats.

[0017] In one possible implementation of the first aspect of this application, the visual data format is used to standardize image-type input and video-type input, and the parameters of the visual data format include resolution, color space, frame rate, and compression format; the text data format is used to standardize text-type input, and the parameters of the text data format include encoding method, maximum token length, language identifier, and context window definition; the structured data format is used to standardize supply chain structured data, and the parameters of the structured data format include structured data type, field type annotation, and numerical precision; the hybrid task package data format is used to package multiple subtasks into a single task package, and the parameters of the hybrid task package data format include task identifier, priority, dependency graph, and callback interface definition.

[0018] In one possible implementation of the first aspect of this application, the multiple standardized data formats are optimized for intelligent supply chain management scenarios. The structured data format includes dedicated field specifications for order data, inventory snapshots, transportation trajectories, and inventory holding unit attributes. The hybrid task package data format supports a built-in supply chain task priority chain. Furthermore, the visual data format is used for shelf image recognition, warehouse video analysis, and multimodal feature extraction of goods. The text data format is used for contract semantic parsing, procurement requirement text understanding, and supplier evaluation report generation. The structured data format is used for order data processing, inventory snapshot analysis, transportation trajectory prediction, and inventory holding unit attribute parsing. The hybrid task package data format is used to support end-to-end supply chain analysis tasks.

[0019] In one possible implementation of the first aspect of this application, the conversion layer further includes a task package packaging engine, which is used to decompose the composite requirements of the application layer into multiple single-type subtasks based on the multiple standardized data formats and to arrange the execution order and priority labeling of the multiple single-type subtasks, thereby supporting supply chain end-to-end analysis tasks. Furthermore, the conversion layer is also used for reverse parsing to convert the model return result into the business data format of the application layer.

[0020] In one possible implementation of the first aspect of this application, the at least one artificial intelligence application includes multimodal feature extraction and parsing, nonlinear data processing, supply chain demand forecasting, logistics route optimization, and intelligent inventory control.

[0021] Secondly, embodiments of this application also provide a model management method for supply chain control. The model management method includes: deploying at least one artificial intelligence application for supply chain control through an application layer; converting the input / output requirements of each of the at least one artificial intelligence application into multiple standardized data formats through a conversion layer to obtain the input / output requirements of the conversion layer; and transmitting model return results to the application layer, wherein the multiple standardized data formats cover all input / output types associated with the input / output requirements of each of the at least one artificial intelligence application; deploying at least one adaptation module corresponding one-to-one with at least one artificial intelligence model through an adaptation layer, wherein each of the at least one adaptation module includes a calling interface for a corresponding artificial intelligence model in the at least one artificial intelligence model, and the at least one adaptation module is respectively used for bidirectional conversion between its respective calling interface and the multiple standardized data formats; wherein the adaptation layer includes a business allocation engine, which is used to allocate the input / output requirements of the conversion layer in the at least one artificial intelligence model based on a business allocation strategy, and to obtain the model return results from the allocated artificial intelligence model and transmit the model return results to the conversion layer.

[0022] Through the second aspect of this application, by utilizing a three-layer architecture and modular design of application layer – transformation layer – adaptation layer, along with a total of two-layer transformation mechanisms performed separately in the transformation and adaptation layers, decoupling and isolation are achieved between the AI ​​application at the application layer and the underlying AI model. This ensures that the development of the AI ​​application and the adaptation development of the underlying AI model are independent of each other. Changes to the application layer code only affect the standardized data format, while changes to the calling details of the underlying AI model only affect the module parameters of the adaptation module. Thus, based on the decoupling and isolation between the AI ​​application at the application layer and the underlying AI model, combined with the business allocation engine of the adaptation layer, for the intersection of AI and supply chain management, this not only supports free switching between large models without modifying the upper-layer application, effectively avoiding system operation risks caused by changes in pricing strategies or service interruptions from large model vendors, and helping to fully utilize free or low-cost quotas to reduce the cost of calling large models, but also simplifies the adaptation complexity of model switching and application ecosystem migration, which is beneficial for ensuring effectiveness and controlling system operation risks.

[0023] In one possible implementation of the second aspect of this application, the service allocation strategy includes a free quota priority routing strategy, a task type matching routing strategy, a cost-optimal routing strategy, a fault-tolerant degradation routing strategy, and a dual-model parallel verification routing strategy.

[0024] In one possible implementation of the second aspect of this application, the module parameters of each of the at least one adapter module include: call interface encapsulation format, data packet size limit, handshake protocol, and data retransmission mechanism, and the at least one adapter module is maintained separately and independently of each other.

[0025] In one possible implementation of the second aspect of this application, the plurality of standardized data formats include visual data formats, text data formats, structured data formats, and hybrid task package data formats.

[0026] Thirdly, embodiments of this application also provide a computer device, the computer device including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement a method according to any of the above-mentioned implementations.

[0027] Fourthly, embodiments of this application also provide a computer-readable storage medium storing computer instructions that, when executed on a computer device, cause the computer device to perform a method according to any of the above-described implementations.

[0028] Fifthly, embodiments of this application also provide a computer program product, the computer program product including instructions stored on a computer-readable storage medium, which, when executed on a computer device, cause the computer device to perform a method according to any of the above-described aspects. Attached Figure Description

[0029] To more clearly illustrate the technical solutions of the embodiments of this application, the drawings used in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0030] Figure 1 A schematic diagram of a model management system for supply chain control provided in an embodiment of this application; Figure 2 A schematic diagram illustrating a conversion layer with multiple standardized data formats and an adaptation layer with multiple adaptation modules provided in an embodiment of this application; Figure 3 A schematic diagram illustrating a progressive switching mechanism based on a dual-model parallel verification routing strategy, provided in an embodiment of this application; Figure 4 A flowchart illustrating dynamic switching and task routing of a large model provided in an embodiment of this application; Figure 5 A flowchart illustrating a model management method for supply chain control provided in an embodiment of this application; Figure 6 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application. Detailed Implementation

[0031] The embodiments of this application will now be described in further detail with reference to the accompanying drawings.

[0032] It should be understood that in the description of this application, "at least one" means one or more, and "multiple" means two or more. In addition, the words "first," "second," etc., unless otherwise stated, are used only for the purpose of distinguishing descriptions and should not be construed as indicating or implying relative importance or order.

[0033] Figure 1 This is a schematic diagram of a model management system for supply chain control provided as an embodiment of this application. Figure 1 As shown, the model management system includes: an application layer 100 for deploying at least one artificial intelligence application for supply chain management; a conversion layer A110 for converting the input / output requirements of the at least one artificial intelligence application into multiple standardized data formats to obtain the input / output requirements of the conversion layer A110, and transmitting model return results to the application layer 100. The multiple standardized data formats cover all input / output types associated with the input / output requirements of the at least one artificial intelligence application. The model management system also includes an adaptation layer A120. The adaptation layer A120 includes at least one adaptation module corresponding one-to-one with the at least one artificial intelligence model. Each adaptation module includes a calling interface for the corresponding artificial intelligence model in the at least one artificial intelligence model. The at least one adaptation module is used for bidirectional conversion between its respective calling interface and the multiple standardized data formats. The adaptation layer A120 includes a business allocation engine 122. The business allocation engine 122 is used to allocate the input and output requirements of the conversion layer A110 in the at least one artificial intelligence model based on the business allocation strategy, and to obtain the model return results from the allocated artificial intelligence model and transmit the model return results to the conversion layer A110.

[0034] See Figure 1For illustrative purposes, application layer 100 includes at least one artificial intelligence application, specifically including multimodal feature extraction and parsing 101, nonlinear data processing 102, supply chain demand forecasting 103, logistics route optimization 104, and intelligent inventory control 105. Conversion layer A110 includes a standardized data format converter 112, used to convert the input and output requirements of the at least one artificial intelligence application into various standardized data formats to obtain the input and output requirements of conversion layer A110. In some embodiments, conversion layer A110 further includes a task package packaging engine 114. For illustrative purposes, adaptation layer A120 includes multiple adaptation modules corresponding one-to-one with multiple artificial intelligence models, specifically including adaptation module A corresponding to artificial intelligence model A, adaptation module B corresponding to artificial intelligence model B, adaptation module C corresponding to artificial intelligence model C, and adaptation module D corresponding to artificial intelligence model D. It should be understood that... Figure 1 The model management system for supply chain control shown herein includes an application layer 100 containing a number and specific composition of artificial intelligence applications, as well as an adaptation layer A120 containing a number of adaptation modules and the composition of the corresponding artificial intelligence models. These can be specifically defined according to actual needs and application scenarios. Figure 1 The specific content shown is for illustrative purposes only.

[0035] Continue reading Figure 1With the widespread application of large-scale AI models across various fields, the use of underlying AI models to support intelligent supply chain management in the intersection of AI and supply chain management may lead to functional failures and increased costs due to changes in pricing strategies, service methods, or security and privacy concerns by large-scale model vendors. For example, large-scale model vendors may convert previously open-source models into closed-source, paid models. Alternatively, new versions of large-scale models may have access restrictions in specific countries or regions, or pose security and privacy risks. Furthermore, different large-scale models may have their own strengths; for instance, some models excel at video generation while others excel at text parsing. Developers of upper-layer applications built on top of these underlying AI model technologies can mitigate the system operational risks associated with reliance on large-scale model vendors by developing and deploying localized or proprietary models. However, developing large-scale models in-house requires significant investment of time and resources, far exceeding the affordability of most upper-layer application developers. Therefore, most developers of upper-layer applications, especially those in the field of intelligent supply chain management, rely on AI models provided by various large model vendors as underlying technical support. This exposes them to various system operational risks, and changes in pricing strategies, security policies, etc., may necessitate migrating the entire application ecosystem from one large model to another. This not only presents high switching costs but also risks that the application ecosystem built on the original large model may not achieve the same performance on the new model, posing a business quality risk. If each migration to a new large model requires a complete reconstruction of the upper-layer application ecosystem developed for the original large model, or the development of a separate application ecosystem for multiple large models, it inevitably leads to a huge workload and cost of reconstruction. However, the underlying operating principles, infrastructure, and key algorithms relied upon by various large model vendors when developing their respective large models often differ significantly, and much of this content is not publicly disclosed. Generally, the external capabilities of the large models are provided through specific calling methods and dedicated calling interfaces, further increasing the complexity and economic cost of adapting to various large models.

[0036] Continue reading Figure 1 ,by Figure 1Taking the application layer 100, conversion layer A110, and adaptation layer A120 as an example, the three-layer architecture and modular design of the application layer-conversion layer-adaptation layer achieve decoupling and isolation between the AI ​​applications deployed in the application layer and the underlying AI models. When switching between different large models, the upper-layer application ecosystem for supply chain management does not need any modification. Therefore, the development and maintenance of the upper-layer application ecosystem are carried out without the awareness of the underlying large models, thus avoiding the risks brought about by strong binding with large models. Through the switching between different large models and the scheduling and allocation between large models, the system operation risks brought about by changes in the charging strategy and service method of large models are effectively overcome. In addition, in order to ensure the normal operation and correct function of the upper-layer application ecosystem, that is, the AI ​​applications deployed in the application layer, and also to avoid the time and economic costs brought about by a large amount of reconstruction work, a two-layer conversion mechanism is constructed using the above-mentioned three-layer architecture and modular design of the application layer-conversion layer-adaptation layer. The two-layer conversion mechanism includes a one-layer conversion performed in the conversion layer, that is, converting the input and output requirements of the at least one AI application into various standardized data formats to obtain the input and output requirements of the conversion layer. Thus, regardless of how the upper-layer application ecosystem updates or how the supply chain business logic changes, by converting the input and output requirements of all AI applications into multiple standardized data formats, and ensuring that these standardized data formats cover all input and output types associated with the input and output requirements of at least one AI application, bidirectional decoupling is achieved between the supply chain business logic of the application layer and the specific interfaces of the large model in the adaptation layer. Various AI applications in the application layer used for supply chain management only interact with these standardized data formats, and all input and output requirements of the application layer are converted into these standardized data formats. In some embodiments, the model's return results are reverse-parsed into the application layer's business data format and transmitted to the application layer. When a new AI application is deployed to the application layer, or when existing AI applications in the application layer are updated, only the impact on the standardized data formats needs to be considered, such as adding new standardized data formats or modifying existing ones. The two-layer conversion mechanism also includes another layer of conversion in the adaptation layer, where the at least one adaptation module is used for bidirectional conversion between its respective calling interface and the multiple standardized data formats. The adaptation layer independently develops an adaptation module for each large model, encapsulating specific parameters such as the model's calling interface, data packet size limits, handshake protocol, and data retransmission mechanism. Furthermore, the adaptation layer includes a business allocation engine, used to allocate the input and output requirements of the transformation layer among the at least one AI model based on business allocation strategies, thus implementing a multi-dimensional routing strategy.Thus, even if different large model vendors adopt different underlying operating principles, different infrastructures, or different key algorithms for their respective large model development, generally, the calling interfaces, data formats, and handshake protocols of different large models are different. By developing corresponding adaptation modules independently for each large model in the adaptation layer, responsible for the bidirectional conversion between the standardized data format and the specific calling interface of the corresponding large model, when switching models, only the corresponding adaptation module needs to be activated, avoiding the workload of reconstructing the entire application ecosystem. Furthermore, when a new large model needs to be added, only the corresponding adaptation module needs to be added, without modifying the code of the upper application layer. In this way, changes to the code of the upper application layer only affect the standardized data format, while changes to the calling details of the underlying large model only affect the module parameters of the adaptation module. The standardized data format system covers all input and output types of supply chain AI applications as a unified output constraint of the conversion layer on the adaptation layer. The standardized data format system is the core of the entire decoupled architecture. New large models only need to deploy the corresponding new adaptation modules without modifying the application layer code. Conversely, new AI applications only need to be developed in accordance with the specifications of the standardized data format system without needing to understand the calling details of the underlying large model.

[0037] Continue reading Figure 1By utilizing the aforementioned three-layer architecture (application layer – transformation layer – adaptation layer) and modular design, along with two separate transformation mechanisms in the transformation and adaptation layers, decoupling and isolation between the standardized data format and the underlying large model are achieved. This ensures that the development of the upper-layer application ecosystem and the adaptation development of the underlying large model are independent of each other. Changes to the code in the upper-layer application layer only affect the standardized data format, while changes to the calling details of the underlying large model only affect the module parameters of the adaptation module. This decoupling and isolation design reduces the overall development complexity and lays the foundation for the overall migration of the application ecosystem and flexible business allocation strategies. Specifically, activating the corresponding adaptation module enables the corresponding artificial intelligence model. Combined with the business allocation engine of the adaptation layer, the input and output requirements of the transformation layer are allocated in the artificial intelligence model based on the business allocation strategy. Flexible business allocation strategies can be implemented. For example, the business allocation engine can maximize the utilization of free quota by routing according to multiple dimensions such as free quota / performance / cost. Furthermore, a dual-model parallel verification mechanism can be used to complete the effect convergence verification before model switching, thus ensuring predictability. The three-layer architecture—Application Layer, Transformation Layer, and Adaptation Layer—features optimized division of labor and collaboration. The core responsibility of the Application Layer is the supply chain AI business logic. Key technical specifications include outputting data and information in standardized data formats through multiple AI applications, without being aware of the underlying large model's call details. The core responsibilities of the Transformation Layer are format standardization and task packaging. By defining multiple standardized data formats, it establishes a standardized data format system and reverse-engineers the returned model output results to ensure they conform to the application layer's business data specifications. Additionally, the Transformation Layer provides a task packaging engine that decomposes requirements, orchestrates them, and prioritizes them, further improving overall system execution efficiency. The core responsibilities of the Adaptation Layer are interface adaptation and routing for large models. By providing independent adaptation modules for each large model, the interfaces, protocols, packet sizes, retransmission mechanisms, etc., of each large model are encapsulated within these modules. Adjusting the module parameters of the adaptation modules allows for convenient adaptation to changes in large models. Furthermore, the business allocation engine in the adaptation layer enables flexible business allocation strategies (free quota / task type / cost / fault tolerance), and can perform multi-dimensional routing based on free quota, task type matching, call cost, and model availability. The underlying large model provides training and inference services, mainly relying on various large AI models provided by large model vendors, and can also further enhance data privacy and security through local and private deployment.

[0038] In short, Figure 1The model management system for supply chain control, as shown, utilizes a three-layer architecture (application layer – transformation layer – adaptation layer) and modular design, along with a two-layer transformation mechanism (conducted separately in the transformation and adaptation layers). This achieves decoupling and isolation between the AI ​​applications at the application layer and the underlying AI models. This ensures that the development of AI applications and the adaptation development of the underlying AI models are independent of each other. Changes to the application layer code only affect the standardized data format, while changes to the calling details of the underlying AI models only affect the module parameters of the adaptation modules. Thus, based on the decoupling and isolation between the AI ​​applications at the application layer and the underlying AI models, combined with the business allocation engine in the adaptation layer, this system, targeting the intersection of AI and supply chain management, not only supports free switching between large models without modifying the upper-layer applications, effectively mitigating system operation risks caused by changes in pricing strategies or service interruptions from large model vendors, and helping to fully utilize free or low-cost quotas to reduce the cost of calling large models, but also simplifies the adaptation complexity of model switching and application ecosystem migration, thus helping to ensure effectiveness and control system operation risks.

[0039] Figure 2 This diagram illustrates a conversion layer with multiple standardized data formats and an adaptation layer with multiple adaptation modules, as provided in an embodiment of this application. Figure 2 As shown, the conversion layer B210 is used to convert the input / output requirements of the at least one artificial intelligence application into various standardized data formats to obtain the input / output requirements of the conversion layer B210. These various standardized data formats include visual data formats, text data formats, structured data formats, and mixed task package data formats. Figure 2The document also exemplifies the specific content of various standardized data formats. Visual data formats include: resolution: maximum 4K; color space: RGB or YUV; frame rate: 1 to 120 FPS; compression: H.264 / HEVC. Text data formats include: encoding: UTF-8; maximum length: 128K words; language identifier: Chinese, English, etc.; context window: configurable. Structured data formats include: format: JSON or Parquet; field type annotations; numerical precision: FP32 or FP16; batch size: configurable. Hybrid task package data formats include: task identifier with priority; subtask list; dependency graph; callback interface definition. The B220 adaptation layer includes multiple adaptation modules corresponding to various AI models. The module parameters of these modules provide the external output capabilities of the large model by defining specific calling methods and dedicated calling interfaces. For illustrative purposes only, the module parameters of adapter module A corresponding to AI model A include: interface: v1 chat data packet less than or equal to 16KB; handshake: HTTP 2 retransmission up to 3 times; focus: video generation and multimodal. The module parameters of adapter module B corresponding to AI model B include: interface: DashScope API; context: 1M vocabulary; focus: long-text semantics and code. The module parameters of adapter module C corresponding to AI model C include: interface: OpenAI REST; data format: JSON; focus: general inference and creation. The module parameters of adapter module D corresponding to AI model D include: interface: localized or private deployment; open-source model; focus: low cost and data security. It should be understood that... Figure 2 The various standardized data formats and details of the adaptation modules shown are merely illustrative. The adaptation layer, such as... Figure 2 The B220 adaptation layer in the architecture independently develops adaptation modules for each large model, encapsulating specific parameters such as the model's calling interface, data packet size limits, handshake protocol, and data retransmission mechanism. Generally, different large models have different calling interfaces, data formats, and handshake protocols. By independently developing corresponding adaptation modules for each large model in the adaptation layer, the bidirectional conversion between the standardized data format and the specific calling interface of the corresponding large model is handled. When switching models, only the corresponding adaptation module needs to be activated, avoiding the workload of refactoring the entire application ecosystem. A standardized data format system covers all input and output types of supply chain AI applications, serving as a unified output constraint from the conversion layer to the adaptation layer. As the core of the entire decoupled architecture, the standardized data format system allows newly added large models to deploy only the corresponding new adaptation modules without modifying the application layer code. Conversely, newly added AI applications only need to conform to the standardized data format system specifications during development without needing to understand the underlying large model's calling details.

[0040] Figure 3 This diagram illustrates a gradual switching mechanism based on a dual-model parallel verification routing strategy, as provided in an embodiment of this application. Figure 3 As shown, in Phase 1: Normal operation, the current model is responsible for handling all tasks. In Phase 2: Parallel verification of dual models. On one hand, the current model is responsible for handling all tasks, and the model output results of the current model for representative tasks serve as a reference benchmark; on the other hand, representative tasks are simultaneously submitted to the model to be switched, and the model output results of the model to be switched for representative tasks are used for result comparison. In Phase 3: Model switching is completed. That is, the model switching is completed, and the model to be switched is responsible for handling all tasks. Thus, the result comparison engine compares the model output results to obtain model difference indicators, adjusts the module parameters of the adaptation module, and achieves convergence. In some embodiments, the result comparison engine can be deployed in the adaptation layer to compare the model output results of the current model for representative tasks (serving as a reference benchmark) and the model output results of the model to be switched for representative tasks (serving as the comparison object). In other embodiments, the result comparison engine can be independent of the model management system used for supply chain control, serving as an external device to assist in model switching. Thus, using a three-layer architecture of application layer – transformation layer – adaptation layer, with standardized data format as the core constraint, bidirectional decoupling and isolation are achieved. A progressive switching mechanism based on a dual-model parallel verification routing strategy is implemented in three phases. In Phase 2, representative tasks (e.g., 5% to 10% of all tasks) are selected and submitted to both the current model and the model to be switched. A result comparison engine then calculates the difference indicators between the two models' outputs. Combined with business indicators specific to the supply chain management application scenario, once all difference indicators reach a threshold, the switch confidence score is met, triggering the formal switch. After the model switch is complete, the business allocation engine routes all tasks to the model to be switched (the new model), while the original model's adaptation module is retained for later use. In this way, the model switch process does not interrupt the original tasks, nor does it require a complete reconstruction of the entire application ecosystem. Furthermore, the difference indicator and threshold mechanism ensures that result convergence verification is completed before the switch, guaranteeing business quality and predictability.

[0041] Figure 4 This is a flowchart illustrating a large-scale model dynamic switching and task routing method provided in an embodiment of this application. Figure 4 As shown, the dynamic switching of large models and task routing includes the following steps.

[0042] Step S401: The application layer initiates a business request.

[0043] Step S403: The conversion layer is broken down into standardized data formats and packaged into task packages.

[0044] Step S405: Determine the task type. Here, taking visual and language task types as examples, if it matches the visual task type, proceed to step S407: Visual data format; if it matches the language task type, proceed to step S409: Text data format. In this way, by utilizing a standardized data format system, business requests initiated from the application layer are broken down into multiple standardized data formats. Tasks with the same standardized data format are packaged together, and then the task execution order and priority labeling are arranged, which helps improve overall efficiency.

[0045] Step S410: The business allocation engine of the adaptation layer allocates requirements based on the business allocation strategy. Thus, the business allocation engine assigns requirements to the target model.

[0046] Step S412: Determine if the target model is available. If the target model is available, proceed to step S414: Call the target model. If the target model is unavailable, proceed to step S416: Switch to the backup model and load the corresponding adaptation module.

[0047] Step S420: The adaptation layer receives the results returned by the model and converts them into a standardized data format.

[0048] Step S422: The transformation layer performs reverse parsing, converting the model's returned results into the application layer's business data format.

[0049] Step S424: The application layer obtains the model's returned results and continues to execute the business process.

[0050] See Figure 4It achieves end-to-end data flow. Supply chain AI applications (demand forecasting / path optimization, etc.) construct business requests; the transformation layer task package packaging engine breaks down the requests and converts them into corresponding standardized data format task packages; the business allocation engine evaluates the current status of various models (availability / free quota / cost) and selects the target model; the target adaptation module converts the standardized data format into the specific calling format of the model (including interface / package size / handshake protocol); the target large model is called and an inference request is sent; the inference result is received, and the adaptation module converts the result back to the standardized data format; the transformation layer reverse parsing engine restores the standardized data format result to the application layer business data format; the application layer obtains the result, and the business process continues to execute (without being aware of the underlying model changes throughout the entire process). By leveraging the aforementioned three-layer architecture (application layer – transformation layer – adaptation layer) and modular design, along with two separate transformation mechanisms in the transformation and adaptation layers, decoupling and isolation between the standardized data format and the underlying large model are achieved. This ensures that the development of the upper-layer application ecosystem and the adaptation development of the underlying large model are independent of each other. Changes to the upper-layer application layer code only affect the standardized data format, while changes to the calling details of the underlying large model only affect the module parameters of the adaptation module. This decoupling and isolation design reduces overall development complexity and lays the foundation for the overall migration of the application ecosystem and flexible business allocation strategies. Activating the corresponding adaptation module enables the corresponding artificial intelligence model. Combined with the business allocation engine of the adaptation layer, the input and output requirements of the transformation layer are allocated to the artificial intelligence model based on the business allocation strategy, enabling flexible business allocation strategies. The dual-model parallel verification mechanism completes effect convergence verification before model switching, thus ensuring predictability.

[0051] See Figure 1 , Figure 2 , Figure 3 and Figure 4In one possible implementation, the business allocation strategy includes a free quota priority routing strategy. This strategy instructs the business allocation engine to prioritize tasks that meet the free mode quota in the input / output requirements of the transformation layer to the AI ​​models with the free mode quota among the at least one AI models. Large model vendors may adopt different charging strategies, and these strategies may change. Generally, there are limits on the free quota, and a hybrid model of basic free plus advanced paid is adopted. Utilizing the aforementioned three-layer architecture and modular design of the application layer-transformation layer-adaptation layer, along with a total of two-layer transformation mechanisms performed in the transformation and adaptation layers, decoupling and isolation between standardized data formats and the underlying large models are achieved. Furthermore, this decoupling and isolation design lays the foundation for the overall migration of the application ecosystem and flexible business allocation strategies. Here, the business allocation strategy includes a free quota priority routing strategy, where the business allocation engine routes based on free quota / performance / cost in multiple dimensions to maximize the utilization of the free quota.

[0052] See Figure 1 , Figure 2 , Figure 3 and Figure 4In one possible implementation, the business allocation strategy includes a task type matching routing strategy, which instructs the business allocation engine to preferentially allocate tasks of a given type from the input / output requirements of the transformation layer to the AI ​​model among the at least one AI model that has the processing capability for the given type of task. In some embodiments, the given type of task includes at least one of the following: visual generation tasks, multimodal tasks, long-text semantic parsing tasks, and context parsing tasks. Thus, the strengths of each AI model can be utilized; for example, visual generation / multimodal tasks can be preferentially routed to one AI model, while long-text semantic / context parsing tasks can be preferentially routed to another AI model. For example, suppose a supply chain management system is simultaneously running three types of tasks: demand forecasting (text + structured data), shelf recognition (visual data), and contract parsing (long text). The demand forecasting task is characterized by structured historical order data, large volume but low cost per transaction, therefore it can be routed through the business allocation engine to a large model with corresponding characteristics, such as being adept at handling millions of word context terms and having high batch processing efficiency. The shelf recognition task is characterized by multimodal image analysis, therefore it can be routed through the business allocation engine to a large model with corresponding characteristics, such as having visual advantages and daily free quotas. The contract parsing task is characterized by a length greater than 50K terms, i.e., extremely long text semantics. Therefore, it can be routed to a large model with corresponding characteristics through the business allocation engine, such as being adept at handling 1M term context. It can be seen that the scheduling process can be completely transparent to the application layer, and all three types of tasks are routed to the optimal large model without the application layer being aware of the task, thus reducing the overall cost.

[0053] See Figure 1 , Figure 2 , Figure 3 and Figure 4 In one possible implementation, the service allocation strategy includes a cost-optimal routing strategy, which instructs the service allocation engine to prioritize allocating the input / output requirements of the transformation layer to the AI ​​model with the lowest call cost among the at least one AI models. Thus, by comparing the call costs of various models in real time, the lowest-cost solution is selected while ensuring effectiveness.

[0054] See Figure 1 , Figure 2 , Figure 3 and Figure 4In one possible implementation, the service allocation strategy includes a fault-tolerant degradation routing strategy. This strategy instructs the service allocation engine to allocate the input / output requirements of the transformation layer to a backup model associated with the target model in the at least one AI model when the target model is unavailable. Thus, when the target model is unavailable, the system automatically switches to the backup model and loads the corresponding adaptation module, improving system fault tolerance.

[0055] See Figure 1 , Figure 2 , Figure 3 and Figure 4In one possible implementation, the business allocation strategy includes a dual-model parallel verification routing strategy. This strategy instructs the business allocation engine to simultaneously submit representative tasks from the input / output requirements of the transformation layer to both the current model and the model to be switched in the at least one AI model. Furthermore, the model output results of the current model for the representative task and the model output results of the model to be switched for the representative task are used to achieve model switching from the current model to the model to be switched. As mentioned above, due to changes in pricing strategies, security privacy policies, etc., the entire developed application ecosystem needs to be migrated from one large model to another. This not only faces high switching costs but also risks that the application ecosystem developed on the original large model may not achieve the same performance on the new large model, posing a business quality risk. If the upper-layer application ecosystem developed for the original large model is reconstructed every time a new large model is migrated, or if a separate application ecosystem is developed for multiple large models, it will inevitably lead to a huge workload and cost of reconstruction. However, the underlying operating principles, infrastructure, and key algorithms relied upon by various large model vendors when developing their respective large models often differ significantly, and much of this content is not publicly disclosed. Generally, the external capabilities of large models are provided through specific calling methods and dedicated calling interfaces, further increasing the complexity and economic cost of adapting to various large models. To address this, the aforementioned three-layer architecture (application layer – transformation layer – adaptation layer) and modular design, along with two separate transformation mechanisms at the transformation and adaptation layers, decouple and isolate the standardized data format from the underlying large model. This decoupling and isolation design lays the foundation for the overall migration of the application ecosystem and flexible business allocation strategies. Here, a dual-model parallel verification and gradual switching mechanism is used. A portion of all tasks is selected as representative tasks, such as 5% to 10% of representative task samples in supply chain business, and submitted to both the current model and the model to be switched as the subsequent target model. The result comparison engine automatically compares the output differences between the two models and adjusts the adaptation module parameters and standardized data format based on the difference indicators. When the difference indicators converge to within a preset threshold (switching confidence level meets the standard), the formal switch is triggered. In this way, business continuity can be guaranteed without modifying the application layer code after the official switch is completed.

[0056] In some embodiments, the adaptation layer further includes a result comparison engine. The dual-model parallel verification routing strategy instructs the result comparison engine to compare the model output of the current model for the representative task with the model output of the model to be switched for the representative task to obtain a model difference index. Then, based on the model difference index, the module parameters of the at least one adaptation module corresponding to the model to be switched are continuously adjusted until the model difference index converges to a preset threshold. This improves the transparency and predictability of large model switching. The convergence rate of parallel verification results can be determined by the proportion of the difference index meeting the target. Furthermore, the transparency and cost of large model switching can be calculated by comparing the amount of application layer code modifications before and after the switch with the total amount of code. Because the convergence of the difference index between the two models is achieved through representative task samples before the switch is completed, the cost and time of adapting to the new large model are reduced, helping to ensure business continuity during model switching. This is beneficial for business stability and switching risk control in supply chain management application scenarios. For example, it may be necessary to migrate the entire application ecosystem from a large model that is about to be charged to another free and open-source large model. By initiating model switching in the management console and selecting the source model (current model) and the target model (model to be switched), the system automatically extracts 5% of the multimodal feature extraction tasks from the historical task library as validation samples. Then, in the parallel validation phase, the same batch of shelf images are submitted to both models simultaneously, and the result comparison engine calculates the cosine similarity of the feature vectors. After 200 samples, the adaptation module parameters are adjusted (e.g., adjusting the image size normalization method and feature dimension alignment), increasing the similarity from 0.71 to 0.93 (exceeding the threshold of 0.90). Finally, the confidence score is deemed satisfactory, and the system automatically routes all multimodal feature extraction tasks to the new model, thus achieving zero modification to the application layer code. For example, if it is necessary to evaluate whether a new open-source large model can replace the current model, representative samples from the supply chain demand forecasting tasks of the past three months can be extracted, such as 100 stock keeping units (SKUs), to cover typical scenarios such as seasonality, promotions, and new products. By running two models in parallel, the current benchmark model and the model to be validated each complete 100 prediction tasks. Then, through result comparison, the MAPE difference, initially at 8.3% (not meeting the standard), is reduced to 3.1% (meeting the 5% threshold) by adjusting the field mapping of the standardized data format and the time series encoding method. Finally, it meets the confidence score requirement of 0.94 (≥0.90), thus approving the formal switch. This allows for local private deployment of the new open-source model after the switch, reducing model usage costs while ensuring data remains within the country, meeting data compliance requirements.

[0057] In some embodiments, the dual-model parallel verification routing strategy is optimized for intelligent supply chain management scenarios. The model difference indicators include supply chain business indicators, ROUGE-L similarity, and field-level accuracy. The supply chain business indicators include supply chain forecasting task accuracy, path optimality, and inventory turnover rate. Thus, by expanding the standardized data format of supply chain data and establishing a supply chain task priority system, supply chain-specific evaluation indicators can be improved, enabling dedicated optimization in the cross-situation of supply chain and artificial intelligence.

[0058] In some embodiments, the dual-model parallel verification routing strategy further indicates that when the model difference metric exceeds the preset threshold, the model to be switched is determined to be unavailable and the current model is automatically switched to a backup model. Thus, the timing of model switching can be controlled by the preset threshold, improving the transparency of model switching and ensuring business stability.

[0059] See Figure 1 , Figure 2 , Figure 3 and Figure 4 In one possible implementation, the module parameters of each of the at least one adapter module include: a call interface encapsulation format, a data packet size limit, a handshake protocol, and a data retransmission mechanism. Furthermore, the at least one adapter module is maintained separately and independently of each other. Thus, each large model corresponds to an independent adapter module, encapsulating all the calling details of that model.

[0060] See Figure 1 , Figure 2 , Figure 3 and Figure 4In one possible implementation, the various standardized data formats include visual data formats, text data formats, structured data formats, and hybrid task package data formats. In some embodiments, the visual data format is used to standardize image and video inputs, and its parameters include resolution, color space, frame rate, and compression format; the text data format is used to standardize text inputs, and its parameters include encoding method, maximum token length, language identifier, and context window definition; the structured data format is used to standardize supply chain structured data, and its parameters include structured data type, field type annotations, and numerical precision; the hybrid task package data format is used to package multiple subtasks into a single task package, and its parameters include task identifier, priority, dependency graph, and callback interface definition. Thus, a standardized data format system is constructed through various standardized data formats, serving as a data constraint between the conversion layer and the adaptation layer, and different format types can correspond to different applicable scenarios. The process involves using a task package packaging engine to break down and organize composite application layer requirements into standardized data format task packages. The specific steps include: requirement parsing: receiving application layer requests and identifying task types (visual / text / structured / hybrid); subtask decomposition: breaking down composite requirements into several single-type subtasks; dependency modeling: constructing a directed acyclic graph (DAG) of subtasks to determine the execution order; priority labeling: labeling each subtask with a priority based on supply chain business rules; and packaged output: assembling the subtasks into a hybrid task package and passing it to the business allocation engine in the adaptation layer.

[0061] In some embodiments, the various standardized data formats are optimized for intelligent supply chain management scenarios. The structured data format includes specific field specifications for order data, inventory snapshots, transportation trajectories, and inventory holding unit attributes. The hybrid task package data format supports a built-in supply chain task priority chain. Furthermore, the visual data format is used for shelf image recognition, warehouse video analysis, and multimodal feature extraction of goods; the text data format is used for contract semantic parsing, procurement requirement text understanding, and supplier evaluation report generation; the structured data format is used for order data processing, inventory snapshot analysis, transportation trajectory prediction, and inventory holding unit attribute parsing; and the hybrid task package data format supports end-to-end supply chain analysis tasks. Thus, a standardized data format system is constructed through various standardized data formats, serving as a data constraint between the conversion layer and the adaptation layer. Different format types can correspond to different applicable scenarios. For example, the built-in supply chain task priority can indicate that emergency replenishment is greater than demand forecasting, which is greater than route optimization, which is greater than report generation.

[0062] In some embodiments, the transformation layer further includes a task package packaging engine. This engine is used to decompose the composite requirements of the application layer into multiple single-type subtasks based on the various standardized data formats, and to arrange the execution order and priority labeling of these single-type subtasks, thereby supporting end-to-end supply chain analysis tasks. Furthermore, the transformation layer is also used for reverse parsing to convert the model's returned results into the business data format of the application layer. This achieves end-to-end data flow and supports end-to-end supply chain analysis task packages, such as composite tasks integrating visual, text, and structured data.

[0063] See Figure 1 , Figure 2 , Figure 3 and Figure 4 In one possible implementation, the at least one artificial intelligence application includes multimodal feature extraction and parsing, nonlinear data processing, supply chain demand forecasting, logistics route optimization, and intelligent inventory control. This supports a rich ecosystem of upper-level applications.

[0064] Figure 5 This is a flowchart illustrating a model management method for supply chain control, provided as an embodiment of this application. Figure 5 As shown, the model management method includes the following steps.

[0065] Step S501: Deploy at least one artificial intelligence application for supply chain management through the application layer.

[0066] Step S503: Through the conversion layer, the input and output requirements of the at least one artificial intelligence application are converted into multiple standardized data formats to obtain the input and output requirements of the conversion layer, and the model returns the results to the application layer, wherein the multiple standardized data formats cover all input and output types associated with the input and output requirements of the at least one artificial intelligence application.

[0067] Step S505: Through the adaptation layer, deploy at least one adaptation module corresponding to at least one artificial intelligence model, wherein each of the at least one adaptation module includes a calling interface of the corresponding artificial intelligence model in the at least one artificial intelligence model, and the at least one adaptation module is used for bidirectional conversion between the calling interface of the at least one adaptation module and the multiple standardized data formats.

[0068] The adaptation layer includes a business allocation engine, which is used to allocate the input and output requirements of the conversion layer in the at least one artificial intelligence model based on a business allocation strategy, and to obtain the model return results from the allocated artificial intelligence model and transmit the model return results to the conversion layer.

[0069] Figure 5 The model management method for supply chain control, as shown, utilizes a three-layer architecture (application layer – transformation layer – adaptation layer) and modular design, along with a two-layer transformation mechanism (conducted separately in the transformation and adaptation layers). This achieves decoupling and isolation between the AI ​​applications at the application layer and the underlying AI models. This ensures that the development of AI applications and the adaptation development of the underlying AI models are independent of each other. Changes to the application layer code only affect the standardized data format, while changes to the calling details of the underlying AI models only affect the module parameters of the adaptation modules. Thus, based on the decoupling and isolation between the AI ​​applications at the application layer and the underlying AI models, combined with the business allocation engine in the adaptation layer, this approach, targeting the intersection of AI and supply chain management, not only supports free switching between large models without modifying the upper-layer applications—effectively mitigating system operation risks caused by changes in pricing strategies or service interruptions from large model vendors—but also helps to fully utilize free or low-cost quotas to reduce the cost of calling large models. Furthermore, it simplifies the adaptation complexity of model switching and application ecosystem migration, thus helping to ensure effectiveness and control system operation risks.

[0070] See Figure 5 In one possible implementation, the service allocation strategy includes a free quota priority routing strategy, a task type matching routing strategy, a cost-optimal routing strategy, a fault-tolerant degradation routing strategy, and a dual-model parallel verification routing strategy. This supports flexible service allocation strategies.

[0071] See Figure 5 In one possible implementation, the module parameters of each of the at least one adaptation module include: a call interface encapsulation format, a data packet size limit, a handshake protocol, and a data retransmission mechanism. Furthermore, the at least one adaptation module is maintained separately and independently of each other. This supports adaptation to various artificial intelligence models.

[0072] See Figure 5 In one possible implementation, the various standardized data formats include visual data formats, text data formats, structured data formats, and hybrid task package data formats. Thus, a standardized data format system is constructed, serving as a data constraint between the conversion layer and the adaptation layer, allowing different format types to correspond to different applicable scenarios.

[0073] Figure 6This is a schematic diagram of a computer device 600 provided in an embodiment of this application. The computer device 600 includes one or more processors 610, a communication interface 620, and a memory 630. The processors 610, the communication interface 620, and the memory 630 are interconnected via a bus 640. Optionally, the computer device 600 may further include an input / output interface 650, which is connected to input / output devices for receiving user-set parameters, etc. The computer device 600 can be used to implement some or all of the functions of the device embodiment or system embodiment in the above-described embodiments of this application; the processor 610 can also be used to implement some or all of the operation steps of the method embodiment in the above-described embodiments of this application. For example, the specific implementation of various operations performed by the computer device 600 can be referred to the specific details in the above embodiments, such as the processor 610 being used to execute some or all of the steps or operations in the above-described method embodiments. For example, in the embodiments of this application, the computer device 600 can be used to implement some or all of the functions of one or more components in the above-described device embodiments. In addition, the communication interface 620 can be used specifically for communication functions necessary to implement the functions of these devices and components, and the processor 610 can be used specifically for processing functions necessary to implement the functions of these devices and components.

[0074] It should be understood that, Figure 6 The computer device 600 may include one or more processors 610, and the multiple processors 610 may cooperate to provide processing power in a parallel connection mode, a serial connection mode, a serial-parallel connection mode, or an arbitrary connection mode; or the multiple processors 610 may form a processor sequence or a processor array; or the multiple processors 610 may be divided into a main processor and an auxiliary processor; or the multiple processors 610 may have different architectures, such as adopting a heterogeneous computing architecture. Furthermore, Figure 6 The structural and functional descriptions of the computer device 600 shown are exemplary and non-limiting. In some exemplary embodiments, the computer device 600 may include... Figure 6 The diagram shows more or fewer components, or combinations of some components, or splitting of some components, or different arrangements of components.

[0075] The processor 610 can have various specific implementations. For example, the processor 610 may include one or more combinations of a central processing unit (CPU), a graphics processing unit (GPU), a neural network processing unit (NPU), a tensor processing unit (TPU), or a data processing unit (DPU), etc. This application embodiment does not impose specific limitations. The processor 610 can also be a single-core processor or a multi-core processor. The processor 610 can be a combination of a CPU and hardware chips. The aforementioned hardware chips can be application-specific integrated circuits (ASICs), programmable logic devices (PLDs), or combinations thereof. The aforementioned PLDs can be complex programmable logic devices (CPLDs), field-programmable gate arrays (FPGAs), generic array logic (GALs), or any combination thereof. The processor 610 can also be implemented solely using logic devices with built-in processing logic, such as FPGAs or digital signal processors (DSPs). The communication interface 620 can be a wired interface or a wireless interface, used to communicate with other modules or devices. The wired interface can be an Ethernet interface, a local interconnect network (LIN), etc., and the wireless interface can be a cellular network interface or a wireless LAN interface, etc.

[0076] Memory 630 may be non-volatile memory, such as read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. Memory 630 may also be volatile memory, which may be random access memory (RAM) used as an external cache. By way of example, but not limitation, many forms of RAM are available, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate synchronous DRAM (DDR SDRAM), enhanced synchronous DRAM (ESDRAM), synchronous linked DRAM (SLDRAM), and direct rambus RAM (DR RAM). The memory 630 can also be used to store program code and data, so that the processor 610 can call the program code stored in the memory 630 to execute some or all of the operation steps in the above method embodiments, or to execute the corresponding functions in the above device embodiments. Furthermore, the computer device 600 may include, compared to... Figure 6 The number of components displayed may be more or less, or there may be different component configurations.

[0077] Bus 640 can be a Peripheral Component Interconnect Express (PCIe) bus, or an Extended Industry Standard Architecture (EISA) bus, a Unified Bus (Ubus or UB), a Compute Express Link (CXL) bus, a Cache Coherent Interconnect for Accelerators (CCIX) bus, etc. Bus 640 can be divided into address bus, data bus, control bus, etc. In addition to the data bus, bus 640 can also include a power bus, control bus, and status signal bus. However, for clarity, Figure 6 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0078] The methods and devices provided in this application are based on the same inventive concept. Since the principles by which the methods and devices solve problems are similar, the embodiments, implementation methods, examples, or methods of implementation of the methods and devices can be referred to each other, and repeated details will not be repeated. This application also provides a system comprising multiple computer devices, the structure of each computer device of which can refer to the structure of the computer devices described above. The functions or operations achievable by this system can refer to the specific implementation steps in the above method embodiments and / or the specific functions described in the above device embodiments, and will not be repeated here.

[0079] This application also provides a computer-readable storage medium storing computer instructions. When these computer instructions are executed on a computer device (such as one or more processors), they can implement the method steps described in the above method embodiments. The specific implementation of the above method steps by the processor of the computer-readable storage medium can refer to the specific operations described in the above method embodiments and / or the specific functions described in the above device embodiments, and will not be repeated here.

[0080] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. This application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Embodiments of this application can be implemented wholly or partially by software, hardware, firmware, or any other combination. When implemented in software, the above embodiments can be implemented wholly or partially as a computer program product. This application can take the form of a computer program product embodied on one or more computer-usable storage media containing computer-usable program code. The computer program product includes one or more computer instructions. When the computer program instructions are loaded or executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line) or wireless (e.g., infrared, wireless network communication, microwave, etc.) means. Computer-readable storage media can be any available medium that a computer can access, or a data storage device such as a server or data center that contains one or more sets of available media. Available media can be magnetic media (such as floppy disks, hard disks, and magnetic tapes), optical media, or semiconductor media. Semiconductor media can be solid-state drives, random access memory, flash memory, read-only memory, erasable programmable read-only memory, electrically erasable programmable read-only memory, registers, or any other suitable form of storage medium.

[0081] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. Each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to operate in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The functions specified in one or more boxes. These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable apparatus for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0082] In the above embodiments, the descriptions of each embodiment have their own emphasis. Parts not described in detail in a certain embodiment can be referred to in the relevant descriptions of other embodiments. Obviously, those skilled in the art can make various modifications and variations to the embodiments of this application without departing from the spirit and scope of the embodiments of this application. The steps in the methods of the embodiments of this application can be adjusted in order, combined, or deleted according to actual needs; the modules in the systems of the embodiments of this application can be divided, combined, or deleted according to actual needs. If these modifications and variations of the embodiments of this application fall within the scope of the claims of this application and their equivalents, then this application also intends to include these modifications and variations.

Claims

1. A model management system for supply chain control, characterized in that, The model management system includes: The application layer is used to deploy at least one artificial intelligence application for supply chain management; A conversion layer is used to convert the input and output requirements of the at least one artificial intelligence application into a variety of standardized data formats to obtain the input and output requirements of the conversion layer, and to transmit the model return results to the application layer, wherein the variety of standardized data formats cover all input and output types associated with the input and output requirements of the at least one artificial intelligence application. An adaptation layer, wherein the adaptation layer includes at least one adaptation module corresponding one-to-one with at least one artificial intelligence model, each of the at least one adaptation module includes a calling interface of the corresponding artificial intelligence model in the at least one artificial intelligence model, and the at least one adaptation module is respectively used for bidirectional conversion between the calling interface of the at least one adaptation module and the multiple standardized data formats. The adaptation layer includes a business allocation engine, which is used to allocate the input and output requirements of the conversion layer in the at least one artificial intelligence model based on a business allocation strategy, and to obtain the model return results from the allocated artificial intelligence model and transmit the model return results to the conversion layer.

2. The model management system according to claim 1, characterized in that, The service allocation strategy includes a free quota priority routing strategy, which instructs the service allocation engine to prioritize the allocation of tasks that meet the free mode quota in the input / output requirements of the conversion layer to the AI ​​model with the free mode quota in the at least one AI model.

3. The model management system according to claim 1, characterized in that, The business allocation strategy includes a task type matching routing strategy, which instructs the business allocation engine to preferentially allocate tasks of a given type from the input / output requirements of the conversion layer to the AI ​​model in the at least one AI model that has the processing capability for the given type of task.

4. The model management system according to claim 1, characterized in that, The service allocation strategy includes a cost-optimal routing strategy, which instructs the service allocation engine to preferentially allocate the input / output requirements of the transformation layer to the AI ​​model with the lowest call cost among the at least one AI models.

5. The model management system according to claim 1, characterized in that, The service allocation strategy includes a fault-tolerant and degradation routing strategy, which instructs the service allocation engine to allocate the input / output requirements of the conversion layer to a backup model associated with the target model in the at least one artificial intelligence model when the target model in the at least one artificial intelligence model is unavailable.

6. The model management system according to claim 1, characterized in that, The business allocation strategy includes a dual-model parallel verification routing strategy. The dual-model parallel verification routing strategy is used to instruct the business allocation engine to simultaneously submit representative tasks from the input and output requirements of the transformation layer to the current model and the model to be switched in the at least one artificial intelligence model. Furthermore, the model output results of the current model for the representative task and the model output results of the model to be switched for the representative task are used to realize the model switching from the current model to the model to be switched.

7. The model management system according to claim 6, characterized in that, The adaptation layer also includes a result comparison engine. The dual-model parallel verification routing strategy is used to instruct the result comparison engine to compare the model output results of the current model for the representative task with the model output results of the model to be switched for the representative task to obtain a model difference index. Then, based on the model difference index, the module parameters of the adaptation module corresponding to the model to be switched in the at least one adaptation module are continuously adjusted until the model difference index converges to a preset threshold.

8. The model management system according to claim 7, characterized in that, The dual-model parallel verification routing strategy is optimized for intelligent supply chain management scenarios. The model difference indicators include supply chain business indicators, ROUGE-L similarity, and field-level accuracy. The supply chain business indicators include supply chain forecasting task accuracy, path optimality, and inventory turnover rate.

9. The model management system according to claim 8, characterized in that, The dual-model parallel verification routing strategy also indicates that when the model difference index exceeds the preset threshold, the model to be switched is determined to be unavailable and the current model is automatically switched to the backup model.

10. The model management system according to claim 1, characterized in that, The module parameters of each of the at least one adapter module include: call interface encapsulation format, data packet size limit, handshake protocol, and data retransmission mechanism, and the at least one adapter module is maintained separately and independently of each other.

11. The model management system according to claim 1, characterized in that, The various standardized data formats include visual data formats, text data formats, structured data formats, and mixed task package data formats.

12. The model management system according to claim 11, characterized in that, The visual data format is used to standardize image and video inputs, and its parameters include resolution, color space, frame rate, and compression format. The text data format is used to standardize text inputs, and its parameters include encoding method, maximum token length, language identifier, and context window definition. The structured data format is used to standardize supply chain structured data, and its parameters include structured data type, field type annotations, and numerical precision. The hybrid task package data format is used to package multiple subtasks into a single task package, and its parameters include task identifier, priority, dependency graph, and callback interface definition.

13. The model management system according to claim 11, characterized in that, The transformation layer also includes a task package packaging engine, which is used to decompose the composite requirements of the application layer into multiple single-type sub-tasks based on the various standardized data formats, and to arrange the execution order and priority labeling of the multiple single-type sub-tasks, thereby supporting supply chain end-to-end analysis tasks. Furthermore, the transformation layer is also used for reverse parsing to convert the model return results into the business data format of the application layer.

14. The model management system according to claim 1, characterized in that, The at least one artificial intelligence application includes multimodal feature extraction and analysis, nonlinear data processing, supply chain demand forecasting, logistics route optimization, and intelligent inventory control.

15. A model management method for supply chain control, characterized in that, The model management method includes: At the application layer, deploy at least one artificial intelligence application for supply chain management; Through a transformation layer, the input and output requirements of the at least one artificial intelligence application are transformed into multiple standardized data formats to obtain the input and output requirements of the transformation layer, and the model returns the results to the application layer, wherein the multiple standardized data formats cover all input and output types associated with the input and output requirements of the at least one artificial intelligence application. Through the adaptation layer, at least one adaptation module corresponding to at least one artificial intelligence model is deployed, wherein each of the at least one adaptation module includes a calling interface for the corresponding artificial intelligence model in the at least one artificial intelligence model, and the at least one adaptation module is used for bidirectional conversion between the calling interface of the at least one adaptation module and the multiple standardized data formats. The adaptation layer includes a business allocation engine, which is used to allocate the input and output requirements of the conversion layer in the at least one artificial intelligence model based on a business allocation strategy, and to obtain the model return results from the allocated artificial intelligence model and transmit the model return results to the conversion layer.

Images