Defect document processing device and defect document processing method

Abstract

To extract defect information from a defect report sentence including fluctuation of an expression by an unified expression, and create a defect knowledge database used for a defect factor diagnosis.SOLUTION: A defect document processing method includes steps of: extracting a relation between a component of a target product or a term related to a defect thereof from a defect report statement and a unique expression from the defect report statement based on a defect knowledge database storing information on a defect and a hardware knowledge database storing names of parts of the product, synonyms thereof, and design information; generating first graph data from a result of a unique expression extraction process and a relation extraction process; comparing the unique expression of the first graph data with the hardware knowledge database; after name identification is performed to generate second graph data in which elements of the synonymous expression are corrected, generating third graph data by combining the second graph data with the unique expression of the defect knowledge database; comparing the graph data with the defect knowledge database; and updating the defect knowledge database.SELECTED DRAWING: Figure 3

Description

[Technical Field]

[0001] The present invention relates to a defect document processing device and a defect document processing method that extracts the causes of product defects from defect reports that describe the defects and builds a defect knowledge database. [Background technology]

[0002] When a malfunction occurs in an industrial product or a consumer product or device, the maintenance staff who responded to the malfunction often prepares a report (defect report) on the details of the response, and the location of the malfunction and its root cause are often dug up based on the defect report. This report from the maintenance staff contains various information related to the operational status of the product or device and the cause of the malfunction. By utilizing this information in malfunction response and next-generation design, product reliability can be further improved. Furthermore, by extracting and systematizing information on the product's condition during operation and related components from the maintenance staff report, it is expected that feedback can be provided to next-generation design and maintenance can be made more efficient and sophisticated.

[0003] However, defect reports vary in expression (variations in spelling, language differences, level of detail) depending on the maintenance personnel, making them difficult to process using a uniform rule base or word dictionary. In response to this, language processing models that can solve a variety of tasks by changing the input instructions, such as LLM (Large Language Models), a type of generative AI, are attracting attention. LLMs have high processing performance for differences in expression due to learning from large-scale data and multiple tasks, and are being used to extract information from industrial product defect reports that eliminates ambiguity in spelling.

[0004] Previously, an invention described in Patent Document 1 (JP 2023-32128 A) eliminated ambiguity in information extracted from maintenance documents through name matching and constructed fault knowledge. Patent Document 2 (JP 2019-79216 A (Patent No. 7021499)) also described an invention that integrated information extracted from multiple information sources with information in a database and performed machine learning based on the content to obtain inference results. [Prior art documents] [Patent documents]

[0005] [Patent Document 1] Japanese Patent Application Publication No. 2023-32128 [Patent Document 2] Japanese Patent Application Publication No. 2019-79216 Summary of the Invention [Problem to be solved by the invention]

[0006] In Patent Document 1, the name matching process is performed based on the co-occurrence relationship between combinations of failure expressions and treatment expressions, but when extracting more complex defect occurrence mechanisms with more components, the number of combinations becomes enormous. Furthermore, as mentioned above, defect reports may be expressed differently depending on the writer, even if the same event is described in detail, so desired results may not be obtained depending on the target product.

[0007] Furthermore, in Patent Document 2, a process is performed in which information from multiple information sources is directly integrated with information on a database, but in order to integrate information obtained from defect reports, it may be necessary to resolve the problem of variations in the notation of the same phenomenon mentioned above.

[0008] Therefore, it is possible to use a language processing model trained on large amounts of data to extract information from defect reports and build knowledge, but the language processing model may not have learned knowledge about the names of industrial product parts and phenomena, which could result in low accuracy in responses regarding industrial product defects.

[0009] The present invention has been made in consideration of the above points, and aims to extract defect information in a unified manner from defect report sentences that contain variations in expression, and to create a defect knowledge database that can be used to diagnose the cause of the defect. [Means for solving the problem]

