Failure diagnosis device, failure diagnosis method, and program thereof

Abstract

The present invention solves the problem that, because defect reports generally differ in sentence expression (notation variations, language differences, degrees of detail) depending on the person in charge of creating the defect reports, it is not always easy to perform sentence processing on the basis of a predetermined rule or to perform processing by using a word dictionary.　Provided is a defect diagnosis device for diagnosing the cause of a defect from a defect report that is written in regard to a product defect, wherein: the device is configured to include a diagnosis knowledge database for storing information relating to the product defect, an input / output unit for inputting / outputting information, and a processor unit for performing a prescribed computation process; and the processor unit extracts a term associated with the written content of the defect report from the diagnosis knowledge database to create a defect term list, converts the written content of the defect report to a defect answer sentence written in a predetermined format by using the defect term list, and diagnoses the cause of the defect written about in the defect report by using the defect answer sentence and the diagnosis knowledge database.

Description

Fault diagnosis device, fault diagnosis method, and program thereof

[0001] The present invention relates to a fault diagnosis device, a fault diagnosis method, and a program therefor that diagnose the cause of a product fault from a fault report that describes the fault.

[0002] When a malfunction occurs in an industrial product or a consumer product or device, a report on the malfunction (a malfunction report) is prepared by the maintenance staff or call center operator who handles the issue, and the location of the malfunction and its root cause are dug up based on the malfunction report. It is expected that by processing this malfunction report using AI technology, maintenance efficiency and accuracy will be improved.

[0003] However, defect reports generally have differences and variations in the way they are expressed and written depending on the maintenance staff who create them, so it is not always easy to process the text based on predetermined rules or using a word dictionary.

[0004] Meanwhile, in recent years, attention has been drawn to language processing models such as LLM (Large Language Models), which can solve a variety of tasks by changing the input instruction sentence. These language processing models are said to have high processing performance for differences in expression through training on multiple tasks using large-scale data, and are expected to be used to automate the identification of defect causes from defect reports of industrial products, etc.

[0005] However, currently available language processing models are not necessarily trained on sentences related to the names of specific industrial product parts or phenomena, and therefore cannot be expected to provide accurate responses regarding product defects. While it is possible to strengthen machine learning models through fine tuning to improve accuracy, this has presented challenges, such as the model parameters required for tuning being confidential in some cases and the need for considerable computational resources for training.

[0006] A conventional invention of this type is described in Patent Document 1 (JP 2017-194727 A), which describes an invention that processes defect reports using natural language processing.

[0007] JP 2017-194727 A

[0008] In Patent Document 1, text processing is performed based on co-occurrence relationships, but as mentioned above, defect reports may be written differently depending on the person who creates them, even if the same event is occurring, and therefore, depending on the target product, the desired results may not be obtained.

[0009] Therefore, it is possible to automate the diagnostic process from defect reports using a language processing model that can solve a variety of tasks by adjusting input prompts (hereinafter referred to as prompts).However, the language processing model may not necessarily have knowledge of industrial product part names and phenomena, and the accuracy of responses regarding industrial product defects may be low.

[0010] In order to solve the above-mentioned problems, the present invention provides a fault diagnosis device that diagnoses the cause of a fault from a fault report that describes a product fault, and includes a diagnostic knowledge database that stores information about the product fault, an input / output unit that inputs and outputs information, and a processor unit that performs predetermined arithmetic processing.The processor unit is configured to extract terms related to the contents of the fault report from the diagnostic knowledge database to create a fault term list, convert the contents of the fault report into a fault answer statement written in a predetermined format using the fault answer statement and the diagnostic knowledge database, and diagnose the cause of the fault described in the fault report.

[0011] It is possible to accurately diagnose the cause of a defect even in defect reports that contain differences or variations in expression or description.

