A plug-in management method, device and equipment based on a pre-trained language model and a storage medium

Abstract

The application discloses a plug-in management method and device based on a pre-trained language model, computer equipment and a storage medium. The method comprises the following steps: acquiring a plug-in list; if a query request is received, sending the query request and configuration information of available plug-ins in the updated plug-in list to the pre-trained language model; the pre-trained language model generates an output result according to the query request and the configuration information, and judges whether the output result contains a calling instruction; if the output result contains the calling instruction, the target plug-in is called according to the calling instruction, the execution result of the target plug-in is obtained, and the execution result is returned to the pre-trained language model; the pre-trained language model generates a processing result based on the execution result and the output result and returns the processing result; if the output result does not contain the calling instruction, the pre-trained language model returns the output result as the processing result; by the method, different platforms can be adapted, and the plug-in extensibility can be improved.

Description

Technical Field

[0001] The present application relates to the technical field of plug-in natural language processing, and in particular to a plug-in management method, apparatus, device, and storage medium based on a pre-trained language model. Background Art

[0002] Pretrained language models (LLMs) are a core technology in the field of natural language processing. Based on a deep learning neural network architecture and trained on large-scale text data, they possess the ability to understand, generate, and process natural language. The Transformer architecture, which enables efficient parallel computing and long-range dependency modeling through a self-attention mechanism, serves as the foundation of LLMs. Subsequent models such as BERT, the GPT series, and T5 have further improved their performance in tasks such as text generation, classification, and translation through a pretraining-fine-tuning paradigm. In recent years, plug-ins have become a key means of expanding the functionality of LLMs. By integrating external tools and resources, they have significantly enhanced the model's flexibility and industry adaptability, enabling it to meet diverse application needs.

[0003] Currently, LLMs implement functional expansion through a plug-in system, allowing developers to add or modify functional modules without retraining the model. The plug-in system typically includes plug-in registration, configuration management, and a call interface, allowing the model to dynamically load external functions. For example, plug-ins can implement tasks in specific fields, such as medical diagnosis or financial analysis, and interact with the model through APIs or functional interfaces. In existing technologies, plug-in implementation relies on standardized interface specifications and configuration templates. The model parses the intent of the user query, matches the appropriate plug-in, calls its function, and ultimately feeds the results back to the user. This mechanism supports functional reuse across models, reduces development costs, and improves update efficiency.

[0004] While plugin systems offer significant advantages for LLMs, challenges remain. Compatibility is a major bottleneck. Architectural differences between different models can prevent plugins from being universal, limiting their cross-platform applicability. Plugin scalability is limited. Existing systems often rely on pre-built plugins, resulting in high development and integration costs for new plugins and difficulty in quickly responding to new requirements. Furthermore, data interaction between plugins and models can be inefficient or erroneous due to non-standard interfaces or inaccurate semantic matching, impacting system stability. Summary of the Invention

[0005] Based on this, it is necessary to provide a plug-in management method, device, equipment and storage medium based on a pre-trained language model that can adapt to different platforms and improve the scalability of plug-ins to address the above technical problems.

[0006] In a first aspect, a plug-in management method based on a pre-trained language model is provided, comprising:

[0007] Get the plugin list;

[0008] In response to receiving the query request, sending the query request and configuration information of available plug-ins in the updated plug-in list to the pre-trained language model;

[0009] The pre-trained language model generates output results based on the query request and configuration information and determines whether the output results contain call instructions;

[0010] In response to the output result containing a call instruction, calling the target plug-in according to the call instruction, obtaining the execution result of the target plug-in, and returning the execution result to the pre-trained language model. The pre-trained language model generates a processing result based on the execution result and the output result and returns it;

[0011] In response to the output result not including the call instruction, the pre-trained language model returns the output result as a processing result.

[0012] In a second aspect, a plug-in management device based on a pre-trained language model is provided, which is applied to a plug-in management method based on a pre-trained language model described in the first aspect, including:

[0013] Get module, used to get the plug-in list;

[0014] a query module configured to, in response to receiving a query request, send the query request and configuration information of available plug-ins in the updated plug-in list to the pre-trained language model;

[0015] The judgment module is used to pre-train the language model, generate output results based on query requests and configuration information, and determine whether the output results contain call instructions;

[0016] The first result submodule is configured to, in response to the output result containing a call instruction, call the target plug-in according to the call instruction, obtain the execution result of the target plug-in, and return the execution result to the pre-trained language model. The pre-trained language model generates a processing result based on the execution result and the output result and returns it;

[0017] The second result submodule is configured to return the output result as a processing result in response to the output result not containing a call instruction.

[0018] In the third aspect, a computer device is also provided, including a memory, a processor, and a computer program stored in the memory and runnable on the processor. When the processor executes the computer program, the plug-in management method based on the pre-trained language model recorded in the first aspect is implemented.

[0019] In a fourth aspect, a computer-readable storage medium is provided, on which a computer program is stored. When the computer program is executed by a processor, the plug-in management method based on the pre-trained language model recorded in the first aspect is implemented.