[0010] In order to solve the above-mentioned problems, the present invention provides a defect document processing device that extracts causes of defects from defect reports describing product defects and builds a defect knowledge database, the device comprising: a defect knowledge database storing information about defects; a hardware knowledge database storing names of product parts, their synonyms, and design information; an input / output unit that inputs and outputs information; and a processor unit that performs predetermined arithmetic processing, the processor unit including: a named entity extraction process that extracts terms related to components of a target product and defects in the target product from defect report sentences based on the defect report; a relationship extraction process that extracts relationships between named entities from the defect report sentences; a named entity / relationship integration process that generates first graph data from the results of the named entity extraction process and the relationship extraction process; a name matching process that compares the named entities in the first graph data with the hardware knowledge database and generates second graph data by correcting elements of synonyms; a graph integration process that links the second graph data with the named entities in the defect knowledge database to generate third graph data; and a defect knowledge database update process that compares the third graph data with the defect knowledge database and updates the defect knowledge database. The present invention is characterized by carrying out the following. [Effects of the Invention]

[0011] The defect knowledge database is updated using information extracted from defect reports without mistaking the same event for a different event. Problems, configurations, and effects other than those described above will become apparent from the following description of the preferred embodiment of the invention. [Brief explanation of the drawings]

[0012] [Figure 1A] 1 is a diagram illustrating a configuration of a defect document processing device according to an embodiment of the present invention. [Figure 1B] 2 is an example of a defect knowledge database (DB) in the present embodiment. [Figure 1C] 2 is an example of a hardware (HW) knowledge DB in this embodiment. [Figure 1D] 2 is an example of a HW knowledge DB in the present embodiment. [Figure 2] FIG. 2 is a diagram illustrating the flow of document processing in this embodiment. [Figure 3] 10 is a flowchart of document processing in this embodiment. [Figure 4A] 10 is an example of a defect report in the present embodiment. [Figure 4B] 10 is an example of a defect report in this embodiment. [Figure 4C] 10 is an example of a named entity extracted sentence in this embodiment. [Figure 4D] 10 is an example of a named entity list in the present embodiment. [Figure 4E] 10 is an example of a relational current extraction sentence in this embodiment. [Figure 4F] 10 is an example of a relationship list in this embodiment. [Figure 4G] 10 is an example of graph data in this embodiment. [Figure 4H] 10 is an example of a name identification processing statement in this embodiment. [Figure 4I] 10 is an example of table data in this embodiment. [Figure 4J] 10 is an example of corrected graph data in this embodiment. [Figure 4K] 10 is an example of subgraph data in this embodiment. [Figure 4L] 10 is an example of integrated graph data in this embodiment. [Figure 4M] 10 is an example of an updated defect knowledge DB in this embodiment. [Figure 5] FIG. 10 is a diagram illustrating the flow of another example of document processing in the present embodiment. [Figure 6A]10 is an example of a relationship list in this embodiment. [Figure 6B] 10 is an example of graph data in this embodiment. [Figure 6C] 2 is an example of a HW knowledge DB in the present embodiment. [Figure 6D] This is an example in which an explanatory text is added to the defect report text in this embodiment. [Figure 6E] 3 is an example of dictionary data in the present embodiment. [Figure 6F] 10 is an example of graph data in this embodiment. [Figure 7] 10 is another example of a flowchart of document processing in the present embodiment. [Figure 8] 10 is an example of a correction processing statement in this embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0013] Hereinafter, embodiments of the present invention will be described with reference to the drawings. The examples are illustrative of the present invention, and for clarity of explanation, appropriate omissions and simplifications have been made. The present invention can be implemented in various other forms. Unless otherwise specified, each component may be singular or plural.

[0014] In order to facilitate understanding of the invention, the position, size, shape, range, etc. of each component shown in the drawings may not represent the actual position, size, shape, range, etc. Therefore, the present invention is not necessarily limited to the position, size, shape, range, etc. disclosed in the drawings.

[0015] Although various types of information may be described using expressions such as "table" and "list" as examples, the various types of information may also be expressed using data structures other than these. For example, various types of information such as "XX table" and "XX list" may also be expressed as "XX information." When describing identification information, expressions such as "identification information," "identifier," "name," "ID," and "number" are used, but these are interchangeable.

[0016] When there are multiple components with the same or similar functions, they may be described using the same reference numeral with different subscripts. When there is no need to distinguish between these multiple components, the subscripts may be omitted.

