Intelligent model automatic orchestration method, device, system, equipment, medium and product

Abstract

The application discloses an intelligent model automatic arrangement method, device, system, equipment, medium and product, and belongs to the field of artificial intelligence. The method comprises the following steps: acquiring code context information in a programming environment, and determining a first scene corresponding to the code context information; determining a first model which performs best in the first scene from a plurality of models, and establishing an initial session connection with the first model; in the process that a target object interacts with the first model, determining whether the first model needs to be re-evaluated by judging a session state, and in the case that the first model needs to be re-evaluated and the result of the model re-evaluation is that the model needs to be switched, the first model is switched to a target model. The application solves the technical problem that in the related art, the model selection decision in the programming assistant is based on a preset rule or simple matching, and lacks real-time sensing capability for dynamic programming scenes.

Description

Technical Field

[0001] This application relates to the field of artificial intelligence, and more specifically, to a method, apparatus, system, device, medium, and product for automatic arrangement of intelligent models. Background Technology

[0002] In related technologies, programming assistant systems mainly have the following drawbacks: First, programming assistant systems adopt a single deployment architecture, and model switching depends on manual selection by the user; second, the system handles different model instances through a fixed session management mechanism, and users need to manually operate when switching between different sessions, and historical context cannot be automatically inherited; third, model selection decisions are based on preset rules or simple matching, lacking the ability to perceive dynamic programming scenarios in real time.

[0003] There is currently no effective solution to the above problems. Summary of the Invention

[0004] This application provides an intelligent model automatic orchestration method, apparatus, system, device, medium, and product to at least solve the technical problem in related technologies where programming assistants rely on preset rules or simple matching for model selection decisions, lacking real-time perception capabilities for dynamic programming scenarios.

[0005] According to one aspect of the embodiments of this application, an intelligent model automatic orchestration method is provided, comprising: obtaining code context information in a programming environment and determining a first scenario corresponding to the code context information; determining a first model that performs best in the first scenario from multiple models and establishing an initial session connection with the first model; during the interaction between the target object and the first model, determining whether the first model needs to be re-evaluated by judging the session state; and if model re-evaluation is required and the result of model re-evaluation is that model switching is required, switching the first model to the target model.

[0006] Optionally, determining the best-performing model in the first scenario from multiple models includes: obtaining the effective usage time of multiple models, where the effective usage time represents the cumulative time spent coding under different types of scenarios; obtaining the displayed evaluation scores of multiple models, where the displayed evaluation scores represent the target object's satisfaction rating with the code generated by the model; obtaining the modification rate of multiple models, where the modification rate represents the proportion of code generated by the model that has been adjusted by the target object; obtaining the base performance score of multiple models, where the base performance score represents the inherent performance of the model in standard tests; performing a weighted sum of the effective usage time, displayed evaluation score, modification rate, and base performance score to obtain a comprehensive score for each model; determining a capability matching matrix table based on the comprehensive scores of the multiple models; and querying the best-performing model in the first scenario from the capability matching matrix table.

[0007] Optionally, determining whether to re-evaluate the first model by judging the session state includes: obtaining the first feature vector corresponding to the code context information, and obtaining the second feature vector during the interaction between the target object and the first model; determining the similarity between the first feature vector and the second feature vector; determining that there is scene drift in the session if the similarity is less than the feature threshold; obtaining the resource level during the interaction between the target object and the first model if no scene drift occurs; and re-evaluating the first model if the resource level exceeds the preset safety level and the target object completes a stage code submission, or if scene drift occurs.

[0008] Optionally, after re-evaluating the first model, the method further includes: in the event of scene drift, determining the second model corresponding to the second feature vector from the capability matching matrix table, and determining the first comprehensive score and the second comprehensive score of the first model and the second model respectively from the capability matching matrix table, wherein the capability matching matrix table stores the comprehensive scores of multiple models in different types of scenes; determining the difference between the second comprehensive score and the first comprehensive score, and if the difference is greater than a preset difference, determining that model switching is required, and generating a first model switching instruction, wherein the first model switching instruction is to switch the first model to the second model, and the second model is determined as the target model; if the difference is less than or equal to the preset difference, determining that model switching is not required.

[0009] Optionally, after re-evaluating the first model, the method further includes: if no scene drift occurs, the resource level exceeds the preset safety level, and the target object completes the phased code submission, querying the capability matching matrix table again based on the first scene to obtain the query result, wherein the capability matching matrix table stores the comprehensive scores of multiple models in different types of scenes; if the query result indicates that the first model is the optimal model for the first scene, determining that no model switching is required; if the query result indicates that the third model is the optimal model for the first scene, determining that a model switching is required, and generating a second model switching instruction, wherein the second model switching instruction switches the first model to the third model and identifies the third model as the target model.

[0010] Optionally, if the model re-evaluation result indicates that a model switch is required, the first model is switched to the target model, including: after the target object has completed rendering after interacting with the first model in the last time, and before the next interaction request is initiated, starting a container instance of the target model and loading the first feature vector corresponding to the code context information into the container instance; obtaining the next interaction request initiated by the target object and distributing the next interaction request to both the first model and the target model; if the target model handles the next interaction request without errors and responds normally, enabling the target model to take over subsequent requests and releasing all resources of the first model; if the target model handles the next interaction request with errors or timeouts, automatically falling back to the first model to continue executing the next interaction request.

[0011] Optionally, after enabling the target model to take over subsequent requests, the method further includes: obtaining switching information of the model switch, wherein the switching information includes at least one of the following: triggering reason, switching time and task continuity score during the model switch process; storing the switching information in an offline log, and updating the capability matching matrix table based on the switching information.

[0012] According to another aspect of the embodiments of this application, an intelligent model automatic orchestration device is also provided, comprising: an acquisition module, configured to acquire code context information in a programming environment and determine a first scenario corresponding to the code context information; a determination module, configured to determine a first model that performs best in the first scenario from multiple models and establish an initial session connection with the first model; and a switching module, configured to determine whether model re-evaluation of the first model is required by judging the session state during the interaction between the target object and the first model, and to switch the first model to the target model if model re-evaluation is required and the result of model re-evaluation is that model switching is required.

[0013] According to another aspect of the embodiments of this application, an intelligent model automatic orchestration system is also provided, including: a context feature extractor, an intelligent session manager, a model fit evaluator, and a resource scheduler. The context feature extractor is used to obtain code context information in a programming environment and determine a first scenario corresponding to the code context information. The model fit evaluator is used to determine the first model that performs best in the first scenario from multiple models and establish an initial session connection with the first model. The intelligent session manager is used to determine whether model re-evaluation of the first model is needed by judging the session state during the interaction between the target object and the first model. If model re-evaluation is needed and the result of the model re-evaluation is that model switching is required, the manager sends a switching instruction to the resource scheduler, wherein the switching instruction is used to switch the first model to the target model. The resource scheduler is used to receive the switching instruction and switch the first model to the target model according to the switching instruction.

