A tool invocation method and apparatus

Abstract

This application discloses a tool invocation method and apparatus. The method includes: obtaining query data input by a user; generating a structured tool requirement specification based on the query data; determining a candidate tool set from a pre-built tool vector library based on the tool requirement specification, wherein the candidate tool set includes several candidate tools that meet the matching degree condition with the tool requirement specification, and the matching degree between the tools in the tool vector library and the tool requirement specification is determined based on the tool fingerprint of the tools in the tool vector library; and inputting the candidate tool set into a pre-trained first model to obtain the tool selection result output by the first model.

Description

Technical Field

[0001] This application relates to the field of large model technology, and more specifically, to a tool invocation method and apparatus. Background Technology

[0002] In the current field of large-scale models, applications that call other tools based on large models have been implemented. However, in scenarios with multiple callable tools, the lack of uniformity in the naming, parameter, and description standards of these tools, as well as the existence of semantically similar tools, often leads to problems when calling these tools, such as insufficient accuracy and high computational costs. Summary of the Invention

[0003] In view of the above, this application provides the following technical solution:

[0004] The first aspect of this application provides a tool invocation method, the method comprising:

[0005] Obtain the query data input by the user;

[0006] A structured tool requirements specification is generated based on the query data;

[0007] Based on the tool requirement specification, a set of candidate tools is determined from a pre-built tool vector library. The set of candidate tools includes several candidate tools that meet the matching degree condition with the tool requirement specification. The matching degree between the tools in the tool vector library and the tool requirement specification is determined based on the tool fingerprint of the tools in the tool vector library.

[0008] The candidate tool set is input into a pre-trained first model to obtain the tool selection result output by the first model.

[0009] In one possible implementation, the generation of structured tool requirements specifications based on the query data includes:

[0010] Extract specified data from the query data, wherein the specified data includes at least one of the following: intent data, entity data, and constraint data;

[0011] Based on the aforementioned set data, hypothetical requirements are determined;

[0012] A structured tool requirement specification is generated based on the hypothetical requirements.

[0013] In one possible implementation, the construction of the tool vector library includes:

[0014] The metadata of each tool is first processed to obtain the tool fingerprint of each tool. The first processing makes each tool uniquely identifiable. The tool fingerprint is feature data obtained by identifying, extracting and fusing the tool's description data.

[0015] The tool fingerprints of each tool are vectorized, and the vectorized tool fingerprints are stored in the tool vector library.

[0016] In one possible implementation, the first processing of the metadata of each tool to obtain the tool fingerprint of each tool includes:

[0017] For parameters used to represent the same meaning in different tools, a unified name mapping process is performed, and the constraint data of the corresponding parameters is extracted to obtain the first data containing parameter names and constraint data;

[0018] Extract the current tool's invocation conditions based on the tool's description data; obtain fingerprint text based on the tool's description data;

[0019] Based on the first data, the calling conditions, and the fingerprint text, fused data is obtained;

[0020] The fused data is vectorized to obtain the tool fingerprint.

[0021] In one possible implementation, the training process of the first model includes:

[0022] A set of candidate tools is obtained based on the given query data;

[0023] A training data set is constructed based on the candidate tool set;

[0024] The training is performed based on the training dataset until a first model that meets the convergence condition is obtained.

[0025] In one possible implementation, a training dataset is constructed based on the candidate tool set, including at least one of the following:

[0026] Select a first number of tools from the tool vector library that have the highest similarity to the target tool in the candidate tool set but are unusable. Combine the first number of tools with the given query data to form training data. The unusable tools are characterized by the fact that the tool is different from the target tool in at least one of the following: the tool's parameters, the tool's calling conditions, and the fingerprint text corresponding to the tool's description data.

[0027] The corresponding candidate tool set is backtracked from the historical tool selection error data, and each candidate tool in the backtracked candidate tool set is combined with the given query data to form training data.

[0028] One possible implementation also includes:

[0029] Construct an obfuscated data set based on the target tool corresponding to the given query data, including:

[0030] A second process is performed based on the structured name and description information of the target tool to obtain an approximate tool. The given query data, the approximate tool, and the target tool constitute a confused data set, which belongs to the training data set of the first model.

[0031] In one possible implementation, after obtaining the tool selection result output by the first model, the method further includes:

[0032] Obtain the tool call result, generate training samples labeled with the corresponding result based on the call result, and incrementally update the training samples into the obfuscated data set.

