Task execution method and device based on large model, storage medium and program product

Abstract

The invention provides a task execution method and device based on a large model, a storage medium and a program product, and relates to the technical field of artificial intelligence, the method comprises the following steps: extracting task description information in input prompt information of the large model, and analyzing a tool calling intention corresponding to the task description information; determining at least one candidate execution tool matched with the tool calling intention, and respectively calling each candidate execution tool; identifying whether tool illusion occurs in the running process of each candidate execution tool; determining at least one target execution tool according to each candidate execution tool and the corresponding tool illusion recognition result; and generating task execution feedback based on the operation result of each target execution tool. Therefore, by evaluating illusion in the tool running process, error result feedback caused by illusion type tool calling can be effectively reduced, and the reliability of task execution is improved.

Description

Technical Field

[0001] The present application relates to the field of artificial intelligence technology, and in particular to a task execution method, device, storage medium and program product based on a large model. Background Art

[0002] With the continuous development of artificial intelligence technology, Large Language Models (LLMs) have expanded their capabilities from language generation to interacting with external systems through tool calls, providing great potential for practical applications.

[0003] The main goal of tool learning is to enable large language models to understand and use external tools. By leveraging various tools, LLMs can improve their efficiency in solving a large number of natural language processing (NLP) tasks. In addition, more and more research is exploring how LLMs interact with real tasks through tool use, positioning tool learning as a key interface between LLMs and the physical world.

[0004] Despite these advances, challenges remain when LLMs are asked to reliably call external tools. One important challenge is the phenomenon of tool hallucination—where the model incorrectly selects or uses a tool.

[0005] Solving the tool hallucination problem is critical because it has a significant impact on multiple key aspects. First, the consequences of tool hallucinations can be more serious than traditional text-based hallucinations because tools are the interface between LLMs and the physical world. When models incorrectly select or use tools, it can lead to actions that cause physical harm or system failures, which can bring greater risks and impacts in real-world scenarios. Second, tool hallucinations generate misleading task outputs that are often more difficult to detect. Because such hallucinations occur during task execution, they are difficult to detect and can easily lead to hallucinations in the final output, significantly eroding users' trust in the reliability of the system. Finally, from an operational cost perspective, hallucinatory tool calls waste system resources, increase computing costs, and overload processes through redundant or erroneous tool calls, reducing efficiency.

[0006] The industry has not yet proposed a better solution to the above problems. Summary of the invention

[0007] The present application provides a large model-based task execution method, device, storage medium and program product, which are used to at least solve the problem of hallucination tool calling of large language models in the current related technology.

[0008] In a first aspect, an embodiment of the present application provides a task execution method based on a large model, comprising: extracting task description information from the input prompt information of the large model, and parsing the tool call intention corresponding to the task description information; determining at least one candidate execution tool that matches the tool call intention, and calling each candidate execution tool respectively; identifying whether tool hallucination occurs during the operation of each of the candidate execution tools; determining at least one target execution tool based on each of the candidate execution tools and the corresponding tool hallucination recognition results; and generating task execution feedback based on the operation results of each of the target execution tools.

[0009] In a second aspect, an embodiment of the present application provides an electronic device, comprising: at least one processor, and a memory communicatively connected to the at least one processor, wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can perform the steps of the large model-based task execution method of any embodiment of the present application.

[0010] In a third aspect, an embodiment of the present application provides a storage medium on which a computer program is stored, characterized in that when the program is executed by a processor, the steps of the large model-based task execution method of any embodiment of the present application are implemented.

[0011] In a fourth aspect, an embodiment of the present application provides a computer program product, including a computer program / instruction, which, when executed by a processor, implements the steps of the large model-based task execution method of any embodiment of the present application.

[0012] The beneficial effects of the embodiments of the present application are: When the input prompt of the large model involves the intention to call the candidate execution tool, by identifying whether the tool hallucination occurs during the operation of the candidate execution tool, the final target execution tool is determined according to the tool hallucination identification result, and the task execution feedback is generated using its operation result. Therefore, by evaluating the hallucination during the tool operation process, the erroneous result feedback caused by the hallucination tool call can be effectively reduced, and the reliability of task execution can be improved. BRIEF DESCRIPTION OF THE DRAWINGS

[0013] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, a brief introduction will be 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 application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0014] Figure 1A flowchart showing an example of a large model-based task execution method according to an embodiment of the present application is shown; Figure 2 An operation flow chart showing an example of an evaluation tool hallucination according to an embodiment of the present application; Figure 3 An operation flow chart of an example of a target execution tool according to an embodiment of the present application is shown; Figure 4 A schematic diagram showing the effects of an example of four types of tool illusions; Figure 5 It is a schematic structural diagram of an embodiment of an electronic device of the present application. DETAILED DESCRIPTION

[0015] In order to make the purpose, technical solution and advantages of the embodiments of the present application clearer, the technical solution in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of this application.

[0016] With the continuous advancement of artificial intelligence technology, some tool-enhanced language models have emerged. These technologies enable large language models (LLMs) to use external tools to perform specific tasks, such as querying databases, calling APIs, interacting with other software, etc. This type of technology aims to enhance the versatility of the model so that it is not limited to text generation tasks, but can also perform more complex operations in the real world. When calling a tool, the language model is allowed to automatically select and call appropriate external tools or resources based on the task content after receiving the task request. The tool calling process usually requires accurate selection and execution based on task requirements. In response to errors in tool calls (such as incorrect tool selection or incorrect input parameters, etc.), these technologies use specific strategies to reduce the error rate of the model when calling external tools to improve the stability and reliability of the system.

[0017] It should be noted that in tool-enhanced language models, by combining external tools (such as APIs, databases, computing software, etc.) with large models, the language model not only relies on the internal knowledge base, but also can access external resources in real time. These tools can be general (such as search engines, translation tools) or specialized (such as data analysis software, image processing tools, etc.).

