Script generation device and script generation method

Abstract

To enable the easy and appropriate creation of scripts to perform the desired settings. [Solution] A computer 1 that generates a script to set a predetermined higher-level function for a predetermined device comprises a storage device 20, a memory 40, and a CPU 30. The memory 40 stores an API code database 44b that stores the codes of multiple APIs for setting each of multiple lower-level functions. The CPU 30, upon receiving a request from a user to set a higher-level function realized using multiple lower-level functions, searches the database for and obtains the codes of multiple APIs used to set the multiple lower-level functions related to the request. The CPU 30 uses the obtained API codes to create a script for setting the higher-level function, sets the parameters of the script based on user input, and issues the script for the higher-level function.

Description

Technical Field

[0001] The present invention relates to a technique for generating a script for setting a device.

Background Art

[0002] For example, a chatbot that chats on behalf of a human is known. Building a chatbot is difficult and it takes time to correctly implement a chatbot.

[0003] For example, Patent Document 1 discloses a technique for automatically generating a chatbot for an API (Application Programming Interface). Here, an API is an interface for operating and setting a certain function of a certain device from a program.

Prior Art Documents

Patent Documents

[0004]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0005] In the technique described in Patent Document 1, it is effective if there is a one-to-one correspondence between the function desired by the user of the chatbot and the API for setting that function. On the other hand, when a plurality of APIs are required for setting the function desired by the user of the chatbot, the user needs to interact with the chatbot according to an appropriate procedure for the required APIs. For this reason, there is a problem that a user who does not understand the setting procedures using a plurality of APIs in setting the desired function cannot set it appropriately.

[0006] This invention has been made in view of the above circumstances, and its purpose is to provide a technology that helps to easily and appropriately create scripts for performing desired settings. [Means for solving the problem]

[0007] To achieve the above objective, a script generation device relating to one perspective is a script generation device that assists in generating a script to set a predetermined higher-level function for a predetermined device, comprising a storage device and a processor, wherein the storage device stores a database that stores the codes of multiple APIs for setting each of multiple lower-level functions, and the processor, upon receiving a request from a user for setting a higher-level function realized using multiple lower-level functions, searches the database for and obtains the codes of multiple APIs used to set the multiple lower-level functions relating to the request, creates a script for setting the higher-level function using the obtained API codes, sets the parameters of the script for the higher-level function based on user input, and issues the script for the higher-level function. [Effects of the Invention]

[0008] According to the present invention, a technology is provided that enables the easy and appropriate creation of scripts for performing desired settings. [Brief explanation of the drawing]

[0009] [Figure 1] Figure 1 is a diagram illustrating the overview of the computer processing according to Example 1. [Figure 2] Figure 2 is a diagram showing the configuration of the computer according to Example 1. [Figure 3] Figure 3 shows an example of the API specification related to Example 1. [Figure 4] Figure 4 is a diagram showing an example of the configuration of an API code database according to Example 1. [Figure 5] Figure 5 is a diagram illustrating an example of a scenario definition related to Example 1. [Figure 6]FIG. 6 is a configuration diagram of an example of an intent definition according to Example 1. [Figure 7] FIG. 7 is a configuration diagram of an example of an entity·slot definition according to Example 1. [Figure 8] FIG. 8 is a configuration diagram of an example of a response definition according to Example 1. [Figure 9] FIG. 9 is a configuration diagram of an example of a script database according to Example 1. [Figure 10] FIG. 10 is a flowchart of a setting procedure extraction process according to Example 1. [Figure 11] FIG. 11 is a flowchart of a script generation process according to Example 1. [Figure 12] FIG. 12 is a flowchart of a chatbot setting process according to Example 1. [Figure 13] FIG. 13 is a flowchart of an action code generation process according to Example 1. [Figure 14] FIG. 14 is a flowchart of a chatbot process according to Example 1. [Figure 15] FIG. 15 is a diagram for explaining the interaction between an operation administrator and a chatbot according to Example 1. [Figure 16] FIG. 16 is a diagram for explaining the outline of the processing of a computer according to Example 2. [Figure 17] FIG. 17 is a configuration diagram of setting procedure information according to Example 2. [Figure 18] FIG. 18 is a configuration diagram of an example of an API specification database according to Example 2. [Figure 19] FIG. 19 is a flowchart of a chatbot setting process according to Example 2. [Figure 20] FIG. 20 is a flowchart of an action code generation process according to Example 2.

MODE FOR CARRYING OUT THE INVENTION

[0010] The embodiments will be described with reference to the drawings. Note that the embodiments described below do not limit the invention according to the claims, and not all of the elements and their combinations described in the embodiments are essential for the solution means of the invention.

[0011] In the following description, the "program" may be used as the operation subject for the description of the process. However, the program is executed by a processor to perform the defined process while appropriately using at least one of a storage device and an interface device. Therefore, the operation subject of the process may be a processor (or a computer or a computer system having a processor). The program may be installed in the computer from a program source. The program source may be, for example, a program distribution server or a computer-readable recording medium. Also, in the following description, two or more programs may be realized as one program, or one program may be realized as two or more programs. Further, at least a part of the process realized by the execution of the program may be realized by a hardware circuit (for example, an ASIC (Application Specific Integrated Circuit) or an FPGA (Field-Programmable Gate Array)).

Embodiment

[0012] In the computer according to Embodiment 1, for example, by using the manual of the device that the user wants to operate and the API specification of this device, a script for setting a function that needs to execute and set a plurality of APIs in this device is generated. The set values of the parameters required for the script are obtained while querying the user, the set values are entered into the script, and then output to the user.

[0013] Here, an API specification is a document that defines the input / output parameters and attributes for each API used to operate a device from a program. An example of an API specification is one that conforms to SWAGGER. The following explanation uses a SWAGGER-compliant specification as an example, but API specifications are not limited to this.

[0014] Figure 1 is a diagram illustrating the overview of the computer processing according to Example 1.

