Large model tool calling method and device based on multiple constraint sets and electronic equipment

Abstract

The invention provides a large model tool calling method and device based on multiple constraint sets and electronic equipment. The method comprises the steps that a current constraint set comprises a permission constraint set, a state constraint set and a context constraint set; based on the current constraint set and a tool set cue word builder, obtaining a tool set cue word corresponding to the current constraint set, and generating a calling intention based on the task demand instruction and the tool set cue word; and generating a tool call description based on a cue word formed by the large language model and the call intention, and executing tool function call under the condition that grammar and semantic check of the tool call description is passed. On one hand, a current constraint set uniformly manages authority, state and context constraint conditions, and the constraints are flexibly subjected to set operation to dynamically judge the availability of a tool; and on the other hand, the tool set cue words are dynamically screened, redundancy of the tool set cue words is avoided, the calculation amount of a large language model is reduced, and the possibility of calling wrong tools is reduced.

Description

Technical Field

[0001] The present invention relates to the field of artificial intelligence technology, and in particular to a large model tool calling method, device and electronic equipment based on multiple constraint sets. Background Art

[0002] When interacting with external tools, the large language model typically uses a "question-answer" interaction paradigm: the user first expresses a requirement in natural language, and the large language model understands and infers the requirement, parsing the underlying intent into a structured description of the tool call. This structured description generally includes the name of the tool and the parameters required for the specific call. The system then dynamically calls the corresponding function or service based on this parsed result. For example, when a user requests to query a certain record, the large language model maps the "query record" requirement to a tool function such as "queryRecord" and provides the keywords or filter conditions required for the search. The system then completes the actual database query operation based on this. The above calling method greatly simplifies the interaction process between people and tools, allowing users to complete complex cross-system calling tasks with the help of the large language model simply through natural language.

[0003] In the existing large language model tool calling method, the common practice is to enumerate all the callable tool functions in the system and embed them into the prompt word. The large language model then selects the appropriate tool function based on the user's natural language input, and finally determines whether the call is legal through permission or status verification.

[0004] However, such a process has several major problems. First, the system often lacks strict judgment on user permissions and system status when making function call decisions. As long as the large language model "sees" a tool function, it may try to call it, regardless of whether the user has legal permission to access the tool. Secondly, in some application scenarios, the availability of the tool is closely related to the state of the business process, such as "editing operations are only allowed in the edit state", but existing methods are usually rough or even absent in the management of such state constraints. Thirdly, in the interactive prompt words between the large language model and the tool, if no filtering is done, the descriptions of all tool functions will be provided to the model at once, resulting in lengthy and messy prompt words, increasing the risk of model generation errors or ambiguous calls, and may also slow down the model's response speed. Summary of the Invention

[0005] The present invention provides a large model tool calling method, device and electronic device based on multiple constraint sets, which are used to solve the defects of the large model tool calling method in the existing technology that lacks strict judgment of user permissions and system status, and does not screen interactive prompt words.

[0006] The present invention provides a large model tool calling method based on multiple constraint sets, comprising the following steps: Obtaining the user's task requirement instructions in natural language form; Based on the current user authority, the current system state and the current context information, a current constraint set corresponding to the task requirement instruction is constructed; the current constraint set includes a permission constraint set corresponding to the current user authority, a state constraint set corresponding to the current system state, and a context constraint set corresponding to the current context information; Based on the current constraint set and a toolset prompt word builder, a toolset prompt word corresponding to the current constraint set is obtained, and a call intent is generated based on the task requirement instruction and the toolset prompt word; the call intent includes the task requirement and a list of available tool function descriptions, wherein each tool function description includes a purpose, a name, and a list of formal parameters; Based on the large language model and the prompt words formed by the calling intention, a tool calling description is generated, and the tool calling description is subjected to grammatical and semantic checks. If the grammatical and semantic checks pass, the tool function call corresponding to the tool calling description is executed.

[0007] According to a large model tool calling method based on multiple constraint sets provided by the present invention, the method further includes: Storing the current constraint set and the tool set prompt word corresponding to the current constraint set in a tool set prompt word cache area; The step of determining the content of the tool set prompt word buffer area includes: Obtaining a current constraint set and an initial tool set corresponding to each constraint in the current constraint set; determining a candidate toolset based on a union and / or intersection between the plurality of initial toolsets; The current constraint set is used as a key, and the prompt word of the candidate toolset is used as a value to form a key-value pair and store it in the toolset prompt word cache.

[0008] According to a large model tool calling method based on multiple constraint sets provided by the present invention, the method uses the current constraint set as a key and the prompt word of the candidate tool set as a value to form a key-value pair and stores it in the tool set prompt word cache area, and further includes: filtering the candidate toolset based on required constraints and / or prohibited constraints; The required constraints refer to a set of constraints that must be met for the tool to take effect; the prohibited constraints refer to constraints that prohibit the use of the tool.

[0009] According to a large model tool calling method based on multiple constraint sets provided by the present invention, storing the current constraint set and the tool set prompt word corresponding to the current constraint set in a tool set prompt word cache area includes: Using the current constraint set as a key value, performing a key-value pair query in the tool set prompt word cache, and if the current constraint set exists in the tool set prompt word cache, determining the tool set prompt word corresponding to the current constraint set; the tool set prompt word includes the name, parameter format, and function description of the callable tool; If the current constraint set does not exist in the tool cache, a candidate toolset corresponding to each constraint in the current constraint set is obtained, a set operation is performed on the candidate toolset using a tool filter to obtain an available toolset, the available toolset is converted into a target toolset prompt word, and the current constraint set and the target toolset prompt word are cached in the form of a key-value pair in the toolset prompt word cache.

[0010] According to a large model tool calling method based on multiple constraint sets provided by the present invention, when the syntax and semantic checks pass, executing the tool function call corresponding to the tool calling description, and then further comprising: If the tool function corresponding to the calling intention is successfully executed, the calling result information is returned; In the event that the tool function call corresponding to the calling intention fails, a log is recorded and an error message is returned to the external module or user; the error message includes at least one of an empty available toolset, a syntax error, no permission to operate, and a call timeout.

[0011] According to a large model tool calling method based on multiple constraint sets provided by the present invention, the current context information includes at least one of time, geographic location, user equipment and other business-level variables.

[0012] The present invention also provides a large model tool calling system based on multiple constraint sets, comprising the following units: An acquisition unit, used to acquire a task requirement instruction in a natural language form of a user; A construction unit, configured to construct a current constraint set corresponding to the task requirement instruction based on current user authority, current system state, and current context information; the current constraint set includes a permission constraint set corresponding to the current user authority, a state constraint set corresponding to the current system state, and a context constraint set corresponding to the current context information; A call intention generating unit is configured to obtain a toolset prompt word corresponding to the current constraint set based on the current constraint set and a toolset prompt word builder, and generate a call intention based on the task requirement instruction and the toolset prompt word; the call intention includes the task requirement and a list of available tool function descriptions, wherein each tool function description includes a purpose, a name, and a list of formal parameters; An execution unit is used to generate a tool call description based on a large language model and prompt words formed by the call intention, and to perform syntax and semantic checks on the tool call description. If the syntax and semantic checks pass, the tool function call corresponding to the tool call description is executed.

[0013] The present invention also provides an electronic 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 program, the method for calling a large model tool based on multiple constraint sets as described above is implemented.

[0014] The present invention also provides a non-transitory computer-readable storage medium having a computer program stored thereon. When the computer program is executed by a processor, the method for calling a large model tool based on multiple constraint sets as described above is implemented.

[0015] The present invention also provides a computer program product, comprising a computer program, which, when executed by a processor, implements any of the above-mentioned large model tool calling methods based on multiple constraint sets.