[0018] In the tool calling mechanism, the language model determines the required tool by parsing the input task and automatically calls it. This requires the model to have good task recognition capabilities and be able to determine the match between the task type and the tool. In actual operation, the model will select the appropriate tool based on the task description and break the task into subtasks suitable for tool processing.

[0019] In order to solve the problem of misselection or incorrect use in tool calls, tool error control and reduction technology is used to use a variety of means (such as optimization algorithms, contextual reasoning, feedback mechanisms, etc.) to correct deviations in tool calls, ensure that the model's calling behavior is more accurate, and reduce unnecessary resource waste or erroneous results.

[0020] Although tool calls can be implemented through the above technologies, there is still the problem of "tool hallucination", that is, large models sometimes select the wrong tool or use incorrect parameters or methods when calling the tool. Such errors not only affect the task success rate of the model, but may also cause incorrect behavior of physical devices or systems, which in turn has serious consequences. In addition, unlike the hallucinations generated by traditional text, tool hallucinations occur during the task execution phase and are usually difficult to detect and correct, resulting in the final result misleading the user. In addition, unnecessary tool calls and incorrect tool use not only waste computing resources, but also increase the cost of task execution and reduce the overall efficiency of the system.

[0021] It should be noted that recent advances in tool learning have enabled LLMs to effectively integrate external tools, thereby enhancing real-time knowledge retrieval, multimodal capabilities, and domain expertise. Approaches range from leveraging tool descriptions and examples in contextual learning to explicit training on tool-rich datasets. The evaluation of tool-enhanced LLMs mainly focuses on indicators such as tool invocation accuracy and task success rate, usually with more emphasis on the execution level. However, there is limited research on the critical issue of tool hallucination, which may undermine the reliability and credibility of tools in real-world applications.

[0022] In view of this, in this paper, the concept of reliable tool invocation is proposed for the first time, tool illusion is systematically examined, and the causes and types of tool illusion are explained, so as to provide strategies to reduce these errors to improve the reliability of LLM tool invocation.

[0023] Figure 1 A flowchart of an example of a large model-based task execution method according to an embodiment of the present application is shown.

[0024] like Figure 1 As shown, in step S110, the task description information in the input prompt information of the large model is extracted, and the tool calling intention corresponding to the task description information is parsed.

[0025] In some embodiments, task requirements are extracted from user input by using natural language processing technology, such as lexical analysis, syntactic analysis, etc., to decompose the input prompt information into words, phrases, and sentence structures, and then perform task classification (such as query, calculation, reasoning, etc.).

[0026] In step S120, at least one candidate execution tool matching the tool calling intention is determined, and each candidate execution tool is called respectively.

[0027] In one example of the embodiment of the present application, the selection and invocation of tools can be determined by a set of predefined rules, which can be manually written by human experts based on the characteristics of the task (such as task type, input content, etc.). The rule engine analyzes each task according to these rules and determines which tool to use. In this way, through the preset rules, the behavior of the system is very predictable, and the user can clearly understand the basis for each step of the operation.

[0028] In another example of the embodiment of the present application, the most appropriate tool is selected according to the task type and requirements through a trained decision model, and the decision model may make a judgment based on the characteristics of the tool and the context information of the task. Specifically, the system automatically analyzes the task type and selects a suitable tool to perform the task based on the task input by the user. For example, for a query task, the system selects an information retrieval tool; for a calculation task, a calculation tool is selected, etc.

[0029] The description of candidate execution tools is as follows: On the one hand, the tool call intention can indicate the call of one or more tools. For example, a complex prompt instruction may require the coordinated call of multiple tools to meet feedback requirements. On the other hand, the tool call intention may not point to a specific tool, resulting in multiple pending tool items.

[0030] In terms of tool calling and execution, the system starts to execute tasks according to the selected tool, calling the API of the corresponding tool or interacting with the external system to complete the task processing. Specifically, the system interacts with external tools through standardized APIs to ensure that the tool calling process is seamless and efficient, and by introducing a fault-tolerant mechanism, when the tool call fails, it will automatically retry or select a backup tool to ensure that the task continues to be executed. In this way, it ensures that the task can be executed accurately, avoids task interruptions caused by tool call failures or errors, improves the stability of the system, and ensures that complex tasks can be completed smoothly.

[0031] Through accurate task identification and tool selection, the system can select the most suitable execution tool for each task, thereby improving the efficiency and accuracy of task execution, avoiding incorrect tool selection, and ensuring that task execution proceeds as expected.

[0032] As a preferred implementation, when the tool call intention is detected to be ambiguous, a user interaction operation is triggered to collect supplementary input information for the task description information. In this way, when the system encounters uncertainty (for example, when the task description is ambiguous or the tool selection is unclear), the system confirms the task details with the user through simple rules or basic conversational interactions. As a result, some ambiguous task scenarios can be resolved through user interaction, which improves the flexibility of the system.

[0033] In some examples, when the task description is unclear or there are multiple possible tools, the system will adopt an "uncertain behavior handling" strategy, such as further interacting with the user to obtain more information or adjust the tool selection. Specifically, when the task description is vague, the system will dialogue with the user and ask for more details to eliminate uncertainty. In addition, if there are multiple feasible tools, the system will select the most suitable tool for processing based on the context of the task, or tentatively call multiple tools at the same time. As a result, when encountering unclear or uncertain tasks, the system can respond flexibly, reduce misoperations and wrong choices, and ensure the accuracy of task execution.

[0034] In step S130 , it is identified whether tool hallucination occurs during the operation of each candidate execution tool.