[0014] According to another aspect of the embodiments of this application, an electronic device is also provided, including: a memory for storing program instructions; and a processor connected to the memory for executing program instructions to perform the following functions: obtaining code context information in a programming environment and determining a first scenario corresponding to the code context information; determining a first model that performs best in the first scenario from multiple models and establishing an initial session connection with the first model; and during the interaction between the target object and the first model, determining whether the first model needs to be re-evaluated by judging the session state, and if model re-evaluation is required and the result of model re-evaluation is that model switching is required, switching the first model to the target model.

[0015] According to another aspect of the embodiments of this application, a non-volatile storage medium is also provided, the non-volatile storage medium including a stored computer program, wherein the device where the non-volatile storage medium is located executes the above-described intelligent model automatic arrangement method by running the computer program.

[0016] According to another aspect of the embodiments of this application, a computer program product is also provided, including computer instructions that, when executed by a processor, implement the above-described intelligent model automatic arrangement method.

[0017] In this embodiment, by obtaining code context information in the programming environment and determining the first scenario corresponding to the code context information; determining the first model that performs best in the first scenario from multiple models and establishing an initial session connection with the first model; during the interaction between the target object and the first model, determining whether the first model needs to be re-evaluated by judging the session state; if model re-evaluation is required and the result of model re-evaluation is that model switching is required, the first model is switched to the target model, thereby achieving the purpose of matching the model with the currently changing programming scenario in real time and accurately, thus achieving the technical effect of improving programming experience and efficiency, and solving the technical problem in related technologies where the model selection decision is based on preset rules or simple matching and lacks real-time perception capability of dynamic programming scenarios. Attached Figure Description

[0018] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:

[0019] Figure 1 This is a hardware structure block diagram of a computer terminal for implementing an automatic arrangement method for intelligent models according to an embodiment of this application;

[0020] Figure 2 This is a flowchart of an intelligent model automatic arrangement method according to an embodiment of this application;

[0021] Figure 3 This is a flowchart illustrating the generation of a first model switching instruction according to an embodiment of this application;

[0022] Figure 4 This is a flowchart illustrating the generation of a second model switching instruction according to an embodiment of this application;

[0023] Figure 5 This is a system processing flowchart according to an embodiment of this application;

[0024] Figure 6 This is a structural diagram of an intelligent model automatic arrangement device according to an embodiment of this application. Detailed Implementation

[0025] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort should fall within the scope of protection of the present application.

[0026] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0027] Current code generation methods in related technologies provide a model list and manual selection function through a user interface for model switching. However, due to a lack of automatic analysis capabilities of the user's current programming environment (including code syntax characteristics, complexity characteristics, domain characteristics, etc.), model selection becomes disconnected from the specific programming task, relying solely on the user's subjective judgment. Therefore, it is difficult to meet the needs of accurate and efficient model matching in complex programming scenarios. This approach suffers from rigid model selection, failing to match the optimal model in real time according to dynamically changing programming scenarios.

[0028] Furthermore, while related solutions employ independent session management mechanisms to achieve parallel operation of multiple models, the lack of intelligent state transition mechanisms and state isolation between different sessions means that contextual information such as historical interaction records, task progress, and user preferences cannot be automatically transferred to the new session when token limits are reached or models are switched. Therefore, this approach fails to meet the requirements for seamless and continuous experiences in complex, long-term, cross-model programming tasks. This approach suffers from a lack of intelligent prediction and guarantee mechanisms for session switching, leading to task continuity interruptions and resource waste.

[0029] To address the problems existing in related technologies, this application provides an intelligent model automatic orchestration method, which can run on... Figure 1 The computer terminal shown is explained below.

[0030] The intelligent model automatic arrangement method embodiments provided in this application can be executed on mobile terminals, computer terminals or similar computing devices. Figure 1 A hardware block diagram of a computer terminal for implementing an automatic orchestration method for intelligent models is shown. Figure 1 As shown, the computer terminal 10 may include one or more processors (shown as 102a, 102b, ..., 102n in the figure) (the processor may include, but is not limited to, a microprocessor MCU or a programmable logic device FPGA, etc.), a memory 104 for storing data, and a transmission module 106 for communication functions connected via wired and / or wireless networks. In addition, it may also include: a display, a keyboard, a cursor control device, an input / output interface (I / O interface), a universal serial bus (USB) port (which may be included as one of the ports of the I / O interface), a network interface, and a BUS bus. Those skilled in the art will understand that... Figure 1 The structure shown is for illustrative purposes only and does not limit the structure of the aforementioned electronic device. For example, computer terminal 10 may also include... Figure 1 The more or fewer components shown, or having the same Figure 1 The different configurations shown.

[0031] It should be noted that the aforementioned one or more processors and / or other data processing circuits are generally referred to herein as "data processing circuits". These data processing circuits may be embodied, in whole or in part, in software, hardware, firmware, or any other combination thereof. Furthermore, the data processing circuits may be a single, independent processing module, or may be integrated, in whole or in part, into any other element within the computer terminal 10. As involved in the embodiments of this application, the data processing circuits serve as a processor control mechanism (e.g., selection of a variable resistor termination path connected to an interface).

[0032] The memory 104 can be used to store software programs and modules of application software, such as the program instructions / data storage device corresponding to the intelligent model automatic arrangement method in this embodiment. The processor executes various functional applications and data processing by running the software programs and modules stored in the memory 104, thereby realizing the aforementioned intelligent model automatic arrangement method. The memory 104 may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 104 may further include memory remotely located relative to the processor, and these remote memories can be connected to the computer terminal 10 via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0033] The transmission module 106 is used to receive or send data via a network. Specific examples of the network described above may include a wireless network provided by the communication provider of the computer terminal 10. In one example, the transmission module 106 includes a network interface controller (NIC), which can connect to other network devices via a base station to communicate with the Internet. In another example, the transmission module 106 may be a radio frequency (RF) module, used for wireless communication with the Internet.

[0034] The display can be, for example, a touchscreen liquid crystal display (LCD), which enables the target object to interact with the target object interface of the computer terminal 10.

[0035] It should be noted here that, in some optional embodiments, the above... Figure 1 The computer terminal shown may include hardware elements (including circuitry), software elements (including computer code stored on a computer-readable medium), or a combination of both hardware and software elements. It should be noted that... Figure 1 This is only one instance of a specific particular instance, and is intended to illustrate the types of components that may exist in the aforementioned computer terminal.

[0036] In the above operating environment, this application provides an embodiment of an intelligent model automatic orchestration method. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Also, although a logical order is shown in the flowchart, in some cases, the steps shown or described can be executed in a different order than that shown here.

[0037] Figure 2 This is a flowchart of an intelligent model automatic arrangement method according to an embodiment of this application, such as... Figure 2 As shown, the method includes the following steps:

[0038] Step S202: Obtain code context information in the programming environment and determine the first scenario corresponding to the code context information.

[0039] In step S202 above, a context feature extractor in the context-aware layer deployed in the user's local IDE (Integrated Development Environment) plugin can collect real-time data of the user's current development or programming environment, including code context information. By analyzing the code context information, a corresponding first scenario can be obtained, which can represent the current task intent, such as code generation or bug debugging.