[0033] In one possible implementation, before the output tool selects the result, it also includes:

[0034] The tools and / or parameters corresponding to the tool selection results obtained from the first model are validated, and the tool selection results that pass the validation are output.

[0035] The verification includes at least one of the following: parameter format verification, parameter constraint data verification, and tool invocation condition verification.

[0036] A second aspect of this application provides a tool invocation device, the device comprising:

[0037] The data acquisition module is used to acquire the query data input by the user;

[0038] The specification determination module is used to generate structured tool requirement specifications based on the query data;

[0039] The candidate set determination module is used to determine a set of candidate tools from a pre-built tool vector library based on the tool requirement specification. The set of candidate tools includes several candidate tools that meet the matching degree condition with the tool requirement specification. The matching degree between the tools in the tool vector library and the tool requirement specification is determined based on the tool fingerprint of the tools in the tool vector library.

[0040] The result acquisition module is used to input the candidate tool set into a pre-trained first model to obtain the tool selection result output by the first model. Attached Figure Description

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

[0042] Figure 1 This is a flowchart illustrating a tool invocation method disclosed in an embodiment of this application;

[0043] Figure 2 This is a flowchart illustrating the generation of structured tool requirements specifications disclosed in an embodiment of this application;

[0044] Figure 3 This is a flowchart illustrating the construction tool vector library disclosed in the embodiments of this application;

[0045] Figure 4 This is a schematic diagram of the composition structure of the tool vector library disclosed in the embodiments of this application;

[0046] Figure 5 This is a schematic diagram illustrating the principle of training sample construction disclosed in the embodiments of this application;

[0047] Figure 6 This is a schematic diagram illustrating the implementation components of a tool data enhancement method disclosed in an embodiment of this application.

[0048] Figure 7 This is a schematic diagram of the structure of a tool calling device disclosed in an embodiment of this application. Detailed Implementation

[0049] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0050] Figure 1 This is a flowchart illustrating a tool invocation method disclosed in an embodiment of this application. See also... Figure 1 As shown, tool invocation methods can include:

[0051] Step 101: Obtain the query data input by the user.

[0052] The query data can contain only a problem description, such as "My laptop is unresponsive and always freezes"; or only a purpose description, such as "Please help me find a tool to clean my hard drive"; or the query data can contain both a problem description and a purpose description. The more specific the problem and / or requirement of the query data, the faster and more accurate the tool will be found.

[0053] This application does not impose fixed restrictions on the way users input query data. It can be text input, voice input, etc. In the implementation of voice input, after the user completes the voice input, the corresponding text content can be displayed on the corresponding display interface, and the user can further manually adjust the text content.

[0054] Step 102: Generate a structured tool requirement specification based on the query data.

[0055] It is understandable that different users have different ways of expressing themselves and different knowledge reserves, so there are problems such as the diversity of user expressions and the instability of keywords in the query data. In order to facilitate the accuracy of subsequent tool retrieval, in this application, after obtaining the query data input by the user, the query data is first analyzed and processed to generate a structured tool requirement specification.

[0056] The tool requirement specification may include several defined elements to ensure its validity, enabling subsequent retrieval of corresponding tools from the tool vector library based on the tool requirement specification. The elements included in the tool requirement specification may include, but are not limited to, the work to be performed, the object, constraint data, parameters, etc.

[0057] After generating the structured tool requirement specifications in step 102, the subsequent retrieval and recall of tools are carried out. Compared with the solution of directly retrieving the tool description using query data, this implementation is closer to the actual execution intent and can significantly improve the probability of recalling the correct tools.

[0058] Step 103: Based on the tool requirement specification, determine a set of candidate tools from a pre-built tool vector library. The set of candidate tools includes several candidate tools that meet the matching degree condition of the tool requirement specification.

[0059] The degree of matching between the tools in the tool vector library and the tool requirement specifications is determined based on the tool fingerprints of the tools in the tool vector library.

[0060] The tool fingerprints in the tool vector library are feature data obtained by processing the tool's description information. Each tool's tool fingerprint is unique, and different tools have different tool fingerprints. In practical applications, the tool vector library can include data related to many tools, among which there may be some tools with high similarity. These tools often have similar names, such as "Clean Master" and "Sweep Master," or some similar character names. Although the tool names are similar, the objects they handle, the calling conditions, and / or parameters may be different. For example, "Clean Master" focuses on handling network cache junk, while "Sweep Master" focuses on cleaning expired or invalid data on the hard drive.