[0035] As described above, tool hallucination can be the model incorrectly selecting or using a tool, and its identification method can be diverse. In some embodiments, based on preset inspection rules and / or assistant language models, it is identified whether tool hallucination exists during the operation of each candidate execution tool. Thus, it is identified whether there is a tool selection error (for example, the wrong tool is selected) or a tool usage error (for example, the tool usage parameters are wrong).

[0036] In step S140, at least one target execution tool is determined according to each candidate execution tool and the corresponding tool hallucination recognition result.

[0037] In some embodiments, when facing a single tool call intention, the candidate execution tool for which the risk of tool hallucination is identified should be avoided, and the candidate execution tool for which the risk of tool hallucination is identified can be selected as the target execution tool. In addition, when facing a multi-tool collaborative call intention, it requires multiple tools to be completed collaboratively, that is, to complete the task execution through the tool call path. At this time, the hallucination recognition results of each tool in the path can be counted, and then the corresponding hallucination rate can be counted, and then the tool call path with a lower corresponding hallucination rate can be selected.

[0038] In step S150, task execution feedback is generated based on the operation results of each target execution tool.

[0039] In some implementations, the running results of the target execution tool are optimized, for example, by generating feedback messages through semantic slot filling, image generation, speech synthesis, etc., and returning them to the user. At the same time, tool selection, task execution process, etc. are optimized based on the feedback of the task to improve the processing effect of future tasks. Specifically, by analyzing the feedback during the task execution process, the decision model and tool selection strategy are continuously optimized. Based on the task results, optimized training data is generated to improve the system's adaptability to future complex tasks.

[0040] Therefore, through continuous learning and optimization, the system can continuously improve its performance in complex tasks, making it more efficient and accurate when facing new tasks, so that the optimized system can adapt to more complex and changing task requirements, and further improve the reliability of task execution.

[0041] In some implementations, the tool call is verified when executing the task, and a simple result evaluation is performed after the task is completed. If the task is not successful, the system will feedback error information and try to call the tool again. Therefore, by introducing a task execution monitoring and error correction mechanism, potential errors in the execution process are monitored, thereby avoiding some obvious tool misuses, and timely detecting errors in the use of tools, and can also feedback to the user for reselection or correction, thereby improving the robustness of the system and ensuring the success rate of task execution.

[0042] In some examples of the embodiments of the present application, the tool hallucination includes at least one of the following types: tool type hallucination, tool timing hallucination, tool format hallucination, or tool content hallucination.

[0043] Here, tool calling is considered as a decision-making behavior. When the decision conditions are not met or the decision fails, it may lead to unexpected illusion phenomena. Tool illusions are divided into two categories: tool selection illusions and tool use illusions. Tool selection illusions refer to the model selecting an inappropriate tool or calling a tool at the wrong time. Tool use illusions refer to errors in the way the model uses a tool after selecting it.

[0044] Specifically, tool selection illusion includes two subtypes: tool type illusion and tool sequence illusion. Specifically, tool type illusion refers to the model calling a tool that is irrelevant to the current task, or making up a tool name that does not exist in the available toolset. Tool sequence illusion involves errors in the order of tool calls. This illusion occurs when the model repeatedly calls the same tool with consistent inputs and outputs, indicating that the tool should not be called again at this point in the task process.

[0045] In addition, tool usage hallucinations include two subtypes: tool format hallucinations and tool content hallucinations. Specifically, tool format hallucinations refer to errors in the tool usage structure or format, such as providing an invalid JSON format, using an incorrect parameter name, omitting a required parameter, or specifying a value of the wrong data type for a parameter. In addition, tool content hallucinations refer to the specific content of the tool parameters being fabricated by the model, that is, the input provided to the tool is not based on the user's query, but is fictionalized by the model.

[0046] Figure 2 An operational flow chart showing an example of an evaluation tool illusion according to an embodiment of the present application.

[0047] like Figure 2 As shown in Figure 2, the evaluation of tool call hallucination is achieved by fusing rules and assistant LLMs (e.g., GPT-4o mini). Specifically, first, the specific call tool TC is checked by the rule i Does it belong to the available tool set T? If not, it is confirmed as tool timing illusion. Then, TC is identified through LLMs i Is it relevant to the task? If not, it is confirmed as a tool type illusion. Then, TC is identified through rules. i Is it repeated? If not, it is confirmed that there is a tool type illusion. Then, the TC is identified by the rule i Is it valid? If not, it is confirmed that there is a tool format illusion. If it is confirmed that TC i If it is valid, it is further checked through LLMs to see if the content is authentic. If the content is not authentic, it is confirmed that tool content hallucination has occurred.

[0048] pass Figure 2 The pipeline shown determines whether a particular tool call is hallucinated and identifies its type. It is important to note that not only does it rely on rule-based detection (e.g. format checking), but it also leverages a large language model as an evaluator to assess certain hallucination aspects in tool calls. The LLM plays a key role in assessing the relevance of the tool to the task and in determining whether the tool call parameters are derived from user input or fabricated by the model.

[0049] Figure 3 An operational flowchart of an example of determining a target execution tool according to an embodiment of the present application is shown.

[0050] like Figure 3 As shown, in step S310, the potential execution results of the tasks corresponding to each candidate execution tool are obtained, and the corresponding task execution reliability is evaluated in combination with the tool hallucination recognition results of each candidate execution tool. The task execution reliability covers the measurement of the success rate of the task level and the efficiency of the tool use.

[0051] First, after the tool is executed, the correctness of the task results is evaluated to see how well they match the expectations. If the execution is successful, the system returns the results; if the execution fails, the system reports the error and considers adjusting the execution path. Specifically, the task execution results are compared with the expected results to ensure that the task is successfully completed. In addition, by monitoring the task execution process in real time, timely feedback is provided and remedial measures are taken when anomalies are found. Therefore, by evaluating the execution results of the task, it is ensured that the task is completed as expected, errors are discovered and corrected in a timely manner, and the output of erroneous results is avoided.