[0016] The present invention provides a large model tool calling method, device and electronic device based on multiple constraint sets. On the one hand, the current constraint set is a multiple constraint set, which uniformly manages multi-dimensional constraints such as authority, status, and context. By flexibly performing set operations on these constraints, the availability of the tool is dynamically judged. Compared with traditional static role mapping or complex rule configuration, this mechanism improves flexibility, scalability and adaptability. On the other hand, combined with the currently activated multiple constraint sets, the available tool function subsets are screened out in real time, and targeted tool set prompt words are generated, thereby dynamically screening the tool set prompt words to avoid tool set prompt word redundancy, not only reducing the computational complexity of the large language model, but also reducing the possibility of calling the wrong tool. In addition, the tool call description is subjected to grammatical and semantic checks. If the grammatical and semantic checks pass, the tool function call corresponding to the tool call description is executed, thereby improving the accuracy and reliability of the tool function call. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] In order to more clearly illustrate the technical solutions in the present invention or the prior art, a brief introduction is given below to the drawings required for use in the embodiments or the description of the prior art. Obviously, the drawings described below are some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0018] Figure 1 It is a flowchart of the large model tool calling method based on multiple constraint sets provided by the present invention.

[0019] Figure 2 This is the overall system architecture diagram provided by the present invention.

[0020] Figure 3 It is a structural diagram of the large model tool calling system based on multiple constraint sets provided by the present invention.

[0021] Figure 4 It is a structural schematic diagram of the electronic device provided by the present invention. DETAILED DESCRIPTION

[0022] To make the objectives, technical solutions, and advantages of the present invention more clear, the technical solutions of the present invention will be clearly and completely described below in conjunction with the accompanying drawings. Obviously, the embodiments described are only some of the embodiments of the present invention, not all of them. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making creative efforts shall fall within the scope of protection of the present invention.

[0023] In the related art, existing technologies for invoking large language models often rely on the natural language understanding capabilities of large language models to parse user requests into structured tool invocation instructions, and then invoke external tools or services through APIs (Application Programming Interfaces) or other interfaces. However, these existing technologies have significant shortcomings in terms of tool invocation efficiency, permission management, state constraints, and prompt word optimization.

[0024] First, existing technologies pass all tool function information to the large language model at once, resulting in redundant prompts and increasing the computational burden on the model during parsing and selection, potentially reducing response speed and call accuracy. Furthermore, traditional methods only perform permission and status verification after the large language model makes a function selection. If the selected tool doesn't meet the corresponding permission or status requirements at this point, not only does this waste computational resources for model inference, it can also lead to incorrect calls or unnecessary secondary verification.

[0025] Secondly, in terms of permissions management, existing technologies typically use role-based access control (RBAC) or attribute-based access control (ABAC) models. The RBAC model manages user permissions by assigning roles, but its static nature makes it difficult to cope with complex dynamic permissions requirements, especially when business process states change. While the ABAC model is more flexible, its implementation is more complex. In scenarios where large language model tools are used, developers need to implement complex permission verification logic, increasing development costs and maintenance difficulties.

[0026] Again, in terms of state constraints, existing technologies usually limit the callability of tools by hard-coding state verification logic. For example, in a document editing system, the "save" operation is only available in the "edit" state and not in the "read-only" state. However, this hard-coded approach lacks flexibility and is difficult to cope with complex business process changes. Some systems use rule engines to manage state constraints and determine the callability of tools based on predefined rules. Although rule engines provide a certain degree of flexibility, their configuration and maintenance costs are high, and in large language model tool call scenarios, rule engines usually require complex integration with external systems.

[0027] A dynamic tool selection and optimization system and method for external tool calls of large models have been proposed in the prior art. This method realizes the dynamic selection and optimization of tool calls through technologies such as multi-dimensional task analysis, tool feature space construction, and dynamic adaptive matching engine. However, this method still has some shortcomings. First, this method lacks refined management of permissions and status during the tool call process, and fails to effectively combine user permissions and system status for dynamic constraint judgment, which easily leads to unauthorized calls or tool calls in inappropriate states. Secondly, this method does not fully consider the context constraints of tool calls in the generation of prompt words. The prompt words may contain a large amount of irrelevant tool information, which increases the reasoning burden and the risk of erroneous calls of large language models. In addition, although this method introduces a dynamic optimization mechanism, it is relatively weak in the unified management of constraints and set operations, and it is difficult to flexibly deal with complex combinations of permissions, status and context constraints, resulting in insufficiently refined security and compliance control of tool calls.

[0028] When it comes to optimizing prompts, existing technologies typically provide a large language model with descriptions of all callable tools at once, resulting in lengthy and cluttered prompts. For example, the system might embed all API names, parameter formats, and function descriptions into the prompts, increasing the inference burden of the large language model. Some systems embed tool call prompts into the training data of the large language model through pre-training and fine-tuning. While this approach can reduce prompt length, it lacks flexibility and struggles to cope with dynamically changing tool sets and permission constraints.

[0029] In summary, existing large-scale language model tool invocation technologies have significant shortcomings in terms of tool invocation efficiency, permission management, state constraints, and prompt optimization. Specifically, these shortcomings include insufficient permission management, extensive state management, and lengthy and disorganized prompts. These limitations limit the effectiveness of existing technologies in large-scale model tool invocation scenarios, necessitating a new technical solution to address these issues.

[0030] Based on the above problems, the present invention provides a large model tool calling method based on multiple constraint sets. Figure 1 This is a flow chart of a method for calling a large model tool based on multiple constraint sets provided by the present invention. Figure 1 As shown, the method includes step 110 , step 120 , step 130 and step 140 .

[0031] Step 110: Obtain the user's task requirement instructions in natural language.

[0032] Specifically, a task requirement instruction in natural language format can be obtained from the user. For example, a task requirement instruction could be something like "Please schedule a meeting for me tomorrow at 9:00 AM" or "Query next month's sales data." This task requirement instruction can be obtained from an external module, which is the front-end of system interaction and is responsible for interfacing with end users or other business systems. This external module accepts the user's natural language task description or instruction and then sends an execution request to the "Tool Calling Agent." The Tool Calling Agent leverages the understanding and generation capabilities of a large language model to convert the natural language task or instruction into a function call in a computer programming language. Once the call is completed, it is responsible for returning the result to the external module. External modules often carry both user interface logic and basic security verification functions. User interface logic includes the GUI (Graphical User Interface), CLI (Command-Line Interface), HTTP (Hypertext Transfer Protocol), and API, though this is not specifically limited in this embodiment of the present invention.

[0033] Step 120, based on the current user authority, the current system state and the current context information, construct a current constraint set corresponding to the task requirement instruction; the current constraint set includes a permission constraint set corresponding to the current user authority, a state constraint set corresponding to the current system state, and a context constraint set corresponding to the current context information.

[0034] Specifically, based on the current user authority, the current system status and the current context information, a current constraint set corresponding to the task requirement instructions is constructed, wherein the current constraint set includes a permission constraint set corresponding to the current user authority, a state constraint set corresponding to the current system status, and a context constraint set corresponding to the current context information.

[0035] Here, the current constraint set is a multi-constraint set. A multi-constraint set is a set of constraints in multiple dimensions (such as permissions, status, context conditions, etc.), which can be expressed as: in, is the complete set of all possible constraint identifiers that have been registered, Indicates the currently activated constraint subset. Different from the existing public methods, the present invention proposes a unified processing of different constraints based on set operations.

[0036] Furthermore, the multiple constraint sets in this embodiment are defined within a virtual namespace, a logical space used to centrally manage various constraints (such as permissions, states, and contexts). Each constraint is uniquely identified by a string or similar format, such as "auth / modify_plan" and "state / editing."

[0037] In the virtual namespace of the present invention, each permission or state constraint is mapped to a "Constraint Identifier." For example, "auth / modify_plan" indicates the permission to modify a plan, and "state / editing" indicates that the system is in the "editing" state.

[0038] set up Represents the set of all registered constraint identifiers, namely: Among them, each All are constraint identifiers in the form of a string. Developers can register Add new constraint identifiers and describe their meanings in the system metadata.

[0039] The following describes the definitions of user permission mapping, system status mapping, and context condition mapping as examples.

[0040] 1) User permission mapping First, get the list of permissions the current user has (which can come from a database, memory cache, or other user management module). For ease of description, all state constraints are prefixed with "auth / ". If the current user's permission set is: Then each string can be mapped to " ”, and add them one by one to the current constraint set.