[0061] Distinguishing tools solely by their names can lead to confusion and affect the accuracy of tool retrieval. For example, if multiple tools have similar functions but differ slightly in their boundaries (minor differences in triggering conditions or unavailability conditions), the tool selection model (the first model described below) is prone to misselection. Conversely, directly inputting tools and their descriptions as prompts into the tool selection model results in context explosion and information redundancy, placing high demands on system computing power and reducing efficiency. Furthermore, tool descriptions lack standardized formats and may contain highly similar descriptions, posing significant challenges for the model in understanding and selecting tools, making accurate tool selection difficult. Therefore, in this application, all tools in the tool library are processed using the same procedure to obtain a unique tool fingerprint, avoiding unsatisfactory tool retrieval results due to similar tool names.

[0062] Several candidate tools that meet the matching criteria can be either a fixed number of candidate tools with the highest matching degree, or several candidate tools with a matching degree higher than a set matching degree threshold. The matching degree between a tool and its requirements specification is determined based on the tool's tool fingerprint. Existing matching degree calculation methods in the field can be used, such as cosine distance calculation or Euclidean distance calculation. The specific method used can be selected based on the actual scenario.

[0063] Step 104: Input the candidate tool set into the pre-trained first model to obtain the tool selection result output by the first model.

[0064] After obtaining the candidate tool set, it can be input into a pre-trained first model, and the tool requirement specification can be input simultaneously. The first model determines the final tool selection result from the candidate tool set based on the tool requirement specification. The first model is a model that provides the final tool selection result from a certain number of candidate tools. The tool selection result can be a choice of one tool, a combination of two or three tools, or no tool selection.

[0065] The tool retrieval method described in this embodiment does not directly retrieve tools based on the user-input query data. Instead, it first uses a structured tool requirement specification based on the query data, then determines a set of candidate tools from a tool vector library containing tool fingerprints of all tools based on the tool requirement specification, and finally determines the tool selection result based on the candidate tool set. Since the structured tool requirement specification standardizes the query requirements, and the tool fingerprints in the tool vector library are uniquely identifiable, it avoids the problems of inaccurate tool search results that may occur when query data lacks standardized elements and when searching for tools based solely on tool names, thereby improving the accuracy of the tool selection result.

[0066] Figure 2 This is a flowchart illustrating the generation of structured tool requirements specifications disclosed in an embodiment of this application. See also... Figure 2 As shown, in one implementation, the generation of a structured tool requirement specification based on the query data may include:

[0067] Step 201: Extract setting data from the query data, wherein the setting data includes at least one of the following: intent data, entity data, and constraint data.

[0068] As mentioned earlier, different users have different expression habits and knowledge reserves, which means that different users will input different query data for the same problem or need. Therefore, it is necessary to process the query data accordingly in order to obtain a standardized tool requirement specification that includes the set elements.

[0069] In this implementation, firstly, setting data is extracted from the query data. This setting data corresponds to the setting elements and is used to "select" or "hit" the tool that best meets the needs from a large number of tools in the tool library. The intent data includes things like "service appointment," "improve device running speed," "virus and Trojan removal," "device detection," and "device cleanup"; the entity data includes things like "hard drive," "display module," and "wireless communication module"; and the constraint data includes things like "applies only to *** model / type devices," "only available to personnel with management privileges," and "only accessible to users within a specific local area network."

[0070] Step 202: Determine hypothetical requirements based on the set data.

[0071] After extracting the set data, hypothetical requirements can be determined based on the set data. These hypothetical requirements define the conditions that the tools to be retrieved or recalled should meet. It should be noted that the hypothetical requirements are unstructured text. To facilitate subsequent tool retrieval or recall, the hypothetical requirements can be further processed, which is the content of step 203.

[0072] Step 203: Generate a structured tool requirement specification based on the hypothetical requirements.

[0073] After identifying hypothetical requirements, a structured tool requirement specification can be generated based on these requirements. This allows for the efficient and accurate retrieval of several candidate tools from a tool vector library that meet the matching criteria. The structured tool requirement specification may contain defined elements, which can be arranged in a predefined order.

[0074] The tool requirement specification is generated, for example: given a user query "{query}" and context "{context}", the tool requirement specification to be invoked to complete the task is generated and output as structured text; the specification is vectorized: V_hypo =Embed(hypothetical_spec).

