Document generation device and document generation method

Abstract

To enable generation of a document also relating to codes other than representative codes.SOLUTION: A document generation device includes: an input generation unit that uses input data including one or more processing units to generate input to a document generation unit for each processing unit according to processing order as order to process the processing unit; and a document acquisition unit that inputs the input to the document generation unit to acquire a document relating to the processing unit from the document generation unit.SELECTED DRAWING: Figure 1

Description

[Technical Field]

[0001] The present invention relates to a document generation device and a document generation method. [Background technology]

[0002] The spread of agile development has created a demand for technology to generate documentation from source code. Non-Patent Document 1 discloses a technology that generates readmes using a large-scale language model by extracting representative code fragments that provide an overview of what a repository does using heuristics and weakly supervised learning. [Prior art documents] [Patent documents]

[0003] [Non-Patent Document 1] Yuta Koreeda and 3 others, "Readme Generation Based on Large-Scale Language Models and Heuristics," [online], 2023, Japanese Society for Artificial Intelligence, retrieved February 14, 2024, Internet<URL:https: / / www.jstage.jst.go.jp / article / pjsai / JSAI2023 / 0 / JSAI2023_4Xin108 / _pdf> Summary of the Invention [Problem to be solved by the invention]

[0004] The invention described in Patent Document 1 can only generate documentation (readme) related to representative code. [Means for solving the problem]

[0005] A document generation device according to a first aspect of the present invention comprises an input generation unit that uses input data including one or more processing units to generate input to the document generation unit for each processing unit in accordance with a processing order, which is the order in which the processing units are processed, and a document acquisition unit that inputs the input to the document generation unit and acquires a document related to the processing unit from the document generation unit. A document generation method according to a second aspect of the present invention is a document generation method executed by a document generation device, and includes using input data including one or more processing units to generate input, which is a string of characters to be input to a document generation unit for each processing unit, in accordance with a processing order, which is the order in which the processing units are processed, and inputting the input to the document generation unit to obtain a document related to the processing unit from the document generation unit. [Effects of the Invention]

[0006] The present invention allows for the generation of documentation for more than just representative code. [Brief explanation of the drawings]

[0007] [Figure 1] Functional configuration diagram of the document generation device [Figure 2] Hardware configuration diagram of the document generation device [Figure 3] A diagram showing an example of a code repository [Figure 4] A diagram showing an example of a generated document [Figure 5] An example of a call graph [Figure 6] A diagram showing an example of a processing sequence [Figure 7] An example of a graph-style external API reference [Figure 8] A diagram showing an example of a set of data acquisition functions [Figure 9] A diagram showing an example of a data acquisition function selection table [Figure 10] A diagram showing an example of an input template [Figure 11]FIG. 10 is a diagram showing an example of an input template correspondence table; [Figure 12] Flowchart showing the processing of the calculation unit [Figure 13] Flowchart showing the processing of the processing order determination unit [Figure 14] Image diagram showing the processing of the processing order determination unit [Figure 15] Flowchart showing the processing of the input generation unit [Figure 16] A diagram showing the user interface operated by the user [Figure 17] FIG. 10 is a diagram showing an example of a data acquisition method update screen. [Figure 18] FIG. 10 is a diagram showing an example of an input template update screen. [Figure 19] An example of the API reference update screen [Figure 20] Flowchart showing the processing of the input generation unit in Modification 2 DETAILED DESCRIPTION OF THE INVENTION

[0008] -First embodiment- A first embodiment of a document generation device and a document generation method will be described below with reference to Figures 1 to 19. The document generation device described below analyzes input source code groups and generates documents for each processing unit. Processing units are, for example, functions, scripts, classes, and class methods. The processing units have the same or smaller granularity as source code.