[0012] 1 is a configuration diagram of a defect document processing device in this embodiment. FIG. 2 is an example of a diagnostic knowledge DB in this embodiment. FIG. 3 is a diagram showing an overview of diagnostic processing in this embodiment. FIG. 4 is a flowchart of diagnostic processing in this embodiment. FIG. 5 is an example of a defect report in this embodiment. FIG. 6 is an example of a defect term list in this embodiment. FIG. 7 is an example of a prompt sentence in this embodiment. FIG. 8 is an example of an answer sentence in this embodiment. FIG. 9 is an example of a defect feature table in this embodiment. FIG. 10 is a flowchart of searching the diagnostic knowledge DB to obtain a diagnostic result in this embodiment. FIG. 11 is an example of a search of the diagnostic knowledge DB in this embodiment. FIG. 12 is an example of an output of a diagnostic result in this embodiment. FIG. 13 is a flow of generating a defect knowledge sentence in this embodiment. FIG. 14 is an example of a feature word list in this embodiment. FIG. 15 is an example of a sentence template in this embodiment. FIG. 16 is an example of a defect knowledge sentence in this embodiment. FIG. 17 is a flowchart of diagnostic processing in this embodiment. FIG. 18 is an example of a prompt sentence in this embodiment. FIG. 19 is an example of a search query in this embodiment. FIG. 19 is a flowchart of diagnostic processing in this embodiment. FIG. 19 is an example of a screen display in this embodiment. FIG. 20 is a flowchart of expanding the diagnostic knowledge DB in this embodiment.

[0013] Hereinafter, embodiments of the present invention will be described in detail with reference to the accompanying drawings. For the sake of convenience, the same components may be designated by different reference numerals in different drawings, but if the names of the components are basically the same, they are considered to be the same.

[0014] 1A is a configuration diagram of a defect document processing device 1000 according to this embodiment. The defect document processing device 1000 has a processor system 1100 implemented by a personal computer, a general-purpose computer, or the like, and an input / output device 1200 implemented by a display device, a keyboard, or the like. Furthermore, the defect document processing system also includes an external device 1400 connected via a network 1300, as needed.

[0015] The processor system 1100 has a processor unit 1110 that performs arithmetic processing, a memory resource unit 1120 in which programs and data used in the arithmetic processing are stored, a network interface unit (NI) 1130 that is an interface with an external network, etc., and a user interface unit (UI) 1140 that is an interface with a display device, keyboard, etc. used by the user (operator) of this device.

[0016] The memory resource unit 1120 also has a program unit 1121 in which programs (diagnostic processing program 1121A, knowledge DB expansion program 1121B) that perform various processing described below are stored, a diagnostic knowledge database (DB) 1122 that stores information about malfunctions in the target device, a language processing model 1123, and a malfunction report storage unit 1124 that stores the contents of malfunction reports described below, and the processor unit 1110 performs predetermined processing using these programs 1121, knowledge DB 1122, language processing model 1123, malfunction report storage unit 1124, etc.

[0017] Here, the language processing model 1123 is a language processing model that can solve various tasks by changing the input instruction sentence, such as LLM (Large Language Models), and in recent years, ChatGPT (Chat Generative Pre-Trained Transformer) and FLAN (Finetuned Language Net) are well known, but it is not limited to these, and any language processing model that uses a prompt as input will suffice, and is not limited to a specific language processing model.

[0018] In addition, the language processing model 1123 may be located in an external device 1400, etc., in which case the processor unit 1110 can access the language processing model of the external device via the NI (1130) and the network 1300 and obtain the required processing results.

[0019] 1B is an example of a diagnostic knowledge DB, and in this example, the target device is assumed to be an automobile, and shows a portion of the entire diagnostic knowledge DB. The diagnostic knowledge DB stores the locations, phenomena, and causal relationships related to malfunctions in the target device, and is a knowledge graph that hierarchically represents the malfunction locations and the parts and units (parts) that make them up, and also represents the phenomena that can occur in each of these parts (failures and conditions that can cause them) as the reasons and results of phenomena that can occur in other hierarchical parts.

[0020] 1B, for a defect location, multiple nodes (parts) at the start points of arrows constitute parts of the nodes at the same end points of those arrows, and each arrow may be referred to as a "part of link" in this embodiment. Also, for a phenomenon, the phenomenon that causes the node (phenomenon) at the start point of an arrow is the phenomenon at the node at the end of that arrow, and each arrow may be referred to as a "caused by link" in this embodiment.