[0017] For convenience of explanation, the same components may be denoted by different reference numerals in different drawings.

[0018] In the embodiments, processing performed by executing a program may be described. Here, a computer executes the program using a processor (e.g., a CPU or a GPU) and performs processing defined by the program using storage resources (e.g., a memory) and interface devices (e.g., a communication port). Therefore, the entity performing the processing by executing the program may be the processor. Similarly, the entity performing the processing by executing the program may be a controller, device, system, computer, or node having a processor. The entity performing the processing by executing the program may be any computing unit, and may include a dedicated circuit that performs specific processing. Here, the dedicated circuit may be, for example, an FPGA (Field Programmable Gate Array), an ASIC (Application Specific Integrated Circuit), or a CPLD (Complex Programmable Logic Device).

[0019] A program may be installed on a computer from a program source. The program source may be, for example, a program distribution server or a computer-readable storage medium. When the program source is a program distribution server, the program distribution server may include a processor and a storage resource for storing the program to be distributed, and the processor of the program distribution server may distribute the program to be distributed to other computers. In addition, in an embodiment, two or more programs may be realized as one program, or one program may be realized as two or more programs. [Example]

[0020] 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. Furthermore, if necessary, an external device 1400 connected via a network 1300 also constitutes the defect document processing system.

[0021] The processor system 1100 has a processor 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.

[0022] The memory resource unit 1120 also has a program unit 1121 that stores programs (a fault knowledge database (DB) update processing program 1121A, a fault diagnosis processing program 1121B) that perform various processing described below, a hardware (HW) knowledge database (DB) 1122 that compiles the components of the system that are the target of fault diagnosis, the names of the faults, and their synonymous expressions, a language processing model 1123, a fault knowledge DB 1124 that stores the relationships between nodes that represent information such as components and statuses related to faults in the target product or device, and a fault report storage unit 1125 that stores the contents of fault reports, and the processor 1110 performs predetermined processing using these programs 1121, HW knowledge DB 1122, language processing model 1123, fault knowledge DB 1124, fault report storage unit 1125, etc.

[0023] 1B, the malfunction knowledge DB 1124 stores the relationships between nodes that represent information such as the location, component, and status of malfunctions in the target product or device, and is a knowledge graph that hierarchically expresses the inclusion relationship between the malfunction location and the units that make it up, and also expresses the possible phenomena (failures and conditions that could be their causes) that can occur in each of those parts as the reasons and results of phenomena that can occur in other locations. In this example, a diesel generator is assumed as the target device, and the same applies to the other DBs and examples described below.

[0024] In the knowledge graph of this embodiment, an arrow indicating the location of occurrence of a phenomenon with its starting point being the occurrence location and its ending point being the phenomenon is called an "is edge." Also, an arrow indicating a causal relationship with respect to a phenomenon with its starting point being the cause and its ending point being the result is called a "cause edge." Furthermore, an arrow indicating an inclusion relationship with respect to a defective part with its starting point being a component is called a "part_of edge."

[0025] Furthermore, the causal relationships represented by the cause edges may be provided with coefficient information, and the coefficient information may be saved in a Bayesian network format that includes probability information such as conditional probability.

[0026] The HW knowledge DB 1122 is a database that compiles design information such as the components of the system that are the subject of fault diagnosis, the names of the faults, and their synonymous expressions. It is created based on the system design documents and the knowledge of experts, and the synonymous expressions are updated based on the updates made to the fault knowledge DB 1124.

[0027] The HW knowledge DB 1122 has a DB section 1122A relating to hardware parts and configuration information as shown in FIG. 1C, and a DB section 1122B relating to hardware malfunction terms as shown in FIG. 1D, each of which represents a portion of the entire HW knowledge DB 1122.

[0028] In Figure 1C, the elements include "ID" which stores a unique identification number, "Entity" which stores the representative name of the HW component, "Parent" which stores the ID of the higher-level component as an inclusion relationship, "Fault Mode" which stores the ID of possible elements in the HW knowledge DB 1122 related to fault terms, which will be described later, and "Synonym" which stores a list of synonyms that indicate the name of the component.