[0052] Furthermore, during the entire task execution process, the system will evaluate the reliability of tool calls in real time, including the probability of task success and the resource cost consumed. Specifically, by measuring the success rate of the task level and the efficiency of tool use to calculate the corresponding task execution reliability, it can comprehensively evaluate the success rate and cost-effectiveness of tool calls.

[0053] In step S320, a target tool calling path is determined according to the task execution reliability and each candidate execution tool, and the target tool calling path includes multiple target execution tools that are executed sequentially.

[0054] Here, based on the evaluation results, the system dynamically adjusts the tool call strategy, optimizes decisions, avoids invalid tool calls, and saves resources. Therefore, through real-time evaluation, the system optimizes the task execution path, reduces resource waste, and improves the efficiency and success rate of task execution.

[0055] In the embodiments of this application, by optimizing the decision-making mechanism in the tool calling process, reducing the "tool illusion", significantly improving the reliability and success rate of task execution, reducing the error rate and resource waste, and improving system efficiency. The chain reaction includes enhancing user trust and experience, reducing manual intervention, reducing costs, promoting the processing of more complex tasks, promoting the popularization of AI and automation technology in various industries, improving security and risk control capabilities, and accelerating cross-industry cooperation and innovation, providing support for the optimization and application expansion of future intelligent systems.

[0056] It should be noted that the phenomenon of tool illusion (i.e., models incorrectly select or misuse tools) poses a key challenge, which may lead to mission failure and increased operating costs.

[0057] In this regard, this paper explores the concept of reliable tool invocation and highlights the need to address the tool hallucination problem. Tool hallucination is systematically classified into two main types: tool selection hallucination and tool usage hallucination. To address these issues, a reliability-focused alignment framework is proposed to enhance the model's ability to accurately assess tool relevance and usage patterns. By proposing a set of evaluation metrics and evaluating them on StableToolBench, the effectiveness of the framework in reducing tool hallucination and improving the overall system reliability of LLM tool invocation is further demonstrated.

[0058] Specifically, instrumental illusions are divided into two major types and four subtypes, such as Figure 4 As shown in Figure 2. Tool selection illusion refers to the model mistakenly selecting a tool that is irrelevant to the task or calling it at the wrong time. Tool usage illusion involves errors in the way the tool is applied, such as providing wrong parameters or faking non-existent parameters. By distinguishing these types, we can better understand the nature of tool illusion and develop corresponding strategies to mitigate its impact.

[0059] Figure 4 A schematic diagram showing the effects of an example of four types of tool illusions.

[0060] like Figure 4 As shown in the figure, the task proposed by the user is: "I'm a football enthusiast and I want to know more about Lionel Messi's career. Can you provide me with information about Messi's clubs, managers, teammates? I'm also curious about any notable transfers he has made." (I am a football enthusiast and I want to know more about Lionel Messi's career. Can you provide information about Messi's clubs, coaches and teammates? I'm also curious about his important transfers.) As described above, tool selection types are divided into type illusion and timing illusion. Tool use illusion includes format illusion and content illusion.

[0061] Specifically, in the tool type hallucination, the assistant calls a non-existent tool name "get_info_for_footballer", which is a tool type hallucination because this tool is not in the set of available tools.

[0062] Additionally, when calling the "transfer_search" tool, if it is called repeatedly with the same input and output, this is a tool timing illusion. For example, calling the tool repeatedly when it should not be called again.

[0063] In addition, when calling the "transfer_search" tool, if required parameters are omitted (such as "transfer_search ()" is missing required parameters), this is a tool format illusion.

[0064] In addition, when the assistant calls “transfer_search (name = Cristiano Ronaldo)”, the “Cristiano Ronaldo” here is the content fabricated by the model, not based on the user query (the user queries for Messi’s information), which is a tool content illusion.

[0065] It should be noted that the above-mentioned types of hallucinations can be analyzed based on the assistant LLM through the tool call history. It can analyze the causes of tool hallucinations, learn the corresponding hallucination patterns, and identify the types of corresponding tool hallucinations.

[0066] Regarding the calculation details of task execution reliability, on the one hand, it can be achieved through a deep learning model, and on the other hand, it can also be achieved through mathematical operations of multiple indicators, and both are within the scope of implementation of the embodiments of the present application.

[0067] In some examples of the embodiments of the present application, first, the benefit-cost utility index and the benefit-cost ratio index are calculated according to the potential execution results of the tasks corresponding to each candidate execution tool and the tool hallucination recognition results. Then, the task execution reliability is calculated according to the benefit-cost utility index and the benefit-cost ratio index. Here, the benefit-cost utility index is a reward-based index, which assigns scores to tasks based on the passing results of task execution and the tool usage efficiency. In addition, the benefit-cost ratio index is the ratio between the overall task pass rate and the number of tool calls, and the overall task pass rate is the proportion of tasks that are successfully passed and have no hallucination answers.

[0068] It should be noted that in addition to solving the tool illusion problem, ensuring the reliability of LLM tool interactions is critical to achieving high task performance and operational efficiency. Reliability involves not only the successful completion of the task, but also the management of the costs required to achieve success. The presence of tool illusion may seriously damage reliability, leading to hallucinatory task outputs and unnecessarily increasing tool call costs. To this end, two indicators are introduced: a) benefit-cost utility, which is used to reward successful tasks and punish hallucinations and excessive tool call costs; b) benefit-cost ratio, which is used to measure the relationship between task success and tool call costs. These indicators highlight the importance of reducing tool illusion to improve task success and reduce unnecessary tool use.