[0021] Furthermore, the causal relationships may be provided with coefficient information, and the coefficient information may be stored in the form of a Bayesian network, which is probability information, for example.

[0022] Next, the diagnostic process in the document processing apparatus of this embodiment will be outlined with reference to FIG.

[0023] The diagnostic process in this embodiment is carried out by searching (DB search 240) for similar phenomena in the diagnostic knowledge DB 250 based on the contents of a report (failure report 200) about a malfunction (fault, abnormality, etc.) that has occurred in the target device, and diagnosing the malfunction locations and phenomena described in the malfunction report by tracing back the locations and phenomena that caused the occurrence of the malfunction and obtaining a result (diagnosis result 260).

[0024] Since the trouble reports may be written in different formats and with different terminology depending on the staff member who handled the problem, it is not possible to search the diagnostic knowledge DB effectively as is. Therefore, the language processing model 220 is used to convert the trouble report into a sentence (answer sentence 221) using a predetermined format and terminology.

[0025] A prompt sentence 211 specifying the processing method, format, terminology, etc. when converting a defect report into an answer sentence is input to the language processing model, and when generating the prompt sentence (210), a defect term list 271 is generated (270) from the diagnostic knowledge DB, which lists terms related to the defect report, and is used.

[0026] The answer statement 221 is further converted by an answer statement processing unit 230 into a tabular failure characteristics table 231 suitable for searching the diagnostic knowledge database, and by using this table to search the diagnostic knowledge database, a diagnostic result 260 (such as the location and phenomenon of the failure) is obtained.

[0027] In this way, the language processing model only performs the conversion process of the defect report. The diagnosis and inference of the fault location and cause are realized by the processor searching the diagnostic knowledge DB, and the language processing model does not necessarily have to diagnose or infer the fault location and cause.

[0028] 3 is a flowchart of the diagnostic process in this embodiment. Note that each processing step in this flowchart is processed by the processor 1110 unless otherwise specified.

[0029] The operator of the document processing device inputs the contents of the defect report using the input / output device 1200 (step S301). Fig. 4A shows an example of a defect report 400, which includes a report record item 410 containing information such as a report ID, a report date, a reporter, and the product ID of the target device or equipment, and a report content body 420. The operator inputs the contents of the report content body 420. If the defect report is recorded as text data, the information may be automatically input via the UI 1140 or the NI 1130.

[0030] Next, the processor 1110 generates a defect term list based on the input defect report using the diagnostic knowledge DB 1122 shown in Fig. 1B (step S302). The defect term list is obtained by extracting, from the diagnostic knowledge DB 1122, terms that express locations and phenomena that may be related to the description of the defect report (including items that are ultimately unrelated).

[0031] 4B is an example of a defect term list, which can be generated, for example, by listing in advance all words related to defect-related locations and phenomena used in the diagnostic knowledge DB 1122 and extracting words that match or are similar (possibly related) to the descriptions in the defect report. Furthermore, when extracting similar words, a separate AI model (not shown) may be used to determine the similarity. For example, it is conceivable to determine the similarity using a word2vec model.

[0032] As described above, the defect term list is a list of words extracted from the full word list of the diagnostic knowledge DB 1122 that may be related to the content of the defect report. Narrowing down the full word list of the diagnostic knowledge DB 1122 to some extent can shorten the length of sentences input to the language processing model, thereby making processing more efficient. However, as a result of extraction, the defect term list and the full word list of the diagnostic knowledge DB 1122 may have the same content. Furthermore, if the volume of the diagnostic knowledge DB 1122 is relatively small, the list of all words in the DB may be used as the defect term list as is.

[0033] Returning to the flowchart of FIG. 3, in step S303, a prompt sentence is generated that instructs the language processing model to convert the contents of the defect report into a response sentence in a predetermined format using the terms in the defect term list.

[0034] 5 shows an example of a prompt statement 500, which includes a feature extraction directive 510 that instructs the language processing model to perform a specific process, an output format directive 520, a term list reference directive 530, the defect term list 540, and a defect report 550. That is, the feature extraction directive 510 instructs the processing procedure for the defect report 550, the output format directive 520 instructs the output format of the answer statement, and the term list reference directive 530 instructs that the defect term list 540 be referenced when creating the answer statement. Here, the output format of the answer statement instructed by the output format directive 520 may be CSV or Markdown, etc.