[0075] The above content describes the specific implementation of generating structured tool requirements specifications, which helps those skilled in the art to better understand and implement the technical solution of this application.

[0076] Figure 3 This is a flowchart illustrating the construction tool vector library disclosed in an embodiment of this application. See also... Figure 3 As shown, the construction of the tool vector library may include:

[0077] Step 301: Perform a first processing on the metadata of each tool to obtain the tool fingerprint of each tool. The first processing makes each tool uniquely identifiable. The tool fingerprint is feature data obtained by identifying, extracting and fusing the tool's description data.

[0078] It is understandable that the tools in the tool library come from different business lines and third-party systems, and their naming, parameters and description specifications are not consistent. There are also a large number of synonymous tools and near-synonymous parameters. In order to avoid confusion in tool recall caused by these factors, the solution in this application can perform unified standardization processing on the metadata of the tools (including but not limited to tool name, description data, etc.), that is, the first processing, to obtain a tool fingerprint that can uniquely represent the corresponding tool.

[0079] Specifically, the metadata of each tool is first processed to obtain the tool fingerprint of each tool. This may include: performing a unified name mapping process on parameters used to represent the same meaning in different tools, and extracting the constraint data of the corresponding parameters to obtain first data containing parameter names and constraint data; extracting the calling conditions of the current tool based on the tool's description data; obtaining fingerprint text based on the tool's description data; obtaining fused data based on the first data, the calling conditions, and the fingerprint text; and vectorizing the fused data to obtain the tool fingerprint.

[0080] The descriptive data of a tool usually contains a relatively rich description of the tool, including key information such as "inapplicability, counterexamples, and access restrictions". Conventional solutions tend to rely on the tool name or a few keywords, ignoring the fine-grained constraints in the description. Therefore, in this application, the tool fingerprint is obtained based on the tool's descriptive data, which can not only effectively characterize a specific tool, but also make the tool have unique identification characteristics.

[0081] Step 302: Vectorize the tool fingerprints of each tool and store the vectorized tool fingerprints in the tool vector library.

[0082] One implementation of tool normalization and fingerprint construction may include: normalizing the raw metadata of each tool, ToolMeta={name, description, params, examples}, to obtain ToolFP (tool fingerprint). The process includes: parameter alias normalization: establishing an alias map for each parameter (e.g., {user_id, uid, userIdentifier} -> user_id) to map parameters with the same meaning (but different names) from different tools to a single name, and extracting type / format / required constraints; capability slot extraction: extracting slots such as action / object / domain / triggering conditions / inapplicable conditions / permission restrictions from the description; fingerprint text: fp_text = concat(action, object, domain, constraints, normalized_params, negative_triggers, examples); and fingerprint vectorization: V_fp = Embed(fp_text), obtaining the tool fingerprint and writing it to the tool vector library.

[0083] Figure 4 This is a schematic diagram illustrating the structural composition of the tool vector library disclosed in an embodiment of this application. (In conjunction with...) Figure 4As shown, the tool vector library may contain, but is not limited to, four parts: function name, parameter name, function description, and parameter description; where the function name is generated based on the description data, and the parameter name is also generated based on the description data. Generating function names and / or parameter names based on description data can be done according to a set naming rule. The naming rules for generating function names and parameter names can be the same or different. An example naming rule is to extract elements from the description data (including but not limited to functions, constraints, applicable scenarios, triggering conditions, etc.), concatenate multiple extracted elements in a certain order, perform a hash operation on the concatenated data, and the result of the hash operation is the function name / parameter name.

[0084] In one implementation, the training process of the first model may include: obtaining a set of candidate tools based on given query data; constructing a training data set based on the set of candidate tools; and training based on the training data set until a first model that meets the convergence condition is obtained.

[0085] The step of constructing a training data set based on the candidate tool set may include at least one of the following: selecting a first number of tools from the tool vector library that have the highest similarity to the target tool in the candidate tool set but are unusable; combining the first number of tools with the given query data to form training data; wherein, an unusable tool is characterized by the tool differing from the target tool in at least one of the following: the tool's parameters, the tool's calling conditions, or the fingerprint text corresponding to the tool's description data; backtracking the corresponding candidate tool set from the historical tool selection error data, and combining each candidate tool in the backtracked candidate tool set with the given query data to form training data.