[0069] In the embodiment of the present application, a reliability-focused alignment framework is proposed to alleviate tool hallucinations. Specifically, in this framework, its action space is expanded for the first time to include uncertain operations. Unlike the previous deterministic operations that only rely on direct tool calls (which often lead to hallucinations or errors), operations such as talking to users or changing tools are introduced. These uncertain operations help the model better identify different situations and avoid hallucinatory decisions.

[0070] As a preferred implementation method for determining the target tool call path, at least one tool call path is determined based on each candidate execution tool, and each target tool call path includes multiple candidate execution tools executed sequentially. Next, the hallucination rate of tool hallucination occurring during the operation of each tool call path is calculated. Then, it is identified whether there is at least one successful tool call path corresponding to the successful trajectory of the task in each tool call path.

[0071] On the one hand, when it is identified that there is at least one successful tool call path, a target tool call path is determined from each successful tool call path according to the hallucination rate. For example, the successful tool call path with the lowest hallucination rate can be used to determine the target tool call path.

[0072] Specifically, we introduce a metric called tool hallucination rate to measure the proportion of hallucinated tool calls in a set of tasks. This metric first calculates the hallucination rate at the sample level—that is, the individual calculation performed for each task—and then averages it across all samples to obtain a more comprehensive measure of tool hallucination behavior.

[0073] Specifically, for a given task, let is the total number of tool calls, The number of times a hallucinated tool was called. The sample-level tool hallucination rate is defined as: The overall tool illusion rate is: (1) in, Represents the total number of tasks in the evaluation set.

[0074] When a task is successfully executed, it can provide useful information to the user. However, tool illusion may lead to unnecessary overhead and increased decision costs. Therefore, the reliability of LLM tool invocation is a holistic measure that covers both the success rate at the task level and the efficiency of tool use. Here, two indicators are introduced to capture this trade-off: benefit-cost utility and benefit-cost ratio.

[0075] Benefit-Cost Utility is a reward-based metric that assigns a score to each task based on the results of task execution and tool usage efficiency. The utility captures the quality of the task results (success, failure, or illusion) as well as the penalty for excessive tool calls. The scoring system is designed to incentivize high task completion rates and efficient tool usage.

[0076] The utility score is calculated as follows: - If the task is successfully completed (passed), the model will receive a bonus of 20 points.

[0077] - If the task is not completed and fails, the score is 0.

[0078] - If the task fails and the model provides a hallucinatory answer, the utility score is -10 points.

[0079] - In addition to task-based rewards, excessive tool usage is penalized. Each task is expected to be completed with the minimum number of tool calls. For each tool call that exceeds the necessary number of calls, 1 point will be deducted, with a maximum penalty of -10 points. This penalty mechanism encourages the model to avoid redundant or unnecessary tool calls and improve tool usage efficiency.

[0080] Therefore, the utility score of each task execution is calculated as: (2) in, is a reward based on the task result (20 points for success, 0 points for failure, -10 points for illusion); is the penalty for excessive tool invocation, calculated as .

[0081] This utility metric allows for a granular assessment of task performance and cost efficiency, reflecting in a single score how well the model balances successful task completion and sensible tool usage.

[0082] The benefit-cost ratio provides a complementary perspective to the benefit-cost ratio, which emphasizes the efficiency of tool use by evaluating the ratio of task success to tool use cost. This metric measures the efficiency of tool use by comparing the overall task pass rate with the average tool call cost between tasks.

[0083] For each task, the tool usage cost is defined as follows: - If the task is completed without unnecessary tool calls, the base cost is 1.

[0084] - For each tool call beyond the necessary number of calls, the cost increases. The maximum cost is capped at 2, which is reached when the model calls the tool more than 10 times in a single task. The cost formula is: (3) This means that if there are no additional tool calls, the cost is 1; if the model is called 10 or more times in the task, the cost will be capped at 2.

[0085] The benefit-cost ratio is calculated by dividing the overall task pass rate by the average tool call cost: (4) in: - Reliable Pass Rate is the proportion of tasks that were successfully passed without hallucination answers (e.g., using LLM to check whether the answer is hallucination), - Average Tool Cost is the average cost of tool usage in all task executions.

[0086] This ratio clearly expresses the balance between the model's success rate and operating costs. A high benefit-cost ratio indicates that the model not only successfully completes the task, but also does so at an efficient cost. On the contrary, a low ratio implies that either the pass rate is low or the tool is used inefficiently, resulting in an increased cost per successful task.

[0087] In terms of the alignment goal of reliability alignment, the alignment goal of LLM in reliable tool invocation focuses on ensuring accurate and efficient interaction with external tools during task completion. From a task perspective, the main goal is to maximize successful tool invocations and minimize hallucination phenomena. This goal can be formalized as the following preference hierarchy: - A successful tool invocation path that leads to task completion is preferred over a path that leads to task failure or abandonment.

[0088] - A path that fails or is abandoned is better than a path that produces hallucinatory results, which can mislead users.

[0089] In form, Represents a tool call path, represents the hallucination rate in this path. For a given task, the alignment preference is defined as: , in, Indicates the success path, Indicates the path that led to task failure or abandonment, Represents the path that produces the hallucinated result.

[0090] In experiments, we found that when a model exhibits a high rate of tool hallucination, it tends to generate hallucinated outputs rather than admit failure. This behavior poses significant risks because hallucinated results may mislead users into thinking that the task has been successfully completed, thereby undermining trust in the system. In addition, when comparing paths with the same task results (for example, both paths successfully completed the task), the path with fewer hallucinations is more ideal. Specifically: , in, and Respectively represent the path and The hallucination rate.

[0091] In addition, for many tasks, the number of tool calls required is usually fixed. Models that over-call tools tend to introduce more hallucinations. Therefore, minimizing tool hallucinations not only improves the reliability of tasks, but also reduces the overall number of tool calls, leading to more efficient tool usage. Indicates the path The goal is to minimize the hallucination rate and the number of calls , in order to comprehensively improve the efficiency and reliability of the task process.

