Failure diagnosis device, failure diagnosis method, and program therefor

Abstract

To overcome the problem of failure reports in general that, since text expression (notation variability, difference in language, level of detailed explanation) varies according to a person in charge of maintenance who creates the report, processing using text processing based on predetermined rules, and a word dictionary is not necessarily easy.SOLUTION: A failure diagnosis device for diagnosing a factor of failure from a failure report describing the failure of a product includes: a diagnosis knowledge database which stores information related to failure of a product; an input / output part for inputting / outputting information; and a processor part for performing prescribed arithmetic processing. The processor part creates a failure term list by extracting terms related to a description content of the failure report from the diagnosis knowledge database, converts a description content of the failure report to failure reply sentences written in a predetermined format by using the failure term list, and diagnoses a factor of the failure described in the failure report by using the failure reply sentences and the diagnosis knowledge database.SELECTED DRAWING: Figure 1A

Description

[Technical field]

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

[0002] When any malfunction occurs in industrial products or general-purpose products and equipment, a report on the malfunction (malfunction report) is prepared by the maintenance staff or call center operator in charge, and the malfunction location and root cause are investigated based on the malfunction report. It is expected that the efficiency and accuracy of maintenance will be improved by processing this malfunction report using AI technology.

[0003] However, in general, defect reports have differences and variations in the expressions and descriptions used depending on the maintenance staff who creates them, so it is not necessarily easy to process the text based on predetermined rules or using a word dictionary.

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

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

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

[0007] [Patent Document 1] JP 2017-194727 A Summary of the Invention [Problem to be solved by the invention]

[0008] In Patent Document 1, text processing is performed based on co-occurrence relationships, but as mentioned above, the wording of defect reports may differ depending on who writes them, even if the same event occurs, so the desired results may not be obtained depending on the target product.

[0009] Therefore, it is possible to automate the diagnosis process from defect reports by 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 does not necessarily have knowledge of industrial product part names or phenomena, and the accuracy of responses regarding industrial product defects may be low. [Means for solving the problem]