[0086] In implementation, training samples (obfuscation set enhancement) can be constructed by combining a tool candidate set with an obfuscation mining strategy. This includes, but is not limited to: similarity hard negatives (hard negative samples): selecting tools from the vector library that are most similar to the correct tool but are unusable / have different boundaries; log hard negatives: backtracking from historical misselected / error samples online to form the true obfuscation set; parameter challenges: generating adversarial examples for synonymous parameters, date formats, regularization constraints, etc., forcing the model to learn parameter alignment and verification. Each training sample only provides C (a fingerprint summary / tool ​​fingerprint of a small number of candidate tools), requiring the model to output: whether to call, which tool to call, parameters, and, if necessary, clarification questions. Figure 5 This is a schematic diagram illustrating the principle of training sample construction disclosed in the embodiments of this application, which can be combined with... Figure 5 Understand the foregoing content.

[0087] In other implementations, constructing a training data set based on the candidate tool set may further include: constructing a confused data set based on the target tool corresponding to the given query data. Specifically, a second processing can be performed based on the structured name and description information of the target tool to obtain an approximate tool. The given query data, the approximate tool, and the target tool constitute the confused data set, which belongs to the training data set of the first model. The second processing includes any of the following: adding random characters to the name, rewriting the name, rewriting the description information, etc. Figure 6 This is a schematic diagram illustrating the implementation of a tool data enhancement method disclosed in an embodiment of this application. For function names, in the final generated obfuscated data set, 30% of the tools retain the original tool names, 20% generate function names based on description data, and 50% replace at least some characters in the names. For parameter names, in the final generated obfuscated data set, 30% of the parameters retain the original parameter names, 20% generate parameter names based on description data, and 50% replace at least some characters in the names. For function descriptions, in the final generated obfuscated data set, 50% are rewritten function descriptions, and 50% are original function descriptions. For parameter descriptions, in the final generated obfuscated data set, 50% are rewritten parameter descriptions, and 50% are original parameter descriptions. This can be combined with... Figure 6 Understand the foregoing content.

[0088] Furthermore, after obtaining the tool selection result output by the first model, the process may further include: obtaining the tool invocation result, generating training samples labeled with the corresponding result based on the invocation result, and incrementally updating the training samples to the obfuscated data set.

[0089] When the amount of training data is sufficient, the first model can be trained based on the training data. The implementation can employ a phased training and reward mechanism, such as: Phase 1: SFT (Supervised Fine-Tuning) for learning candidate selection and parameter generation; Phase 2: GRPO (Group Relative Policy Optimization, a reinforcement learning method) / preference optimization for the confusion set (bad cases). Example reward function: R = α·format_accuracy (model output format reward) + β·tool_correctness (tool selection reward) + γ·param_executable (parameter selection reward); where param_executable is provided by the parameter aligner and validator (required / type / regularity / enumeration / permission / idempotency, etc.), and α, β, and γ are weights.

[0090] The above content details the training of the first model. Those skilled in the art can refer to the disclosed content to implement the solution of this application.

[0091] In other implementations, before outputting the tool selection result, the tool invocation method may further include: verifying the tool and / or parameters corresponding to the tool selection result obtained from the first model, and outputting the tool selection result that passes the verification; wherein, the verification includes at least one of the following: parameter format verification, parameter constraint data verification, and tool invocation condition verification.

[0092] In summary, this application's solution simultaneously improves the reliability of tool selection across three levels: tool selection, parameter generation, and executable verification. The solution focuses not only on the ability of the model to call tools, but also on providing a practical method for large-scale, heterogeneous, and continuously evolving enterprise tool libraries. This method includes tool semantic representation, intent-enhanced retrieval, similar tool identification, parameter alignment, and feedback loop, enabling the model to stably output executable calls under the premise of controllable tokens.

[0093] This application provides a solution for enhancing the tool invocation capabilities of large language models for enterprise-level large-scale tool libraries. It includes "tool fingerprinting semantic representation + intent-enhanced retrieval + confusion set discrimination training + parameter alignment and executable verification + feedback loop." The solution is compatible with existing common tool invocation protocols and can be directly integrated into existing enterprise service agent systems. This solution addresses heterogeneous enterprise tool libraries by achieving automatic normalization and stable semantic representation; it features confusion set discrimination and hard negative training for similar tools, helping to improve tool selection accuracy; furthermore, it implements an engineering closed loop for parameter alignment, type verification, and failure self-recovery; the solution has good feasibility and scalability.

[0094] In a specific implementation, the solution can reliably invoke a tool through the process of "intent specification generation -> candidate recall -> call generation -> parameter alignment and validation -> execution feedback." This includes the following:

