Planning program, planning method, and information processing device

Abstract

A planning program according to the present invention causes a computer to execute a process for: accepting specification of a task; causing a large language model to iteratively perform, on the basis of the specified task and a set of functions which includes a first function that executes a process corresponding to a specific function and a second function that causes the large language model to select a function to be called from among candidates of permitted functions, planning in which subtasks are expanded to a hierarchy lower than the hierarchy of the specified task and the first function or the second function to be executed for the subtasks is selected; and outputting a tree-structure plan in which the subtasks are expanded for each hierarchy as a result of the iterative planning.

Description

Planning Program, Planning Method, and Information Processing Apparatus

[0001] The present invention relates to a planning program, a planning method, and an information processing apparatus.

[0002] There is provided a software development kit that decomposes a task input by a user into fine sub-tasks using a generative AI (Artificial Intelligence) and generates a plan.

[0003] For example, Function Calling in which an interactive generative AI selects a function to be called in response to a user input by giving a function definition separately from the user input, and Task Planning in which a complex task is broken down into detail, a plan is made, and then executed, are known.

[0004] Japanese Patent No. 7509972

[0005] However, in the prior art represented by the above Function Calling and the above Task Planning, as the task specified by the user becomes more complex, the plan also becomes longer, so there is room for improvement in that the accuracy of planning decreases.

[0006] One aspect aims to provide a planning program, a planning method, and an information processing apparatus capable of improving the accuracy of planning.

[0007] A planning program according to one aspect causes a computer to execute a process of accepting a task specification, a set of functions including a first function that executes a process corresponding to a specific function and a second function that causes a large language model to select a function to be called from candidates of permitted functions, and based on the specified task, repeatedly performing planning on the large language model to expand sub-tasks to a lower hierarchy than the hierarchy of the specified task and select the first function or the second function to be executed by the sub-tasks, and outputting a plan having a tree structure in which the sub-tasks are expanded hierarchically as the planning is repeated.

[0008] According to one embodiment, it is possible to improve the accuracy of planning.

[0009] Figure 1 is a block diagram showing an example of the functional configuration of a server device. Figure 2 is a schematic diagram illustrating an example of planning. Figure 3 is a diagram showing an example of a plan. Figure 4 is a schematic diagram illustrating a planning method. Figure 5 is a diagram showing an example of information stored in ToolLake. Figure 6 is a diagram showing an example of information stored in DataLake. Figure 7 is a diagram showing an example of a prompt. Figure 8 is a diagram (1) showing an example of a function definition. Figure 9 is a diagram (2) showing an example of a function definition. Figure 10 is a diagram showing an example of a data definition. Figure 11 is a diagram showing an example of a response from LLM. Figure 12 is a diagram (1) showing an example of a plan. Figure 13 is a diagram (2) showing an example of a plan. Figure 14 is a diagram (3) showing an example of a plan. Figure 15 is a diagram (4) showing an example of a plan. Figure 16 is a diagram (5) showing an example of a plan. Figure 17 is a diagram (1) showing an example of a plan display. Figure 18 is a diagram (2) showing an example of a plan display. Figure 19 is a diagram (3) showing an example of a plan display. Figure 20 is a diagram showing an example of the display of task execution results. Figure 21 is a flowchart showing the procedure for the planning process. Figure 22 is a diagram showing the control sequence for data uploading. Figure 23 is a diagram (1) showing the control sequence for function execution. Figure 24 is a diagram (2) showing the control sequence for function execution. Figure 25 is a diagram (3) showing the control sequence for function execution. Figure 26 is a diagram (4) showing the control sequence for function execution. Figure 27 is a diagram (5) showing the control sequence for function execution. Figure 28 is a block diagram showing an example of the functional configuration of a server device related to an application example. Figure 29 is a diagram (4) showing an example of plan display. Figure 30 is a diagram (5) showing an example of plan display. Figure 31 is a diagram (6) showing an example of plan display. Figure 32 is a diagram (7) showing an example of plan display. Figure 33 is a diagram (8) showing an example of plan display. Figure 34 is a diagram showing an example of hardware configuration.

[0010] Hereinafter, embodiments of the planning program, planning method, and information processing device relating to this disclosure will be described with reference to the attached drawings. It should be noted that these embodiments represent only one example or one aspect, and the following description does not limit the structure, operation, function, properties, characteristics, methods, and applications relating to this disclosure.

[0011] <Example 1> <Overall Configuration> Figure 1 is a block diagram showing an example of the functional configuration of a server device 10. Figure 1 shows an information processing device 10 that provides a planning function to generate a plan by breaking down a user-specified task into subtasks, from the perspective of supporting automatic software generation.

[0012] This planning function can be used in various situations, including when system engineers (SEs) or sales representatives solve customer problems, as well as when companies solve their own internal problems.

[0013] The server device 10 can provide the above-mentioned planning function as a cloud service by running a PaaS (Platform as a Service) type middleware or a SaaS (Software as a Service) type application. The server device 10 may be included as an example of an information processing device.

[0014] As shown in Figure 1, the server device 10 can be connected to the client terminal 30 via a network NW in a communicative manner. For example, the network NW may be any type of communication network, such as the Internet or a LAN (Local Area Network), whether wired or wireless. Although Figure 1 shows an example where one client terminal 30 is connected to one server device 10, this does not prevent any number of client terminals 30 from being connected.

[0015] The client terminal 30 is a terminal device that receives the planning function described above. For example, the client terminal 30 may be implemented using any computer, including personal computers, smartphones, tablet devices, and wearable devices.

[0016] From one perspective, the client terminal 30 may be used by users such as system engineers and sales personnel to solve customer problems. From another perspective, the client terminal 30 may be used by corporate stakeholders, such as accounting personnel, in situations where reporting obligations are required, in order for companies to solve their own problems.

[0017] Note that Figure 1 shows an example where the above planning function is provided by a single server device 10, but the above planning function may also be provided using multiple server devices such as a web server and a backend server.

[0018] Furthermore, while the above-mentioned planning function is provided as a cloud service, it is not limited to this. For example, the above-mentioned planning function may be provided on-premises. Also, while the above-mentioned planning function is provided as a client-server system, it is not limited to this. For example, an application running on the client terminal 30 may cause the client terminal 30 to execute processing corresponding to the above-mentioned planning function, thereby preventing the above-mentioned planning function from being provided in a standalone form.

[0019] <Explanation of Terms> A "task" refers to a user's request written in natural language. A "plan" refers to a task that has been broken down into a series of smaller tasks (hereinafter referred to as "subtasks"). "Planning" refers to the process of generating a plan. A "function" refers to a function that is called to execute a task. For example, from the perspective of generative AI, a function can also be called a tool. "Generative AI" refers to a generative model that generates content corresponding to various modals such as text, images, videos, and audio. Below, as an example of a text-to-text generative model that receives text input and outputs text, we will use a large language model, also known as an LLM (Large Language Model).