[0029] Also, in Figure 1D, the elements include "ID" which stores a unique identification number, "Entity" which stores the name of the defect or state, "Related Component" which stores the ID of the component in which the defect or state may occur, and "Synonym" which stores a list of synonyms that indicate the name of the defect.

[0030] Note that the components of the HW knowledge DB 1122 may be stored in the fault knowledge DB 1124, so that the functions of the HW knowledge DB 1122 are replaced by the fault knowledge DB 1124. That is, this can be realized by having the elements of the "Entity" table correspond to the names of the nodes in the fault knowledge DB, the elements of the "Parent" table correspond to the part_of edges, the elements of the "Fault Mode" table and "Related Component" correspond to the "is" edges, and the elements of the "Synonym" table be held as additional information for each node.

[0031] 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), which is a type of generative AI. In this embodiment, the language processing model 1123 reads prompts generated by named entity extraction processing, relationship extraction processing, name matching processing, and graph integration processing, and executes each natural language processing task.

[0032] Typical models include ChatGPT (Chat Generative Pre-Trained Transformer) and FLAN (Finetuned LAnguage Net), but are not limited to these. Any language processing model that generates text in response to a directive sentence will suffice, and the present invention is not limited to a specific language processing model. Furthermore, in the present embodiment and drawings, such language processing models may be collectively referred to as "LLM," but this does not mean that the present invention is limited to a specific language processing model.

[0033] The HW knowledge DB 1122, language processing model 1123, defect knowledge DB 1124, and defect report memory unit 1125 may be located in an external device 1400, etc. In this case, the processor unit 1110 can access the external device via an API or the like via the NI (1130) and the network 1300 to obtain the required processing results.

[0034] Next, the defect document processing in this embodiment will be described. Fig. 2 is a diagram for explaining the flow of defect document processing, and Fig. 3 is a flowchart thereof. Below, each step of the flowchart in Fig. 3 will be described in order, also with reference to Fig. 2. Note that each step of this flowchart is executed by the processor 1110 in Fig. 1.

[0035] (Step S2110): Defect report document input process 2110 generates defect report text 2011 by extracting portions containing descriptions of defects from input data, namely, defect report 2010. Examples of defect report 2010 and defect report text 2011 are shown in FIG. 4A and FIG. 4B.

[0036] (Step S2120): The named entity extraction process 2120 generates prompt 1 (2121) that instructs the LLM 1123 to extract named entities, such as components of the target product or system and expressions related to their defects, from the defect report text and output them as named entity list 2122 in list format with named entity name and classification as items. Figure 4C shows an example of prompt 1 (2121). Figure 4D shows an example of named entity list 2122 output by the LLM 1123 based on prompt 1 (2121).

[0037] (Step S2130): The relationship extraction process 2130 extracts relationships such as inclusion relationships and causal relationships between the named entity list (2122) obtained by the named entity extraction process, and generates prompt 2 (2131) that instructs the LLM 1123 to output a relationship list 2132 in list format with related named entities and classifications as items. Figure 4E shows prompt 2 (2131). Figure 4F shows an example of the relationship list 2132 output by the LLM 1123 based on prompt 2 (2131).

[0038] (Step S2140): The named entity / relationship integration process 2140 generates graph-format data (graph data 2141) from the named entity list 2122 and the relationship list 2132 output from the LLM 1123, with elements on the named entity list 2122 as nodes and elements on the relationship list 2132 as edges. An example of the graph data 2141 is shown in FIG. 4G.

[0039] (Step S2150): The name identification process 2150 generates prompt 3 (2151) that instructs the LLM 1123 to perform a process of obtaining table data 1 (2152) in which elements of synonymous expressions are associated by collating with the HW knowledge DB 1122 to obtain graph data 2154 in which elements of synonymous expressions are corrected for graph data 2141 generated by the named entity / relationship integration process. Then, in the graph representation conversion process (2153), corrected graph data (2154) is output based on table data 1 (2152) and graph data 2141 output from the LLM 1123.

[0040] Figure 4H shows an example of prompt 2151, and Figure 4I shows an example of table data 2152. Figure 4J shows an example of corrected graph data 2154. It can be seen that the element "diesel engine" in the graph data 2141 before correction has been replaced with "diesel engine" in the corrected (name-matched) graph data (2154).