[0095] Step 1: Query and Understanding. Extract user intent, entities, and key constraints (time, order number / work order number, device serial number, account, etc.), and determine whether tools are needed or clarification is required first.

[0096] Step 2: Generate hypothetical tool requirements specifications and recall the Top K tools based on the tool fingerprint vector library.

[0097] Step 3: Cue word assembly. Provide the model only with fingerprint summaries / tool ​​fingerprints of the candidate set C (triggered / non-triggered conditions + normalized parameter schema + 1-2 examples), and require the output of standard function_call.

[0098] Step 4: Parameter Alignment and Executability Validation. Normalize, convert, and validate the model output parameters using alias_map; if missing or uncertain, trigger clarification questions or revert to Step 2 for re-retrieval.

[0099] Step 5: Execution and Feedback Loop. Record tool call results (success / failure codes, error types, user confirmation), automatically generate self-annotated training samples, and incrementally update the confusion set and vector library.

[0100] The advantages of this application include:

[0101] 1. Intent-Enhanced Retrieval: To address the issues of diverse user expressions and unstable keywords, a "hypothetical tool requirement specification" (including the actions, objects, constraints, and potential parameters to be performed) is first generated, followed by vector retrieval and recall. Compared to directly using a query to retrieve tool descriptions, this specification is closer to the actual execution intent, significantly increasing the probability of recalling the correct tools.

[0102] 2. Tool Fingerprint Generation and Confusion Set Construction: Each tool undergoes automatic normalization (parameter alias normalization, type and format constraint extraction, and trigger / non-trigger condition extraction) to form a stable "Tool Fingerprint" text and vector representation. During training and inference, comparisons are prioritized based on the fingerprint rather than the original tool name. Simultaneously, similarity and historical log mining of confusion sets (hard negatives) are combined to systematically train the model to distinguish the boundaries of similar tools.

[0103] 3. Practical Tasks and Optimizations: Training data covers a mixed distribution of "single tool selection / multiple tool combinations / no invocation," and is fixed within the TopK candidate set for decision-making, reducing training-inference mismatch. SFT learning is first used for structured selection and parameter generation, followed by GRPO / preference optimization to reinforce key bad cases on the confusion set. Rewards consider format, tool selection correctness, and parameter executability simultaneously.

[0104] 4. Parameter Alignment and Executability Validation: After the model outputs `function_call`, a parameter aligner (alias mapping, type conversion, regular expression / enumeration validation) and lightweight executable checks (required fields, permissions, idempotency, etc.) are introduced. For missing or uncertain parameters, clarification questions or automatic reselection tools are triggered, improving the success rate of a single call. Through a "retrieval and filtering + fingerprint comparison + validation closed loop," the reliability of single-round tool calls is significantly improved while maintaining a controllable Prompt length, and it adapts to the dynamic evolution of the tool library.

[0105] For the foregoing method embodiments, in order to simplify the description, they are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, because according to this application, some steps can be performed in other orders or simultaneously. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are all preferred embodiments, and the actions and modules involved are not necessarily essential to this application.

[0106] The methods described in the above-disclosed embodiments of this application are detailed in terms of the methods. The methods of this application can be implemented by various forms of apparatus. Therefore, this application also discloses an apparatus. Specific embodiments are given below for detailed description.

[0107] Figure 7 This is a schematic diagram of the structure of a tool calling device disclosed in an embodiment of this application. See also... Figure 7 As shown, the tool invocation device 70 may include:

[0108] The data acquisition module 701 is used to acquire query data input by the user.

[0109] Specification determination module 702 is used to generate structured tool requirement specifications based on the query data.

[0110] The candidate set determination module 703 is used to determine a set of candidate tools from a pre-built tool vector library based on the tool requirement specification. The set of candidate tools includes several candidate tools that meet the matching degree condition with the tool requirement specification. The matching degree between the tools in the tool vector library and the tool requirement specification is determined based on the tool fingerprint of the tools in the tool vector library.

[0111] The result acquisition module 704 is used to input the candidate tool set into a pre-trained first model to obtain the tool selection result output by the first model.

[0112] The tool invocation device described in this embodiment first uses the structured tool requirement specifications of the query data, then determines a set of candidate tools from a tool vector library containing tool fingerprints of all tools based on the tool requirement specifications, and finally determines the tool selection result based on the candidate tool set. Since the structured tool requirement specifications standardize the query requirements, and the tool fingerprints in the tool vector library are uniquely identifiable, the problem of inaccurate tool search results that may occur when query data lacks standardized elements and when querying tools based solely on tool names is avoided, thereby improving the accuracy of the tool selection result.

