Model hierarchical degradation configuration method and system

Abstract

This invention provides a hierarchical degradation configuration method and system for network model configuration, relating to the field of network model configuration technology. By introducing point-level hierarchical attribute name identifiers and base key names, hierarchical configuration management is achieved. This allows configurations to be defined according to the hierarchical relationships of business modules, sub-modules, agents, and sub-tasks, providing fine-grained configuration capabilities and allowing overriding or inheriting upper-level configurations at specific levels. By independently performing three-level priority resolution on the three configuration dimensions—model name, API access address, and API authentication key—smooth degradation and multi-dimensional decoupling of configurations are achieved. When a configuration at a specific level is missing, it can automatically backtrack to the parent level or the global default configuration, ensuring that model instances can always be successfully constructed and avoiding system failures caused by missing configurations. Each dimension is resolved independently and without interference, greatly reducing the coupling between configurations.

Description

Technical Field

[0001] This invention relates to the field of network model configuration technology, and more specifically, to a hierarchical degradation configuration method and system for models. Background Technology

[0002] In enterprise-level multi-module AI application platforms, different business modules (such as document generation, contract review, and data analysis) and different sub-tasks within the same module (such as text classification, text generation, and code execution) often have different requirements for LLM: some sub-tasks require flagship models with high inference capabilities, while others use lightweight models; some modules use privately deployed LLM services (with different API addresses), while other modules use public cloud services, etc., reflecting different application requirements.

[0003] Existing systems typically offer two extremes: either globally unified configuration (all modules use the same LLM) or each module has completely independent configuration (unable to share common configurations). When the business module hierarchy is adjusted, a large number of configuration key references in the code need to be modified.

[0004] Existing technologies suffer from problems such as a lack of fine-grained configuration and smooth transition to global defaults in multi-module LLM application configurations, as well as coupling of multi-dimensional configurations. Summary of the Invention

[0005] The problem that this invention aims to solve is the lack of fine-grained configuration and smooth transition of global defaults in the configuration of multi-module LLM applications in the prior art, as well as the coupling of multi-dimensional configurations.

[0006] To address the aforementioned problems, in a first aspect, the present invention provides a model-level degradation configuration method, comprising: Receive the point hierarchical attribute name identifiers of the model and construct the base key name for the configuration query; Based on the base key name, three-level priority parsing is performed independently for each of the three configuration dimensions: model name, API access address, and API authentication key, to determine the triplet configuration data of the model instance; Construct a model instance based on the triple configuration data.

[0007] Optionally, the model hierarchical degradation configuration method further includes: Using the directory containing the model's code file in the model instance as the base directory, the relative path of the Prompt file is concatenated to obtain the absolute path of the Prompt file, and its content is loaded. The relative position of the Prompt file and the model's code file remains fixed, and they are stored in the same folder. When the directory structure of the model's code file is adjusted, the reference relationship of the Prompt file is automatically migrated accordingly.

[0008] Optionally, the point-level hierarchical attribute name identifier includes a dot separator and multiple level names, wherein the dot separator separates the multiple level names, and the multiple level names include module name, submodule name, Agent name and subtask name; The base key name includes a prefix and a dotted hierarchical attribute name identifier.

[0009] Optionally, the attribute name of the model name is the base key name; The attribute name of the API access address is the base key name followed by a dot separator and the access address name in sequence; The attribute name of the API authentication key is the base key name followed by a dot separator and the key name in sequence.

[0010] Optionally, the three-level priority resolution includes: First priority: Read the specific configuration corresponding to the attribute name; Second priority: If the configuration of the first priority is not matched and the base key name in the attribute name includes at least one dot separator, extract the parent identifier in the base key name to replace the original base key name, form a new attribute name, and read the parent configuration corresponding to the new attribute name. The third priority is to directly read the global default configuration if the second priority configuration is not matched.