[0041] 2) System status mapping In complex business processes, the system often exists in different states (e.g., "Editing," "Reviewing," "Archiving," etc.). For ease of description, all state constraints are prefixed with "state / ." For example, if the system is currently in the "Editing Plan" state, then "state / editing" should be added to the constraint set.

[0042] 3) Contextual Condition Mapping Some business scenarios also impose restrictions based on time, geographic location, user device, and business-level variables (such as the "current project ID"). This invention allows for defining prefixes (such as context / and env / ) for such contextual information in the virtual namespace. When the relevant context is needed, the current constraint set can also be added.

[0043] Step 130, based on the current constraint set and the toolset prompt word builder, obtain the toolset prompt word corresponding to the current constraint set, and generate a call intent based on the task requirement instructions and the toolset prompt word; the call intent includes the task requirements and a list of available tool function descriptions, wherein each tool function description includes purpose, name and formal parameter list.

[0044] Specifically, after obtaining the current constraint set, the corresponding toolset prompt is generated based on the current constraint set and the toolset prompt builder. The toolset prompt builder uses the Builder design pattern to assemble the available toolset with the necessary business context information to generate a "toolset prompt," which is then embedded into the large model context. This prompt typically includes key information such as the tool name, invocation method, and parameter format, guiding the large language model to efficiently invoke tool functions within the permitted range. If the available toolset remains unchanged under the current constraints, the previously generated prompt can be reused, reducing recalculation costs.

[0045] After obtaining the toolset prompt, a call intent can be generated based on the task requirement instructions and the toolset prompt, where the call intent includes the task requirements and a list of available tool function descriptions, where each tool function description includes purpose, name, and formal parameter list.

[0046] Step 140, based on the large language model and the prompt words composed of the calling intention, generates a tool calling description, and performs a syntax and semantic check on the tool calling description. If the syntax and semantic check pass, executes the tool function call corresponding to the tool calling description.

[0047] Specifically, after obtaining the calling intention, the tool calling description can be generated based on the prompt words of the calling intention based on the large language model, and the tool calling description can be checked for syntax and semantics. If the syntax and semantic checks pass, the tool function call corresponding to the tool calling description is executed.

[0048] Among them, syntax checking detects whether the function name and parameter format output by the large language model comply with the convention; if an illegal call occurs (such as a non-existent function name or an incorrect number of parameters), an error message will be directly returned or corrections will be made.

[0049] Semantic validation is based on the current set of multiple constraints , confirm again whether the calling behavior is still in the available toolset If the large language model calls an unauthorized tool or an operation that deviates from the current state, the call will be rejected and a warning will be returned.

[0050] The method provided by an embodiment of the present invention constructs a current constraint set corresponding to a task requirement instruction based on current user permissions, current system status, and current context information; the current constraint set includes a permission constraint set, a state constraint set, and a context constraint set; then, based on the current constraint set and a tool set prompt word builder, a tool set prompt word corresponding to the current constraint set is obtained, and a call intent is generated based on the task requirement instruction and the tool set prompt word; the call intent includes a task requirement and a list of available tool function descriptions, where each tool function description includes a purpose, name, and a list of formal parameters; finally, based on a large language model and prompt words constructed by the call intent, a tool call description is generated, and the tool call description is subjected to syntax and semantic checks. If the syntax and semantic checks pass, the tool function call corresponding to the tool call description is executed. On the one hand, the current constraint set is a multiple constraint set that uniformly manages multi-dimensional constraints such as permissions, status, and context, and dynamically determines the availability of the tool by flexibly performing set operations on these constraints. Compared to traditional static role mapping or complex rule configuration, this mechanism improves flexibility, scalability, and adaptability. Furthermore, by combining the currently activated multiple constraint sets, it filters out a subset of available tool functions in real time and generates targeted tool set prompts. This allows for dynamic selection of tool set prompts, avoiding redundant tool set prompts. This not only reduces the computational effort of large language models but also the likelihood of calling the wrong tool. Furthermore, tool call descriptions are subjected to syntax and semantic checks. If these checks pass, the corresponding tool function is executed, improving the accuracy and reliability of tool function calls.

[0051] Based on the above embodiment, the method further includes: Step 20: storing the current constraint set and the tool set prompt word corresponding to the current constraint set in a tool set prompt word cache area; The step of determining the content of the tool set prompt word buffer area includes: Step 210: Obtain the current constraint set and the initial tool set corresponding to each constraint in the current constraint set; Step 220 , determining a candidate toolset based on the union and / or intersection of the multiple initial toolsets; Step 230 : Using the current constraint set as a key and the prompt word of the candidate toolset as a value, a key-value pair is constructed and stored in the toolset prompt word cache.

[0052] Specifically, the current constraint set and the toolset prompt words corresponding to the current constraint set can be stored in the toolset prompt word cache. Among them, the toolset prompt word cache is specifically used to cache the "toolset prompt words" generated under different constraint combinations (such as different user permissions, system status). When the system detects that a set of constraints matches an existing record in the cache, it can skip part of the construction process and read the previously generated prompt words directly from the cache to improve overall performance and reduce latency. The caching mechanism also supports efficient retrieval based on the hash value or other identifiers of the constraint set. Tool function set: external functions or business modules that can actually be called in the system. Such as "create plan", "update plan", "get order information", etc. Each tool contains corresponding calling interface, parameter description and other meta information.

[0053] The tool function set contains the business logic or external service interfaces that the system can actually call. Each tool function is accompanied by metadata such as its name, parameter descriptions, and return value type. For example, operations such as "Create Plan," "Update Plan," and "Get Order Information" can all be registered in this set. When a tool-calling agent ultimately decides to call a tool function, the system locates and executes its implementation logic through reflection or dynamic scheduling, completing access to external resources or logical services.

[0054] Here, the steps for determining the content of the tool set prompt word cache area include: Get the current constraint set and the initial toolsets corresponding to the constraints in the current constraint set. Then, based on the union and / or intersection of multiple initial toolsets, determine the candidate toolsets. Finally, use the current constraint set as the key and the prompt word of the candidate toolset as the value to form a key-value pair and store it in the toolset prompt word cache.

[0055] Based on the above embodiment, step 230 may further include: Step 231 , filtering the candidate toolset based on required constraints and / or prohibited constraints; In step 232, the required constraints refer to a set of constraints that must be satisfied for the tool to be effective; the prohibited constraints refer to constraints that prohibit the use of the tool.

[0056] Specifically, a mapping relationship is established between the previously created toolset and the corresponding constraint identifier to record "the toolset available when a certain constraint is met." In formal description, a mapping function can be defined: in, is the set of constraint identifiers, express All subsets (i.e. power sets) of . For each constraint , both Correspondingly, it means that when the constraint When activated, the system enables a subset of tool functions by default .

[0057] In actual implementation, a dictionary (such as Python's dict) can be used to store this mapping relationship: # Initialize tool constraint registry TOOL_CONS_REGISTRY = {} #Register toolset constraints TOOL_CONS_REGISTRY["auth / modify_plan"] = my_tools TOOL_CONS_REGISTRY["state / editing"] = your_tools Here, "auth / modify_plan" and "state / editing" are mapped to different tool sets. For example, if the "auth / modify_plan" constraint is activated, the system can enable the two tool functions "foo1" and "foo2." Furthermore, when building more complex business logic, set operations can be used.

[0058] In addition to directly mapping tool sets to specific constraint identifiers (i.e., "which tools are available when a certain constraint is activated"), the present invention also supports specifying "Required Constraints" and "Forbidden Constraints" for each tool.

[0059] 1) Required constraints ( ) For tools , you can specify a set of constraints that must be met for it to take effect. For example, the "Update Plan" tool is only available if both the "auth / modify_plan" and "state / editing" constraints are activated; or "the file must be open and the user must have editing permissions." In other words, if Then only if: When established, tools To be called.

[0060] 2) Prohibition of restraint ( ) Disable constraints means that when certain constraints are activated, the tool Should be prohibited. For example, "Prohibit modification operations when the document is in the archived state." For another example, the "Create Schema" tool is unavailable when the "state / editing" constraint is activated. In this case, you can specify: . like , Tools Excluded by the filter. In other words, we can specify a tool constraint for each tool in the tool constraint registry. Two subsets are recorded: The following criteria correspond to the required and prohibited constraints respectively. The tool availability is quickly determined by the following criteria: in, Represents an element in the set of available tools.