[0092] On the other hand, when it is identified that there is no successful tool call path, that is, all tool call paths are task failure trajectories, the task type of each failed tool call path can be identified at this time, and different rejection feedback operations can be performed according to the task type.

[0093] Specifically, in terms of the alignment method for reliability alignment, an alignment framework is proposed to enhance the reliability of task completion in complex environments. The framework contains two key components: a) Uncertainty Operation: The "ChangeTools" and "TalkToUser" functions are introduced to handle different hallucination scenarios. "ChangeTools" is used for tool type hallucination to seek alternative tools; while "TalkToUser" is used for tool content hallucination to prompt the model to communicate with the user. b) Data Synthesis Framework: Preference data is generated based on task completion and the type of hallucination encountered, enabling the model to learn from rich datasets and make more informed decisions.

[0094] 1) Supervised Finetuning (SFT) The first step of the method is supervised fine-tuning (SFT), in which tool call traces for a specific task are sampled. If some traces succeed on the task, those with the least hallucinations are selected as fine-tuning labels. If all sampled traces fail, the task is considered likely unachievable for the model, and a rejection strategy is designed based on the hallucination type. Specifically: - Tool type hallucination: When this type of hallucination occurs, indicating that the existing tools are insufficient to complete the task, the model is trained to trigger the “ChangeTools” function to request an alternative tool.

[0095] - Tool content hallucination: If the hallucination is caused by incorrect tool content, the model learns to call the "TalkToUser" function to complete the task by communicating with the user.

[0096] 2) Direct Preference Optimization (DPO) Direct Preference Optimization (DPO) focuses on building preference data to fine-tune the model's behavior. The goal of DPO is to guide the model to choose the best tool call trajectory based on task success and hallucination type. Preference data is defined under three main scenarios to guide the model on how to rank different responses: - Successful trajectories vs. unsuccessful trajectories: If a task has successful trajectories, trajectories with fewer hallucinations are preferred over trajectories with more hallucinations. Additionally, successful trajectories are always preferred over trajectories where the model triggers rejection mechanisms such as tool change or task abandonment.

[0097] - Tool Type Illusion: When the primary illusion type is a tool dependency issue (i.e. the model incorrectly selects an unrelated tool), trajectories where the model calls the "ChangeTools" function outperform trajectories that continue to use the hallucinated tool call.

[0098] - Tool content hallucination: If the hallucination stems from incorrect tool content (i.e., the model generates incorrect outputs based on the tool’s responses), then trajectories where the model communicates the difficulty of the task via the “TalkToUser” feature are preferred over trajectories that continue to use the incorrect tool data.

[0099] The preference ranking can be summarized as: in, and denote successful trajectories with relatively low and high instrumental illusions, respectively; and Represents failed trajectories where the actions of the "ChangeTools" and "TalkToUser" denial mechanisms were used, respectively; these paths outperform paths with high tool hallucination or that result in hallucinated outcomes .

[0100] The DPO framework ensures that the model learns to rank trajectories according to these preferences. By optimizing on this type of data, the model is able to select the most reliable sequence of tool calls or, if necessary, recognize when to abandon a task or seek further clarification from the user.

[0101] Furthermore, to ensure training stability and maximize model performance, a joint training strategy is adopted to combine the loss functions of SFT and DPO. Instead of training in sequence, the two losses are optimized simultaneously: This approach stabilizes DPO while allowing the model to benefit from the supervisory signal provided by SFT, thereby improving task completion and reducing hallucinations. By integrating the two loss functions, the model can handle complex tasks more reliably, call appropriate rejection strategies, and minimize hallucinations.

[0102] The following will expand on the relevant details of the experimental part of the system framework of the embodiment of the present application.

[0103] Regarding the dataset, two datasets were mainly used in the experiment: ToolBench and StableToolBench. ToolBench is built by crawling various APIs from RapidAPI and generating corresponding tasks, containing a total of 120,000 data samples. Toolllama is reproduced using all the training data of ToolBench, and 10,000 samples are randomly selected to build reliability alignment data. StableToolBench is built based on the test set of ToolBench, screens out unresolved tasks, and uses API caching technology to ensure the stability of the API. Specific test scenarios are created using its I1 instruction subset to evaluate the performance of the model under challenging conditions. Two changes were made: - Missing parameter subset: This change hides certain task parameters associated with tool calls. Specifically, this data is generated through LLM, hiding the parameters in the task to simulate the situation where key information is missing and evaluate the model's ability to operate effectively under incomplete information.

[0104] - Mismatched tool subset: In this scenario, the tools specified in the task are replaced with unrelated or mismatched tools to test the model's robustness against hallucinations caused by incorrect tool correlations.

[0105] Regarding the experimental settings, all experiments were conducted using the LLAMA 3.1 8B INSTRUCT model, which has been specifically aligned for tool use. The maximum sequence length was set to 8192, the training batch size was 32, and the DEEPSPEED-CHAT framework was used for efficient model training. In the joint training of SFT and DPO, a loss combination ratio of 0.5 was set for each method. The learning rate was set to 1e-5 for SFT and 1e-6 for DPO, and all training was completed within two epochs.

[0106] When constructing the training data, 10,000 samples were randomly divided into 4000, 3000, and 3000 data points for keeping the same, introducing additional tool replacements, and constructing missing parameter scenarios, respectively. In addition, the evaluation of tool hallucination and task success used the GPT-4O MINI model, and other evaluation details were consistent with the settings of StableToolBench. To calculate the benefit-cost utility and ratio, the number of necessary tool calls for solvable tasks (I1 instructions) was set to 1, and the number of unsolvable tasks (missing parameters and I1 instructions with mismatched tools) was set to 0. All experiments were performed using Nvidia A800 GPUs.