[0035] Next, a language processing model is executed based on the above-mentioned prompt sentence 500 (FIG. 3; step S304), and the defect report 550 is converted into a response sentence 600 as shown in FIG. 6. That is, "CSV format 1" in the output format directive 520 corresponds to "1." 610 in the response sentence 600, and "CSV format 2" corresponds to "2." 620 in the response sentence 600.

[0036] In other words, response statement 610 means "Number: 1, Location: Control board, Phenomenon: Dust accumulation," "Number: 2, Location: Control board, Phenomenon: Scratch," "Number: 3, Location: Camera unit, Phenomenon: Image recognition abnormality," and "Number: 4, Location: ADAS system, Phenomenon: Emergency shutdown processing," and response statement 620 indicates that number "3" occurred due to event numbers "1" and "2" described in response statement 610, and number "4" occurred due to number "3."

[0037] In addition, the terms (words) used in the response sentence 610 are terms from the defect term list 540 (the expression "accumulation of dust, etc." has been extracted as "accumulation of dust" to match the defect term list 540).

[0038] Next, the response statements 600 in CSV format are organized into a table format (fault characteristics table 700) as shown in Fig. 7 (Fig. 3; step S305). The fault characteristics table 700 has a location / phenomenon table 710 corresponding to the response statements 610 and a cause / result table 720 corresponding to the response statements 620, and serves as information for searching the diagnostic knowledge DB 1122.

[0039] Then, in step S306, the diagnostic knowledge DB 1122 is searched to obtain a diagnostic result from events and causal relationships related to the above-mentioned defect characteristics table 700. Fig. 8A shows an example of a processing flow for searching the diagnostic knowledge DB 1122 to obtain a diagnostic result, which will be described below.

[0040] First, referring to the defect characteristics table 700 shown in Fig. 7, each item in the location / phenomenon table 710 is regarded as a graph with a node, and a matching subgraph is searched for in the diagnostic knowledge DB 1122 (step S810). Fig. 8B is a part of the diagnostic knowledge DB 1122, and in order to explain the flow of Fig. 8A, a part (800) different from the part shown in Fig. 1B is shown, and the part surrounded by a dashed line with reference numeral "801" is the subgraph searched for in step S810.

[0041] Next, a list of nodes closest to the cause is obtained within the searched subgraph. That is, a list of nodes (leaf nodes) that do not have a link starting from that node within the subgraph is obtained (step S820). In the example of the diagnostic knowledge DB in Fig. 8B, the portion enclosed by the dashed line with reference numeral "802" corresponds to the list of nodes to be obtained.

[0042] Then, a list of nodes at the end of the "caused by" links starting from each node in the list of leaf nodes obtained is obtained as the diagnostic result (step S830). In the diagnostic knowledge DB in Fig. 8B, this corresponds to the part enclosed by the dashed line and marked "803".

[0043] The above is an example of a method for searching the diagnostic knowledge DB 1122 to obtain a diagnostic result, and the search method is not limited to this. Furthermore, if the diagnostic knowledge DB 1122 is constructed as a Bayesian network model rather than a knowledge graph, the diagnostic result can be inferred using a posterior probability inference algorithm.

[0044] 8C is an example of an output of the diagnostic results, which can be displayed on a display device or the like of the input / output device 1200. Furthermore, as described above, the diagnostic knowledge DB can be in the form of a Bayesian network that has probability information about causal relationships, and in that case, as shown in FIG. 8D, it is possible to output a certainty factor based on the probability information for each event in the diagnostic results.

[0045] As described above, according to this embodiment, by using a language processing model, it is possible to provide an accurate diagnosis even for differences and variations in the expressions and descriptions in defect reports. Furthermore, since the diagnostic process itself is not performed by a language processing model but by searching a knowledge graph, it is possible to diagnose product defects with higher accuracy even in cases where the language processing model has not learned sentences related to product defects.