[0061] Based on the above embodiment, step 20 of storing the current constraint set and the tool set prompt word corresponding to the current constraint set in the tool set prompt word cache includes: Using the current constraint set as a key value, performing a key-value pair query in the tool set prompt word cache, and if the current constraint set exists in the tool set prompt word cache, determining the tool set prompt word corresponding to the current constraint set; the tool set prompt word includes the name, parameter format, and function description of the callable tool; If the current constraint set does not exist in the tool cache, a candidate toolset corresponding to each constraint in the current constraint set is obtained, a set operation is performed on the candidate toolset using a tool filter to obtain an available toolset, the available toolset is converted into a target toolset prompt word, and the current constraint set and the target toolset prompt word are cached in the form of a key-value pair in the toolset prompt word cache.

[0062] Specifically, the current constraint set is used as the key value to query the tool set prompt word cache. If the current constraint set exists in the tool set prompt word cache, the tool set prompt word corresponding to the current constraint set is determined. The tool set prompt word includes the name of the callable tool, the parameter format and the function description. That is, after obtaining the constraint set After that, the system first tries to check whether the tool set prompt word cache already exists. The corresponding tool description (i.e., the explanatory text for the list of available tools). If a previously constructed "Toolset Hint" is already saved in the cache, it can be reused directly, skipping the filtering process to reduce repeated calculations and improve performance.

[0063] Formally speaking, if we define a cache mapping: in, for The power set of represents all possible constraint sets. If it exists, it means that the constraint set can be obtained in the cache. Matching prompt string If it does not exist, go to the next step of filtering to generate a new prompt word.

[0064] If the current constraint set does not exist in the tool cache, obtain the candidate toolset corresponding to each constraint in the current constraint set, use the tool filter to perform set operations on the candidate toolset to obtain the available toolset, convert the available toolset into the target toolset prompt word, and cache the current constraint set and the target toolset prompt word in the form of a key-value pair in the toolset prompt word cache.

[0065] If there is no prompt word in the cache, the system will call the tool filter and query the available tool set in the tool constraint registry according to the current constraint U. The above formula represents the set of all tool functions registered in the system. , the required constraints can be found in the tool constraint registry and prohibition constraints The following expression tool can be used Availability: in, Represents a "subset of available tools". This formula explains: 1. If Not true, which means that the tool is not currently satisfied If all the required constraints are met, the tool is excluded; 2. If If it is not empty, it means the tool is triggered. If a disabling condition is met, the tool should also be excluded.

[0066] For all registered utility functions in the system, let: Identifies the mapping of constraints to a subset of tools. Tool filters determine the final set of available tools through set operations. .

[0067] If T'=∅, it means that no tools are available under the currently activated constraints. At this time, the system can throw an exception of "the available toolset is empty" or return a prompt to the user / large language model that the execution cannot be performed.

[0068] Based on the above embodiment, in step 140, if the syntax and semantics check passes, executing the tool function call corresponding to the tool call description, then further includes: If the tool function corresponding to the calling intention is successfully executed, the calling result information is returned; In the event that the tool function call corresponding to the calling intention fails, a log is recorded and an error message is returned to the external module or user; the error message includes at least one of an empty available toolset, a syntax error, no permission to operate, and a call timeout.

[0069] Specifically, if the tool function corresponding to the call intention is successfully called, the call result information is returned. For example, if the syntax and semantic checks are passed, the system will use the reflection mechanism (or equivalent technology of dynamic scheduling) to execute the specific tool function call. Suppose the called tool is , whose parameters are At the program implementation level, the function implementation can be found and called through name reflection or function pointers to complete the corresponding logic.

[0070] Formally speaking, let The above formula represents the tool function The actual calling process.

[0071] In the event that the tool function call corresponding to the call intention fails, a log is recorded and an error message is returned to the external module or user, wherein the error message includes at least one of the available toolset being empty, syntax error, no permission to operate, and call timeout.

[0072] For example: Success scenario: return information such as {"status": "success", "data": ...}; Failure scenario: Returns descriptions such as {"status": "error", "message": "Tool unavailable"}.

[0073] Based on the above embodiment, the current context information includes at least one of time, geographic location, user equipment and other service-level variables.

[0074] Specifically, the current context information includes at least one of time, geographic location, user equipment, and other service-level variables.

[0075] The method provided by the embodiments of this invention achieves more flexible, efficient, secure, and easy-to-maintain context management by defining a set of constraints for context information. This design not only improves system performance and user experience, but also provides strong support for the implementation of complex business scenarios while reducing development and deployment costs.

[0076] Based on any of the above embodiments, Figure 2 This is the overall system architecture diagram provided by the present invention, such as Figure 2 As shown in the figure, the overall system architecture includes external modules, large language models, tool calling agents, tool function sets, toolset description builders, tool filters, toolset description caches, and tool constraint registries.

[0077] The external module is at the front end of system interaction, responsible for connecting with end users or other business systems. It accepts natural language task descriptions or instructions entered by users and then sends execution requests to the "Tool Calling Agent." The Tool Calling Agent leverages the understanding and generation capabilities of a large language model to convert the natural language tasks or instructions into function calls in a computer programming language. Once the call is completed, it is responsible for returning the results to the external module.

[0078] The large language model is the core model for natural language understanding and generation in the system. It uses semantic parsing and reasoning based on user task descriptions to determine when external tools need to be called. Specifically, the tool-calling agent first combines the input task description with the description of the callable function to form a tool-calling context. Then, when the large model determines based on this context that the current requirement requires external logic or data query, it generates a corresponding "tool-calling intent," including the target tool function name and required parameters. Finally, the tool-calling agent performs the actual function call based on the program's runtime environment.

[0079] The tool call agent is located in the core scheduling position of the tool call system and is responsible for organizing the execution of the entire call process. Its main responsibilities include: 1) Collect and summarize multiple constraints in the current context (such as user permissions, system status, etc.) to form an activated constraint set.

[0080] 2) Interact with the "Tool Filter" to obtain the external tools available under this constraint set.

[0081] 3) Call the "Toolset Prompt Word Builder" to generate or retrieve the corresponding prompt words to pass the available tool information to the large language model.

[0082] 4) Parse the tool call instructions returned by the large model, perform further syntax and semantic checks, and ultimately decide whether to initiate an actual call to the "tool function set".

[0083] The tool constraint registry stores the "required constraints" and "disallowed constraints" corresponding to all tool functions. Required constraints specify the permissions or status under which the tool can be called, while prohibited constraints indicate the circumstances under which the tool should be denied. Through unified registry management, the system facilitates the maintenance and expansion of various business logic.

[0084] The tool filter uses the "Tool Constraint Registry" and the "Current Constraint Set" as inputs. Using set operations, it determines which tools satisfy required constraints and do not trigger prohibited constraints, resulting in a dynamically adjusted subset of available tools. This module allows the system to hide irrelevant or unauthorized tool descriptions in prompts, improving the efficiency of large model calls while reducing the risk of errors or unauthorized operations.

[0085] The toolset prompt builder uses the Builder design pattern to assemble the available toolset with necessary business context information to generate a "toolset prompt," which is then embedded into the large model context. This prompt typically includes key information such as the tool name, invocation method, and parameter format, guiding the large model to efficiently invoke tool functions within permitted limits. If the available toolset remains unchanged within the current constraints, previously generated prompts can be reused, reducing recalculation costs.

[0086] The toolset prompt word cache is specifically used to cache "toolset prompt words" generated under different constraint combinations (such as different user permissions and system status).

[0087] Through the close collaboration of the above modules, the present invention establishes a tool call management mechanism based on multiple constraint sets in the large language model application scenario. On the one hand, the system uses the "tool constraint registry" and "tool filter" to ensure that the tool will only be exposed to the large model when the corresponding permissions or status are met; on the other hand, with the help of the "tool set prompt word builder" and the ingenious design of the cache area, the prompt information that needs to be processed by the large model is simplified as much as possible, thereby reducing the model's inference time and reducing the probability of incorrect calls. This architecture not only achieves the goal of fine-grained control in terms of access security and operational compliance, but also improves the execution efficiency of tool calls and user experience through prompt word construction and cache optimization.