[0009] 1 is a functional configuration diagram of a document generation device 1. The document generation device 1 includes a calculation unit 10 and a data storage unit 4. The calculation unit 10 includes a processing order determination unit 11, an input generation unit 12, and a document acquisition unit 13. The data storage unit 4 stores a code repository 41, a call graph 42, a processing order 43, a graph-format external API reference 44, a data acquisition function group 45, a data acquisition function selection table 46, an input template 47, an input template correspondence table 48, and a generated document 49. Details of the data stored in the data storage unit 4 will be described later.

[0010] The code repository 41, graph-format external API reference 44, data retrieval function group 45, data retrieval function selection table 46, input template 47, and input template correspondence table 48 are created in advance and stored in the data storage unit 4. The call graph 42 and processing order 43 are generated by the processing order determination unit 11. The generated document 49 is generated by the document generation unit 99, which will be described later. The code repository 41 includes one or more source codes. Hereinafter, the code repository 41 will also be referred to as "input data."

[0011] The processing order determination unit 11 reads the code repository 41 and outputs a call graph 42 and a processing order 43. The input generation unit 12 reads the code repository 41, the call graph 42, the processing order 43, the graph-format external API reference 44, the data acquisition function group 45, the data acquisition function selection table 46, the input template 47, the input template correspondence table 48, and the generated document 49, generates an input for each processing unit, and outputs the generated input to the document acquisition unit 13.

[0012] The document acquisition unit 13 inputs the input for each processing unit generated by the input generation unit 12 to the document generation unit 99 to obtain a document. The document acquisition unit 13 stores the document acquired from the document generation unit 99 as a generated document 49 in the data storage unit 4. The generation of input by the input generation unit 12 and the acquisition of documents by the document acquisition unit 13 are executed repeatedly. The input generation unit 12 reads the documents acquired by the document acquisition unit 13 up to that point as needed. This will be described in more detail later.

[0013] Text is input to the document generation unit 99, which outputs text sentences. The document generation unit 99 is, for example, a language model or a large-scale language model. The input is an operation command for the document generation unit 99, and the document generation unit 99 operates based on the input. The document generation unit 99 may be realized by hardware different from the document generation device 1, or may operate inside the document generation device 1. The document generation unit 99 may also be provided as an API service.

[0014] FIG. 2 is a hardware configuration diagram of document generation device 1. Document generation device 1 includes a calculation device 2, a main memory device 3, a data storage unit 4, a network IF 5, an input IF 6, and an output IF 7. The calculation device 2 is, for example, a central processing unit. The calculation device 2 implements a calculation unit 10 by loading a program stored in a ROM (not shown) into the main memory device 3 and executing it. The main memory device 3 is a storage device capable of high-speed reading and writing, such as a DRAM (Dynamic Random Access Memory). The data storage unit 4 is a non-volatile storage device, such as a hard disk drive. However, the data storage unit 4 may be implemented by combining multiple storage devices.

[0015] The network IF5 is a communication interface, such as a network interface card, that enables the document generation device 1 to communicate with other devices. The input IF6 is an interface for communicating with an input device 92 that accepts input from a user 95. The output IF7 is an interface for communicating with a display 91 that outputs video to the user 95. However, the network IF5 may be used instead of the input IF6 or the output IF7.

[0016] FIG. 3 is a diagram showing an example of a code repository 41. The code repository 41 contains a group of source code. In the example shown in FIG. 3, the source code "main.py" and the directories "hoge_dir" and "piyo_dir" are located directly under the directory "repos" in the code repository 41. The directory "hoge_dir" stores the source code "hoge.py". The directory "piyo_dir" stores the source code "piyo.py". Although FIG. 3 only shows file names, the code repository 41 also contains the actual source code of each source code.

[0017] Fig. 4 is a diagram showing an example of generated document 49. This example corresponds to the example of code repository 41 shown in Fig. 3. The generated document 49 shown in Fig. 4 includes documentation on the "main" function included in "main.py", documentation on the "hoge_a_func", "hoge_b_func", and "hoge_c_func" functions included in "hoge.py", and documentation on the "piyo_func" function included in "piyo.py".