[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 regarding product faults, an input / output unit that inputs and outputs information, and a processor unit that performs specified 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 sentence written in a predetermined format using the fault answer sentence and the diagnostic knowledge database, and diagnose the cause of the fault described in the fault report. Effect of the Invention

[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. [Brief description of the drawings]

[0012] [Figure 1A] FIG. 2 is a diagram showing the configuration of a defect document processing device according to the present embodiment. [Figure 1B] 3 is an example of a diagnostic knowledge DB in the present embodiment. [Diagram 2] FIG. 2 is a diagram showing an overview of a diagnostic process in the present embodiment. [Diagram 3] 4 is a flowchart of a diagnostic process in the present embodiment. [Figure 4A] 4 is an example of a defect report in the present embodiment. [Figure 4B] 4 is an example of a defect term list in the present embodiment. [Diagram 5] 4 is an example of a prompt sentence in this embodiment. [Figure 6] 11 is an example of a reply sentence in the present embodiment. [Figure 7] 4 is an example of a defect characteristics table in the present embodiment. [Figure 8A] 10 is a flowchart for obtaining a diagnosis result by searching a diagnostic knowledge DB in the present embodiment. [Figure 8B]13 is a diagram illustrating an example of a search in a diagnostic knowledge DB according to the present embodiment. [Figure 8C] 13 is an example of an output of a diagnosis result in the present embodiment. [Figure 8D] 13 is an example of an output of a diagnosis result in the present embodiment. [Figure 9A] 13 is a flow chart showing a generation flow of a defect knowledge statement in the present embodiment. [Figure 9B] 4 is an example of a feature word list in the present embodiment. [Figure 9C] 4 is an example of a sentence template in the present embodiment. [Figure 9D] 13 is an example of a defect knowledge sentence in the present embodiment. [Figure 10A] 4 is a flowchart of a diagnostic process in the present embodiment. [Figure 10B] 4 is an example of a prompt sentence in this embodiment. [Figure 10C] 4 is an example of a search query in the present embodiment. [Figure 11] 4 is a flowchart of a diagnostic process in the present embodiment. [Figure 12] 4 is an example of a screen display in the present embodiment. [Figure 13] 10 is a flowchart showing a process for expanding a diagnostic knowledge DB in the present embodiment. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0013] Hereinafter, the embodiments of the present invention will be described in detail with reference to the drawings as appropriate. For convenience of explanation, different reference numerals may be given to the same components in some drawings, but if the names of the components are basically the same, they are the same. EXAMPLES

[0014] 1A is a configuration diagram of a defect document processing device 1000 in this embodiment. The defect document processing device 1000 has a processor system 1100 realized by a personal computer, a general-purpose computer, etc., and an input / output device 1200 realized by a display device, a keyboard, etc. Also, if necessary, an external device 1400 connected via a network 1300 is included to configure the defect document processing system.

[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 a 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 later are stored, a diagnostic knowledge database (DB) 1122 in which information regarding malfunctions of the target device is stored, a language processing model 1123, and a malfunction report memory unit 1124 in which the contents of a malfunction report described later are stored, and the processor unit 1110 performs predetermined processing using these programs 1121, knowledge DB 1122, language processing model 1123, malfunction report memory 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). In recent years, ChatGPT (Chat Generative Pre-Trained Transformer) and FLAN (Finetuned LAnguage Net) have become well known, but it is not limited to these, and any language processing model that uses a prompt as input will suffice, and it 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 to obtain the necessary processing results.

[0019] Figure 1B is an example of a diagnostic knowledge DB, and in this example, an automobile is assumed as the target device, and a portion of the entire diagnostic knowledge DB is shown. 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 expresses the malfunction locations and the parts and units (parts) that compose them, and also expresses the phenomena that may occur in each of these parts (failures and conditions that may be their causes) as the reasons and results of phenomena that may occur in other hierarchical parts.

[0020] 1B, for the defective part, the multiple nodes (parts) at the start points of the arrows constitute the parts of the nodes at the same end points of the arrows, and each arrow may be referred to as a "part of link" in this embodiment. Also, for the phenomenon, the phenomenon that causes the node (phenomenon) at the start point of the arrow is the phenomenon at the node at the end of the 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, for example, probability information.

[0022] Next, the diagnostic process in the document processing device 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 phenomena similar to a report (fault report 200) about a fault (breakdown, abnormality, etc.) that has occurred in a target device, and diagnosing the fault locations and phenomena described in the fault report by tracing back the locations and phenomena that caused the faults and obtaining a result (diagnosis result 260).

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

[0025] A prompt sentence 211 that specifies the processing method, format, and terminology for 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 that lists terms related to the defect report from the diagnostic knowledge DB is generated (270) and used.

[0026] The answer sentence 221 is further converted by an answer sentence processing 230 into a fault feature table 231 in a table format suitable for searching the diagnostic knowledge DB, and by searching the diagnostic knowledge DB using this, a diagnosis result 260 (cause and phenomenon of the fault, etc.) is obtained.

[0027] In this way, the language processing model only performs the conversion process of the defect report. Diagnosis and inference of the fault location and cause are realized by the processor searching the diagnostic knowledge DB, so the language processing model does not 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 has report record items 410 including the report ID, report date, reporter, product ID of the target device / equipment, etc., and report content body 420. The operator inputs the description of report content body 420. If the defect report is recorded as text data, it may be automatically input via UI 1140 or 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 expressing 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 making a list in advance of all words related to the parts and phenomena of defects used in the diagnostic knowledge DB 1122, and extracting words that match or are similar (possibly related) to the descriptions in the defect report. In addition, when extracting similar words, a separate AI model (not shown) may be used to determine the similarity. For example, it is possible to determine the similarity using a word2vec model.

[0032] As described above, the defect term list is a list of words that may be related to the contents of a defect report extracted from the full word list of the diagnostic knowledge DB1122, and by narrowing down the full word list of the diagnostic knowledge DB1122 to some extent, the length of the sentences input to the language processing model can be shortened and the processing can be made more efficient. However, as a result of the extraction, the defect term list and the full word list of the diagnostic knowledge DB1122 may have the same contents. Also, if the volume of the diagnostic knowledge DB1122 is relatively small, the list of all words in the DB may be used as the defect term list as it 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 sentence 500, which consists of a feature extraction directive 510 that instructs the language processing model to carry out a specific process, an output format directive 520, a term list reference directive 530, the above-mentioned 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 sentence, and the term list reference directive 530 instructs that the defect term list 540 should be referenced when creating the answer sentence. Here, the output format of the answer sentence 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 an answer sentence 600 as shown in FIG. 6. That is, "CSV format 1" in the output format instruction sentence 520 corresponds to "1." 610 in the answer sentence 600, and "CSV format 2" corresponds to "2." 620 in the answer sentence 600.

[0036] In other words, answer 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 stop processing", and answer statement 620 indicates that number "3" occurred due to event numbers "1" and "2" listed in answer statement 610, and number "4" occurred due to number "3".

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

[0038] Next, the answer sentence 600 in CSV format is organized in 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 answer sentence 610 and a cause / result table 720 corresponding to the answer sentence 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 feature table 700 shown in Fig. 7, each item of 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 shows a part (800) different from the part shown in Fig. 1B in order to explain the flow of Fig. 8A, but the part surrounded by a dashed line with the reference numeral "801" is the subgraph searched for in step S810.

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

[0042] Then, a list of nodes that are the terminals of the caused by links starting from each node in the list of acquired leaf nodes is acquired as a diagnostic result (step S830). In the diagnostic knowledge DB in FIG. 8B, this corresponds to the part surrounded by a dashed line with reference numeral "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. In addition, if the diagnostic knowledge DB 1122 is constructed as a Bayesian network model rather than a knowledge graph, the diagnostic result can be inferred by a posteriori probability inference algorithm.

[0044] Fig. 8C is an example of the output of the diagnosis result, 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 having probability information about causal relationships, and in that case, as shown in Fig. 8D, the confidence level based on the probability information can also be output for each event in the diagnosis result.

[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 expressions and descriptions in defect reports. In addition, since the diagnosis process itself is not performed by the language processing model but by searching a knowledge graph, it is possible to diagnose product defects with high accuracy even in cases where the language processing model has not learned sentences related to product defects. EXAMPLES

[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. However, by providing the language processing model with a "defect knowledge sentence" in the form of a sentence containing information on the relationship 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 the defect knowledge sentence will be described. Note that the entire 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 in the first embodiment (the term list reference instruction sentence 530 in FIG. 5 refers to the defect knowledge sentence), and therefore the description will be omitted.

[0048] FIG. 9A shows a flow of generating a failure knowledge sentence. First, words (characteristic words) that are thought to be related to the parts or phenomena of the target device are extracted from the description of the failure report 1124 (step S810). Here, since it is desirable to extract characteristic words widely without omission, 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 characteristic 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 surroundings as a partial graph (node ​​and link information) (steps S820, S830).

[0050] Then, by applying the acquired partial graph (node-link information) to a sentence template as shown in Fig. 9C, a defect knowledge sentence as shown in Fig. 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 Fig. 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 Fig. 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. Therefore, even when a language processing model is used that does not provide sufficient performance by referring to the defect term list, an answer sentence can be generated with high accuracy. EXAMPLES

[0052] In the above-mentioned embodiment, the answer sentences generated by the language processing model were organized into a fault feature table, and diagnostic results were obtained by searching the diagnostic knowledge DB1122 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 for searching the diagnostic knowledge DB1122.

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

[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. In addition, since an answer sentence (search query) is generated by the language processing model, the content of the prompt sentence generated in step S1003 is also different from that of the first embodiment shown in Fig. 5.

[0055] Fig. 10B shows the contents of the prompt sentence in this embodiment, and the difference from the prompt sentence in embodiment 1 shown in Fig. 5 is that an instruction to generate a search query as "STEP 4" is added to the feature extraction directive sentence 1010, and that a sentence 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 sentence to the diagnostic knowledge DB 1122, for example, a search query written in a predetermined programming language as shown in Fig. 10C can be obtained.

[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. EXAMPLES

[0057] In this embodiment, a configuration is described in which, when the expected diagnostic result is not obtained in the above-mentioned embodiment, the contents of the defect report are supplemented and the diagnostic process is performed again. Fig. 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 Fig. 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 diagnostic result). The evaluation method can be automatic evaluation according to a predetermined evaluation rule, such as evaluating the result as "not good" when the number of candidates determined to be the root cause of the defect is too large compared to a specified number. In addition, when the diagnostic knowledge DB is a Bayesian network, the diagnostic result can be output together with its confidence level as shown in FIG. 8C, so that the confidence level may be compared with a predetermined threshold value 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 diagnosis result is judged to be "good" in step S1107, the diagnosis process ends (step S1108), but if it is evaluated to be "not good", additional information on 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, in step S1102 and thereafter, the diagnostic process is similarly executed based on the supplemented defect report.

[0061] 12 is 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 malfunction 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 candidate malfunction causes of the diagnostic result in a knowledge graph of the diagnostic knowledge DB surrounded by a frame 1252A, but is not limited to this and may display them in a table format as in FIG. 8B or FIG. 8C.

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

[0064] Using an additional information input field 1253, the operator inputs the contents of an additional report, etc., and when the operator presses a rediagnosis button 1254, the rediagnosis process from step S1102 onwards is executed.

[0065] As described above, according to this embodiment, when 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. EXAMPLES

[0066] In each of the above-mentioned embodiments, in order to obtain a diagnosis result, a subgraph matching the fault characteristic is searched for in the diagnostic knowledge DB. If a match cannot be found, the fault characteristic may be added to the diagnostic knowledge DB to expand the diagnostic knowledge DB.

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

[0068] The difference from the search flow in FIG. 8A is that a step (step S1320) is added to determine whether or not there is a matching subgraph based on the result of the search in step S1320. If there is no matching subgraph (NO in step S1320), the fault characteristics are added to the diagnostic knowledge DB (step S1350), and the diagnosis 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 found" but also a message such as "The fault characteristics you searched for were not found 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 of the input / output device 1200 to ask whether or not to add the diagnostic knowledge DB.

[0071] As described above, according to this embodiment, if a subgraph matching a malfunction characteristic cannot be found in the diagnostic knowledge DB, the malfunction 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, each embodiment can be appropriately combined within an applicable range, or a part of an embodiment can be replaced with another embodiment or a part of it. For example, in the second embodiment, the configuration is shown in which the 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. Also, it is possible to display a screen equivalent to the screen display 1200 shown in FIG. 12 of the fourth embodiment in the other embodiments. [Explanation of symbols]

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

Claims

1. A fault diagnosis device for diagnosing a cause of a fault in a product from a fault report that describes the fault, comprising: The diagnostic knowledge database stores information about defects in the product, an input / output unit inputs and outputs information, and a processor unit performs a predetermined calculation process. The processor unit includes: extracting terms related to the contents of the defect report from the diagnostic knowledge database to create a defect term list; converting the content of the defect report into a defect answer written in a predetermined format using the defect term list; diagnosing the cause of the defect described in the defect report using the defect response text and the diagnostic knowledge database; A fault diagnosis device comprising:

2. The fault diagnosis device according to claim 1, The fault diagnosis device, wherein the processor performs conversion into the fault answer sentence using a predetermined language processing model.

3. The fault diagnosis device according to claim 1, The processor unit includes: A fault diagnosis device characterized in that, instead of the fault term list, a fault knowledge sentence written in a sentence format is used for processing.

4. The fault diagnosis device according to claim 3, The processor unit includes: extracting characteristic words related to a defect type included in the defect report; Searching for related items of the characteristic words from the diagnostic knowledge database; Using the searched related items, a text describing information about the product and its defects is created and used as the defect knowledge text. A fault diagnosis device comprising:

5. The fault diagnosis device according to claim 2, the language processing model is a model for outputting a response sentence corresponding to an input prompt sentence, The prompt sentence is: A text instructing a procedure for extracting features from the defect report; A sentence instructing an output format of the answer sentence; A sentence instructing to refer to the defect term list when generating the answer sentence; An instruction sentence including: A fault diagnosis device comprising the fault term list and the fault report.

6. The fault diagnosis device according to claim 5, The processor unit includes: inputting the prompt sentence into the language processing model to obtain the problem answer sentence; generating search information for the diagnostic knowledge database from the defect response text; diagnosing a cause of the malfunction by searching the diagnostic knowledge database using the search information; A fault diagnosis device comprising:

7. The fault diagnosis device according to claim 6, The fault diagnosis device is characterized in that the search information includes a phenomenon related to the fault, a location of the fault, and a causal relationship thereof.

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

9. The fault diagnosis device according to claim 8, A fault diagnosis device, wherein the diagnostic knowledge database is a Bayesian network including probability information for the causal relationships.

10. The fault diagnosis device according to claim 7, the input / output unit displays the results of the diagnosis and is capable of receiving additional information regarding a defect in the product; The fault diagnosis device further comprises adding the additional information to the fault report and re-diagnosing the cause of the fault.

11. The fault diagnosis device according to claim 6, and when, as a result of searching the diagnostic knowledge database using the search information, an event corresponding to the search information is not present in the diagnostic knowledge database, the search information is added as information in the diagnostic knowledge database.

12. A method for diagnosing a cause of a product defect from a defect report that describes the defect, comprising the steps of: A step of extracting terms related to the contents of the defect report from a diagnostic knowledge database storing information on defects of the product, and creating a defect term list; converting the content of the defect report into a defect answer sentence written in a predetermined format using the defect term list; a step of diagnosing a cause of the malfunction described in the malfunction report by using the malfunction response text and the diagnostic knowledge database; A fault diagnosis method comprising:

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

Images