[0088] The core of the method provided by the embodiment of the present invention is to use multiple constraint sets to accurately limit the callable tool functions of large models, thereby achieving higher security and flexibility in authority management and business process management, and realizing a complete closed loop from receiving user needs to securely executing external tools.

[0089] Based on any of the aforementioned embodiments, to better illustrate the specific implementation of the "multiple constraint sets" proposed in this invention in tool call management, the system operation process is divided into two main processes: "Process A: Constraint Registration Process" and "Process B: Tool Call Process." The former is primarily responsible for registering and mapping various constraints such as permissions and status, as well as tool functions, providing a queryable and scalable basic data structure for subsequent calls. The latter dynamically generates prompt information about available tool sets when an external module or large model actually initiates a call, and performs rigorous semantic and syntactic validation of the call behavior based on the current context and constraint sets, thereby ensuring system security and availability. These two processes are described in detail below.

[0090] Process a: Constraint registration process Step a1: Define constraint identifiers Step a2: Register tool function Callable utility functions in the system are registered in a "utility function set." A utility function set is a collection where each item is a description of a utility function. At runtime, the system can call the tools using the description of the utility function and the reflection mechanism.

[0091] The callable tool functions in the system are registered in a structure called "tool function set". The tool function set can be registered with the symbol It is defined as: Among them, each Represents a callable utility function (or its encapsulation information). These utility functions can be called at runtime through reflection or dynamic scheduling. For example, in Python, you can The description is a list or dictionary that stores meta-information such as function name, parameter types, and implementation module. Through this registration process, the system has a global "mapping table" of all available tool functions, and can subsequently dynamically call the corresponding function logic based on the name and parameters.

[0092] Step a3: Define the toolset In some business scenarios, it may be necessary to group or combine tool functions to form a "ToolSet" for batch management at the level of permission or status constraints.

[0093] When you need to integrate available tools across multiple dimensions to cover a wider range of possibilities, you can perform a union operation on each initial tool set. For example, when you need to meet multiple business scenarios simultaneously and want all tools that meet any scenario to be included in the candidate list, performing a union operation on the tool subsets for these scenarios can best preserve the available tools.

[0094] When tool availability requires multiple dimensions (e.g., specific permissions and a specific state), perform an intersection operation on the initial tool sets. For example, if a tool is only available when the user has "Administrator permissions" and the system is in an "Editable state," perform an intersection operation on the two tool sets to select a subset of tools that meet both the permissions and state requirements.

[0095] In more complex scenarios, you may need to first union some toolsets and then intersect the result with another toolset, or vice versa. This allows for flexible combination of multiple constraint dimensions and more refined control over tool availability.

[0096] set up Represents the set of all defined toolsets, where each toolset In Python, it can be simply represented by a set, as shown below: #Define two toolsets my_tools ={”foo1”, “foo2”} your_tools ={”bar1”, ”bar2”} #Define a new toolset using the union of two toolsets our_tools = my_tool_set | you_tool_set Among them, "foo1", "foo2", "bar1", and "bar2" are the names of callable tool functions.

[0097] At the mathematical level, we can abstract it as follows: given two subsets , through the union or intersection This allows you to flexibly reuse defined toolsets and build complex toolset structures that better meet business needs.

[0098] Step a4: Register toolset constraints Establish a mapping relationship between the previously created toolset and the corresponding constraint identifier to record "the toolset available when a certain constraint is met". In the formal description, a mapping function can be defined in, is the set of constraint identifiers, express All subsets (i.e. power sets) of . For each constraint , both Correspondingly, it means that when the constraint When activated, the system enables a subset of tool functions by default .

[0099] Required constraints: For a tool , if it wants to be called, it must satisfy a predefined subset of required constraints 。Recorded as when , it indicates that the current context satisfies the required constraints of this tool. In other words, the required constraints clearly define the conditions under which the tool can be called and are the core of pre-call judgment.

[0100] Prohibited constraints: The subset of constraints involved when the tool cannot be called is denoted as when , it indicates that the current context triggers a prohibition condition and the tool should be rejected. In contrast to the required constraints, the prohibition constraint subset is used to indicate "under what conditions the tool should not be called".

[0101] In actual implementation, you need to pay attention to details such as module encapsulation, error handling, caching, etc. For example, before registering tool constraints, you need to ensure that The corresponding function name exists in the ,to avoid abnormal situations such as mapping to invalid tools.

[0102] Through the four steps described above, the present invention completes a series of actions in the "constraint registration process," from defining constraint identifiers, registering tool functions, assembling toolsets, and establishing mappings between toolsets and constraints. These operations ultimately build a queryable, extensible, and composable constraint-tool mapping structure for the system. This allows the system to quickly determine which tool functions are available under the current constraints, thereby enabling refined management and control of tool calls.

[0103] Processing flow b: Tool calling process When an external module or a large model makes a call request, the system needs to dynamically determine the available tools and generate a concise prompt for them based on the multiple constraint sets activated in the current context, and finally execute or reject the call. Represents the set of all constraint identifiers registered in the system (see "Processing Flow a"), let A set of constraints that are currently active (user permissions, system status, and other contextual information).

[0104] Step b1: Enter the task description.

[0105] The external module inputs a description D in natural language, such as "automatically adjust document format" or "update the solution content being edited." This description is forwarded to the tool-invoking agent, which, in conjunction with the multiple constraint set management mechanism of the present invention, determines the currently available tools in the system and generates the next prompt information for the large model.

[0106] Example scenario: Task Description: D = "Automatically adjust the document format to make the headings bold and indented"; User permissions: auths = {"modify_doc", "read_doc"}; System status: status = {"editing"}; Additional context: device_type="mobile".

[0107] Step b2: Get the current constraint set.

[0108] The tool-calling agent constructs a currently active constraint set U⊆C based on user permissions, system state, or contextual conditions. For example, if the user has the "modify_doc" and "read_doc" permissions, "auth / modify_doc" and "auth / read_doc" are added to the set, respectively. If the system is currently in the editing state "editing," "state / editing" is added. Other contextual information (such as the device type "mobile") is converted to identifiers such as "context / device_mobile." Combining these constraints, U can be formalized as: in: Represents a set of user permission constraints. It maps each permission the user actually has to an identifier prefixed with "auth / " to form a subset of all valid permission constraint identifiers. For example, if a user has the permissions "modify_doc" and "read_doc", then Add "auth / modify_doc" and "auth / read_doc" respectively.

[0109] Represents the set of state constraints the system is currently in. The system's business process states (such as "editing" and "reviewing") are uniformly mapped to identifiers prefixed with "state / " to facilitate querying and filtering in subsequent tool availability determinations.

[0110] Represents a set of contextual constraints. In addition to permissions and status, some business conditions related to time, device type, or geographic location are also converted to identifiers prefixed with "context / " and integrated into the same constraint decision logic, allowing the system to provide more flexible and refined management when tools are called.

[0111] The following example shows how to get this collection in Python pseudocode: # Get all permissions the user has, such as ["modify_plan", "read_plan"], etc. user_auths = user.authorities() # Returns a list of strings for auth in user_auths: #Use "auth / " as the permission constraint prefix constraint_str = f"auth / {auth}" current_constraints.add(constraint_str) Next, obtain the constraint set corresponding to the current system state: # Assume that system_context contains "status" to indicate the business process status, such as "editing" current_status = system_context.get("status", None) if current_status: #Use "state / " as the prefix for system state constraints constraint_str = f"state / {current_status}" current_constraints.add(constraint_str) Of course, if the system may contain multiple parallel states, they can also be added here one by one according to different fields.

[0112] Then, obtain the constraint sets corresponding to other context conditions: # Take device type as an example device_type = system_context.get("device_type", None) if device_type: # Assume that the device type is prefixed with "context / device_" constraint_str = f"context / device_{device_type}" current_constraints.add(constraint_str) You can also add more context fields based on actual business needs and map them to corresponding prefixes.