[0018] Figure 5 shows an example of a call graph 42. This example corresponds to the examples shown in Figures 3 and 4. The call graph 42 is a type of "dependency graph," which is a directed graph that shows syntactic and semantic relationships in a program, such as inheritance relationships and variable reference relationships, as well as citation relationships between documents. The call graph 42 shows the calling relationships between processing units. Specifically, data related to the type, code path, function name, and document path for each processing target is listed. Below, the type, code path, function name, and document path for each processing unit are collectively referred to as a "node." That is, six nodes are shown in Figure 5. Strictly speaking, if the type is an external function, document generation is not required, but for convenience, it is referred to as a "processing unit."

[0019] The type is the type of processing unit, such as an execution script, function, or external function. The code path is the path of the source code that contains the processing unit. The function name is the name of the function that is written when the processing unit is a function. The document path is the path where the document to be processed is stored.

[0020] FIG. 6 is a diagram showing an example of a processing order 43. This example corresponds to the examples shown in FIGS. 3 to 5. The processing order 43 shows five nodes, excluding one node whose type is an external function from the six nodes shown in FIG. 5. In FIG. 6, the processing order is indicated by arrows, and is specifically as follows: That is, it shows that the function name "piyo_func" shown at the top of FIG. 6 is processed first, the function name "hoge_b_func" shown next is processed second, and "main.py" is processed last.

[0021] FIG. 7 is a diagram showing an example of a graph-format external API reference 44. This example corresponds to the examples shown in FIGS. 3 to 5. In the graph-format external API reference 44, data related to external APIs not included in the code repository 41 is described in a graph format. Specifically, the graph-format external API reference 44 includes citation relationships of the external APIs and descriptions of the external APIs. In the example shown in FIG. 7, the description of the external APIs is omitted, but specific explanatory text used to generate the input is actually stored.

[0022] Fig. 8 is a diagram showing an example of the data acquisition function group 45. The data acquisition function group 45 describes specific codes of functions for acquiring data. Fig. 8 shows three example functions. Which function should be used is shown in the data acquisition function selection table 46.

[0023] Fig. 9 is a diagram showing an example of the data acquisition function selection table 46. This example corresponds to the example shown in Fig. 8. The data acquisition function selection table 46 is referenced to determine the process for acquiring data related to the processing unit, that is, to determine which function from the data acquisition function group 45 to use. The conditions in the data acquisition function selection table 46 can also be rephrased as the attributes of the node.

[0024] FIG. 10 is a diagram showing an example of an input template 47. This example corresponds to the examples shown in FIGS. 8 and 9. The input template 47 includes multiple templates. In each template, the character strings enclosed in curly brackets, specifically {function_name} and {called_function_1}, are substituted by the input generation unit 12 with the name of the processing unit and the name of the called function. The source code of the corresponding processing unit read from the code repository 41 is transcribed under "Code of {function_name}." The docstring of the called function is transcribed under "Description of {called_function_1}." If the called function is included in the code repository 41, a sentence generated by the document generation unit 99 is used as the docstring. If the called function is not included in the code repository 41, a description of the module, etc., described in the graph-format external API reference 44 and data acquired by the data acquisition function are used.

[0025] 11 is a diagram showing an example of the input template correspondence table 48. The input template correspondence table 48 shows the selection of the input template 47 for each processing unit.

[0026] 12 is a flowchart showing the processing of the calculation unit 10. First, in step S301, the processing order determination unit 11 reads the code repository 41, creates a call graph 42, and then determines a processing order 43. Details of this step will be described later with reference to FIG. 13. In the following step S302, the calculation unit 10 sets the processing unit listed at the top of the processing order 43 as the processing target, and proceeds to step S303. In step S303, the input generation unit 12 of the calculation unit 10 generates an input. Details of this step will be described later with reference to FIG. 15.