[0020] By implementing the aforementioned plug-in management method, apparatus, device, and storage medium based on a pre-trained language model, this method introduces a unified plug-in registration mechanism and a standardized plug-in configuration information management system to enable dynamic registration and automatic updates of plug-ins. This avoids the existing problem of plug-ins being limited to pre-installed and difficult to expand in existing systems, significantly improving the system's adaptability and scalability to new plug-ins. Furthermore, when responding to user queries, the system not only inputs the natural language query but also the currently active plug-in configuration information into the pre-trained language model, which then performs unified intent understanding and plug-in matching. This fundamentally addresses the inaccurate plug-in invocation issues caused by inconsistent interface standards or weak semantic adaptation capabilities in traditional methods. This solution enables the pre-trained language model to have deep understanding of plug-in functions and intelligent invocation capabilities, significantly improving the efficiency of data exchange and the accuracy of invocations between plug-ins and the model. Furthermore, the invocation logic in the method distinguishes between cases where invocation instructions are included, enabling flexible response to different query scenarios, supporting both direct response-based questions and answers and capability-expansion-based operation requests, enhancing the system's intelligent responsiveness and versatility. This method shields the differences between different model architectures through a structured plug-in calling process, reduces the migration and reuse costs of plug-ins on multiple pre-trained language model platforms, and effectively breaks through the limitations of poor cross-platform compatibility of existing plug-in systems. BRIEF DESCRIPTION OF THE DRAWINGS

[0021] In order to more clearly illustrate the embodiments of the present application, the following is a brief introduction to the drawings required for use in the embodiments. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0022] Figure 1 A flowchart of a plug-in management method based on a pre-trained language model provided in an embodiment of the present application;

[0023] Figure 2 A structural block diagram of a plug-in management device based on a pre-trained language model provided in an embodiment of the present application;

[0024] Figure 3 A plug-in calling flow chart of a plug-in management method based on a pre-trained language model provided in an embodiment of the present application;

[0025] Figure 4A flowchart of creating a plug-in for a plug-in management method based on a pre-trained language model provided in an embodiment of the present application;

[0026] Figure 5 A diagram showing the overall plug-in architecture of a plug-in management method based on a pre-trained language model provided in an embodiment of the present application;

[0027] Figure 6 This is a diagram of the internal structure of a computer device in an embodiment of the present application. DETAILED DESCRIPTION

[0028] The following will be combined with the accompanying drawings in the embodiments of this application to clearly and completely describe the technical solutions in the embodiments of this application. Obviously, the embodiments described are only part of the embodiments of this application, not all of them. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.

[0029] It should be noted that, in the description of this application, the terms "comprises," "includes," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or system comprising a series of elements includes not only those elements, but also other elements not explicitly listed, or elements inherent to such process, method, article, or system. The terms "first," "second," etc., in this application are used to distinguish similar objects, and are not used to describe a particular order or sequence.

[0030] In order to enable those skilled in the art to better understand the present application, the present application is further described in detail below with reference to the accompanying drawings and specific implementation methods.

[0031] In one embodiment, Figure 1 As shown, a plug-in management method based on a pre-trained language model is provided, including:

[0032] S100: Get the plug-in list;

[0033] S200: In response to receiving the query request, sending the query request and configuration information of available plug-ins in the updated plug-in list to the pre-trained language model;

[0034] S300: The pre-trained language model generates an output result based on the query request and configuration information and determines whether the output result contains a call instruction;

[0035] S400: In response to the output result including a call instruction, calling the target plug-in according to the call instruction, obtaining an execution result of the target plug-in, and returning the execution result to the pre-trained language model. The pre-trained language model generates a processing result based on the execution result and the output result and returns the result.

[0036] S500: In response to the output result not including the call instruction, the pre-trained language model returns the output result as a processing result.

[0037] Among them, the plug-in list refers to the collection of all plug-ins currently registered in the system and available for selection and invocation by the pre-trained language model. Each plug-in in the list contains its unique identifier, function description, invocation interface information, and enabled status and other configuration information; plug-in configuration information: structured data describing the behavior and invocation method of the plug-in, including the plug-in name, function summary, input and output parameter templates, interface URL, etc., used to support plug-in matching and function docking; invocation instruction: refers to the structured or semi-structured command contained in the generated response of the pre-trained language model, which is used to instruct the invocation of a specific plug-in to perform a function, usually including the target plug-in identifier and invocation parameters; target plug-in: in this embodiment, refers to the plug-in that is determined to need to be called to perform a specific task based on the matching of the user's query intention and configuration information.