[0041] (Step S2160): The graph integration process 2160 links the graph data (2154) obtained by the name identification process (S2150) with the named entity of the subgraph 1124A extracted from the defect knowledge DB 1124, and generates integrated graph data 2162.

[0042] Returning to FIG. 2, the graph integration process 2160 searches (2161) the malfunction knowledge DB 1124 shown in FIG. 1B and extracts parts that include components ("diesel engine" and "electric pump" in FIG. 4J) included in the merged graph data 2154. Then, components connected to the components (named entities) via "part_of edges" and parts of components connected to the components via "part_of edges" are extracted as subgraph 1124A. An example of the subgraph 1124A extracted in this example is shown in FIG. 4K.

[0043] Then, the merged graph data 2154 (FIG. 4J) and the subgraph 1124A (FIG. 4K) are integrated based on the common component "diesel engine" in both, and integrated graph data 2162 as shown in FIG. 4L is obtained.

[0044] (Step S2170): The defect knowledge DB update process 2170 compares the graph data 2162 obtained by the graph integration process with the defect knowledge DB 1124, and if there is a difference, issues an update instruction to the defect knowledge DB 1124. A query to update the defect knowledge DB 1124 may be generated and executed.

[0045] For example, in the graph data 2162 of Figure 4L, the part surrounded by dashed line 2162A does not exist in the defect knowledge DB 1124 of Figure 1B, so this part (2162A) is added to the defect knowledge DB 1124 of Figure 4J, and the updated defect knowledge DB 1124A shown in Figure 4M (the part surrounded by dashed line is the updated part) is obtained.

[0046] By processing each of the above steps, the update process 2100 of the defect knowledge DB 1124 is completed, and the defect diagnosis process 2200 can diagnose the cause of the defect by tracing the location of the defect and identifying its cause based on defect information such as defect reports and the defect knowledge DB 1124 using the defect diagnosis program 1121B.

[0047] Although the present embodiment has been described with respect to a configuration in which the malfunction knowledge DB 1124 is updated based on the name matching process, etc., it is also possible to perform an update process for the HW knowledge DB 1122, such as changing a term defined in a synonym (Synonym column) of the HW knowledge DB 1122 to a representative name (Entity), depending on the status of multiple name matching processes, etc. Also, instead of a malfunction report, the hardware configuration information in the malfunction knowledge DB 1124 may be updated by analyzing design-related information on a device or system using a method similar to the above-mentioned process.

[0048] As described above, according to this embodiment, it is possible to construct a database that can appropriately diagnose defect reports that contain variations in the descriptions and expressions of the same phenomenon. [Example]

[0049] In the above-described embodiment, a model that generates text in response to an input instruction sentence was used as the language processing model, but it is conceivable that this may not be easy to implement in an environment with limited computing resources or in an environment where the range of data available is limited.

[0050] Therefore, in this embodiment, an example will be described in which an LLM with an encoder configuration that obtains a high-dimensional vector representation (embedded representation) for input text is used, which is a language processing model with a relatively light processing load as an LLM.

[0051] In other words, the language processing model in this embodiment is a model that outputs a multidimensional numerical array for input text, the named entity extraction process labels words in a sentence based on the numerical array output and outputs the result as a named entity list, the relationship extraction process outputs a relationship list based on the numerical array output and the named entity list, the name matching process performs a process of matching named entities included in the named entity list with terms in the HW knowledge database by a similarity calculation process using the numerical array output, and the graph integration process performs a process of matching named entities included in the named entity list with terms in the defect knowledge DB by a similarity calculation process using the numerical array output.

[0052] Figure 5 is a diagram explaining the flow of defect document processing in this embodiment (equivalent to Figure 2 in the first embodiment), and the overall configuration of the device and the basic processing flow are the same as those in the first embodiment shown in Figures 1A and 3.