[0107] Table 1: Performance comparison of different methods.

[0108] As the main results of the experiment described in Table 1, RePR ↑: reliable pass rate. Tool Hallu ↓: tool hallucination rate. Tool Num ↓: average number of tool calls. The performance of the model on three subsets of StableToolbench was evaluated, focusing on the measurement of tool hallucination rate and task pass rate. The results show that the implementation of the reliability alignment framework including SFT and DPO significantly reduced the tool hallucination rate of the baseline model. In addition, the average number of tool calls required for each task was reduced. It is worth noting that in the MissingParameter and UnmatchedTools subsets, the baseline models (including ChatGPT and Toolllama 3.1) exhibited a higher tool hallucination rate. In contrast, the model provided by the embodiment of the present application showed significant improvements in identifying and managing these two special cases, effectively reducing the number of tool calls while reducing the corresponding tool hallucination rate.

[0109] Table 2: Reliability evaluation of different methods.

[0110] Table 2 shows the comprehensive results of the reliability evaluation of different models and methods. This table focuses on two key indicators: utility and ratio. The data shows that the proposed method significantly improves the utility and ratio compared to the baseline model. Although the combination of SFT and DPO slightly reduces the task pass rate, the utility and ratio are significantly improved due to the significant reduction in tool hallucinations and unnecessary tool calls. This improvement indicates that the system is more reliable because the model is more efficient in completing the task and tool usage related errors are reduced. The higher utility and ratio values ​​indicate that the alignment method not only reduces the hallucination rate, but also enhances the effectiveness of the system in reliably handling complex tasks.

[0111] Table 3: Reliability evaluation of different methods.

[0112] Table 3 shows the distribution of different types of tool hallucinations in detail, where Type, Tim., Form., and Con. represent tool type, timing, format, and content hallucinations, respectively. Specifically, in the I1 instruction subset, the main types of hallucinations are tool timing hallucinations and tool content hallucinations. In the missing parameter subset, the most common error is tool content hallucinations; while in the mismatched tool subset, tool type hallucinations dominate. Experimental results show that the alignment framework enables the model to learn to accurately evaluate the purpose and correct use of tools, thereby significantly reducing hallucinations in tool selection and use and improving the reliability of overall tool calls. In all subsets, the method achieves a consistent reduction in the incidence of various types of hallucinations. In particular, in the mismatched tool subset, the model successfully completely eliminates hallucinations, reducing the hallucination rate to zero. This significant improvement enhances the reliability of tool use in this subset and reduces hallucination-related errors, thereby achieving more accurate and reliable tool interactions.

[0113] Through the embodiments of the present application, the tool hallucination challenges faced by LLMs during tool interaction are solved. By dividing tool hallucination into selection and usage errors, a framework for understanding these problems is proposed. The reliability-focused alignment framework improves tool selection and usage of LLMs and mitigates tool hallucination risks. Combining optimization techniques such as supervised fine-tuning and direct preference optimization, training data that focuses on reliability can be effectively generated. By proposing evaluation metrics for hallucinations and testing them on StableToolbench, tool hallucinations can be effectively mitigated, demonstrating a significant improvement in model reliability. The results highlight the importance of optimizing tool calling behavior to ensure effective and secure interaction with external systems.

[0114] It should be noted that, for the aforementioned method embodiments, for the sake of simplicity of description, they are all expressed as a series of actions combined, but those skilled in the art should be aware that the present application is not limited by the described order of actions, because according to the present application, certain steps can be performed in other orders or simultaneously. Secondly, those skilled in the art should also be aware that the embodiments described in the specification are all preferred embodiments, and the actions and modules involved are not necessarily required by the present application. In the above embodiments, the description of each embodiment has its own emphasis. For parts that are not described in detail in a certain embodiment, please refer to the relevant description of other embodiments.

[0115] In some embodiments, an embodiment of the present application provides a non-volatile computer-readable storage medium, in which one or more programs including execution instructions are stored. The execution instructions can be read and executed by an electronic device (including but not limited to a computer, a server, or a network device, etc.) to execute any of the above-mentioned large model-based task execution methods of the present application.

[0116] In some embodiments, the embodiments of the present application also provide a computer program product, which includes a computer program stored on a non-volatile computer-readable storage medium, and the computer program includes program instructions. When the program instructions are executed by a computer, the computer executes any one of the above-mentioned large model-based task execution methods.

[0117] In some embodiments, the embodiments of the present application also provide an electronic device, comprising: at least one processor, and a memory communicatively connected to the at least one processor, wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to execute a task execution method based on a large model.

[0118] Figure 5 is a schematic diagram of the hardware structure of an electronic device for executing a task execution method based on a large model provided by another embodiment of the present application, such as Figure 5 As shown, the device includes: One or more processors 510 and memory 520, Figure 5 A processor 510 is taken as an example.

[0119] The device for executing the large model-based task execution method may further include: an input device 530 and an output device 540 .

[0120] The processor 510, the memory 520, the input device 530 and the output device 540 may be connected via a bus or other means. Figure 5 The example of connecting through bus is taken in the following.

[0121] The memory 520, as a non-volatile computer-readable storage medium, can be used to store non-volatile software programs, non-volatile computer executable programs and modules, such as program instructions / modules corresponding to the large model-based task execution method in the embodiment of the present application. The processor 510 executes various functional applications and data processing of the server by running the non-volatile software programs, instructions and modules stored in the memory 520, that is, the large model-based task execution method in the above method embodiment is implemented.