[0038] Specifically, the system first dynamically retrieves a plug-in list, which records all currently registered plug-ins and their configuration information. Upon receiving a user's natural language query, the system does not directly process the query request with the model. Instead, it sends the query request, along with the configuration information of the available plug-ins in the updated plug-in list, to the pre-trained language model. This enables the pre-trained language model to understand the query content while also being able to perceive the plug-in capability boundaries and interface parameters, thereby enhancing its adaptability in multi-plug-in environments and the accuracy of command generation. This overcomes the limitations of existing technologies, which often result in inaccurate or failed calls due to a lack of semantic linkage between the model and plug-ins. The pre-trained language model generates an output based on the input and further determines whether it contains a call instruction. If a call instruction is included, the system identifies the target plug-in and calls its functional interface, obtaining the execution result returned by the plug-in. This execution result is then fed back to the pre-trained language model and further fused with the original model output to generate the final response content, ensuring consistency in the call context and integrity of the response content. If the output does not contain a call instruction, the model directly returns the generated result, avoiding redundant plug-in calls and improving response efficiency. Through the above mechanism, not only the instant registration, dynamic update and efficient management of plug-ins are achieved, but also an interactive mechanism with high coupling, low latency and strong semantic collaboration is constructed between the pre-trained language model and the plug-in system. It effectively solves the technical difficulties of the existing plug-in system in multi-model environment, such as weak compatibility, poor scalability and low calling accuracy, and significantly improves the system's adaptability and intelligent service capabilities in multiple fields and complex tasks, and has good engineering feasibility and promotion prospects.

[0039] In one embodiment, it further includes:

[0040] In response to receiving a plug-in registration request, registering a new plug-in and updating a plug-in list;

[0041] Send an interface request to the backend by calling the plug-in registration interface;

[0042] In response to receiving the registration instruction information returned by the back end, judging the registration instruction information;

[0043] In response to the registration indication information indicating that the registration has failed, an error message is fed back and the current registration operation is terminated;

[0044] In response to the registration indication information indicating that the registration is successful, the information of the new plug-in is added to the plug-in list.

[0045] Among them, plug-in registration request: a request initiated by the plug-in developer or the system server, used to register a new plug-in and its configuration information into the plug-in management system so that the plug-in can be subsequently identified, enabled and called; plug-in registration interface: a server-side API or communication channel used to submit the plug-in configuration information to the back-end system for registration, usually supporting RESTful API, GraphQL or RPC; registration indication information: response data returned by the back-end system to indicate whether the plug-in registration is successful, usually including fields such as status code, prompt information and plug-in identification; error information: in this embodiment, when the plug-in registration fails, the system generates and feeds back the prompt information to the user or caller, used to indicate the reason for the failure, which may include missing fields, interface abnormalities, insufficient permissions, etc.

[0046] Specifically, by introducing a standardized plug-in registration process, the system effectively solves the problems of plug-in registration relying on manual configuration, unclear error feedback, and asynchronous plug-in status in the existing plug-in system, further improving the robustness and expansion efficiency of the plug-in system. Specifically, after receiving the plug-in registration request, the system first calls the plug-in registration interface to send the plug-in's metadata to the back-end system, ensuring that all plug-in registration operations are processed through a unified interface, with consistency and auditability. After the registration interface call is completed, the system makes a judgment based on the registration instruction information returned by the back-end: if the registration fails, the system immediately feedbacks the error information and terminates the current registration process to avoid system abnormalities due to incomplete plug-in information or incorrect parameter configuration; if the registration is successful, the new plug-in information is automatically written to the plug-in list to complete the dynamic addition of the plug-in. This automated registration mechanism significantly improves the real-time nature of plug-in management and the automation level of the system, reduces the cost of human intervention, and ensures that the plug-in list is always up-to-date, thereby providing accurate and reliable basic information for subsequent pre-trained language model matching and plug-in calls. Through this process, the system can quickly deploy and launch plug-ins with higher efficiency and lower error rate. It is particularly suitable for intelligent system scenarios with multiple plug-ins and frequent updates, and enhances the platform's sustainable expansion capabilities and service response capabilities.

[0047] In one embodiment, in response to the registration indication information indicating that the registration is successful, the information of the new plug-in is added to the plug-in list, including:

[0048] In response to the new plug-in being successfully registered, the functional interface of the new plug-in is called to test the availability of the new plug-in;

[0049] In response to a successful test, the plug-in is written into the plug-in list and the plug-in list is updated;

[0050] In response to a test failure, the system returns to the initial state of the plug-in configuration and provides test failure information.

[0051] Among them, the functional interface refers to the calling entry exposed by the plug-in for executing its specific functions, which usually exists in the form of an API, such as an HTTP interface, RPC service or local method, allowing other systems or modules to call plug-in functions through this interface; usability testing refers to the verification of the functional interface of the newly registered plug-in to confirm that the plug-in can be called normally and can return expected results; this test usually includes interface connectivity testing, parameter response verification and exception handling mechanism inspection, etc.; the initial state of the plug-in configuration refers to the default configuration state before the plug-in is registered, which has not yet been written to the plug-in list and has not been recognized or used by the pre-trained language model. It is used to fall back when the plug-in test fails and keep the system running stably.