[0015] Computer 1 (see Figure 2) in Example 1 performs, broadly speaking, the following processes: pre-DB construction process S10, bot construction process S20, and bot operation process S30.

[0016] In the pre-DB construction process S10, computer 1 constructs the API code database 44b from the API specifications. The API code database 44b is, for example, a database that manages key-value pairs, where the key is the API description and the value is the code (API code) that executes the API corresponding to the API description of the key. In Figure 1, the API description is shown as a description in natural language, but for example, the description in natural language may be a numerical value vectorized using a predetermined language model. Here, Word2Vec, BERT, and text-embedding-ada-002 can be used as the language model, but other existing language models or newly developed language models may also be used.

[0017] The bot construction process S20 is a process executed by computer 1 through an operation by a construction administrator, who is the user building the chatbot (also simply called a bot). Here, the construction administrator is, for example, an administrator who is skilled in the specifications of the device's API.

[0018] Computer 1 receives an instruction from the build administrator requesting, for example, the extraction of the procedure for setting up a certain function of a device (for example, function A), and searches the pre-built manual database 42 for a document that shows the procedure for setting up the requested function (S21). Here, the document that shows the procedure for setting up the function is, for example, the document on the page in the API manual of the device that shows the procedure for setting up the function.

[0019] Computer 1 inputs the text containing the function setup procedure obtained through the search into a procedure extraction generation AI (Artificial Intelligence) to summarize it, and outputs the function setup procedure to the construction screen, for example, in bullet points (S22). Next, Computer 1 receives the bulleted setup procedure from the construction administrator via the construction screen, and based on the received setup procedure, generates a template script to execute each setting procedure for setting the function (S23, S24), and inputs it into the script database 48 (S25).

[0020] Specifically, Computer 1 retrieves the API code (API code) for configuring each received configuration procedure from the API code database 44b (S23), and merges the retrieved multiple codes using a code generation AI to generate a template script for executing each configuration procedure that configures the function (S24). Here, the unit for merging the codes may be, for example, all configuration procedure codes, or the code may be merged based on the configuration procedures of intermediate functions that constitute the requested higher-level function. The intermediate functions may be specified by Computer 1, or they may be accepted from the construction administrator.

[0021] Next, Computer 1 displays a script template on the construction screen, receives the script template to be configured for the chatbot from the construction administrator, and generates and outputs the chatbot configuration file 21 and action code 22 (S26, S27). Computer 1 generates the chatbot model file 23 from the chatbot configuration file 21 (S28).

[0022] Bot operation process S30 is a process executed by computer 1 through an operation by an operations manager, who is a user who operates the equipment using the bot. In this bot operation process S30, even if the operations manager is unfamiliar with the specifications of the equipment's API, for example, they can configure the higher-level functions of the equipment without any problems.

[0023] Computer 1 configures a chatbot and interacts with the operations manager via a bot screen, receiving requests from the operations manager to configure desired functions. It then sequentially asks for the parameter settings required for configuring the requested functions (S31). Once Computer 1 has received answers for all parameter settings, it executes action code 22 (S32). Executing action code 22, Computer 1 searches the script database 48 for a script to configure the functions, enters the parameter settings obtained from the operations manager into the script, and outputs it. Alternatively, instead of outputting the script itself, the URL containing the script may be output.

[0024] Figure 2 is a diagram showing the configuration of the computer according to Example 1.

[0025] Computer 1 is an example of a script generation device and is composed of computers such as a PC (Personal Computer) or a general-purpose server. Computer 1 comprises one or more CPUs (Central Processing Units) 30, one or more memories 40, one or more storage devices 20, and one or more network (NW) interfaces 10. These components are connected via a bus 80 that enables bidirectional communication. Here, the memory 40 and / or storage devices 20 are examples of storage devices. Computer 1 is not limited to the physical configuration described above and may be a virtual configuration using virtualization technology such as a virtual machine or container. Furthermore, Computer 1 may be composed of multiple physical computers.

[0026] The network interface 10 is an interface for communicating with external devices of the computer 1 via a network (not shown). The network interface 10 may include any network devices according to the external communication standard.

[0027] The CPU 30 is an example of a processor, and it performs various processes by executing various programs stored in the memory 40.

[0028] Memory 40 is, for example, DRAM (Dynamic Random Access Memory). Memory 40 stores various programs and data from various databases. Specifically, memory 40 stores a manual search program 41, a manual database 42, a procedure extraction generation AI program 43, a script generation program 44, a configuration file generation program 45, an action code generation program 46, a chatbot program 47, a script database 48, a script search program 49, and a parameter entry program 50. Note that memory 40 may also store data other than that shown in the diagram.

[0029] The manual search program 41, when executed on the CPU 30, accepts strings of natural language expressions such as words, sentences, and texts as input, vectorizes the natural language expression strings, and uses the vectorized values ​​as keys to search the manual database 42 for text corresponding to the keys. A language model can be used to vectorize the natural language expression strings. For example, the language model may be Word2Vec, BERT, or text-embedding-ada-002, or it may be another language model or a newly developed language model.

[0030] The manual database 42 is a vector database in which the natural language representations of the contents of a manual (an example of configuration procedure information) concerning the configuration of the target device are vectorized and made searchable. In the example in Figure 2, the manual database 42 is stored in memory 40, but it is not limited to this, and the manual database 42 may also be stored in the storage device 20. The manual database 42 does not have to be a vector database; for example, it may be a database that makes the text of the manual searchable by keywords, or a database that makes the text of the manual searchable by any other search method. A language model can be used to vectorize the strings of the natural language representations of the contents of the manual. For example, the language model may be Word2Vec, BERT, or text-embedding-ada-002, or it may be another language model or a newly developed language model.

[0031] The procedure extraction generation AI program 43, when executed on the CPU 30, receives the manual text retrieved by the manual search program 41 and the name of the target function, and outputs a bulleted list of the setting procedure for the target function. The Large Language Model (LLM) used by the procedure extraction generation AI program 43 may be, for example, GPT-4, GPT-3, LlaMa2, or any other LLM. Furthermore, knowledge can be added to the LLM through fine-tuning or additional learning using arbitrary data.