[0020] <Examples of Conventional Technologies> As explained in the background technology section above, conventional technologies such as Function Calling and Task Planning are known.

[0021] Figure 2 is a schematic diagram illustrating an example of planning. Figure 2 shows the planning of each task in Function Calling and Task Planning. For example, Figure 2 shows a case where the prompt "How many days are left from today until April 1st?" is given to the generating AI, and the list of predefined functions for the generating AI includes "get_today()", "sub_dates(date1,date2)", "...".

[0022] As shown in Figure 2, in the case of Function Calling, when the generating AI receives the prompt "How many days are left from today until April 1st?", it responds to the client-side software with a call to the function "get_today()". The client-side software, upon receiving this response, executes the function "get_today()" and obtains the result "3 / 4". Next, the generating AI, having received the result "3 / 4" from the function "get_today()", responds to the client-side software with a call to the function "sub_dates(4 / 1,3 / 4)" with the arguments created. The client-side software, upon receiving this response, executes the function "sub_dates(4 / 1,3 / 4)" and obtains the result "27 days".

[0023] In the case of Task Planning, when the prompt "How many days are left from today until April 1st?" is input to the generating AI, it generates a task execution plan, "Execute in the order of "d=get_today()" and "answer=sub_dates(4 / 1,d)"" and responds to the client-side software. Upon receiving such a response, the client-side software executes the function "get_today()" and obtains the execution result "3 / 4". Next, the client-side software uses the execution result "3 / 4" of the function "get_today()" as the argument for d and executes the function "sub_dates(4 / 1,d=3 / 4)" and obtains the execution result "27 days".

[0024] <One aspect of the challenge> As explained in the background technology section above, with conventional technologies such as Function Calling and Task Planning, the accuracy of the planning decreases as the complexity of the tasks specified by the user increases and the plans become longer, so there is room for improvement.

[0025] <One aspect of the problem-solving approach> In this embodiment, the planning function performs hierarchical planning using LLM so that the plan has a tree structure, and as a method, planning is performed using a function to perform the planning as a candidate.

[0026] The key points of this type of planning are as follows: 1) Divide into a “Planner” that plans the function and a “Leaf” that actually performs the processing. 2) Each Planner decides which function (Planner / Leaf) to use for planning. 3) When the Planner is executed, a subplan is generated (the Planner does not perform the actual processing). 4) When the Leaf is executed, the actual processing is performed.

[0027] In other words, the planning function according to this embodiment causes the LLM to repeatedly perform planning, which involves expanding subtasks to a lower hierarchy than the user-input task hierarchy and selecting a Leaf or Planner to be executed by the subtask, based on a set of functions including a Leaf that executes processing corresponding to a specific function and a Planner that causes the LLM to select a function to call from among the candidates of permitted functions, and a user-input task.

[0028] Figure 3 shows an example of a plan. In Figure 3, an example of a plan generated by the planning function according to this embodiment is shown with the prompt "Task data is available, and the work time has been recorded for completed tasks. Assign the unfinished tasks to 5 workers in a way that minimizes the execution time." Furthermore, in Figure 3, among the subtasks included in the plan's tree structure, subtasks selected by Planner are shown with hatching, while subtasks selected by Leaf are shown without hatching.

[0029] As shown in Figure 3, the planning function in this embodiment performs planning by breaking down semantically large units into subtasks at the higher levels, and further breaking down parent subtasks into smaller subtasks at the lower levels. With the plan generated in this way, users familiar with machine learning can understand and confirm the plan by visualizing the lowest level corresponding to the leaf nodes in the tree structure. Even users unfamiliar with machine learning can understand the overview of the plan, even if they do not understand the details, by visualizing the middle level one level below the root node in the tree structure. In the plan shown in Figure 3, tasks can be accomplished by executing the subtasks corresponding to the leaf nodes in order from left to right.

[0030] Figure 4 is a schematic diagram illustrating the planning method. In Figure 4, Planner functions are shown in hatching, while Leaf functions are shown in plain colors. For example, in the example shown in Figure 4, when a prompt is entered, function 0, which is a Planner, is executed, expanding the tree by one level and generating four subplans, functions 1 through 4. Of these, function 1, which is a Planner, is executed, generating two subplans, functions 1-1 and 1-2. Function 2, which is a Planner, is executed, generating two more subplans, functions 2-1 and 2-2. Furthermore, function 4, which is a Planner, is executed, generating three more subplans, functions 4-1 through 4-3. Since function 3 is a Leaf, the lower levels of function 3 are not expanded. In this type of plan, the processing flow to accomplish the task will consist of each Leaf being arranged in the following order: function 1-1, function 1-2, function 2-1, function 2-2, function 3, function 4-1, function 4-2, and function 4-3.

[0031] As is clear from the examples shown in Figures 3 and 4, the planning function according to this embodiment can suppress the number of subtasks at each level, for example, the number of child subtasks under each parent subtask, even when the tasks specified by user input become complex.

[0032] Therefore, the planning function according to this embodiment can improve the accuracy of planning.

[0033] Furthermore, the planning function in this embodiment allows users to understand the general process by looking at the higher levels and the detailed processes by looking at the lower levels, thus supporting understanding tailored to the skill and knowledge levels of each user. Therefore, it is possible to generate plans that are easy for users to understand.

[0034] <Configuration of Server Device 10> Next, the functional configuration of the server device 10 that provides the planning function described above will be explained. Figure 1 schematically shows the blocks related to the planning function of the server device 10. As shown in Figure 1, the server device 10 has a communication control unit 11, a storage unit 13, and a control unit 15. Note that Figure 1 only shows a selection of the functional units related to the planning function described above, and the server device 10 may also be equipped with functional units other than those shown.

[0035] The communication control unit 11 is a functional unit that controls communication with other devices such as the client terminal 30. In one embodiment, the communication control unit 11 can be implemented by a network interface card such as a LAN card. In one aspect, the communication control unit 11 receives a request from the client terminal 30 to execute planning, or outputs a response to the request, such as the result of generating a plan, to the client terminal 30.

[0036] The storage unit 13 is a functional unit that stores various types of data. In one embodiment, the storage unit 13 may be implemented by internal, external, or auxiliary storage of the server device 10. For example, the storage unit 13 has storage areas such as Workspace 13A, ToolLake 13B, and DataLake 13C.

[0037] Workspace 13A is the user's workspace. One aspect of Workspace 13A is that it can store data uploaded from the client terminal 30. Another aspect is that Workspace 13A may also store files created as a result of function execution. These files created as a result of function execution can also be downloaded to the client terminal 30.

[0038] ToolLake 13B is a memory area where a set of available functions is stored. Figure 5 shows an example of the information stored in ToolLake 13B. As shown in Figure 5, ToolLake 13B may register the definition of each function included in the set of functions, such as an overview, input parameters, output, and implementation format. For example, the implementation format of a function may include various formats such as a program, a Docker container, or a Web API (Application Programming Interface). Furthermore, a list of functions that the Planner considers as planning candidates may be stored in association with the Planner. Each function can access Workspace 13A, ToolLake 13B, and DataLake 13C as needed.