[0011] Optionally, the step of extracting the parent identifier from the base key name, replacing the original base key name to form a new attribute name, and reading the parent configuration corresponding to the new attribute name includes: Separate and delete the last dot separator and the content after the last dot separator in the base key name to obtain the parent identifier; Replace the base key name with the parent identifier and use it as the new base key name; Depending on the different parsing dimensions, new attribute names are constructed accordingly, and the parent configuration corresponding to the new attribute names is read. If no configuration is read, the new property name is used as the basis to extract the parent identifier from the new base key name and iteratively construct the next new property name, and the corresponding parent configuration is read, until the configuration is read or the new base key name in the new property name cannot be divided.

[0012] Optionally, if the base key name in the attribute name does not include a dot separator or the new base key name in the new attribute name cannot be separated, then skip the second priority and proceed directly to the third priority.

[0013] Optionally, for the dimension of model name, if the configuration is not matched after parsing all three priority levels, the built-in default model is used and a warning log is recorded sequentially.

[0014] Optionally, for the API access address dimension, if the configuration is not matched after parsing all three priority levels, a configuration missing exception message is generated to indicate the corresponding API access address in the configuration.

[0015] Secondly, the present invention also provides a model-level degradation configuration system, comprising: The key name building module is used to receive the point hierarchical attribute name identifiers of the model and build the base key names for configuration queries; The configuration parsing module is used to independently perform three-level priority parsing on the three configuration dimensions of model name, API access address and API authentication key based on the base key name, and determine the triplet configuration data of the model instance. The instance construction module is used to construct model instances based on triple configuration data.

[0016] This invention provides a hierarchical degradation configuration method and system. Compared with the prior art, it has the following advantages: By introducing hierarchical attribute name identifiers and base key names, hierarchical configuration management is achieved, allowing configurations to be defined according to the hierarchical relationships of business modules, sub-modules, agents, and subtasks. This provides fine-grained configuration capabilities, allowing configurations to be overridden or inherited from higher levels at specific levels. By independently performing three-level priority resolution on the three configuration dimensions—model name, API access address, and API authentication key—smooth configuration degradation and multi-dimensional decoupling are achieved. When a configuration at a specific level is missing, it can automatically backtrack to the parent level or the global default configuration, ensuring that model instances can always be successfully constructed and avoiding system failures caused by missing configurations. Simultaneously, independent resolution of each dimension means that model names, API addresses, and authentication keys can be obtained from different levels without affecting each other, greatly reducing the coupling between configurations. When adjusting the business module hierarchy, there is no need to modify a large amount of configuration key references in the code, because the configuration is obtained based on dynamically resolved hierarchical identifiers, rather than hard-coded configuration keys. This significantly improves the maintainability and adaptability of the system, enabling the AI ​​application platform to respond more flexibly to business changes and technological evolution. Attached Figure Description

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

[0018] Figure 1 A flowchart illustrating a hierarchical degradation configuration method for a model provided in an embodiment of the present invention; Figure 2 This is a schematic diagram of a model-level degradation configuration system provided in an embodiment of the present invention. Detailed Implementation

[0019] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions in the embodiments of this application are described clearly and completely. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0020] To better understand the above technical solutions, the following will provide a detailed explanation of the technical solutions in conjunction with the accompanying drawings and specific implementation methods.

[0021] like Figure 1 As shown in the embodiment of this application, a model-level degradation configuration method is provided, including: S1: Receives the point hierarchical attribute name identifier of the model and constructs the base key name for the configuration query.

[0022] It accepts an attribute name identifier (e.g., model_prop_name) that describes the purpose of the Large Language Model (LLM). The identifier adopts a dot-separated hierarchical structure (e.g., oa.doc, compliance.contract, or trading.analyzer, etc.), where the dot separator (.) separates the hierarchy, and the hierarchy from left to right represents a tree structure of "module → submodule → agent → subtask". The attribute name identifier is concatenated with the prefix "model." to form the corresponding base key name in the configuration file (e.g., model.oa.doc).