[0032] The script generation program 44, when executed on the CPU 30, accepts strings of natural language representations describing each of several APIs as input values ​​and performs the process of generating scripts that execute each API. The script generation program 44 includes an API code search program 44a, an API code database 44b, and a code merge generation AI program 44c.

[0033] The API code search program 44a, when executed on the CPU 30, accepts a string of natural language representations describing each of several APIs as input, and searches the API code corresponding to the input from the API code database 44b.

[0034] API code database 44b is a database that is constructed during the pre-database construction process.

[0035] The code merge generation AI program 44c, when executed on the CPU 30, receives multiple API codes as input from the API code search program 44a and outputs a single script that executes multiple APIs by merging those codes. Here, the LLM used by the code merge generation AI program 44c may be CodeLLama, CodeLLama-python, CodeLLama-instruction, or any other LLM. Furthermore, knowledge may be added to the LLM through fine-tuning or additional learning using arbitrary data.

[0036] The configuration file generation program 45, when executed on the CPU 30, receives a script that executes multiple APIs as input, analyzes the parameters used in the script, and generates a chatbot configuration file 21 necessary for constructing a dialogue scenario that queries the user for the settings of each parameter. Details of the chatbot configuration file 21 will be described later.

[0037] The action code generation program 46, when executed on the CPU 30, receives a script that executes multiple APIs as input, analyzes the parameters used in the script, and generates action code 22 that sets the values ​​of these parameters. Action code 22 is an arbitrary program. Details of action code 22 will be described later.

[0038] The chatbot program 47 is a program that constitutes the chatbot and is executed on the CPU 30. It comprises an NLU (Natural Language Understanding) 47a and a Dialogue management 47b. The NLU 47a, executed on the CPU 30, performs the following processes: intent classification, entity extraction, response acquisition, and slot storage. The NLU is, for example, a model trained by machine learning, which classifies the natural language input by the user into which intent it is. The Dialogue management 47b, executed on the CPU 30, performs the process of determining the next action in the user-chatbot dialogue based on the context. In this embodiment, the chatbot is built on, for example, RASA Open Source (also simply called RASA). RASA includes the NLU 47a and the Dialogue management 47b, which are customized by learning the chatbot configuration file 21 located on the memory device 20 to generate a chatbot model file 23. The chatbot may also be built on any chatbot platform. Chatbot model file 23 is a file for recording the customized NLU47a and Dialogue management47b.

[0039] The chatbot program 47 uses NLU 47a to recognize natural language input values ​​from the user as intent, entity, and slot. The chatbot program 47 then outputs a response to the user according to the context determined by Dialogue management 47b. Details of Intent, entity, slot, and response will be described later. The chatbot program 47 then executes action code 22 according to the context determined by Dialogue management 47b.

[0040] The script database 48 is, for example, a database that manages key-value pairs. The key is a vectorized value of a string representing a natural language expression containing the names of each function of the device, and the value is a script that collectively executes APIs for configuring the functions. A language model may be used to vectorize the string representing the natural language expression containing the names of the devices. The language model may be Word2Vec, BERT, text-embedding-ada-002, other language models, or newly developed language models. Details of the script database 48 will be described later.

[0041] The script search program 49, when executed on the CPU 30, accepts a string representing a natural language expression indicating the function to be configured as input, and searches the script database 48 for a script corresponding to the input.

[0042] The parameter entry program 50, when executed by the CPU 30, executes action code 22, which then performs the process of entering setting values ​​for the parameters within the script.

[0043] The storage device 20 is a non-volatile storage device such as an HDD (Hard Disk Drive) or SSD (Solid State Drive). The storage device 20 stores the OS (Operating System) image, data for building the chatbot, API specifications, etc. Specifically, the storage device 20 stores the chatbot configuration file 21, action code 22, chatbot model file 23, and API specifications 24. Note that the storage device 20 may store data other than that shown in the diagram.

[0044] The chatbot configuration file 21 is a file necessary for building a chatbot that executes a scenario in which the user is prompted to query the settings of each parameter in the script. The chatbot configuration file 21 includes a scenario definition 21a, an intent definition 21b, an Entity / slot definition 21c, and a response definition 21d.

[0045] Action code 22 is executed on CPU 30 to set values ​​for parameters used within the script.

[0046] Chatbot model file 23 is a file for recording the customized NLU47a and Dialogue management47b.

[0047] API specification 24 is a document that defines the input and output parameters and attributes for each API used to programmatically control the device.

[0048] Figure 3 shows an example of the API specification related to Example 1.

[0049] API specification 24 is a SWAGGER-compliant specification for the Storage REST API for managing storage devices as an example of equipment.

[0050] Lines 1-3 of API specification 24 describe the SWAGGER version and the API version. Line 4 describes the API title. Line 5 describes the API base path.

[0051] Lines 6-25 of API specification 24 describe resources (resources that can be manipulated within storage, such as volumes), actions (GET, POST, etc.), and responses (information returned after using the API). In Figure 3, for simplicity, only / v1 / volumes is described in detail as a resource, while other resources are omitted. Also, as for actions, only the POST action for the path / v1 / volumes is shown in detail. Furthermore, in Figure 3, only one type of response is shown in detail.

[0052] In the example in Figure 3, line 17, ref:"# / definitions / VOLUMEPOST", is the type of the request body, which is the input value for POST / v1 / volumes, and refers to the type definition in VOLUMEPOST described in lines 26-37. The Type definition in VOLUMEPOST defines that you should input the values ​​for the volumeId, poolId, and capacity parameters. In the example in Figure 3, only the type definition for POST to / v1 / volumes is shown in detail, and the others are omitted.

[0053] Figure 4 is a diagram showing an example of the configuration of an API code database according to Example 1.

[0054] The API code database 44b is created, for example, during the pre-database construction process. The API code database 44b stores entries for each API described in the API specification.