[0052] Specifically, building on the existing plug-in registration process, a post-registration availability verification mechanism is introduced to ensure that when integrating a new plug-in, the system not only completes the formal registration but also verifies its actual functional availability, thereby significantly improving the stability of the system and the reliability of plug-in calls. When a new plug-in is successfully registered, the system automatically calls the functional interface exposed by the plug-in to perform a standardized availability test to verify whether the plug-in can be called normally and returns a valid response. If the test passes, it means that the plug-in is running normally in the current environment and has actual functional capabilities. The system will then write its information to the plug-in list and update the overall plug-in status, officially including it in the range of plug-ins that can be scheduled by the pre-trained language model. If the test fails, the system will immediately terminate the activation process of the plug-in and restore its configuration to its initial state. At the same time, it will feedback the test failure information, prompting the developer or management end to repair it. Through this mechanism, the system effectively avoids including unstable or unavailable plug-ins in the schedulable range, prevents subsequent call failures or output errors due to plug-in anomalies, and ensures the overall controllability and robustness of the plug-in management system.

[0053] In one embodiment, in response to the successful registration of the new plug-in, the functional interface of the new plug-in is called to test the availability of the new plug-in, including:

[0054] Get the response data of the functional interface, which includes: response status and response data structure, and determine whether the new plug-in is available based on the response status and response data structure;

[0055] If the response status of the function interface is successful and the response data structure contains the preset fields, the new plug-in is available;

[0056] If the response status of the functional interface is failure, or the response data structure does not contain the preset fields, the new plug-in is not available.

[0057] Among them, response data refers to the information content returned after calling the plug-in function interface, including the status code of the interface call, response time, return results, etc., which is used to determine whether the interface is operating normally and whether the plug-in function is executed successfully; response status refers to a part of the response data, which is used to identify the result status of the function interface call, such as the HTTP status code (such as 200 for success, 500 for server error), or an internally agreed status flag to determine whether the plug-in service is reachable; response data structure refers to the organizational form or field content structure of the specific data returned by the function interface, such as JSON, XML or structured objects, which contains specific information about the execution results of the plug-in function; preset fields refer to key fields pre-set by the system, which are used to verify the integrity and compliance of the plug-in response data; preset fields represent whether the plug-in function has returned the core content as expected, such as the result set, status description or key data identifier.

[0058] Specifically, after a new plug-in is successfully registered, the system will immediately call the plug-in's functional interface and obtain the response data it returns. First, it will determine whether the interface call is successful based on the response status. If the response status is failure, it indicates that the plug-in is currently unavailable, and the system can directly terminate the plug-in activation process and feedback an error message. If the response status is successful, the system will further verify the content of the response data structure to confirm whether it contains key fields preset by the system, such as function return value, business identifier or data summary. Only when both conditions are met at the same time, that is, the interface response is successful and the data structure meets the preset specifications, will the plug-in be identified as an available plug-in and included in the plug-in list. In this way, the system can effectively screen out plug-ins with "false success" situations, that is, plug-ins whose interface response is successful but the returned content is incomplete or malformed, thereby ensuring the callability and correctness of the plug-in in real business scenarios. It can capture deep-seated problems such as potential data structure anomalies and missing fields, and prevent functionally abnormal plug-ins from entering the system and causing operational failures.

[0059] In one embodiment, in response to receiving a plug-in registration request, registering a new plug-in and updating a plug-in list further includes:

[0060] In response to receiving a function expansion instruction for any plug-in in the plug-in list, modifying a parameter definition template of the plug-in, wherein the updated plug-in list includes at least one of the following: a built-in plug-in and a new plug-in;

[0061] Update the configuration information of the plug-in based on the modified parameter definition template, overwrite the original plug-in configuration information, activate the plug-in, and update the plug-in list.

[0062] Among them, function extension instructions refer to the system's operational instructions for enhancing or changing the functions of a plug-in, which may come from users, system policies or automatic adaptation mechanisms, and are used to trigger modifications to the plug-in parameter structure, functional scope or behavioral logic; parameter definition templates refer to standardized definition files or data structures used by plug-ins to describe their calling parameter structures, which usually contain information such as parameter name, parameter type, whether it is required, default value, etc., and are the basic constraint format for plug-in configuration and calling; built-in plug-ins refer to plug-in modules that are preset and exist by default in the system, and are usually used to provide core common functions such as search, calculation, data conversion, etc., as opposed to "new plug-ins" registered by users later; plug-in activation refers to the plug-in officially entering the callable state after completing the registration, configuration and verification processes, so that it can be recognized by the pre-trained language model and scheduled to participate in processing user requests.

[0063] Specifically, when the system receives a function expansion instruction for a plug-in, it modifies the plug-in's parameter definition template, expanding or adjusting its parameter structure to accommodate new business requirements or external call methods. For example, this can include adding parameter fields, adjusting data types, or updating parameter default values. This modification applies not only to user-defined plug-ins but also to built-in and newly added plug-ins, ensuring a unified system extension mechanism. After the parameter definition template is updated, the system regenerates and overwrites the original plug-in's configuration information based on the new template, ensuring that the plug-in call process is consistent with the latest functional structure. The plug-in is reactivated, completing the entire process from configuration change to call readiness. The updated plug-in is added to the plug-in list, forming a plug-in collection that is maintained and dynamically adapted in real time. This process significantly enhances the flexibility of the plug-in system, avoiding functional bottlenecks caused by rigid plug-in structures and enabling the system to quickly respond to external environmental changes and iterative user needs. Through this mechanism, the system can implement plug-in enhancements and configuration upgrades without interrupting service, avoiding the operational and maintenance burden of frequent plug-in uninstallation and reinstallation, and eliminating the risk of system crashes due to plug-in format incompatibilities. This makes it particularly suitable for high-availability, highly interactive intelligent service platforms.