[0023] S2: Based on the base key name, perform three-level priority parsing independently for each of the three configuration dimensions: model name, API access address, and API authentication key, to determine the triplet configuration data of the model instance.

[0024] Specifically, for each configuration dimension, the system attempts to find the corresponding configuration value from different configuration sources or levels. For example, for the model name dimension, the system can first try to find a configuration item that exactly matches the complete base key name. If not found, it can try to find a configuration item that matches the parent level of the base key name. If still not found, it can further search the global default configuration. This process is also performed independently for the API access address and API authentication key dimensions. This independent resolution approach allows each configuration dimension to have its own search logic and priority, avoiding strong coupling between different configuration dimensions.

[0025] S3: Construct a model instance based on the triple configuration data.

[0026] Specifically, once the three key parameters—model name, API access address, and API authentication key—are successfully parsed and obtained, the system can use these parameters to initialize or instantiate a specific model object. For example, the system can call a model factory function, passing the parsed model name, API access address, and API authentication key as parameters, to obtain a model instance that can be used by business logic. This model instance will have all the necessary configuration information and can be used directly.

[0027] In this optional embodiment, hierarchical configuration management is achieved by introducing point-level hierarchical attribute name identifiers and base key names, allowing configurations to be defined according to the hierarchical relationships of business modules, sub-modules, agents, and subtasks. This provides fine-grained configuration capabilities, allowing for the overriding or inheritance of upper-level configurations at specific levels. By independently performing three-level priority resolution on the three configuration dimensions of model name, API access address, and API authentication key, smooth configuration degradation and multi-dimensional decoupling are achieved. When a configuration at a specific level is missing, it can automatically backtrack to the parent level or the global default configuration, ensuring that model instances can always be successfully constructed and avoiding system failures caused by missing configurations. At the same time, independent resolution of each dimension means that the model name, API address, and authentication key can be obtained from different levels without affecting each other, greatly reducing the coupling between configurations. For example, an agent may use the API address defined by its parent module but use the globally default model name. Therefore, when adjusting the business module hierarchy, this method does not require modifying a large number of configuration key references in the code, because the configuration is obtained based on dynamically resolved hierarchical identifiers, rather than hard-coded configuration keys. This significantly improves the maintainability and adaptability of the system, enabling AI application platforms to respond more flexibly to business changes and technological evolution.

[0028] The following is a detailed description of each step.

[0029] S1: Receives the point hierarchical attribute name identifier of the model and constructs the base key name for the configuration query.

[0030] Specifically, the dot-separated hierarchical attribute name identifier includes a dot separator and multiple hierarchical names, wherein the dot separator separates the multiple hierarchical names, and the multiple hierarchical names include module name, submodule name, Agent name, and subtask name. The base key name includes a prefix and a dot-separated hierarchical attribute name identifier.

[0031] The introduction of dotted hierarchical attribute name identifiers, particularly through the specific hierarchical division of module names, submodule names, agent names, and subtask names, ensures that model configurations closely correspond to the actual business architecture and functional modules, significantly improving configuration readability and maintainability. Furthermore, the design of including prefixes and dotted hierarchical attribute name identifiers in the base key names not only provides a unique and structured entry point for configuration queries but also achieves configuration classification and namespace management through prefixes, effectively avoiding key name conflicts. This explicit hierarchical definition and key name construction method allows the system to more accurately and efficiently locate configuration data at different levels during three-level priority resolution, ensuring that model instances obtain the most suitable configuration. This significantly improves the efficiency and accuracy of configuration management and reduces the risk of system errors caused by configuration chaos.

[0032] S2: Based on the base key name, perform three-level priority parsing independently for each of the three configuration dimensions: model name, API access address, and API authentication key, to determine the triplet configuration data of the model instance.