[0055] An entry in the API code database 44b includes a key 441 and a value 442. Key 441 stores the key, which is a description of the API corresponding to the entry (an example of information identifying a lower-level function). In this embodiment, the API description may be a vectorized value of a string representing the natural language expression of the API description. The API description may also be the summary in the API specification 24. For example, the API for POST to / v1 / volumes in the API specification 24 in Figure 3 may use the value on line 11. Note that the API description may also contain information other than the summary.

[0056] The value442 contains the code that executes the API corresponding to the entry, which is the value. For example, the value442 of the first entry contains file 443, which is the code file named Create-volume.py.

[0057] In file 443, lines 1-5 contain code to import the necessary libraries. Lines 7-9 contain code to utilize the authentication and authorization mechanism for the device executing the API. Lines 11-13 contain code to configure the API instance and set the parameters of the request body. Lines 15-20 contain the code that actually executes the API. Note that the code shown in Figure 4 is just an example, and other code may be stored. For example, the code shown in Figure 4 uses Python as the programming language, but the code may be written in any programming language. Furthermore, the code that executes the API may be created manually by the user, automatically generated using SWAGGER's functions, or created by any other method.

[0058] Figure 5 is a diagram illustrating an example of a scenario definition related to Example 1.

[0059] Scenario definition 21a is information that defines the scenario in which the chatbot interacts with the user. In scenario definition 21a shown in Figure 5, the second line contains the scenario name. The fourth line contains the intent that triggers the scenario. Details about the intent will be described later. The fifth line contains the execution of a form. When this form is executed, the chatbot begins a dialogue with the user, asking questions about the slots defined in the form. The form closes when all the answers for the slots have been answered. The form and slots will be described later. Lines 13 onwards are executed when the form closes. Lines 13, 15, and 17 describe the execution of a process (response) that causes the chatbot to output a natural language string indicating that it will generate a script to the screen. The response will be described later. Lines 14, 16, and 18 describe the execution of action code that generates the script. Details about the action code will be described later. In the example in Figure 5, scenario definition 21a is in YAML format, but other formats such as JSON format may also be used.

[0060] Figure 6 is a diagram illustrating an example of an intent definition related to Example 1.

[0061] The intent definition 21b is used by NLU47a to understand the natural language string entered by the user. In the intent definition 21b shown in Figure 6, lines 4-8 describe the definitions of multiple intents for a user who wants to configure remote copy. By learning this description, NLU47a identifies the intent as ask_how_configure_remote_copy when the user enters a string that is the same as or similar to these natural language strings. Lines 9-15 describe the definition of another intent. Lines 16-18 describe the definition of an intent using a regular expression. The intent definition using a regular expression is the intent that NLU47a identifies when the user enters a value that matches this regular expression as an input value. The other lines also describe intent definitions in a similar or adapted manner to the above. Note that in the example in Figure 6, intent definition 21b is in YAML format, but other formats such as JSON format may also be used.

[0062] Figure 7 is a diagram illustrating an example of an Entity·slot definition related to Example 1.

[0063] The Entity·slot definition 21c is used by NLU47a to extract a specific object from a string of natural language input by the user and store it in a variable. Here, "entity" indicates the type of the target object, and "slot" indicates the area for storing the object. For example, when the user inputs "Please give me a volume of 100GB", NLU47a can extract "100" as the entity and store it in a slot called "capacity". The value stored in the slot can then be referenced as a variable from action code 22.

[0064] In the Entity·slot definition 21c shown in Figure 7, the definition of the entity is described in lines 2-3. CARDINAL represents an integer type entity. re_capacity indicates that the intent defined in line 16 of the intent definition 21b shown in Figure 6 is being referenced as the entity. Lines 6-22 describe the definitions of slots for multiple variables.

[0065] Dialogule management47b prompts the user to input values ​​to be stored in a slot, depending on the context of the interaction with the user. Dialogule management47b uses forms as the criterion for determining the context.

[0066] In the Entity·slot definition 21c shown in Figure 7, lines 27-30 define configure_remote_copy_form, that is, the form for configuring remote copy. This description indicates that the form for configuring remote copy requires slots such as volume_id, capacity, pool_id, and journal_id. When configure_remote_copy_form is invoked, the chatbot outputs a response to the user to query them for these slots. A concrete example of the chatbot's interaction with the user to query for slots will be described later. For simplicity, other entities and slots are omitted in Figure 7, but they can be defined in a similar manner. In the example in Figure 7, the Entity·slot definition 21c is in YAML format, but it can also be in other formats such as JSON format.

[0067] Figure 8 is a diagram illustrating an example of a response definition related to Example 1.

[0068] The response definition 21d defines the responses, which are natural language texts that the chatbot outputs to the user. In the response definition 21d shown in Figure 8, lines 2, 4, 6, 9, 11, 13, and 15 describe the names of each response, while lines 3, 5, 7, 10, 12, 14, and 16 describe the actual text of the response. For simplicity, other responses may be defined in a similar manner, although they are omitted in Figure 8. In the example in Figure 8, the response definition 21d is in YAML format, but other formats such as JSON format may also be used.

[0069] Figure 9 is a diagram showing an example of a script database according to Example 1.

[0070] The script database 48 is created, for example, during the bot construction process. The script database 48 stores entries for each device function (higher-level function).

[0071] An entry in the script database 48 includes a key 481 and a value 482. Key 481 stores a description of the function corresponding to the entry, which serves as the key (for example, the function name). In this embodiment, the function description may be a vectorized value of a string representing the natural language expression of the function name.