[0039] DataLake 13C is a storage area where data sets available to the user are stored. Figure 6 shows an example of information stored in DataLake 13C. For example, Figure 6 shows two files, "sales.csv" and "cities.csv," as just examples of the data included in the data set, but this does not prevent other data from being stored. Each of these data sets may also have definitions related to the data, such as an overview and descriptions of each column, stored in association with it. It is also possible to allow only reading by the client terminal 30 to DataLake 13C, while prohibiting writing from the client terminal 30.

[0040] Note that Workspace 13A, ToolLake 13B, and DataLake 13C do not necessarily have to reside in the internal storage of the server device 10. For example, Workspace 13A, ToolLake 13B, and DataLake 13C may reside in storage outside the server device 10, or they may be implemented through various storage services.

[0041] The control unit 15 is a functional unit that performs overall control of the server device 10. For example, the control unit 15 can be realized by a hardware processor. As shown in FIG. 1, the control unit 15 includes a reception unit 15A, a planning unit 15B, an LLM execution unit 15C, and an output control unit 15D. Note that the control unit 15 may be realized by hardwired logic or the like.

[0042] The reception unit 15A is a processing unit that receives various types of information from the client terminal 30. As one aspect, the reception unit 15A can receive a request to execute planning from the client terminal 30. When receiving such a request, it can receive a task specification via text described in natural language.

[0043] The planning unit 15B is a processing unit that executes planning to decompose a task specified by the user into subtasks and generate a plan. As one aspect, the planning unit 15B repeats, to the LLM, planning to expand subtasks to a lower hierarchy than the hierarchy of the task specified by the user input based on the ToolLake 13B and select a Leaf or Planner to be executed by the subtasks.

[0044] More specifically, when a task is specified by the reception unit 15A, the planning unit 15B executes the RootPlanner. For example, the RootPlanner generates a prompt in which the specified task is embedded and transmits the prompt to an LLM, for example, the LLM executed by the LLM execution unit 15C.

[0045] Figure 7 shows an example of a prompt. Figure 7 shows a prompt with the user-specified task "Draw a bar plot of sales for each city." embedded as an argument to `goal`. Furthermore, Figure 7 illustrates, as just one example of a prompt, the SequentialPlanner prompt of the semantic kernel rewritten for JSON (Java® Script Object Notation) output. Additionally, Figure 7 shows the parts of the SequentialPlanner prompt added to utilize Workspace 13A and DataLake 13C in the function, indicated in underlined, bold, and italic fonts. As shown in Figure 7, the prompt includes instructions to output a plan in JSON format, including the values ​​of each key such as id, description, function, parameters, and output. Note that {{$work_dir}} in the prompt is replaced with the actual directory name by the planning unit 15B before the prompt is sent to the LLM.

[0046] Figures 8 and 9 are (1) and (2) showing examples of function definitions. Figures 8 and 9 show examples of function definitions that are embedded in the {{$available function}} part of the prompt shown in Figure 7. For example, Figure 8 shows an excerpt of the definition of the function "TransformTablePlanner" as an example of a Planner from ToolLake 13B shown in Figure 5, while Figure 9 shows an excerpt of the definition of the function "TransformTableCode" as an example of a Leaf.

[0047] For example, in the example shown in FIG. 8, since the function "TransformTablePlanner" is a Planner function, the return value at runtime is a plan, but as the output during planning, what should be returned as a task is described. Here, as is clear from the comparison between the function "TransformTablePlanner" shown in FIG. 8 and the function "TransformTableCode" shown in FIG. 9, during planning, whether the function is a Planner or a Leaf is not distinguished. Therefore, from only the definitions of Planner or Leaf, the distinction between Planner and Leaf cannot be made, but Planner and Leaf have different behaviors at runtime.

[0048] FIG. 10 is a diagram showing an example of data definition. FIG. 10 shows an example of the data definition embedded in the {{$available datasets}} part of the prompt shown in FIG. 7. For example, FIG. 10 shows the definitions regarding the file names "sales.csv" and "cities.csv" included in the DataLake13C shown in FIG. 6. In the example shown in FIG. 10, the outline of the file with the file name "sales.csv" and the explanations of each column of "store_id", "sales", and "city_name" are described. Furthermore, the outline of the file with the file name "cities.csv" and the explanations of each column of "city", "prefecture", and "population" are described. Note that the {{$work_dir}} in the prompt is replaced with the actual directory name by the planning unit 15B before the prompt is sent to the LLM.

[0049] When such a prompt is sent from the RootPlanner to the LLM, the response from the LLM is as shown in FIG. 11. FIG. 11 is a diagram showing an example of the response from the LLM. For example, at the top of FIG. 11, the JSON response output by the LLM to which the prompt shown in FIG. 7 is input is shown, while at the bottom of FIG. 11, a part of the prompt shown in FIG. 7 is excerpted from the aspect of comparative explanation.

[0050] For example, in the example shown in Figure 11, the execution result of RootPlanner means that LLM has planned a subplan in which the function "TransformTablePlanner" identified by "id" "1" and the function "PlotGraphPlanner" identified by "id" "2" are executed in that order.

[0051] In this case, when the output of the preceding function is passed to the following function, a variable can be embedded in the output of the preceding function according to the description instructed as the procedure for calling the function in the prompt shown in Figure 7, that is, the third description. For example, in the case of the preceding function "TransformTablePlanner" among the two functions shown in Figure 11, the variable name "AGGREGATED_SALES_BY_CITY" determined by LLM is embedded, as shown in the dashed-dotted frame in Figure 11.

[0052] Furthermore, the specified variable names are embedded in the output of the overall plan result according to the description instructed as the procedure for calling the function in the prompt shown in Figure 7, that is, the fourth description. For example, in the case of the second function "PlotGraphPlanner" among the two functions shown in Figure 11, the variable name "Result__FINAL_ANSWER" determined by LLM is embedded, as shown in the dashed-dot frame in Figure 11.

[0053] Furthermore, the prompt shown in Figure 7 instructs that variable names be enclosed in ${...} according to the fifth instruction, which is the procedure for calling the function. For example, in the case of the second function "PlotGraphPlanner" among the two functions shown in Figure 11, ${AGGREGATED_SALES_BY_CITY} is embedded in the variable name of the input path, as shown by the dashed box in Figure 11.

[0054] When a JSON response is obtained in this manner, the planning unit 15B performs an update to embed the JSON response into the plan. Figure 12 is Figure (1) which shows an example of a plan. For example, the upper part of Figure 12 shows the plan template in its initial state before the execution of RootPlanner, while the lower part of Figure 12 shows the plan updated after the execution of RootPlanner based on the JSON response from LLM shown in Figure 11.