[0046] In the above-described embodiment, a list of defect terms based on a diagnostic knowledge DB was used as input to the language processing model, but by providing the language processing model with "defect knowledge sentences" in the form of sentences containing information on the relationships between terms rather than a list of terms, the language processing model can generate answer sentences with greater accuracy.

[0047] Therefore, in this embodiment, a method for creating this defect knowledge sentence will be described. Note that the overall flow of the diagnostic process and other processes are the same as in the first embodiment except that a "defect knowledge sentence" is used instead of the "defect term list" (the "term list reference instruction sentence 530" in FIG. 5 refers to the defect knowledge sentence), and therefore the description will be omitted.

[0048] 9A shows the flow for generating failure knowledge sentences. First, words (feature words) that are thought to be potentially related to the parts or phenomena of the target device are extracted from the description of the failure report 1124 (step S810). Here, it is desirable to extract a wide range of feature words without omissions, so all nouns used in the failure report 1124 may be extracted, or terms used in the diagnostic knowledge DB 1122 may be separately listed, and terms identical or similar to those may be extracted from the failure report 1124. For example, it is possible to determine the similarity between terms using a word2vec model. FIG. 9B shows an example list of extracted feature words.

[0049] Next, the diagnostic knowledge DB 1122 is searched to obtain locations and phenomena that may be related to the above-mentioned characteristic words and causal relationships with the surrounding areas as a partial graph (node ​​and link information) (steps S820, S830).

[0050] Then, by applying the acquired subgraph (node ​​and link information) to a sentence template such as that shown in Figure 9C, a defect knowledge sentence such as that shown in Figure 9D can be generated (step S840). For example, the relationship between terms connected by a "caused by" link in the knowledge DB can be expressed as a sentence by applying it to the first sentence template in Figure 9C. The relationship between terms connected by a "part of" link can be expressed as a sentence by applying it to the second sentence template in Figure 9C.

[0051] As described above, according to this embodiment, the defect term list input to the language processing model is changed to a defect knowledge sentence, which is a sentence format, so that information on the relationship between terms can be input to the language processing model, and even when using a language processing model that does not provide sufficient performance by referencing the defect term list, answer sentences can be generated with high accuracy.

[0052] In the above-mentioned embodiment, the answer sentences generated by the language processing model were organized into a defect feature table, and diagnostic results were obtained by searching the diagnostic knowledge DB 1122 using the flow shown in Figure 8, etc., but in this embodiment, efficiency is improved by using the answer sentences generated by the language processing model themselves as queries to search the diagnostic knowledge DB 1122.

[0053] FIG. 10A shows the processing flow in this embodiment, and the overall flow is similar to the processing flow in the first embodiment shown in FIG. 3, but in step S1005, the diagnostic knowledge DB is searched using a search query to obtain the diagnostic results.

[0054] Therefore, the processing flow differs from that of the first embodiment shown in Fig. 3 in that a search query is output as an answer sentence by executing the language processing model in step S1004. Furthermore, since the answer sentence (search query) is generated by the language processing model, the content of the prompt sentence generated in step S1003 also differs from that of the first embodiment shown in Fig. 5.

[0055] Figure 10B shows the contents of the prompt statement in this embodiment, which differs from the prompt statement in Example 1 shown in Figure 5 in that an instruction to generate a search query as "STEP 4" is added to feature extraction directive statement 1010, and statement 1040 notifying the type of diagnostic knowledge DB 1122 to be searched is added, but the rest is the same. By providing such a prompt statement to diagnostic knowledge DB 1122, it is possible to obtain, for example, a search query written in a predetermined programming language as shown in Figure 10C.

[0056] As described above, according to this embodiment, the answer sentence itself generated by the language processing model is used as a query for searching the diagnostic knowledge DB, thereby making it possible to improve the efficiency of the entire diagnostic process.

[0057] In this embodiment, a configuration will be described in which, in the case where the expected diagnostic results are not obtained in the above-mentioned embodiment, the contents of the defect report are supplemented and the diagnostic process is performed again. Figure 11 is a flowchart of the diagnostic process in this embodiment, and steps S1100 to S1106 are the same as those in the first embodiment shown in Figure 3.