[0040] In addition, the context feature extractor deeply extracts, analyzes, and structures programming context information from code text and interaction history to generate standardized feature vectors for model matching.

[0041] Specifically, in the code feature extraction module of the context feature extractor, the currently edited file is analyzed in real time by integrating a Tree-sitter syntax parser to generate an abstract syntax tree (AST). Structural features such as function nesting depth, class inheritance hierarchy, and exception handling patterns are extracted quantitatively, and cyclomatic complexity and cognitive complexity indices are calculated using static code analysis algorithms. The syntax complexity vector is then determined based on these indices.

[0042] For example, Tree-sitter parsing generates an AST (Abstract Syntax Tree), and traversing the AST to check the maximum nesting level of functions can determine the nesting depth; searching for class inheritance keywords can obtain the class inheritance hierarchy; counting "try-catch" blocks in the code can yield the number of exception handling patterns; and constructing a control flow graph based on the AST (standard formula: M = E - N + 2P) can calculate the cyclomatic complexity of the algorithm, where M represents cyclomatic complexity, a measure of the number of independent paths in the code; E represents the number of edges in the control flow graph, representing possible transition paths in the program execution flow; N represents the number of nodes in the control flow graph, representing basic blocks in the program, i.e., sequentially executed code segments without branches; and P represents the number of connected components. By counting the number of nodes in the control flow graph as described above, a basic complexity score can be obtained. Based on this, other scores such as nesting depth and variable complexity (i.e., the number of times a function references external variables) can be added, and these can be accumulated to obtain the cognitive complexity.

[0043] In the code style recognition module of the context feature extractor, user programming habits are analyzed to identify indentation preferences (spaces / tabs), naming conventions (camelCase / underscore / serpentine), comment styles, and code organization patterns, constructing a lightweight, personalized user coding style profile. This recognition process can employ a combination of regular expressions and statistics. For example: determining spaces / tabs by statistically analyzing the distribution of leading whitespace characters to identify indentation preferences; identifying naming conventions by matching variable / function names with regular expressions and statistically analyzing the proportion of camelCase and underscores; determining comment styles by calculating the ratio of comment lines to code lines and the common distribution of comments in the code; determining user-preferred alphabetical order and standard order by analyzing import order, function order in the code, and variable name order; and determining code organization patterns by calculating the ratio of method count to total class lines to obtain class / function arrangement density. These features are then encoded into code style vectors to construct user profiles.

[0044] In the domain semantic analysis module of the context feature extractor, the import statements, API call patterns and code snippets are semantically vectorized based on the pre-trained code model. By matching the domain knowledge graph built in the background with cosine similarity, the current programming domain (such as Spring Boot microservices, PyTorch deep learning, etc.) and task type are accurately identified to obtain the domain semantic vector.

[0045] In the interaction history structuring module of the context feature extractor, a summarization algorithm is used to extract the natural language description of the current task from the multi-turn dialogue history, generating a task-oriented core semantic summary. The summarization algorithm is computationally simple and can employ a sliding window combined with the TextRank algorithm. The most recent N rounds of dialogue text are extracted, segmented into sentences, and a sentence similarity graph is constructed. Node weights are iteratively calculated to extract the Top-K core sentences. Irrelevant content is removed, retaining the task intent, error messages, and solutions, thus concatenating the extracted content into a summary. Alternatively, if resources are sufficient, a lightweight local large model can be used for abstraction and generalization to directly generate the task description, thereby obtaining the task summary vector.

[0046] In the feature vectorization output module of the context feature extractor, the above four dimensions (syntactic complexity, code style, domain semantics, and task summary) are uniformly encoded into a standardized vector format, which can obtain the first feature vector corresponding to the code context information. This first feature vector is directly output to the downstream model fit evaluator, and the first scenario corresponding to the code context information can be determined through the first feature vector.

[0047] Step S204: Determine the first model that performs best in the first scenario from multiple models, and establish an initial session connection with the first model.

[0048] In step S204 above, in the model fit evaluator in the model orchestration and resource layer, a pre-built capability matching matrix table is used to automatically match and select the largest language model (i.e., the first model) that is most suitable for the task (i.e., the first scenario) based on the first feature vector of the current programming scenario, and establish an initial session connection with the first model.

[0049] Step S206: During the interaction between the target object and the first model, determine whether the first model needs to be re-evaluated by judging the session state. If model re-evaluation is required and the result of model re-evaluation is that model switching is required, switch the first model to the target model.