[0113] Finally, the currently active set of constraints will be maintained in current_constraints.

[0114] Step b3: Search tool set prompt words.

[0115] Based on the current constraint set, the corresponding toolset prompt word is searched from the toolset cache. If a built toolset prompt word exists, proceed to step b5; otherwise, proceed to step b4 first.

[0116] Step b4: Retrieve the available toolset.

[0117] Calls the tool filter to query the tool constraint registry for the set of available tools based on the current constraint set.

[0118] Step b5: Construct prompt words.

[0119] If the available toolset is successfully retrieved , you need to generate a toolset description string , used to pass to the large model. The description string includes the name of the callable tool, parameter format, function description, etc. It can be written as: Indicates that Each tool The text obtained by concatenating or rendering the brief information of . For example: def build_tool_prompt(tool_set): """ Receives a set of available tools tool_set (e.g. {"foo1", "bar2"}), Generate a prompt string S for the large model """ # Example assembly method lines = [] for tool in tool_set: lines.append(f"Tool name: {tool}, Function description: ... Parameter format: ...") return "\n".join(lines) The tool calling agent will then pass this "toolset description" Task description entered by the user Merge and construct tool call prompts that will eventually be handed over to the large language model. This prompt usually instructs the large model: "You can use these tools to implement the task description under the following constraints or scenarios." If this prompt word can be reused, the system will also Write the tool set prompt word cache area for quick reuse in similar contexts.

[0120] Step b6: Check tool call syntax and semantics.

[0121] Step b7: Execute the call of the tool function.

[0122] Step b8: Return the result or handle the error.

[0123] In the core technical solutions described above, this invention primarily focuses on refined management of tool invocations using "multiple constraint sets" and "large language models." However, to accommodate different business needs, model types, or infrastructure constraints, several alternative solutions are provided below, all of which achieve similar or identical objectives without departing from the core principles of this invention.

[0124] Replace the "large language model" with a multimodal large model: In the foregoing, the large language model mainly processes natural language input and generates call intent. If the actual scenario requires processing richer input forms (such as images, audio or video), the plain text large language model can be replaced with a "multimodal large model". The multimodal model can also interact with external modules through prompts, but its input may contain multimodal information such as image or voice features, and the output can still be a structured tool call description. The management mechanism of multiple constraint sets remains unchanged in this scenario, and still provides conditional filtering such as permissions and status for tool calls, but the contextual information that needs to be parsed is more complex. By injecting metadata unique to the multimodal model into the prompt or context, the present invention can also limit the availability of tools under specific permissions and status.

[0125] Introducing microservices or distributed architecture: In this implementation, modules such as the tool invocation agent, tool filter, and toolset prompt builder can be centrally deployed within the same system or split into several microservices. For large-scale enterprise applications, the "tool constraint registry" and "tool filter" can be implemented as independent microservices to support horizontal scalability and high-availability deployment. As long as the current constraints (user permissions, status, etc.) are retrieved and tool filtering is completed during each invocation, the same call management effect can be achieved.

[0126] Use a custom prompt word strategy or multi-stage prompts instead: In the previous solution, the system often uses the Builder pattern to generate a complete "toolset prompt" in one go, which is then fed into a large (multimodal) language model. Some scenarios may require a more flexible, multi-stage prompt: first, the model performs a preliminary intent classification of the user's needs; then, based on the classification results and a set of constraints, a specific toolset prompt is generated.

[0127] This approach also allows for different subsets of tools or descriptions to be presented to the model at different permissions and states. The core idea remains: multiple sets of constraints are used to filter or aggregate tools, ultimately instructing the large model to call the appropriate function.

[0128] Changing from "required / prohibited constraints" to "priority" or "scoring": The current solution primarily uses a logical approach: tools are enabled only if they meet required constraints and don't trigger prohibited constraints. For advanced requirements, constraints can be mapped to specific priorities or scores, allowing different tools to have different priorities in the same scenario (for example, allowing high-privilege users to prioritize certain tools under specific circumstances). Essentially, this still uses multiple constraint sets, but it's expanded to numerical values or weights, allowing for a combined "filtering + sorting" approach within tool filters.

[0129] Combine Multiple Constraint Sets with external knowledge bases or security engines: In addition to managing permissions, status, and context, "multiple constraint sets" can also be connected to enterprise-level security policies or external rule engines (such as RBAC and ABAC implementations). For example, if the system already has a powerful enterprise-level permission management module, the present invention simply maps "tool required / prohibited constraints" to the permission management module's policy, and then the external engine returns whether the call conditions are met. The core concept of the present invention, "performing set operations on multiple constraint sets and generating prompt words," is still followed, except that the acquisition and verification of permission / status data is the responsibility of the external security engine.

[0130] Applicable to non-conversational tool scheduling scenarios: While this paper primarily demonstrates the use of large language models for tool invocation management in a conversational environment, the same constraint mechanism can also be applied to non-conversational scenarios, such as batch scripts and process automation engines. As long as the current role or system state can be accessed during process execution, executable tools can be filtered according to the rules defined by the "multiple constraint sets" and corresponding process instructions can be generated, achieving safer and more sophisticated automated scheduling.

[0131] In summary, the above-mentioned alternative solutions have expanded or transformed the core ideas of the present invention at different levels, and still adhered to the main purpose of managing available tools with multiple constraint sets and generating streamlined "prompt words / instructions". Regardless of whether the large model is single-modal or multi-modal, whether the system is deployed in a single or distributed manner, or whether a more complex "scoring / priority" mechanism is used for tool screening, the advantages of the present invention in refined call management are retained. It can be seen that the present invention has strong flexibility and scalability when facing different environments and needs.

[0132] The embodiments of the present invention have the following advantages: 1. Dynamic management and unified operation of multiple constraint sets: In large-scale model tool invocation scenarios, the concept of "multiple constraint sets" is introduced to uniformly manage multi-dimensional constraints such as permissions, state, and context. By abstracting these constraints into unique identifiers in a virtual namespace (such as "auth / modify_plan" and "state / editing"), the system can flexibly perform set operations to dynamically determine tool availability. This mechanism offers significant advantages over traditional static role-based access control (RBAC) or complex rule-based access control (ABAC) in terms of flexibility, scalability, and adaptability: 1) Dynamicity: Supports dynamic adjustment of tool call logic at runtime without modifying code logic or redeploying rules.

[0133] 2) Refinement: By combining "required constraints" and "prohibited constraints", fine-grained control is provided over the security and compliance of tool calls.

[0134] 3) Scalability: Allows developers to quickly define and register constraints for any new tool or scenario, and efficiently complete tool screening through set operations.

[0135] This innovation breaks through the limitations of traditional permission management models on dynamic states in complex business processes, and provides more precise logical support for the management of large language model tool calls.

[0136] 2. Constraint-based tool set prompt word optimization: To address the issues of lengthy prompt words, high noise information, and high call ambiguity in large models, this paper proposes a "constraint-based tool set prompt word generation mechanism" that achieves significant optimization through the following innovations: 1) Dynamic Filtering: Combined with the currently activated multiple constraint sets, it filters out the available tool function subsets in real time and generates targeted tool set prompts.

[0137] 2) Optimize prompt word design: The prompt word content only contains key information such as the tool name, function description, parameter format, etc., significantly reducing the length of the prompt word to avoid errors in large model generation due to information overload.

[0138] 3) Cache reuse: Introducing a tool set prompt word cache area, directly reuse the generated prompt words in repeated scenarios, further reducing system response time and resource consumption.

[0139] By optimizing prompt words, the present invention not only improves the reasoning efficiency of large language models, but also reduces the risks of miscalls and unauthorized calls, significantly improving the user experience of tool calls.

[0140] 3. Wide adaptability and scalability The architectural design of this invention has significant advantages in adaptability and versatility, and can support a variety of business needs and application scenarios: 1) Compatible with large multimodal models: This solution is not only applicable to natural language models, but can also be extended to support large multimodal models (such as images, audio, and video). It enables cross-modal tool call management through prompt word embedding.

[0141] 2) Support for distributed architecture: System modules (such as tool call agents, tool filters, etc.) can be split into microservices to support enterprise-level distributed deployment and high availability.