[0058] When the diagnostic result is output in step S1106, the diagnostic result is evaluated as "good" or "not good" in step S1107 (evaluation of the diagnostic result). The evaluation method can be automatic evaluation according to predetermined evaluation rules, such as evaluating the diagnostic result as "not good" if the number of candidates identified as the root cause of the malfunction is too large compared to a specified number. Furthermore, when the diagnostic knowledge DB is a Bayesian network, the diagnostic result can be output together with its certainty as shown in FIG. 8C , and the certainty may be compared with a predetermined threshold for evaluation. The operator may visually check the diagnostic result displayed on a display device or the like of the input / output device 1200 and input the evaluation result.

[0059] If the diagnostic result is determined to be "good" in step S1107, the diagnostic process ends (step S1108), but if the result is evaluated to be "not good," additional information regarding the defect (defect report) is acquired in step S1109. The acquisition of the additional information (S1109) may be performed by displaying a screen on the display device of the input / output device 1200 or the like that allows the operator to input additional defect information, and the operator may input the contents of the additional report or the like in accordance with the screen, so that the information is added to the defect report previously input in step S1101, or if the information is acquired as text-based electronic information, it may be automatically added to the previous defect report.

[0060] After the contents of the defect report are supplemented as described above, the diagnostic process is similarly executed based on the supplemented defect report from step S1102 onwards.

[0061] 12 shows an example of a screen display 1250 for inputting diagnostic results and additional information on a display device or the like of the input / output device 1200. The screen display 1250 has a failure report section 1251 for the device to be diagnosed, a diagnostic result display section 1252, an input field 1253 for additional information, and a re-diagnosis button 1254.

[0062] As an example, the diagnostic result display unit 1252 in FIG. 12 displays the potential defect causes of the diagnostic results in a knowledge graph of the diagnostic knowledge DB by enclosing them in a frame 1252A, but this is not limiting and the display may be in a tabular format as shown in FIG. 8B or FIG. 8C.

[0063] Furthermore, if the diagnostic results are automatically evaluated in step S1107, the evaluation results may also be displayed.

[0064] The operator uses the additional information input field 1253 to input the contents of the additional report, etc., and presses the re-diagnosis button 1254, which causes the re-diagnosis process from step S1102 onwards to be executed.

[0065] As described above, according to this embodiment, if the expected diagnostic results are not obtained, the contents of the defect report are supplemented and the diagnostic process is performed again, thereby further improving the accuracy of the diagnostic results.

[0066] In each of the above-described embodiments, a subgraph matching the fault characteristics is searched for in the diagnostic knowledge DB to obtain a diagnostic result. However, if a match cannot be found, the fault characteristics may be added to the diagnostic knowledge DB to expand the diagnostic knowledge DB.

[0067] Fig. 13 is a flowchart for the case where such expansion of the diagnostic knowledge DB is included, and corresponds to the search flow of Fig. 8A in Example 1. That is, steps S1310, S1330, and S1340 are the same processes as steps S810, S820, and S830 in Fig. 8A, respectively, and therefore description thereof will be omitted.

[0068] The difference from the search flow in FIG. 8A is that a step (step S1320) is provided to determine whether or not there is a matching subgraph based on the search result in step S1320. If there is no matching subgraph (NO in step S1320), the defect characteristics are added to the diagnostic knowledge DB (step S1350), and the diagnostic result is set to "not matched" or the like (step S1360).

[0069] The display device of the input / output device 1200 may display not only the diagnostic result message "Not Applicable" but also a message such as "The searched defect characteristics were not found to match anything in the diagnostic knowledge DB, so they have been added to the diagnostic knowledge DB."

[0070] Furthermore, before adding to the diagnostic knowledge DB, a confirmation screen or the like may be displayed on the display device or the like of the input / output device 1200 to ask whether or not the addition is acceptable.

[0071] As described above, according to this embodiment, if a subgraph matching a fault characteristic cannot be found in the diagnostic knowledge DB, the fault characteristic is added to the diagnostic knowledge DB, thereby enabling the diagnostic knowledge DB to be expanded.