[0122] The memory 520 may include a program storage area and a data storage area, wherein the program storage area may store an operating system, an application required for at least one function; the data storage area may store data created according to the use of the electronic device, etc. In addition, the memory 520 may include a high-speed random access memory, and may also include a non-volatile memory, such as at least one disk storage device, a flash memory device, or other non-volatile solid-state storage device. In some embodiments, the memory 520 may optionally include a memory remotely arranged relative to the processor 510, and these remote memories may be connected to the electronic device via a network. Examples of the above-mentioned network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0123] The input device 530 may receive input digital or character information and generate signals related to user settings and function control of the electronic device. The output device 540 may include a display device such as a display screen.

[0124] The one or more modules are stored in the memory 520, and when executed by the one or more processors 510, the large model-based task execution method in any of the above method embodiments is executed.

[0125] The above-mentioned product can execute the method provided in the embodiment of the present application, and has the functional modules and beneficial effects corresponding to the execution method. For technical details not fully described in this embodiment, please refer to the method provided in the embodiment of the present application.

[0126] The electronic devices of the embodiments of the present application exist in various forms, including but not limited to: (1) Mobile communication equipment: This type of equipment is characterized by having mobile communication functions and its main purpose is to provide voice and data communications. This type of terminal includes: smart phones, multimedia phones, functional phones, and low-end phones.

[0127] (2) Ultra-mobile personal computer devices: These devices belong to the category of personal computers, have computing and processing functions, and generally also have mobile Internet access features. These terminals include: PDA, MID and UMPC devices, etc.

[0128] (3) Portable entertainment devices: These devices can display and play multimedia content. They include audio and video players, handheld game consoles, e-books, smart toys, and portable car navigation devices.

[0129] (4) Other onboard electronic devices with data interaction functions, such as on-board devices installed in vehicles.

[0130] The device embodiments described above are merely illustrative, wherein the units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple network units. Some or all of the modules may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0131] Through the description of the above implementation methods, those skilled in the art can clearly understand that each implementation method can be implemented by means of software plus a general hardware platform, and of course, by hardware. Based on this understanding, the above technical solution, in essence, or the part that contributes to the relevant technology, can be embodied in the form of a software product, which can be stored in a computer-readable storage medium, such as ROM / RAM, a disk, an optical disk, etc., including a number of instructions for a computer device (which can be a personal computer, a server, or a network device, etc.) to execute the methods described in each embodiment or some parts of the embodiment.

[0132] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present application, rather than to limit it. Although the present application 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 embodiments of the present application.

Claims

1. A task execution method based on a large model, comprising: Extracting task description information from the input prompt information of the large model, and parsing the tool call intent corresponding to the task description information; Determine at least one candidate execution tool that matches the tool calling intention, and call each candidate execution tool respectively; identifying whether tool hallucination occurs during the operation of each of the candidate execution tools; Determining at least one target execution tool according to each of the candidate execution tools and the corresponding tool hallucination recognition results; Based on the operation results of each of the target execution tools, task execution feedback is generated.

2. The method according to claim 1, wherein: The tool hallucination includes at least one of the following types: tool type hallucination, tool timing hallucination, tool format hallucination or tool content hallucination.

3. The method according to claim 1, wherein: The identifying whether tool hallucination exists during the operation of each of the candidate execution tools includes: Based on preset checking rules and / or assistant language models, it is identified whether tool hallucination exists during the operation of each of the candidate execution tools.

4. The method according to claim 1, wherein: After parsing the tool call intention corresponding to the task description information, the method further includes: In the case where it is detected that the tool calling intention is ambiguous, a user interaction operation is triggered to collect supplementary input information for the task description information.

5. The method according to any one of claims 1 to 4, wherein: The step of determining at least one target execution tool according to each of the candidate execution tools and the corresponding tool hallucination recognition results includes: Obtaining the potential execution results of the tasks corresponding to each of the candidate execution tools, and evaluating the corresponding task execution reliability in combination with the tool hallucination recognition results of each of the candidate execution tools; the task execution reliability covers the measurement of the success rate of the task level and the efficiency of the tool use; A target tool calling path is determined according to the task execution reliability and the candidate execution tools, wherein the target tool calling path includes a plurality of target execution tools that are executed sequentially.

6. The method according to claim 5, wherein: Obtaining the potential execution results of the tasks corresponding to the candidate execution tools, and evaluating the execution reliability of the corresponding tasks in combination with the tool hallucination recognition results of the candidate execution tools, including: Calculate the benefit-cost utility index and benefit-cost ratio index according to the potential execution results of the tasks and the tool hallucination recognition results corresponding to each candidate execution tool; Calculating task execution reliability according to the benefit-cost utility index and the benefit-cost ratio index; Among them, the benefit-cost utility indicator is a reward-based indicator, which assigns scores to tasks based on the pass results of task execution and the efficiency of tool use; the benefit-cost ratio indicator is the ratio between the overall task pass rate and the number of tool calls, and the overall task pass rate is the proportion of tasks that are successfully passed and have no hallucination answers.

7. The method according to claim 5, wherein: According to the task execution reliability and the candidate execution tools, a target tool calling path is determined, including: Determine at least one tool calling path according to each of the candidate execution tools; each of the target tool calling paths includes a plurality of candidate execution tools that are executed sequentially; Calculate the hallucination rate of tool hallucinations during the operation of each tool call path; Identify whether there is at least one successful tool calling path corresponding to a successful task track in each of the tool calling paths; When it is identified that there is at least one corresponding successful tool calling path, a target tool calling path is determined from each of the successful tool calling paths according to the hallucination rate.

8. A storage medium having a computer program stored thereon, wherein: When the program is executed by a processor, the steps of the method described in any one of claims 1 to 7 are implemented.

9. An electronic device, comprising: At least one processor, and a memory communicatively connected to the at least one processor, wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform the steps of the method described in any one of claims 1 to 7.

10. A computer program product, comprising a computer program / instruction, which, when executed by a processor, implements the steps of the method according to any one of claims 1 to 7.

Images