[0050] In step S206 above, the intelligent session manager in the intelligent control layer detects the session state, including resource level state and scene drift state, to determine whether a model re-evaluation of the first model is required. If a model re-evaluation is required, the intelligent session manager sends a re-evaluation request to the model fit evaluator, along with the latest feature vector (e.g., the second feature vector during the user's interaction with the first model). Based on the re-evaluation result, it determines whether a model switch is required. If the re-evaluation result returned by the model fit evaluator indicates that a model switch is required, the intelligent session manager sends a switching instruction to switch the first model to the target model to the resource scheduler in the model orchestration and resource layer, and the model switch is implemented through the resource scheduler.

[0051] Through steps S202 to S206, the goal of matching the model with the changing programming scenario in real time and accurately is achieved, thereby improving the programming experience and efficiency. This solves the technical problem in related technologies where programming assistants rely on preset rules or simple matching for model selection decisions, lacking real-time awareness of dynamic programming scenarios. The following is a further explanation.

[0052] In step S204 above, determining the best-performing model in the first scenario from multiple models includes: obtaining the effective usage time of multiple models, where the effective usage time represents the cumulative time spent coding in different types of scenarios; obtaining the display evaluation score of multiple models, where the display evaluation score represents the target object's satisfaction rating with the code generated by the model; obtaining the modification rate of multiple models, where the modification rate represents the proportion of code generated by the model that has been adjusted by the target object; obtaining the basic performance score of multiple models, where the basic performance score represents the inherent performance of the model in standard tests; performing a weighted sum of the effective usage time, display evaluation score, modification rate, and basic performance score to obtain a comprehensive score for each model; determining a capability matching matrix table based on the comprehensive scores of multiple models; and querying the best-performing model in the first scenario from the capability matching matrix table.

[0053] In some embodiments of this application, a multi-dimensional model evaluation system is established, which integrates four dimensions: user stickiness, subjective satisfaction, objective code quality, and inherent model capabilities. A score is obtained by weighted calculation, resulting in a comprehensive score for multiple models. Then, a capability matching matrix table is determined based on the comprehensive scores of multiple models, and the first model that performs best in the first scenario is queried from the capability matching matrix table.

[0054] Specifically, the capability matching matrix table is determined in the following way:

[0055] (1) Obtain the effective usage time (T) of each model. The effective usage time represents the cumulative time that users interact effectively with the model in different types of scenarios (or different types of tasks). This indicator can reflect user stickiness. The higher T is, the more trusted the model is by users in that scenario.

[0056] (2) Obtain the explicit rating score (R) for each model. This explicit rating score is used to represent the direct feedback rating of the target object (i.e., the user) on the results generated by the model (such as code) (such as the like or dislike ratio, satisfaction score). This indicator is used to reflect the user's subjective satisfaction. The higher the R, the more satisfied the user is.

[0057] (3) Obtain the modification rate (M) of each model. The modification rate is used to represent the proportion of the results (such as code) generated by the model that are manually modified or adjusted by the target object. The user represents the code adoption rate or accuracy. This indicator is an inverse indicator. That is, the lower the M, the more accurate the model is, and the higher the contribution score of this indicator is; the higher the M, the worse the quality of the model generation is, and the lower the contribution score of this indicator is.

[0058] (4) Obtain the baseline performance score (P) for each model. This baseline performance score represents the inherent performance of the model in publicly available standard benchmark tests (such as HumanEval). This metric reflects the upper limit of the model's general programming ability. The higher the P, the more general the model. This metric serves as a static benchmark and can be used to balance new models or niche scenarios that lack sufficient user data.

[0059] Based on the four indicators obtained above, the comprehensive score of each model is determined using the following formula:

[0060] S = w1T + w2R + w3(1-M) + w4P;

[0061] Where S represents the overall score, and w1, w2, w3, and w4 represent the weight coefficients corresponding to the four indicators. The weight coefficients w can be dynamically adjusted for different task intentions (such as code generation or bug debugging) to achieve accurate profiling of different model capabilities.

[0062] By combining the overall score, model name ID, and scores for each metric, a capability matching matrix table can be constructed. For example, the columns in the table represent the model name ID, and the rows represent the scores for each metric and the overall score. After obtaining the first feature vector corresponding to the code context information, the first scenario is determined through the first feature vector. Therefore, the capability matching matrix table can be used to query the best-performing model in the first scenario.

[0063] In step S206 above, determining whether the first model needs to be re-evaluated by judging the session state includes: obtaining the first feature vector corresponding to the code context information, and obtaining the second feature vector during the interaction between the target object and the first model; determining the similarity between the first feature vector and the second feature vector; determining that there is scene drift in the session if the similarity is less than the feature threshold; obtaining the resource level during the interaction between the target object and the first model if no scene drift occurs; and re-evaluating the first model if the resource level exceeds the preset safety level and the target object completes the stage code submission, or if scene drift occurs.

[0064] In some embodiments of this application, the intelligent session manager is responsible for proactively advancing the session lifecycle based on a multi-condition triggering mechanism. This intelligent session manager can monitor session status, including real-time reading of the current session's token throughput and window capacity (i.e., obtaining resource levels), and quantifying session health into three levels: "healthy," "warning," and "saturated," based on a sliding window algorithm. When no scene drift or change occurs, if the intelligent session manager detects that token usage exceeds a preset safety level (e.g., 60%), and the target object completes a phased code commit (e.g., judging the user's completion point by code commit frequency), it determines that a model re-evaluation of the first model is necessary. By setting "phased code commit" as a resource-driven confirmation condition, frequent re-evaluation triggers caused by rapid user keystrokes or frequent code changes are prevented, thus avoiding system instability.

[0065] The intelligent session manager's session state monitoring also includes scene drift detection, continuously comparing the feature vectors output by the context feature extractor. When it detects that a user has switched file types, introduced a new technology stack, or that there has been a significant change in code structure (i.e., scene drift or scene change), it proactively sends a re-evaluation request to the model fit evaluator, along with the latest feature vectors. Taking the first and second feature vectors mentioned above as examples, when the similarity between the first and second feature vectors is less than the feature threshold, it indicates that there is a difference between the current scene and the initial scene, and that scene drift has occurred. Therefore, the original first model needs to be re-evaluated.

[0066] In the above steps, after re-evaluating the first model, as follows: Figure 3 As shown, the method also includes the following steps:

[0067] Step S302: In the event of scene drift, determine the second model corresponding to the second feature vector from the capability matching matrix table, and determine the first comprehensive score and the second comprehensive score of the first model and the second model respectively from the capability matching matrix table. The capability matching matrix table stores the comprehensive scores of multiple models in different types of scenes.

[0068] Step S304: Determine the difference between the second comprehensive score and the first comprehensive score. If the difference is greater than a preset difference, determine that model switching is required and generate a first model switching instruction. The first model switching instruction is to switch the first model to the second model and determine the second model as the target model.

[0069] Step S306: If the difference is less than or equal to a preset difference, it is determined that no model switching is required.

[0070] In some embodiments of this application, in the event of scene drift, when the model fit evaluator receives a re-evaluation request and the latest feature vector (i.e., the aforementioned second feature vector) from the intelligent session manager, it determines the corresponding second scene (or task) through the second feature vector and performs a query operation in the capability matching matrix table to determine the optimal model corresponding to the second scene. This optimal model is the second model. The first comprehensive score S corresponding to the first model is obtained from the capability matching matrix table. current And obtain the second comprehensive score S corresponding to the second model. best If S best -S current If the value is greater than ΔS (preset difference), the model fit evaluator returns a "suggest switching" signal and the optimal model ID (the ID of the second model) to the intelligent session manager. After receiving the "suggest switching" signal, the intelligent session manager generates a first model switching instruction and sends it to the resource scheduler. The resource scheduler then switches the first model to the second model using the first model switching instruction.

[0071] If the optimal model for the second scenario is determined through the query capability matching matrix table to be the first model, and the difference between the second comprehensive score and the first comprehensive score satisfies the condition of being less than or equal to a preset difference, then the model fit evaluator returns a "maintain status quo" signal to the intelligent session manager, thus preventing model switching. Upon receiving this "maintain status quo" signal, the intelligent session manager cancels the switching instruction, resets the detection state, and continues to monitor token consumption and scenario changes in the next round.

[0072] In the above steps, after re-evaluating the first model, as follows: Figure 4 As shown, the method also includes the following steps:

[0073] Step S402: If no scene drift occurs, the resource level exceeds the preset safety level, and the target object completes the phased code submission, query the capability matching matrix table again based on the first scene to obtain the query result. The capability matching matrix table stores the comprehensive scores of multiple models in different types of scenes.

[0074] Step S404: If the query results indicate that the first model is the optimal model for the first scenario, it is determined that no model switching is required.

[0075] Step S406: If the query result indicates that the third model is the optimal model for the first scenario, it is determined that a model switch is required, and a second model switch instruction is generated. The second model switch instruction is to switch the first model to the third model and determine the third model as the target model.

[0076] In some embodiments of this application, when no scene drift occurs, the resource level exceeds a preset safety level, and the target object completes a phased code submission, the intelligent session manager sends a re-evaluation request to the model fit evaluator, along with the current feature vector (i.e., the first feature vector). Based on the current first scene, the model fit evaluator queries the capability matching matrix table again to obtain the query results. If the query results show that the first model is still the optimal model for the current scene, it returns a signal to the intelligent session manager indicating that no model switching is needed. Upon receiving the corresponding signal, the intelligent session manager resets the detection state and continues to monitor the session state for the next round.