[0033] Specifically, the attribute name of the model name is the base key name. The attribute name of the API access address is the base key name followed by a dot separator and the access address name (dimension suffix), for example, model.oa.doc.openai_api_base_url. The attribute name of the API authentication key is the base key name followed by a dot separator and the key name (dimension suffix). This standardized attribute name construction method provides a clear lookup target for subsequent degradation resolution, ensuring the accuracy and efficiency of the configuration resolution process, avoiding configuration errors or lookup failures caused by ambiguous attribute names, and thus improving the reliability of the entire model instance configuration.

[0034] In addition, the three-level priority resolution includes: S210: First Priority (Exact Match): Reads the specific configuration corresponding to the attribute name. For example, using model.oa.doc.openai_api_base_url as the attribute name, it reads the dimension configuration value specific to this Agent from the configuration system; if the configuration item exists and is not empty, it is used, and the parsing terminates.

[0035] S220: Second Priority (Parent Degradation): If the first priority configuration is not found and the base key name within the attribute name contains at least one dot separator, extract the parent identifier from the base key name to replace the original base key name, forming a new attribute name, and read the parent configuration corresponding to the new attribute name. For example, extract the part before the last dot as the parent identifier, read the parent configuration with model.oa.openai_api_base_url as the attribute name, and if the configuration item exists and is not empty, use that value, and the parsing terminates.

[0036] S230: Third priority (global default). If the second priority configuration is not matched, the global default configuration is read directly. For example, the system's global default configuration is read using the global default attribute name (such as openai_api_base_url or OPENAI_API_KEY).

[0037] By first attempting the most precise configuration match (first priority), and if unsuccessful, intelligently backtracking up to the parent configuration (second priority), until a configuration is found or the highest level is reached, and finally, if still not found, the global default configuration (third priority) is used. This hierarchical degradation resolution mechanism ensures that a suitable configuration data can always be found in complex, multi-level model configuration scenarios. It searches for configurations from the most specific to the most general, thus providing robust and flexible configuration management for model instance construction. It significantly reduces the need for redundant configurations because configurations can be inherited from the parent. Simultaneously, it ensures that even if a specific configuration is missing, the model instance can still be successfully constructed by backtracking to the parent or the global default configuration, thereby improving the system's automation and fault tolerance. This hierarchical degradation resolution approach enables the system to operate more efficiently and stably when facing complex and ever-changing model configuration requirements.

[0038] The step of extracting the parent identifier from the base key name, replacing the original base key name to form a new attribute name, and reading the parent configuration corresponding to the new attribute name includes: S221: Split and delete the last dot separator and the content after the last dot separator in the base key name to obtain the parent identifier.

[0039] Specifically, by systematically removing the most specific hierarchical information from the base key name, a more general, higher-level identifier is obtained. For example, the base key name can be split based on the dot separator using string processing functions, then the last segment can be discarded, and the remaining parts can be recombined to form the parent identifier; alternatively, regular expressions can be used to match and remove the last dot separator and all characters following it from the base key name.

[0040] S222: Replace the base key name with a parent identifier as the new base key name. Update the context of the current configuration lookup to the parent hierarchy, ensuring that subsequent lookup operations are based on this broader parent identifier. This can be achieved by directly assigning the newly generated parent identifier to the variable storing the base key name, or by creating a new variable to store the new base key name.

[0041] S223: Based on the different parsing dimensions, construct new attribute names and read the parent configuration corresponding to the new attribute names.

[0042] Specifically, this ensures that parent-level lookups are performed for specific configuration dimensions (such as model name, API access address, or API authentication key). Specifically, if the current dimension is the model name, the new attribute name is the new base key name; if the dimension is the API access address, the new attribute name is the new base key name followed by a dot separator and the access address name; for the API authentication key dimension, it's the new base key name followed by a dot separator and the key name. After the build is complete, the system calls the corresponding configuration read interface to attempt to retrieve the parent configuration corresponding to the new attribute name.