[0053] In Figure 5, LLM501 and LLM502 are language processing models with an encoder configuration. Typical examples include BERT (Bidirectional Encoder Representations from Transformers) and RoBERTa (Robustly optimized BERT approach), but any language processing model that outputs embeddings for tokens will suffice, and the present invention is not limited to a specific language processing model. Furthermore, each LLM is intended to be fine-tuned according to the task, with LLM501 being fine-tuned for named entity recognition and relationship extraction, and LLM502 being fine-tuned for named entity disambiguation tasks.

[0054] The update process of the defect knowledge DB 1124 in this embodiment will be described below with reference to FIG.

[0055] LLM 501 divides the defect report sentence 2011, similar to that shown in Figure 4B, into units called tokens based on the results of morphological analysis, etc., and obtains a token sequence, which is an embedding representation 503 as a numerical representation of each token, through a neural network. For example, when defect report sentence 2011, "The diesel engine automatically shut down due to damage to the cooling pump," is given to LLM 501, the token sequence obtained is ["cooling," "pump," "of," "damaged," "to," "by," "diesel," "engine," "was," "automatic," "stopped," "did," "had," "."]" and the numerical representation of each token is [v1, v2, ..., v14] (where each v is a multiple floating-point value).

[0056] The graph data and dictionary data in LLM203 are used to calculate the input representation vector to the neural network.

[0057] The named entity extraction process 504 extracts named entities from a sentence by labeling each token based on the embedded expressions and token sequence output by the LLM 501. Examples of labeling methods include the inside-outside-beginning (IOB) notation. For example, with the IOB notation, each token of ["cooling pump", "pump", "of", "damaged", "to", "by", "diesel", "engine", "ga", "automatic", "stopped", "did", "ta", "."] is labeled as [B,I,O,B,O,O,B,I,O,B,I,O,O,O], and the named entity list 506 is extracted as ["cooling pump", "damaged", "diesel engine", "automatic stop"].

[0058] The relationship extraction process 505 labels the relationships between named entities based on the embedded expressions and token strings output by the LLM 501 and the named entity list 506 described above, extracts the relationships, and outputs the results as a relationship list 507 as shown in Fig. 6A. This is synonymous with the relationship list 2132 (Fig. 4F) in the first embodiment.

[0059] Named entity / relationship integration process 508 performs the same processing as named entity / relationship integration process 2140 in the first embodiment. That is, it outputs graph data 509 as shown in Fig. 6B, which is obtained by integrating the named entity list 506 and relationship list 507 described above. This is synonymous with graph data 2141 in Fig. 4G.

[0060] The name matching process 511 compares the named entities included in the graph data 509 output from the named entity / relationship integration process 508 (the contents of the named entity list 506 output from the named entity extraction process 504) with the terms in the HW knowledge DB 510. As shown in Fig. 6C, the HW knowledge DB 510 of this embodiment has examples of term usage and explanations in a "Description" column 510A in addition to the components of the HW knowledge DB 1122A (Fig. 1C) of the first embodiment.

[0061] If the result of the comparison is that there is a named entity that is not included in the "Entity" of the HW knowledge DB 510, information on related terms is obtained from the HW knowledge DB 510, and sentence 511A is generated by adding an explanation of the term to the defect report sentence, and this sentence is output together with dictionary data 511B.

[0062] In this example, the named entities "diesel engine" and "cooling pump" are not included in the "Entity" of HW knowledge DB 511, so descriptions of the related terms "ID=101: diesel generator" and "ID=103: electric pump" are added to the malfunction report, generating sentence 511A as shown in Fig. 6D. Dictionary data 511B output at the same time is, for example, data of terms and synonyms extracted from HW knowledge DB 510 as shown in Fig. 6E.

[0063] In the LLM 502, the sentence 511A is converted into an embedded expression 512 using dictionary data 511B.

[0064] Similarity calculation process 1 (513) calculates the similarity between each of the different named entities ("cooling pump", "diesel engine", "diesel generator", "diesel engine", "cooling device") as a value between 0 and 1 based on the embedded representation 512 output from LLM 502, and outputs graph data 514 (FIG. 6F) in which each term in graph data 509 is unified with a term in HW knowledge DB 510 that has a high similarity to it (for example, a similarity of 0.98 or more) (the content is equivalent to that of FIG. 4J). The similarity can be calculated using, for example, a method using cosine similarity or a predicted value of a token label using a softmax function, but other methods are also possible.