[0072] The value482 contains a script (a higher-level function script) that executes the function corresponding to the entry, which is the value. In this embodiment, value482 contains one or more scripts that execute multiple lower-level functions (intermediate functions and / or lower-level functions: functions of medium and / or minor categories) that constitute the higher-level function (major category function) corresponding to the entry. The script stored in value482 may be a script that merges multiple API codes for multiple functions that constitute the higher-level function, or it may be a script that merges multiple API codes for lower-level functions (minor category functions) for each of the multiple intermediate functions (medium category functions: which can also be called lower-level functions for the higher-level function) that constitute the higher-level function. In short, it is sufficient to include a script that merges at least a part of the code that configures the multiple functions that constitute the higher-level function. For example, the value482 of the first entry contains scripts (master-journal.py, secondary-journal.py, master-volume.py, secondary-volume.py, pair-creat.py) for each of the five intermediate functions that constitute Remote copy. Note that at least one script for an intermediate function is a merged collection of API code that executes multiple subordinate functions. For example, in master-journal.py shown in Figure 9, lines 1-5 import the necessary libraries, lines 7-9 contain code to utilize the authentication and authorization mechanism for the device executing the API, lines 11-12 configure the API instance for volume creation and set the request body parameters, lines 14-19 contain the code that actually executes the API for volume creation (subordinate function), lines 21-22 configure the API instance for journal creation and set the request body parameters, and lines 24-29 contain the code that actually executes the API for journal creation (subordinate function). Note that the code in master-journal.py shown in Figure 9 is just an example, and other code may be used.

[0073] Figure 10 is a flowchart of the setting procedure extraction process according to Example 1.

[0074] The manual search program 41 (more precisely, the CPU 30 that executes the manual search program 41) displays a configuration screen (S1001). The destination of the configuration screen may be computer 1, or a user's terminal connected to computer 1 via a network. The configuration screen may be in chat format, CLI format, or GUI format.

[0075] Next, the manual search program 41 receives a natural language text (string) from the user via the configuration screen regarding the desired storage device function (target function) (S1002). The text received may also be the name of the storage function.

[0076] Next, the manual search program 41 searches the manual database 42 based on the received natural language text to find a document containing the setting procedure for the target function (S1003). Here, the manual search program 41 vectorizes the received natural language text and inputs the vector values ​​into the manual database 42. The manual database 42 identifies keys that have a high similarity to the input vector values ​​and outputs the manual document corresponding to the identified key value. Note that the method for calculating the similarity of the vector values ​​may be, for example, approximate nearest neighbor search, or any other arbitrary similarity calculation algorithm may be used.

[0077] Next, the procedure extraction generation AI program 43 receives manual text from the manual search program 41, extracts the setting procedure for the target function from the received manual text, and outputs the setting procedure in bullet points to the configuration screen (S1004). According to this configuration screen, the user can easily understand the setting procedure for setting the target function.

[0078] Figure 11 is a flowchart of the script generation process according to Example 1.

[0079] The script generation process is executed, for example, following the setup procedure extraction process.

[0080] The script generation program 44 (more precisely, the CPU 30 that executes the script generation program 44) displays the build screen created in step S1004 of the setting procedure extraction process (S1101).

[0081] Next, the script generation program 44 receives from the user a natural language representation of each setting procedure for configuring a predetermined storage function (target function) (S1102). Here, the script generation program 44 may accept the setting procedure text displayed on the build screen as is, or it may accept the setting procedure text that has been modified by the user from the setting procedure text displayed on the build screen.

[0082] Next, the API code search program 44a searches the API code database 44b for the API code corresponding to each setting procedure based on the natural language expression text of each input setting procedure (S1103). Specifically, the API code search program 44a vectorizes the received natural language expression text and inputs the vector values ​​into the API code database 44b. The API code database 44b identifies keys with high similarity to the input vector values ​​and outputs the API code that is the value corresponding to the identified key. The method for calculating the similarity of the vector values ​​may be, for example, approximate nearest neighbor search, or any other arbitrary similarity calculation algorithm may be used.

[0083] Next, the code merge generation AI program 44c receives the API codes for each setting procedure as input values, merges the input API codes while removing duplicates to generate a script, and outputs a URL to the build screen that allows referencing the generated script (S1104). Alternatively, the script itself may be output to the build screen instead of the script's URL.

[0084] Next, the code merge generation AI program 44c stores the generated script in the script database 48 (S1105). The key used when storing the script in the script database 48 may be, for example, a vectorized value of a string representing the name of the target function in natural language. For example, if the target function is remote copy, the key may be a vectorized value of "remote copy".

[0085] Figure 12 is a flowchart of the chatbot configuration process according to Example 1.

[0086] The chatbot configuration process is executed, for example, following the script generation process.

[0087] The configuration file generation program 45 displays the build screen output in step S1104 of the script generation process (S1201).

[0088] Next, the configuration file generation program 45 accepts a script via the construction screen to configure a predetermined function (target function) for which the chatbot will be built (S1202). The configuration file generation program 45 may accept the script by specifying the name of the script that configures the target function, or it may accept the script directly.

[0089] Next, the configuration file generation program 45 analyzes the received script and extracts the code for inputting parameters for each API (S1203). For example, if the received script is master-journal.py as shown in Figure 9, the configuration file generation program 45 extracts, for example, line 12, request_body = swagger_client. VOLUMEPOST(volume_id: int='example', pool_id: int='example', capacity: str='example'), and line 22, request_body = swagger_client. JOURNALPOST(volume_id: int='example', journal_id: int='example').

[0090] Next, the configuration file generation program 45 creates a list of information containing each parameter from the code for parameter input (S1204). For example, if the received script is master-journal.py as shown in Figure 9, a list of information containing volume_id, pool_id, capacity, volume_id, and journal_id is created from the code extracted in step S1203.

[0091] Next, the configuration file generation program 45 removes duplicate parameters from the list of parameters (S1205). In the example of the list information above, volume_id is duplicated, so one volume_id is removed, and volume_id, pool_id, capacity, and journal_id remain in the list information.

[0092] The configuration file generation program 45 creates entity and slot definitions 21c from the parameter list information (S1206). For example, since the volume_id in the above list information is of type int, the type in the entity and slot definition 21c will be CARDINAL, as shown in Figure 7, and since Capacity is of type str, the type will be text. Other entities and slots are created in the same manner.