[0142] 3) Integration with external permission systems: It can be combined with existing enterprise permission engines (such as RBAC, ABAC) or security policies to achieve unified management through constraint identification mapping.

[0143] This flexible architecture not only enables the present invention to be instantly applied in scenarios such as intelligent customer service and process automation, but also has the potential to be migrated to complex industrial processes, IoT platforms, and multi-scenario interactive environments.

[0144] IV. Differentiated Management Capabilities for Complex Scenarios 1) Strong binding between state and tool invocation: For example, in the "read-only" state, editing tools are prohibited from being invoked, while in the "edit" state, editing tools are activated to meet the refined requirements of business processes.

[0145] 2) Dynamic adaptation of permissions and context: The tool can dynamically adjust tool availability based on user permissions and context information, avoiding hard-coded logic and reducing development and maintenance costs.

[0146] 3) Efficiently handle complex constraint combinations: Supports the combination and exclusion logic of multiple constraint conditions (such as "X must be satisfied but Y must not be triggered"), providing support for tool call management in complex processes.

[0147] 5. Cross-industry application potential The core technology of this invention is not only applicable to common scenarios such as intelligent customer service, business process automation, and collaborative office, but can also be widely used in the following fields: 1) Intelligent scheduling systems: such as logistics and robotics scheduling, dynamically adjusting task allocation based on multiple constraints.

[0148] 2) Smart City: Manage city resource access based on multi-dimensional status (such as device status, location, and permissions).

[0149] 3) Security Audit and Risk Control: Dynamically bind permissions and status to screen compliance tool calls in real time to prevent potential risks.

[0150] In summary, by introducing multiple constraint sets and dynamic prompt word optimization mechanism, the present invention realizes the deep integration of authority management, state control and tool screening in the field of large model tool call management, significantly improves the security, efficiency and adaptability of the system, and has broad industry application value and technical prospects.

[0151] The present invention introduces the concept of multiple constraint sets to uniformly manage and judge "authority" and "status" and other contextual conditions, so that the large model can perform security and compliance checks based on these constraints before and after generating the structured description of the tool call. By maintaining a set of constraint management mechanisms based on set operations in the system, external tool functions will be forcibly bound to relevant constraints, and will only be automatically selected by the large model or system when the corresponding authority and status are met. On this basis, the list of tool functions in the prompt words will be dynamically screened and simplified to reduce interference with the model and the error call rate. These measures can not only effectively prevent unauthorized use and miscalling, but also help to shorten the length of the model's prompt words and improve overall call efficiency.

[0152] The large model tool calling system based on multiple constraint sets provided by the present invention is described below. The large model tool calling system based on multiple constraint sets described below and the large model tool calling method based on multiple constraint sets described above can be referenced to each other.

[0153] Based on any of the above embodiments, the present invention provides a large model tool calling system based on multiple constraint sets. Figure 3 This is a schematic diagram of the structure of the large model tool calling system based on multiple constraint sets provided by the present invention. Figure 3 As shown, the system includes: An acquisition unit 310 is configured to acquire a task requirement instruction in a natural language form from a user; A construction unit 320 is configured to construct a current constraint set corresponding to the task requirement instruction based on current user permissions, current system state, and current context information; the current constraint set includes a permission constraint set corresponding to the current user permissions, a state constraint set corresponding to the current system state, and a context constraint set corresponding to the current context information; A call intent generating unit 330 is configured to obtain a toolset prompt word corresponding to the current constraint set based on the current constraint set and a toolset prompt word builder, and generate a call intent based on the task requirement instruction and the toolset prompt word; the call intent includes the task requirement and a list of available tool function descriptions, wherein each tool function description includes a purpose, a name, and a list of formal parameters; The execution unit 340 is used to generate a tool call description based on the large language model and the prompt words composed of the call intention, and perform syntax and semantic checks on the tool call description. If the syntax and semantic checks pass, the tool function call corresponding to the tool call description is executed.

[0154] The system provided by the embodiment of the present invention, on the one hand, the current constraint set is a multiple constraint set, and the current constraint set uniformly manages multi-dimensional constraints such as authority, status, and context, and dynamically judges the availability of tools by flexibly performing set operations on these constraints. Compared with traditional static role mapping or complex rule configuration, this mechanism improves flexibility, scalability, and adaptability; on the other hand, combined with the currently activated multiple constraint sets, it filters out a subset of available tool functions in real time and generates targeted tool set prompts, thereby dynamically filtering the tool set prompts and avoiding redundancy of tool set prompts, which not only reduces the computational complexity of large language models, but also reduces the possibility of calling the wrong tool. In addition, the tool call description is subjected to grammatical and semantic checks. If the grammatical and semantic checks pass, the tool function call corresponding to the tool call description is executed, which improves the accuracy and reliability of the tool function call.

[0155] Based on any of the above embodiments, a cache unit is further included, and the cache unit specifically includes: A storage unit, configured to store the current constraint set and the tool set prompt word corresponding to the current constraint set in a tool set prompt word cache area; The content determination unit is further included, and the content determination unit specifically includes: A constraint set acquisition unit is used to acquire a current constraint set and an initial tool set corresponding to each constraint in the current constraint set; a candidate toolset determination unit, configured to determine a candidate toolset based on a union and / or intersection of a plurality of initial toolsets; The content determination subunit is configured to use the current constraint set as a key and the prompt word of the candidate toolset as a value to form a key-value pair and store the pair in the toolset prompt word cache.

[0156] Based on any of the above embodiments, the invention further includes a filtering unit, wherein the filtering unit is specifically configured to: filtering the candidate toolset based on required constraints and / or prohibited constraints; The required constraints refer to a set of constraints that must be met for the tool to take effect; the prohibited constraints refer to constraints that prohibit the use of the tool.

[0157] Based on any of the above embodiments, the storage unit is specifically used to: Using the current constraint set as a key value, performing a key-value pair query in the tool set prompt word cache, and if the current constraint set exists in the tool set prompt word cache, determining the tool set prompt word corresponding to the current constraint set; the tool set prompt word includes the name, parameter format, and function description of the callable tool; If the current constraint set does not exist in the tool cache, a candidate toolset corresponding to each constraint in the current constraint set is obtained, a set operation is performed on the candidate toolset using a tool filter to obtain an available toolset, the available toolset is converted into a target toolset prompt word, and the current constraint set and the target toolset prompt word are cached in the form of a key-value pair in the toolset prompt word cache.

[0158] Based on any of the above embodiments, the further embodiment includes an execution unit, wherein the execution unit is specifically configured to: If the tool function corresponding to the calling intention is successfully executed, the calling result information is returned; In the event that the tool function call corresponding to the calling intention fails, a log is recorded and an error message is returned to the external module or user; the error message includes at least one of an empty available toolset, a syntax error, no permission to operate, and a call timeout.

[0159] Based on any of the above embodiments, the current context information includes at least one of time, geographic location, user equipment, and other service-level variables.

[0160] Figure 4 Schematic diagram of the structure of the electronic device provided by the present invention, such as Figure 4 As shown, the electronic device may include: a processor (processor) 410 , a communication interface (Communications Interface) 420 , a memory (memory) 430 and a communication bus 440 , wherein the processor 410 , the communication interface 420 , and the memory 430 communicate with each other via the communication bus 440 . The processor 410 can call the logic instructions in the memory 430 to execute a large model tool calling method based on multiple constraint sets, which includes: obtaining the user's task requirement instructions in natural language form; constructing a current constraint set corresponding to the task requirement instructions based on current user permissions, current system status and current context information; the current constraint set includes a permission constraint set corresponding to the current user permissions, a state constraint set corresponding to the current system status, and a context constraint set corresponding to the current context information; based on the current constraint set and a toolset prompt word builder, obtaining a toolset prompt word corresponding to the current constraint set, and generating a call intent based on the task requirement instructions and the toolset prompt word; the call intent includes a task requirement and a list of available tool function descriptions, wherein each tool function description includes a purpose, a name and a list of formal parameters; based on a large language model and the prompt words constructed by the call intent, generating a tool call description, and performing syntax and semantic checks on the tool call description, and executing the tool function call corresponding to the tool call description if the syntax and semantic checks pass.