[0072] Although each embodiment has been described above, it is possible to combine the embodiments as appropriate within the applicable range, or to replace a part of an embodiment with another embodiment or a part thereof. For example, in the second embodiment, a configuration is shown in which a defect knowledge sentence is used instead of the defect term list of the first embodiment, but in the other embodiments, it is also possible to use not only the defect term list but also the defect knowledge sentence. Furthermore, it is also possible to display a screen equivalent to the screen display 1200 shown in FIG. 12 of the fourth embodiment in the other embodiments.

[0073] 1000: Defect document processing device 1100: Processor system 1110: Processor section 1121: Program section 1121A: Diagnostic processing program 1121B: Knowledge DB expansion program 1122: Diagnostic knowledge database (DB) 1123: Language processing model 1124: Defect report storage section 1120: Memory resource section 1130: Network interface section (NI) 1140: User interface section (UI) 1200: Input / output device 1300: Network 1400: External device

Claims

1. A fault diagnosis device that diagnoses the cause of a fault from a fault report that describes a product fault, comprising: a diagnostic knowledge database that stores information regarding the product fault, an input / output unit that inputs and outputs information, and a processor unit that performs specified calculation processing, wherein the processor unit: extracts terms related to the contents of the fault report from the diagnostic knowledge database to create a fault term list, uses the fault term list to convert the contents of the fault report into a fault answer statement written in a predetermined format, and diagnoses the cause of the fault described in the fault report using the fault answer statement and the diagnostic knowledge database.

2. A fault diagnosis device according to claim 1, characterized in that said processor section converts said fault answer sentence into said fault answer sentence using a predetermined language processing model.

3. A fault diagnosis device as claimed in claim 1, characterized in that the processor unit processes using fault knowledge sentences written in a sentence format instead of the fault term list.

4. A fault diagnosis device as described in claim 3, characterized in that the processor unit extracts characteristic words related to the fault type contained in the fault report, searches for related matters of the characteristic words from the diagnostic knowledge database, and creates a sentence containing information about the product and its fault using the searched related matters, which is used as the fault knowledge sentence.

5. A fault diagnosis device as described in claim 2, wherein the language processing model is a model that outputs an answer sentence corresponding to an input prompt sentence, and the prompt sentence includes instruction sentences including: a sentence instructing a processing procedure for extracting features from the fault report; a sentence instructing an output format of the answer sentence; and a sentence instructing to refer to the fault term list when generating the answer sentence; the fault diagnosis device characterized in that it includes the fault term list and the fault report.

6. A fault diagnosis device as described in claim 5, characterized in that the processor unit: inputs the prompt sentence into the language processing model to obtain the fault answer sentence; generates search information for the diagnostic knowledge database from the fault answer sentence; and diagnoses the cause of the fault by searching the diagnostic knowledge database using the search information.

7. A fault diagnosis device according to claim 6, characterized in that the search information includes a phenomenon related to the fault, its occurrence location and its causal relationship.

8. A fault diagnosis device according to claim 1, wherein said diagnostic knowledge database is a knowledge graph representing fault-related phenomena, their occurrence locations and their causal relationships.

9. A fault diagnosis device according to claim 8, characterized in that said diagnostic knowledge database is a Bayesian network including probability information for said causal relationships.

10. A fault diagnosis device as claimed in claim 7, wherein the input / output unit displays the results of the diagnosis and is capable of accepting additional information relating to the fault in the product, adds the additional information to the fault report, and re-diagnoses the cause of the fault.

11. A fault diagnosis device as claimed in claim 6, characterized in that, when a result of searching the diagnostic knowledge database using the search information indicates that an event corresponding to the search information does not exist in the diagnostic knowledge database, the search information is added as information in the diagnostic knowledge database.

12. A method for diagnosing the cause of a product defect from a defect report that describes the defect, comprising the steps of: extracting terms related to the contents of the defect report from a diagnostic knowledge database that stores information about the product defect, and creating a defect term list; converting the contents of the defect report into a defect answer statement written in a predetermined format using the defect term list; and diagnosing the cause of the defect described in the defect report using the defect answer statement and the diagnostic knowledge database.

13. A program for causing a computer to function as the fault diagnosis device according to claim 1.

Images