[0043] S224: If no configuration is read, then based on the new attribute name, extract the parent identifier from the new base key name to iteratively construct the next new attribute name, and read the corresponding parent configuration until the configuration is read or the new base key name in the new attribute name cannot be divided.

[0044] Specifically, if the configuration is not found at the current parent level, the system will not stop. Instead, it will start from the new base key and repeat the process of extracting the parent identifier, constructing new attribute names, and attempting to read the configuration. This iterative process will continue until the configuration is successfully read at a certain parent level, or until the base key name can no longer be divided (i.e., the root of the hierarchy has been reached), thus ensuring a comprehensive search of the entire configuration hierarchy.

[0045] S225: If the base key name within the attribute name does not include a dot separator or the new base key name within the new attribute name cannot be separated, then skip the second priority and directly proceed to the third priority. That is, during the iterative search for the parent configuration in the second priority, the new base key name contained in the new attribute name currently used for querying can no longer generate a higher-level parent identifier by deleting the last dot separator and the content after it.

[0046] This iterative parent configuration resolution mechanism ensures that when the most specific configuration cannot be found, the system can search upwards along the configuration hierarchy level by level until a suitable parent configuration is found, or all parent levels are exhausted. This significantly improves the success rate and accuracy of configuration lookup, avoiding premature fallback to the global default configuration due to a single failed parent lookup, thus allowing model instances to obtain configuration data more consistent with their hierarchical context. Ultimately, this helps improve the robustness and fine-grained management capabilities of the entire configuration system, enabling models at different levels to inherit and override configurations, achieving efficient and maintainable configuration management.

[0047] It should be noted that different handling strategies are adopted for cases where the configuration is not matched after all three levels of priority parsing for different dimensions. For the model name dimension, if the configuration is not matched after all three levels of priority parsing, the handling strategy is to use the built-in default model (such as qwen-max-latest) and log warnings accordingly. For the API access address dimension, if the configuration is not matched after all three levels of priority parsing, the handling strategy is to generate a configuration missing exception message to indicate the corresponding API access address.

[0048] After parsing the configuration through a three-tiered priority process (specific configuration, parent configuration, and global default configuration), if a valid model name configuration is still not successfully obtained, the system will not interrupt or report an error. Instead, it will automatically activate a fault-tolerance mechanism. The system will use a pre-built default model to replace the missing model name configuration, ensuring that the model instance can be successfully constructed and put into use. Simultaneously, to facilitate subsequent problem tracking and system maintenance, the system will record the configuration parsing failure and the use of the default model in the form of a warning log. This approach ensures that the system maintains a certain level of availability even with incomplete or erroneous configurations, preventing the entire service from becoming unavailable due to the absence of a single configuration item, thereby improving system robustness and user experience. Through this mechanism, the system provides a fallback solution at the end of the configuration parsing process, effectively addressing potential configuration omissions or errors in complex configuration scenarios and ensuring the continuity of model services. When the API access address of the model instance is not found in all configuration levels, the system can issue a timely and explicit warning, rather than silently failing or using an uncertain default value. This enables developers or operations personnel to quickly identify and correct configuration errors or omissions, avoiding system runtime errors or functional abnormalities caused by missing API access addresses, and significantly improving the transparency of the configuration process and the maintainability of the system.

[0049] The degradation resolution of the three dimensions (model name, API address, and API key) is independent of each other. That is, the model name can be matched precisely at the Agent level, while the API address is downgraded to the module level, and the API key is downgraded to the global default. The three can be at different levels.

[0050] S3: Construct a model instance based on the triple configuration data.

[0051] Specifically, the three configuration dimensions each independently execute the three-level priority resolution mechanism, supporting the following flexible configuration combinations: only overriding the model name and inheriting the parent's API access address and authentication key; only overriding the API access address and inheriting the global authentication key; and any combination that hits different levels in different dimensions.