[0027] In the following step S304, the document acquisition unit 13 inputs the input to the document generation unit 99. In the following step S305, the document acquisition unit 13 stores the output of the document generation unit 99 in the generated document 49 of the data storage unit 4. In the following step S306, the calculation unit 10 determines whether all processing units have been processed. If the calculation unit 10 determines that all processing targets have been processed, in other words, that all processing units have been set as processing targets, it ends the processing shown in FIG. 12. If the calculation unit 10 determines that there is a processing target that has not been processed, it proceeds to step S307. In step S307, the calculation unit 10 sets the processing unit listed next to the current processing target in the processing order 43 as the new processing unit, and returns to step S303.

[0028] 13 is a flowchart showing the processing of the processing order determination unit 11, and is a flowchart showing details of step S301 in FIG. 12. First, in step S311, the processing order determination unit 11 reads the code repository 41 from the data storage unit 4 and analyzes the code repository 41 to create a call graph 42. Various known techniques can be used to create the call graph 42. In the following step S312, the processing order determination unit 11 saves the call graph 42 created in step S311 in the data storage unit 4. In the following step S313, the processing order determination unit 11 topologically sorts the call graph 42.

[0029] In the next step S314, the processing order determination unit 11 determines the order of the processing units based on the result of the topological sort. In the next step S315, the processing order determination unit 11 stores the order determined in step S314 as the processing order 43 in the data storage unit 4, and the processing shown in FIG. 13 ends.

[0030] 14 is an image diagram showing the processing of the processing order determination unit 11. "main.py" shown at the top calls "hoge_a_func" and "piyo_func", and "hoge_a_func" calls "hoge_c_func" and "hoge_b_func". In this case, the processing order determination unit 11 sets the processing order 43 so that processing proceeds from the bottom to the top of the illustration. By setting the processing order 43 in this way, a document for the processing unit of the callee is generated at the time the caller's processing is performed.

[0031] Fig. 15 is a flowchart showing the processing of the input generation unit 12. The processing shown in Fig. 15 is a detail of step S303 in Fig. 12, and the processing unit to be processed is set in advance at the time when the processing shown in Fig. 15 starts. First, in step S321, the input generation unit 12 reads the call graph 42 from the data storage unit 4. In the following step S322, the input generation unit 12 obtains the source code of the processing unit to be processed from the data storage unit 4.

[0032] In the next step S323, the input generation unit 12 determines whether the processing target has a child node. For example, in the case of the call graph 42 shown in FIG. 5, if the processing target is the function "hoge_b_func" or the function "hoge_c_func," a negative determination is made in this step. If the input generation unit 12 determines that the processing target has a child node, the process proceeds to step S324; if the input generation unit 12 determines that the processing target does not have a child node and is the end of a node, the process proceeds to step S325. In step S324, the input generation unit 12 obtains the document of the graph child node and proceeds to step S325.

[0033] In the following step S325, the input generation unit 12 determines a template to use based on the node type and other factors of the processing target. Specifically, the input generation unit 12 refers to the input template correspondence table 48 and selects a template that meets the conditions. In the following step S326, the input generation unit 12 determines a data retrieval function. Specifically, the input generation unit 12 refers to the data retrieval function selection table 46 and determines one of the data retrieval functions based on the node type and conditions of the processing unit to be processed. In the following step S327, the input generation unit 12 executes the data retrieval function determined in step S326 to collect data necessary for generating the input. In the following step S328, the input generation unit 12 generates an input by embedding the data collected in step S327 in the template determined in step S325, and then ends the processing shown in FIG. 15.

[0034] 16 is a diagram showing a user interface 81 operated by a user 95. The user interface 81 includes an upload window 810, a data update window 812, a graph window 813, and a document window 814. When the user 95 drags and drops a ZIP file that includes the code repository 41 into the upload window 810 and presses a start generation button 811, processing by the calculation unit 10 shown in FIG.

[0035] The data update window 812 includes a data acquisition method update button 8121, an input template update button 8122, and an API reference update button 8123. When the user 95 presses the data acquisition method update button 8121, a data acquisition method update screen 82, which will be described later, is displayed. When the user 95 presses the input template update button 8122, an input template update screen 83, which will be described later, is displayed. When the user 95 presses the API reference update button 8123, an API reference update screen 84, which will be described later, is displayed.