[0161] Furthermore, the logic instructions in the aforementioned memory 430 can be implemented as software functional units and, when sold or used as independent products, can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, or the portion that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product, stored in a storage medium, includes instructions for enabling a computer device (which can be a personal computer, server, or network device, etc.) to perform all or part of the steps of the methods described in various embodiments of the present invention. The aforementioned storage medium includes various media capable of storing program code, such as a USB flash drive, a mobile hard drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk.

[0162] On the other hand, the present invention also provides a computer program product, which includes a computer program, which can be stored on a non-transitory computer-readable storage medium. When the computer program is executed by a processor, the computer can execute the large model tool calling method based on multiple constraint sets provided by the above methods, the method including: obtaining a task requirement instruction in the form of a user's natural language; constructing a current constraint set corresponding to the task requirement instruction based on current user permissions, current system status and current context information; the current constraint set includes a permission constraint set corresponding to the current user permissions, a state constraint set corresponding to the current system status, and a context constraint set corresponding to the current context information; based on the current constraint set and a toolset prompt word builder, obtaining a toolset prompt word corresponding to the current constraint set, and generating a call intent based on the task requirement instruction and the toolset prompt word; the call intent includes a task requirement and a list of available tool function descriptions, wherein each tool function description includes a purpose, a name and a list of formal parameters; based on a large language model and the prompt words constructed by the call intent, generating a tool call description, and performing syntax and semantic checks on the tool call description, and executing the tool function call corresponding to the tool call description if the syntax and semantic checks pass.

[0163] On the other hand, the present invention also provides a non-transitory computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, is implemented to execute the large model tool calling method based on multiple constraint sets provided by the above methods, the method comprising: obtaining a task requirement instruction in the form of a user's natural language; constructing a current constraint set corresponding to the task requirement instruction based on current user permissions, current system status and current context information; the current constraint set includes a permission constraint set corresponding to the current user permissions, a state constraint set corresponding to the current system status, and a context constraint set corresponding to the current context information; based on the current constraint set and a toolset prompt word builder, obtaining a toolset prompt word corresponding to the current constraint set, and generating a call intent based on the task requirement instruction and the toolset prompt word; the call intent includes a task requirement and a list of available tool function descriptions, wherein each tool function description includes a purpose, a name and a list of formal parameters; based on a large language model and the prompt words constructed by the call intent, generating a tool call description, and performing syntax and semantic checks on the tool call description, and executing the tool function call corresponding to the tool call description if the syntax and semantic checks pass.

[0164] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units, i.e., they may be located in one location or distributed across multiple network units. Some or all of the modules may be selected based on actual needs to achieve the objectives of the present embodiment. Persons of ordinary skill in the art will be able to understand and implement the present invention without inventive effort.

[0165] Through the above description of the embodiments, those skilled in the art will clearly understand that each embodiment can be implemented using software plus a necessary general-purpose hardware platform, or of course, hardware. Based on this understanding, the essence of the above technical solution, or the portion that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, a magnetic disk, or an optical disk, and includes a number of instructions for causing a computer device (such as a personal computer, server, or network device) to execute the methods described in each embodiment or certain portions of the embodiments.

[0166] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, rather than to limit it. Although the present invention has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. However, these modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the various embodiments of the present invention.

Claims

1. A large model tool calling method based on multiple constraint sets, characterized in that: include: Obtaining the user's task requirement instructions in natural language form; Based on the current user authority, the current system state and the current context information, a current constraint set corresponding to the task requirement instruction is constructed; the current constraint set includes a permission constraint set corresponding to the current user authority, a state constraint set corresponding to the current system state, and a context constraint set corresponding to the current context information; Based on the current constraint set and a toolset prompt word builder, obtain a toolset prompt word corresponding to the current constraint set, and generate a call intent based on the task requirement instruction and the toolset prompt word; The calling intention includes task requirements and a list of available tool function descriptions, wherein each tool function description includes a purpose, a name, and a list of formal parameters; Based on the large language model and the prompt words formed by the calling intention, a tool calling description is generated, and the tool calling description is subjected to grammatical and semantic checks. If the grammatical and semantic checks pass, the tool function call corresponding to the tool calling description is executed.

2. The large model tool calling method based on multiple constraint sets according to claim 1 is characterized in that: The method further comprises: Storing the current constraint set and the tool set prompt word corresponding to the current constraint set in a tool set prompt word cache area; The step of determining the content of the tool set prompt word buffer area includes: Obtaining a current constraint set and an initial tool set corresponding to each constraint in the current constraint set; determining a candidate toolset based on a union and / or intersection between the plurality of initial toolsets; The current constraint set is used as a key, and the prompt word of the candidate toolset is used as a value to form a key-value pair and store it in the toolset prompt word cache.

3. The large model tool calling method based on multiple constraint sets according to claim 2 is characterized in that: The method uses the current constraint set as a key and the prompt word of the candidate toolset as a value to form a key-value pair and stores the pair in the toolset prompt word cache, and also includes: filtering the candidate toolset based on required constraints and / or prohibited constraints; The required constraints refer to a set of constraints that must be met for the tool to take effect; the prohibited constraints refer to constraints that prohibit the use of the tool.

4. The large model tool calling method based on multiple constraint sets according to claim 2 is characterized in that: The storing the current constraint set and the tool set prompt word corresponding to the current constraint set in a tool set prompt word cache area includes: Using the current constraint set as a key value, performing a key-value pair query in the tool set prompt word cache, and if the current constraint set exists in the tool set prompt word cache, determining the tool set prompt word corresponding to the current constraint set; the tool set prompt word includes the name, parameter format, and function description of the callable tool; If the current constraint set does not exist in the tool cache, a candidate toolset corresponding to each constraint in the current constraint set is obtained, a set operation is performed on the candidate toolset using a tool filter to obtain an available toolset, the available toolset is converted into a target toolset prompt word, and the current constraint set and the target toolset prompt word are cached in the form of a key-value pair in the toolset prompt word cache.

5. The large model tool calling method based on multiple constraint sets according to any one of claims 1 to 4, characterized in that: If the syntax and semantics check passes, executing the tool function call corresponding to the tool call description, and then further comprising: If the tool function corresponding to the calling intention is successfully executed, the calling result information is returned; In the event that the tool function call corresponding to the calling intention fails, a log is recorded and an error message is returned to the external module or user; the error message includes at least one of an empty available toolset, a syntax error, no permission to operate, and a call timeout.

6. The large model tool calling method based on multiple constraint sets according to any one of claims 1 to 4, characterized in that: The current context information includes at least one of time, geographic location, user equipment, and other service-level variables.

7. A large model tool calling system based on multiple constraint sets, characterized by: include: An acquisition unit, used to acquire a task requirement instruction in a natural language form of a user; A construction unit, configured to construct a current constraint set corresponding to the task requirement instruction based on current user authority, current system state, and current context information; the current constraint set includes a permission constraint set corresponding to the current user authority, a state constraint set corresponding to the current system state, and a context constraint set corresponding to the current context information; A call intention generating unit is configured to obtain a toolset prompt word corresponding to the current constraint set based on the current constraint set and a toolset prompt word builder, and generate a call intention based on the task requirement instruction and the toolset prompt word; The calling intention includes task requirements and a list of available tool function descriptions, wherein each tool function description includes a purpose, a name, and a list of formal parameters; An execution unit is used to generate a tool call description based on a large language model and prompt words formed by the call intention, and to perform syntax and semantic checks on the tool call description. If the syntax and semantic checks pass, the tool function call corresponding to the tool call description is executed.

8. An electronic device comprising a memory, a processor, and a computer program stored in the memory and running on the processor, characterized in that: When the processor executes the computer program, the large model tool calling method based on multiple constraint sets as described in any one of claims 1 to 6 is implemented.

9. A non-transitory computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the large model tool calling method based on multiple constraint sets as described in any one of claims 1 to 6 is implemented.

10. A computer program product comprising a computer program, characterized in that When the computer program is executed by a processor, the large model tool calling method based on multiple constraint sets as described in any one of claims 1 to 6 is implemented.

Images