[0064] In one embodiment, Figure 4 As shown, in response to receiving the query request, the query request and the available plug-in configuration information are sent to the pre-trained language model, including:

[0065] Get the current enabled status of each plug-in;

[0066] According to the current plug-in activation status, the currently activated plug-in is obtained from the plug-in list to form a plug-in information subset, which includes: a plug-in function description field and a plug-in parameter definition field;

[0067] Perform semantic analysis on the query request text to extract the intent information and preset parameters;

[0068] Convert intent information and preset parameters into embedding vectors;

[0069] Perform vector conversion on the plug-in function description field and the plug-in parameter definition field to generate a plug-in vector;

[0070] Compute a matching score based on the semantic similarity between the embedding vector and the plugin vector;

[0071] Filter out plug-ins with a matching degree higher than a preset threshold based on the matching score to form a candidate plug-in set;

[0072] Determine matching plug-ins based on the plug-in priority and historical call information in the candidate plug-in set;

[0073] Build structured input data based on matching plug-ins and query requests;

[0074] Load structured input data into a pre-trained language model.

[0075] Among them, the plug-in information subset refers to the set of plug-ins that are currently activated and filtered according to the plug-in activation status, and only contains plug-in information that can be called and participate in the current query processing; semantic parsing refers to the in-depth understanding and processing of natural language query text, extracting structured semantic information such as intent, entities, parameters, etc. for subsequent processing; embedding vector refers to the high-dimensional numerical representation obtained by converting natural language text through a specific model (such as the embedding layer in the language model), which can capture the semantic features of the text and facilitate semantic similarity calculation and matching; plug-in configuration field refers to the key fields in the plug-in configuration information, such as plug-in name, function description, input parameters, output format, etc., which are used for semantic matching with query intent; structured input data refers to the data representation of the query intent and target plug-in information organized into a unified format after semantic matching and screening, which is convenient for input into the pre-trained language model for reasoning or task generation.

[0076] Specifically, after receiving a user query, the system checks the status of the current plug-in list and selects only active plug-ins to form a plug-in information subset. This prevents invalid plug-ins from participating in subsequent matching, ensuring system efficiency and accuracy. The system then performs semantic parsing on the query text to extract the user's true intent and related parameters, such as the operation goal, constraints, and expected result type. This information is further processed and converted into an embedding vector, which serves as input for semantic computation. The system then matches the query embedding vector with the configuration fields of each plug-in in the plug-in information subset, assessing their semantic relevance and generating matching results. This matching process relies not only on keywords but also on deep semantic features, enabling it to identify situations with similar meanings despite different expressions, significantly enhancing the intelligence of plug-in selection. Based on the matching results, the system constructs structured input data containing the user's intent, the plug-in goal, and the parameters required for invocation. This input is then fed into a pre-trained language model, enabling the model to perform subsequent reasoning, plug-in invocation, or result generation within a clear and explicit context. Through the above-described process, the system significantly enhances the semantic adaptation between natural language input and plug-in functionality, overcoming the limited recognition capabilities of traditional systems that rely solely on keyword matching. Suitable for complex environments with a wide variety of plug-ins and a high degree of functional similarity, it intelligently selects the plug-in most suitable for the current query without relying on manual annotation rules, improving the accuracy, speed, and stability of user request responses. It also enhances the system's ability to understand and process complex and ambiguous queries, improving the overall user experience.

[0077] For example, a user enters the query "I want to view last month's spending trends and display them as a chart." The system first checks the status of all plugins and finds that the "Billing Statistics Plugin" and "Charting Plugin" are currently active, forming a subset of plugin information. The system then performs semantic parsing on the query, extracting "view spending trends" as the core intent, "last month" as the time parameter, and "charting" as the desired output format. This request is converted into an embedding vector and matched against the configuration fields of the two plugins: the "Billing Statistics Plugin" has a "consumption statistics by time period" function field, which strongly matches the intent; the "Charting Plugin" configuration includes a "data visualization output" specification, which is also highly relevant to the "charting" request. The system then constructs this information into structured input data: the intent is "obtain spending trends," the target plugins are "Billing Statistics" and "Charting Plugin," the parameter is "last month," and the output format is "charting." This input is then fed into a pre-trained language model, which then calls the plugins and generates results. This process does not rely on fixed rules, but rather dynamically matches semantic understanding, enabling the system to achieve greater adaptability and semantic accuracy.

[0078] In one embodiment, Figure 3 As shown, in response to the output result containing a call instruction, the target plug-in is called according to the call instruction, the execution result of the target plug-in is obtained, and the execution result is returned to the pre-trained language model. The pre-trained language model generates a processing result based on the execution result and the output result and returns it, including:

[0079] Parse the output results and extract the target plug-in identifier and its calling parameters contained in the calling instruction;