[0036] The graph window 813 displays the call graph 42 generated by the processing order determination unit 11. However, nothing is displayed in the graph window 813 before the user 95 presses the generation start button 811. The user 95 can select a node displayed in the graph window 813, and the data of the node selected by the user 95 is displayed in the document window 814. In Figure 16, the node selected by the user 95 is indicated by hatching.

[0037] The document window 814 displays data relating to a node selected by the user 95 in the graph window 813. The data displayed here includes documents generated by the document generator 99.

[0038] 17 is a diagram showing an example of a data acquisition method update screen 82 that is displayed when the user 95 presses the data acquisition method update button 8121. The data acquisition method update screen 82 includes a data acquisition function selection table 820 being edited, an add function button 822, a function edit field 823, and an update function button 824.

[0039] The currently edited data retrieval function selection table 820 has substantially the same configuration as the data retrieval function selection table 46 shown in FIG. 9, with the addition of a selection column 821 on the left side. When the user 95 checks one of the selection columns 821, the function of the selected row is displayed in a function edit column 823. The user 95 can edit the column for node type and condition. Furthermore, when the user 95 presses an add function button 822, a new row is added to the currently edited data retrieval function selection table 820. The user 95 can edit the function displayed in the function edit column 823. When the user 95 presses an update function button 824, the function entered in the function edit column 823 is registered or updated.

[0040] 18 is a diagram showing an example of an input template update screen 83 that is displayed when the user 95 presses the input template update button 8122. The input template update screen 83 includes an input template currently being edited correspondence table 830, an add template button 832, a template edit field 833, and an update template button 834.

[0041] The currently edited input template correspondence table 830 has substantially the same configuration as the input template correspondence table 48 shown in FIG. 11, with the addition of a selection field 831 on the left side. When the user 95 checks one of the selection fields 831, the template for the selected row is displayed in a template editing field 833. The user 95 can edit the condition field. Furthermore, when the user 95 presses an add template button 832, a new row is added to the currently edited input template correspondence table 830.

[0042] The user 95 can edit the functions displayed in the template edit field 833. When the user 95 presses the template update button 834, the template entered in the template edit field 833 is registered or updated.

[0043] 19 is a diagram showing an example of the API reference update screen 84 that is displayed when the user 95 presses the API reference update button 8123. The API reference update screen 84 includes a node edit window 841, an add upper node button 845, an add lower node button 846, a delete selected node button 847, an edit description field 848, and an update description button 849.

[0044] The node edit window 841 displays the currently registered graph-format external API references 44, and the user 95 adds nodes by operating the buttons. FIG. 19 shows a situation in which the user 95 selects the central node indicated by the reference numeral 843, and then presses the add upper node button 845, thereby adding a node indicated by the reference numeral 842. The user 95 can edit the description displayed in the description edit field 848. When the user 95 presses the description update button 849, the description written in the description edit field 848 is registered or updated.

[0045] According to the first embodiment described above, the following advantageous effects can be obtained. (1) The document generation device 1 includes an input generation unit 12 that uses input data including one or more processing units, i.e., a code repository 41, to generate an input, which is a character string to be input to a document generation unit 99 for each processing unit, in accordance with a processing order 43 that is the order in which the processing units are processed, and a document acquisition unit 13 that inputs the input to the document generation unit 99 and acquires a document related to the processing unit from the document generation unit 99. Therefore, the document generation device 1 can generate documents related to other than representative code.

[0046] (2) The document generation device 1 includes a processing order determination unit 11 that analyzes input data to generate a dependency graph and determines a processing order 43 based on the dependency graph. Therefore, the document generation device 1 can create the processing order 43 by itself without relying on other devices or operators.

[0047] (3) The input generation unit 12 includes, as necessary, documents generated by the document generation unit 99 for processing units that precede the target unit, which is the processing unit for which the input is generated. This allows the document generation device 1 to generate documents that also take into account explanations of the called functions.