[0093] The configuration file generation program 45 creates an intent definition 21b from the parameter list information (S1207). For example, the configuration file generation program 45 has templates such as "How do I configure <function name>?", "Tell me how to configure <function name>", and "I want to configure <function name>" prepared internally. The configuration file generation program 45 generates the ask_how_configure_remote_copy definition in the intent definition 21b shown in Figure 6 by replacing <function name> in the template with the name of the target function. For other intents, intent definition templates are also prepared in the contents of the configuration file generation program 45, and each definition can be generated in the same way by replacing a part of the template with the target of the intent (for example, "volume_id", "capacity", etc.). Note that the method of creating intent definitions is not limited to this, and other methods may be used.

[0094] The configuration file generation program 45 creates a scenario definition 21a from the information of the intermediate functions (intermediate classifications) that constitute the target function (S1208). For example, if the remote copy function configuration procedure received in step S1102 includes the intermediate functions of "journal creation," "volume creation," and "pair creation," the configuration file generation program 45 creates a scenario to generate each script, as described in lines 13 to 18 of the scenario definition 21a in Figure 5. Note that the method of creating the scenario is not limited to this, and other methods may be used.

[0095] Next, the configuration file generation program 45 creates a response definition 21d from the information of the intermediate functions (intermediate classifications) that constitute the target function (S1209). For example, if the remote copy function configuration procedure received in step S1102 includes the intermediate functions of "journal creation," "volume creation," and "pair creation," the configuration file generation program 45 generates the descriptions from lines 2 to 7 in the Response definition 21d in Figure 8. The configuration file generation program 45 also generates the descriptions from lines 9 to 16 in the Response definition 21d in Figure 8 based on the parameter list information.

[0096] Next, the configuration file generation program 45 creates a chatbot model file 23 using the intent definition 21b, the intent / slot definition 21c, and the scenario definition 21a (S1210).

[0097] Next, when the CPU 30 receives an instruction from the user to execute the chatbot program 47 (S1211), it starts the chatbot program 47. The started chatbot program 47 reads the chatbot model file 23 and starts providing chatbot services (S1212).

[0098] Figure 13 is a flowchart of the action code generation process according to Example 1.

[0099] The action code generation process is executed, for example, after the script generation process.

[0100] The action code generation program 46 displays a code generation screen (S1301). Here, the code generation screen may be the same as the construction screen output in step S1104 of the script generation process.

[0101] Next, the action code generation program 46 receives a script from the code generation screen that sets a predetermined function (target function) to be built for the chatbot (S1302). The action code generation program 46 may accept the script by specifying the name of the script that sets the target function, or it may accept the script directly.

[0102] Next, the action code generation program 46 executes the processes of steps S1303 to S1305 (similar to the processes of steps S1203 to S1205).

[0103] Next, the action code generation program 46 generates parameter entry code (S1306). Here, parameter entry code is code that replaces the code related to the parameters in the script for setting the target function with code that inputs the value obtained by the chatbot from the user and stored in Slot as the parameter setting value. For example, in master-journal.py shown in Figure 9, the parameter entry code is code that replaces the code volume_id:int='example' on line 12 with the code volume_id:int=111 when the value of Slot obtained by the chatbot from the user is 111.

[0104] Figure 14 is a flowchart of the chatbot processing according to Example 1.

[0105] Chatbot processing is the process that is executed when the chatbot program 47 is launched.

[0106] Chatbot program 47 displays a screen for the bot (S1401).

[0107] Next, the chatbot program 47 receives a request from the user for a script to set a predetermined function (target function) (S1402). In this embodiment, the chatbot program 47 receives a natural language sentence (an example of higher-level function identification information) indicating that the user wants a script to set the target function as input.

[0108] The chatbot program 47 displays questions on the bot's screen that ask the user for each of the parameters necessary to configure the target function (S1403).

[0109] Next, the chatbot program 47 receives the answer to the question, that is, the setting value of each parameter, as a value expressed in natural language (S1404).

[0110] Next, the chatbot program 47 saves the setting values ​​for each parameter received from the user to their respective slots (S1405).

[0111] Next, the script search program 49 searches the script database 48 for a script that sets the target function (S1406).

[0112] Next, the parameter entry program 50 executes the action code 22 corresponding to the target function, thereby entering the setting values ​​of each parameter stored in the Slot into the script obtained in step S1406 (S1407).

[0113] Next, the chatbot program 47 outputs a URL to the bot's screen that allows it to access a script (execution script) with the parameter settings already filled in (S1408). Alternatively, the script itself may be output to the bot's screen instead of the script's URL.

[0114] Figure 15 illustrates the dialogue between the operations manager and the chatbot in Example 1.

[0115] Figure 15 shows the interaction between an administrator who wants to configure the remote copy function and a chatbot. Specifically, when the administrator inputs "I want to configure remote copy" (S1501), the chatbot queries a series of slots, i.e., the settings for each parameter required for the script, and receives the responses from the administrator (S1502~S1510). The slots queried are volume_id, pool_id, capacity, and journal_id.

[0116] If all slots are answered, the chatbot program 47 executes the chatbot processing shown in Figure 14 and outputs "A script has been created. Please obtain it from the link below: https: / / hoge.fuga / master-journal.py" (S1511). The administrator can obtain the script to configure the target function by clicking the displayed link. Here, the method of outputting the script is not limited to presenting a link; the content of the script may also be displayed directly on the screen. If there are multiple intermediate function scripts required for configuring the remote copy function, the same processing will be performed on each script. This makes it possible to create all the intermediate function scripts required for configuring the higher-level function.

[0117] As explained above, with the computer 1 according to Embodiment 1, the operations manager can easily and appropriately generate a script for setting the desired function, even if they are not familiar with the setting procedure for setting the desired function. [Examples]

[0118] Next, we will describe the computer according to Example 2.

[0119] Example 2 differs from Example 1 in the following respects. In this example, instead of using the procedure extraction generation AI program 43, the build administrator directly inputs information on the setting procedures (setting procedure information) for configuring the desired functions into the computer. In the bot build process, the script generation process, the configuration file generation process, and the action code generation process are executed based on the input setting procedure information. The following description will focus on the differences from Example 1, and explanations of overlapping content may be omitted.