[0077] When the query results show that the first model is not the optimal model, while the third model is the optimal model in the current scenario, if the comprehensive score of the third model in the first scenario is higher than that of the first model in the first scenario, then a model switch is required. The model fit evaluator returns a "suggest switch" signal and the optimal model ID (the ID of the third model) to the intelligent session manager. After receiving the "suggest switch" signal, the intelligent session manager generates a second model switch instruction and sends it to the resource scheduler. The resource scheduler switches the first model to the optimal third model through the second model switch instruction.

[0078] Regardless of whether scene drift occurs, the above two scenarios ensure that the model switching operation is only performed when the new model is superior to the old model, thereby guaranteeing the stability and efficiency of the system.

[0079] In step S206 above, if the model re-evaluation result indicates that model switching is required, the first model is switched to the target model, including: after the target object has completed rendering after interacting with the first model in the last time, and before the next interaction request is initiated, starting the container instance of the target model and loading the first feature vector corresponding to the code context information into the container instance; obtaining the next interaction request initiated by the target object and distributing the next interaction request to both the first model and the target model; if the target model handles the next interaction request without errors and responds normally, enabling the target model to take over subsequent requests and releasing all resources of the first model; if the target model handles the next interaction request with errors or timeouts, automatically reverting to the first model to continue executing the next interaction request.

[0080] In some embodiments of this application, during model switching, the traditional switching process typically involves first disconnecting the old connection and then establishing a new connection, which results in long model response times. To address this issue, embodiments of this application employ a preloading and dual-mode verification mechanism to achieve seamless model switching.

[0081] Specifically, upon receiving a switching instruction (either a first model switching instruction or a second model switching instruction), the resource scheduler silently launches the target model's container instance in the background during the UI idle window period—"after the user's last interaction with the first model has completed rendering, and before the next interaction request with the first model is initiated"—and injects the first feature vector generated by the context feature extractor into the target model. When the user initiates a new round of requests, since the target model has already been pre-loaded, there is no need to wait for startup time, thus reducing switching latency. The resource scheduler obtains the next interaction request initiated by the target object and simultaneously distributes the next interaction request to both the first model and the target model. Based on the response of the two models, it determines whether to perform a model switching operation. If the target model handles the next interaction request without errors and responds normally (e.g., returning reasonable code or text within a specified time), then the target model can be officially enabled to take over subsequent tasks; that is, all subsequent interaction requests are only sent to the target model, and all resources of the first model are released directly after a successful switch. If the target model encounters an error or timeout in processing the next interaction request, it will fall back to the first model to continue executing the next interaction request and return the processing result, while a new alternative model will be warmed up in the background.

[0082] The above mechanism adopts a very simple resource release strategy. After confirming that the new model has taken over stably, the old model process is immediately cut off and computing resources are reclaimed. Only a very small amount of metadata logs are retained for offline evaluation at night, thereby reducing system complexity.

[0083] In the above steps, after enabling the target model to take over subsequent requests, the method further includes: obtaining switching information of the model switch, wherein the switching information includes at least one of the following: triggering reason, switching time and task continuity score during the model switch process; storing the switching information in offline logs, and updating the capability matching matrix table based on the switching information.

[0084] In some embodiments of this application, to achieve closed-loop feedback and continuous optimization of the method, it is necessary to obtain switching information during the model switching process, including the triggering reason, switching time, and task continuity score during the model switching process. The triggering reason can be, for example, scene drift or resource exhaustion; the switching time represents the time spent from issuing the switching command to the target model officially taking over and returning the result. This metric measures the smoothness of the model switching; if the time is too long, it indicates that the warm-up mechanism or scheduling logic needs optimization, or that the target model's startup speed is too slow; the task continuity score measures whether the user experience is interrupted during the model switching process, with a higher score indicating a smoother switching.

[0085] The aforementioned switching information is written to an offline log database for operations and maintenance personnel to analyze the system's operational status. Furthermore, due to the large volume of switching information, it is not suitable to directly update the capability matching matrix table in the real-time user interaction process, as this would affect model response speed. Therefore, it is first stored in the database, and the capability matching matrix table in the model adaptation evaluator is updated based on the switching information during nighttime batch tasks.

[0086] Specifically, based on the switching information, the comprehensive score of the relevant models in the capability matching matrix table is dynamically updated. For example, if the model switching is successful in scenario A and the user is unaware of it, and the switching time is short and the consistency score is high, the basic performance score of the corresponding model in that scenario can be increased; if the model switching fails in scenario B or the user experience is poor, and the switching time is long or the consistency score is low, the basic performance score of the corresponding model in that scenario can be decreased.

[0087] The aforementioned intelligent model automatic orchestration method can run in an intelligent model automatic orchestration system. This system adopts a cloud-edge collaborative architecture design, achieving intelligent model matching and seamless switching while considering system efficiency and resource consumption. The core components of this system include a context feature extractor, a model fit evaluator, an intelligent session manager, and a resource scheduler. The context feature extractor obtains code context information from the programming environment and determines the first scenario corresponding to that context. The model fit evaluator selects the best-performing model from multiple models in the first scenario and establishes an initial session connection with it. The intelligent session manager determines whether model re-evaluation of the first model is necessary during interaction between the target object and the first model by judging the session state. If model re-evaluation is required and the result indicates model switching, the manager sends a switching instruction to the resource scheduler, which switches the first model to the target model. The resource scheduler receives the switching instruction and switches the first model to the target model accordingly.

[0088] The system architecture comprises a context-aware layer, an intelligent control layer, and a model orchestration and resource layer. Specifically, the context-aware layer on the client side is deployed in the user's local IDE plugin and includes a context feature extractor. It is responsible for real-time analysis of the programming environment, extracting the code's syntactic complexity, code style, domain semantics, and task summary through static code analysis techniques, and monitoring model usage.

[0089] The central intelligent control layer includes an intelligent session manager. Relying on data from the context-aware layer, it monitors scene drift and resource levels in real time, proactively initiates re-evaluation requests to the model fit evaluator, and issues switching decisions based on the evaluation results. When making a switching decision through the intelligent session manager, it first receives feedback from the model fit evaluator, and triggers a switching command if any of the following conditions are met:

[0090] Condition 1: Resource-driven: Token consumption reaches a preset safety threshold (e.g., 60%) and the user completes a phased code submission.

[0091] Condition 2: Performance-driven: Receive a "suggested switch" signal from the model fit evaluator (i.e., the current model is no longer optimal).

[0092] After the switching instruction is triggered, the smart session manager sends a seamless switching instruction to the resource scheduler.

[0093] The cloud-based model orchestration and resource layer serves as the cloud-based decision-making hub, comprising a model fit evaluator and a resource scheduler. The model fit evaluator performs rapid matching based on a pre-processed capability matching matrix and dynamically re-evaluates in response to requests from the intelligent session manager; the resource scheduler is responsible for the underlying computing power configuration and seamless switching execution.