[0065] Graph integration process 515 acquires graph data 514 obtained by similarity calculation process 1 (513) and related subgraph data 1124B from defect knowledge DB 1124, converts both (516) into embedded representation 517 by LLM 502, and compares the correspondence between named entities in both in similarity calculation process 2 (518). Once the correspondence is obtained, graph data 514 and subgraph data 1124B are integrated to obtain integrated graph data 519 similar to that shown in FIG. 4L.

[0066] The other processes are the same as those in the first embodiment.

[0067] As described above, according to this embodiment, by utilizing an LLM with an encoder configuration that obtains a high-dimensional vector representation (embedded representation) of input text, which is a language processing model with a relatively light processing load as an LLM, it is possible to construct a database that can appropriately diagnose defect reports that include variations in the descriptions and expressions of the same phenomenon, just as in the first embodiment, even in environments with limited computing resources or where the range of data use is limited. [Example]

[0068] In this embodiment, a mechanism has been added to the first embodiment in which the results of the named entity / relationship extraction process and the name matching process are verified and fed back, and the named entity extraction process (step S2120) and the relationship extraction process (step S2130) are re-executed.

[0069] A flowchart of this embodiment is shown in Figure 7. The same processing steps as in the first embodiment are given the same reference numerals. The extraction result verification process (step S2142) evaluates the graph data 2141 (Figure 4G) that is the output of the named entity / relationship integration process (step S2140), and outputs an instruction to re-execute the named entity extraction process (step S2120) or the relationship extraction process (step S2130) depending on the evaluation result.

[0070] Possible methods for evaluating graph data 2141 include a combination of evaluation using morphological analysis of named entities when multiple named entities are included in one extracted named entity, evaluation focusing on graph structure such as acyclicity of causal relationships, and evaluation by determining violations of relationship classification rules based on the classification of named entities, and an appropriate evaluation method is applied depending on the target product.

[0071] For example, when a sentence containing multiple named entities is recognized as a named entity, such as "electric pump broken," it must be further decomposed into "electric pump" and "broken" through morphological analysis. As a specific example of evaluation focusing on graph structure, if a bidirectional cause edge exists between "broken" and "automatic stop," it must be corrected to a unidirectional cause edge. As a specific example of evaluation based on named entity classification, if a cause edge exists between "electric pump" and "diesel engine," it must be deleted.

[0072] The correspondence matching process (step S2152) evaluates causal relationships based on the terms in the HW knowledge DB 1122 associated with the graph data 2154 (Figure 4J) obtained as a result of the name matching process (step S2150), and outputs instructions to re-execute named entity extraction or relationship extraction depending on the results.

[0073] For example, as an example of a leap in causality, if the cause in the malfunction knowledge DB 1124 shown in Figure 1B is linked from a "blockage" in a tank to a "failure to continue operating" of a diesel generator, it is necessary to supplement the causes in between, such as a "lack of water volume" or "overheating."

[0074] The extraction condition refinement process (step S2154) generates a correction prompt based on instructions obtained from the extraction result verification process (step S2142) or the correspondence matching process (step S2152) described above, and passes it to the named entity extraction process (step S2120) or the relationship extraction process (step S2130). An example of a correction prompt is shown in Figure 8.

[0075] The other processing steps are the same as those in the first embodiment.

[0076] As described above, according to this embodiment, the results of the named entity / relationship extraction process and the name matching process are verified, fed back, and re-executed, thereby further improving the accuracy of these processes. [Explanation of symbols]

[0077] 1000: Defective document processing device 1100: Processor system 1110: Processor 1120: Memory resource section 1121: Program Department 1121A: Update processing program 1121B: Malfunction diagnosis processing program section 1122: Hardware (HW) Knowledge DB Department 1123: Language processing model 1124: Defect Knowledge DB Department 1125: Defect report memory section 1130: Network interface section 1140: User interface section 1200: Input / output device 1300:Network

Claims