[0120] Figure 16 is a diagram illustrating the overview of the computer processing according to Example 2.

[0121] In the computer used in Example 2, the pre-database construction process and the bot construction process differ from those in Example 1.

[0122] In the pre-database construction process S40, the API code database 44b and the API specification database 70 are constructed. The process for constructing the API code database 44b is the same as in Example 1, so the explanation is omitted.

[0123] The API specification database 70 is, for example, a database that manages key-value pairs, where the key is an API description and the value is information about the API specification corresponding to the API description of the key. In Figure 16, the API description is shown as a description of a natural language expression, but for example, the description of a natural language expression may be a numerical value vectorized using a predetermined language model. Here, Word2Vec, BERT, and text-embedding-ada-002 can be used as the language model, but other existing language models or newly developed language models may also be used.

[0124] In Bot construction process S50, the computer receives bulleted configuration procedure information from the construction administrator via a construction screen. The configuration procedure information may be structured to have multiple levels (classifications) as shown in Figure 16. An example of configuration procedure information will be described later. Furthermore, in Bot construction process S50, computer 1 generates a template script that executes each configuration procedure for setting up the functions based on the received configuration procedure information (S51, S52) and stores it in the script database 48 (S53).

[0125] Next, the computer searches the API specification database 70 for the specifications of each API that configures each function based on the received bulleted list of setup procedures (S54). Then, the computer generates and outputs a chatbot configuration file 21 and an action code 22 based on the specifications of each API (S55, S56). The computer generates a chatbot model file 23 from the chatbot configuration file 21 (S57).

[0126] Figure 17 is a diagram showing the configuration of the setting procedure information related to Example 2.

[0127] The setting procedure information 60 is composed of a hierarchical structure, for example, having a major category 61, a medium category 62, and a minor category 63.

[0128] The major category 61 stores the functions (higher-level functions) for which the system administrator requests scripts. In the example in Figure 17, remote copy settings are stored. The subcategory 62 stores the intermediate functions that make up the higher-level functions. In the example in Figure 17, five intermediate functions are stored: journal settings for the primary site, data volume settings for the primary site, journal settings for the secondary site, data volume settings for the secondary site, and pair creation. In this embodiment, scripts are generated using intermediate functions as the unit. The minor category 63 stores the lower-level functions that make up the intermediate functions. A lower-level function is, for example, the smallest unit of an API. In this embodiment, an intermediate function has one or more lower-level functions. In a script that sets up an intermediate function composed of multiple lower-level functions, multiple APIs that set up multiple lower-level functions will be executed.

[0129] Figure 18 is a diagram showing an example of the configuration of an API specification database related to Example 2.

[0130] The API specification database 70 is created, for example, during the pre-database construction process. The API specification database 70 stores entries for each API.

[0131] An entry in the API specification database 70 includes a key 701 and a value 702. Key 701 stores the description of the API corresponding to the entry, which serves as the key. In this embodiment, the API description may be a vectorized value of a string representing the natural language expression of the API description. The API description may also be the summary in the API specification 24. For example, for the API for POST to / v1 / volumes in the API specification 24 in Figure 3, the value on line 11 may be used. Note that the API description may also contain information other than the summary.

[0132] The value702 contains the API specification corresponding to the entry, which is the value. The API specification may be information about the parameters for executing the API. For example, for the API for POSTing to / v1 / volumes in API specification 24 in Figure 3, the values ​​on lines 26-38 may be used. For example, the value702 of the first entry contains file 703, which is a code file with the filename Create-volume.yml.

[0133] In file 703, line 4 describes the parameter name "volumeId," and line 5 describes the type of this parameter as "integer." Other parameters are described similarly. Note that the information regarding the specifications of each API is not limited to the parameter information in the API specification that conforms to SWAGGER; it may also be information regarding any other API specification. Furthermore, in the example shown in Figure 18, the API specification information is in YAML format, but this is not the only format; any format, such as JSON, may be used.

[0134] Figure 19 is a flowchart of the chatbot configuration process according to Example 2.

[0135] The configuration file generation program 45 displays a configuration screen (S1901). Next, the configuration file generation program 45 receives configuration procedure information 60 for the target function via the configuration screen (S1902).

[0136] Next, the configuration file generation program 45 searches the API specification database 70 for API specification information corresponding to each configuration procedure in the configuration procedure information 60, that is, the configuration procedure of the subcategory in Figure 17 (S1903).

[0137] Next, the configuration file generation program 45 creates a list of parameters for each script, using the subcategory in Figure 17 as the unit of the script to be generated (S1904). For example, for "...Journal settings" in the configuration procedure information 60 shown in Figure 17, a list of parameters including volume_id, pool_id, capacity, volume_id, and journal_id is created from the API specification information (e.g., parameter codes) extracted in S1903.

[0138] Next, the configuration file generation program 45 removes duplicate parameters from the list of parameters (S1905). For example, in the configuration procedure information 60 shown in Figure 17, for "...Journal settings", since volume_id is duplicated, one volume_id is removed, and volume_id, pool_id, capacity, and journal_id remain in the list information.

[0139] The configuration file generation program 45 creates entity and slot definitions 21c from the parameter list information (S1906). For example, since the volume_id in the above list information is of type int, the type in the entity and slot definition 21c will be CARDINAL, as shown in Figure 7, and since Capacity is of type str, the type will be text. Other entities and slots are created in the same manner.

[0140] The configuration file generation program 45 creates an intent definition 21b from the parameter list information (S1907). For example, the configuration file generation program 45 has templates such as "How do I configure <function name>?", "Tell me how to configure <function name>", and "I want to configure <function name>" prepared internally. The configuration file generation program 45 generates the definition of ask_how_configure_remote_copy in the intent definition 21b shown in Figure 6 by replacing <function name> in the template with the name of the target function. For other intents, intent definition templates are also prepared in the contents of the configuration file generation program 45, and each definition can be generated in the same way by replacing a part of the template with the target of the intent (for example, "volume_id", "capacity", etc.). Note that the method of creating intent definitions is not limited to this, and other methods may be used.