[0055] For example, the planning unit 15B updates the "state" of RootPlanner from "created" to "planned" before and after the execution of RootPlanner. Furthermore, after the execution of RootPlanner, the planning unit 15B embeds the "plan" from the JSON response from LLM shown in Figure 11 into the "steps" portion of the plan shown in Figure 12, and also performs the addition and processing of information as exemplified below.

[0056] For example, the planning unit 15B may add a key "type" to identify the type of function, in order to distinguish between Planner and Leaf when displaying functions. The value of such "type" will be either Planner or Leaf. Furthermore, the planning unit 15B may add a key "state" in order to manage the execution results of functions. For example, the value of such "state" may be "created" during planning, while "completed" or "failed" is stored during execution. Furthermore, the planning unit 15B may rename the key "output" to "outpout_name". Furthermore, although the output from LLM contains the string "RESULT__FINAL_ANSWER" according to the instructions written in the prompt shown in Figure 7, the planning unit 15B may perform a rename to match the variable name of "global_result", which is the output of RootPlanner. Furthermore, the planning unit 15B may embed the execution result of a function as a variable in the value of the key "outputs" when the function is executed. In this case, variable names are embedded enclosed in ${...}. Furthermore, the planning unit 15B may insert "steps" with an empty list as its value at the end, in order to prepare for embedding child nodes corresponding to subtasks that may be generated by Planner in the future, i.e., when the function obtained in planning is executed. As a result of these additions and modifications, the plan template shown at the top of Figure 12 is updated to the plan shown at the bottom of Figure 12.

[0057] After RootPlanner is executed, the planning unit 15B executes the functions assigned to the unexecuted subtasks among the subtasks developed by the planning, namely Planner or Leaf, in depth-first order.

[0058] For example, at the time of creating the plan shown in Figure 12, of the two functions, "TransformTablePlanner" (identified by "id" 1) and "PlotGraphPlanner" (identified by "id" 2), the function "TransformTablePlanner" is executed.

[0059] In this case as well, the prompt sent by the function "TransformTablePlanner" to the LLM is the prompt shown in Figure 7, but the following changes may be made. For example, "available_dataset" embedded in the prompt may be narrowed down to the data corresponding to "input_path". Furthermore, "available_functions" embedded in the prompt may be narrowed down to the functions that "TransformTablePlanner" can use as planning candidates. In addition, the prompt may be further modified to indicate that only "input_path" is used, and that output is made to "output_path".

[0060] When such a function "TransformTablePlanner" is executed, the planning unit 15B embeds the response from LLM into the "steps" portion at the end of the object identified by "id" "1" in the plan shown at the bottom of Figure 12. As a result, the plan shown at the bottom of Figure 12 is updated to the plan shown in Figure 13.

[0061] Figure 13 is Figure (2), which shows an example of a plan. For example, Figure 13 shows the plan shown at the bottom of Figure 12 after the execution of the function "TransformTablePlanner," updated based on the JSON response from LLM. As shown in Figure 13, this means that LLM has planned a subplan to be executed in the following order: function "TransformTableCode" identified by "id" as "step1", function "ExecuteCode" identified by "id" as "step2", and function "ReturnPath" identified by "id" as "step3". The output of the last of these three functions to be executed, "ReturnPath", is renamed so that "RESULT__FINAL_ANSWER" matches the output_name of the parent Planner function "TransformTablePlanner".

[0062] Subsequently, the planning unit 15B executes the three Leaf functions corresponding to the subtasks of the function "TransformTablePlanner" in the following order: the function "TransformTableCode" identified by "id" "step1", the function "ExecuteCode" identified by "id" "step2", and the function "ReturnPath" identified by "id" "step3".

[0063] Figure 14 is Figure (3) which shows an example of a plan. For example, Figure 14 shows the plan after execution of three Leaves corresponding to the subtasks of the function "TransformTablePlanner". As shown in Figure 14, the "state" value of the three Leaves corresponding to all subtasks of the function "TransformTablePlanner", namely the function "TransformTableCode", the function "ExecuteCode", and the function "ReturnPath", is updated to "complete". Accordingly, the "state" value of the parent node, the function "TransformTablePlanner", is also updated to "complete". For example, in the case of the function "TransformTableCode", the code shown in the callout is generated as the value of "outputs". In the case of the function "ExecuteCode", standard error and standard output are generated as the value of "outputs". Furthermore, in the case of the function "ReturnPath", the input " / work / aggregated_sales_by_city.csv" is returned as the value of "outputs". This is because, while LLM planning frequently uses the output of the last subtask as the overall output, in this example, the preceding task is code execution, so the file path is necessary to obtain the result.

[0064] After the plan update shown in Figure 14 is performed, the planning unit 15B executes the function "PlotGraphPlanner" whose "id" is identified as "2".

[0065] For example, when the function "PlotGraphPlanner" is executed, the planning unit 15B embeds the response from LLM into the "steps" portion at the end of the object identified by "id" "2" in the plan. As a result, the plan shown in Figure 14 is updated to the plan shown in Figure 15.

[0066] Figure 15 is Figure (4), which shows an example of a plan. For example, Figure 15 shows the plan shown in Figure 14 after the execution of the function "PlotGraphPlanner," updated based on the JSON response from LLM. As shown in Figure 15, this means that LLM has planned a subplan to be executed in the following order: function "PlotGraphCode" identified by "id" "1", function "ExecuteCode" identified by "id" "2", and function "ReturnPath" identified by "id" "3".

[0067] Subsequently, the planning unit 15B executes the three Leaf functions corresponding to the subtasks of the function "PlotGraphPlanner" in the following order: the function "PlotGraphCode" identified by "id" "1", the function "ExecuteCode" identified by "id" "2", and the function "ReturnPath" identified by "id" "3".

[0068] Figure 16 is Figure (5) which shows an example of a plan. For example, Figure 16 shows the plan after execution of three Leaves corresponding to the subtasks of the function "PlotGraphPlanner". As shown in Figure 16, the "state" value of the three Leaves corresponding to all subtasks of the function "PlotGraphPlanner", namely the function "PlotGraphCode", the function "ExecuteCode", and the function "ReturnPath", is updated to "complete". Accordingly, the "state" value of the parent node, the function "PlotGraphPlanner", is also updated to "complete". For example, in the case of the function "PlotGraphCode", the code shown in the callout is generated as the value of "outputs". In the case of the function "ExecuteCode", standard error and standard output are generated as the value of "outputs". Furthermore, in the case of the function "ReturnPath", the input " / work / sales_by_city.png" is returned as the value of "outputs". Thus, the "outputs" of the function "ReturnPath" represent the execution results of the user-specified tasks, i.e., the execution results of the entire plan.

[0069] As described above, the planning unit 15B executes the functions assigned to unexecuted subtasks in depth-first order until there are no more subtasks that can be executed among the subtasks included in the plan, in other words, until all Leafs have been executed.

[0070] Note that while this example shows the execution of functions assigned to unexecuted subtasks within the plan in depth-first order, it is not limited to this. For example, since all Planners can be executed in any order, it is possible to generate only the plan before the task execution results by executing all Planners first and postponing the execution of the Leaf.