[0080] Based on the target plug-in identifier, retrieve the functional interface of the corresponding plug-in from the plug-in list;

[0081] Call the function interface of the target plug-in through the calling parameters and obtain the execution result of the returned plug-in;

[0082] Return the plug-in execution results to the pre-trained language model;

[0083] The pre-trained language model performs fusion reasoning based on the plug-in execution results and output results, generates and returns the processing results.

[0084] Among them, call parameters refer to the input data required by the target plug-in when it is called, which are usually extracted from the user's query intent and contain fields and values ​​necessary for plug-in execution, such as time, location, keywords, thresholds, etc., which are used to control plug-in behavior or limit the query scope; target plug-in identifier refers to the unique identifier assigned by the system to each plug-in, which is used to accurately locate a specific plug-in in the plug-in list to avoid confusion between plug-ins with the same name or similar functions; fusion reasoning refers to the process in which the pre-trained language model, after receiving the plug-in execution result, jointly analyzes and comprehensively judges the result with the original model output to generate processing results that are more in line with the semantic context.

[0085] Specifically, if Figure 5As shown, when the pre-trained language model identifies a call instruction within the output, the system immediately parses the output, extracting the target plug-in identifier and call parameters contained therein. This allows the system to identify the plug-in object to be called and its operational details. The system then uses the plug-in identifier to retrieve the corresponding plug-in's functional interface from the current plug-in list, ensuring scheduling accuracy and uniqueness of the call path. Using the extracted call parameters as input, the system calls the plug-in's functional interface and retrieves its execution result. The plug-in's execution result can be structured business data (such as weather information, database query results, or calculation results) or the service status provided by the plug-in (such as task completion or normal interface response). This execution result is transmitted to the pre-trained language model in real time. The model combines its original output (i.e., its understanding of the user request and draft response) with the precise information returned by the plug-in for inference, generating a more complete, contextually logical, and consistent processing result. Finally, the processing result is sent back to the requesting system for user review or further use.

[0086] Suppose a user enters the query "What's the weather like in Shanghai tomorrow? Is it suitable for running?" The pre-trained language model identifies the query intent as consisting of two subtasks: weather query and exercise recommendation. After matching plugin semantics, the system determines that the "weather query plugin" needs to be invoked. Recognizing the call instruction in the output, the system extracts the target plugin identifier "weather_shanghai" and the call parameters "date = tomorrow, city = Shanghai." It retrieves the plugin's functional interface from the plugin list and initiates the call. The plugin returns weather information such as "temperature 28°C, humidity 60%, no rain, and excellent air quality." The pre-trained language model then combines its own language capabilities with the original output logic to generate the result "Tomorrow in Shanghai will be sunny, with moderate temperatures and excellent air quality, suitable for outdoor running" and returns this result to the user. This process ensures that the language model not only understands the user's language but also leverages the plugin to obtain real-world data and provide specific, reliable, and semantically complete answers. This effectively addresses the issue of overgeneralization or inaccurate responses often seen in traditional models when processing external knowledge and dynamic data, significantly enhancing the model's practicality, scalability, and user experience.

[0087] In one embodiment, performing failure detection on a plug-in includes:

[0088] In response to detecting that a plug-in is operating abnormally or the number of consecutive call failures exceeds a preset threshold, marking the plug-in as invalid and removing it from the list of available plug-ins;

[0089] Retrieve alternative plug-ins with similar functions to the invalid plug-in from the preset plug-in candidate library and perform similarity matching based on functional descriptions or semantic information;

[0090] In response to a successful match, a replacement plug-in registration request is sent to the backend to complete the alternative plug-in registration process;

[0091] In response to the new plug-in being successfully registered and passing the usability test, the alternative plug-in is automatically replaced to the position of the original invalid plug-in in the plug-in list, and the plug-in configuration information is updated synchronously;

[0092] Notify the pre-trained language model of the replacement result so that it can use the new plug-in for reasoning and calling in subsequent generation processes.

[0093] Among them, the plug-in candidate library refers to a pre-built and maintained plug-in collection library, which contains multiple plug-ins that have not yet been activated or registered for use. These plug-ins have a certain degree of functional diversity and are used to replace or supplement the main plug-in when it fails, fails, or needs to be expanded; functional description refers to a collection of information used to express the functional behaviors that the plug-in can perform, usually including natural language descriptions, interface capability descriptions, supported parameter types, usage scenarios, etc., which are used to assist in matching the relationship between plug-ins and task requirements; semantic information similarity matching refers to analyzing the semantic correlation between plug-in function descriptions through natural language processing technology, thereby evaluating the similarity between different plug-ins at the functional level, to assist in establishing a replacement matching relationship between failed plug-ins and candidate plug-ins.