[0052] S4: Using the directory where the model's code file is located in the model instance as the base directory, concatenate the relative path of the Prompt file to obtain the absolute path of the Prompt file and load its content; the relative position of the Prompt file and the model's code file remains fixed and is saved in the same folder; when the directory structure where the model's code file is located is adjusted, the reference relationship of the Prompt file will automatically follow and migrate.

[0053] Specifically, the Prompt file is loaded using a relative path mechanism based on the runtime caller file (i.e., the model's code file). The absolute path of the file containing the code that calls the prompts_from() function (i.e., the absolute path of the caller's code file) is obtained from the program's runtime stack information. Using the directory containing the caller file as the base directory, the passed relative path (e.g., prompts / contract_classify.md) is concatenated to form the absolute path of the Prompt file. The contents of the Prompt file are then read and returned.

[0054] In this step, the Prompt file is placed alongside the Agent code file using a relative path. When the code directory structure changes, the Prompt references automatically migrate accordingly, eliminating the need to maintain hard-coded absolute paths. For example, each Agent's Prompt file is stored near the Agent code file using a relative path, eliminating the need to hard-code absolute paths in the Prompt loading call. When the Agent code file's location changes, the Prompt references automatically migrate. When the entire directory containing the model code files is moved, copied, or renamed, because the Prompt file's location is based on the model code file's relative path, no manual modification to any configuration or code is required. The system can still automatically find and load the Prompt file using the new base directory and the unchanged relative path. This greatly enhances the model's deployment flexibility and maintenance convenience.

[0055] like Figure 2 As shown in the embodiment of this application, a model-level degradation configuration system is provided, including: The key name building module is used to receive point hierarchical attribute name identifiers from the model and build the base key names for configuration queries.

[0056] The configuration parsing module is used to independently perform three-level priority parsing on the three configuration dimensions of model name, API access address and API authentication key based on the base key name, and determine the triplet configuration data of the model instance.

[0057] The instance construction module is used to construct model instances based on triple configuration data.

[0058] In this optional embodiment, by combining point-level hierarchical attribute name identifiers with a three-level priority resolution mechanism in a hierarchical configuration query manner, fine-grained control of configuration and smooth transition of global defaults are achieved. This reduces the coupling between the three configuration dimensions—model name, API access address, and API authentication key—and improves system maintainability. Specifically, the key name construction module dynamically generates basic key names based on point-level hierarchical attribute name identifiers, making configuration queries closely related to the business hierarchy structure. The configuration resolution module independently performs three-level priority resolution for the three configuration dimensions. When a specific level of configuration is missing, it automatically backtracks to the parent identifier or the global default configuration, avoiding modification of configuration key references due to adjustments in the business module hierarchy. The instance construction module completes model instantiation based on the parsed triplet configuration data. Through the above technical solution, the system does not need to modify a large number of configuration key references in the code when adjusting the business module hierarchy, while ensuring the reliable construction of model instances. This effectively solves the problems in the prior art where globally unified configuration cannot meet differentiated needs and completely independent configuration leads to complex maintenance.

[0059] In summary, compared with existing technologies, it has the following beneficial effects: 1. Minimize redundant configuration: The hierarchical degradation mechanism allows lower-level agents to configure only different dimensions from the parent layer, and the same API address and key do not need to be filled in repeatedly, reducing the redundancy of configuration files; 2. Independent degradation across dimensions, flexible configuration: Independent degradation across three dimensions (model name, API address, and key) supports flexible combinations such as "specific model + inherited API address" to meet the needs of different agents using different models (but sharing the same API access point) within the same module; 3. Zero friction when adding a new Agent: When adding a new Agent that uses a different model but shares the API access point, you only need to add a line of model name configuration in the configuration file, without modifying the code; 4. Unified interface for multiple LLM platforms: Through independent configuration of API address and key, the system can connect to multiple LLM service providers at the same time. All business code creates instances through the unified base_llm() interface, without being aware of the differences in underlying service providers; 5. Prompt file and Agent code are migrated together: The relative path Prompt file loading mechanism ensures that the Prompt file is adjacent to the Agent code file. When the directory is restructured, the two are moved synchronously, reducing maintenance costs.