[0048] (4) When the target unit has a child node in the call graph 42 (S323 in FIG. 15: YES), the input generation unit 12 includes in the input the document generated by the document generation unit 99 for the child node. This allows the document generation device 1 to generate a document that also takes into account the explanation of the called function.

[0049] (5) The input generation unit 12 determines an input template according to the type of processing unit (S325 in FIG. 15) and generates an input according to the template. Therefore, the input generation unit 12 can use an appropriate template according to the type of processing unit.

[0050] (6) When the target unit has a child node in the dependency graph, the input generation unit 12 changes the document acquisition means of the child node according to the type and attribute of the child node, i.e., the namespace (S326 in FIG. 15), and includes the document acquired by the document acquisition means in the input (S327 in FIG. 15). Therefore, the input generation unit 12 can include the document of the child node in the input.

[0051] (Variation 1) The calculation unit 10 does not have to include the processing order determination unit 11. For example, a device other than the document generation device 1 may include the processing order determination unit 11, and the call graph 42 and the processing order 43 may be input to the document generation device 1 from outside. Furthermore, it is not essential that the processing order determination unit 11 generates the call graph 42 and the processing order 43; for example, an operator may generate the call graph 42 and the processing order 43 and input them to the document generation device 1.

[0052] (Variation 2) Fig. 20 is a flowchart showing the processing of the input generation unit 12 in Modification 2. The difference from Fig. 15 described in the first embodiment is that step S329 is added. In this modification, if a positive determination is made in step S323, the process proceeds to step S329 instead of step S324. In step S329, the input generation unit 12 determines whether the child node to be processed has been learned by the document generation unit 99.

[0053] Specifically, if the type of the child node to be processed is an external function and the function name is included in the pre-created learned function list, the input generation unit 12 makes a positive determination in this step and proceeds to step S325. If the type of the child node to be processed is not an external function or the function name is not included in the pre-created learned function list, the input generation unit 12 makes a negative determination and proceeds to step S324. Note that if there are multiple child nodes to be processed in step S329, a positive determination is made only if the type of the child node for all nodes is an external function and the function name is included in the pre-created learned function list.

[0054] According to the second modification, the following effects can be obtained. (7) When the target unit has a child node in the call graph 42 and the document generation unit 99 has not learned data related to the child node (YES in S323 and NO in S329 in FIG. 20), the input generation unit 12 includes in its input the document generated by the document generation unit 99 for the child node. This eliminates the need for the input generation unit 12 to include in its input the document related to the function that the document generation unit 99 has learned.

[0055] (Variation 3) The processing target of the document generation device 1 is not limited to source code. The document generation device 1 can process various documents including citations. For example, the document generation device 1 can process HTML files that reference other files, legal provisions that reference other provisions, and the like.

[0056] (Variation 4) The document generation device 1 may process only a single file or a single source code. When a single source code contains multiple functions and there is a call relationship between the functions, the same effects as those of the above-described embodiment can be obtained.

[0057] (Variation 5) The processing order determination unit 11 may output data in another format that indicates the dependency relationships for each processing unit instead of the call graph 42. For example, a character string, a table, XML, or the like may be used instead of the call graph 42.

[0058] (Variation 6) The means by which the processing order determination unit 11 determines the processing order 43 is not limited to the above-mentioned means, and various known techniques can be adopted. For example, the processing order determination unit 11 may use ReAct (Reasoning and Acting).

[0059] (Variation 7) The means by which the input generation unit 12 acquires information outside the code repository 41 is not limited to the above-described means, and various known techniques may be employed. For example, the input generation unit 12 may use Retrieval-Augmented Generation (RAG).

[0060] (Variation 8) The input generated by the input generation unit 12 is not limited to character strings. For example, if a multimodal large-scale language model capable of inputting and outputting not only character strings but also images and sounds is used as the document generation unit 99, the input can include images and sounds published in the document.