[0094] The model fit evaluator employs a responsive mechanism of offline pre-training, online table lookup, and on-demand re-evaluation. It establishes a multi-dimensional capability profile for each large language model integrated into the system through an offline capability matching matrix. The system periodically triggers batch weighted calculation tasks, comprehensively considering four indicators: effective usage time, displayed evaluation score, modification rate, and basic performance score. These four indicators are used to calculate a comprehensive score for each model, which is then used to construct the capability matching matrix. When selecting models, the capability matching matrix allows for rapid selection of the model with the highest comprehensive score and best cost-effectiveness, minimizing real-time computing costs and allowing the system to focus on user experience.

[0095] The resource scheduler is responsible for the optimal allocation of underlying computing power, enabling lightweight, seamless switching and resource reclamation. Through preloading and dual-model verification mechanisms, it reduces model latency and improves the user experience.

[0096] It should be noted that the aforementioned intelligent model automatic orchestration system is used to execute... Figure 2 The intelligent model automatic orchestration method shown above is also applicable to this intelligent model automatic orchestration system, and will not be repeated here.

[0097] The following combination Figure 5 The above system processing flow is illustrated with specific examples, such as... Figure 5 As shown, the specific steps include the following:

[0098] Step 1: Initial Stage (Feature Extraction Stage): The user wakes up the IDE and uses the programming assistant. The system automatically captures the code context information of the current editor through the context feature extractor in the context-aware layer. The Tree-sitter parser identifies the current file as "Python Web Development" and states that a moderately complex view function involving Django ORM is being written, thus obtaining the task intent, i.e., determining the first scenario. The context feature extractor determines the first feature vector corresponding to the code context information and sends it to the model fit evaluator.

[0099] Step 2: Model Selection (Capability Matching): The intelligent session manager initiates an initial matching request to the model fit evaluator. The model fit evaluator receives the first feature vector corresponding to the first scenario, searches in the pre-processed capability matching matrix table, and obtains the model A (e.g., DeepSeek-Coder, i.e., the first model) that has historically performed best or is most suitable for the current first scenario, and automatically establishes an initial session connection.

[0100] Step 3: Session Progression (State Monitoring): The user uses Model A and interacts with it in multiple rounds, gradually refining the code logic. The intelligent session manager monitors the session state in the background, continuously executing two core monitoring tasks: first, tracking the token consumption curve in real time; second, listening to changes in the feature vector output by the context feature extractor.

[0101] Step 4: Switching Assessment: Based on the monitoring results, the intelligent conversation manager assesses the situation along two paths to determine whether a switching command needs to be issued:

[0102] Path A: Scene Drift Scenario (Performance-Driven) Detection: The user suddenly closes a Django view file and opens a data processing script (.py file containing Pandas / Numpy libraries). The intelligent session manager determines that scene drift has occurred through significant changes in feature vectors.

[0103] Evaluation Request: The intelligent session manager immediately sends a re-evaluation request to the model fit evaluator, along with the relevant feature vectors (i.e., the second feature vectors) of the latest "data processing script".

[0104] Evaluation Result 1 (Model Switching or Replacement Required): After querying the capability matching matrix table, the model fit evaluator found that the comprehensive score of Model B, which specializes in data processing (such as Claude-3, i.e., the second model), far exceeded the comprehensive score of the current Model A, and the difference between the two comprehensive scores exceeded the preset difference. The model fit evaluator returned a "Suggest switching to Model B" signal to the intelligent session manager. Upon receiving this signal, the intelligent session manager immediately issued a (first model) switching instruction to the resource scheduler and proceeded to step 5 (seamless switching).

[0105] Evaluation Result 2 (No Model Switching or Replacement Required): After querying the capability matching matrix table, the model fit evaluator finds that model A still has the highest overall score in the new scenario (e.g., model A is an all-around general-purpose model), or the difference between the two overall scores does not reach the preset difference. The model fit evaluator returns a "Maintain Status Quo" signal to the intelligent session manager. The intelligent session manager cancels the switching command, resets the monitoring status, continues to monitor token consumption and the next round of scenario changes, and returns to step 3 (session in progress).

[0106] Path B: Resource Water Level Triggered (Resource-Driven) Detection: The user has been working in the current file without any scene changes or scene drift. However, the intelligent session manager detects that the token usage has reached or exceeded the preset safety water level (e.g., 60%), and judges that the user is at a stage completion point based on the code commit frequency.

[0107] Evaluation Request: The intelligent session manager sends a re-evaluation request to the model fit evaluator, along with the current first feature vector (i.e., the Django web development scenario).

[0108] Evaluation Results: Based on the current scenario, the model fit evaluator queries the capability matching matrix again to confirm that the current model A is still the optimal solution for this scenario (or selects a third model C that is more suitable for long text processing), and returns the evaluation results to the intelligent session manager. Subsequent Process: Upon receiving the evaluation results, if the intelligent session manager determines that the third model is the optimal model, it immediately issues a second model switching instruction to the resource scheduler and proceeds to step 5 (seamless switching). After successful model switching, the monitoring status is reset, and the process returns to step 3. If the evaluation results indicate that the first model is the optimal model, no model switching is required.

[0109] Step 5: Seamless Switching: The resource scheduler silently launches a container instance of the target model (B or C) in the background and loads the first feature vector. When the user initiates a new round of interaction requests, the system simultaneously distributes the interaction request to both the old model A and the target model. If the target model successfully returns a coherent response, it officially takes over the task. After a successful switch, the system directly releases all resources of model A in the background. If the switch fails (i.e., the target model has errors or timeouts), it automatically switches back to model A.

[0110] Step 6: Continuous optimization (closed-loop feedback): After the target model takes over, the system will record the triggering reason (scene drift / resource exhaustion), time consumption, and task continuity score of this switch into the offline log, and update the capability matching matrix table of the model fitness evaluator in the night batch task.

[0111] The intelligent model automatic orchestration method provided in this application adopts a cloud-edge collaborative architecture. It monitors changes in the programming scenario in real time on the edge and establishes a pre-calculated capability matching matrix in the cloud. Real-time model optimization and matching are achieved through scenario drift monitoring and dynamic re-evaluation mechanisms. This approach breaks through the traditional fixed-rule model matching mode and, by introducing a four-dimensional capability evaluation model (user stickiness, explicit evaluation, code quality, and baseline performance), achieves accurate model capability profiling. This allows for real-time perception of changes in the user's programming scenario, automatic model re-evaluation and matching decisions, significantly improving the timeliness and accuracy of model selection and adapting to rapidly changing programming task requirements.

[0112] Furthermore, the intelligent model automatic orchestration method in this embodiment establishes a dual-drive switching triggering mechanism based on scene drift and resource level to achieve smooth and seamless intelligent prediction switching, ensuring the continuity of the user's programming thinking; when performing model switching, it optimizes resource allocation efficiency, reduces system operation and maintenance costs, ensures zero-perception and high reliability of the switching process, ensures switching success rate, and avoids service interruption through dual-model parallel verification and UI idle window switching strategies; and adopts a resource reclamation mechanism to reduce system complexity.