[0060] In a configuration example, taking a multi-module platform as an example, the key-value organization method of the configuration file is as follows: Global default (shared by all modules) openai_api_base_url=https: / / api.openai.com / v1 OPENAI_API_KEY=sk-global-xxx openai_default_model=qwen-max-latest OA module (using Alibaba Cloud DashScope, module-level coverage of API addresses and keys) model.oa.openai_api_base_url=https: / / dashscope.aliyuncs.com / compatible-mode / v1 model.oa.openai_api_key=sk-dashscope-xxx model.oa=qwen-max-latest The document generation agent for the OA module (only overwrites the model name, inheriting the API address and key of the OA module). model.oa.doc=qwen-vl-max Compliance module contract review agent (completely independent configuration) model.compliance.contract=deepseek-reasoner model.compliance.contract.openai_api_base_url=https: / / api.deepseek.com model.compliance.contract.openai_api_key=sk-deepseek-xxx In the above configuration, when calling base_llm (i.e., oa.doc): Model name: model.oa.doc=qwen-vl-max (Exact hit) API address: model.oa.doc.openai_api_base_url is not configured → Degrade to the address where model.oa.openai_api_base_url=DashScope (parent page hit). API key: model.oa.doc.openai_api_key not configured → downgraded to model.oa.openai_api_key=DashScope key (parent key is configured). Instantiate a multimodal Vision LLM client using the triple (qwen-vl-max, DashScope address, DashScope key).

[0061] In another configuration example, suppose the OA module needs to add a "News Summary" subtask that uses the DeepSeek model, but still uses the OA module's DashScope access point (the platform is also compatible with the DeepSeek protocol).

[0062] Only one line needs to be added to the configuration file: model.oa.news.summary=deepseek-v3 When calling base_llm (i.e., oa.news.summary): Model Name: Exact Hit Deepseek-v3 API address: Demoted to the parent's model.oa.openai_api_base_url=DashScope address (inherited from the parent). API key: Demoted to the parent model.oa.openai_api_key=DashScope key (inherited from the parent). This allows you to complete the integration of a new Agent with a single line of configuration, eliminating the need to repeatedly fill in the DashScope address and key.

[0063] An electronic device provided in this application includes a memory and a processor; the memory is used to store a computer program; the processor is used to implement the model-level degradation configuration method as described above when executing the computer program.

[0064] This application provides a computer-readable storage medium storing a computer program. When the computer program is executed by a processor, it implements the model-level degradation configuration method described above.

[0065] In this embodiment, the beneficial effects of the electronic device and the computer-readable storage medium are similar to those of the hierarchical degradation configuration method described above, and will not be repeated here.

[0066] The present invention describes electronic devices that can serve as servers or clients of this application, which are examples of hardware devices that can be applied to various aspects of this application. Electronic devices are intended to represent various forms of digital electronic computer devices, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. Electronic devices can also represent various forms of mobile devices, such as personal digital assistant devices, cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely examples and are not intended to limit the implementation of the application described and / or claimed herein.

[0067] Electronic devices include a computing unit that can perform various appropriate actions and processes based on a computer program stored in read-only memory (ROM) or loaded from a storage unit into random access memory (RAM). The RAM can also store various programs and data required for device operation. The computing unit, ROM, and RAM are interconnected via a bus. Input / output (I / O) interfaces are also connected to the bus.

[0068] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. The storage medium can be a magnetic disk, optical disk, read-only memory (ROM), or random access memory (RAM), etc. In this application, the separately described modules may or may not be physically separate. Some or all of the modules can be selected to achieve the purpose of the embodiments of this application according to actual needs. Furthermore, the functional modules in the various embodiments of this application can be integrated into one processing unit, or each module can exist physically separately, or two or more modules can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0069] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0070] The above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application.