[0071] The LLM execution unit 15C is a processing unit that executes LLM. The LLM executed by the LLM execution unit 15C in this way can then be used by a function to execute a subtask. While this example shows LLM being executed within the server device 10, it goes without saying that LLM may be executed outside the server device 10. For example, the functionality of LLM executed in a cloud service providing machine learning tools, a so-called MLaaS (Machine Learning as a Service), may be provided via API.

[0072] The output control unit 15D is a processing unit that controls the output of various types of information. "Output" here may include display output and audio output. Furthermore, the destination of the information output is not limited to client terminals 30 connected to the server device 10, but may also be external terminal devices, backend services, or applications.

[0073] One aspect of this is that the output control unit 15D can display the plan generation result on the client terminal 30 when all functions included in the plan have been executed. Furthermore, the output control unit 15D can also display the plan generated at the time a function corresponding to a subtask included in the plan is executed on the client terminal 30.

[0074] As merely one example of the results of such plan generation, the output control unit 15D can display the JSON responses after all Planner executions, or after all Leaf executions.

[0075] Figures 17 and 18 are Figures (1) and (2) showing examples of plan displays. Figure 17 shows the result of plan generation obtained by executing all Leaf operations, i.e., a display example in which some of the display of the plan generation result shown in Figure 16 is omitted, while Figure 18 shows a display example in which some of the omitted display of the plan shown in Figure 17 is un-omitted.

[0076] In the example shown in Figure 17, when the root of the plan's tree structure is considered to be level 0, the display is filtered to show only the function objects belonging to the level 1 hierarchy. That is, from the JSON response of the entire plan, the object corresponding to the function "TransformTablePlanner" identified by "id" "1" and the object corresponding to the function "PlotGraphPlanner" identified by "id" "2" are extracted and displayed. This display can be the default, and by accepting operations on the "[...]" of the "steps" contained in each object, such as clicking, the abbreviated display of the child nodes of that object can be removed. For example, by accepting operations on the "[...]" of the "steps" of the function "TransformTablePlanner" and the "[...]" of the function "PlotGraphPlanner" shown in Figure 17, the abbreviated display of the child nodes of the function "TransformTablePlanner" and the function "PlotGraphPlanner" is removed, and all nodes are displayed in an expanded view, as shown in Figure 18. In this way, the display or hiding of each level can be toggled through user interaction.

[0077] In addition, the output control unit 15D can also display a chart in which the tree structure of the plan is drawn based on the JSON response. Figure 19 is Figure (3) showing an example of plan display. Figure 19 shows an example of display in which graph data corresponding to the tree structure of the plan is drawn based on the plan generation result obtained by executing all Leafs, i.e., the JSON response shown in Figure 16. When graph data is displayed in this way, the nodes corresponding to Planner and Leaf can display the function name of Planner or Leaf, or they can display a subtask associated with the Planner or Leaf function, such as a description. Furthermore, the display format can be changed between the node corresponding to Planner and the node corresponding to Leaf.

[0078] Another aspect is that the output control unit 15D can also display the execution results of the Leaf subtasks assigned to the leaf in the plan's tree structure, executed in depth-first order, on the client terminal 30 as the execution result of a specified task. Figure 20 shows an example of how the task execution results are displayed. For example, Figure 20 shows an example of how the execution results of the entire plan in the JSON response shown in Figure 16 are displayed, i.e., the PNG file saved in the directory named " / work / sales_by_city.png" is rendered. As shown in Figure 20, the display of the task execution results allows the user to verify whether the execution result of the task specified by user input was successful or not.

[0079] <Processing Flow> Figure 21 is a flowchart showing the steps of the planning process. This process can be started as an example when a task specification is received from the client terminal 30 via text written in natural language.

[0080] As shown in Figure 21, when the receiving unit 15A receives the task specification (step S101), the planning unit 15B executes RootPlanner (step S102).

[0081] Subsequently, the planning unit 15B executes a loop process 1 that repeats the processes from step S103 to step S105 below until there are no more executable subtasks among the subtasks developed by the planning by RootPlanner or other Planners.

[0082] In other words, the planning unit 15B selects functions, i.e., Planners or Leafs, assigned to unimplemented subtasks among the subtasks developed by planning by RootPlanner or other Planners, in depth-first order (step S103).

[0083] Then, the planning unit 15B executes the function selected in step S103 (step S104), as will be explained later using Figures 23 to 27. After that, the planning unit 15B updates the plan based on the result of the function execution in step S104 (step S105).

[0084] This loop process 1 is repeated, executing all the leaves. This yields the plan generation results and the task execution results.

[0085] Subsequently, the output control unit 15D displays the plan generation result and the task execution result on the client terminal 30 (step S106), and then terminates the process.

[0086] For example, if the user input “Draw a bar plot of sales for each city.” is specified as the task, the functions will be executed in the order of node numbers 1 to 9, which are associated with each node in the plan tree structure shown in Figure 19.

[0087] Node number 1: Function "RootPlanner" corresponding to the task "Draw a bar plot of sales for each city." Node number 2: Function "TransformTablePlanner" corresponding to the subtask "Transform the sales data to aggregate sales by city." Node number 3: Function "TransformTableCode" corresponding to the subtask "Generate Python code to aggregate sales data by city and sum the sales for each city." Node number 4: Function "ExecuteCode" corresponding to the subtask "Execute the generated Python code to transform the table." Node number 5: Function "ReturnPath" corresponding to the subtask "Return the file path of the transformed table to the user." Node number 6: Function "PlotGraphPlanner" corresponding to the subtask "Plot a bar chart of the aggregated sales data by city." Node number 7: Function "PlotGraphCode" corresponding to the subtask "Generate Python code to plot a bar chart of sales for each city." Node number 8: Function "ExecuteCode" corresponding to the subtask "Execute the generated Python code to create the plot." Node number 9: Function "Return the file path of the The function "ReturnPath" corresponds to "plotted figure to the user."

[0088] Figure 22 is a diagram showing the control sequence for uploading data. As shown in Figure 22, when the server device 10 receives a data upload instruction from the client terminal 30 (step S201), it transfers the data to Workspace 13A (step S202).

[0089] Subsequently, when a controller or the like that controls access to Workspace 13A sends an upload completion notification to the server device 10 (step S203), the server device 10 forwards the upload completion notification to the client terminal 30 (step S204).

[0090] Figure 23 is a diagram (1) showing the control sequence for function execution. Figure 23 shows an example where a function execution instruction is received from the client terminal 30, but the function may be executed automatically.

[0091] As shown in Figure 23, when a function execution instruction is sent from the client terminal 30 to the server device 10 (step S301), the planning unit 15B of the server device 10 sends a request to the controller or the like that controls access to ToolLake 13B to obtain the implementation of the function corresponding to the execution instruction in step S301 (step S302).

[0092] Then, when the planning unit 15B of the server device 10 obtains the function implementation as a result of step S302 (step S303), it executes the function according to the function implementation (step S304).