1. A defect document processing device that extracts defect causes from defect reports that describe product defects and builds a defect knowledge database, a fault knowledge database storing information about the faults; A hardware knowledge database that stores product part names, their synonyms, and design information; an input / output unit for inputting and outputting information; a processor unit that performs predetermined arithmetic processing, The processor unit a named entity extraction process for extracting terms related to components of the target product and the defects thereof from the defect report text based on the defect report; A relationship extraction process for extracting relationships between named entities from the defect report sentence; a named entity / relationship integration process that generates first graph data from a result of the named entity extraction process and a result of the relationship extraction process; a name matching process for collating the named entities of the first graph data with the hardware knowledge database to obtain second graph data in which elements of synonymous expressions have been corrected; a graph integration process for linking the second graph data with the named entities in the defect knowledge database to generate third graph data; a fault knowledge database update process for comparing the third graph data with the fault knowledge database and updating the fault knowledge database; A defect document processing device characterized by performing the above.

2. 2. The defect document processing device according to claim 1, the processor unit executes the named entity extraction process, the relationship extraction process, and the name identification process using a predetermined language processing model. A defect document processing device.

3. 2. The defect document processing device according to claim 1, The hardware knowledge database includes: It contains information on the terminology, inclusion relationships, failure modes, and synonyms of equipment components, and updates the information based on the results of the name matching process. A defect document processing device.

4. 2. The defect document processing device according to claim 1, storing the components of the hardware knowledge database in the failure knowledge database; The processor unit performing a name matching process using the defect knowledge database; A defect document processing device.

5. 2. The defect document processing device according to claim 1, The fault knowledge database is a knowledge graph that represents the relationships between fault-related phenomena, their occurrence locations, and their causal relationships. A defect document processing device.

6. 6. The defect document processing device according to claim 5, the fault knowledge database is a Bayesian network including probability information in the causal relationships; A defect document processing device.

7. 2. The defect document processing device according to claim 1, analyzing the hardware configuration information of the fault knowledge database from the design-related text in the same flow, and updating the fault knowledge database; A defect document processing device.

8. 3. The defect document processing device according to claim 2, the language processing model is a model that outputs a response sentence corresponding to an input instruction sentence, The directive may be: A statement instructing a processing procedure for the named entity extraction processing; A statement instructing a processing procedure for the relationship extraction processing; a statement instructing a processing procedure for the name identification processing; A defect document processing device.

9. 3. The defect document processing device according to claim 2, the language processing model is a model that outputs a multidimensional numerical array for an input text, The named entity extraction process labels words in a sentence based on the output of the numerical array, and outputs the result as a named entity list; The relationship extraction process outputs a relationship list based on the output numerical array and the named entity list; the name matching process performs a process of associating named entities included in the named entity list with terms in the hardware knowledge database by a similarity calculation process using a numerical value array output, the graph integration process is a process of associating named entities included in the named entity list with terms in the defect knowledge database by a similarity calculation process using a numerical value array output; A defect document processing device.

10. 2. The defect document processing device according to claim 1, The processor unit an extraction result verification process that evaluates a result of the named entity / relationship integration process and generates an instruction to re-execute the named entity extraction process or the relationship extraction process according to the evaluation result; a correspondence matching process for evaluating a result of the name identification process and generating an instruction to re-execute the named entity extraction process or the relationship extraction process according to the evaluation result; an extraction condition refinement process that generates a prompt to modify the processing content of the named entity extraction process or the relationship extraction process based on instructions generated in the extraction result verification process and the correspondence relationship matching process; A defect document processing device characterized by performing the above.

11. A defect document processing method for extracting defect causes from defect reports describing product defects and constructing a defect knowledge database, comprising: a named entity extraction process for extracting terms related to components of the target product and the defects thereof from the defect report text based on the defect report; A relationship extraction process for extracting relationships between named entities from the defect report sentence; a named entity / relationship integration process that generates first graph data from a result of the named entity extraction process and a result of the relationship extraction process; a name matching process for collating the named entities of the first graph data with a first database storing names of product parts, their synonyms, and design information, and obtaining second graph data in which elements of synonymous expressions have been corrected; a graph integration process for linking the second graph data with named entities in a second database that stores information about product defects to generate third graph data; a database update process for comparing the third graph data with the second database and updating the second database; A defect document processing method comprising:

Images