[0113] Figure 6 This is a structural diagram of an intelligent model automatic arrangement device according to an embodiment of this application, such as... Figure 6 As shown, the device includes:

[0114] The acquisition module 60 is used to acquire code context information in the programming environment and determine the first scenario corresponding to the code context information;

[0115] The determination module 62 is used to determine the first model that performs best in the first scenario from multiple models, and to establish an initial session connection with the first model.

[0116] The switching module 64 is used to determine whether the first model needs to be re-evaluated by judging the session state during the interaction between the target object and the first model. If the model needs to be re-evaluated and the result of the model re-evaluation is that model switching is required, the first model is switched to the target model.

[0117] Through the acquisition module, determination module, and switching module in the aforementioned intelligent model automatic orchestration device, the goal of matching the model with the current changing programming scenario in real time and accurately is achieved, thereby improving the programming experience and efficiency. This solves the technical problem in related technologies where programming assistants rely on preset rules or simple matching for model selection decisions, lacking real-time perception of dynamic programming scenarios.

[0118] In the aforementioned determining module, this module is further used to obtain the effective usage time of multiple models, where the effective usage time represents the cumulative time spent by the models in coding work under different types of scenarios; obtain the display evaluation scores of multiple models, where the display evaluation scores represent the target object's satisfaction rating with the code generated by the models; obtain the modification rates of multiple models, where the modification rate represents the proportion of code generated by the models that has been adjusted by the target object; obtain the basic performance scores of multiple models, where the basic performance scores represent the inherent performance of the models in standard tests; perform a weighted summation of the effective usage time, display evaluation scores, modification rates, and basic performance scores of the target object to obtain the comprehensive score corresponding to multiple models; determine the capability matching matrix table based on the comprehensive scores corresponding to multiple models; and query the first model that performs best in the first scenario from the capability matching matrix table.

[0119] In the aforementioned switching module, the switching module is also used to obtain the first feature vector corresponding to the code context information, and to obtain the second feature vector during the interaction between the target object and the first model; determine the similarity between the first feature vector and the second feature vector; if the similarity is less than the feature threshold, determine that there is scene drift in the session; if no scene drift occurs, obtain the resource level during the interaction between the target object and the first model; if the resource level exceeds the preset safety level and the target object completes the stage code submission, or if scene drift occurs, perform model re-evaluation on the first model.

[0120] In the aforementioned switching module, the module is further configured to, in the event of scene drift, determine the second model corresponding to the second feature vector from the capability matching matrix table, and determine the first comprehensive score and the second comprehensive score of the first model and the second model respectively from the capability matching matrix table, wherein the capability matching matrix table stores the comprehensive scores of multiple models corresponding to different types of scenes; determine the difference between the second comprehensive score and the first comprehensive score, and if the difference is greater than a preset difference, determine that model switching is required and generate a first model switching instruction, wherein the first model switching instruction is to switch the first model to the second model and determine the second model as the target model; if the difference is less than or equal to the preset difference, determine that model switching is not required.

[0121] In the aforementioned switching module, the module is further configured to, under the conditions that no scene drift has occurred, the resource level exceeds the preset safety level, and the target object has completed the phased code submission, query the capability matching matrix table again based on the first scene to obtain the query results. The capability matching matrix table stores the comprehensive scores of multiple models corresponding to different types of scenes. If the query results indicate that the first model is the optimal model for the first scene, it is determined that no model switching is required. If the query results indicate that the third model is the optimal model for the first scene, it is determined that a model switching is required, and a second model switching instruction is generated. The second model switching instruction switches the first model to the third model and identifies the third model as the target model.

[0122] In the aforementioned switching module, the switching module is further configured to: after the target object has completed rendering through its previous interaction with the first model and before the next interaction request is initiated, start a container instance of the target model and load the first feature vector corresponding to the code context information into the container instance; obtain the next interaction request initiated by the target object and distribute the next interaction request to both the first model and the target model; if the target model handles the next interaction request without errors and responds normally, enable the target model to take over subsequent requests and release all resources of the first model; if the target model handles the next interaction request with errors or timeouts, automatically fall back to the first model to continue executing the next interaction request.

[0123] In the aforementioned switching module, the switching module is also used to obtain switching information when a model switching occurs, wherein the switching information includes at least one of the following: triggering reason, switching time, and task continuity score during the model switching process; the switching information is stored in the offline log, and the capability matching matrix table is updated based on the switching information.

[0124] It should be noted that, Figure 6 The intelligent model automatic orchestration device shown is used to perform Figure 2 The intelligent model automatic arrangement method shown above is also applicable to this intelligent model automatic arrangement device, and will not be repeated here.

[0125] This application also provides an electronic device, which includes a memory and a processor. The memory is used to store program instructions. The processor is connected to the memory and is used to execute program instructions that perform the following functions: obtaining code context information in a programming environment and determining a first scenario corresponding to the code context information; determining a first model that performs best in the first scenario from multiple models and establishing an initial session connection with the first model; during the interaction between the target object and the first model, determining whether the first model needs to be re-evaluated by judging the session state; and if model re-evaluation is required and the result of model re-evaluation is that model switching is required, switching the first model to the target model.

[0126] It should be noted that the aforementioned electronic equipment is used to perform Figure 2 The intelligent model automatic arrangement method shown above is also applicable to this electronic device, and will not be repeated here.

[0127] This application embodiment also provides a non-volatile storage medium, which includes a stored computer program. The device where the non-volatile storage medium is located executes the following intelligent model automatic orchestration method by running the computer program: obtaining code context information in the programming environment and determining a first scenario corresponding to the code context information; determining the first model that performs best in the first scenario from multiple models and establishing an initial session connection with the first model; during the interaction between the target object and the first model, determining whether the first model needs to be re-evaluated by judging the session state; if model re-evaluation is required and the result of model re-evaluation is that model switching is required, switching the first model to the target model.

[0128] It should be noted that the aforementioned non-volatile storage media is used for execution. Figure 2 The intelligent model automatic orchestration method shown above is also applicable to this non-volatile storage medium, and will not be repeated here.

[0129] This application also provides a computer program product, including computer instructions that, when executed by a processor, implement the steps of the intelligent model automatic orchestration method in various embodiments of this application.

[0130] This application also provides a computer program that, when executed by a processor, implements the steps of the intelligent model automatic arrangement method in various embodiments of this application.

[0131] The sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0132] In the above embodiments of this application, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0133] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. The device embodiments described above are merely illustrative; for example, the division of units can be a logical functional division, and in actual implementation, there may be other division methods. For instance, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual coupling, direct coupling, or communication connection may be through some interfaces; the indirect coupling or communication connection between units or modules may be electrical or other forms.

[0134] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0135] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0136] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard drive, magnetic disk, or optical disk.