[0061] (Variation 9) The generated document 49 output by the document generator 99 is not limited to a character string. For example, if a multimodal large-scale language model is used as the document generator 99, images required for the document can be output along with the character string.

[0062] In each of the above-described embodiments and modifications, the functional block configurations are merely examples. Some functional configurations shown as separate functional blocks may be configured as an integrated unit, or a configuration shown in a single functional block diagram may be divided into two or more functions. Furthermore, some of the functions of each functional block may be provided by other functional blocks.

[0063] In the above-described embodiments and modifications, the program is stored in a ROM (not shown), but the program may be stored in the data storage unit 4. Furthermore, the document generation device 1 may be provided with an input / output interface (not shown), and the program may be loaded from another device as needed via the input / output interface and a medium usable by the document generation device 1. Here, the medium refers to, for example, a storage medium detachable from the input / output interface, or a communication medium, i.e., a wired, wireless, or optical network, or a carrier wave or digital signal propagating through the network. Furthermore, some or all of the functions realized by the program may be realized by a hardware circuit or FPGA.

[0064] The above-described embodiments and modifications may be combined with each other. Although various embodiments and modifications have been described above, the present invention is not limited to these. Other embodiments conceivable within the scope of the technical concept of the present invention are also included within the scope of the present invention. [Explanation of symbols]

[0065] 1: Document generation device 11: Processing order determination unit 12: Input generation unit 13: Document acquisition section 41: Code repository 42: Call graph 43: Processing order 44:Graph format external API reference 45: Data acquisition functions 46: Data Acquisition Function Selection Table 47: Input template 48: Input template correspondence table 49: Generated document 99: Document Generation Unit

Claims

1. an input generation unit that uses input data including one or more processing units and generates an input to the document generation unit for each processing unit in accordance with a processing order that is an order in which the processing units are processed; a document acquisition unit that inputs the input to the document generation unit and acquires a document related to the processing unit from the document generation unit.

2. 2. The document generation device according to claim 1, The document generation device, wherein the input data is source code.

3. 2. The document generation device according to claim 1, The document generation device, wherein the document generation unit is a machine learning model.

4. 2. The document generation device according to claim 1, The document generation device, wherein the processing unit is a function.

5. 2. The document generation device according to claim 1, A document generation device in which the input generation unit includes, as necessary, the document generated by the document generation unit for a processing unit that precedes the target unit, which is the processing unit for which the input is to be generated, in the input.

6. 2. The document generation device according to claim 1, The input generation unit determines a template for the input according to a type of the processing unit, and generates the input according to the template.

7. 2. The document generation device according to claim 1, The document generation device further comprises a processing order determination unit that analyzes the input data to generate a dependency graph, and determines the processing order based on the dependency graph.

8. 8. The document generation device according to claim 7, The document generation device, wherein the dependency graph is a call graph.

9. 9. The document generation device according to claim 7, A document generation device in which the input generation unit includes the document generated by the document generation unit for the child node in the input when the target unit, which is the processing unit for which the input is to be generated, has a child node in the dependency graph.

10. 9. The document generation device according to claim 7, the document generation unit includes a machine learning model; A document generation device in which the input generation unit includes the document generated by the document generation unit for the child node in the input when the target unit, which is the processing unit for which the input is to be generated, has a child node in the dependency graph and the document generation unit has not learned data regarding the child node.

11. 9. The document generation device according to claim 7, The input generation unit, when a target unit, which is the processing unit for which the input is to be generated, has a child node in the dependency graph, changes a document acquisition means for acquiring documents related to the child node according to the type and attributes of the child node, and includes the documents acquired by the document acquisition means in the input.

12. A document generation method executed by a document generation device, comprising: using input data including one or more processing units, generating an input to a document generation unit for each processing unit in accordance with a processing order that is an order in which the processing units are processed; a document generation method including inputting the input to the document generation unit and obtaining a document relating to the processing unit from the document generation unit.

Images