[0093] Next, the function executed in step S304 sends a request to the controller or the like that controls access to the DataLake 13C to reference the DataLake 13C (step S305).

[0094] Furthermore, when the function executed in step S304 obtains the information it uses as a result of step S305 (step S306), it sends a request to refer to Workspace 13A to a controller or the like that controls access to Workspace 13A (step S307).

[0095] Furthermore, when the function executed in step S304 obtains the information it uses as a result of step S307 (step S308), it sends a request to the controller or the like that controls access to ToolLake 13B to reference ToolLake 13B (step S309).

[0096] Subsequently, the function executed in step S304, once it has obtained the information to be used by the function as a result of step S309 (step S310), sends a query to the LLM (step S311).

[0097] Then, when the function executed in step S304 returns a response to the query in step S311 (step S312), it sends a request to save the file to Workspace 13A to the controller or the like that controls access to Workspace 13A (step S313).

[0098] Next, when the function executed in step S304 receives notification that the file saving is complete as a result of step S313 (step S314), it returns the execution result of the function to the planning unit 15B of the server device 10 (step S315).

[0099] Finally, the planning unit 15B of the server device 10 displays the updated overall plan based on the execution results on the client terminal 30 (step S316).

[0100] In addition, in the process shown in Figure 23, steps S305 to S314 may be executed with different content depending on the implementation of the function.

[0101] Figure 24 is a diagram (2) showing the control sequence for function execution. For example, Figure 24 shows the control sequence when the function executed in step S104 of the flowchart shown in Figure 21 is Planner. Although Figure 24 also shows an example where a function execution instruction is received from the client terminal 30, the function may be executed automatically.

[0102] As shown in Figure 24, when a function execution instruction is sent from the client terminal 30 to the server device 10 (step S401), the planning unit 15B of the server device 10 sends a request to the controller or the like that controls access to ToolLake 13B to obtain the implementation of the function corresponding to the execution instruction in step S401 (step S402).

[0103] Then, when the planning unit 15B of the server device 10 obtains the implementation of the function as a result of step S402 (step S403), it executes the function according to the implementation of the function (step S404).

[0104] Next, the function executed in step S404 sends a request to the controller or other device that controls access to DataLake 13C, which refers to the description of the data set embedded in the prompt "available_datasets" (step S405).

[0105] Furthermore, when the function executed in step S404 returns a description of the data set as a result of step S405 (step S406), it sends a request to the controller or the like that controls access to Workspace 13A to refer to the description of the data set embedded as a user-specified dataset in the prompt (step S407).

[0106] Furthermore, when the function executed in step S404 receives a description of the data set as a result of step S407 (step S408), it sends a request to the controller or the like that controls access to ToolLake 13B to refer to the description of the function set embedded in the prompt "available_fuctions" (step S409).

[0107] Subsequently, the function executed in step S404 sends a request to the LLM to create a subplan (step S411) when the description of the function set is returned as a result of step S409 (step S410).

[0108] Then, when the function executed in step S404 returns a subplan as a result of the creation request in step S411 (step S412), it returns the subplan to the planning unit 15B of the server device 10 (step S413).

[0109] Finally, the planning unit 15B of the server device 10 displays the overall plan, including the added subplans, on the client terminal 30 (step S414).

[0110] Figure 25 is a diagram (3) showing the control sequence for function execution. For example, Figure 25 shows the control sequence when the function executed in step S104 of the flowchart shown in Figure 21 is the ReturnPath function, which is Leaf. Although Figure 25 also shows an example where a function execution instruction is received from the client terminal 30, the function may be executed automatically.

[0111] As shown in Figure 25, when a function execution instruction is sent from the client terminal 30 to the server device 10 (step S501), the planning unit 15B of the server device 10 sends a request to the controller or the like that controls access to ToolLake 13B to obtain the implementation of the function corresponding to the execution instruction in step S501 (step S502).

[0112] Then, when the planning unit 15B of the server device 10 obtains the implementation of the function as a result of step S502 (step S503), it executes the function according to the implementation of the function (step S504).

[0113] Next, the function executed in step S504 returns the file path to the planning unit 15B of the server device 10 (step S505). Finally, the planning unit 15B of the server device 10 displays the updated overall plan on the client terminal 30 (step S506).

[0114] Figure 26 is a diagram (4) showing the control sequence for function execution. For example, Figure 26 shows the control sequence when the function executed in step S104 of the flowchart shown in Figure 21 is the TransformTableCode function, which is a Leaf function. Although Figure 26 also shows an example where a function execution instruction is received from the client terminal 30, the function may be executed automatically.

[0115] As shown in Figure 26, when a function execution instruction is sent from the client terminal 30 to the server device 10 (step S601), the planning unit 15B of the server device 10 sends a request to the controller or the like that controls access to ToolLake 13B to obtain the implementation of the function corresponding to the execution instruction in step S601 (step S602).

[0116] Then, when the planning unit 15B of the server device 10 obtains the implementation of the function as a result of step S602 (step S603), it executes the function according to the implementation of the function (step S604).

[0117] Next, the function executed in step S604 sends a request to the controller or other device that controls access to DataLake 13C, which refers to the description of the data set embedded in the prompt "available_datasets" (step S605).

[0118] Furthermore, when the function executed in step S604 returns a description of the data set as a result of step S605 (step S606), it sends a request to the controller or the like that controls access to Workspace 13A, referring to the description of the data set embedded as a user-specified dataset in the prompt (step S607).

[0119] Furthermore, when the function executed in step S604 returns a description of the data set as a result of step S607 (step S608), it sends a request to LLM to generate code (step S609).

[0120] Then, when the function executed in step S604 returns a generation code as a result of the generation request in step S609 (step S610), it returns the generation code to the planning unit 15B of the server device 10 (step S611).

[0121] Finally, the planning unit 15B of the server device 10 displays the overall plan after adding the generated code on the client terminal 30 (step S612).

[0122] Figure 27 is a diagram (5) showing the control sequence for function execution. For example, Figure 27 shows the control sequence when the function executed in step S104 of the flowchart shown in Figure 21 is the ExecuteCode function, which is Leaf. Although Figure 27 also shows an example where a function execution instruction is received from the client terminal 30, the function may be executed automatically.

[0123] As shown in Figure 27, when a function execution instruction is sent from the client terminal 30 to the server device 10 (step S701), the planning unit 15B of the server device 10 sends a request to the controller or the like that controls access to ToolLake 13B to obtain the implementation of the function corresponding to the execution instruction in step S701 (step S702).

[0124] Then, when the planning unit 15B of the server device 10 obtains the implementation of the function as a result of step S702 (step S703), it executes the function according to the implementation of the function (step S704).

[0125] Next, the function executed in step S704 sends a request to the controller or other device that controls access to the DataLake 13C to reference the input data (step S705).