[0113] In one implementation, the specification determination module can be used to: extract setting data from the query data, the setting data including at least one of the following: intent data, entity data, constraint data; determine hypothetical requirements based on the setting data; and generate structured tool requirement specifications based on the hypothetical requirements.

[0114] In one implementation, the apparatus further includes: a first processing module, configured to perform a first processing on the metadata of each tool to obtain a tool fingerprint of each tool, wherein the first processing at least makes each tool uniquely identifiable, and the tool fingerprint is feature data obtained by identification, extraction and fusion processing based on the tool's description data; and a vectorization module, configured to perform vectorization processing on the tool fingerprint of each tool and store the vectorized tool fingerprint in a tool vector library.

[0115] In one implementation, the first processing module can be specifically used to: perform a unified name mapping process on parameters used to represent the same meaning in different tools, and extract the constraint data of the corresponding parameters to obtain first data containing parameter names and constraint data; extract the calling conditions of the current tool based on the tool's description data; obtain fingerprint text based on the tool's description data; obtain fused data based on the first data, the calling conditions, and the fingerprint text; and perform vectorization processing on the fused data to obtain the tool fingerprint.

[0116] In one implementation, the training process of the first model includes: obtaining a set of candidate tools based on given query data; constructing a training data set based on the set of candidate tools; and training based on the training data set until a first model that meets the convergence condition is obtained.

[0117] In one implementation, constructing a training data set based on the candidate tool set includes at least one of the following: selecting a first number of tools from the tool vector library that have the highest similarity to the target tool in the candidate tool set but are unusable; combining the first number of tools with the given query data to form training data; wherein, an unusable tool is characterized by the tool differing from the target tool in at least one of the following: the tool's parameters, the tool's invocation conditions, or the fingerprint text corresponding to the tool's description data; backtracking the corresponding candidate tool set from the historical tool selection error data, and combining each candidate tool in the backtracked candidate tool set with the given query data to form training data.

[0118] In one implementation, training the first model further includes: constructing a confused data set based on the target tool corresponding to the given query data, including: performing a second processing based on the structured name and description information of the target tool to obtain an approximate tool, wherein the given query data, the approximate tool and the target tool constitute the confused data set, and the confused data set belongs to the training data set of the first model.

[0119] In one implementation, the apparatus may further include: a result feedback module, used to obtain the tool invocation result, generate training samples labeled with the corresponding result based on the invocation result, and incrementally update the training samples to the obfuscated data set.

[0120] In one implementation, the apparatus may further include: a verification processing module, used to verify the tool and / or parameters corresponding to the tool selection result obtained from the first model before outputting the tool selection result, and output the tool selection result that passes the verification; wherein the verification includes at least one of the following: parameter format verification, parameter constraint data verification, and tool invocation condition verification.

[0121] The specific implementation of the above-mentioned tool invocation device and its various modules, as well as other possible implementations, can be found in the relevant sections of the method embodiments, and will not be repeated here.

[0122] The tool invocation device described in the above embodiments includes a processor and a memory. The data acquisition module, specification determination module, candidate set determination module, result acquisition module, first processing module, vectorization module, result feedback module, and verification processing module in the above embodiments are all stored as program modules in the memory. The processor executes the above program modules stored in the memory to realize the corresponding functions.

[0123] The processor contains a kernel, which retrieves the corresponding program modules from memory. One or more kernels can be configured, and the processing of accessed data can be achieved by adjusting kernel parameters.

[0124] The memory may include non-permanent memory in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM, and the memory includes at least one memory chip.

[0125] In an exemplary embodiment, a computer-readable storage medium is also provided, which can be directly loaded into the internal memory of a computer, and contains software code that, after being loaded and executed by the computer, can implement the steps shown in any of the embodiments of the tool invocation method described above.

[0126] In an exemplary embodiment, a computer program product is also provided, which can be directly loaded into the internal memory of a computer and contains software code. After being loaded and executed by the computer, the computer program can implement the steps shown in any embodiment of the tool invocation method described above.

[0127] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For the apparatus disclosed in the embodiments, since they correspond to the methods disclosed in the embodiments, the description is relatively simple; relevant parts can be referred to the method section.

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