[0141] The configuration file generation program 45 creates a scenario definition 21a from the information of the intermediate functions (intermediate categories) that constitute the target function (S1908). For example, if the configuration procedure information for the remote copy function received in step S1902 includes the intermediate functions of "journal creation," "volume creation," and "pair creation," the configuration file generation program 45 creates a scenario to generate each script, as described in lines 13 to 18 of the scenario definition 21a in Figure 5. Note that the method of creating the scenario is not limited to this, and other methods may be used.

[0142] Next, the configuration file generation program 45 creates a response definition 21d from the information of the intermediate functions (intermediate categories) that constitute the target function (S1909). For example, if the configuration procedure information for the remote copy function received in step S1902 includes the intermediate functions of "journal creation," "volume creation," and "pair creation," the configuration file generation program 45 generates the descriptions from lines 2 to 7 in the Response definition 21d in Figure 8. The configuration file generation program 45 also generates the descriptions from lines 9 to 16 in the Response definition 21d in Figure 8 based on the parameter list information.

[0143] Next, the configuration file generation program 45 creates a chatbot model file 23 using the intent definition 21b, the intent / slot definition 21c, and the scenario definition 21a (S1910).

[0144] Next, when the CPU 30 receives an instruction from the user to execute the chatbot program 47 (S1911), it starts the chatbot program 47. The started chatbot program 47 reads the chatbot model file 23 and starts providing the chatbot service (S1912).

[0145] Figure 20 is a flowchart of the action code generation process according to Example 2.

[0146] The action code generation program 46 displays the code generation screen (S2001).

[0147] Next, the action code generation program 46 receives setting procedure information for a predetermined function (target function) to be built in the chatbot from the code generation screen (S2002).

[0148] Next, the action code generation program 46 executes the processing in steps S2003 to S2005 (similar to the processing in steps S1903 to S1905).

[0149] Next, the action code generation program 46 generates parameter entry code (S2006). Here, parameter entry code is code that replaces the code related to the parameters in the script for setting the target function with code that inputs the value obtained by the chatbot from the user and stored in Slot as the parameter setting value. For example, in master-journal.py shown in Figure 9, the parameter entry code is code that replaces the code volume_id:int='example' on line 12 with the code volume_id:int=111 when the value of Slot obtained by the chatbot from the user is 111.

[0150] As explained above, with the computer according to Example 2, the operations manager can easily and appropriately generate a script for setting the desired function, even if they are not familiar with the setting procedures for setting the desired function.

[0151] It should be noted that the present invention is not limited to the embodiments described above, and can be implemented with appropriate modifications without departing from the spirit of the invention. [Explanation of symbols]

[0152] 1...Calculator, 20...Memory device, 21...Chatbot configuration file, 22...Action code, 23...Chatbot model file, 24...API specification, 30...CPU, 40...Memory, 41...Manual search program, 42...Manual database, 43...Procedure extraction generation AI program, 44...Script generation program, 45...Configuration file generation program, 46...Action code generation program, 47...Chatbot program, 48...Script database

Claims

1. A script generation device that generates a script to set a predetermined higher-level function for a predetermined device, A device comprising a memory device and a processor, The aforementioned storage device is It stores a database that stores the code for multiple APIs to configure each of multiple functions, The processor, having received a request from the user to configure a higher-level function implemented using multiple lower-level functions, The code for multiple APIs used to configure multiple subordinate functions related to the above request is retrieved from the database. Using the acquired API codes, a script for the higher-level function is created to configure the aforementioned higher-level function. Based on user input, the parameters of the higher-level function script are set, and the higher-level function script is issued. Script generator.

2. The storage device stores setting procedure information related to the settings of the device, The aforementioned processor, The multiple lower-level functions to be used for the higher-level function are identified from the aforementioned setting procedure information. The script generation device according to claim 1.

3. The aforementioned processor, A chatbot is set up to interact with the user, and the user's input for setting the parameters is received through the interaction with the chatbot. The script generation device according to claim 1.

4. The aforementioned setup procedure information is, This includes the setting of multiple intermediate functions used for setting the predetermined higher-level function, and the setting of lower-level functions used for setting the intermediate function. The script generation device according to claim 2.

5. The aforementioned processor, The parameters used in the multiple API codes obtained by the above search are identified, and duplicates are removed from the parameters of the identified multiple codes. Obtain input from the user to set parameter values ​​that have been eliminated. The script generation device according to claim 1.

6. The aforementioned processor, Using the settings of the aforementioned parameters, a parameter entry code is created to be entered into the parameters of the script for the higher-level function. The script generation device according to claim 1.

7. The aforementioned processor, The system accepts information from the user to identify the higher-level function to be configured. The script for setting the higher-level function corresponding to the aforementioned higher-level function identification information accepts input of parameter settings, Search for a script for higher-level functions that configures the higher-level functions corresponding to the aforementioned higher-level function identification information. By entering the parameter settings received by the chatbot into the aforementioned higher-level function script, an execution script is created. Output the aforementioned execution script. The script generation device according to claim 3.

8. The aforementioned processor, From a document describing the specifications of multiple APIs of the aforementioned device, multiple pairs of subordinate function identification information, which identifies a subordinate function, and the API code that executes the configuration of the subordinate function are identified and stored in the database. The script generation device according to claim 1.

9. A script generation method using a script generation device that generates a script to set a predetermined higher-level function for a predetermined device, The script generation device, The system receives a request from a user to configure a higher-level function that is implemented using multiple lower-level functions, and retrieves from a database that stores the API codes for multiple APIs used to configure each of the multiple lower-level functions for the device in question, the device being configured for the request, the API codes required for configuring the multiple lower-level functions used to configure the higher-level function, Using the acquired API codes, create a script for the higher-level function to configure the aforementioned higher-level function. Based on user input, the parameters of the higher-level function script are set, and the higher-level function script is issued. How to generate a script.

Images