Claims

1. A hierarchical degradation configuration method for models, characterized in that, include: Receive the point hierarchical attribute name identifiers of the model and construct the base key name for the configuration query; Based on the base key name, three-level priority parsing is performed independently for each of the three configuration dimensions: model name, API access address, and API authentication key, to determine the triplet configuration data of the model instance; Construct a model instance based on the triple configuration data.

2. The model-level degradation configuration method as described in claim 1, characterized in that, Also includes: Using the directory containing the model's code file in the model instance as the base directory, the relative path of the Prompt file is concatenated to obtain the absolute path of the Prompt file, and its content is loaded. The relative position of the Prompt file and the model's code file remains fixed, and they are stored in the same folder. When the directory structure of the model's code file is adjusted, the reference relationship of the Prompt file is automatically migrated accordingly.

3. The model-level degradation configuration method as described in claim 1, characterized in that, The point-level hierarchical attribute name identifier includes a dot separator and multiple hierarchical names, wherein the dot separator separates the multiple hierarchical names, and the multiple hierarchical names include module name, submodule name, Agent name, and subtask name; The base key name includes a prefix and a dotted hierarchical attribute name identifier.

4. The model hierarchical degradation configuration method as described in claim 3, characterized in that, The attribute name of the model name is the base key name; The attribute name of the API access address is the base key name followed by a dot separator and the access address name in sequence; The attribute name of the API authentication key is the base key name followed by a dot separator and the key name in sequence.

5. The model hierarchical degradation configuration method as described in claim 4, characterized in that, The three-level priority resolution includes: First priority: Read the specific configuration corresponding to the attribute name; Second priority: If the configuration of the first priority is not matched and the base key name in the attribute name includes at least one dot separator, extract the parent identifier in the base key name to replace the original base key name, form a new attribute name, and read the parent configuration corresponding to the new attribute name. The third priority is to directly read the global default configuration if the second priority configuration is not matched.

6. The model hierarchical degradation configuration method as described in claim 5, characterized in that, The step of extracting the parent identifier from the base key name, replacing the original base key name to form a new attribute name, and reading the parent configuration corresponding to the new attribute name includes: Separate and delete the last dot separator and the content after the last dot separator in the base key name to obtain the parent identifier; Replace the base key name with the parent identifier and use it as the new base key name; Depending on the different parsing dimensions, new attribute names are constructed accordingly, and the parent configuration corresponding to the new attribute names is read. If no configuration is read, the new property name is used as the basis to extract the parent identifier from the new base key name and iteratively construct the next new property name, and the corresponding parent configuration is read, until the configuration is read or the new base key name in the new property name cannot be divided.

7. The model hierarchical degradation configuration method as described in claim 6, characterized in that, If the base key name within the attribute name does not include a dot separator or the new base key name within the new attribute name cannot be separated, then skip the second priority and proceed directly to the third priority.

8. The model hierarchical degradation configuration method as described in claim 1, characterized in that, For the model name dimension, if the configuration is not matched after parsing all three priority levels, the built-in default model will be used, and warning logs will be recorded accordingly.

9. The model hierarchical degradation configuration method as described in claim 1, characterized in that, For the API access address dimension, if the configuration is not matched after parsing all three priority levels, a configuration missing exception message will be generated to indicate the corresponding API access address in the configuration.

10. A model-level degradation configuration system, characterized in that, include: The key name building module is used to receive the point hierarchical attribute name identifiers of the model and build the base key names for configuration queries; The configuration parsing module is used to independently perform three-level priority parsing on the three configuration dimensions of model name, API access address and API authentication key based on the base key name, and determine the triplet configuration data of the model instance. The instance construction module is used to construct model instances based on triple configuration data.

Images