[0126] Furthermore, when the function executed in step S704 returns input data as a result of step S705 (step S706), it sends a request to the controller or the like that controls access to Workspace 13A to reference the input data (step S707).

[0127] Furthermore, the function executed in step S704 sends a request to a controller or the like that controls access to Workspace 13A to save an output file containing the code execution results (step S710).

[0128] Subsequently, the function executed in step S704 returns the execution result to the planning unit 15B of the server device 10 (step S711). Finally, the planning unit 15B of the server device 10 displays the updated overall plan with the execution result on the client terminal 30 (step S712).

[0129] <Summary> As described above, the server device 10 according to this embodiment plans the execution plan of a task using LLM, and includes a function in the candidates that plans so that the plan has a tree structure, and plans hierarchically. Therefore, even if the task specified by user input becomes complex, the number of subtasks at each level, for example the number of child subtasks under each parent subtask, can be suppressed. Accordingly, the server device 10 according to this embodiment can improve the accuracy of planning.

[0130] <Example 2> Now, although Example 1 of the present disclosure has been described, various applications are possible, and furthermore, it may be implemented in various different forms other than Example 1 described above.

[0131] <Additional Functions> In addition to the functional units described in Embodiment 1 above, various other functions may be provided. Figure 28 is a block diagram showing an example of the functional configuration of a server device 20 according to an application example. As shown in Figure 28, the server device 20 differs from the server device 10 shown in Figure 1 in that it has an output control unit 25A that further displays errors related to the execution results of Leaf, and a modification unit 25B that performs modifications to the plan.

[0132] Figure 29 is Figure (4) showing an example of the plan display. For example, in the example shown in Figure 29, the output control unit 25A can display the error message "... No such file or directory: / worksales.csv" as the value of "outputs" for the function "ExecuteCode" where the value of "state" is "faield". In this case, the value of "state" being "faield" and the error message "... No such file or directory: / worksales.csv" may be displayed in a different format from the display format of other strings, for example, by highlighting. Such error display can help in the analysis that the cause is that "TransformTablePlanner" has incorrectly generated the parameter "input_path". In other words, the error message can identify that LLM has mistakenly written " / worksales.csv" instead of the correct " / work / sales.csv" for "input_path". If the file path in the "input_path" parameter is incorrect, an error will occur in the path within the code generated by the "TransformTableCode" function, resulting in an error in the execution result of the "ExecuteCode" function. In this case, the correction unit 25B can accept corrections to the parameters of the Leaf. For example, it can accept a correction to change the file path in the "input_path" parameter of the "TransformTableCode" function from " / worksales.csv" to " / work / sales.csv".

[0133] Modifying the parameters of a Leaf in this way does not involve modifying the plan itself. For example, only the functions corresponding to the subtrees below the subtask of the function "TransformTablePlanner" need to be re-executed. This limits the scope of plan re-execution to the subtrees.

[0134] Figure 30 is Figure (5) showing an example of plan display. For example, Figure 30 shows an example where an error occurs in the column name in the code generated by the function "TransformTableCode (in the case of an implementation where code is generated by LLM)". In this case, as shown in Figure 30, the output control unit 25A can display the error message "... KeyError:'city'" as the value of "outputs" for the function "ExecuteCode" where the value of "state" is "faield". At this time, the value of "state" being "faield" and the error message "... KeyError:'city'" may be displayed in a different format from the display format of other strings, for example, by highlighting. Such error displays allow users to notice that the column name in the code generated by LLM is incorrect. In this case, the correction unit 25B can accept corrections to the parameters of Leaf. For example, it can accept a correction to change the execution result of the function "TransformTableCode" from "city" to "city_name". Such corrections also do not involve corrections to the plan itself. For example, only the functions corresponding to the subtrees under the subtask of the function "TransformTablePlanner" need to be re-executed. This limits the scope of plan re-execution to the subtrees.

[0135] Figure 31 is Figure (6) showing an example of a plan display. Figure 31 shows an example where the plan obtained by executing the function "TransformTablePlanner" is incorrect. For example, in the example shown in Figure 31, the subplan generated by the function "PlotGraphPlanner" is only the function "ReturnPath", which is clearly incorrect. The execution of this function "ReturnPath" completes without errors, and the value of "output_path" is obtained as " / work / aggregated_sales_by_city.csv", but this file has not been generated, so the execution of the next function "PlotGraphPlanner" fails. In this case, the user will notice that the ' / work / aggregated_sales_by_city.csv' file that should have been generated (an error "No such file or directory" will be displayed) has not been generated, and when they check the plan, they will notice that the plan is clearly incorrect. If the LLM is unfortunately incorrect, the user may be able to obtain the correct result by simply re-executing the function "TransformTablePlanner". In addition, the modification unit 25B can also improve the likelihood of obtaining a correct subplan by accepting modifications to the "instruction" parameter of the function "TransformTablePlanner". For example, "Aggregate the sales data by city and sum the sales for each city." can be modified to "Aggregate the sales data by city and sum the sales for each city and save the result to a file."

[0136] Figures 32 and 33 are (7) and (8) showing examples of plan display. Figures 32 and 33 show examples where the code generated by the function "TransformTableCode" is incorrect and the output CSV file is incorrect. For example, as shown in Figure 33, the output control unit 25A can display the error message "... ValueError: Could not interpret value 'city_name' for 'x'..." as the value of "outputs" of "ExecuteCode" in the function "PlotGraphPlanner" where the value of "state" is "failed". Displaying such an error makes it clear that the "city_name" column is missing. This can then trigger a check of the plan by working backward from the function "PlotGraphPlanner", as shown in Figure 32, which also reveals that the "city_name" column is already missing from " / work / aggregated_sales_by_city.csv", the output of the function "TransformTablePlanner". On the other hand, since the original input " / work / sales.csv" contains a "city_name" column, it can be inferred that the output code of the function "TransformTableCode" is incorrect. How to handle this depends on the user's skill level. For example, a user who can write code can check the output code and notice that the "city_name" column is missing because "reset_index()" is not being called. In this case, the correction unit 25B can accept a correction to the output code of the function "TransformTableCode". After such a correction is made, a plan without errors can be obtained by re-executing the function "ExecuteCode" within the function "TransformTablePlanner". On the other hand, a user who cannot write code may infer that the output code is incorrect, but will not know how to correct it.Therefore, the modification unit 25B can accept modifications such as adding "The output csv must contain city_name column." to the "instruction" parameter of the function "TransformTableCode". In this case, the likelihood of obtaining an error-free plan increases by re-executing the function "TransformTableCode".

[0137] <Exercise of Creative Ability> The matters described in Embodiment 1 above, such as functions, LLMs, types and number of various data, and specific examples of functions, LLMs, and various data, are merely examples and can be changed. Also, the flowchart described in Embodiment 1 above can be modified in terms of processing order, as long as it is consistent.