[0137] The above description is only a preferred embodiment of this application. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. A method for automatically arranging intelligent models, characterized in that, include: Obtain code context information in the programming environment and determine the first scenario corresponding to the code context information; Determine the first model that performs best in the first scenario from multiple models, and establish an initial session connection with the first model; During the interaction between the target object and the first model, the system determines whether the first model needs to be re-evaluated by judging the session state. If the model needs to be re-evaluated and the result of the model re-evaluation is that the model needs to be switched, the first model is switched to the target model. The switching instruction is triggered when any of the following conditions are met: no scene drift occurs, but the token consumption is detected to reach the preset safety level and the user completes the stage code submission; or in the scene drift scenario detection, a suggested switching signal is received from the model fit evaluator.

2. The method according to claim 1, characterized in that, The first model that performs best in the first scenario is determined from multiple models, including: Obtain the effective usage time of multiple models, wherein the effective usage time is used to represent the cumulative usage time of the models for encoding work in different types of scenarios; Obtain the display evaluation scores of multiple models, wherein the display evaluation scores are used to represent the target object's satisfaction rating with the code generated by the model; Obtain the modification rate of multiple models, wherein the modification rate is used to represent the proportion by which the code generated by the model is adjusted by the target object; Obtain the baseline performance scores of multiple models, wherein the baseline performance scores are used to represent the inherent performance of the models in standard tests; The effective usage time of the target object, the display evaluation score, the modification rate, and the basic performance score are weighted and summed to obtain the comprehensive score corresponding to multiple models. The capability matching matrix table is determined based on the comprehensive scores corresponding to the multiple models; The first model that performs best in the first scenario is retrieved from the capability matching matrix table.

3. The method according to claim 1, characterized in that, Determining whether the first model needs to be re-evaluated by judging the session state includes: Obtain the first feature vector corresponding to the code context information, and obtain the second feature vector during the interaction between the target object and the first model; Determine the similarity between the first feature vector and the second feature vector; If the similarity is less than the feature threshold, it is determined that the session has scene drift; In the absence of scene drift, obtain the resource level during the interaction between the target object and the first model; If the resource level exceeds the preset safety level and the target object completes a phased code submission, or if scene drift occurs, the first model will be re-evaluated.

4. The method according to claim 3, characterized in that, After re-evaluating the first model, the method further includes: In the event of scene drift, a second model corresponding to the second feature vector is determined from the capability matching matrix table, and a first comprehensive score and a second comprehensive score of the first model and the second model are determined from the capability matching matrix table respectively. The capability matching matrix table stores the comprehensive scores of multiple models in different types of scenes. The difference between the second comprehensive score and the first comprehensive score is determined. If the difference is greater than a preset difference, it is determined that a model switch is required, and a first model switch instruction is generated. The first model switch instruction is to switch the first model to the second model and determine the second model as the target model. If the difference is less than or equal to the preset difference, it is determined that no model switching is required.

5. The method according to claim 3, characterized in that, After re-evaluating the first model, the method further includes: If no scene drift occurs, the resource level exceeds the preset safety level, and the target object completes the phased code submission, the capability matching matrix table is queried again based on the first scene to obtain the query result. The capability matching matrix table stores the comprehensive scores of multiple models in different types of scenes. If the query results indicate that the first model is the optimal model for the first scenario, it is determined that no model switching is required. If the query result indicates that the third model is the optimal model for the first scenario, it is determined that a model switch is required, and a second model switch instruction is generated, wherein the second model switch instruction is to switch the first model to the third model and determine the third model as the target model.

6. The method according to claim 1, characterized in that, If the model re-evaluation result indicates that a model switch is required, the first model will be switched to the target model, including: After the target object has completed rendering after interacting with the first model in the previous time, and before the next interaction request is initiated, the container instance of the target model is started, and the first feature vector corresponding to the code context information is loaded into the container instance; Obtain the next interaction request initiated by the target object, and simultaneously distribute the next interaction request to the first model and the target model; If the target model handles the next interaction request without errors and responds normally, the target model is enabled to take over subsequent requests, and all resources of the first model are released. If the target model encounters an error or timeout in processing the next interaction request, it will automatically fall back to the first model to continue executing the next interaction request.

7. The method according to claim 6, characterized in that, After enabling the target model to take over subsequent requests, the method further includes: Obtain switching information when a model switch occurs, wherein the switching information includes at least one of the following: triggering reason, switching time, and task continuity score during the model switch process; The switching information is stored in the offline log, and the capability matching matrix table is updated based on the switching information.

8. An intelligent model automatic arrangement device, characterized in that, include: The acquisition module is used to acquire code context information in the programming environment and determine the first scenario corresponding to the code context information; The determination module is used to determine the first model that performs best in the first scenario from multiple models, and to establish an initial session connection with the first model. The switching module is used to determine whether the first model needs to be re-evaluated by judging the session state during the interaction between the target object and the first model. If model re-evaluation is required and the result of the model re-evaluation is that model switching is required, the first model is switched to the target model. The switching instruction is triggered when any of the following conditions are met: no scene drift occurs, but the token consumption is detected to reach the preset safety water level and the user completes the stage code submission; or in the scene drift scenario detection, a suggested switching signal is received from the model adaptability evaluator.

9. An intelligent model automatic arrangement system, characterized in that, include: The system comprises a context feature extractor, an intelligent session manager, a model fit evaluator, and a resource scheduler. The context feature extractor is used to obtain code context information in the programming environment and determine the first scenario corresponding to the code context information; The model fit evaluator is used to determine the first model that performs best in the first scenario from multiple models, and to establish an initial session connection with the first model. The intelligent session manager is used to determine whether the first model needs to be re-evaluated by judging the session state during the interaction between the target object and the first model. If model re-evaluation is required and the result of the model re-evaluation is that model switching is required, a switching instruction is sent to the resource scheduler. The switching instruction is used to switch the first model to the target model. The switching instruction is triggered when any of the following conditions are met: no scene drift occurs, but token consumption is detected to reach a preset safety level and the user completes a phased code submission; or in the scene drift scenario detection, a suggested switching signal is received from the model fit evaluator. The resource scheduler is used to receive the switching instruction and switch the first model to the target model according to the switching instruction.

10. An electronic device, characterized in that, include: Memory, used to store program instructions; The processor, connected to the memory, is configured to execute program instructions that perform the following functions: acquire code context information in a programming environment and determine a first scenario corresponding to the code context information; determine a first model that performs best in the first scenario from multiple models and establish an initial session connection with the first model; During the interaction between the target object and the first model, the system determines whether the first model needs to be re-evaluated by judging the session state. If the model needs to be re-evaluated and the result of the model re-evaluation is that the model needs to be switched, the first model is switched to the target model. The switching instruction is triggered when any of the following conditions are met: no scene drift occurs, but the token consumption is detected to reach the preset safety level and the user completes the stage code submission; or in the scene drift scenario detection, a suggested switching signal is received from the model fit evaluator.

11. A non-volatile storage medium, characterized in that, The non-volatile storage medium includes a stored computer program, wherein the device containing the non-volatile storage medium executes the intelligent model automatic arrangement method according to any one of claims 1 to 7 by running the computer program.

12. A computer program product comprising computer instructions, characterized in that, When the computer instructions are executed by the processor, they implement the intelligent model automatic arrangement method according to any one of claims 1 to 7.

Images