[0094] Specifically, the system continuously monitors the operational status of registered plug-ins during operation. If a plug-in experiences repeated call failures exceeding a set threshold due to reasons such as interface anomalies, response timeouts, or call return errors, the system automatically marks it as invalid and removes it from the list of available plug-ins. This process effectively prevents the erroneous plug-in from continuing to participate in the inference process, improving the overall system's responsiveness and stability. The system then initiates an intelligent replacement process from the candidate plug-in library. By comparing the functional descriptions of the invalid plug-in with those of the candidate plug-in and using a semantic information analysis algorithm to assess their functional similarity, the system accurately selects alternative plug-ins that can replace the original plug-in. This significantly improves the accuracy of matching the replacement plug-in's tasks with the original plug-in, ensuring the rationality and continuity of the replacement. If a match is successful, the system automatically initiates the registration process for the candidate plug-in. After registration, the system immediately conducts usability testing on the plug-in to confirm that its functional interface is functioning properly, its structural response complies with regulations, it contains necessary fields, and it has actual usable capabilities. If the test passes, the plug-in is seamlessly written to the original plug-in's location, and the configuration file is updated simultaneously, avoiding disruptive manual maintenance. After receiving the plug-in replacement notification, the pre-trained language model will automatically switch to the new plug-in in the generation logic and continue to process subsequent tasks. The entire process does not require manual intervention, which significantly improves the stability of the plug-in management system in high-concurrency, large-scale task scheduling, reduces manual maintenance costs, optimizes the continuity of the collaborative processing of the model and plug-in, and enhances the reliability of the user experience.

[0095] In one embodiment, Figure 2 As shown, a plug-in management device based on a pre-trained language model is provided, including: an acquisition module 710, a query module 720, a judgment module 730, a result first submodule 740, and a result second submodule 750, which are used to:

[0096] Acquisition module 710, used to obtain a plug-in list;

[0097] A query module 720 is configured to, in response to receiving a query request, send the query request and configuration information of available plug-ins in the updated plug-in list to the pre-trained language model;

[0098] A determination module 730 is configured to generate an output result based on the query request and configuration information by the pre-trained language model and determine whether the output result contains a call instruction;

[0099] The first result submodule 740 is configured to, in response to the output result including a call instruction, call the target plug-in according to the call instruction, obtain the execution result of the target plug-in, and return the execution result to the pre-trained language model. The pre-trained language model generates a processing result based on the execution result and the output result and returns it;

[0100] The second result submodule 750 is configured to return the output result as a processing result in response to the output result not including the call instruction.

[0101] In one embodiment, the result first submodule 740 is configured to:

[0102] Parse the output results and extract the target plug-in identifier and its calling parameters contained in the calling instruction;

[0103] Based on the target plug-in identifier, retrieve the functional interface of the corresponding plug-in from the plug-in list;

[0104] Call the function interface of the target plug-in through the calling parameters and obtain the execution result of the returned plug-in;

[0105] Return the plug-in execution results to the pre-trained language model;

[0106] The pre-trained language model performs fusion reasoning based on the plug-in execution results and the original output results, generates and returns the processed results.

[0107] It should be understood that although Figure 2 The steps in the device structure block diagram are shown in sequence as indicated by the arrows, but these steps are not necessarily executed in the order indicated by the arrows. Unless otherwise specified in this document, there is no strict order restriction for the execution of these steps, and these steps can be executed in other orders. Moreover, Figure 2 At least part of the steps may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily executed at the same time, but can be executed at different times. The execution order of these sub-steps or stages is not necessarily sequential, but can be executed in turn or alternately with other steps or at least part of the sub-steps or stages of other steps.

[0108] An embodiment of the present application further provides a computer-readable storage medium storing a computer program, wherein the computer program is configured to execute the steps of any of the above-mentioned embodiments of the plug-in management method based on a pre-trained language model when running.

[0109] In an exemplary embodiment, the computer-readable storage medium may include, but is not limited to, various media that can store computer programs, such as a USB flash drive, a read-only memory (ROM), a random access memory (RAM), a mobile hard disk, a magnetic disk, or an optical disk.

[0110] An embodiment of the present application further provides a computer program product, which includes a computer program. When the computer program is executed by a processor, the steps in any of the above-mentioned plug-in management method embodiments based on a pre-trained language model are implemented.

[0111] Professionals may further appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented by electronic hardware, computer software, or a combination of the two, such as Figure 6 As shown, in order to clearly illustrate the interchangeability of hardware and software, the above description has generally described the components and steps of each example according to function. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Professionals and technicians may use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0112] The above is a detailed introduction to a plug-in management method based on a pre-trained language model provided by this application. This article uses specific examples to illustrate the principles and implementation methods of this application. The description of the above embodiments is only used to help understand the method of this application and its core idea. It should be pointed out that for ordinary technicians in this technical field, without departing from the principles of this application, several improvements and modifications can be made to this application, and these improvements and modifications also fall within the scope of protection of this application.

Claims