[0129] The steps of the methods or algorithms described in conjunction with the embodiments disclosed herein can be implemented directly by hardware, a software module executed by a processor, or a combination of both. The software module can be located in random access memory (RAM), main memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disk, removable disk, CD-ROM, or any other form of storage medium known in the art.

[0130] The above description of the disclosed embodiments enables those skilled in the art to make or use this application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this application. Therefore, this application is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A tool invocation method, the method comprising: Obtain the query data input by the user; A structured tool requirements specification is generated based on the query data; Based on the tool requirement specification, a set of candidate tools is determined from a pre-built tool vector library. The set of candidate tools includes several candidate tools that meet the matching degree condition with the tool requirement specification. The matching degree between the tools in the tool vector library and the tool requirement specification is determined based on the tool fingerprint of the tools in the tool vector library. The candidate tool set is input into a pre-trained first model to obtain the tool selection result output by the first model.

2. The tool invocation method according to claim 1, wherein generating a structured tool requirement specification based on the query data includes: Extract specified data from the query data, wherein the specified data includes at least one of the following: intent data, entity data, and constraint data; Based on the aforementioned set data, hypothetical requirements are determined; A structured tool requirement specification is generated based on the hypothetical requirements.

3. The tool invocation method according to claim 1, wherein the construction of the tool vector library includes: The metadata of each tool is first processed to obtain the tool fingerprint of each tool. The first processing makes each tool uniquely identifiable. The tool fingerprint is feature data obtained by identifying, extracting and fusing the tool's description data. The tool fingerprints of each tool are vectorized, and the vectorized tool fingerprints are stored in the tool vector library.

4. The tool invocation method according to claim 3, wherein the first processing of the metadata of each tool to obtain the tool fingerprint of each tool includes: For parameters used to represent the same meaning in different tools, a unified name mapping process is performed, and the constraint data of the corresponding parameters is extracted to obtain the first data containing parameter names and constraint data; Extract the current tool's invocation conditions based on the tool's description data; obtain fingerprint text based on the tool's description data; Based on the first data, the calling conditions, and the fingerprint text, fused data is obtained; The fused data is vectorized to obtain the tool fingerprint.

5. The tool invocation method according to claim 1, wherein the training process of the first model includes: A set of candidate tools is obtained based on the given query data; A training data set is constructed based on the candidate tool set; The training is performed based on the training dataset until a first model that meets the convergence condition is obtained.

6. The tool invocation method according to claim 5, wherein the training data set is constructed based on the candidate tool set, comprising at least one of the following: selecting a first number of tools from the tool vector library that are most similar to the target tool in the candidate tool set but are not available, and combining the obtained first number of tools with the given query to form training data, respectively, wherein, An unavailable tool is characterized by the fact that the tool differs from the target tool in at least one of the following: the tool's parameters, the tool's invocation conditions, or the fingerprint text corresponding to the tool's description data; The corresponding candidate tool set is backtracked from the historical tool selection error data, and each candidate tool in the backtracked candidate tool set is combined with the given query data to form training data.

7. The tool invocation method according to claim 5 further includes: Construct an obfuscated data set based on the target tool corresponding to the given query data, including: A second process is performed based on the structured name and description information of the target tool to obtain an approximate tool. The given query data, the approximate tool, and the target tool constitute a confused data set, which belongs to the training data set of the first model.

8. The tool invocation method according to claim 7, after obtaining the tool selection result output by the first model, further includes: Obtain the tool call result, generate training samples labeled with the corresponding result based on the call result, and incrementally update the training samples into the obfuscated data set.

9. The tool invocation method according to claim 1, further comprising, before outputting the tool selection result: The tools and / or parameters corresponding to the tool selection results obtained from the first model are validated, and the tool selection results that pass the validation are output. The verification includes at least one of the following: parameter format verification, parameter constraint data verification, and tool invocation condition verification.

10. A tool invocation device, the device comprising: The data acquisition module is used to acquire the query data input by the user; The specification determination module is used to generate structured tool requirement specifications based on the query data; The candidate set determination module is used to determine a set of candidate tools from a pre-built tool vector library based on the tool requirement specification. The set of candidate tools includes several candidate tools that meet the matching degree condition with the tool requirement specification. The matching degree between the tools in the tool vector library and the tool requirement specification is determined based on the tool fingerprint of the tools in the tool vector library. The result acquisition module is used to input the candidate tool set into a pre-trained first model to obtain the tool selection result output by the first model.

Images