[0138] <System> The processing procedures, control procedures, specific names, and information including various data and parameters shown in the above document and drawings may be changed at will unless otherwise specified. For example, one or more of the functions of the server device 10, such as the reception unit 15A, planning unit 15B, LLM execution unit 15C, and output control unit 15D, may be configured as separate devices. Furthermore, one or more of the storage areas of the server device 10, such as Workspace 13A, ToolLake 13B, and DataLake 13C, may be configured as separate devices.

[0139] Furthermore, the components of each illustrated device are functionally conceptual and do not necessarily need to be physically configured as shown. In other words, the specific forms of distribution and integration of each device are not limited to those shown. That is, all or part of them can be functionally or physically distributed and integrated in any units according to various loads and usage conditions. Note that each configuration may also be a physical configuration.

[0140] Furthermore, the processing performed by the illustrated apparatus can be implemented, in whole or in part, by a program executed by a hardware processor such as an MPU (Micro-Processing Unit) or CPU (Central Processing Unit), or by hardware using wired logic.

[0141] <Hardware> Next, an example of the hardware configuration of the information processing device described in the above embodiment will be explained. Figure 34 is a diagram showing an example of the hardware configuration. As shown in Figure 34, the server device 10 has a communication device 10a, a storage device 10b, a memory 10c, and a processor 10d. Note that each part shown in Figure 34 may be connected to each other by a bus or the like.

[0142] The communication device 10a is a network interface card, etc. The storage device 10b is a storage device such as an HDD (Hard Disk Drive) or SSD (Solid State Drive). For example, the storage device 10b stores programs and databases that operate the functions shown in Figure 1.

[0143] The processor 10d reads a program that performs the same processing as the processing unit shown in Figure 1 from the storage device 10b or the like and loads it into memory 10c, thereby operating the process that performs the function described in Figure 1.

[0144] Such a process implements functions similar to those of the processing unit in the server device 10. For example, the processor 10d reads a program having functions similar to those of the reception unit 15A, planning unit 15B, LLM execution unit 15C, and output control unit 15D from the storage device 10b or the like. Then, the processor 10d executes a process that performs the same processing as the reception unit 15A, planning unit 15B, LLM execution unit 15C, and output control unit 15D.

[0145] Thus, the server device 10 operates as an information processing device that executes a planning method by reading and executing a program. The server device 10 can also achieve the same functionality as the embodiment described above by reading the program from a recording medium using a media reader and executing the read program. It should be noted that the program referred to in this other embodiment is not limited to being executed by the information processing device 10. For example, the functions of this disclosure can be similarly applied when another computer or server executes the program, or when they cooperate to execute the program.

[0146] The above program can be distributed via a network such as the Internet. Furthermore, the program can be recorded on any storage medium and executed by reading it from the medium by a computer. For example, the storage medium can be a hard disk, flexible disk (FD), CD-ROM, MO (Magneto-Optical disk), DVD (Digital Versatile Disc), etc.

[0147] 10 Server device 11 Communication control unit 13 Storage unit 13A Workspace 13B ToolLake 13C DataLake 15 Control unit 15A Reception unit 15B Planning unit 15C LLM execution unit 15D Output control unit 30 Client terminal

Claims

1. A planning program characterized by causing a computer to execute a process that includes: a set of functions including a first function that accepts a task specification and executes processing corresponding to a specific function, a second function that causes a large-scale language model to select a function to call from among candidates of permitted functions, and the specified task, which iterates through the planning to output a tree structure plan in which the subtasks are expanded hierarchically.

2. The planning program according to claim 1, characterized in that the process of repeating the planning includes the process of executing the first function or the second function assigned to the unexecuted subtasks among the subtasks developed by the planning in depth-first order.

3. The planning program according to claim 1, characterized in that the output process includes a process of outputting the execution results of the first function assigned to a leaf subtask included in the tree structure of the plan, executed in depth-first order, as the execution result of the specified task.

4. The planning program according to claim 1, characterized in that the output process includes a process for displaying errors related to the execution results of leaves included in the tree structure of the plan.

5. The planning program according to claim 1, characterized in that the computer further performs a process to accept modifications to the parameters of the leaves included in the tree structure of the plan.

6. The planning program according to claim 5, characterized in that the process of iterating the planning includes the process of re-executing the first function or the second function assigned to a subtask of a subtree containing the leaf from the tree structure of the plan to which the modification has been accepted.

7. A planning method characterized in that a computer executes a process comprising: a set of functions including a first function that accepts a task specification and executes processing corresponding to a specific function, a second function that causes a large-scale language model to select a function to call from among candidates of permitted functions, and the specified task, wherein the large-scale language model repeatedly performs planning to expand subtasks to a lower hierarchy than the hierarchy of the specified task and to select the first or second function to be executed in the subtasks, and the repeated planning outputs a tree structure plan in which the subtasks are expanded hierarchically.

8. The planning method according to claim 7, characterized in that the process of repeating the planning includes the process of executing the first function or the second function assigned to the unexecuted subtasks among the subtasks developed by the planning in depth-first order.

9. The planning method according to claim 7, characterized in that the output process includes a process of outputting the execution results of the first function assigned to a leaf subtask included in the tree structure of the plan, executed in depth-first order, as the execution result of the specified task.

10. The planning method according to claim 7, characterized in that the output process includes a process for displaying errors related to the execution results of leaves included in the tree structure of the plan.

11. The planning method according to claim 7, characterized in that the computer further performs a process to accept modifications to the leaf parameters included in the tree structure of the plan.

12. The planning method according to claim 11, characterized in that the process of iterating the planning includes the process of re-executing the first function or the second function assigned to a subtask of a subtree containing the leaf from the tree structure of the plan to which the modification has been accepted.

13. An information processing device having a control unit that executes processing, comprising: a set of functions including a first function that accepts a task specification and executes processing corresponding to a specific function, a second function that causes a large-scale language model to select a function to call from among candidates of permitted functions, and the specified task, which causes the large-scale language model to repeatedly perform planning to expand subtasks to a lower hierarchy than the hierarchy of the specified task and to select the first or second function to be executed in the subtasks, and which outputs a tree structure plan in which the subtasks are expanded hierarchically as the planning is repeated.

14. The information processing apparatus according to claim 13, characterized in that the process of repeating the planning includes the process of executing the first function or the second function assigned to the unexecuted subtasks among the subtasks developed by the planning in depth-first order.

15. The information processing apparatus according to claim 13, characterized in that the output process includes a process of outputting the execution results of the first function assigned to a leaf subtask included in the tree structure of the plan as the execution result of the specified task, in depth-first order.

16. The information processing apparatus according to claim 13, characterized in that the output process includes a process for displaying errors related to the execution results of leaves included in the tree structure of the plan.

17. The information processing apparatus according to claim 13, characterized in that the control unit further performs a process to accept modifications to the parameters of the leaves included in the tree structure of the plan.

18. The information processing apparatus according to claim 17, characterized in that the process of iterating the planning includes the process of re-executing the first function or the second function assigned to a subtask of a subtree containing the leaf from the tree structure of the plan to which the modification was accepted.

Images