1. A plug-in management method based on a pre-trained language model, characterized in that: include: Get the plugin list; In response to receiving the query request, sending the query request and the configuration information of the plug-in available in the updated plug-in list to the pre-trained language model; The pre-trained language model generates an output result according to the query request and the configuration information and determines whether the output result contains a call instruction; In response to the output result including the call instruction, calling the target plug-in according to the call instruction, obtaining the execution result of the target plug-in, and returning the execution result to the pre-trained language model, wherein the pre-trained language model generates a processing result based on the execution result and the output result and returns the result; In response to the output result not including the call instruction, the pre-trained language model returns the output result as the processing result; In response to receiving the query request, sending the query request and the available plug-in configuration information to the pre-trained language model includes: Get the current enabled status of each plug-in; According to the current activation state of the plug-in, the plug-in currently in the activated state is obtained from the plug-in list to form a plug-in information subset, wherein the plug-in information subset includes: a plug-in function description field and a plug-in parameter definition field; Performing semantic analysis on the text of the query request to extract intent information and preset parameters; Converting the intent information and the preset parameters into an embedding vector; Performing vector conversion on the plug-in function description field and the plug-in parameter definition field to generate a plug-in vector; Calculating a matching score based on semantic similarity between the embedding vector and the plugin vector; Filter out plug-ins with a matching degree higher than a preset threshold according to the matching score to form a candidate plug-in set; Determine a matching plug-in based on the plug-in priority and historical call information in the candidate plug-in set; Based on the matching plug-in and the query request, constructing structured input data, the structured input data including: user intent, plug-in target, and parameters required for calling; Loading the structured input data into the pre-trained language model; Calculating a matching score based on semantic similarity between the embedding vector and the plug-in vector includes: The embedding vector is matched with the configuration fields of each plugin in the plugin information subset, and its semantic relevance is evaluated to generate a matching result.

2. A plug-in management method based on a pre-trained language model according to claim 1, characterized in that: The method further comprises: In response to receiving a plug-in registration request, register a new plug-in and update the plug-in list: Send an interface request to the backend by calling the plug-in registration interface; In response to receiving the registration instruction information returned by the back end, judging the registration instruction information; In response to the registration indication information indicating that the registration has failed, feeding back an error message and terminating the current registration operation; In response to the registration indication information indicating that the registration is successful, the information of the new plug-in is added to the plug-in list.

3. A plug-in management method based on a pre-trained language model according to claim 2, characterized in that: In response to the registration indication information indicating that the registration is successful, adding the information of the new plug-in to the plug-in list includes: Calling the functional interface of the new plug-in to test the availability of the new plug-in; In response to the test being successful, writing the plug-in into the plug-in list and updating the plug-in list; In response to the test failure, the system returns to the initial state of the plug-in configuration and feeds back test failure information.

4. The plug-in management method based on a pre-trained language model according to claim 3, characterized in that: In response to the new plug-in being successfully registered, calling the functional interface of the new plug-in to test the availability of the new plug-in includes: Acquire response data of the functional interface, the response data including: a response status and a response data structure, and determine whether the new plug-in is available based on the response status and the response data structure; In response to the response status of the functional interface being successful, and the response data structure including a preset field, the new plug-in is available; In response to the response status of the functional interface being failure, or the response data structure not including the preset field, the new plug-in is unavailable.

5. The plug-in management method based on a pre-trained language model according to claim 2, characterized in that: The step of registering a new plug-in and updating the plug-in list in response to receiving the plug-in registration request further includes: In response to receiving a function expansion instruction of any plug-in in the plug-in list, modifying a parameter definition template of the plug-in, wherein the updated plug-in list includes at least one of the following: a built-in plug-in and a new plug-in; The configuration information of the plug-in is updated based on the modified parameter definition template, overwriting the configuration information of the original plug-in, setting the plug-in to an activated state, and updating the plug-in list.

6. The plug-in management method based on a pre-trained language model according to claim 3, characterized in that: In response to the output result including the call instruction, calling the target plug-in according to the call instruction, obtaining an execution result of the target plug-in, and returning the execution result to the pre-trained language model, wherein the pre-trained language model generates a processing result based on the execution result and the output result and returns the processing result, including: Parsing the output result to extract the target plug-in identifier and its calling parameters contained in the calling instruction; Based on the target plug-in identifier, searching the functional interface of the corresponding plug-in from the plug-in list; Calling the functional interface of the corresponding target plug-in through the calling parameters, and obtaining the execution result of the target plug-in; Returning the plug-in execution result to the pre-trained language model; The pre-trained language model performs fusion reasoning based on the plug-in execution result and the output result to generate and return the processing result.

7. A plug-in management device based on a pre-trained language model for implementing the plug-in management method based on a pre-trained language model according to any one of claims 1 to 6, characterized in that: The device comprises: Get module, used to get the plug-in list; a query module configured to, in response to receiving a query request, send the query request and the configuration information of the plug-in available in the updated plug-in list to the pre-trained language model; A judgment module, configured for the pre-trained language model to generate an output result according to the query request and the configuration information and to judge whether the output result contains a call instruction; A first result submodule is configured to, in response to the output result containing the call instruction, call the target plug-in according to the call instruction, obtain the execution result of the target plug-in, and return the execution result to the pre-trained language model, wherein the pre-trained language model generates a processing result based on the execution result and the output result and returns the result; The second result sub-module is configured to, in response to the output result not including the call instruction, cause the pre-trained language model to return the output result as the processing result.

8. A computer device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein: When the processor executes the computer program, the steps of the method according to any one of claims 1 to 6 are implemented.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 6 are implemented.

Images